1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-10-30 13:57:54 +01:00
Commit graph

1575 commits

Author SHA1 Message Date
Junio C Hamano
248542ea9a Don't forget to build the howto-index file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-25 00:36:41 -07:00
Junio C Hamano
e6fc2346c1 Link howto documents from the main git.txt documentation.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-25 00:28:18 -07:00
Junio C Hamano
628894b26d Sort branch names snarfed from refs/ hierarchy.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 23:26:20 -07:00
Junio C Hamano
8572aa85a7 Fix fetching of tags.
"git fetch tag <tag>" stored a tag after dereferencing.  Bad.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 22:46:07 -07:00
Junio C Hamano
3857284f7b Merge refs/heads/master from . 2005-08-24 18:54:24 -07:00
Linus Torvalds
569061432e [PATCH] Fix silly pathspec bug in git-ls-files
The "verify_pathspec()" function doesn't test for ending NUL character in
the pathspec, causing some really funky and unexpected behaviour. It just
happened to work in the cases I had tested.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 18:53:29 -07:00
tony.luck@intel.com
ab22707f0a [PATCH] Fix git-checkout-script exit status
Sometimes the git-read-tree in git-checkout-script fails for me.
Make sure that the failed status is passed up to caller.

Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 18:53:15 -07:00
Junio C Hamano
96fdc218f7 Merge refs/heads/master from . 2005-08-24 17:50:26 -07:00
Junio C Hamano
9e3e2a5596 Fix markup minimally to get man pages built.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 17:50:05 -07:00
Junio C Hamano
434d6ba031 Merge refs/heads/master from . 2005-08-24 16:56:48 -07:00
Junio C Hamano
c95173410d Update tutorial to describe shared repository style a bit more.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 16:50:55 -07:00
Junio C Hamano
ab9b31386b Documentation: multi-head fetch.
Add documentation related to multi-head work, including $GIT_DIR/remotes/
changes.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 16:50:54 -07:00
Junio C Hamano
ff27adf3da Support +<src>:<dst> format in push as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 16:50:53 -07:00
Junio C Hamano
efe9bf0f3b [PATCH] Allow "+remote:local" refspec to cause --force when fetching.
With this we could say:

    Pull: master:ko-master +pu:ko-pu

to mean "fast forward ko-master with master, overwrite ko-pu with pu",
and the latter one does not require the remote "pu" to be descendant
of local "ko-pu".

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 16:50:53 -07:00
Junio C Hamano
521003ff52 [PATCH] Use git-octopus when pulling more than one heads.
With this, you can finally say "git pull jgarzik sil24 pdc2027x".

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 16:50:52 -07:00
Junio C Hamano
ae2da40690 [PATCH] "git fetch --force".
Just like "git push" can forcibly update a ref to a value that is not
a fast-forward, teach "git fetch" to do so as well.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 16:50:52 -07:00
Junio C Hamano
6687f8fea2 [PATCH] Use .git/remote/origin, not .git/branches/origin.
Now multi-head fetch is complete, let's migrate the
default configuration for new repositories created with
the "git clone" command.

The original $GIT_DIR/branches is not deprecated yet, but create
remotes directory by default from the templates as well.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 16:50:52 -07:00
Junio C Hamano
92c533ef0e [PATCH] Make "git pull" and "git fetch" default to origin
Amos Waterland sent in a patch for the pre-multi-head aware
version of "git pull" to do this, but the code changed quite a
bit since then.  If there is no argument given to pull from, and
if "origin" makes sense, default to fetch/pull from "origin"
instead of barfing.

[jc: besides, the patch by Amos broke the non-default case where
explicit refspecs are specified, and did not make sure we know
what "origin" means before defaulting to it.]

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 16:50:51 -07:00
Junio C Hamano
d9f3be7e2e [PATCH] Infamous 'octopus merge'
This script uses the list of heads and their origin multi-head "git
fetch" left in the $GIT_DIR/FETCH_HEAD file, and makes an octopus
merge on top of the current HEAD using them.

