On Tue, Oct 5, 2010 at 11:10 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > >> I believe this use-case is valid: >> >> * The user wants *all* his remote tracking branches to point to the >> latest branch head in all the repos in the case the can be >> fast-forwarded, and in the case they can't, print an error and >> continue with the rest. > > I would not be so sure about the validity of that use case. > > If your tracking branches are always trailing, never having any real work > of your own, there is no reason to have them locally, instead of checking > them out on demand. ÂSo let's forget about that case. Don't be so quick. Typing 'master' is certain easier than 'origin/master', or 'stable' rather than 'linux-stable/master', or 'vj-feature-1' rather than 'whatever-repo-this-came-from/feature-1'. The fact that you don't do it doesn't mean it's not a valid use-case. > On the other hand, if you have forked a topic branch to build your new > nifty feature at some known point (e.g. immediately after the upstream > reached a new stable point), but you haven't done any real work on it, it > is doubtful that it is even a good idea to fast-forward it automatically > to begin with. ÂC.f. Fortunately we have 'git checkout --no-track -b origin/foo'. Problem solved. But rather, what I do is: % git branch -t origin/foo % git checkout -b nifty-feature foo > Â Message-ID: <AANLkTim85sH_2o=xCiDuoQrHq_7ZL96Y91xQMGxUP5Fy@xxxxxxxxxxxxxx> > > Â "The real problem is that maintainers often pick random - and not at > Â Âall stable - points for their development to begin with. They just > Â Âpick some random "this is where Linus -git tree is today", and do > Â Âtheir development on top of that. THAT is the problem - they are > Â Âunaware that there's some nasty bug in that version." > > IOW, once I decided one point is a good place to fork a topic, created a > branch off of it, but didn't have a chance to do a real work on it yet, it > would be very irritating if "git pull" updated that branch only because I > do not have my own commit on it yet. Then either: 1) fork of a local branch 2) use --no-track 3) don't do 'git pull --all' > I see little sanity in doing this with any option whose name has "all"; it > largely depends on the workflow, and in a single repository, some branches > may want to get fast-forwarded automatically while others don't [*2*]. I think if you are issuing 'git pull --all' you want your remote tracking branches to fast forward if possible, if not, why are you doing 'git pull --all'? Cheers. -- Felipe Contreras -- 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