Re: How to update a cloned git repository

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 11, 2012, 16:00 UTC
Message-ID: <7v627kk0re.fsf@alter.siamese.dyndns.org>
In-Reply-To: <006f01cd900e$fce59a60$f6b0cf20$@schmitz-digital.de>

"Joachim Schmitz" <jojo@schmitz-digital.de> writes:

Show 8 quoted lines

>> From: Matthieu Moy [mailto:Matthieu.Moy@grenoble-inp.fr]
>> ..
>> Short answer: don't work on pu. Work on master unless you have a good
>> reason not to.
>
> There are some changes in pu, that I need as the basis, namely my
> setitimer patch and my 2nd mkdir patch, which haven't yet made it
> into the master branch (and in the setitimer case not out of pu)

And that is not a good reason, either.

In general, it is a good habit to get into to base your changes on the oldest point release they may want to be used with. For example, if you really wanted to, you could make sure your Tandem changes can be back-merged all the way down to v1.7.6 by forking your own branch from there, queuing your changes like mkdir, itimer on top. And you develop and test your changes on that branch, without pulling from or rebasing it on top of my tree where random other things happen that won't affect you an iota. A recent change to add the new "--set-upstream-to" option to "branch" command does not have any platform-specific bits, and for the purpose of the "port to Tandem" topic, keeping up to date with such a change in my tree is pointless, for example. To make sure that the result is still usable with recent releases, you can create a throw-away merge between your work (that is forked from a stable base) and my tip every once in a while, test the result, and discard the throw-away merge when you are done. Any breakage in your series you find in such an integration test is to be fixed on your branch, not on top of such a throw-away merge.

It might be the case that nobody cares if the resulting patches will not apply to and usable with 'master' or older integration branches, so in the particular case of "Tandem", choosing a stable fork point that is older than 'master' may not make much sense, though.