On Wed, Nov 28, 2007 at 09:58:52PM +0000, Johannes Schindelin wrote:
quoted text
> Hi,
> 
> On Wed, 28 Nov 2007, Junio C Hamano wrote:
> 
> > "Lars Hjemli" <hjemli@gmail.com> writes:
> > 
> > > On 11/28/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >> On Wed, 28 Nov 2007, Steven Grimm wrote:
> > >> > I wonder if this shouldn't be branch.<name>.pulltype or something like
> > >> > that, so we can represent more than just "rebase or not." Values could
> > >> > be "rebase", "merge" (the default) and maybe even "manual" to specify
> > >> > that git-pull should neither merge nor rebase a particular branch even
> > >> > if it matches a wildcard refspec.
> > >>
> > >> I am not convinced that this is a good thing... We already have
> > >> branch.<name>.mergeOptions for proper merges, and I want to make clear
> > >> that this is about rebase, and not about merge.
> > >
> > > Maybe branch.<name>.pullOptions ?
> > 
> > Maybe not make this part of git-pull at all?  merge and rebase have
> > totally different impact on the resulting history, so perhaps a separate
> > command that is a shorthand for "git fetch && git rebase" may help
> > unconfuse the users.
> 
> Not so sure about that.  We already have too many commands, according to 
> some outspoken people, and this would add to it.

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....

--b.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html