Skip to content

G
git

李少辉-开发者 / git
与 Fork 源项目一致

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 06 4月, 2007 4 次提交
    • J
      Fix bogus error message from merge-recursive error path · 0424138d
      由 Junio C Hamano 提交于 
      This error message should not usually trigger, but the function
make_cache_entry() called by add_cacheinfo() can return early
without calling into refresh_cache_entry() that sets cache_errno.

Also the error message had a wrong function name reported, and
it did not say anything about which path failed either.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      0424138d
    • A
      Show binary file size change in diff --stat · b1882587
      由 Andy Parkins 提交于 
      Previously, a binary file in the diffstat would show as:

 some-binary-file.bin       |  Bin

The space after the "Bin" was never used.  This patch changes binary
lines in the diffstat to be:

 some-binary-file.bin       |  Bin 12345 -> 123456 bytes

The very nice "->" notation was suggested by Johannes Schindelin, and
shows the before and after sizes more clearly than "+" and "-" would.
If a size is 0 it's not shown (although it would probably be better to
treat no-file differently from zero-byte-file).

The user can see what changed in the binary file, and how big the new
file is.  This is in keeping with the information in the rest of the
diffstat.

The diffstat_t members "added" and "deleted" were unused when the file
was binary, so this patch loads them with the file sizes in
builtin_diffstat().  These figures are then read in show_stats() when
the file is marked binary.
Signed-off-by: NAndy Parkins <andyparkins@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      b1882587
    • S
      Fix lost-found to show commits only referenced by reflogs · 566842f6
      由 Shawn O. Pearce 提交于 
      Prior to 1.5.0 the git-lost-found utility was useful to locate
commits that were not referenced by any ref.  These were often
amends, or resets, or tips of branches that had been deleted.
Being able to locate a 'lost' commit and recover it by creating a
new branch was a useful feature in those days.

Unfortunately 1.5.0 added the reflogs to the reachability analysis
performed by git-fsck, which means that most commits users would
consider to be lost are still reachable through a reflog.  So most
(or all!) commits are reachable, and nothing gets output from
git-lost-found.

Now git-fsck can be told to ignore reflogs during its reachability
analysis, making git-lost-found useful again to locate commits
that are no longer referenced by a ref itself, but may still be
referenced by a reflog.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      566842f6
    • N
      clean up and optimize nth_packed_object_sha1() usage · d72308e0
      由 Nicolas Pitre 提交于 
      Let's avoid the open coded pack index reference in pack-object and use
nth_packed_object_sha1() instead.  This will help encapsulating index
format differences in one place.

And while at it there is no reason to copy SHA1's over and over while a
direct pointer to it in the index will do just fine.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Acked-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      d72308e0
  3. 05 4月, 2007 1 次提交
  5. 04 4月, 2007 15 次提交
  7. 03 4月, 2007 1 次提交
  9. 01 4月, 2007 15 次提交
  11. 31 3月, 2007 4 次提交
    • J
      contrib/workdir: add a simple script to create a working directory · 4f01748d
      由 Julian Phillips 提交于 
      Add a simple script to create a working directory that uses symlinks
to point at an exisiting repository.  This allows having different
branches in different working directories but all from the same
repository.

Based on a description from Junio of how he creates multiple working
directories[1].  With the following caveat:

"This risks confusion for an uninitiated if you update a ref that
is checked out in another working tree, but modulo that caveat
it works reasonably well."

[1] http://article.gmane.org/gmane.comp.version-control.git/41513/Signed-off-by: NJulian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      4f01748d
    • A
      Reimplement emailing part of hooks--update in contrib/hooks/post-receive-email · 4557e0de
      由 Andy Parkins 提交于 
      The update hook is no longer the correct place to generate emails; there
is now the hooks/post-receive script which is run automatically after a
ref has been updated.

This patch is to make use of that new location, and to address some
faults in the old update hook.

The primary problem in the conversion was that in the update hook, the
ref has not actually been changed, but is about to be.  In the
post-receive hook the ref has already been updated.  That meant that
where we previously had lines like:

 git rev-list --not --all

would now give the wrong list because "--all" in the post-receive hook
includes the ref that we are making the email for.  This made it more
difficult to show only the new revisions added by this update.

