Граф коммитов

55 Коммитов

Автор SHA1 Сообщение Дата
Junio C Hamano 58a1e0e83b Merge branch 'lj/refs'
* lj/refs: (63 commits)
  Fix show-ref usagestring
  t3200: git-branch testsuite update
  sha1_name.c: avoid compilation warnings.
  Make git-branch a builtin
  ref-log: fix D/F conflict coming from deleted refs.
  git-revert with conflicts to behave as git-merge with conflicts
  core.logallrefupdates thinko-fix
  git-pack-refs --all
  core.logallrefupdates create new log file only for branch heads.
  Remove bashism from t3210-pack-refs.sh
  ref-log: allow ref@{count} syntax.
  pack-refs: call fflush before fsync.
  pack-refs: use lockfile as everybody else does.
  git-fetch: do not look into $GIT_DIR/refs to see if a tag exists.
  lock_ref_sha1_basic does not remove empty directories on BSD
  Do not create tag leading directories since git update-ref does it.
  Check that a tag exists using show-ref instead of looking for the ref file.
  Use git-update-ref to delete a tag instead of rm()ing the ref file.
  Fix refs.c;:repack_without_ref() clean-up path
  Clean up "git-branch.sh" and add remove recursive dir test cases.
  ...
2006-11-01 08:48:50 -08:00
Junio C Hamano 694500edbd sha1_name.c: avoid compilation warnings.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-23 21:15:34 -07:00
pclouds@gmail.com 8a83157e04 Reject hexstring longer than 40-bytes in get_short_sha1()
Such a string can never be a valid object name.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-18 21:21:50 -07:00
Junio C Hamano ab2a1a32ff ref-log: allow ref@{count} syntax.
Often I find myself wanting to say 'tip of "next" before I
merged the last three topics'.  Now I can say that with:

	git log next@{3}..next

Since small integers alone are invalid input strings to
approxidate, there is no fear of confusion.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-05 23:17:11 -07:00
Junio C Hamano 2958d9b5db Merge branch 'master' into lj/refs
* master: (72 commits)
  runstatus: do not recurse into subdirectories if not needed
  grep: fix --fixed-strings combined with expression.
  grep: free expressions and patterns when done.
  Corrected copy-and-paste thinko in ignore executable bit test case.
  An illustration of rev-list --parents --pretty=raw
  Allow git-checkout when on a non-existant branch.
  gitweb: Decode long title for link tooltips
  git-svn: Fix fetch --no-ignore-externals with GIT_SVN_NO_LIB=1
  Ignore executable bit when adding files if filemode=0.
  Remove empty ref directories that prevent creating a ref.
  Use const for interpolate arguments
  git-archive: update documentation
  Deprecate merge-recursive.py
  gitweb: fix over-eager application of esc_html().
  Allow '(no author)' in git-svn's authors file.
  Allow 'svn fetch' on '(no date)' revisions in Subversion.
  git-repack: allow git-repack to run in subdirectory
  Remove upload-tar and make git-tar-tree a thin wrapper to git-archive
  git-tar-tree: Move code for git-archive --format=tar to archive-tar.c
  git-tar-tree: Remove duplicate git_config() call
  ...
2006-09-27 22:23:12 -07:00
Junio C Hamano 8da1977554 Tell between packed, unpacked and symbolic refs.
This adds a "int *flag" parameter to resolve_ref() and makes
for_each_ref() family to call callback function with an extra
"int flag" parameter.  They are used to give two bits of
information (REF_ISSYMREF and REF_ISPACKED) about the ref.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-20 22:02:01 -07:00
Junio C Hamano 7dd45e15c2 sha1_name.c: understand "describe" output as a valid object name
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-20 16:11:08 -07:00
Linus Torvalds ed378ec7e8 Make ref resolution saner
The old code used to totally mix up the notion of a ref-name and the path
that that ref was associated with.  That was not only horribly ugly (a
number of users got the path, and then wanted to try to turn it back into
a ref-name again), but it fundamnetally doesn't work at all once we do any
setup where a ref doesn't have a 1:1 relationship with a particular
pathname.

