Re: [PATCH v2] Teach 'git pull' about --rebase

> What they're really complaining about is the size and complexity of the
> interface, and the lack of a clearly identified subset for them to learn
> first.
> 
> This has so far mainly manifested itself in complaints about the number
> of commands, because that's currently where a lot of our complexity is.
> But they *will* complain about proliferation of commandline switches and
> config options too.  (I've heard complaints about the number of switches
> required on the average cvs commandline, for example.)
> 
> We're stuck expanding the interface here, whether we expand it by
> another command or another commandline switch.
> 
> So, how do you decide whether to make it a new command or not?
> 
> 	- Look at existing documentation that talks about pull: if that
> 	  documentation will still apply to the new pull, that weighs
> 	  for keeping it the same command.  If theat documentation would
> 	  apply only without having a certain config value set, then I
> 	  think it's better as a separate command.
> 
> 	- Will this make it more or less simple to identify the subset
> 	  of the git syntax that a user will have to do a given job?  If
> 	  there are jobs for which someone might only ever need the new
> 	  fetch+rebase, or for which they would only ever need the
> 	  traditional pull, then I think it would keep the two separate,
> 	  to make it easier for a learner to skip over information about
> 	  the one they're not using.
> 
> I've got no proposal for an alternate name.  All that comes to mind is
> the portmanteau "freebase", which is terrible....