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

From: Markus Heidelberg <markus.heidelberg@web.de>
Date: Apr 10, 2009, 14:48 UTC
Message-ID: <200904101648.44593.markus.heidelberg@web.de>
In-Reply-To: <20090410081843.GB9369@gmail.com>

David Aguilar, 10.04.2009:

Show 6 quoted lines

> On  0, David Aguilar <davvid@gmail.com> 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.

Show 20 quoted lines

> $ git log -p 44c36d1c
> commit 44c36d1ccc9a40bfb31910dfd7e18d59fa8be502
> Author: Charles Bailey <charles@hashpling.org>
> 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 <charles@hashpling.org>
>     Signed-off-by: Junio C Hamano <gitster@pobox.com>
> 
> 
> 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