This fixes things up so that we use the ref-name throughout, and only
turn it into a pathname once we actually look it up in the filesystem.
That makes a lot of things much clearer and more straightforward.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-17 19:09:11 -07:00
Shawn Pearce 9befac470b Replace uses of strdup with xstrdup.
Like xmalloc and xrealloc xstrdup dies with a useful message if
the native strdup() implementation returns NULL rather than a
valid pointer.

I just tried to use xstrdup in new code and found it to be missing.
However I expected it to be present as xmalloc and xrealloc are
already commonly used throughout the code.

[jc: removed the part that deals with last_XXX, which I am
 finding more and more dubious these days.]

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-02 03:24:37 -07:00
Junio C Hamano a8e0d16d85 Convert memset(hash,0,20) to hashclr(hash).
In the same spirit as hashcmp() and hashcpy().

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-23 13:57:23 -07:00
Shawn Pearce e702496e43 Convert memcpy(a,b,20) to hashcpy(a,b).
This abstracts away the size of the hash values when copying them
from memory location to memory location, much as the introduction
of hashcmp abstracted away hash value comparsion.

A few call sites were using char* rather than unsigned char* so
I added the cast rather than open hashcpy to be void*.  This is a
reasonable tradeoff as most call sites already use unsigned char*
and the existing hashcmp is also declared to be unsigned char*.

[jc: Splitted the patch to "master" part, to be followed by a
 patch for merge-recursive.c which is not in "master" yet.

 Fixed the cast in the latter hunk to combine-diff.c which was
 wrong in the original.

 Also converted ones left-over in combine-diff.c, diff-lib.c and
 upload-pack.c ]

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-23 13:53:10 -07:00
David Rientjes a89fccd281 Do not use memcmp(sha1_1, sha1_2, 20) with hardcoded length.
Introduces global inline:

	hashcmp(const unsigned char *sha1, const unsigned char *sha2)

Uses memcmp for comparison and returns the result based on the length of
the hash name (a future runtime decision).

Acked-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-17 14:23:53 -07:00
David Rientjes 0bef57ee44 make inline is_null_sha1 global
Replace sha1 comparisons to null_sha1 with a global inline (which previously an
unused static inline in builtin-apply.c)

[jc: with a fix from Jonas Fonseca.]

Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-15 15:06:03 -07:00
Junio C Hamano 02c5cba200 find_unique_abbrev() with len=0 should not abbreviate
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-09 13:17:04 -07:00
Linus Torvalds 1974632c66 Remove TYPE_* constant macros and use object_type enums consistently.
This updates the type-enumeration constants introduced to reduce
the memory footprint of "struct object" to match the type bits
already used in the packfile format, by removing the former
(i.e. TYPE_* constant macros) and using the latter (i.e. enum
object_type) throughout the code for consistency.

Eventually we can stop passing around the "type strings"
entirely, and this will help - no confusion about two different
integer enumeration.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-12 23:18:03 -07:00
Peter Eriksen 817151e61a Rename safe_strncpy() to strlcpy().
This cleans up the use of safe_strncpy() even more.  Since it has the
same semantics as strlcpy() use this name instead.  Also move the
definition from inside path.c to its own file compat/strlcpy.c, and use
it conditionally at compile time, since some platforms already has
strlcpy().  It's included in the same way as compat/setenv.c.

Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-24 23:16:25 -07:00
Linus Torvalds 885a86abe2 Shrink "struct object" a bit
This shrinks "struct object" by a small amount, by getting rid of the
"struct type *" pointer and replacing it with a 3-bit bitfield instead.

In addition, we merge the bitfields and the "flags" field, which
incidentally should also remove a useless 4-byte padding from the object
when in 64-bit mode.

Now, our "struct object" is still too damn large, but it's now less
obviously bloated, and of the remaining fields, only the "util" (which is
not used by most things) is clearly something that should be eventually
discarded.

This shrinks the "git-rev-list --all" memory use by about 2.5% on the
kernel archive (and, perhaps more importantly, on the larger mozilla
archive). That may not sound like much, but I suspect it's more on a
64-bit platform.

There are other remaining inefficiencies (the parent lists, for example,
probably have horrible malloc overhead), but this was pretty obvious.

