Subject: Re: [PATCH v2 1/2] Ensure consistent usage of mergetool.keepBackup in git

From: Markus Heidelberg <[email-masked]>
Date: Fri, 10 Apr 2009 16:48:43 +0200

David Aguilar, 10.04.2009:
> On  0, David Aguilar <[email-masked]> wrote:
> > 
> > It /seems/ like the docs and completion should be updated.
> 
> Though my guess is as good as any....
> I'd rather hear someone else's opinion.

And I've waited for a response from the difftool/mergetool maintainers
at first, so I waited with my reply till now.

> $ git log -p 44c36d1c
> commit 44c36d1ccc9a40bfb31910dfd7e18d59fa8be502
> Author: Charles Bailey <[email-masked]>
> Date:   Thu Feb 21 23:30:02 2008 +0000
> 
>     Tidy up git mergetool's backup file behaviour
>     
>     Currently a backup pre-merge file with conflict markers is sometimes
>     kept with a .orig extenstion and sometimes removed depending on the
>     particular merge tool used.
>     
>     This patch makes the handling consistent across all merge tools and
>     configurable via a new mergetool.keepBackup config variable
>     
>     Signed-off-by: Charles Bailey <[email-masked]>
>     Signed-off-by: Junio C Hamano <[email-masked]>
> 
> 
> The commit comment says mergetool.keepBackup, even though the code always
> had it as merge.keepBackup.

Yes, merge.keepbackup was never documented, we shouldn't have to keep
backwards compatibility for such undocumented behaviour.

> Right now more people have merge.keepbackup already set since git-gui
> has had it that way for the last 7 months or so.

People which noticed that the documented mergetool.keepBackup didn't
work, had to look into the source to find out that merge.keepBackup did
it, so I see no problem with changing it. They rather should have
reported it anyway.

Ferry did it right with fixing this inconsistency.

> Nevertheless,
> Shawn's already applied the git-gui patch which hints that maybe
> we should just make the code match the docs.

Yes.

Markus