The solution is not pretty; however it does work and doesn't need any
changes to git-rev-list itself.  It also fixes (more accurately: reduces
the likelihood of) a nasty race when another update occurs while this
script is running.  The solution, in short, looks like this (see the
source code for a longer explanation)

 git rev-parse --not --all | grep -v $(git rev-parse $refname) |
 git rev-list --pretty --stdin $oldrev..$newrev

This uses git-rev-parse followed by grep to filter out the revision of
the ref in question before it gets to rev-list and inhibits the output
of itself.  By using $(git rev-parse $revname) rather than $newrev as the
filter, it also takes care of the situation where another update to the
same ref has been made since $refname was $newrev.

The second problem that is addressed is that of tags inhibiting the
correct output of an update email.  Consider this, with somebranch and
sometag pointing at the same revision:

 git push origin somebranch
 git push origin sometag

That would work fine; the push of the branch would generate an email
containing all the new commits introduced by the update, then the push
of the tag would generate the shortlog formatted tag email.  Now
consider:

 git push origin sometag
 git push origin somebranch

When some branch comes to run its "--not --all" line, it will find
sometag, and filter those commits from the email - leaving nothing.
That meant that those commits would not show (in full) on any email.
The fix is to not use "--all", and instead use "--branches" in the
git-rev-parse command.

Other changes
 * Lose the monstrous one-giant-script layout and put things in easy to
   digest functions.  This makes it much easier to find the place you
   need to change if you wanted to customise the output.  I've also
   tried to write more verbose comments for the same reason.  The hook
   script is big, mainly because of all the different cases that it has
   to handle, so being easy to navigate is important.
 * All uses of "git-command" changed to "git command", to cope better
   if a user decided not to install all the hard links to git;
 * Cleaned up some of the English in the email
 * The fact that the receive hook makes the ref available also allows me
   to use Shawn Pearce's fantastic suggestion that an annotated tag can
   be parsed with git-for-each-ref.  This removes the potentially
   non-portable use of "<<<" heredocs and the nasty messing around with
   "date" to convert numbers of seconds UTC to a real date
 * Deletions are now caught and notified (briefly)
 * To help with debugging, I've retained the command line mode from the
   update hook; but made it so that the output is not emailed, it's just
   printed to the screen.  This could then be redirected if the user
   wanted
 * Removed the "Hello" from the beginning of the email - it's just
   noise, and no one seriously has their day made happier by "friendly"
   programs
 * The fact that it doesn't rely on repository state as an indicator any
   more means that it's far more stable in its output; hopefully the
   same arguments will always generate the same email - even if the
   repository changes in the future.  This means you can easily recreate
   an email should you want to.
 * Included Jim Meyering's envelope sender option for the sendmail call
 * The hook is now so big that it was inappropriate to copy it
   to every repository by keeping it in the templates directory.
   Instead, I've put a comment saying to look in contrib/hooks, and
   given an example of calling the script from that template hook.  The
   advantage of calling the script residing at some fixed location is
   that if a future package of git included a bug fixed version of the
   script, that would be picked up automatically, and the user would not
   have to notice and manually copy the new hook to every repository
   that uses it.
Signed-off-by: NAndy Parkins <andyparkins@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      4557e0de
    • E
      git-svn: avoid respewing similar error messages for missing paths · a6a15a99
      由 Eric Wong 提交于 
      We ignore errors if the path we're tracking did not exist for
a particular revision range, but we still print out warnings
telling the user about that.

As pointed out by Seth Falcon, this amounts to a lot of warnings
that could confuse and worry users.  I'm not entirely comfortable
completely silencing the warnings, but showing one warning per
path that we track should be reasonable.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      a6a15a99
    • T
      Rename warn() to warning() to fix symbol conflicts on BSD and Mac OS · 46efd2d9
      由 Theodore Ts'o 提交于 
      This fixes a problem reported by Randal Schwartz:

>I finally tracked down all the (albeit inconsequential) errors I was getting
>on both OpenBSD and OSX.  It's the warn() function in usage.c.  There's
>warn(3) in BSD-style distros.  It'd take a "great rename" to change it, but if
>someone with better C skills than I have could do that, my linker and I would
>appreciate it.

It was annoying to me, too, when I was doing some mergetool testing on
Mac OS X, so here's a fix.
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
Cc: "Randal L. Schwartz" <merlyn@stonehenge.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      46efd2d9