git/git.git
14 years agoMerge branch 'master' of git://repo.or.cz/git/fastimport
Junio C Hamano [Wed, 7 Feb 2007 16:39:16 +0000 (08:39 -0800)]
Merge branch 'master' of git://repo.or.cz/git/fastimport

* 'master' of git://repo.or.cz/git/fastimport:
  Add a Tips and Tricks section to fast-import's manual.
  Don't crash fast-import if the marks cannot be exported.
  Dump all refs and marks during a checkpoint in fast-import.
  Teach fast-import how to sit quietly in the corner.
  Teach fast-import how to clear the internal branch content.
  Minor timestamp related documentation corrections for fast-import.

14 years agogit-clone --reference: work well with pack-ref'ed reference repository
Junio C Hamano [Wed, 7 Feb 2007 10:10:56 +0000 (02:10 -0800)]
git-clone --reference: work well with pack-ref'ed reference repository

Earlier we only used loose refs to anchor already existing
objects.  When cloning from a repository that forked relatively
long time ago from the reference repository, this made the
want/have exchange by fetch-pack to do unnecessary work.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoAdd a Tips and Tricks section to fast-import's manual.
Shawn O. Pearce [Wed, 7 Feb 2007 08:49:08 +0000 (03:49 -0500)]
Add a Tips and Tricks section to fast-import's manual.

There has been some informative lessons learned in the gfi user
community, and these really should be written down and documented
for future generations of frontend developers.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years agoAvoid ActiveState Perl IO in t800[12]
Alex Riesen [Mon, 5 Feb 2007 13:04:09 +0000 (14:04 +0100)]
Avoid ActiveState Perl IO in t800[12]

Use sed instead, it comes with cygwin and there is almost no chance of
someone installing a sed with default CRLF lineendings by accident.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoDocumentation: add KMail in SubmittingPatches
Michael [Mon, 5 Feb 2007 13:27:32 +0000 (14:27 +0100)]
Documentation: add KMail in SubmittingPatches

Signed-off-by: Michael <barra_cuda@katamail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoDon't crash fast-import if the marks cannot be exported.
Shawn O. Pearce [Wed, 7 Feb 2007 07:46:35 +0000 (02:46 -0500)]
Don't crash fast-import if the marks cannot be exported.

Apparently fast-import used to die a horrible death if we
were unable to open the marks file for output.  This is
slightly less than ideal, especially now that we dump
the marks as part of the `checkpoint` command.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years agoDump all refs and marks during a checkpoint in fast-import.
Shawn O. Pearce [Wed, 7 Feb 2007 07:42:44 +0000 (02:42 -0500)]
Dump all refs and marks during a checkpoint in fast-import.

If the frontend asks us to checkpoint (via the explicit checkpoint
command) its probably because they are afraid the current import
will crash/fail/whatever and want to make sure they can pickup from
the last checkpoint.  To do that sort of recovery, we will need the
current tip of every branch and tag available at the next startup.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years agoTeach fast-import how to sit quietly in the corner.
Shawn O. Pearce [Wed, 7 Feb 2007 07:19:31 +0000 (02:19 -0500)]
Teach fast-import how to sit quietly in the corner.

Often users will be running fast-import from within a larger frontend
process, and this may be a frequent periodic tool such as a future
edition of `git-svn fetch`.  We don't want to bombard users with our
large stats output if they won't be interested in it, so `--quiet`
is now an option to make gfi be more silent.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years agoTeach fast-import how to clear the internal branch content.
Shawn O. Pearce [Wed, 7 Feb 2007 07:03:03 +0000 (02:03 -0500)]
Teach fast-import how to clear the internal branch content.

Some frontends may not be able to (easily) keep track of which files
are included in the branch, and which aren't.  Performing this
tracking can be tedious and error prone for the frontend to do,
especially if its foreign data source cannot supply the changed
path list on a per-commit basis.

fast-import now allows a frontend to request that a branch's tree
be wiped clean (reset to the empty tree) at the start of a commit,
allowing the frontend to feed in all paths which belong on the branch.

This is ideal for a tar-file importer frontend, for example, as
the frontend just needs to reformat the tar data stream into a gfi
data stream, which may be something a few Perl regexps can take
care of. :)

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years agoMinor timestamp related documentation corrections for fast-import.
Shawn O. Pearce [Wed, 7 Feb 2007 05:51:58 +0000 (00:51 -0500)]
Minor timestamp related documentation corrections for fast-import.

As discussed on the mailing list, the documentation used here was
not quite accurate.  Improve upon it.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years agoRemove git-merge-recur
Junio C Hamano [Wed, 7 Feb 2007 05:27:09 +0000 (21:27 -0800)]
Remove git-merge-recur

This was useful when the current recursive was in development, and
the original Python version was still called git-merge-recursive.

Now the synonym has served us well, it is time to move on.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoAdd deprecation notices.
Junio C Hamano [Wed, 7 Feb 2007 05:25:33 +0000 (21:25 -0800)]
Add deprecation notices.

Schedule git-diff-stages and git-resolve to be removed by 1.5.1

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoMerge branch 'master' of git://repo.or.cz/git/fastimport
Junio C Hamano [Wed, 7 Feb 2007 03:33:22 +0000 (19:33 -0800)]
Merge branch 'master' of git://repo.or.cz/git/fastimport

* 'master' of git://repo.or.cz/git/fastimport: (81 commits)
  S_IFLNK != 0140000
  Don't do non-fastforward updates in fast-import.
  Support RFC 2822 date parsing in fast-import.
  Minor fast-import documentation corrections.
  Remove unnecessary null pointer checks in fast-import.
  Correct fast-import timezone documentation.
  Correct minor style issue in fast-import.
  Correct compiler warnings in fast-import.
  Remove --branch-log from fast-import.
  Initial draft of fast-import documentation.
  Don't support shell-quoted refnames in fast-import.
  Reduce memory usage of fast-import.
  Include checkpoint command in the BNF.
  Accept 'inline' file data in fast-import commit structure.
  Reduce value duplication in t9300-fast-import.
  Create test case for fast-import.
  Support delimited data regions in fast-import.
  Remove unnecessary options from fast-import.
  Use fixed-size integers when writing out the index in fast-import.
  Always use struct pack_header for pack header in fast-import.
  ...

