On Sat, Feb 24, 2018 at 1:08 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Duy Nguyen <pclouds@xxxxxxxxx> writes: > >> On Fri, Feb 23, 2018 at 1:19 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> Duy Nguyen <pclouds@xxxxxxxxx> writes: >>> >>>> Now that you mention it, the only command that completes >>>> --rerere-autoupdate is git-merge. Since this is "auto" I don't think >>>> people want to type manually. >>> >>> Sorry, but I do not quite get the connection between "since this is >>> 'auto'" and the rest of the sentence. Is it just it is so lengthy >>> that people do not want to type and are likely to use completion? >> >> Well, if it is to be done automatically, I should not need to tell it >> manually (by typing the option on command line). Granted it's a weak >> argument. > > Perhaps I am not reading what the option does correctly, but my > understanding is that merge operations: > > - always allow rerere to intervene and auto-resolve in the working > tree, as long as rerere is enabled; > > - by default they however do not add the rerere-resolved result to > the index, so that the combined diff output from "git diff" can > be used as a way to sanity check the result; but > > - if the user says --rerere-autoupdate, they add the > rerere-resolved result to the index, letting the user blindly > trust it, so that such a trusting user can even commit the result > without looking at it by merely making sure there is no path > remaining in the "git ls-files -u" output. > > The "autoupdate" could be somewhat dangerous depending on your > workflow, and that is why the user can selectively enable it via the > command line option (when known to be safe) even if the user does > not set rerere.autoupdate to true. > > So I am not sure I understand "an option to allow something to be > done automatically should not be given manually" as a valid argument > at all, whether it is weak or strong. > > Or am I grossly confused? Nope. It's just me not understanding rerere functionality. -- Duy
