On Fri, Mar 18, 2016 at 11:17 AM, Mehul Jain <mehul.jain2029@xxxxxxxxx> wrote: > On Fri, Mar 18, 2016 at 10:09 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: >> Actually, this is going to pass --autostash or --no-autostash to >> git-rebase unconditionally won't it? This seems kind of undesirable >> due to the unnecessarily tight coupling it creates between the two >> commands. I wasn't paying close attention to the earlier discussion, >> but wasn't the idea that you should pass one of these two options >> along to git-rebase only if the user explicitly asked to do by saying >> so on the command line? > > This is interesting. I checked out git-rebase.sh and found that it reads > rebase.autoStash if nothing is specified by user. So if user is not > specifying anything about stashing then it is the job of git-rebase > to decide whether or not to do stashing by reading rebase.autoStash. > > Similarly if user doesn't specify the --[no-]autostash option to git-pull > then neither of --autostash and --no-autstash should be passed to the > git-rebase as it will decide on his own about what needs to be done. > Agreed. I made a unnecessary tight coupling between git-pull and > git-rebase. Instead of that the following changes can be done to > remove it. > > This way there's no need to remove "autostash" from the current code > base and instead use it to write a much cleaner patch. Something like > this (this is w.r.t. current code base) > [...] > > What are your views on this? I think this makes the patches cleaner and the final code nicer, and it eliminates the too-tight coupling between the two commands, so it seems to be a win overall. -- 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