Jonathan del Strother wrote: >> 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. My point wasn't that we should use gitk instead, I was just trying to illustrate that there may be a whole raft of other commands or activities that a user might want to run to help them with a merge so why should we hard wire any one of them into mergetool? The other doubt that I've since had about this patch is this. Is just before running the merge tool the best place to offer to show the log? In my usual workflows (not necessarily the best!), I usually want to fire up the merge tool as quickly as possible to get the merge resolutions done. Only once I'm in the mergetool do I realise that this one's a bit complex and I might need to consult the logs to help me resolve this one. But now, mergetool is blocked waiting for the merge tool to finish. If I abort the merge it's going to offer me the option to abort completely or carry on with the next file. (Perhaps "try again" could be a future direction that mergetool might offer, but it doesn't at the moment.) I'm far more likely to want to consult the logs in a different terminal (or gui) with the merge tool still running, especially if I've already merged some of the easy chunks and have only hit difficulties later on in the merge. Charles. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
