Johannes Sixt <j.sixt@xxxxxxxxxxxxx> helpfully observes:
> Brian Foster schrieb:
> > Dmitry Potapov <dpotapov@xxxxxxxxx> correctly deduced:
> >> I suspect your original git repository has info/grafts
> > bingo! YES, it does:
>[ ... ]
> > the goal is to put things into a sane state so any new
> > clones are healthy. there's only one(?) existing clone,
> > which may or may not be(? become?) an issue.
>
> Just move info/grafts out of the way and you *may* be all set. Don't
> delete it - there might be a reason that the file exists.
Hannes & Dmitry,
thanks for the suggestions. I've made (and carefully protected)
multiple backups, and am doing all my experiments on copies, and
have taken other protective steps, so no worries about accidents.
moving info/grafts out of the way causes `fsck --full' to issue
the same complaints as it does for clones. conversely, copying
info/grafts to a clone makes `fsck --full' happy. furthermore,
close examination of that one pre-existing clone shows it has the
identical info/grafts as the bare repository. so that seems to
have been what was previously being done (I'm now attempting to
confirm this, and also to find out WHY).
however, no joy at all with the suggestion:
> Your best bet is to run 'git filter-branch --tag-name-filter cat -- --all'
> on *a copy* of your bare repository (with info/grafts in place). [ ... ]
at toplevel of (a copy of) the bare repository, with info/grafts
in-place, and `fsck --full' happy:
$ git version
1.5.3
$ git filter-branch --tag-name-filter cat -- --all # at bare toplevel
fatal: Not a git repository: '.git'
You need to run this command from the toplevel of the working tree.
$
at toplevel of a (not-bare) clone, with info/grafts in-place,
and a happy `fsck -full' (same machine so same git version):
$ git filter-branch --tag-name-filter cat -- --all # at not-bare toplevel
Rewrite 7df30811617517bc4d5ec7c190a435667228320c (168/168)
Ref 'refs/heads/master' was rewritten
Ref 'refs/remotes/origin/HEAD' was rewritten
WARNING: Ref 'refs/remotes/origin/master' is unchanged
Ref 'refs/tags/linux-2.6.15' was rewritten
error: Ref refs/tags/linux-2.6.15 is at \
26a33413c95dfda6c70ca4a83da49cddb7b236b9 but expected \
2dcaaf2decd31ac9a21d616604c0a7c1fa65d5a4
fatal: refs/tags/linux-2.6.15: cannot lock the ref
Could not rewrite refs/tags/linux-2.6.15
$
in the later case, the info/grafts still existed at the end,
and `fsck --full' was happy. (I suppose this isn't surprising
since the filter-branch was not happy.) moving info/grafts
out of the way caused the same complaints from `fsck --full'.
the missing commits are all(? mostly?) similar to this example:
$ git remote
origin
$ git remote show origin
* remote origin
URL: git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git
[ ... ]
$ git show dff364d8da
commit dff364d8da15be0b856a174062fb785acb1c363e
Merge: bc59a40... 427abfa...
Author: Ralf Baechle <ralf@xxxxxxxxxxxxxx>
Date: Sun Jun 18 03:42:49 2006 +0100
Merge tag 'v2.6.17' of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
$
as such, is there some way of adding them back to the bare
repository (if that even makes sense?), or whatever? (i.e.,
that have not been lost, is it possible to take advantage
of that fact?)
also (sorry!), does anyone recognise the development process
that apparently was used? (the one pre-existing clone has
few-to-no clews, since it was used for some fairly trivial
local development, not for the "merging" (if I can call it
that) with linux-mips repository.)
cheers!
-blf-
--
"How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools." | http://www.stopesso.com
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
