git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Linus Torvalds <torvalds@osdl.org>
Cc: git@vger.kernel.org, Franck Bui-Huu <vagabon.xyz@gmail.com>
Subject: Re: Re : 2 questions on git-send-email usage
Date: Wed, 12 Jul 2006 09:19:10 -0700	[thread overview]
Message-ID: <7v7j2izthd.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0607120834200.5623@g5.osdl.org> (Linus Torvalds's message of "Wed, 12 Jul 2006 08:43:02 -0700 (PDT)")

Linus Torvalds <torvalds@osdl.org> writes:

> On a slightly related note, I absolutely _hate_ how cherry-picking adds 
> "(cherry-picked from commit <sha1>)" at the end. It's wrong for so many 
> reasons, one of them being that it then breaks things like this, but the 
> main one being that <sha1> will quite often actually end up not even 
> _existing_ in the resulting archive (you cherry-picked from your private 
> branch, and even if you keep your branch, you don't necessarily push it 
> out).
>
> Junio, can we make the default _not_ to do it, please?

I understand that it can be annoying.

I was hoping that however when you do something like this:

	git log --filter-backported-commits v2.6.16.9..v2.6.17

an improved log-inspection tool could notice and filter out the
ones that was backported from the mainline to the maintenance
branch.

But I realize that is probably a faulty logic.  First of all,
not all backports are cherry-picked (the same patch can be
applied from an e-mail, for example), so if we really want to do
the above filtering, we would need to be able to detect the same
patch anyway without "cherry-picked from" information.

To a certain degree, git-patch-id would help detecting such a
duplicated patch, but it would not help you detect "moral
equivalent" changes that are textually different.  A cherry-pick
after a conflict resolution that ends up applying a textually
different patch would still leave the "cherry-picked from"
message in the commit log (or a "note " header if we implement
it to reduce cluttering the log message), which would be the
only advantage of recording the information somehow.  But that
is probably not worth it -- it means "moral equivalent" changes
need to be recorded somehow by hand, which is unnecessarly
developer burden if it is rare enough to want to filter such
duplicates when inspecting the log.

Do people find "cherry-picked from" information useful?  Does
anybody mind if we change the default not to record it?

  reply	other threads:[~2006-07-12 16:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-11  8:46 Re : 2 questions on git-send-email usage moreau francis
2006-07-11 10:08 ` Franck Bui-Huu
2006-07-11 19:22   ` Junio C Hamano
2006-07-12  7:37     ` Franck Bui-Huu
2006-07-12 15:43       ` Linus Torvalds
2006-07-12 16:19         ` Junio C Hamano [this message]
2006-07-12 16:24         ` Junio C Hamano
2006-07-12 16:37           ` Linus Torvalds
2006-07-13  4:34             ` Junio C Hamano
2006-07-13  4:40               ` Linus Torvalds

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=7v7j2izthd.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=torvalds@osdl.org \
    --cc=vagabon.xyz@gmail.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).