Re: git 1.5.4.3 push incorrectly honors grafts file

[Dmitry Potapov <dpotapov@gmail.com>]

On Sun, May 03, 2009 at 07:14:22PM +0200, elupus wrote:
> On Mon, 27 Apr 2009 17:51:05 +0200, elupus wrote:
> 
> > Hi, 
> > 
> > I recently had a problem with git push honoring the grafts file. It caused
> > it not to push all data required for a branch to the remote repository,
> > rendering it impossible to clone the remote repository (missing blobs)
> > 
> > This was with an not so fresh git version of 1.5.4.3 (ubuntu hardy).
> > 
> > Has this issue been fixed in later git version? I saw a thread talking
> > about it a long time ago (long before my release in question) on this
> > mailing list, but nothing was mentioned about if it was actually solved.
> > 
> > Regards
> > Joakim Plate
> 
> Bump, anybody know of a way to avoid this?

Don't use the grafts file. It is primary useful immediately after importing
some repository to Git when you need to clean up it a bit before fixing the
result by running git-filter-branch. Another usage of it is to add old history,
which is not part of the official repository. In the last case, you only add
a new parent, so it should not be a problem, except this addition is purely
local and any cloned repo will not have it.

> The problem even occurs on the
> local machine in that git gc will cleanup stuff that isn't required due to
> the grafts file, rendering the repo invalid if the graft file is removed.

It may happen only if your graft makes some part of history unreachable. And
as I said above, using the grafts file should be avoided wherever possible,
and graft that replaces or removes some parents should only be used if you
are going to run git-filter-branch after that.

> 
> I don't think running filter-branch on the git svn imported branches seems
> like a good idea. since that would also wreak havoc on any repo that pulls
> from mine (ie still private repo like usb stick or other dev machine).

If you migrate from SVN to Git and want to edit history after importing, you
should run filter-branch before making this repository public.  Re-writing
public history is always a bad idea, regardless how it is done. If you use
git-svn for bidirectional synchronization then you most like use grafts in
the way it was not intended to use...

> Imho, grafts shouldn't be honored on either push/pull/gc operations.

If git gc will not honor grafts then it may delete those that are referred
by grafts, which is clearly wrong. So, perhaps, what you really want is that
git-gc should consider grafts as an additional source of information rather
than replacement. (Actually, git-gc is high level wrapper over git-repack,
git-prune, etc, which should be changed.) Also, git-fsck needs to be changed
to consider grafts as an additional source of information...

Whether grafts should be completely ignored by push/pull is not completely
clear. Though it may be the best course of action, it is also confusing,
because git log and other commands show you one history, but something
different gets pulled or pushed. (So, anyone who inherited such a repo from
another co-worker is bound to a big surprise as to why pull/push do not
work correctly). Also, we have a single logic that creates packages, whether
it is packages for network transfer or local storage, but it should be
changed to work different based on whether it is local or non-local package.
So, it appears to me a lot of changes, but the end result will be still not
something what you really want to use for reliable storage...

IMHO, grafts should not be used at all except very rare cases like editing
an imported history before making it public.


Dmitry