From: Felipe Contreras Date: Thu, 07 Oct 2010 10:04:30 GMT Subject: Re: Useful tracking branches and auto merging Message-ID: In-Reply-To: <7vvd5g5rjq.fsf@alter.siamese.dyndns.org> On Tue, Oct 5, 2010 at 11:10 PM, Junio C Hamano wrote: > Felipe Contreras 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: > >   "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