On 2007.11.28 13:55:39 -0800, Junio C Hamano wrote: > "Lars Hjemli" <hjemli@xxxxxxxxx> writes: > > > On 11/28/07, Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. Hm, why not tackle the whole thing the other way around? IMHO the primary action is the merge/rebase, not the fetch. So choosing which action you want in addition to the fetch seems a bit backwards. git-svn already includes a fetch from svn in its rebase operation, which is really handy, because you rebase quite often with that beast. And it's likely that you want to merge with/rebase against the latest available remote commit all the time anyway and on the few(?) occassions where you have no connectivity, but already fetched some remote stuff which you want to incorporate into your local branches now, it's hopefully bearable to pass --no-fetch. So how about adding --fetch/--no-fetch (maybe with a configurable default?) to git-merge/git-rebase and deprecate git-pull over time? Björn - 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