The implementation tries to be strict for the sake of safety.  It
insists that your working tree is clean (no local changes) and matches
the HEAD, and when any of the merged heads does not automerge, the
whole process is aborted and tries to rewind your working tree is to
the original state.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 16:50:51 -07:00
Junio C Hamano
e0bfc81e05 [PATCH] Retire git-parse-remote.
Update git-pull to match updated git-fetch and allow pull to
fetch from multiple remote references.  There is no support for
resolving more than two heads, which will be done with "git
octopus".

Update "git ls-remote" to use git-parse-remote-script.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 16:50:50 -07:00
Junio C Hamano
853a3697dc [PATCH] Multi-head fetch.
Traditionally, fetch takes these forms:

    $ git fetch <remote>
    $ git fetch <remote> <head>
    $ git fetch <remote> tag <tag>

This patch updates it to take

    $ git fetch <remote> <refspec>...

where:

    - A <refspec> of form "<src>:<dst>" is to fetch the objects
      needed for the remote ref that matches <src>, and if <dst>
      is not empty, store it as a local <dst>.

    - "tag" followed by <next> is just an old way of saying
      "refs/tags/<next>:refs/tags/<next>"; this mimics the
      current behaviour of the third form above and means "fetch
      that tag and store it under the same name".

    - A single token <refspec> without colon is a shorthand for
      "<refspec>:"  That is, "fetch that ref but do not store
      anywhere".

    - when there is no <refspec> specified

      - if <remote> is the name of a file under $GIT_DIR/remotes/
	(i.e. a new-style shorthand), then it is the same as giving
	the <refspec>s listed on Pull: line in that file.

      - if <remote> is the name of a file under $GIT_DIR/branches/
	(i.e. an old-style shorthand, without trailing path), then it
	is the same as giving a single <refspec>
	"<remote-name>:refs/heads/<remote>" on the command line, where
	<remote-name> is the remote branch name (defaults to HEAD, but
	can be overridden by .git/branches/<remote> file having the
	URL fragment notation).  That is, "fetch that branch head and
	store it in refs/heads/<remote>".

      - otherwise, it is the same as giving a single <refspec>
        that is "HEAD:".

The SHA1 object names of fetched refs are stored in FETCH_HEAD,
one name per line, with a comment to describe where it came from.
This is later used by "git resolve" and "git octopus".

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 16:50:50 -07:00
Junio C Hamano
ac4b0cff00 [PATCH] Start adding the $GIT_DIR/remotes/ support.
All the necessary parsing code is in git-parse-remote-script;
update git-push-script to use it.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 16:50:49 -07:00
Pavel Roskin
d998a0895f [PATCH] Fix "prefix" mixup in git-rev-list
Recent changes in git have broken cg-log.  git-rev-list no longer
prints "commit" in front of commit hashes.  It turn out a local
"prefix" variable in main() shadows a file-scoped "prefix" variable.

The patch removed the local "prefix" variable since its value is never
used (in the intended way, that is).  The call to
setup_git_directory() is kept since it has useful side effects.

The file-scoped "prefix" variable is renamed to "commit_prefix" just
in case someone reintroduces "prefix" to hold the return value of
setup_git_directory().

Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 16:50:16 -07:00
Junio C Hamano
ff84d327df Audit rev-parse users again.
Some callers to rev-parse were using the output selection flags
inconsistently.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 14:31:36 -07:00
Junio C Hamano
4866ccf0f4 Rationalize output selection in rev-parse.
Earlier rounds broke 'whatchanged -p'.  In attempting to fix this,
make two axis of output selection in rev-parse orthogonal:

  --revs-only	tells it not to output things that are not revisions nor
		flags that rev-list would take.
  --no-revs	tells it not to output things that are revisions or
		flags that rev-list would take.
  --flags	tells it not to output parameters that do not start with
		a '-'.
  --no-flags	tells it not to output parameters that starts with a '-'.

So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386',
while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'.

