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