On Wed, Nov 28, 2007 at 05:33:39PM -0500, J. Bruce Fields wrote: > 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.... Actually, considering the second point: people that are using fetch+rebase don't necessarily need or (for now) want to understand pull at all. But they certainly *do* have to understand rebase. Would it be possible to add this to rebase instead of to pull? git rebase --url git://x.org/x.git master where --url means "interpret <upstream> as a branch from the given remote repository. That interacts poorly with --onto, though. --b. - 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
