Johannes Sixt <j6t@xxxxxxxx> writes: > Junio, > > you may want to squash this into your merge commit of branch > ps/test-chmtime-get (today it is fa57c0871fc9) > > -- Hannes > > diff --git a/t/helper/test-chmtime.c b/t/helper/test-chmtime.c > index daeddc1cbc..aa22af48c2 100644 > --- a/t/helper/test-chmtime.c > +++ b/t/helper/test-chmtime.c > @@ -25,7 +25,7 @@ > * > * To print only the mtime use --get: > * > - * test-chmtime --get file > + * test-tool chmtime --get file > * > * To set the mtime to current time: > * > @@ -33,7 +33,7 @@ > * > * To set the file mtime offset to +1 and print the new value: > * > - * test-chmtime --get +1 file > + * test-tool chmtime --get +1 file > * > */ > #include "test-tool.h" Thanks. It might be a good idea to make a merge where one branch renames and both branches make changes to the contents to always signal a failure in auto-merge and require manual inspection of the result even when the content level 3-way merge cleanly resolves to avoid a gotcha like this. If the renaming side had to modify existing contents (i.e. it had to update "test-chmtime" to "test-tool chmtime" for a feature that existed in the common ancestor), then it is plausible that the updating side that introduced changes to the contents (i.e. a newly added "test-chmtime --get") needs a similar adjustment, which is what your patch shows. On the other hand, if the renaming side did a pure rename without content change, and the other side updated contents, it is much less likely that we need to adjust the new material added on the updating side for the rename. We would be introducing a case where the entry for each of the three stages is still present in the index even though there is no conflict markers in the working tree files if we did so, so there may be some stuff that needs adjusting to the fallout from such a change (e.g. "rerere remaining" might get confused).