Also the meaning of --verify has been made stronger.  It now rejects
anything but a single valid rev argument.  Earlier it passed some flags
through without complaining.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 14:30:04 -07:00
Junio C Hamano
ccf1ee327f Generate pack info file after repack.
Pulling from a packed repository over dumb transport without the
server info file fails, so run update-server-info automatically
after a repack by default.  This can be disabled with the '-n'
flag.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24 10:40:58 -07:00
Junio C Hamano
168cc639ad Merge refs/heads/master from . 2005-08-23 21:30:42 -07:00
Junio C Hamano
0d6a873cfe Link the tutorial from the main document.
And lead the reader to it at the beginning of the manual.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-23 21:18:49 -07:00
Junio C Hamano
9585e40622 Try to find the optimum merge base while resolving.
The merge-base command acquires a new option, '--all', that causes it
to output all the common ancestor candidates.  The "git resolve"
command then uses it to pick the optimum merge base by picking the one
that results in the smallest number of nontrivial merges.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-23 21:08:59 -07:00
Junio C Hamano
58eaf287f1 Merge refs/heads/master from . 2005-08-23 15:32:17 -07:00
Junio C Hamano
2a29da7c6d Tutorial updates.
- Use "working tree", "object name", "repository" as the canonical
   term consistenly.

 - Start formatting tutorial with asciidoc.

 - Mention shared repository style of cooperation.

 - Update with some usability enhancements recently made, such as
   the "-m" flag to the "git commit" command.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-23 15:28:34 -07:00
Junio C Hamano
0a5a9ea433 Update git-diff-script.
This uses the fixed rev-parse to allow passing diff options to the
underlying diff command.  For example:

    $ git diff -r HEAD

shows the output in raw-diff format, and

    $ git diff -p -R HEAD | git apply

generates a patch to go back from your working tree to HEAD commit
(i.e. an expensive way to say "git checkout -f HEAD").

At the same time, it accidentally removes the use of shell arrays.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-23 13:18:00 -07:00
Linus Torvalds
90e1848113 Make "git-rev-list" work within subdirectories
This trivial patch makes "git-rev-list" able to handle not being in
the top-level directory.  This magically also makes "git-whatchanged"
do the right thing.

Trivial scripting fix to make sure that "git log" also works.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-23 12:43:57 -07:00
Linus Torvalds
0360e99d06 [PATCH] Fix git-rev-parse --default and --flags handling
This makes the argument to --default and any --flags arguments should up 
correctly, and makes "--" together with --flags act sanely.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-23 12:42:58 -07:00
Junio C Hamano
7fc9d69fca Add placeholders for missing documents.
The text does not say anything interesting, but at least the
author list should reflect something close to reality.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-23 01:49:47 -07:00
Junio C Hamano
89305da8a2 Merge refs/heads/master from . 2005-08-23 00:07:17 -07:00
Junio C Hamano
45d197a469 Introduce "reset type" flag to "git reset"
I have been feeling that the current behaviour of "git reset" is
not quite optimal, but so far could not express exactly what I
felt was wrong with it.  This patch clarifies it.

There are at least two situations you may want to "reset" your
working tree.

