* bug? git format-patch -M -D then git am fails
@ 2012-11-13 22:41 Joe Perches
0 siblings, 0 replies; 6+ messages in thread
From: Joe Perches @ 2012-11-13 22:41 UTC (permalink / raw)
To: git; +Cc: David Miller
If a file is deleted with git rm and a patch
is then generated with git format-patch -M -
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug? git format-patch -M -D then git am fails
@ 2012-11-13 22:45 Joe Perches
2012-11-13 22:55 ` Junio C Hamano
0 siblings, 1 reply; 6+ messages in thread
From: Joe Perches @ 2012-11-13 22:45 UTC (permalink / raw)
To: git; +Cc: David Miller
(Sorry about the partial message.
evolution and ctrl-enter sends, grumble...)
If a file is deleted with git rm and a patch
is then generated with git format-patch -M -D
git am is unable to apply the resultant patch.
Is this working as designed?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug? git format-patch -M -D then git am fails
2012-11-13 22:45 Joe Perches
@ 2012-11-13 22:55 ` Junio C Hamano
2012-11-13 23:06 ` Joe Perches
0 siblings, 1 reply; 6+ messages in thread
From: Junio C Hamano @ 2012-11-13 22:55 UTC (permalink / raw)
To: Joe Perches; +Cc: git, David Miller
Joe Perches <joe@perches.com> writes:
> (Sorry about the partial message.
> evolution and ctrl-enter sends, grumble...)
>
> If a file is deleted with git rm and a patch
> is then generated with git format-patch -M -D
> git am is unable to apply the resultant patch.
>
> Is this working as designed?
I would say it is broken as designed and it is even documented.
Please run "git format-patch --help | less" and then type
"/--irreversible-delete" to find:
The resulting patch is not meant to be applied with patch nor
git apply; this is solely for people who want to just
concentrate on reviewing the text after the change.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: bug? git format-patch -M -D then git am fails
2012-11-13 22:55 ` Junio C Hamano
@ 2012-11-13 23:06 ` Joe Perches
2012-11-13 23:22 ` Junio C Hamano
0 siblings, 1 reply; 6+ messages in thread
From: Joe Perches @ 2012-11-13 23:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Miller
On Tue, 2012-11-13 at 14:55 -0800, Junio C Hamano wrote:
> Joe Perches <joe@perches.com> writes:
>
> > (Sorry about the partial message.
> > evolution and ctrl-enter sends, grumble...)
> >
> > If a file is deleted with git rm and a patch
> > is then generated with git format-patch -M -D
> > git am is unable to apply the resultant patch.
> >
> > Is this working as designed?
>
> I would say it is broken as designed and it is even documented.
>
> Please run "git format-patch --help | less" and then type
> "/--irreversible-delete" to find:
>
> The resulting patch is not meant to be applied with patch nor
> git apply; this is solely for people who want to just
> concentrate on reviewing the text after the change.
yeah, it's just that not using -D can result in
some unfortunately large patches being sent to
mailing lists. I don't believe that reversibility
is a really useful aspect of deletion patches
when there are known git repositories involved.
cheers, Joe
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug? git format-patch -M -D then git am fails
2012-11-13 23:06 ` Joe Perches
@ 2012-11-13 23:22 ` Junio C Hamano
2012-11-14 13:28 ` Michael J Gruber
0 siblings, 1 reply; 6+ messages in thread
From: Junio C Hamano @ 2012-11-13 23:22 UTC (permalink / raw)
To: Joe Perches; +Cc: git, David Miller
Joe Perches <joe@perches.com> writes:
> I don't believe that reversibility
> is a really useful aspect of deletion patches
> when there are known git repositories involved.
You can read "reversibility" as "safety" if you want. We would want
to make sure we know what we are deleting before deleting a path.
The history that the receiver of such a patch has may have further
changes that are relevant that the sender of the deletion patch did
not know about, and removing the path in such a case would make the
result inconsistent. If the sender did his work on top of the newer
version with the change in the path, the sender's patch may still
have deleted the path but would have had changes to other paths to
compensate for the loss of that change.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug? git format-patch -M -D then git am fails
2012-11-13 23:22 ` Junio C Hamano
@ 2012-11-14 13:28 ` Michael J Gruber
0 siblings, 0 replies; 6+ messages in thread
From: Michael J Gruber @ 2012-11-14 13:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joe Perches, git, David Miller
Junio C Hamano venit, vidit, dixit 14.11.2012 00:22:
> Joe Perches <joe@perches.com> writes:
>
>> I don't believe that reversibility
>> is a really useful aspect of deletion patches
>> when there are known git repositories involved.
>
> You can read "reversibility" as "safety" if you want. We would want
> to make sure we know what we are deleting before deleting a path.
>
> The history that the receiver of such a patch has may have further
> changes that are relevant that the sender of the deletion patch did
> not know about, and removing the path in such a case would make the
> result inconsistent. If the sender did his work on top of the newer
> version with the change in the path, the sender's patch may still
> have deleted the path but would have had changes to other paths to
> compensate for the loss of that change.
>
Just in case someone wants to hack on this: To be safe, "git am" would
need to read the blob's sha1 from something like
diff --git a/Makefile b/Makefile
deleted file mode 100644
index 1b6d84d..0000000
and check that the file to be deleted matches.
Michael
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-11-14 13:28 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-13 22:41 bug? git format-patch -M -D then git am fails Joe Perches
-- strict thread matches above, loose matches on Subject: below --
2012-11-13 22:45 Joe Perches
2012-11-13 22:55 ` Junio C Hamano
2012-11-13 23:06 ` Joe Perches
2012-11-13 23:22 ` Junio C Hamano
2012-11-14 13:28 ` Michael J Gruber
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).