From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 18 Feb 2011 04:32:28 GMT
Subject: Re: [PATCH v2] branch/checkout --track: Ensure that upstream branch is indeed a branch
Message-ID: <7vk4gy55er.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.2.00.1102171937460.14950@debian>

Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:

> In some workflows (e.g. Linux kernel, IIRC), it is recommended to base
> your work on a tag.

But the thing is, "base your work on some known point" is a rule invented
exactly to discourage casual and frequent rebasing.

If you started your work on v2.6.36 and need to rebase to a more recent
version, you won't be using "rebase @{upstream}" notation _anyway_, as the
old base you forked your work from that you would refer to as @{upstream}
will not be moving.  You will instead rebasing on top of a _different_
commit, perhaps v2.6.38 or something.

So the workflow would look more like: 

	$ git checkout -b frotz-2.6.36 v2.6.36
        ... develop "frotz" feature on top of 2.6.36

        ... time passes ...

	$ git checkout -b frotz-2.6.38 frotz-2.6.36
        $ git rebase --onto v2.6.38 v2.6.36
	... inspect the result and it looks good.
        ... if  you don't want frotz in 2.6.36 then...
        $ git branch -D frotz-2.6.36

There is not much point in using @{upstream} when your branch management
is as disciplined as that recommended practice you cited.