squash! Merge branch 'ps/test-chmtime-get'

squash! Merge branch 'ps/test-chmtime-get'

[Johannes Sixt]

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"

Re: squash! Merge branch 'ps/test-chmtime-get'

[Junio C Hamano]

Johannes Sixt <j6t@kdbg.org> 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).