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

Re: Pull --rebase looses merge information

From
Iin-gitvger@baka.org <in-gitvger@baka.org>
Date
Oct 6, 2011, 20:31 UTC
Message-ID
<201110062031.p96KVvsv018248@no.baka.org>
In-Reply-To
<DECF417E-50BB-4963-965C-BEF1B5C95DAC@mac.com>
In message <DECF417E-50BB-4963-965C-BEF1B5C95DAC@mac.com>, Duane Murphy writes:
    $ git merge topic
    $ git pull 
        merge by rebase; implied by config
    $ git push
    The result of this process is that the file changes are pushed but
    the reference back to the topic branch has been lost. This makes
    it appear as though the topic branch has not been merged properly.
[...]
    Is there a bug here? Is there some way to avoid this situation
    without sacrificing the benefits of pull --rebase?
Yes, but it currently is annoying.

Instead of `git pull --rebase` you need to run `git fetch && git rebase -p @{u}`

It would be very nice if the -p argument to rebase could be automatically included in the `git pull --rebase`.

I personally believe all pull should be --rebase, all merges should be --no-ff, and all rebases should be -p. At least by default. But that is just me.

					-Seth Robertson
Previous: Duane MurphyNext: Philippe Vaucher
Message 2 of 3 in “Pull --rebase looses merge information”
  1. Duane MurphyOct 6, 2011
  2. in-gitvger@baka.orgOct 6, 2011
  3. Philippe VaucherOct 7, 2011

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.