RE: How to update a cloned git repository

From: Joachim Schmitz <jojo@schmitz-digital.de>
Date: Sep 11, 2012, 16:45 UTC
Message-ID: <007301cd903c$e09c0050$a1d400f0$@schmitz-digital.de>
In-Reply-To: <7v627kk0re.fsf@alter.siamese.dyndns.org>

Show 24 quoted lines

> -----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" <jojo@schmitz-digital.de> writes:
> 
> >> 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).

Show 19 quoted lines

> 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