Most of the patch is just changing the comparison of the "type" pointer
from one of the constant string pointers to the appropriate new TYPE_xxx
small integer constant.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-17 18:49:18 -07:00
Peter Eriksen bfbd0bb6ec Implement safe_strncpy() as strlcpy() and use it more.
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-16 22:45:12 -07:00
Shawn Pearce cce91a2cae Change 'master@noon' syntax to 'master@{noon}'.
Its ambiguous to parse "master@2006-05-17 18:30:foo" when foo is
meant as a file name and ":30" is meant as 30 minutes past 6 pm.
Therefore all date specifications in a sha1 expression must now
appear within brackets and the ':' splitter used for the path name
in a sha1 expression ignores ':' appearing within brackets.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-19 15:02:55 -07:00
Shawn Pearce 70e34b2dc8 Fix ref log parsing so it works properly.
The log parser was only ever matching the last log record due to
calling strtoul on "> 1136091609" rather than " 1136091609".  Also
once a match for '@' has been found after the name of the ref there
is no point in looking for another '@' within the remaining text.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-17 17:36:36 -07:00
Shawn Pearce d556fae2c0 Support 'master@2 hours ago' syntax
Extended sha1 expressions may now include date specifications
which indicate a point in time within the local repository's
history.  If the ref indicated to the left of '@' has a log in
$GIT_DIR/logs/<ref> then the value of the ref at the time indicated
by the specification is obtained from the ref's log.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-17 17:36:36 -07:00
Junio C Hamano e7cef45fbc get_sha1() - fix infinite loop on nonexistent stage.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-08 15:44:06 -07:00
Junio C Hamano 73b0e5af9d get_sha1(): :path and :[0-3]:path to extract from index.
Earlier patch to say <ent>:<path> by Linus was very useful, and
this extends the same idea to the current index.  An sha1
expression :<path> extracts the object name for the named path
from the current index.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-30 17:55:34 -07:00
Junio C Hamano 4dcff634e6 get_tree_entry(): make it available from tree-walk
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19 14:05:47 -07:00
Junio C Hamano f3ab49db1b sha1_name.c: no need to include diff.h; tree-walk.h will do.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19 11:56:53 -07:00
Junio C Hamano 041a7308de sha1_name.c: prepare to make get_tree_entry() reusable from others.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19 11:56:07 -07:00
Linus Torvalds 5119602a99 get_sha1() shorthands for blob/tree objects
This is a fairly straightforward patch to allow "get_sha1()" to also have
shorthands for tree and blob objects.

The syntax is very simple and intuitive: you can specify a tree or a blob
by simply specifying <revision>:<path>, and get_sha1() will do the SHA1
lookup from the tree for you.

You can currently do it with "git ls-tree <rev> <path>" and parsing the
output, but that's actually pretty awkward.

With this, you can do something like

	git cat-file blob v1.2.4:Makefile

to get the contents of "Makefile" at revision v1.2.4.

Now, this isn't necessarily something you really need all that often, but
the concept itself is actually pretty powerful. We could, for example,
allow things like

	git diff v0.99.6:git-commit-script..v1.3.0:git-commit.sh

to see the difference between two arbitrary files in two arbitrary
revisions. To do that, the only thing we'd have to do is to make
git-diff-tree accept two blobs to diff, in addition to the two trees it
now expects.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-18 21:52:41 -07:00
Junio C Hamano 84a9b58c42 sha1_name: warning ambiguous refs.
This makes sure that many commands that take refs on the command
line to honor core.warnambiguousrefs configuration.  Earlier,
the commands affected by this patch did not read the
configuration file.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-23 23:41:18 -08:00
Junio C Hamano c51d13692d get_sha1_basic(): try refs/... and finally refs/remotes/$foo/HEAD
This implements the suggestion by Jeff King to use
refs/remotes/$foo/HEAD to interpret a shorthand "$foo" to mean
the primary branch head of a tracked remote.  clone needs to be
told about this convention as well.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-21 01:42:04 -08:00
Junio C Hamano 2f8acdb38e core.warnambiguousrefs: warns when "name" is used and both "name" branch and tag exists.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-20 23:34:17 -08:00
Junio C Hamano 297a1aadbe find_unique_abbrev() simplification.
Earlier it did not grok the 0{40} SHA1 very well, but what it
needed to do was to find the shortest 0{N} that is not used as a
valid object name to be consistent with the way names of valid
objects are abbreviated.  This makes some users simpler.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10 01:51:12 -08:00
Junio C Hamano 0601dbe178 get_sha1_1: allow octopus^12 to be properly parsed.
We probably thought anybody who does more than 9 parents in an
Octopus is insane when this was initially done, but there is no
inherent reason to limit the number of independent topic
branches that happen to mature at the same time.

