Re: who's on first? - following first parent and merge-management
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 9, 2012, 16:26 UTC
- Message-ID
- <7vfwdh7nba.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <4F5A04BA.8030401@ira.uka.de>
Holger Hellmuth <hellmuth@ira.uka.de> writes:
Show 22 quoted lines
> On 09.03.2012 13:29, Johannes Sixt wrote: >> Am 3/9/2012 13:05, schrieb Holger Hellmuth: >>> On 08.03.2012 18:30, Junio C Hamano wrote: >>>> Johannes Sixt<j.sixt@viscovery.net> 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.