Re: [BUG] Cannot push some grafted branches

From: Yann Dirson <dirson@bertin.fr>
Date: Dec 12, 2012, 08:44 UTC
Message-ID: <20121212094432.6e1e48c8@chalon.bertin.fr>
In-Reply-To: <7vd2yg8ngk.fsf@alter.siamese.dyndns.org>

On Tue, 11 Dec 2012 10:15:23 -0800 Junio C Hamano <gitster@pobox.com> wrote:

Show 15 quoted lines

> Yann Dirson <dirson@bertin.fr> writes:
> 
> > There seems to be some bad interactions between git-push and grafts.
> > The problem seems to occur when a commit that exists in the remote
> > repo is subject to a graft in the local repo, and we try to push one
> > of the fake parents.
> 
> History tweaking by grafts is only visible inside your local
> repository and objects are not rewritten, and grafts are not
> transferred across repositories.  They were invented to be used as a
> stop-gap measure until you filter-branch the history before
> publishing (or if you do not publish, then you can keep using your
> local grafts).
> 
> Isn't this well known?  Perhaps we would need to document it better.

I am well aware of that, and did not intend to push any grafted commit. I am attempting to push a well-formed commit, which happens to be used as a grafted commit's fake parent, and my interpretation is that git reacts as if it was considering that the remote already had that commit, possibly because it would not ignore grafts when deciding which commits are already known to the remote.

Show 5 quoted lines

> What you can do is to use "replace" instead and publish the replace
> refs, I think.  Object transfer will then follow the true parenthood
> connectivity and people who choose to use the same replacement as
> you do can fetch the replace ref from you (this will grab objects
> necessary to complete the alternative history) and install it.

I am only using grafts as a temporary and lightweight drafting area, before setting the results in stone - although in my case it will be with filter-branch rather than replace, but the idea is the same. I just got bitten when attempting to push a valid branch while the grafts were in effect, when in fact they should have had no influence at all.

In fact, I even looked for a way to specify an alternate (or supplementary) grafts file for this drafting work, so only well-controlled git invocations would see them, whereas the others would just ignore them, and could not find any - nor could I identify an existing way of disabling the use of grafts by other means than moving it out of the way. In this respect, they seem to be lacking a few features, when compared to "replace" refs, but they have different uses, and just using the latter as a drafting area is just not adequate.

I thought about adding support for a GIT_GRAFTS_FILE envvar, which would default to $GITDIR/info/grafts, or maybe with a more general addition of a GIT_EXTRA_GRAFT_FILES envvar, but I'm not sure the latter would be that useful.

-- 
Yann Dirson - Bertin Technologies