> -----Original Message-----
> From: Junio C Hamano [mailto:gits...@pobox.com]
> Sent: Tuesday, September 11, 2012 6:01 PM
> To: Joachim Schmitz
> Cc: 'Matthieu Moy'; firstname.lastname@example.org
> Subject: Re: How to update a cloned git repository
> "Joachim Schmitz" <j...@schmitz-digital.de> writes:
> >> From: Matthieu Moy [mailto:matthieu....@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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html