From: Jeff King <peff@peff.net>
To: John Szakmeister <john@szakmeister.net>
Cc: Junio C Hamano <gitster@pobox.com>,
Ramkumar Ramachandra <artagnon@gmail.com>,
Git List <git@vger.kernel.org>
Subject: Re: [PATCH 2/2] format-patch: introduce format.defaultTo
Date: Mon, 6 Jan 2014 15:43:54 -0500 [thread overview]
Message-ID: <20140106204353.GB643@sigill.intra.peff.net> (raw)
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:
> > 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.
next prev parent reply other threads:[~2014-01-06 20:44 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-06 17:18 [PATCH 0/2] Minor convinience feature: format.defaultTo Ramkumar Ramachandra
2014-01-06 17:18 ` [PATCH 1/2] completion: complete format.coverLetter Ramkumar Ramachandra
2014-01-07 11:24 ` Ramkumar Ramachandra
2014-01-06 17:18 ` [PATCH 2/2] format-patch: introduce format.defaultTo Ramkumar Ramachandra
2014-01-06 18:35 ` Jonathan Nieder
2014-01-06 19:02 ` Ramkumar Ramachandra
2014-01-06 18:42 ` Junio C Hamano
2014-01-06 18:49 ` Ramkumar Ramachandra
2014-01-06 20:06 ` Junio C Hamano
2014-01-06 20:18 ` Jeff King
2014-01-06 20:29 ` John Szakmeister
2014-01-06 20:42 ` Jonathan Nieder
2014-01-06 21:13 ` John Szakmeister
2014-01-06 21:37 ` Junio C Hamano
2014-01-06 22:54 ` Ramkumar Ramachandra
2014-01-07 0:42 ` John Szakmeister
2014-01-07 16:47 ` Ramkumar Ramachandra
2014-01-06 20:43 ` Jeff King [this message]
2014-01-06 20:38 ` Junio C Hamano
2014-01-06 20:55 ` Jeff King
2014-01-06 21:21 ` Junio C Hamano
2014-01-06 22:10 ` Ramkumar Ramachandra
2014-01-07 20:56 ` Jeff King
2014-01-07 21:07 ` Junio C Hamano
2014-01-07 21:24 ` Jeff King
2014-01-07 22:06 ` Junio C Hamano
2014-01-07 22:17 ` Jeff King
2014-01-07 22:27 ` Junio C Hamano
2014-04-10 19:17 ` Felipe Contreras
2014-01-06 21:59 ` Ramkumar Ramachandra
2014-01-06 22:22 ` Junio C Hamano
2014-01-06 22:47 ` Ramkumar Ramachandra
2014-01-07 21:06 ` Jeff King
2014-01-07 21:25 ` Ramkumar Ramachandra
2014-01-07 21:30 ` Jeff King
2014-04-10 19:20 ` Felipe Contreras
2014-01-06 17:25 ` [PATCH 0/2] Minor convinience feature: format.defaultTo Ramkumar Ramachandra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140106204353.GB643@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=john@szakmeister.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).