All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Jiri Kosina <jkosina@suse.cz>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [TOPIC] Metadata addendum to git commit
Date: Wed, 14 May 2014 09:49:41 +1000	[thread overview]
Message-ID: <20140514094941.41a13b26@notabene.brown> (raw)
In-Reply-To: <alpine.LNX.2.00.1405140127240.16459@pobox.suse.cz>

[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]

On Wed, 14 May 2014 01:29:29 +0200 (CEST) Jiri Kosina <jkosina@suse.cz> wrote:

> On Wed, 14 May 2014, NeilBrown wrote:
> 
> > A particular practical issue is that when doing a git-bisect there might 
> > be a range of commits that only compile/run if some later commit is 
> > applied. If I'm bisecting in that range, I have to repeatedly apply that 
> > commit by hand.
> 
> You can just have it stored in a separate branch and perform the bisection 
> using a script that will always first merge the branch, and reset after 
> good/bad verification is done.
> 
> If the fix is already applied (because you are testing a state of the tree 
> which has the commit already), git handles the merge of the 
> already-applied patch with grace even if they don't have the same SHA-1.
> 

True.  But every extra step I have to add to a script is an extra barrier to
performing what is already a somewhat tedious task.

If fixes were always Strongly-Attached to the commit they fix, then I
wouldn't even need to find these "fix-up" patches.  One person commits the
fix in the "right" way, and everyone benefits.

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  reply	other threads:[~2014-05-13 23:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-13 13:25 [Ksummit-discuss] [TOPIC] Metadata addendum to git commit Takashi Iwai
2014-05-13 23:23 ` NeilBrown
2014-05-13 23:29   ` Jiri Kosina
2014-05-13 23:49     ` NeilBrown [this message]
2014-05-14  1:40 ` Li Zefan
2014-05-16  3:07 ` Jason Cooper
2014-05-16  5:12   ` Christian Couder
2014-05-16  9:24   ` Li Zefan
2014-05-16  9:33   ` Takashi Iwai
2014-05-18 19:23     ` Christian Couder
2014-05-18 22:12       ` Jason Cooper
2014-05-19  6:34         ` Christian Couder
2014-05-19 13:29       ` Takashi Iwai
2014-05-20  6:37         ` Christian Couder
2014-05-20  7:06           ` Takashi Iwai
2014-05-21  5:36             ` Christian Couder
2014-05-22  4:49     ` Christian Couder
2014-05-22  5:58       ` Takashi Iwai
2014-05-22  6:28         ` Johan Herland
2014-05-22  6:52           ` Christian Couder
2014-05-22  7:29             ` Johan Herland
2014-05-22  7:45           ` Takashi Iwai
2014-05-22  7:49             ` Geert Uytterhoeven
2014-05-22  8:03               ` Takashi Iwai
2014-05-22 15:51       ` Theodore Ts'o

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=20140514094941.41a13b26@notabene.brown \
    --to=neilb@suse.de \
    --cc=jkosina@suse.cz \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.