git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Björn Steinbrink <b.steinbrink@gmx.de>
Date
Dec 1, 2007, 20:37 UTC
Message-ID
<20071201203759.GA11710@atjola.homenet>
In-Reply-To
<7vhcj63uhw.fsf@gitster.siamese.dyndns.org>
On 2007.11.28 13:55:39 -0800, Junio C Hamano wrote:
Show 20 quoted lines
> "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.

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
Previous: Johannes SchindelinNext: Karl Hasselström
Message 29 of 32 in “Teach 'git pull' the '--rebase' option”
  1. Teach 'git pull' the '--rebase' optionJohannes Schindelin, Oct 25, 2007
  2. Linus TorvaldsOct 25, 2007
  3. Johannes SchindelinOct 25, 2007
  4. Linus TorvaldsOct 25, 2007
  5. Linus TorvaldsOct 25, 2007
  6. Junio C HamanoOct 25, 2007
  7. Johannes SchindelinOct 26, 2007
  8. Junio C HamanoNov 28, 2007
  9. Teach 'git pull' about --rebaseJohannes Schindelin, Nov 28, 2007
  10. Jonathan del StrotherNov 28, 2007
  11. Johannes SchindelinNov 28, 2007
  12. Jakub NarebskiNov 28, 2007
  13. Steven GrimmNov 28, 2007
  14. Johannes SchindelinNov 28, 2007
  15. Lars HjemliNov 28, 2007
  16. Junio C HamanoNov 28, 2007
  17. Johannes SchindelinNov 28, 2007
  18. Steven GrimmNov 28, 2007
  19. J. Bruce FieldsNov 28, 2007
  20. J. Bruce FieldsNov 28, 2007
  21. Johannes SchindelinNov 28, 2007
  22. Junio C HamanoNov 28, 2007
  23. J. Bruce FieldsNov 28, 2007
  24. Johannes SchindelinNov 29, 2007
  25. Andreas EricssonNov 29, 2007
  26. Nicolas PitreNov 29, 2007
  27. Jon LoeligerNov 28, 2007
  28. Johannes SchindelinNov 28, 2007
  29. Björn SteinbrinkDec 1, 2007
  30. Karl HasselströmDec 3, 2007
  31. Jeff KingOct 26, 2007
  32. Jeff KingOct 26, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.