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

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


[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

[2] You should try to minimize dependencies between feature branches, of
    course, but sometimes they simply form a logical progression of
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to