Martin von Zweigbergk <martin.von.zweigbergk@xxxxxxxxx> 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.
--
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