14 years agoRemove contrib/colordiff
Junio C Hamano [Wed, 7 Feb 2007 00:33:16 +0000 (16:33 -0800)]
Remove contrib/colordiff

This has completely been superseded by built-in --color option.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoCall make always with CFLAGS in git.spec
Horst H. von Brand [Tue, 6 Feb 2007 19:08:55 +0000 (16:08 -0300)]
Call make always with CFLAGS in git.spec

If not, the binaries get built once with the correct CFLAGS, and then again
with the ones in the Makefile when installing

Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoadd replay and log to the usage string of git-bisect
Uwe Kleine-König [Tue, 6 Feb 2007 17:28:32 +0000 (18:28 +0100)]
add replay and log to the usage string of git-bisect

Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoS_IFLNK != 0140000
Junio C Hamano [Tue, 6 Feb 2007 20:46:11 +0000 (12:46 -0800)]
S_IFLNK != 0140000

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years agoDon't do non-fastforward updates in fast-import.
Shawn O. Pearce [Tue, 6 Feb 2007 21:08:06 +0000 (16:08 -0500)]
Don't do non-fastforward updates in fast-import.

If fast-import is being used to update an existing branch of
a repository, the user may not want to lose commits if another
process updates the same ref at the same time.  For example, the
user might be using fast-import to make just one or two commits
against a live branch.

We now perform a fast-forward check during the ref updating process.
If updating a branch would cause commits in that branch to be lost,
we skip over it and display the new SHA1 to standard error.

This new default behavior can be overridden with `--force`, like
git-push and git-fetch.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years agoSupport RFC 2822 date parsing in fast-import.
Shawn O. Pearce [Tue, 6 Feb 2007 19:58:30 +0000 (14:58 -0500)]
Support RFC 2822 date parsing in fast-import.

Since some frontends may be working with source material where
the dates are only readily available as RFC 2822 strings, it is
more friendly if fast-import exposes Git's parse_date() function
to handle the conversion.  This way the frontend doesn't need
to perform the parsing itself.

The new --date-format option to fast-import can be used by a
frontend to select which format it will supply date strings in.
The default is the standard `raw` Git format, which fast-import
has always supported.  Format rfc2822 can be used to activate the
parse_date() function instead.

Because fast-import could also be useful for creating new, current
commits, the format `now` is also supported to generate the current
system timestamp.  The implementation of `now` is a trivial call
to datestamp(), but is actually a whole whopping 3 lines so that
fast-import can verify the frontend really meant `now`.

As part of this change I have added validation of the `raw` date
format.  Prior to this change fast-import would accept anything
in a `committer` command, even if it was seriously malformed.
Now fast-import requires the '> ' near the end of the string and
verifies the timestamp is formatted properly.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years agoMinor fast-import documentation corrections.
Shawn O. Pearce [Tue, 6 Feb 2007 17:35:02 +0000 (12:35 -0500)]
Minor fast-import documentation corrections.

Corrected a couple of header markup lines which were shorter than the
actual header, and made the `data` commands two formats into a named
list, which matches how we document the two formats of the `M` command
within a commit.

Also tried to simplify the language about our decimal integer format;
Linus pointed out I was probably being too specific at the cost of
reduced readability.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years agoRemove unnecessary null pointer checks in fast-import.
Shawn O. Pearce [Tue, 6 Feb 2007 17:05:51 +0000 (12:05 -0500)]
Remove unnecessary null pointer checks in fast-import.

There is no need to check for a NULL pointer before invoking free(),
the runtime library automatically performs this check anyway and
does nothing if a NULL pointer is supplied.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years agoCorrect fast-import timezone documentation.
Shawn O. Pearce [Tue, 6 Feb 2007 16:59:11 +0000 (11:59 -0500)]
Correct fast-import timezone documentation.

Andy Parkins and Linus Torvalds both noticed that the description
of the timezone was incorrect.  Its not expressed in minutes.
Its more like "hhmm", where "hh" is the number of hours and "mm"
is the number of minutes shifted from GMT/UTC.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years agoannotate: fix for cvsserver.
Junio C Hamano [Tue, 6 Feb 2007 09:52:04 +0000 (01:52 -0800)]
annotate: fix for cvsserver.

git-cvsserver does not want the boundary commits shown any differently.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agogitweb: fix mismatched parenthesis
Junio C Hamano [Tue, 6 Feb 2007 09:09:32 +0000 (01:09 -0800)]
gitweb: fix mismatched parenthesis

An earlier commit 04179418 broke gitweb.  Badly.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agogit-push: allow globbing wildcard refspec.
Junio C Hamano [Tue, 6 Feb 2007 07:01:14 +0000 (23:01 -0800)]
git-push: allow globbing wildcard refspec.

