Re: how to create v2 patch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



El 6/12/2007, a las 21:04, Tilman Schmidt escribió:

Am 01.12.2007 14:43 schrieb Mike Hommey:
On Sat, Dec 01, 2007 at 02:17:39PM +0100, Pascal Obry wrote:
Tilman Schmidt a écrit :
I have produced a patch, submitted it to LKML, received a few
comments, committed appropriate changes to my local git tree,
and now want to submit a revised patch. How do I do that?
If I just run git-format-patch again, it produces my original
patch plus a second one containing my updates, but what I need
is a single new patch replacing the first one.
Can't you merge both of your changes in your local repository? I would
do that with an interactive rebase.

Or just git commit --amend when committing.

Hmm. But wouldn't each of these approaches lead to my original
commit being removed from my git repository?

Not immediately, but eventually. Let's say you have a history like this:

A--B--C--D

And you amend commit D to become D':

A--B--C--D'
       \
        D

You effectively have two "branches" now, but one of them (the original D) is unreferenced and will eventually be garbage collected. In other words, your ongoing development will look like this:

A--B--C--D'-E--F--G
       \
        D

At this point the only thing which references commit D will be your reflog, and with default settings that means that the commit will hang around for at least 90 more days before being pruned during garbage collection.

And isn't removing
commits that have already been published strongly discouraged?

Yes, normally that statement is true (because someone else may have based work on top of "D" and if you delete "D" then you just pulled the rug out from under them). But as others have pointed out, posting a PATCH to a mailing list isn't the same thing as "publishing a commit", so I won't repeat what's already been explained.

If, however, you really had *published* the commit (ie. pushed it out to an accessible repository) then you'd want to use "git revert" rather than "git commit --amend".

A--B--C--D--D'--E--F

Reverting doesn't delete any commits at all; instead it introduces a new commit (D') which undoes the change introduced in D. So you're undoing the *effect* of D without actually "undoing" the fact that you committed and published it.

Cheers,
Wincent

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux