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

Re: [PATCH] rebase: be cleverer with rebased upstream branches

From
SBSanti Béjar <santi@agolina.net>
Date
Feb 16, 2011, 09:26 UTC
Message-ID
<AANLkTim_0omhFW-jVRqC8TgrG7vux2-X3k1o6RFaRf0b@mail.gmail.com>
In-Reply-To
<alpine.DEB.2.00.1102151940140.7843@debian>

On Wed, Feb 16, 2011 at 1:37 AM, Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> wrote:

Show 25 quoted lines
> On Tue, 15 Feb 2011, Santi B?jar wrote:
>
>> On Mon, Feb 14, 2011 at 1:51 PM, Martin von Zweigbergk
>> <martin.von.zweigbergk@gmail.com> wrote:
>> > It might seem like most of the related code in git-pull.sh can be
>> > removed once git-rebase.sh supports reflog walking. Unfortunately, not
>> > much of it can be removed, though. The reason is that git-pull.sh
>> > simulates one step of "reflog walking" by keeping track of the
>> > position of the remote-tracking branch before and after the fetch
>> > operation. This does not rely on reflogs. There are at least two cases
>> > where the reflog is not used: a) when it is disabled, b) when the
>> > remote branch was specified on the command line (as in 'git pull
>> > --rebase origin master').  In both of these cases, git-pull.sh
>> > remembers the position of the reference before the fetch and uses that
>> > as a kind of '$upstream@{1}'.
>>
>> I don't agree with point b). In line 190:
>>
>>       remoteref="$(get_remote_merge_branch "$@" 2>/dev/null)" &&
>>
>> It returns the local tracking branch for repo=origin and branch=master
>> and uses its reflog.
>
> Yes, but the local tracking branch is not updated when the
> two-argument version of 'git pull' is used [1].

Yes, but the reflog is used nevertheless and it can use the local tracking branch as the old-remote-hash.

Show 7 quoted lines
>
>> The end result is the same, there is one case where you need the old
>> value of the tracking branch, so it should be done in git-pull.
>
> True, case a) is still there. I was just trying to explain why I
> didn't just move the code from git-pull.sh to git-rebase.sh, but maybe
> it confused more than it clarified...
Yes, with only case a) is sufficient (and complete).

HTH, Santi

Previous: Martin von ZweigbergkNext: Junio C Hamano
Message 4 of 19 in “rebase: be cleverer with rebased upstream branches”
  1. rebase: be cleverer with rebased upstream branchesMartin von Zweigbergk, Feb 14, 2011
  2. Santi BéjarFeb 15, 2011
  3. Martin von ZweigbergkFeb 16, 2011
  4. Santi BéjarFeb 16, 2011
  5. Junio C HamanoFeb 15, 2011
  6. Martin von ZweigbergkFeb 16, 2011
  7. Santi BéjarFeb 16, 2011
  8. Santi BéjarFeb 16, 2011
  9. Junio C HamanoFeb 16, 2011
  10. Santi BéjarFeb 16, 2011
  11. Martin von ZweigbergkFeb 16, 2011
  12. Santi BéjarFeb 17, 2011
  13. Martin von ZweigbergkMar 12, 2011
  14. Santi BéjarMar 12, 2011
  15. Martin von ZweigbergkMar 13, 2011
  16. Martin von ZweigbergkMar 13, 2011
  17. Junio C HamanoMar 13, 2011
  18. Santi BéjarMar 13, 2011
  19. Santi BéjarMar 13, 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.