On Tue, 5 May 2009 00:40:22 +0400, Dmitry Potapov wrote: > > 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. Understandable, but not really an option in my case. (see below) > 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... In my case i'm not migrating. I'm following a svn repo, but want to do my own development in git. > 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... Yea, sounds like the correct approach. > IMHO, grafts should not be used at all except very rare cases like editing > an imported history before making it public. Suppose so, but they are also very usefull for git svn repo's where they can be used to correct for merge history. For example a feature branch getting resynced to the trunk multiple times during it's lifetime. Adding grafts for atleast the latest such occurance, makes it way easier to git diff / git merge --squash and so on between the branches. Also after the branch have been merged back into trunk, there could be a point to add a graft as the previous branch will likely be deleted from the svn repo, and thus would end up unreachable in the git repo should one decide to remove the ref to the tip since there is not branch tracking in the git svn client. In a perfect world (not a likely one as i'll not spend time on implementing it) I would like to be able to add new parents to commits and have them become permanent through something like filter-branch, without this ruining anything for anybody that pulls from this repo. Joakim -- 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