Thread (4 messages) flat view 4 messages, 2 authors, 2016-06-15

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

From: Martin von Zweigbergk <hidden>
Date: 2016-06-15 22:50:34

On Tue, 15 Feb 2011, Santi B?jar wrote:
On Mon, Feb 14, 2011 at 1:51 PM, Martin von Zweigbergk
[off-list ref] wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help