git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] builtin-apply: keep information about files to be deleted

From
Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Date
Apr 17, 2009, 17:23 UTC
Message-ID
<20090417192324.3a888abf@gmail.com>
In-Reply-To
<7v1vrwdyxx.fsf@gitster.siamese.dyndns.org>

W dniu 13 kwietnia 2009 23:30 użytkownik Junio C Hamano <gitster@pobox.com> napisał:

Show 16 quoted lines
>  
> >
> > As far as I understand the code, diffs are applied independently
> > (for every file apply_patch() is called) and for every apply_patch()
> > call fn_table is cleared. So situation you described in only
> > possible in a *single* diff and I don't think it is possible to
> > happen.  
>
> Yes, one invocation of "git format-patch -1" will not produce such a
> situation.
>
> A single diff file that is concatenation of two "git format-patch -1"
> output (or just a plain-old "diff -ru" output from outside git,
> perhaps managed in quilt) was what introduced fn_table mechanism.
>  Apparently people use "git apply" to apply such a patch.
>  

I have been thinking about that and IMO something is not right in handling multiple patches. I'm still new to git, so I may be wrong. Look:

Suppose I have 3 patches:

patch #1: modify A patch #2: rename A to B patch #3: modify B

These patches will be applied correctly.

But, if I swap patches #1 and #3, none of them will be applied. This is because of 2 rules, implemented in add_to_fn_table():

1. If a file was renamed/deleted, applying a patch is not possible.
2. If a file is new/modified, applying a patch is possible.

They seem reasonable. In previous example, file A comes under rule #1 and file B under rule #2. However, there are some cases when these two rules may cause problems:

patch #1: rename A to B patch #2: rename C to A patch #3: modify A

Should patch #3 modify B (which was A) or A (which was C)?

patch #1: rename A to B patch #2: rename B to A patch #3: modify A patch #4: modify B

Which files should be patched by #3 and #4?

In my opinion both #3 and #4 should fail (or both should succeed) -- with my patch only #3 will work and #4 will be rejected, because in #2 B was marked as deleted.

Previous: Junio C HamanoNext: Junio C Hamano
Message 6 of 12 in “builtin-apply: keep information about files to be deleted”
  1. builtin-apply: keep information about files to be deletedMichał Kiedrowicz, Apr 11, 2009
  2. Michał KiedrowiczApr 13, 2009
  3. Junio C HamanoApr 13, 2009
  4. Michał KiedrowiczApr 13, 2009
  5. Junio C HamanoApr 13, 2009
  6. Michał KiedrowiczApr 17, 2009
  7. Junio C HamanoApr 18, 2009
  8. Andreas EricssonApr 18, 2009
  9. Junio C HamanoApr 18, 2009
  10. Michał KiedrowiczApr 18, 2009
  11. tests: make test-apply-criss-cross-rename more robustMichał Kiedrowicz, Apr 18, 2009
  12. Junio C HamanoApr 18, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.