Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

> On 27/11/2017 22:54, Johannes Sixt wrote:
>>
>> I my opinion, putting the focus on integration merge commits and the
>> desire to automate the re-merge step brings in a LOT of complexity in
>> the implementation for a very specific use-case that does not
>> necessarily help other cases.
> 
> It might seem more complex than it is, until you examine the guts to
> see how it really works :)
> 
> Basic concept is pretty simple, as I actually don`t automate
> anything, at least not in terms of what would manual user steps look
> like - for example, there`s no real re-merge step in terms of
> actually redoing the merge, I just reuse what was already there in a
> very clean way, I would think (supported by my current, humble
> knowledge, still).
> 
> The only merge that could possibly ever happen is upon committing
> desired subset of changes onto parent, and that shouldn`t be too
> complex by definition, otherwise that commit doesn`t really belong
> there in the first place, if it can`t be meaningfully applied where
> we want it (for now, at least).
> 
> That said, the whole operation of "posting on parent and re-merging
> everything", the way it looks like from the outside, could end just
> with a simple diff-apply-commit-commit internally, no merges at all.
> Only if simple `git apply` fails, we try some trivial merging - and
> all that inside separate (parent) index only, not touching original
> HEAD index nor working tree, staying pristine for the whole process,
> untouched.
> 
> Once done, you should be in the very same situation you started from,
> nothing changed, just having your history tweaked a bit to tell a
> different story on how you got there (now including a commit you
> posted on your HEAD`s parent).

> Don`t let "usual/preferred/recommended" Git workflow distract you too
> much - one of the reasons I made this is because it also allows _kind
> of_ "vanilla Git" patch queue, where you can quickly work on top of
> the merge head, pushing commits onto parents below, being tips of
> your "queues", putting you up to speed without a need to ever switch
> a branch (hypothetically), until satisfied with what you have, where
> you can slow down and polish each branch separately, as usual.
> 
> Like working on multiple branches at the same time, in the manner
> similar to what `git add --patch` allows in regards to working on
> multiple commits at the same time. This just takes it on yet another
> level... hopefully :)

>> In your scenario above, it would certainly not be too bad if you
>> forgo the automatic merge and have the user issue a merge command
>> manually. The resulting history could look like this:
>>
>> (3)         o---o---A---X    (topicA)
>>             /         \   \
>>            /           M1--M2 (test, HEAD)
>>           /           /||
>>       ---o---o---M---' ||     (master)
>>           \   \       / |
>>            \   o-----B /      (topicB)
>>             \         /
>>              o---o---C        (topicC)
>>
>> I.e., commit --onto-parent A produced commit X, but M2 was then a
>> regular manual merge. (Of course, I am assuming that the merge
>> commits are dispensible, and only the resulting tree is of
>> interest.)
> 
> I see - and what you`re asking for is what I already envisioned and
> hoped to get some more feedback about, here`s excerpt from
> [SCRIPT/RFC 3/3] git-commit--onto-parent.sh[1] (I guess you didn`t
> have time to checked that one yet?):

> 
>    For example, it might make sense to separate commit creation (on
>    current HEAD`s parent) and its actual re-merging into integration
>    test branch, where "--remerge" (or something) parameter would be used
>    on top of "--onto-parent" to trigger both, if/when desired.
>    
>    Another direction to think in might be introducing more general
>    "--onto" parameter, too (or instead), without "parent" restriction,
>    allowing to record a commit on top of any arbitrary commit (other
>    than HEAD). This could even be defaulted to "git commit <commit-ish>"
>    (no option needed), where current "git commit" behaviour would then
>    just be a special case of omitted <commit-ish> defaulting to HEAD,
>    aligning well with other Git commands sharing the same behaviour.
> 
> So I definitely look forward decoupling these two ((1) commit to
> parent and (2) remerge), with enough discussion flowing :)
> 
> Heck, even "to parent" is an artificial/imposed restriction now, in
> reality you could commit on top of any other commit you want (without
> switching branches)... but let`s take one step at a time.
> 
> Just note that omitting the remerge step is what actually makes the
> logic more complex, as we now need to change the original situation,
> too, both HEAD index and working tree, to remove changes which we
> committed elsewhere (without "merging" back in).

>>From what I understand, your `git-post` makes a commit where you are 
> _and copies_ it over to destination, so you end up with same changes
> in two places (two commits). More, you seem to keep working on top of
> your previous commit(s), which seems logical, later "posting" it
> where desired - so after the fact. It also means you do still have
> all your "fix" commits in HEAD while you work on them (and until you
> git-post and abandon them, discarding the integration branch).

> 
> But `git commit --onto-parent` proposed here does the commit on
> destination only, where later "remerge" is crucial part of still
> keeping that commit changes in the current HEAD working tree as well,
> so you can still keep working on top of them.
> 
> Could it be that you`re looking at `git commit --onto-parent` from an
> unexpected perspective (through your `git-post`, being conceptually
> different)...?