Thread (1 message) 1 message, 1 author, 2016-06-15

Re: who's on first? - following first parent and merge-management

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:53:16

Holger Hellmuth [off-list ref] writes:
On 09.03.2012 13:29, Johannes Sixt wrote:
quoted
Am 3/9/2012 13:05, schrieb Holger Hellmuth:
quoted
On 08.03.2012 18:30, Junio C Hamano wrote:
quoted
Johannes Sixt[off-list ref]   writes:
...
I think the underlying mechanism needed to implement the above
shares a lot with what Jeff called "crazy idea", but where you would
want to be after such a merge may be different in these two cases.
I don't think there is much question that you should still be in the same
branch. Not because you necessarily want to be in that branch. But because
it would be surprising if git-merge changed your branch sometimes and most
times not.
I don't think that it is so clear-cut.
...
I see we have different ideas. I envisioned --into to be the equivalent of
git checkout master
git merge topic
git checkout topic

and in that case index and worktree would be topic naturally.
That is why I rewrote it to "git merge-to master" in my response,
and said that there are two slightly different workflow ingredients
that can be implemented with a similar mechanism.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help