From: Theodore Tso <tytso@mit.edu>
To: Andreas Ericsson <ae@op5.se>
Cc: Junio C Hamano <gitster@pobox.com>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive
Date: Mon, 12 Nov 2007 10:20:18 -0500 [thread overview]
Message-ID: <20071112152018.GA20772@thunk.org> (raw)
In-Reply-To: <4738292E.2020103@op5.se>
On Mon, Nov 12, 2007 at 11:21:34AM +0100, Andreas Ericsson wrote:
>
> git format-patch could probably go in, but skip the others. I've never
> used git cherry in my entire life and it's not, strictly speaking,
> necessary for users to have it. There are other and easier ways to
> find the same information.
How useful it is depends on the project, definitely. The Linux kernel
doesn't have the "what's cooking" emails, and is very fast-moving, so
a day after you submit your patch set via e-mail, and then you do a
pull, and several hundred commits come spilling down from upstream,
git-cherry is incredibly useful to see what was accepted and what
wasn't. :-)
> I'd keep cherry-pick though. It's incredibly useful, and especially
> when a commit ends up on the wrong branch which is something newbies
> are likely to do when they start trying out the topic-branch workflow.
> I still do it sometimes, but hardly ever stop thinking about it since
> it's so easy to fix thanks to cherry-pick.
How often cherry-pick is useful is probably also very project
specific, and depends on how branchy a project happens to be, and how
aggressively patches get merged into the master development line. For
a project that is extremely linear, with few branches, cherry-pick is
less useful; I didn't have any occasion to use it for quite a while,
and certainly not while I was a git beginner.
- Ted
next prev parent reply other threads:[~2007-11-12 15:20 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-10 23:11 Deprecate git-fetch-pack? Daniel Barkalow
2007-11-11 0:48 ` Junio C Hamano
2007-11-11 3:09 ` Ask Bjørn Hansen
2007-11-11 11:05 ` Johannes Schindelin
2007-11-11 21:16 ` Junio C Hamano
2007-11-11 22:21 ` Theodore Tso
2007-11-11 22:35 ` Junio C Hamano
2007-11-11 22:50 ` Johannes Schindelin
2007-11-11 23:58 ` Theodore Tso
2007-11-12 0:16 ` Jakub Narebski
2007-11-12 17:29 ` Jon Loeliger
2007-11-12 17:33 ` Johannes Schindelin
2007-11-12 18:56 ` Jon Loeliger
2007-11-12 19:08 ` Johannes Schindelin
2007-11-12 19:16 ` Jon Loeliger
2007-11-12 0:57 ` [PATCH,RFC 1/2] Make the list of common commands more exclusive Theodore Ts'o
2007-11-12 0:57 ` [PATCH,RFC 2/2] Remove hint to use "git help -a" Theodore Ts'o
2007-11-12 2:21 ` [PATCH,RFC 1/2] Make the list of common commands more exclusive Junio C Hamano
2007-11-12 5:48 ` Ping Yin
2007-11-12 6:22 ` Theodore Tso
2007-11-12 7:26 ` Junio C Hamano
2007-11-12 10:24 ` Mike Hommey
2007-11-12 12:23 ` Johannes Schindelin
2007-11-12 7:57 ` Ask Bjørn Hansen
2007-11-12 10:21 ` Andreas Ericsson
2007-11-12 15:20 ` Theodore Tso [this message]
2007-11-12 10:15 ` Deprecate git-fetch-pack? Andreas Ericsson
2007-11-12 1:10 ` Ask Bjørn Hansen
2007-11-11 8:32 ` Mike Hommey
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=20071112152018.GA20772@thunk.org \
--to=tytso@mit.edu \
--cc=ae@op5.se \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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).