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

[Jeff King <peff@peff.net>]

On Wed, Jan 08, 2014 at 02:55:04AM +0530, Ramkumar Ramachandra wrote:

> Jeff King wrote:
> > 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
> 
> Ah, I was perhaps over-specializing for my own usecase, where
> everything is based off 'master'. I never considered 'master' a "true
> upstream" because I throw away topic branches after the maintainer
> merges them. If you have long-running branches that you work on a
> daily basis, the issue is somewhat different.

What I do is maybe somewhat gross, but I continually rebase my patches
forward as master develops. So they diverge from where Junio has forked
them upstream (which does not necessarily have any relationship with
where I forked from, anyway). The nice thing about this is that
eventually the topic becomes empty, as rebase drops patches that were
merged upstream (or resolve conflicts to end up at an empty patch).

It's a nice way of tracking the progress of the patch upstream, and it
catches any differences between what's upstream and what's in the topic
(in both directions: you see where the maintainer may have marked up
your patch, and you may see a place where you added something to be
squashed but the maintainer missed it). The downside is that sometimes
the conflicts are annoying and complicated (e.g., several patches that
touch the same spot are a pain to rebase on top of themselves; the early
ones are confused that the later changes are already in place).

> My primary concern is that the proposed @{publish} should be a
> first-class citizen; if it has everything that @{u} has, then we're
> both good: you'd primarily use @{u}, while I'd primarily use
> @{publish}.

Definitely. I think that's the world we want to work towards.

-Peff