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 -
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
-On Sat, May 20, 2006 at 04:19:06PM -0700, Linus Torvalds wrote: > > What's wrong here? > > Nothing, except > > - you used rsync to fetch the thing (so you get all objects, regardless > 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. > - junio re-bases his "pu" branch, and I just end up following him (I > 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 -
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 -
| Andrew Morton | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| David Miller | Re: [GIT]: Networking |
| Eric Paris | [RFC 0/5] [TALPA] Intro to a linux interface for on access scanning |
| Natalie Protasevich | [BUG] New Kernel Bugs |
git: | |
| Jakub Narebski | Re: VCS comparison table |
| Ingo Molnar | [OT] Your branch is ahead of the tracked remote branch 'origin/master' by 50 commi... |
| Li Frank-B20596 | why not TortoiseGit |
| Joe Fiorini | Undo git-rm without commit? |
| Arjan van de Ven | Re: [GIT]: Networking |
| Andrew Morton | Re: [BUG] New Kernel Bugs |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Glenn Griffin | [PATCH] Add IPv6 support to TCP SYN cookies |
| Marius ROMAN | 1440x900 resolution problem |
| Martin Schröder | Re: Real men don't attack straw men |
| Otto Moerbeek | Re: SCP/SFTP: Couldn't open /dev/null |
| Siju George | Skype on OpenBSD 4.1 using Fedora RPM |
