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 -- 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