quilt-dev
[Top][All Lists]
Advanced

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

Re: [Quilt-dev] After refresh, file renames are transformed to addition/


From: Fab Stz
Subject: Re: [Quilt-dev] After refresh, file renames are transformed to addition/deletion
Date: Mon, 29 Jan 2024 16:31:47 +0100

Hello Andreas,

Thank you for your reply. Comments are below.

Le lundi 29 janvier 2024 15:32:13 CET, vous avez écrit :
> Am Mo., 29. Jan. 2024 um 15:05 Uhr schrieb Fab Stz via Quilt-dev
> 
> <quilt-dev@nongnu.org>:
> > Hello,
> > 
> > I'm seeing this behavior [1]:
> > 
> > I have a patch with this content to rename a file
> > 
> > diff --git
> > a/qttools/src/assistant/qlitehtml/src/3rdparty/GUMBO-AUTHORS.txt b/
> > qttools/src/assistant/qlitehtml/src/3rdparty/litehtml/src/gumbo/GUMBO-
> > AUTHORS.txt
> > similarity index 100%
> > rename from GUMBO-AUTHORS.txt
> > rename to GUMBO-AUTHORS.txt
> > 
> > It applies fine, but when I refresh, it get transformed to a file addition
> > + a file deletion with their respective full content.
> > 
> > Is it possible to preserve this?
> 
> Refresh is currently based on GNU diff; on top of that, quilt only
> tracks which files are part of the patch. This doesn't allow
> preserving renames, unfortunately.
> 
> It might be possible to rewrite the refresh command to use git instead
> of GNU diff, but it's not how git is normally used, so that might be
> difficult.

Ok, no problem. That would also add a dependency to git then.

> > I also noticed another behavior [2]:
> > 
> > If I have a rename A->B, and then a modification of content for B, "push"
> > applies fine. But when I "pop" it complains that the file is missing.
> > Something probably related to the order in which the blocks of the patch
> > file are processed. It seems it processes them in the order of the chunks
> > from top to bottom, even during "pop". Is this intended?
> 
> The output of "git patch" will never do that; it will only rename a
> file and modify it in a single step. So you are probably looking at
> several concatenated patches, and those are not guaranteed to work
> correctly. I would still expect the pop command to do the right thing
> though, so this could be a bug in GNU patch. Can you send an example,
> or better yet, create a small test case that demonstrates the problem?

Ok that explains it. I actually built that file by having one chunk for rename 
and one for content update. pop command worked fine indeed. So the problem was 
my construction.

Regards
Fab




reply via email to

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