RE: How to update a cloned git repository

-----Original Message-----
From: Junio C Hamano [mailto:gitster@pobox.com]
Sent: Tuesday, September 11, 2012 6:01 PM
To: Joachim Schmitz
Cc: 'Matthieu Moy'; git@vger.kernel.org
Subject: Re: How to update a cloned git repository

"Joachim Schmitz" [off-list ref] writes:

quoted

quoted

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

The first version I ever made available for NonStop is 1.5.12, so no reason for me to go back.
On the other hand I see nothing in my patches that would not easily backport to much older releases, as the code I touched is either
newly created by me (e.g. compat/mkdir.c) or pretty old (compar/win32/poll.c).

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.

My goal here is that the next stable release has as much of my patches integrated as possible, so I have much less work when
porting, ideals just hitting 'make'...

So far my poll patches are still needed. And then, but not earlier, my plain NonStop specific ones (like a section in Makefile and
some adjustments in git-compat-utils.h) , these don't make much sense earlier.

Bye, Jojo