login
Header Space

 
 

Re: dangling commits.

Previous thread: gitweb.cgi, $my_uri and too many slashes in url by Brandon Philips on Saturday, May 20, 2006 - 6:58 pm. (1 message)

Next thread: Re: [PATCH 0/5] More ref logging by Shawn Pearce on Saturday, May 20, 2006 - 8:50 pm. (2 messages)
To: <git@...>
Date: Saturday, May 20, 2006 - 7:05 pm

What's wrong here?

(tmp)$ mkdir git
(tmp)$ cd git
(git)$ rsync -azq rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git/ .git
(git)$ git-fsck-objects --full
dangling commit fc024e5e1b92fb11d11aa3c15e9e3f92a888acb6
dangling commit be49def3dd524b241e3f14c657e740f2e4d73d39
dangling commit e659abda29b2b25db2771c3e6086f15bc74b1d06
dangling commit 0f5aaf12d411debc2958dfb029ffcf873d980f15
dangling commit 8eed8a5da8330df6901f254eab4b7056855b919c

The version of git on that box is 1.2.6-1 from Debian etch.

		Dave

-- 
http://www.codemonkey.org.uk
-
To: Dave Jones <davej@...>
Cc: <git@...>
Date: Saturday, May 20, 2006 - 7:19 pm

Nothing, except

 - you used rsync to fetch the thing (so you get all objects, regardless 
   of whether they are reachable or not)

 - junio re-bases his "pu" branch, and I just end up following him (I 
   should stop exporting git entirely, here's no point, really). Thus, 
   whenever "pu" gets reset to something else, the old head of pu gets 
   dropped on the floor and ends up as a "dangling" commit (no branch head 
   points to it any more).

The moral(s) of the story being that

 (a) dangling commits are normal if you reset branch heads (which includes 
     things like "git rebase", for example)

 (b) rsync is not a good transfer protocol, since it will just blindly 
     transfer objects that aren't needed - or worse - successfully clone a 
     corrupt repository.

but there's nothing to _worry_ about in this particular schenario.

		Linus
-
To: Linus Torvalds <torvalds@...>
Cc: <git@...>
Date: Saturday, May 20, 2006 - 7:49 pm

On Sat, May 20, 2006 at 04:19:06PM -0700, Linus Torvalds wrote:

 &gt; &gt; What's wrong here?
 &gt; 
 &gt; Nothing, except
 &gt; 
 &gt;  - you used rsync to fetch the thing (so you get all objects, regardless 
 &gt;    of whether they are reachable or not)

Ah. I actually noticed this when I poked around the box that does
the nightly snapshots, and wondered for a few minutes why I never
switched it over to git:// last time I poked at that script.
Then it came back to me: rsync -q worked better than redirecting
git to /dev/null
- git-clone's -q was still outputting some stuff, so recloning each
  time the cronjob ran wasn't an option,
- subsequent git pull's were noisy too

When run from a cronjob, unless something fatal happens, I basically
never want to get mail from the snapshotting script.

 &gt;  - junio re-bases his "pu" branch, and I just end up following him (I 
 &gt;    should stop exporting git entirely, here's no point, really).

I just updated the snapshot script to pull from 
http://www.kernel.org/pub/scm/git/git.git/ instead.

thanks,

		Dave

-- 
http://www.codemonkey.org.uk
-
To: Dave Jones <davej@...>
Cc: <git@...>
Date: Saturday, May 20, 2006 - 7:08 pm

On Sat, 20 May 2006 19:05:31 -0400

Nothing wrong.  Those commits were just dropped from the "pu" branch at
one time or another when it was rewound.  The repository could use a
pruning, but there's no harm done by having those objects remain in
the object database.   If you had used any protocol other than rsync,
they would not have appeared in your cloned copy.

Sean
-
Previous thread: gitweb.cgi, $my_uri and too many slashes in url by Brandon Philips on Saturday, May 20, 2006 - 6:58 pm. (1 message)

Next thread: Re: [PATCH 0/5] More ref logging by Shawn Pearce on Saturday, May 20, 2006 - 8:50 pm. (2 messages)
speck-geostationary