> -----Original Message----- > From: Junio C Hamano [mailto:gitster@xxxxxxxxx] > Sent: Tuesday, September 11, 2012 6:01 PM > To: Joachim Schmitz > Cc: 'Matthieu Moy'; git@xxxxxxxxxxxxxxx > Subject: Re: How to update a cloned git repository > > "Joachim Schmitz" <jojo@xxxxxxxxxxxxxxxxxx> writes: > > >> From: Matthieu Moy [mailto:Matthieu.Moy@xxxxxxxxxxxxxxx] > >> .. > >> 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 -- 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