Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> I would like it much better, if there was something like
>
> pick 5cc8f37 (init: show "Reinit" message even in ...)
> pick 18d077c (quiltimport: fix misquoting of parse...)
> merge 9876543:5cc8f37,18d077c (Merge blub)
> reset 5cc8f37
> ...
>
> I.e. like with filter-branch, and like with rebase -i -p in its current
> form, we take the _original_ names as keys as to which commits to merge,
> or where to reset to.
While the need probably would not be felt strongly if we design this only
for rebase -i, I suspect that you would want to have two kinds of reset if
you go that route. There might be some other insn that may have similar
issues.
For example, imagine a case where you want to create a merge with a
recontructed side branch. First you grow the branch you would merge into,
with a sequence:
pick A
pick B
pick C
Then in order to reconstruct a side branch that begins from a known point,
say the tip of "master", you would want to reset to a commit that is
outside of the scope of this rewriting. And then you rebuild that side
branch:
reset master
pick D
pick E
And finally (and this step shows the beauty of your approach), come back
to the other tip and make the merge:
reset C
merge E
Two resets above would have different semantics. The former resets to
unwritten, and the latter rewritten.
--
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