1. You made a mess in your working tree.  You want to switch
   back to a known good state and start over.  This mess may be
   a result of your own editing, a merge that had too many
   conflicting changes that you do not feel like to resolve by
   hand at this moment, or a botched application of a patch you
   received from somewhere.

   In this case, you would want to have "git reset HEAD" reset
   the index file to the tree read from the HEAD commit and the
   files in the working tree to match index (i.e. "git status"
   should say "Nothing to commit", without any "unrecorded
   changes").

   The current behaviour leaves the files in the working tree
   intact, which requires you to run "git checkout -f".  Also
   you need to remember "rm -f" any files that the botched patch
   may have left in the working tree if the purpose of this
   "reset" is to attempt to apply it again; most likely the
   patch would fail if such a file is left behind.

2. You have discovered that commits you made earlier need to be
   reorganized.  The simplest example is to undo the last
   commit, re-edit some files, and redo the commit.  Another
   simple eample is to undo the last two commits, and commit the
   changes in those two commits as a single commit.

   In this case, you would want to have "git reset HEAD^" reset
   the $GIT_DIR/HEAD to the commit object name of the parent
   commit of the current commit (i.e. rewinding one commit),
   leave the index file and the files in the working tree in a
   state where you can easily make a commit that records a tree
   that resembles what you have in the current index file and
   the working tree.

   The current behaviour is almost OK for this purpose, except
   that you need to find which files you need to manually run
   "git add" yourself.  They are files that are in the original
   HEAD commit and not in the commit you are resetting to.

The default without the type flag is to do "--mixed", which is
the current behaviour.

    $ git reset [ --hard | --soft | --mixed ] [ <commit-ish> ]

A hard reset would be used for 1 and works in this way:

    (1) remember the set of paths that appear in the current
        index file (which may even have unmerged entries) and
	the current $GIT_DIR/HEAD commit.

    (2) "read-tree --reset" the specified <commit-ish> (default
        to HEAD), followed by "checkout-cache -f -u -a".

    (3) remove any files that appear in (1) but not in
        <commit-ish> from the working tree.

    (4) backup $GIT_DIR/HEAD to $GIT_DIR/ORIG_HEAD and update
        $GIT_DIR/HEAD with the specified <commit-ish>.

    (5) remove leftover $GIT_DIR/MERGE_HEAD

A soft reset would be used for 2 and works in this way:

    (1) Make sure that the index file is merged and we do not
        have MERGE_HEAD; otherwise it does not make sense to do
        soft reset.

    (2) backup $GIT_DIR/HEAD to $GIT_DIR/ORIG_HEAD and update
        $GIT_DIR/HEAD with the specified <commit-ish>.

Note that with the current behaviour, "git diff" is the way to
see what could be committed immediately after "git reset".  With
the "soft reset" described here you would need to say "git diff
HEAD" to find that out.

I am not sure what mixed reset (the current behaviour) is good
for.  If nobody comes up with a good use case it may not be a
bad idea to remove it.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 23:19:18 -07:00
Junio C Hamano
f5e375c9a9 Clean-up output from "git show-branch" and document it.
When showing only one branch a lot of default output becomes redundant,
so clean it up a bit, and document what is shown.  Retire the earlier
implementation "git-show-branches-script".

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 23:18:17 -07:00
Junio C Hamano
f76412ed6d [PATCH] Add 'git show-branch'.
The 'git show-branches' command turns out to be reasonably useful,
but painfully slow.  So rewrite it in C, using ideas from merge-base
while enhancing it a bit more.

 - Unlike show-branches, it can take --heads (show me all my
   heads), --tags (show me all my tags), or --all (both).

 - It can take --more=<number> to show beyond the merge-base.

 - It shows the short name for each commit in the extended SHA1
   syntax.

 - It can find merge-base for more than two heads.

Examples:

    $ git show-branch --more=6 HEAD

    is almost the same as "git log --pretty=oneline --max-count=6".

    $ git show-branch --merge-base master mhf misc

    finds the merge base of the three given heads.

    $ git show-branch master mhf misc

    shows logs from the top of these three branch heads, up to their
    common ancestor commit is shown.

    $ git show-branch --all --more=10

    is poor-man's gitk, showing all the tags and heads, and
    going back 10 commits beyond the merge base of those refs.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 18:34:10 -07:00
Junio C Hamano
4f7599ac25 [PATCH] Add a new extended SHA1 syntax <name>~<num>
The new notation is a short-hand for <name> followed by <num>
caret ('^') characters.  E.g. "master~4" is the fourth
generation ancestor of the current "master" branch head,
following the first parents; same as "master^^^^" but a bit
more readable.

This will be used in the updated "git show-branch" command.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 18:34:09 -07:00
Junio C Hamano
792fe559d0 Fix "git-diff-script A B"
When "git-diff-script A..B" notation was introduced, it ended up breaking
the traditional two revisions notation.

[jc: there are other issues with the current "git diff" I would like to
 address, but they would be left to later rounds.  For example, -M and -p flags
 should not be hardcoded default, and it shouldn't be too hard to rewrite
 the script without using shell arrays.]

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 18:32:38 -07:00
Linus Torvalds
56fc5108a2 [PATCH] git-ls-files: generalized pathspecs
This generalizes the git "glob" string to be a lot more like the
git-diff-* pathspecs (but there are still differences: the diff family
doesn't do any globbing, and because the diff family always generates the
full native pathname, it doesn't have the issue with "..").

It does three things:

 - it allows multiple matching strings, ie you can do things like

	git-ls-files arch/i386/ include/asm-i386/ | xargs grep pattern

 - the "matching" criteria is a combination of "exact path component
   match" (the same as the git-diff-* family), and "fnmatch()". However,
   you should be careful with the confusion between the git-ls-files
   internal globbing and the standard shell globbing, ie

	git-ls-files fs/*.c

   does globbing in the shell, and does something totally different from

	git-ls-files 'fs/*.c'

   which does the globbing inside git-ls-files.

   The latter has _one_ pathspec with a wildcard, and will match any .c
   file anywhere under the fs/ directory, while the former has been
   expanded by the shell into having _lots_ of pathspec entries, all of
   which are just in the top-level fs/ subdirectory. They will happily
   be matched exactly, but we will thus miss all the subdirectories under
   fs/.

   As a result, the first one will (on the current kernel) match 55 files,
   while the second one will match 664 files!

 - it uses the generic path prefixing, so that ".." and friends at the
   beginning of the path spec work automatically

   NOTE! When generating relative pathname output (the default), a
   pathspec that causes the base to be outside the current working
   directory will be rejected with an error message like:

	fatal: git-ls-files: cannot generate relative filenames containing '..'

   because we do not actually generate ".." in the output. However, the
   ".." format works fine for the --full-name case:

	cd arch/i386/kernel
	git-ls-files --full-name ../mm/

   results in

	arch/i386/mm/Makefile
	arch/i386/mm/boot_ioremap.c
	arch/i386/mm/discontig.c
	arch/i386/mm/extable.c
	arch/i386/mm/fault.c
	arch/i386/mm/highmem.c
	arch/i386/mm/hugetlbpage.c
	arch/i386/mm/init.c
	arch/i386/mm/ioremap.c
	arch/i386/mm/mmap.c
	arch/i386/mm/pageattr.c
	arch/i386/mm/pgtable.c

   Perhaps more commonly, the generic path prefixing means that "." and
   "./" automatically get simplified and work properly.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-22 12:58:03 -07:00
Junio C Hamano
15ac516442 Merge refs/heads/master from . 2005-08-21 13:59:38 -07:00
Linus Torvalds
5be4efbefa [PATCH] Make "git-ls-files" work in subdirectories
This makes git-ls-files work inside a relative directory, and also adds
some rudimentary filename globbing support. For example, in the kernel you
can now do

	cd arch/i386
	git-ls-files

and it will show all files under that subdirectory (and it will have
removed the "arch/i386/" prefix unless you give it the "--full-name"
option, so that you can feed the result to "xargs grep" or similar).

The filename globbing is kind of strange: it does _not_ follow normal
globbing rules, although it does look "almost" like a normal file glob
(and it uses the POSIX.2 "fnmatch()" function).

The glob pattern (there can be only one) is always split into a "directory
part" and a "glob part", where the directory part is defined as any full
directory path without any '*' or '?' characters. The "glob" part is
whatever is left over.

For example, when doing

	git-ls-files 'arch/i386/p*/*.c'

the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c".
The directory part will be added to the prefix, and handled efficiently
(ie we will not be searching outside of that subdirectory), while the glob
part (if anything is left over) will be used to trigger "fnmatch()"
matches.

This is efficient and very useful, but can result in somewhat
non-intuitive behaviour.

For example:

	git-ls-files 'arch/i386/*.[ch]'

will find all .c and .h files under arch/i386/, _including_ things in
lower subdirectories (ie it will match "arch/i386/kernel/process.c",
because "kernel/process.c" will match the "*.c" specifier).

Also, while

	git-ls-files arch/i386/

will show all files under that subdirectory, doing the same without the
final slash would try to show the file "i386" under the "arch/"
subdirectory, and since there is no such file (even if there is such a
_directory_) it will not match anything at all.

These semantics may not seem intuitive, but they are actually very
practical. In particular, it makes it very simple to do

	git-ls-files fs/*.c | xargs grep some_pattern

and it does what you want.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-21 13:41:28 -07:00
Junio C Hamano
e65be0b7aa Merge refs/heads/master from . 2005-08-21 04:38:33 -07:00
Junio C Hamano
1dfcfbce2d [PATCH] sha1_name: do not accept .git/refs/snap/.
I think Linus did a cut & paste from an early JIT code while
developing the current extended SHA1 notation, and left it there as a
courtesy, but the directory does not deserve to be treated any more
specially than, say, .git/refs/bisect.

If the subdirectories under .git/refs proliferate, we may want to
switch to scanning that hierarchy at runtime, instead of the current
hard-coded set, although I think that would be overkill.

Signed-off-by: Junio C Hamano <junkio@cox.net>
From nobody Mon Sep 17 00:00:00 2001
Subject: [PATCH] Add a new extended SHA1 syntax <name>:<num>
From: Junio C Hamano <junkio@cox.net>
Date: 1124617434 -0700

The new notation is a short-hand for <name> followed by <num>
caret ('^') characters.  E.g. "master:4" is the fourth
generation ancestor of the current "master" branch head,
following the first parents; same as "master^^^^" but a bit more
readable.

This will be used in the updated "git show-branch" command.

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

 sha1_name.c |   41 +++++++++++++++++++++++++++++++++++++++++
 1 files changed, 41 insertions(+), 0 deletions(-)

d5098ce769da46df6d45dc8f41b06dd758fdaea7
diff --git a/sha1_name.c b/sha1_name.c
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -191,9 +191,29 @@ static int get_parent(const char *name, 
 	return -1;
 }
 
+static int get_nth_ancestor(const char *name, int len,
+			    unsigned char *result, int generation)
+{
+	unsigned char sha1[20];
+	int ret = get_sha1_1(name, len, sha1);
+	if (ret)
+		return ret;
+
+	while (generation--) {
+		struct commit *commit = lookup_commit_reference(sha1);
+
+		if (!commit || parse_commit(commit) || !commit->parents)
+			return -1;
+		memcpy(sha1, commit->parents->item->object.sha1, 20);
+	}
+	memcpy(result, sha1, 20);
+	return 0;
+}
+
 static int get_sha1_1(const char *name, int len, unsigned char *sha1)
 {
 	int parent, ret;
+	const char *cp;
 
 	/* foo^[0-9] or foo^ (== foo^1); we do not do more than 9 parents. */
 	if (len > 2 && name[len-2] == '^' &&
@@ -210,6 +230,27 @@ static int get_sha1_1(const char *name, 
 	if (parent >= 0)
 		return get_parent(name, len, sha1, parent);
 
+	/* name:3 is name^^^,
+	 * name:12 is name^^^^^^^^^^^^, and
+	 * name: is name
+	 */
+	parent = 0;
+	for (cp = name + len - 1; name <= cp; cp--) {
+		int ch = *cp;
+		if ('0' <= ch && ch <= '9')
+			continue;
+		if (ch != ':')
+			parent = -1;
+		break;
+	}
+	if (!parent && *cp == ':') {
+		int len1 = cp - name;
+		cp++;
+		while (cp < name + len)
+			parent = parent * 10 + *cp++ - '0';
+		return get_nth_ancestor(name, len1, sha1, parent);
+	}
+
 	ret = get_sha1_basic(name, len, sha1);
 	if (!ret)
 		return 0;
2005-08-21 03:52:55 -07:00
Yasushi SHOJI
90a734dc7f [PATCH] possible memory leak in diff.c::diff_free_filepair()
Here is a patch to fix the problem in the simplest way.
2005-08-21 03:48:33 -07:00
Junio C Hamano
d57306c794 Create objects/info/ directory in init-db.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-20 10:59:28 -07:00
Marco Costalba
b909a15ede [PATCH] Fix git-commit-script to output on stderr when -v fails
When git-commit-script is called with -v option and
verify test fails result is print on stdout
instead of stderr.

[jc: The original patch from Marco updated git-commit-script that
still had the piece of code in question, which has been moved to
an example hook script on its own, so I transplanted the patch to
that new file instead.]

Signed-off-by: Marco Costalba <mcostalba@yahoo.it>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-20 10:54:27 -07:00
Junio C Hamano
b0e985d5de Merge with master to pick up commit hook works. 2005-08-20 01:47:08 -07:00