[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