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

Re: rebase flattens history when it shouldn't?

From
HHHolger Hellmuth <hellmuth@ira.uka.de>
Date
Aug 6, 2014, 15:09 UTC
Message-ID
<53E2452D.6000109@ira.uka.de>
In-Reply-To
<8738drj2fc.fsf@osv.gnss.ru>
On 23.07.2014 21:33, Sergei Organov wrote:
> What actually bothers me is the unfortunate consequence that "git pull"
> is not always a no-op when nothing was changed at the origin since the
> last "git pull". THIS is really surprising and probably should better be
> fixed. Requiring -f is just one (obvious) way to fix this.

That would invalidate the simple rule that "git pull" is equivalent to "git fetch" + "git rebase".

git rebase depends on both branches it operates on, not just one. The same goes for "git merge", I assume it is just a coincidence that git merge does have this characteristic you now expect both to have.

Previous: Sergei OrganovNext: Sergey Organov
Message 4 of 6 in “rebase flattens history when it shouldn't?”
  1. Sergei OrganovJul 23, 2014
  2. Jonathan NiederJul 23, 2014
  3. Sergei OrganovJul 23, 2014
  4. Holger HellmuthAug 6, 2014
  5. Sergey OrganovAug 6, 2014
  6. Sergey OrganovAug 6, 2014

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.