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

From: Jeff King <peff@peff.net>
Date: Jan 6, 2014, 20:43 UTC
Message-ID: <20140106204353.GB643@sigill.intra.peff.net>
In-Reply-To: <CAEBDL5UaS2Hd-Yb417W+Fw_7j1+5sRAgszko-PbU7z901_X+cw@mail.gmail.com>

On Mon, Jan 06, 2014 at 03:29:57PM -0500, John Szakmeister wrote:

Show 10 quoted lines

> > Yeah, I had similar thoughts. I personally use "branch.*.merge" as
> > "forkedFrom", and it seems like we are going that way anyway with things
> > like "git rebase" and "git merge" defaulting to upstream. But then there
> > is "git push -u" and "push.default = upstream", which treats the
> > upstream config as something else entirely.
> 
> Just for more reference, I rarely use "branch.*.merge" as
> "forkedFrom".  I typically want to use master as my target, but like
> Ram, I publish my changes elsewhere for safe keeping.  I think in a
> typical, feature branch-based workflow @{u} would be nearly useless.

In my feature-branch development for git.git, my upstream is almost always origin/master[1]. However, sometimes feature branches have dependencies[2] on each other. Representing that via the "upstream" field makes sense, since that is what you forked from, and what you would want "git rebase" to start from.

-Peff

[1] I do not even have a local "master" branch for git.git work, as it
    would just be a pain to keep up to date. I am either working
    directly on a topic branch, or I am integrating in my own personal
    branch.

[2] You should try to minimize dependencies between feature branches, of
    course, but sometimes they simply form a logical progression of
    features.