{"thread":{"id":"13139","subject":"Re: fsck --full is Ok, but clones are not, \"missing commits\"?!","startedAt":"2008-04-16T15:04:56Z","lastAt":"2008-04-18T09:29:23Z","messageCount":9,"participants":["Brian Foster","Johannes Sixt","Brandon Casey","Dmitry Potapov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"74557","messageId":"a537dd660804160804t252d2900j33e30a01dc58979c@mail.gmail.com","threadId":"13139","inReplyTo":"200804161626.44174.brian.foster@innova-card.com","subject":"Re: fsck --full is Ok, but clones are not, \"missing commits\"?!","fromName":"Brian Foster","fromEmail":"brian.foster@innova-card.com","sentAt":"2008-04-16T15:04:56Z","receivedAt":"2008-04-16T15:04:56Z","isPatch":false,"sender":{"key":"brian.foster@innova-card.com","avatar":null},"body":"Johannes Sixt <j.sixt@viscovery.net> helpfully observes:\n>  Brian Foster schrieb:\n>  > Dmitry Potapov <dpotapov@gmail.com> correctly deduced:\n>  >>  I suspect your original git repository has info/grafts\n>  >  bingo!  YES, it does:\n>[ ... ]\n>  >  the goal is to put things into a sane state so any new\n>  >  clones are healthy.  there's only one(?) existing clone,\n>  >  which may or may not be(? become?) an issue.\n>\n>  Just move info/grafts out of the way and you *may* be all set. Don't\n>  delete it - there might be a reason that the file exists.\n\nHannes & Dmitry,\n\n thanks for the suggestions.  I've made (and carefully protected)\n multiple backups, and am doing all my experiments on copies, and\n have taken other protective steps, so no worries about accidents.\n\n moving  info/grafts  out of the way causes `fsck --full' to issue\n the same complaints as it does for clones.  conversely, copying\n info/grafts  to a clone makes `fsck --full' happy.  furthermore,\n close examination of that one pre-existing clone shows it has the\n identical  info/grafts  as the bare repository.  so that seems to\n have been what was previously being done (I'm now attempting to\n confirm this, and also to find out WHY).\n\n however, no joy at all with the suggestion:\n\n>  Your best bet is to run 'git filter-branch --tag-name-filter cat -- --all'\n>  on *a copy* of your bare repository (with info/grafts in place).  [ ... ]\n\n at toplevel of (a copy of) the bare repository, with  info/grafts\n in-place, and `fsck --full' happy:\n\n\t$ git version\n\t1.5.3\n\t$ git filter-branch --tag-name-filter cat -- --all   # at bare toplevel\n\tfatal: Not a git repository: '.git'\n\tYou need to run this command from the toplevel of the working tree.\n\t$\n\n at toplevel of a (not-bare) clone, with  info/grafts  in-place,\n and a happy `fsck -full' (same machine so same git version):\n\n\t$ git filter-branch --tag-name-filter cat -- --all  # at not-bare toplevel\n\tRewrite 7df30811617517bc4d5ec7c190a435667228320c (168/168)\n\tRef 'refs/heads/master' was rewritten\n\tRef 'refs/remotes/origin/HEAD' was rewritten\n\tWARNING: Ref 'refs/remotes/origin/master' is unchanged\n\tRef 'refs/tags/linux-2.6.15' was rewritten\n\terror: Ref refs/tags/linux-2.6.15 is at \\\n\t\t26a33413c95dfda6c70ca4a83da49cddb7b236b9 but expected \\\n\t\t2dcaaf2decd31ac9a21d616604c0a7c1fa65d5a4\n\tfatal: refs/tags/linux-2.6.15: cannot lock the ref\n\tCould not rewrite refs/tags/linux-2.6.15\n\t$\n\n in the later case, the  info/grafts  still existed at the end,\n and `fsck --full' was happy.  (I suppose this isn't surprising\n since the filter-branch was not happy.)   moving  info/grafts\n out of the way caused the same complaints from `fsck --full'.\n\n the missing commits are all(? mostly?) similar to this example:\n\n\t$ git remote\n\torigin\n\t$ git remote show origin\n\t* remote origin\n\t  URL: git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git\n        [ ... ]\n\t$ git show dff364d8da\n\tcommit dff364d8da15be0b856a174062fb785acb1c363e\n\tMerge: bc59a40... 427abfa...\n\tAuthor: Ralf Baechle <ralf@linux-mips.org>\n\tDate:   Sun Jun 18 03:42:49 2006 +0100\n\t\n\t    Merge tag 'v2.6.17' of\ngit://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n\t\n\t$\n\n as such, is there some way of adding them back to the bare\n repository (if that even makes sense?), or whatever?  (i.e.,\n that have not been lost, is it possible to take advantage\n of that fact?)\n\n also (sorry!), does anyone recognise the development process\n that apparently was used?  (the one pre-existing clone has\n few-to-no clews, since it was used for some fairly trivial\n local development, not for the \"merging\" (if I can call it\n that) with linux-mips repository.)\n\ncheers!\n\t-blf-\n\n-- \n\"How many surrealists does it take to    |  Brian Foster\n change a lightbulb?  Three.  One calms  |  somewhere in south of France\n the warthog, and two fill the bathtub   |     Stop E$$o (ExxonMobil)!\n with brightly-coloured machine tools.\"  |       http://www.stopesso.com\n"},{"id":"74560","messageId":"480619AE.8010506@viscovery.net","threadId":"13139","inReplyTo":"a537dd660804160804t252d2900j33e30a01dc58979c@mail.gmail.com","subject":"Re: fsck --full is Ok, but clones are not, \"missing commits\"?!","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-04-16T15:22:22Z","receivedAt":"2008-04-16T15:22:22Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Brian Foster schrieb:\n>  at toplevel of a (not-bare) clone, with  info/grafts  in-place,\n>  and a happy `fsck -full' (same machine so same git version):\n> \n> \t$ git filter-branch --tag-name-filter cat -- --all  # at not-bare toplevel\n> \tRewrite 7df30811617517bc4d5ec7c190a435667228320c (168/168)\n> \tRef 'refs/heads/master' was rewritten\n> \tRef 'refs/remotes/origin/HEAD' was rewritten\n> \tWARNING: Ref 'refs/remotes/origin/master' is unchanged\n> \tRef 'refs/tags/linux-2.6.15' was rewritten\n> \terror: Ref refs/tags/linux-2.6.15 is at \\\n> \t\t26a33413c95dfda6c70ca4a83da49cddb7b236b9 but expected \\\n> \t\t2dcaaf2decd31ac9a21d616604c0a7c1fa65d5a4\n> \tfatal: refs/tags/linux-2.6.15: cannot lock the ref\n> \tCould not rewrite refs/tags/linux-2.6.15\n> \t$\n\nActually, I don't know how to overcome this situation; maybe forget about\nthe tags and remove the '--tag-name-filter cat' part. They wouldn't have\nbeen rewritten correctly anyway (annotated tags loose the message and\nbecome unannotated).\n\n>  as such, is there some way of adding them back to the bare\n>  repository (if that even makes sense?), or whatever?  (i.e.,\n>  that have not been lost, is it possible to take advantage\n>  of that fact?)\n> \n>  also (sorry!), does anyone recognise the development process\n>  that apparently was used?  (the one pre-existing clone has\n>  few-to-no clews, since it was used for some fairly trivial\n>  local development, not for the \"merging\" (if I can call it\n>  that) with linux-mips repository.)\n\nIn this case you might be able to salvage missing objects by cloning\nlinux-mips. Just copy the objects/pack/* from that clone into your\nobjects/pack, remove info/grafts, and maybe things \"just work\"?\n\n-- Hannes\n"},{"id":"74562","messageId":"48062515.50903@nrlssc.navy.mil","threadId":"13139","inReplyTo":"480619AE.8010506@viscovery.net","subject":"Re: fsck --full is Ok, but clones are not, \"missing commits\"?!","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-04-16T16:11:01Z","receivedAt":"2008-04-16T16:11:01Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Johannes Sixt wrote:\n> Brian Foster schrieb:\n>>  at toplevel of a (not-bare) clone, with  info/grafts  in-place,\n>>  and a happy `fsck -full' (same machine so same git version):\n>>\n>> \t$ git filter-branch --tag-name-filter cat -- --all  # at not-bare toplevel\n>> \tRewrite 7df30811617517bc4d5ec7c190a435667228320c (168/168)\n>> \tRef 'refs/heads/master' was rewritten\n>> \tRef 'refs/remotes/origin/HEAD' was rewritten\n>> \tWARNING: Ref 'refs/remotes/origin/master' is unchanged\n>> \tRef 'refs/tags/linux-2.6.15' was rewritten\n>> \terror: Ref refs/tags/linux-2.6.15 is at \\\n>> \t\t26a33413c95dfda6c70ca4a83da49cddb7b236b9 but expected \\\n>> \t\t2dcaaf2decd31ac9a21d616604c0a7c1fa65d5a4\n>> \tfatal: refs/tags/linux-2.6.15: cannot lock the ref\n>> \tCould not rewrite refs/tags/linux-2.6.15\n>> \t$\n> \n> Actually, I don't know how to overcome this situation; maybe forget about\n> the tags and remove the '--tag-name-filter cat' part. They wouldn't have\n> been rewritten correctly anyway (annotated tags loose the message and\n> become unannotated).\n\n\nI don't think the tag-name-filter section has been reached yet.\n\nI think the problem is the --all option to rev-parse. This adds everything under\n.git/refs to the list of heads to rewrite. Just a guess, but possibly the\nlinux-2.6.15 is an annotated tag, which is dereferenced to a commit (the oldsha1),\nand then when update-ref is called with the newsha1 and the oldsha1, the oldsha1\ndoesn't match what is in refs/tags/linux-2.6.15 since that points to the sha1 of\nthe tag object.\n\nTry --branches instead of --all. Or leave it blank if you just want to filter\nthe current branch.\n\nAlso, if you're interested in retaining the annotations from the tags, search the\nlist for '[PATCH v4] filter-branch.sh: support nearly proper tag name filtering'\nor grab the patch from git's pu branch.\n\n-brandon\n"},{"id":"74567","messageId":"20080416171547.GE3133@dpotapov.dyndns.org","threadId":"13139","inReplyTo":"a537dd660804160804t252d2900j33e30a01dc58979c@mail.gmail.com","subject":"Re: fsck --full is Ok, but clones are not, \"missing commits\"?!","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-04-16T17:15:47Z","receivedAt":"2008-04-16T17:15:47Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Wed, Apr 16, 2008 at 05:04:56PM +0200, Brian Foster wrote:\n> \n>  in the later case, the  info/grafts  still existed at the end,\n>  and `fsck --full' was happy.  (I suppose this isn't surprising\n>  since the filter-branch was not happy.)   moving  info/grafts\n>  out of the way caused the same complaints from `fsck --full'.\n\nDo not remove info/grafts. Just clone this repository after\nfilter-branch and then the _newly_ cloned repository should\nbe fine.\n\nDmitry\n"},{"id":"74640","messageId":"a537dd660804170753i4dcfd189m45a9581294ce5091@mail.gmail.com","threadId":"13139","inReplyTo":"200804171643.15504.brian.foster@innova-card.com","subject":"Re: fsck --full is Ok, but clones are not, \"missing commits\"?!","fromName":"Brian Foster","fromEmail":"brian.foster@innova-card.com","sentAt":"2008-04-17T14:53:14Z","receivedAt":"2008-04-17T14:53:14Z","isPatch":false,"sender":{"key":"brian.foster@innova-card.com","avatar":null},"body":"Hannes suggested:\n> Brian Foster schrieb:\n> >[ ... ] is there some way of adding [ the missing commits,\n> >  all of which seem to be from linux-mips, ] back to the bare\n> >  repository (if that even makes sense?), or whatever?  (i.e.,\n> >  [ they ] have not been lost, [ so ] is it possible to take\n> >  advantage of that fact?)   [ ... ]\n>\n> In this case you might be able to salvage missing objects by cloning\n> linux-mips. Just copy the objects/pack/* from that clone into your\n> objects/pack, remove info/grafts, and maybe things \"just work\"?\n\nHannes et al.,\n\n thanks for the suggestion.  bingo!  that basically worked.\n after copying linux-mips  objects/pack/*  into my goofy\n bare repository,  `fsck --full'  (after moving  grafts\n out of the way) found different issues.  it complained\n about a zillion dangling tags (yawn), plus a handful of\n dangling commits.\n\n the dangling tags were the linux-mips  refs/tags/*.  copying\n them into my repository's  ref/tags  fixed that.  (there were\n no name collisions with the existing tags, so this was easy.)\n\n the dangling commits were linux-mips  refs/remotes/origin/*,\n and again could be safely/easily copied into my repository.\n\n `fsck --full' is now 100% happy.  (yea!)\n\n the obvious missing thing (which I _think_ is easy to fix?)\n is the remote URL &tc is not in my now-not-so-goofy bare\n repository.  hence `branch -r' shows  origin/*  branches,\n but (I speculate) a `pull' (e.g.) will be confused.\n\n at this point in time I've not done any extensive testing\n of the seemingly-fixed repository, but things are looking\n much better.\n\n before trying the copying suggestion, I played some\n more with `filter-branch'.  I had no success at all.\n as one example, with `--branches' instead of `--all'\n (one of Brandon's suggestions) produced:\n\n\t$ git filter-branch --tag-name-filter cat -- --branches\n\tWhich ref do you want to rewrite?\n\t$\n\n also, Dmitry's suggestion of cloning (with grafts still\n in-place) after `filter-branch ... --all' accomplished\n nothing obvious:  `fsck --full' of the new clone was\n still unhappy (same set of complaints).\n\n whilst I'm still trying to understand the rationale for\n why things were set-up(? left-in?) this weird state,\n browsing the history gives some vague hints.  however,\n the intended usage model remains opaque.\n\n and that will soon be my next problem:  what's a better\n (best?) usage model (for this project)?  I need to do\n some more reading here ....  ;-\\\n\ncheers!\n        -blf-\n\n-- \n\"How many surrealists does it take to    |  Brian Foster\n change a lightbulb?  Three.  One calms  |  somewhere in south of France\n the warthog, and two fill the bathtub   |     Stop E$$o (ExxonMobil)!\n with brightly-coloured machine tools.\"  |       http://www.stopesso.com\n"},{"id":"74644","messageId":"48076F94.7030206@nrlssc.navy.mil","threadId":"13139","inReplyTo":"a537dd660804170753i4dcfd189m45a9581294ce5091@mail.gmail.com","subject":"Re: fsck --full is Ok, but clones are not, \"missing commits\"?!","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-04-17T15:41:08Z","receivedAt":"2008-04-17T15:41:08Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Brian Foster wrote:\n\n>  before trying the copying suggestion, I played some\n>  more with `filter-branch'.  I had no success at all.\n>  as one example, with `--branches' instead of `--all'\n>  (one of Brandon's suggestions) produced:\n> \n> \t$ git filter-branch --tag-name-filter cat -- --branches\n> \tWhich ref do you want to rewrite?\n> \t$\n\nThat's strange. Are there any branches in this repository? Yes, looking at\nyour earlier email:\n\n  at toplevel of a (not-bare) clone, with  info/grafts  in-place,\n  and a happy `fsck -full' (same machine so same git version):\n\n\t$ git filter-branch --tag-name-filter cat -- --all  # at not-bare toplevel\n\tRewrite 7df30811617517bc4d5ec7c190a435667228320c (168/168)\n\tRef 'refs/heads/master' was rewritten\n\tRef 'refs/remotes/origin/HEAD' was rewritten\n  [snip]\n\nLooks like there is a single branch named 'master'.\n\n\nThe command within git-filter-branch.sh that is being called is\n\n   git rev-parse --no-flags --revs-only --symbolic-full-name --default HEAD --branches\n\nIn a trim git repository for example this command returns:\n\n   refs/heads/master\n   refs/heads/next\n\nReferring to two branches 'master' and 'next'. These are the references\nthat exist in .git/refs/heads/*.\n\nI'd be interested to see what this command returns in your repo. You can compare\nthis output to the output you get using --all and also relate that to the\ndirectory structure beneath .git/refs/\n\n-brandon\n\n\np.s. It's more polite to keep the people you are responding to in the cc list.\n     Take a look at how Hannes did it (the email to which this one is replying).\n     Usually it's enough to select 'Reply All'.\n"},{"id":"74719","messageId":"a537dd660804180141h25b7f8e2yf7283f63d49521e6@mail.gmail.com","threadId":"13139","inReplyTo":"200804180943.20933.brian.foster@innova-card.com","subject":"Re: fsck --full is Ok, but clones are not, \"missing commits\"?!","fromName":"Brian Foster","fromEmail":"brian.foster@innova-card.com","sentAt":"2008-04-18T08:41:00Z","receivedAt":"2008-04-18T08:41:00Z","isPatch":false,"sender":{"key":"brian.foster@innova-card.com","avatar":null},"body":"> Brian Foster wrote:\n>  > \t$ git filter-branch --tag-name-filter cat -- --branches\n>  > \tWhich ref do you want to rewrite?\n>  > \t$\n>\n> That's strange. Are there any branches in this repository?  [ ... ]\n> Looks like there is a single branch named 'master'.\n\nBrandon et al.,\n\n correct.  there is just the `master' branch.  it is extremely\n clean and straightforward:   O---O---O---O-- ... --O---O\n\n\n> The command within git-filter-branch.sh that is being called is\n>\n>    git rev-parse --no-flags --revs-only --symbolic-full-name --default HEAD --branches\n>\n> In a trim git repository for example this command returns:\n>\n>    refs/heads/master\n>    refs/heads/next\n>\n> Referring to two branches 'master' and 'next'. These are the references\n> that exist in .git/refs/heads/*.\n>\n> I'd be interested to see what this command returns in your repo.\n\n below is a full example session, including, eventually,\n the above command `rev-parse ...' command, and several\n observations.  all the outputs are quite short, so I\n include most in full:\n\n\t$ git version\n\tgit version 1.5.3\n\t$\n\t$ git clone /pub/scm/linux/kernel/git/linux-2.6-usip.git linux-2.6-usip\n\tInitialized empty Git repository in\n/home/bfoster/usip-linux/linux-2.6-usip/.git/\n\t165531 blocks\n\tChecking 21723 files out...\n\t 100% (21723/21723) done\n\t$\n\t$ cd linux-2.6-usip\n\t$ git fsck --full\n\tbroken link from  commit dd3f3c0636cfd50719c706b030db5473b0270add\n\t              to  commit 0fed9c2eb14eee47097e1d870fe8e55a6430edeb\n\tmissing commit fb57c018d15005b60f104e57f198ff34a6035b99\n\tmissing commit f8947cb0b5fe605e6cb5f73c89f262424b64ef3c\n\tmissing commit 0fed9c2eb14eee47097e1d870fe8e55a6430edeb\n\tmissing commit dff364d8da15be0b856a174062fb785acb1c363e\n\tbroken link from  commit 8700854c41a40d333e90104971c3abbbcf082e57\n\t              to  commit b8b78d1c09e7009f97a1d624f4d771d7e5bd8551\n\tmissing commit ce33a5e8c32816f38862bc41560a1d646d0803a6\n\tmissing commit 91483db9b01b547ae9cc45c8c98b217642acb40a\n\tmissing commit b8b78d1c09e7009f97a1d624f4d771d7e5bd8551\n\tbroken link from  commit c87c46fe892211f8aa4fd363ccff4f667a9aaf7d\n\t              to  commit ce33a5e8c32816f38862bc41560a1d646d0803a6\n\tbroken link from  commit fb5967688f7b464421cff28f266b64ad2a313a9e\n\t              to  commit f8947cb0b5fe605e6cb5f73c89f262424b64ef3c\n\tbroken link from  commit e5a60f1636cceac33777bb8098a0b7a4a136a56c\n\t              to  commit fb57c018d15005b60f104e57f198ff34a6035b99\n\tbroken link from  commit 2dcaaf2decd31ac9a21d616604c0a7c1fa65d5a4\n\t              to  commit 91483db9b01b547ae9cc45c8c98b217642acb40a\n\tbroken link from  commit 0ff75b3afff6fb306bef221bf1823ccf5ffc568b\n\t              to  commit dff364d8da15be0b856a174062fb785acb1c363e\n\t$\n\t$ git filter-branch --tag-name-filter cat -- --branches\n\tWhich ref do you want to rewrite?\n\t$\n\t$ ls -laR .git-rewrite\n\t.git-rewrite:\n\ttotal 16\n\tdrwxrwxr-x  3 bfoster bfoster 4096 Apr 18 10:11 .\n\tdrwxrwxr-x 21 bfoster bfoster 4096 Apr 18 10:11 ..\n\t-rw-rw-r--  1 bfoster bfoster 1864 Apr 18 10:11 backup-refs\n\t-rw-rw-r--  1 bfoster bfoster    0 Apr 18 10:11 heads\n\tdrwxrwxr-x  2 bfoster bfoster 4096 Apr 18 10:11 t\n\n\t.git-rewrite/t:\n\ttotal 8\n\tdrwxrwxr-x 2 bfoster bfoster 4096 Apr 18 10:11 .\n\tdrwxrwxr-x 3 bfoster bfoster 4096 Apr 18 10:11 ..\n\t$\n\n watching the execution of git-filter-branch with `bash -x',\n the key point seems to be that `check-ref-formats' is being\n called with what seems to be a bogus argument:\n\n\t+ git check-ref-format 'refs/heads/master\n\trefs/remotes/origin/master'\n\n that prints nothing on stdout and exits with status 1.\n hence  .git-rewrite/heads  is empty, which is the proximate\n cause of the \"Which ref ...\" message.  (more on this below.)\n\n\t$ git filter-branch --tag-name-filter cat -- --branches\n\t.git-rewrite already exists, please remove it\n\t$\n\t$ git rev-parse --no-flags --revs-only \\\n\t\t--symbolic-full-name --default HEAD --branches\n\t7df30811617517bc4d5ec7c190a435667228320c\n\t$\n\n\n> You can compare this output to the output you get using --all and also\n> relate that to the directory structure beneath .git/refs/\n\n\t$ git branch -a\n\t* master\n\t  origin/HEAD\n\t  origin/master\n\t$\n\n that seemingly bogus `check-ref-format' argument comes\n from the pipeline (where ref=master):\n\n\tgit for-each-ref --format='%(refname)' | grep /\"$ref\"\n i.e.:\n\tgit for-each-ref --format='%(refname)' | grep /master\n\n so...\n\t$ git for-each-ref --format='%(refname)'\n\trefs/heads/master\n\trefs/remotes/origin/HEAD\n\trefs/remotes/origin/master\n\trefs/tags/linux-2.6.15\n\trefs/tags/linux-usip-v2.6.15\n\t[ ... ]\n\t$\n\n note two names match the RE `/master', hence the bogus\n argument.  the reason for that seems to be (this is a\n guess!) that `rev-parse' is *not* being run as:\n\n\tgit rev-parse --no-flags --revs-only \\\n\t\t--symbolic-full-name --default HEAD --branches\n\n as I _think_ you are claiming it should be, but as:\n\n\tgit rev-parse --revs-only --symbolic --branches\n\n the former outputs a list of SHA1s (see above).\n the later outputs just the name `master':\n\n\t$ git rev-parse --revs-only --symbolic --branches\n\tmaster\n\t$\n\n just for completeness, below is the output with `--all':\n\n\t$ git rev-parse --no-flags --revs-only \\\n\t\t--symbolic-full-name --default HEAD --all\n\t7df30811617517bc4d5ec7c190a435667228320c\n\t7df30811617517bc4d5ec7c190a435667228320c\n\t7df30811617517bc4d5ec7c190a435667228320c\n\t26a33413c95dfda6c70ca4a83da49cddb7b236b9\n\t3e1e17e642cd2fface5691ab136d79f709af9a1c\n\t8b9e620aa7f6231e30ddf70cf38759aea7c98070\n\tcd220dbc113774b420c634fe1907860387883aa2\n\tacb1587f596e4bfe4c748be742b6bf1509fc88ed\n\t938ed01b502fbf659de24c4ad1da2bb60e0a3347\n\td52b1d70e5f4c0509b6220070a1e585ac9f6d727\n\t5893ac94b533aba4a9864b0a4a3c346830ec004f\n\tbf0dfbc784e2734c61818aa0683b716cf82f13e2\n\t824a82029f8ebf2f72846490a9cd455ceaf2f5cc\n\tb07c23ef78c785168b579242f652b5f49749b02b\n\t0ae7caf477cd6a8b265497f1fb2e4273378dcfb4\n\t57545107a114f6f6fb0bcc9a0d655d84dc32113c\n\tdb7e2bc1e16ab3c6611de4b84fda529e59cb378e\n\tdf1ae0303a60ee0268012e926240720ac4d01de9\n\tb7e5fe765a0afd315781fb536ffcbd32a6666421\n\t1effee36b5784ebe5e3e7e7d34bfaf6f63be3afa\n\tb9a029d4c06eb18778f8907b359fe1616d1e2019\n\t250210f21cadd70ea5cf459b6dca990d1faecbea\n\tdc8843f2fd0954c941aff8b06205cd15c1f0873f\n\t36ee52578b10eb83d2f30e324117bfb9457e1e0e\n\tf8e0127a4cd3c1e42665a8e895e0c1a9dee052ce\n\t$\n\t$ cat .git/refs/heads/master\n\t7df30811617517bc4d5ec7c190a435667228320c\n\t$\n\n this smells like a bug in this particular version\n (1.5.3) of `git', or perhaps in the installation?\n like the repository, both are inherited, and I do\n not know the history.  ;-(\n\ncheers!\n\t-blf-\n\n-- \n\"How many surrealists does it take to    |  Brian Foster\n change a lightbulb?  Three.  One calms  |  somewhere in south of France\n the warthog, and two fill the bathtub   |     Stop E$$o (ExxonMobil)!\n with brightly-coloured machine tools.\"  |       http://www.stopesso.com\n"},{"id":"74718","messageId":"48086200.5020600@viscovery.net","threadId":"13139","inReplyTo":"a537dd660804180141h25b7f8e2yf7283f63d49521e6@mail.gmail.com","subject":"Re: fsck --full is Ok, but clones are not, \"missing commits\"?!","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-04-18T08:55:28Z","receivedAt":"2008-04-18T08:55:28Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Brian Foster schrieb:\n>  that seemingly bogus `check-ref-format' argument comes\n>  from the pipeline (where ref=master):\n> \n> \tgit for-each-ref --format='%(refname)' | grep /\"$ref\"\n>  i.e.:\n> \tgit for-each-ref --format='%(refname)' | grep /master\n> \n>  so...\n> \t$ git for-each-ref --format='%(refname)'\n> \trefs/heads/master\n> \trefs/remotes/origin/HEAD\n> \trefs/remotes/origin/master\n> \trefs/tags/linux-2.6.15\n> \trefs/tags/linux-usip-v2.6.15\n> \t[ ... ]\n> \t$\n> \n>  note two names match the RE `/master', hence the bogus\n>  argument.  the reason for that seems to be (this is a\n>  guess!) that `rev-parse' is *not* being run as:\n> \n> \tgit rev-parse --no-flags --revs-only \\\n> \t\t--symbolic-full-name --default HEAD --branches\n> \n>  as I _think_ you are claiming it should be, but as:\n> \n> \tgit rev-parse --revs-only --symbolic --branches\n\nOne of the changes since v.1.5.3 was to get rid of this bogus grep. Can\nyou install a newer git?\n\n-- Hannes\n"},{"id":"74716","messageId":"a537dd660804180229i263fea0cxb7f7ac9e8f4780@mail.gmail.com","threadId":"13139","inReplyTo":"200804181114.47067.brian.foster@innova-card.com","subject":"Re: fsck --full is Ok, but clones are not, \"missing commits\"?!","fromName":"Brian Foster","fromEmail":"blf.ireland@gmail.com","sentAt":"2008-04-18T09:29:23Z","receivedAt":"2008-04-18T09:29:23Z","isPatch":false,"sender":{"key":"blf.ireland@gmail.com","avatar":null},"body":"Johannes Sixt <j.sixt@viscovery.net> asked:\n> One of the changes since v.1.5.3 was to get rid of this bogus grep\n> [ in `check-ref-format' ].  Can you install a newer git?\n\nHannes,\n\n yes!  about 10 minutes ago I was handed the keys to a\n brand new VM which is to be the company's git server.\n a very important point is it will be backed-up (unlike\n the former repository!).  git on the VM is \"my\" problem,\n and one of the first things I must do is install it.\n\n the VM is running \"CentOS release 5 (Final)\".  all things\n being equal, I'd prefer to install a reliable/stable\n pre-built package (RPM, I assume, since CentOS is based\n on Redhat).  I confess I do not know (have not looked)\n where to find suitable RPMs of git.\n\n suggestions are most welcome!\n\ncheers!\n\t-blf-\n\n-- \n\"How many surrealists does it take to    |  Brian Foster\n change a lightbulb?  Three.  One calms  |  somewhere in south of France\n the warthog, and two fill the bathtub   |     Stop E$$o (ExxonMobil)!\n with brightly-coloured machine tools.\"  |       http://www.stopesso.com\n"}]}