Our commit-tree allows up to 16 already, so at least we should
prepare to handle what we can produce, if only to be consistent.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-02 23:49:44 -08:00
Junio C Hamano 46a6c2620b abbrev cleanup: use symbolic constants
The minimum length of abbreviated object name was hardcoded in
different places to be 4, risking inconsistencies in the future.
Also there were three different "default abbreviation
precision".  Use two C preprocessor symbols to clean up this
mess.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-28 00:09:38 -08:00
Uwe Zeisberger e974c9ab03 Use symbolic name SHORT_NAME_AMBIGUOUS as error return value
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-26 18:13:54 -08:00
Junio C Hamano 47dd0d595d diff: --abbrev option
When I show transcripts to explain how something works, I often
find myself hand-editing the diff-raw output to shorten various
object names in the output.

This adds --abbrev option to the diff family, which shortens
diff-raw output and diff-tree commit id headers.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-19 18:32:44 -08:00
Junio C Hamano c054d64e87 Revert "get_sha1_basic(): corner case ambiguity fix"
This reverts 6677c4665a commit.

The misguided disambiguation has been reverted, so there is no point
testing that misfeature.
2005-12-17 23:10:56 -08:00
Junio C Hamano 011fbc7f07 Remove misguided branch disambiguation.
This removes the misguided attempt to refuse processing a branch
name xyzzy and insist it to be given as either heads/xyzzy or
tags/xyzzy when a tag xyzzy exists.  There was no reason to do
so --- the search order was predictable and well defined, so if
the user says xyzzy we should have taken the tag xyzzy in such a
case without complaining.

This incidentally fixes another subtle bug related to this.  If
such a duplicate branch/tag name happened to be a unique valid
prefix of an existing commit object name (say, "beef"), we did
not take the tag "beef" but after complaining used the commit
object whose name started with beef.

Another problem this fixes while introducing some confusion is
that there is no longer a reason to forbid a branch name HEAD
anymore.  In other words, now "git pull . ref1:HEAD" would work
as expected, once we revert "We do not like HEAD branch" patch.
It creates "HEAD" branch under ${GIT_DIR-.git}/refs/heads (or
fast-forwards if already exists) using the tip of ref1 branch
from the current repository, and merges it into the current
branch.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-17 23:10:56 -08:00
Junio C Hamano 6677c4665a get_sha1_basic(): corner case ambiguity fix
When .git/refs/heads/frotz and .git/refs/tags/frotz existed, and
the object name stored in .git/refs/heads/frotz were corrupt, we
ended up picking tags/frotz without complaining.  Worse yet, if
the corrupt .git/refs/heads/frotz was more than 40 bytes and
began with hexadecimal characters, it silently overwritten the
initial part of the returned result.

This commit adds a couple of tests to demonstrate these cases,
with a fix.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-15 12:54:00 -08:00
Junio C Hamano 924215024c Make sure heads/foo and tags/foo do not confuse things.
When both heads/foo and tags/foo exist, get_sha1_basic("foo")
picked up the tag without complaining, which is quite confusing.
Make sure we require unambiguous form, "heads/foo" or "tags/foo"
in such cases.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-21 00:43:12 -08:00
Junio C Hamano 9534f40bc4 Be careful when dereferencing tags.
One caller of deref_tag() was not careful enough to make sure
what deref_tag() returned was not NULL (i.e. we found a tag
object that points at an object we do not have).  Fix it, and
warn about refs that point at such an incomplete tag where
needed.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-02 16:50:58 -08:00
Linus Torvalds af13cdf298 Be more careful about reference parsing
This does two things:

 - we don't allow "." and ".." as components of a refname. Thus get_sha1()
   will not accept "./refname" as being the same as "refname" any more.

 - git-rev-parse stops doing revision translation after seeing a pathname,
   to match the brhaviour of all the tools (once we see a pathname,
   everything else will also be parsed as a pathname).

