Ungrafting

Ungrafting

[Leo Famulari]

Hi all,

When committing a bug fix with a graft, I think it would be a good idea
to follow up on some other branch with a commit that makes the same
change without a graft.

Core-updates was suggested on IRC. This would mean that after each graft
commit, master would need to be merged into core-updates, and then the
"ungrafting" patch could be applied.

Thoughts?

Re: Ungrafting

[Mark H Weaver]

Leo Famulari <leo@famulari.name> writes:

> When committing a bug fix with a graft, I think it would be a good idea
> to follow up on some other branch with a commit that makes the same
> change without a graft.
>
> Core-updates was suggested on IRC. This would mean that after each graft
> commit, master would need to be merged into core-updates, and then the
> "ungrafting" patch could be applied.

Merging those two will be awkward.  In my experience, the result of git
automatically merging these two commits is to update the main package
*and* to graft it.  For this reason, I think it's preferable for the
ungrafted commit to be on top of the grafted one, i.e. it should remove
the graft and update the origin package in a single commit.

In practice, this means that after applying the graft to master, master
should be merged into core-updates before applying the ungrafting commit
to core-updates.

What do you think?

      Mark

Re: Ungrafting

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> Leo Famulari <leo@famulari.name> writes:
>
>> When committing a bug fix with a graft, I think it would be a good idea
>> to follow up on some other branch with a commit that makes the same
>> change without a graft.
>>
>> Core-updates was suggested on IRC. This would mean that after each graft
>> commit, master would need to be merged into core-updates, and then the
>> "ungrafting" patch could be applied.
>
> Merging those two will be awkward.  In my experience, the result of git
> automatically merging these two commits is to update the main package
> *and* to graft it.

Good point.

> For this reason, I think it's preferable for the ungrafted commit to
> be on top of the grafted one, i.e. it should remove the graft and
> update the origin package in a single commit.
>
> In practice, this means that after applying the graft to master, master
> should be merged into core-updates before applying the ungrafting commit
> to core-updates.
>
> What do you think?

Sounds like a good workflow, yes.

Regarding builds, it’s really a scheduling problem.  We have periodic
update branches (gnome-updates, python-updates, core-updates), and
Something could tell you whether a change is eligible for one of these
branches, so we could batch related changes together.

Ludo’.

Re: Ungrafting

[Leo Famulari]

On Mon, May 02, 2016 at 09:34:34AM -0400, Mark H Weaver wrote:
> Leo Famulari <leo@famulari.name> writes:
> > Core-updates was suggested on IRC. This would mean that after each graft
> > commit, master would need to be merged into core-updates, and then the
> > "ungrafting" patch could be applied.

> In practice, this means that after applying the graft to master, master
> should be merged into core-updates before applying the ungrafting commit
> to core-updates.
> 
> What do you think?

I'm having a hard time seeing the difference between our suggestions.
Can you clarify yours?

To give more detail, here is what I was suggesting:

1) Apply a graft to master.
2) Merge master into core-updates.
3) Apply a commit to core-updates that "un-does" the graft and applies
the bug fix without a graft.

Apologies if my original email was unclear.