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

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

From
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Date
Feb 16, 2011, 01:37 UTC
Message-ID
<alpine.DEB.2.00.1102151940140.7843@debian>
In-Reply-To
<AANLkTi=1WkZXBtQu71mELTBc6F7XrfBi+NWNWy-AxS79@mail.gmail.com>
On Tue, 15 Feb 2011, Santi B?jar wrote:
Show 20 quoted lines
> 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].
 
> 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...

> But I wonder if it is possible to write a function shared by
> git-pull.sh and git-rebase.sh that computes the branch forking points,
> the number of arguments could detect if it has the old-remote-hash or
> not.
Makes sense. I will have a look at it.
> I think the delay could be much shorter if the computation was not in
> shell, but in C. Or maybe change the algorithm. So I don't think a
> configuration item is the answer here.

It would definitely be nice if we can make it fast enough so we don't have to make it configurable.

[1] http://thread.gmane.org/gmane.comp.version-control.git/165758
Previous: Santi BéjarNext: Santi Béjar
Message 3 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.