bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#26028: 26.0.50; epatch for multifile patches


From: Tino Calancha
Subject: bug#26028: 26.0.50; epatch for multifile patches
Date: Thu, 09 Mar 2017 10:41:18 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Arseny Sher <sher-ars@yandex.ru> writes:

> How then I am expected to apply
> patches generated by VCS, where paths are prefixed with a/ and b/?
Ediff will skip those 'a/', 'b/' automatically.
> Again, let's consider some simple example:
>
> mkdir -p proj/src
> cd proj
> echo "void main() {}" > src/hello.c
> git init
> git add src/ && git commit -m "commit"
> echo "int main() { return 0; }" > src/hello.c
> git diff > ../tmp.patch
> git reset --hard HEAD
>
> cat ../tmp.patch
> diff --git a/src/hello.c b/src/hello.c
> index ab73b3a..76e8197 100644
> --- a/src/hello.c
> +++ b/src/hello.c
> @@ -1 +1 @@
> -void main() {}
> +int main() { return 0; }
>
> How should I apply tmp.patch to proj?
Ediff uses the `default-directory' for the patch buffer as a hint.
When i apply patches generated with VCS i _always_ set the
`default-directory' of the patch buffer equal as the root directory of
the project.  That makes multi patches work OK.
This is how i would do in your exmple:
M-: (dired "/tmp/proj") RET
C-x b *p* RET ; Now copy the patch here in your favourite way.
C-x 4 r /tmp/tmp.patch RET
C-x h M-w C-x o C-y
M-x epatch RET y *p* RET /tmp/proj/src RET

> Yet am not still sure that this is not a bug; some other guy said that
> this behaviour doesn't make sense, and similar bug was fixed recently:
> http://lists.gnu.org/archive/html/help-gnu-emacs/2017-03/msg00064.html
> http://emacs.1067599.n8.nabble.com/bug-25010-26-0-50-epatch-might-parse-wrongly-a-file-name-td413747.html
I tend to agree that it might be possible to improve how Ediff
handle these things.  That said, as a user i haven't being disturbed
so much by this inconvenience.  I am also worry if i could break other
important feature while trying to improve this; that's essentially why
i didn't try hard to work in this issue.

If you have some an idea about how to prepare a patch improving
Ediff on this area i am welcome to support you in that task.

Regards,
Tino





reply via email to

[Prev in Thread] Current Thread [Next in Thread]