Re: [BUG] Cannot push some grafted branches

[Yann Dirson <dirson@bertin.fr>]

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

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

> 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