Re: Useful tracking branches and auto merging

Felipe Contreras [off-list ref] 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.

When you are collaborating with somebody else, sharing a topic branch, and
you are behind because you were not working on it while the other parties
progressed the shared topic, it would be convenient if your local branch
is fast-forwarded before you start to work on it.  One possible solution
for that would be to teach "git pull" to fast-forward such backgrounded
tracking branches that are not checked out.  Another obvious alternative
is to teach "git checkout" tell you where you are, and even tell you that
you could fast-forward [*1*].

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.

   Message-ID: [off-list ref]

   "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.

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*].


[Footnotes]

*1* It is plausible that you could go one step further and define
branch.frotz.autofastforward configuration variable to tell "git checkout"
to fast-forward in such a case, perhaps only when the working tree and the
index are clean.

*2* It also is plausible that the same branch.frotz.autofastforward
configuration variable can be noticed by "git pull".

On Tue, Oct 5, 2010 at 11:10 PM, Junio C Hamano [off-list ref] wrote:

Felipe Contreras [off-list ref] writes:

quoted

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: [off-list ref]

  "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