Re: [PATCH 2/2] format-patch: introduce format.defaultTo

From: Jeff King <peff@peff.net>
Date: Jan 7, 2014, 21:06 UTC
Message-ID: <20140107210607.GB28102@sigill.intra.peff.net>
In-Reply-To: <CALkWK0=Km+a7NBm9ki5MN=R28HkzUZRqnBKcpuPZDrQKdsBesg@mail.gmail.com>

On Tue, Jan 07, 2014 at 04:17:00AM +0530, Ramkumar Ramachandra wrote:

Show 16 quoted lines

> Junio C Hamano wrote:.
> > As I said in the different subthread, I am not convinced that you
> > would need the complexity of branch.*.forkedFrom.  If you set your
> > "upstream" to the true upstream (not your publishing point), and
> > have "remote.pushdefault"set to 'publish', you can expect
> >
> >         git push
> >
> > to do the right thing, and then always say
> >
> >         git show-branch publish/topic topic
> 
> I think it's highly sub-optimal to have a local-branch @{u} for
> several reasons; the prompt is almost useless in this case, and it
> will always show your forked-branch ahead of 'master' (assuming that
> 'master' doesn't update itself in the duration of your development).

I actually use local-branch @{u} all the time to represent inter-topic dependencies. For example, imagine I have topic "bar" which builds on topic "foo", which is based on master. I would have:

  [branch "foo"]
    remote = origin
    merge = refs/heads/master
  [branch "bar"]
    remote = .
    merge = refs/heads/foo

When I rebase "foo", I want to rebase it against upstream's master. When I rebase "bar", I want to rebase it against foo. And naturally, upstream does not necessarily have a "foo", because it is my topic, not theirs (I _may_ have published my "foo" somewhere, but that is orthogonal, and anyway my local "foo" is the most up-to-date source, not the pushed version).

As an aside, if you want to rebase both branches, you have to topo-sort them to make sure you do "foo" first, then rebase "bar" on the result. My daily procedure is something like:

  all_topics |
  while read topic; do "echo $topic $(git rev-parse $topic@{u})"; done |
  topo_sort |
  while read topic upstream; do
    git rebase $upstream $topic || exit 1
  done

> While doing respins, the prompt doesn't aid you in any way. Besides,
> on several occasions, I found myself working on the same forked-branch
> from two different machines; then the publish-point isn't necessarily
> always a publish-point: it's just another "upstream" for the branch.

Right, things get trickier then. But I don't think there is an automatic way around that. Sometimes the published one is more up to date, and sometimes the upstream thing is more up to date. You have to manually tell git which you are currently basing your work on. I find in such a situation that it tends to resolve itself quickly, though, as the first step is to pull in the changes you pushed up from the other machine anyway (either via "git reset" or "git rebase").

-Peff