Basically, if you did

	git log *

and "gitk" was somewhere in the "*", we don't want to replace the filename
"gitk" with the SHA1 of the branch with the same name.

Of course, if there is any change of ambiguity, you should always use "--"
to make it explicit what are filenames and what are revisions, but this
makes the normal cases sane. The refname rule also means that instead of
the "--", you can do the same thing we're used to doing with filenames
that start with a slash: use "./filename" instead, and now it's a
filename, not an option (and not a revision).

So "git log ./*.c" is now actually a perfectly valid thing to do, even if
the first C-file might have the same name as a branch.

Trivial test:

	git-rev-parse gitk ./gitk gitk

should output something like

	9843c3074d
	./gitk
	gitk

where the "./gitk" isn't seen as a revision, and the second "gitk" is a
filename simply because we've seen filenames already, and thus stopped
doing revision parsing.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-28 14:25:05 -07:00
Junio C Hamano 6e1c6c103c Make sure we barf on ref^{type} failure.
Martin Langhoff noticed that ref^0 barfed correctly when we did not
have the commit in a broken repository, but ref^{commit} didn't.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-19 22:49:31 -07:00
Junio C Hamano 5385f52da8 Introduce notation "ref^{type}".
Existing "tagname^0" notation means "dereference tag zero or more
times until you cannot dereference it anymore, and make sure it is a
commit -- otherwise barf".  But tags do not necessarily reference
commit objects.

This commit introduces a bit more generalized notation, "ref^{type}".
Existing "ref^0" is a shorthand for "ref^{commit}".  If the type
is empty, it just dereferences tags until it hits a non-tag object.

With this, "git-rev-parse --verify 'junio-gpg-pub^{}'" shows the blob
object name -- there is no need to manually read the tag object and
find out the object name anymore.

"git-rev-parse --verify 'HEAD^{tree}'" can be used to find out the
tree object name of the HEAD commit.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-15 11:23:40 -07:00
Junio C Hamano 013f276eb7 show-branch: optionally use unique prefix as name.
git-show-branch acquires two new options. --sha1-name to name
commits using the unique prefix of their object names, and
--no-name to not to show names at all.

This was outlined in <7vk6gpyuyr.fsf@assigned-by-dhcp.cox.net>

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-11 15:22:48 -07:00
Junio C Hamano 0bc4589020 Make sure get_sha1 does not accept ambiguous sha1 prefix (again).
The earlier fix incorrectly dropped the code the original had to
ensure the found SHA1 is at least unique within the same pack.
Restore the check.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-03 18:50:06 -07:00
Junio C Hamano 5a82b4fb3e Error message from get_sha1() on ambiguous short SHA1.
Unlike cases where "no such object exists", the case where specified
prefix is ambiguous would confuse the user if we say "no such commit"
or such.  Give an extra error message from the uniqueness check if
there are more than one objects that match the given prefix.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-03 00:36:13 -07:00
Junio C Hamano 99a19b4302 Make sure get_sha1 does not accept ambiguous sha1 prefix.
The original code did not even check alternates, and was confused if
an unpacked object was uniquely found when there was another object
that shares the same prefix in the pack.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-02 21:40:51 -07:00
Linus Torvalds ca8db1424d [PATCH] Allow reading "symbolic refs" that point to other refs
This extends the ref reading to understand a "symbolic ref": a ref file
that starts with "ref: " and points to another ref file, and thus
introduces the notion of ref aliases.

This is in preparation of allowing HEAD to eventually not be a symlink,
but one of these symbolic refs instead.

[jc: Linus originally required the prefix to be "ref: " five bytes
 and nothing else, but I changed it to allow and strip any number of
 leading whitespaces to match what update-ref.c does.]

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-01 23:19:32 -07:00
Linus Torvalds af61c6e008 Fix extended short SHA1 name completion
get_sha1() would not do sha1 completion of short SHA1's when they were
part of a more complex expression.  So doing

	git-rev-parse 727132834e6be48a93c1bd6458a29d474ce7d5d5^

would work, and return 87c6aeb4ef. But using
the shorthand version

	git-rev-list 72713^

wouldn't work.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-20 15:04:19 -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