This allows you to set up mothership-satellite configuration
more symmetrically and naturally by allowing the globbing
wildcard refspec for git-push.  On your satellite machine:

    [remote "mothership"]
        url = mothership:project.git
        fetch = refs/heads/*:refs/remotes/mothership/*
        push = refs/heads/*:refs/remotes/satellite/*

You would say "git fetch mothership" to update your tracking
branches under mothership/ to keep track of the progress on the
mothership side, and when you are done working on the satellite
machine, you would "git push mothership" to update their
tracking branches under satellite/.  Corresponding configuration
on the mothership machine can be used to make "git fetch satellite"
update its tracking branch under satellite/. on the mothership.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoCorrect minor style issue in fast-import.
Shawn O. Pearce [Tue, 6 Feb 2007 05:43:59 +0000 (00:43 -0500)]
Correct minor style issue in fast-import.

Junio noticed that I was using a different style in fast-import
for returned pointers than the rest of Git.  Before merging this
code into the main git.git tree I'd like to make it consistent,
as this style variation was not intentional.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years agoCorrect compiler warnings in fast-import.
Shawn O. Pearce [Tue, 6 Feb 2007 05:26:49 +0000 (00:26 -0500)]
Correct compiler warnings in fast-import.

Junio noticed these warnings/errors in fast-import when compiling
with `-Werror -ansi -pedantic`.  A few changes are to reduce compiler
warnings, while one (in cmd_merge) is a bug fix.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years agoRemove --branch-log from fast-import.
Shawn O. Pearce [Tue, 6 Feb 2007 05:15:37 +0000 (00:15 -0500)]
Remove --branch-log from fast-import.

The --branch-log option and its associated code hasn't been used in
several months, as its not really very useful for debugging fast-import
or a frontend.  I don't plan on supporting it in this state long-term,
so I'm killing it now before it gets distributed to a wider audience.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years agobash: Complete git-remote subcommands.
Shawn O. Pearce [Mon, 5 Feb 2007 04:52:08 +0000 (23:52 -0500)]
bash: Complete git-remote subcommands.

Completing the 3 core subcommands to git-remote, along with the
names of remotes for 'show' and 'prune' (which take only existing
remotes) is handy.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agobash: Support git-rebase -m continuation completion.
Shawn O. Pearce [Mon, 5 Feb 2007 04:52:02 +0000 (23:52 -0500)]
bash: Support git-rebase -m continuation completion.

Apparently `git-rebase -m` uses a metadata directory within .git
(.git/.dotest-merge) rather than .dotest used by git-am (and
git-rebase without the -m option).  This caused the completion code
to not offer --continue, --skip or --abort when working within a
`git-rebase -m` session.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoInitial draft of fast-import documentation.
Shawn O. Pearce [Tue, 6 Feb 2007 02:09:25 +0000 (21:09 -0500)]
Initial draft of fast-import documentation.

This is a first pass at the manpage for git-fast-import.

I have tried to cover the input format in extreme detail, creating a
reference which is more detailed than the BNF grammar appearing in
the header of fast-import.c.  I have also covered some details about
gfi's performance and memory utilization, as well as the average
learning curve required to create a gfi frontend application (as it
is far lower than it might appear on first glance).

The documentation still lacks real example input streams, which may
turn out to be difficult to format in asciidoc due to the blank lines
which carry meaning within the format.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years agoDon't support shell-quoted refnames in fast-import.
Shawn O. Pearce [Tue, 6 Feb 2007 01:30:37 +0000 (20:30 -0500)]
Don't support shell-quoted refnames in fast-import.

The current implementation of shell-style quoted refnames and
SHA-1 expressions within fast-import contains a bad memory leak.
We leak the unquoted strings used by the `from` and `merge`
commands, maybe others.  Its also just muddling up the docs.

Since Git refnames cannot contain LF, and that is our delimiter
for the end of the refname, and we accept any other character
as-is, there is no reason for these strings to support quoting,
except to be nice to frontends.  But frontends shouldn't be
expecting to use funny refs in Git, and its just as simple to
never quote them as it is to always pass them through the same
quoting filter as pathnames.  So frontends should never quote
refs, or ref expressions.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years agoFix longstanding mismerge of ALL_CFLAGS vs BASIC_CFLAGS
Junio C Hamano [Tue, 6 Feb 2007 00:53:12 +0000 (16:53 -0800)]
Fix longstanding mismerge of ALL_CFLAGS vs BASIC_CFLAGS

The earlier commit d7b6c3c0 (Aug 15, 2006) introduced this
mismerge when most of the CFLAGS were renamed to BASIC_CFLAGS.

Not that it matters right now, since we do not compile XS
Perl extensions which wanted non GNU subset of ALL_CFLAGS for
compilation, but we should make things consistent.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agopager: Work around window resizing bug in 'less'
Linus Torvalds [Wed, 24 Jan 2007 19:21:10 +0000 (11:21 -0800)]
pager: Work around window resizing bug in 'less'

If you resize the terminal while less is waiting for input, less
will exit entirely without even showing the output. This is very
noticeable if you do something like "git diff" on a big and
cold-cache tree and git takes a few seconds to think, and then
you resize the window while it's preparing. Boom. No output AT
ALL.

The way to reproduce the problem is to do some pager operation
that takes a while in git, and resizing the window while git is
thinking about the output.  Try

git diff --stat v2.6.12..

in the kernel tree to do something where it takes a while for git to start
outputting information.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoTeach git-remote add to fetch and track
Junio C Hamano [Fri, 2 Feb 2007 07:30:03 +0000 (23:30 -0800)]
Teach git-remote add to fetch and track

This adds three options to 'git-remote add'.

 * -f (or --fetch) option tells it to also run the initial "git
    fetch" using the newly created remote shorthand.

 * -t (or --track) option tells it not to use the default
    wildcard to track all branches.

 * -m (or --master) option tells it to make the
    remote/$name/HEAD point at a remote tracking branch other
    than master.

For example, with this I can say:

  $ git remote add -f -t master -t quick-start -m master \
    jbf-um git://linux-nfs.org/~bfields/git.git/

to

 (1) create remote.jbf-um.url;

 (2) track master and quick-start branches (and no other); the
     two -t options create these two lines:

       fetch = +refs/heads/master:refs/remotes/jbf-um/master
       fetch = +refs/heads/quick-start:refs/remotes/jbf-um/quick-start

 (3) set up remotes/jbf-um/HEAD to point at jbf-um/master so
     that later I can say "git log jbf-um"

Or I could do

  $ git remote add -t 'ap/*' andy /home/andy/git.git

to make Andy's topic branches kept track of under refs/remotes/andy/ap/.

Other possible improvements I considered but haven't implemented
(hint, hint) are:

 * reject wildcard letters other than a trailing '*' to the -t
   parameter;

 * make -m optional and when the first -t parameter does not
   have the trailing '*' default to that value (so the above
   example does not need to say "-m master");

 * if -m is not given, and -t parameter ends with '*' (i.e. the
   above defaulting did not tell us where to point HEAD at), and
   if we did the fetch with -f, check if 'master' was fetched
   and make HEAD point at it.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoblame: document --contents option
Junio C Hamano [Mon, 5 Feb 2007 23:04:01 +0000 (15:04 -0800)]
blame: document --contents option

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoUse pretend_sha1_file() in git-blame and git-merge-recursive.
Junio C Hamano [Mon, 5 Feb 2007 05:49:05 +0000 (21:49 -0800)]
Use pretend_sha1_file() in git-blame and git-merge-recursive.

git-merge-recursive wants an null tree as the fake merge base
while producing the merge result tree.  The null tree does not
have to be written out in the object store as it won't be part
of the result, and it is a prime example for using the new
pretend_sha1_file() function.

git-blame needs to register an arbitrary data to in-core index
while annotating a working tree file (or standard input), but
git-blame is a read-only application and the user of it could
even lack the privilege to write into the object store; it is
another good example for pretend_sha1_file().

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoAdd pretend_sha1_file() interface.
Junio C Hamano [Mon, 5 Feb 2007 05:42:38 +0000 (21:42 -0800)]
Add pretend_sha1_file() interface.

The new interface allows an application to temporarily hash a
small number of objects and pretend that they are available in
the object store without actually writing them.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agogit-blame: no rev means start from the working tree file.
Junio C Hamano [Tue, 30 Jan 2007 09:11:08 +0000 (01:11 -0800)]
git-blame: no rev means start from the working tree file.

Warning: this changes the semantics.

This makes "git blame" without any positive rev to start digging
from the working tree copy, which is made into a fake commit
whose sole parent is the HEAD.

It also adds --contents <file> option to pretend as if the
working tree copy has the contents of the named file.  You can
use '-' to make the command read from the standard input.

If you want the command to start annotating from the HEAD
commit, you need to explicitly give HEAD parameter.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agogit-blame: an Emacs minor mode to view file with git-blame output.
David Kågedal [Mon, 5 Feb 2007 22:22:28 +0000 (14:22 -0800)]
git-blame: an Emacs minor mode to view file with git-blame output.

Here's another version of git-blame.el that automatically tries to
create a sensible list of colors to use for both light and dark
backgrounds.  Plus a few minor fixes.

To use:

  1) Load into emacs: M-x load-file RET git-blame.el RET
  2) Open a git-controlled file
  3) Blame: M-x git-blame-mode

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoAllow forcing of a parent commit, even if the parent is not a direct one.
Simon 'corecode' Schubert [Thu, 1 Feb 2007 10:43:39 +0000 (11:43 +0100)]
Allow forcing of a parent commit, even if the parent is not a direct one.

This can be used to compress multiple changesets into one, for example
like

git cvsexportcommit -P cvshead mybranch

without having to do so in git first.

Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agobisect: it needs to be done in a working tree.
Junio C Hamano [Mon, 5 Feb 2007 22:03:27 +0000 (14:03 -0800)]
bisect: it needs to be done in a working tree.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoCommands requiring a work tree must not run in GIT_DIR
Johannes Schindelin [Tue, 23 Jan 2007 12:30:20 +0000 (13:30 +0100)]
Commands requiring a work tree must not run in GIT_DIR

This patch helps when you accidentally run something like git-clean
in the git directory instead of the work tree.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoAdd hg-to-git conversion utility.
Stelian Pop [Fri, 12 Jan 2007 21:57:03 +0000 (22:57 +0100)]
Add hg-to-git conversion utility.

hg-to-git.py  is able to convert a Mercurial repository into a git one,
and preserves the branches in the process (unlike tailor)

hg-to-git.py can probably be greatly improved (it's a rather crude
combination of shell and python) but it does already work quite well for
me. Features:
- supports incremental conversion
  (for keeping a git repo in sync with a hg one)
- supports hg branches
- converts hg tags

Signed-off-by: Stelian Pop <stelian@popies.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoblameview: Support browsable functionality to blameview.
Aneesh Kumar K.V [Tue, 30 Jan 2007 07:56:50 +0000 (13:26 +0530)]
blameview: Support browsable functionality to blameview.

Double clicking on the row execs a new blameview with commit hash
as argument.

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agogitweb: Convert project name to UTF-8
Yasushi SHOJI [Tue, 30 Jan 2007 10:23:38 +0000 (19:23 +0900)]
gitweb: Convert project name to UTF-8

If the repository directory name is in non-ascii, $project needs to be
converted from perl internal to utf-8 because it will be used as
title, page path, and snapshot filename.

use to_utf8() to do the conversion.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agobash: Support git-bisect and its subcommands.
Shawn O. Pearce [Mon, 5 Feb 2007 20:44:37 +0000 (15:44 -0500)]
bash: Support git-bisect and its subcommands.

We now offer completion support for git-bisect's subcommands,
as well as ref name completion on the good/bad/reset subcommands.
This should make interacting with git-bisect slightly easier on
the fingers.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agobash: Support --add completion to git-config.
Shawn O. Pearce [Mon, 5 Feb 2007 20:44:32 +0000 (15:44 -0500)]
bash: Support --add completion to git-config.

We've recently added --add as an argument to git-config, but I
missed putting it into the earlier round of git-config updates
within the bash completion.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agobash: Hide git-resolve, its deprecated.
Shawn O. Pearce [Mon, 5 Feb 2007 20:44:30 +0000 (15:44 -0500)]
bash: Hide git-resolve, its deprecated.

Don't offer resolve as a possible subcommand completion.  If you
read the top of the script, there is a big warning about how it
will go away soon in the near future.  People should not be using it.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agobash: Offer --prune completion for git-gc.
Shawn O. Pearce [Mon, 5 Feb 2007 20:44:28 +0000 (15:44 -0500)]
bash: Offer --prune completion for git-gc.

I'm lazy.  I don't want to type out --prune if bash can do it for
me with --<tab>.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agobash: Hide diff-stages from completion.
Shawn O. Pearce [Mon, 5 Feb 2007 20:44:24 +0000 (15:44 -0500)]
bash: Hide diff-stages from completion.

Apparently nobody really makes use of git-diff-stages, as nobody
has complained that it is not supported by the git-diff frontend.
Since its likely this will go away in the future, we should not
offer it as a possible subcommand completion.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agobash: Support completion on git-cherry.
Shawn O. Pearce [Mon, 5 Feb 2007 20:44:22 +0000 (15:44 -0500)]
bash: Support completion on git-cherry.

I just realized I did not support ref name completion for git-cherry.
This tool is just too useful to contributors who submit patches
upstream by email; completion support for it is very handy.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoShow an example of deleting commits with git-rebase.
Shawn O. Pearce [Mon, 5 Feb 2007 20:21:06 +0000 (15:21 -0500)]
Show an example of deleting commits with git-rebase.

This particular use of git-rebase to remove a single commit or a
range of commits from the history of a branch recently came up on
the mailing list.  Documenting the example should help other users
arrive at the same solution on their own.

It also was not obvious to the newcomer that git-rebase is able to
accept any commit for --onto <newbase> and <upstream>.  We should
at least minimally document this, as much of the language in
git-rebase's manpage refers to 'branch' rather than 'committish'.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agogit-for-each-ref doesn't return "the bit after $GIT_DIR/refs"
Andy Parkins [Mon, 5 Feb 2007 19:58:47 +0000 (19:58 +0000)]
git-for-each-ref doesn't return "the bit after $GIT_DIR/refs"

The documentation for git-for-each-ref said that the refname variable
would return "the part after $GIT_DIR/refs/", which isn't true.

Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agot9200: Work around HFS+ issues.
Junio C Hamano [Mon, 5 Feb 2007 01:30:58 +0000 (17:30 -0800)]
t9200: Work around HFS+ issues.

We at least know that the test as written has a problem in an
environment where "touch '$p'; ls | fgrep '$p'" fails, and have
a clear understand why it fails.

This tests if the filesystem has that particular issue we know "git
add" has a problem with, and skips the test in such an environment.
This way, we might catch issues "git add" might have in other environments.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoReduce memory usage of fast-import.
Shawn O. Pearce [Mon, 5 Feb 2007 21:34:56 +0000 (16:34 -0500)]
Reduce memory usage of fast-import.

Some structs are allocated rather frequently, but were using integer
types which were far larger than required to actually store their
full value range.

As packfiles are limited to 4 GiB we don't need more than 32 bits to
store the offset of an object within that packfile, an `unsigned long`
on a 64 bit system is likely a 64 bit unsigned value.  Saving 4 bytes
per object on a 64 bit system can add up fast on any sizable import.

As atom strings are strictly single components in a path name these
are probably limited to just 255 bytes by the underlying OS.  Going
to that short of a string is probably too restrictive, but certainly
`unsigned int` is far too large for their lengths.  `unsigned short`
is a reasonable limit.

Modes within a tree really only need two bytes to store their whole
value; using `unsigned int` here is vast overkill.  Saving 4 bytes
per file entry in an active branch can add up quickly on a project
with a large number of files.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years agoInclude checkpoint command in the BNF.
Shawn O. Pearce [Mon, 5 Feb 2007 21:05:11 +0000 (16:05 -0500)]
Include checkpoint command in the BNF.

This command isn't encouraged (as its slow) but it does exist and
is accepted, so it still should be covered in the BNF.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years agoRename get_ident() to fmt_ident() and make it available to outside
Junio C Hamano [Mon, 5 Feb 2007 01:50:14 +0000 (17:50 -0800)]
Rename get_ident() to fmt_ident() and make it available to outside

This makes the functionality of ident.c::get_ident() available to
other callers.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agogit-archimport: initial import needs empty directory
Gerrit Pape [Sat, 3 Feb 2007 22:38:59 +0000 (22:38 +0000)]
git-archimport: initial import needs empty directory

git-archimport should better refuse to start an initial import if the
current directory is not empty.

(http://bugs.debian.org/400508)

Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoRevert "Allow branch.*.merge to talk about remote tracking branches."
Junio C Hamano [Sun, 4 Feb 2007 00:23:38 +0000 (16:23 -0800)]
Revert "Allow branch.*.merge to talk about remote tracking branches."

This reverts commit 80c797764a6b6a373f0f1f47d7f56b0d950418a9.

Back when I committed this, it seemed to be a good idea.  People
who always use remote tracking branches can optionally use the
local name they happen to use to specify what to merge, which meant
that I did not have to teach them why we use the name at the remote
side every time they are confused.

But allowing it seems to break other people's scripts.  The real
solution is not to allow more ways to express the same thing, but
to educate people to use the right syntax.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoMerge branch 'np/dreflog'
Junio C Hamano [Mon, 5 Feb 2007 00:54:47 +0000 (16:54 -0800)]
Merge branch 'np/dreflog'

* np/dreflog:
  show-branch -g: default to the current branch.
  Let git-checkout always drop any detached head
  Enable HEAD@{...} and make it independent from the current branch
  scan reflogs independently from refs
  add reflog when moving HEAD to a new branch
  create_symref(): do not assume pathname from git_path() persists long enough
  add logref support to git-symbolic-ref
  move create_symref() past log_ref_write()
  add reflog entries for HEAD when detached
  enable separate reflog for HEAD
  lock_ref_sha1_basic(): remember the original name of a ref when resolving it
  make reflog filename independent from struct ref_lock

14 years agoWhy is it bad to rewind a branch that has already been pushed out?
Robin Rosenberg [Sun, 4 Feb 2007 16:16:39 +0000 (17:16 +0100)]
Why is it bad to rewind a branch that has already been pushed out?

Mention git-revert as an alternative to git-reset to revert changes.

Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agogit-clone --reference: saner handling of borrowed symrefs.
Junio C Hamano [Sun, 4 Feb 2007 11:25:12 +0000 (03:25 -0800)]
git-clone --reference: saner handling of borrowed symrefs.

When using --reference to borrow objects from a neighbouring
repository while cloning, we copy the entire set of refs under
temporary "refs/reference-tmp/refs" space and set up the object
alternates.  However, a textual symref copied this way would not
point at the right place, and causes later steps to emit error
messages (which is harmless but still alarming).  This is most
visible when using a clone created with the separate-remote
layout as a reference, because such a repository would have
refs/remotes/origin/HEAD with 'ref: refs/remotes/origin/master'
as its contents.

Although we do not create symbolic-link based refs anymore, they
have the same problem because they are always supposed to be
relative to refs/ hierarchy (we dereference by hand, so it only
is good for HEAD and nothing else).

In either case, the solution is simply to remove them after
copying under refs/reference-tmp; if a symref points at a true
ref, that true ref itself is enough to ensure that objects
reachable from it do not needlessly get fetched.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agobash: Support internal revlist options better.
Shawn O. Pearce [Sun, 4 Feb 2007 07:38:47 +0000 (02:38 -0500)]
bash: Support internal revlist options better.

format-patch/log/whatchanged all take --not and --all as options
to the internal revlist process.  So these should be supported
as possible completions.

gitk takes anything rev-list/log/whatchanged takes, so we should
use complete_revlist to handle its options.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agobash: Support unique completion when possible.
Shawn O. Pearce [Sun, 4 Feb 2007 07:38:43 +0000 (02:38 -0500)]
bash: Support unique completion when possible.

Because our use of -o nospace prevents bash from adding a trailing space
when a completion is unique and has been fully completed, we need to
perform this addition on our own.  This (large) change converts all
existing uses of compgen to our wrapper __gitcomp which attempts to
handle this by tacking a trailing space onto the end of each offered
option.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agobash: Support unique completion on git-config.
Shawn O. Pearce [Sun, 4 Feb 2007 07:38:37 +0000 (02:38 -0500)]
bash: Support unique completion on git-config.

In many cases we know a completion will be unique, but we've disabled
bash's automatic space addition (-o nospace) so we need to do it
ourselves when necessary.

This change adds additional support for new configuration options
added in 1.5.0, as well as some extended completion support for
the color.* family of options.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agobash: Classify more commends out of completion.
Shawn O. Pearce [Sun, 4 Feb 2007 07:38:30 +0000 (02:38 -0500)]
bash: Classify more commends out of completion.

Most of these commands are not ones you want to invoke from the
command line on a frequent basis, or have been renamed in 1.5.0 to
more friendly versions, but the old names are being left behind to
support existing scripts in the wild.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agobash: Add space after unique command name is completed.
Shawn O. Pearce [Sun, 4 Feb 2007 07:38:27 +0000 (02:38 -0500)]
bash: Add space after unique command name is completed.

Because we use the nospace option for our completion function for
the main 'git' wrapper bash won't automatically add a space after a
unique completion has been made by the user.  This has been pointed
out in the past by Linus Torvalds as an undesired behavior.  I agree.

We have to use the nospace option to ensure path completion for
a command such as `git show` works properly, but that breaks the
common case of getting the space for a unique completion.  So now we
set IFS=$'\n' (linefeed) and add a trailing space to every possible
completion option.  This causes bash to insert the space when the
completion is unique.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agobash: Complete long options to git-add.
Shawn O. Pearce [Sun, 4 Feb 2007 07:38:23 +0000 (02:38 -0500)]
bash: Complete long options to git-add.

The new --interactive mode of git-add can be very useful, so users
will probably want to have completion for it.

Likewise the new git-add--interactive executable is actually a
plumbing command.  Its invoked by `git add --interactive` and is
not intended to be invoked directly by the user.  Therefore we
should hide it from the list of available Git commands.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agobash: Classify cat-file and reflog as plumbing.
Shawn O. Pearce [Sun, 4 Feb 2007 07:38:21 +0000 (02:38 -0500)]
bash: Classify cat-file and reflog as plumbing.

Now that git-show is capable of displaying any file content from any
revision and is the approved Porcelain-ish level method of doing so,
cat-file should no longer be classified as a user-level utility by
the bash completion package.

I'm also classifying the new git-reflog command as plumbing for the
time being as there are no subcommands which are really useful to
the end-user.  git-gc already invokes `git reflog expire --all`,
which makes it rather unnecessary for the user to invoke it directly.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agobash: Remove short option completions for branch/checkout/diff.
Shawn O. Pearce [Sun, 4 Feb 2007 07:38:17 +0000 (02:38 -0500)]
bash: Remove short option completions for branch/checkout/diff.

The short options (-l, -f, -d) for git-branch are rather silly to
include in the completion generation as these options must be fully
typed out by the user and most users already know what the options
are anyway, so including them in the suggested completions does
not offer huge value.  (The same goes for git-checkout and git-diff.)

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoshow-branch -g: default to the current branch.
Junio C Hamano [Sun, 4 Feb 2007 07:31:47 +0000 (23:31 -0800)]
show-branch -g: default to the current branch.

Now we have a separate reflog on HEAD, show-branch -g without an explicit
parameter defaults to the current branch, or HEAD when it is detached
from branches.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoLet git-checkout always drop any detached head
Nicolas Pitre [Sun, 4 Feb 2007 02:50:39 +0000 (21:50 -0500)]
Let git-checkout always drop any detached head

We used to refuse leaving a detached HEAD when it wasn't matching an
existing ref so not to lose any commit that might have been performed
while not on any branch (unless -f was provided).

But this protection was completely bogus since it was still possible
to move to HEAD^ while still remaining detached but losing the last
commit anyway if there was one.

Now that we have a proper reflog for HEAD it is best to simply remove
that bogus (and admitedly annoying) protection and simply display the
last HEAD position instead.  If one wants to recover a lost detached
state then it can be retrieved from the HEAD reflog.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoEnable HEAD@{...} and make it independent from the current branch
Nicolas Pitre [Sun, 4 Feb 2007 02:49:16 +0000 (21:49 -0500)]
Enable HEAD@{...} and make it independent from the current branch

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoMerge branch 'master' into np/dreflog
Junio C Hamano [Sun, 4 Feb 2007 06:14:40 +0000 (22:14 -0800)]
Merge branch 'master' into np/dreflog

This is to resolve conflicts early in preparation for possible
inclusion of "reflog on detached HEAD" series by Nico, as having
it in 1.5.0 would really help us remove confusion between
detached and attached states.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoDefault GIT_MERGE_VERBOSITY to 5 during tests.
Shawn O. Pearce [Sun, 4 Feb 2007 05:45:47 +0000 (00:45 -0500)]
Default GIT_MERGE_VERBOSITY to 5 during tests.

Its really nice to be able to run a test with -v and automatically
see the "debugging" dump from merge-recursive, especially if we
are actually trying to debug merge-recursive.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoKeep untracked files not involved in a merge.
Shawn O. Pearce [Sun, 4 Feb 2007 05:45:54 +0000 (00:45 -0500)]
Keep untracked files not involved in a merge.

My earlier fix (8371234e) to delete renamed tracked files from the
working directory also caused merge-recursive to delete untracked
files that were in the working directory.

The problem here is merge-recursive is deleting the working directory
file without regard for which branch it was associated with.  What we
really want to do during a merge is to only delete files that were
renamed by the branch we are merging into the current branch,
and that are still tracked by the current branch.  These files
definitely don't belong in the working directory anymore.

Anything else is either a merge conflict (already handled in other
parts of the code) or a file that is untracked by the current branch
and thus is not even participating in the merge.  Its this latter
class that must be left alone.

For this fix to work we are now assuming that the first non-base
argument passed to git-merge-recursive always corresponds to the
working directory.  This is already true for all in-tree callers
of merge-recursive.  This assumption is also supported by the
long time usage message of "<base> ... -- <head> <remote>", where
"<head>" is implied to be HEAD, which is generally assumed to be
the current tree-ish.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoAssorted typo fixes
Pavel Roskin [Sun, 4 Feb 2007 04:49:16 +0000 (23:49 -0500)]
Assorted typo fixes

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoCleanup subcommand documentation for git-remote.
Shawn O. Pearce [Sun, 4 Feb 2007 04:02:59 +0000 (23:02 -0500)]
Cleanup subcommand documentation for git-remote.

Jakub Narebski pointed out the positional notation in git-remote's
documentation was very confusing, especially now that we have 3
supported subcommands.  Instead of referring to subcommands by
position, refer to them by name.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agogit-config --rename-section could rename wrong section
Pavel Roskin [Sun, 4 Feb 2007 03:01:04 +0000 (22:01 -0500)]
git-config --rename-section could rename wrong section

The "git-config --rename-section" implementation would match sections
that are substrings of the section name to be renamed.

Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agocombine-diff: special case --unified=0
Junio C Hamano [Sat, 3 Feb 2007 20:37:54 +0000 (12:37 -0800)]
combine-diff: special case --unified=0

Even when --unified=0 is given, the main loop to show the
combined textual diff needs to handle a line that is unchanged
but has lines that were deleted relative to a parent before it
(because that is where the lost lines hang).  However, such a
line should not be emitted in the final output.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoWhy is it bad to rewind a branch that has already been pushed out?
Junio C Hamano [Sat, 3 Feb 2007 06:40:49 +0000 (22:40 -0800)]
Why is it bad to rewind a branch that has already been pushed out?

I was reading the tutorial and noticed that we say this:

    Also, don't use "git reset" on a publicly-visible branch that
    other developers pull from, as git will be confused by history
    that disappears in this way.

I do not think this is a good explanation.  For example, if we
do this:

(1) I build a series and push it out.

---o---o---o---j

(2) Alice clones from me, and builds two commits on top of it.

---o---o---o---j---a---a

(3) I rewind one and build a few, and push them out.

---o---o---o...j
                    \
                     h---h---h---h

(4) Alice pulls from me again:

---o---o---o---j---a---a---*
                    \             /
                     h---h---h---h

Contrary to the description, git will happily have Alice merge
between the two branches, and never gets confused.

Maybe I did not want to have 'j' because it was an incomplete
solution to some problem, and Alice may have fixed it up with
her changes, while I abandoned that approach I started with 'j',
and worked on something completely unrelated in the four 'h'
commits.  In such a case, the merge Alice would make would be
very sensible, and after she makes the merge if I pull from her,
the world will be perfect.  I started something with 'j' and
dropped the ball, Alice picked it up and perfected it while I
went on to work on something else with 'h'.  This would be a
perfect example of distributed parallel collaboration.  There is
nothing confused about it.

The case the rewinding becomes problematic is if the work done
in 'h' tries to solve the same problem as 'j' tried to solve in
a different way.  Then the merge forced on Alice would make her
pick between my previous attempt with her fixups (j+a) and my
second attempt (h).  If 'a' commits were to fix up what 'j'
started, presumably Alice already studied and knows enough about
the problem so she should be able to make an informed decision
to pick between what 'j+a' and 'h' do.

A lot worse case is if Alice's work is not at all related to
what 'j' wanted to do (she did not mean to pick up from where I
left off -- she just wanted to work on something different).
Then she would not be familiar enough with what 'j' and 'h'
tried to achieve, and I'd be forcing her to pick between the
two.  Of course if she can make the right decision, then again
that is a perfect example of distributed collaboration, but that
does not change the fact that I'd be forcing her to clean up my
mess.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agohonor GIT_REFLOG_ACTION in git-commit
Junio C Hamano [Sat, 20 Jan 2007 01:12:11 +0000 (17:12 -0800)]
honor GIT_REFLOG_ACTION in git-commit

This allows git-cherry-pick and git-revert to properly identify
themselves in the resulting reflog entries.  Earlier they were
recorded as what git-commit has done.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agofix reflog entries for "git-branch"
Junio C Hamano [Fri, 19 Jan 2007 19:51:29 +0000 (11:51 -0800)]
fix reflog entries for "git-branch"

Even when -l is not given from the command line, the repository
may have the configuration variable core.logallrefupdates set,
or an old-timer might have done ": >.git/logs/refs/heads/new"
before running "git branch new".  In these cases, the code gave
an uninitialized msg[] from the stack to be written out as the
reflog message.

This also passes a different message when '-f' option is used.
Saying "git branch -f branch some-commit" is a moral equilvalent
of doing "git-reset some-commit" while on the branch.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoscan reflogs independently from refs
Nicolas Pitre [Sat, 3 Feb 2007 18:25:43 +0000 (13:25 -0500)]
scan reflogs independently from refs

Currently, the search for all reflogs depends on the existence of
corresponding refs under the .git/refs/ directory.  Let's scan the
.git/logs/ directory directly instead.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agocore-tutorial: http reference link fix
Junio C Hamano [Sat, 3 Feb 2007 07:17:34 +0000 (23:17 -0800)]
core-tutorial: http reference link fix

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoTutorial-2: Adjust git-status output to recent reality.
Junio C Hamano [Sat, 3 Feb 2007 06:55:07 +0000 (22:55 -0800)]
Tutorial-2: Adjust git-status output to recent reality.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoTutorial: fix asciidoc formatting of "git add" section.
Junio C Hamano [Sat, 3 Feb 2007 06:19:17 +0000 (22:19 -0800)]
Tutorial: fix asciidoc formatting of "git add" section.

Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoDon't leak file descriptors from unavailable pack files.
Shawn O. Pearce [Fri, 2 Feb 2007 08:00:03 +0000 (03:00 -0500)]
Don't leak file descriptors from unavailable pack files.

If open_packed_git failed it may have been because the packfile
actually exists and is readable, but some sort of verification
did not pass.  In this case open_packed_git left pack_fd filled
in, as the file descriptor is valid.  We don't want to leak the
file descriptor, nor do we want to allow someone in the future
to use this packed_git.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agodoc: hooks.txt said post-commit default sends an email, it doesn't
Andy Parkins [Fri, 2 Feb 2007 23:56:08 +0000 (23:56 +0000)]
doc: hooks.txt said post-commit default sends an email, it doesn't

The default post-commit hook is actually empty; it is the update hook
that sends an email.  This patch corrects hooks.txt to reflect that.

Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoDisallow invalid --pretty= abbreviations
Eric Wong [Fri, 2 Feb 2007 13:10:25 +0000 (05:10 -0800)]
Disallow invalid --pretty= abbreviations

--pretty=o is a valid abbreviation, --pretty=omfg is not

Noticed by: Nicolas Vilz
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoFix some documentation typos and grammar
Mike Coleman [Fri, 2 Feb 2007 06:25:30 +0000 (00:25 -0600)]
Fix some documentation typos and grammar

Also suggest user manual mention .gitignore.

Signed-off-by: Michael Coleman <tutufan@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoDon't find objects in packs which aren't available anymore.
Shawn O. Pearce [Thu, 1 Feb 2007 20:52:38 +0000 (15:52 -0500)]
Don't find objects in packs which aren't available anymore.

Matthias Lederhofer identified a race condition where a Git reader
process was able to locate an object in a packed_git index, but
was then preempted while a `git repack -a -d` ran and completed.
By the time the reader was able to seek in the packfile to get the
object data, the packfile no longer existed on disk.

In this particular case the reader process did not attempt to
open the packfile before it was deleted, so it did not already
have the pack_fd field popuplated.  With the packfile itself gone,
there was no way for the reader to open it and fetch the data.

I'm fixing the race condition by teaching find_pack_entry to ignore
a packed_git whose packfile is not currently open and which cannot
be opened.  If none of the currently known packs can supply the
object, we will return 0 and the caller will decide the object is
not available.  If this is the first attempt at finding an object,
the caller will reprepare_packed_git and try again.  If it was
the second attempt, the caller will typically return NULL back,
and an error message about a missing object will be reported.

This patch does not address the situation of a reader which is
being starved out by a tight sequence of `git repack -a -d` runs.
In this particular case the reader will try twice, probably fail
both times, and declare the object in question cannot be found.
As it is highly unlikely that a real world `git repack -a -d` can
complete faster than a reader can open a packfile, so I don't think
this is a huge concern.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoRefactor open_packed_git to return an error code.
Shawn O. Pearce [Thu, 1 Feb 2007 20:52:33 +0000 (15:52 -0500)]
Refactor open_packed_git to return an error code.

Because I want to reuse open_packed_git in a context where I don't
want the process to die if the packfile in question is bogus, I'm
changing its behavior to return error("...") rather than die("...")
when it detects something is wrong with the packfile it was given.

Right now we still must die out of use_pack should open_packed_git
fail, as none of use_pack's callers are prepared to handle a failure
from that function.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoCorrect comment in prepare_packed_git_one.
Shawn O. Pearce [Thu, 1 Feb 2007 20:52:27 +0000 (15:52 -0500)]
Correct comment in prepare_packed_git_one.

After staring at the comment and the associated for loop, I
realized the comment was completely bogus.  The section of
code its talking about is trying to avoid duplicate mapping
of the same packfile.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoCleanup prepare_packed_git_one to reuse install_packed_git.
Shawn O. Pearce [Thu, 1 Feb 2007 20:52:22 +0000 (15:52 -0500)]
Cleanup prepare_packed_git_one to reuse install_packed_git.

There is little point in having the linked list insertion code
appearing in install_packed_git, and then again just 30 lines
further down in the same file.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoTeach 'git remote' how to cleanup stale tracking branches.
Shawn O. Pearce [Fri, 2 Feb 2007 05:06:08 +0000 (00:06 -0500)]
Teach 'git remote' how to cleanup stale tracking branches.

Since it can be annoying to manually cleanup 40 tracking branches
which were removed by the remote system, 'git remote prune <n>'
can now be used to delete any tracking branches under <n> which
are no longer available on the remote system.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoPull out remote listing functions in git-remote.
Shawn O. Pearce [Fri, 2 Feb 2007 05:05:55 +0000 (00:05 -0500)]
Pull out remote listing functions in git-remote.

I want to reuse the stale branch detection to implement a new
'git remote prune' subcommand.  Easiest way to do that is to use
the same logic that 'git remote show' uses to determine the stale
tracking branches, then delete those.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agogit-svn: do not let Git.pm warn if we prematurely close pipes
Eric Wong [Thu, 1 Feb 2007 21:12:26 +0000 (13:12 -0800)]
git-svn: do not let Git.pm warn if we prematurely close pipes

This mainly quiets down warnings when running git svn log.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
14 years agoUpdate the documentation for the new '@{...}' syntax
Johannes Schindelin [Thu, 1 Feb 2007 23:21:49 +0000 (00:21 +0100)]
Update the documentation for the new '@{...}' syntax

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>