Re: [PATCH] Offer to print changes while running git-mergetool
- From
Jonathan del Strother <jon.delstrother@bestbefore.tv>
- Date
- Feb 8, 2009, 11:43 UTC
- Message-ID
- <57518fd10902080343p47e30330ufdf2ece909ea0bd9@mail.gmail.com>
- In-Reply-To
- <498E3456.1080509@hashpling.org>
On 2/8/09, Charles Bailey <charles@hashpling.org> wrote:
Show 30 quoted lines
> Jonathan del Strother wrote: >> On Sat, Feb 7, 2009 at 8:11 AM, Junio C Hamano <gitster@pobox.com> wrote: >>> Jonathan del Strother <jon.delStrother@bestbefore.tv> writes: >>> >>>> Add a "Show changes" option to each prompt in mergetool. This prints the >>>> conflicted changes on the current file, using 'git log -p --merge >>>> <file>' >>> I think the patch should look like this, given the recent conversation I >>> had with you. It seems that the script thinks the unit of indentation is >>> 4-places, and case arms are indented from case/esac (neither of which is >>> the standard git shell script convention), and I tried to match that >>> style >>> used in the existing code. >>> >>> No, I didn't test it. >>> >>> Charles volunteered to take over mergetool, so he is on the Cc: list. > > At the moment, I'm slightly cool towards this patch, but perhaps I don't > really understand the underlying issue. I understand wanting to check > something (logs) in the middle of a mergetool run but I can't say that > I've ever wanted to specifically run 'git log -p --merge'. Perhaps some > users of mergetool - being visual people - would more naturally reach > for gitk? > > Given that mergetool picks up from where it left off when run a second > time, what does this patch offer over Ctrl-c, run log tool of your > choice, re-run mergetool? Or just running git log in a different > terminal instance? >
A large part of my motivation behind this patch was basically education - my team (and myself) have made poor merge decisions in the past, largely due to not being aware of a tool like "git log --merge". The patch was attempting to get inexperienced users to make better use of such tools. I certainly wouldn't be averse to using gitk instead.