Am 30.11.2017 um 00:10 schrieb Igor Djordjevic:
On 29/11/2017 20:11, Johannes Sixt wrote:
With git-post, I make a fixup commit commit on the integration
branch, then `git post B && git merge B`:
...A ...C <- topics A, C
\ \
---o---o---o---o---f---F <- integration
/ / /
...B ...D / <- topic D
\ /
f'----------' <- topic B
The merge F does not introduce any changes on the integration branch,
so I do not need it, but it helps keep topic B off radar when I ask
`git branch --no-merged` later.
But you`re not committing (posting) on your HEAD`s (direct) parent in
the first place (topic B), so `commit --onto-parent` isn`t right tool
for the job... yet :)
Ohh..kay.
To work with `--onto-parent` and be able to commit on top of any of
the topic branches, you would need a situation like this instead:
(1) ...C <- topic C
|
...A | <- topic A
\|
...o I <- integration
/|
...B | <- topic B
|
...D <- topic D
This is a very, VERY exotic workflow, I would say. How would you
construct commit I when three or more topics have conflicts?
merge-octopus does not support this use-case.
With `commit --onto-parent` you would skip `git post B && git merge
B` steps, where "fixup commit" would be done with `--onto-parent B`,
So you end up in situation like this:
(2) ...C <- topic C
|
...A | <- topic A
\|
...o I' <- integration
/|
...B---f | <- topic B
|
...D <- topic D
State of index and working tree files in your F and my I' commit is
exactly the same (I' = I + f), where in my case (2) history looks
like "f" was part of topic B from the start, before integration
merge happened.
BUT, all this said, I understand that your starting position, where
not all topic branches are merged at the same time (possibly to keep
conflict resolution sane), is probably more often to be encountered
in real-life work... and as existing `--onto-parent` machinery should
be able to support it already, I`m looking forward to make it happen :)
Once there, starting from your initial position:
...A ...C <- topics A, C
\ \ E
---o---o---o---o I <- integration <- HEAD
/ /
...B ...D <- topics B, D
... and doing something like `git commit --onto B --merge` would yield:
(3) ...A ...C <- topics A, C
\ \ E
---o---o---o---o I' <- integration
/ /|
...B ...D | <- topic D
\ |
f-------' <- topic B
... where (I' = I + f) is still true.
I am not used to this picture. I would not think that it is totally
unacceptable, but it still has a hmm-factor.
If that`s preferred in some
cases, it could even look like this instead:
(4) ...A ...C <- topics A, C
\ \ E I
---o---o---o---o---F <- integration
/ / /
...B ...D / <- topic D
\ /
f-------' <- topic B
... where F(4) = I'(3), so similar situation, just that we don`t
discard I but post F on top of it.
This is very acceptable.
Nevertheless, IMO, it is not the task of git-commit to re-compute a
merge commit. It would be OK that it commits changes on top of a branch
that is not checked out. Perhaps it would even be OK to remove the
change from the current workspace (index and worktree), because it will
return in the form of a merge later, but producing that merge is
certainly not the task of git-commit.
-- Hannes
