git move cannot move remote commit as expected

[HAOCHENYE]

Description of the bug

Current Situation

I have two branches:

• Branch A (remote: origin/A): Commit history a <- b <- c
• Branch B: Commit history a <- d <- e

Expected Behavior

When using git move -s <b commit> -d <e>, I expected all descendants of the moved commit to be included.

Actual Behavior

The result is a <- d <- e <- b, with b's child commit c not being moved.

Question

Is this the intended behavior of the git move command? If not, could this be considered a bug?

Additional Context

• Parent commit: a
• Moved commits: b
• Destination: Commit e

Expected behavior

No response

Actual behavior

No response

Version of rustc

No response

Automated bug report

No response

Version of git-branchless

git-branchless-opts 0.10.0

Version of git

git version 2.34.1

[arxanas]

Hi @HAOCHENYE, thanks for asking. It'll be good to document this a little more clearly in case others encounter the same issue. This isn't a bug, exactly, but a deliberate limitation in the design. It's a tricky issue from a conceptual and practical perspective, and results in suboptimal UX in some cases.

Design

Recall that, in the Git object model, each commit points to its parents, and there are no edges in the opposite direction (from parent to child). Therefore, to find the children/descendants of a given commit, it means we need to start at every possible leaf node (Git ref) and traverse+index all the ancestors. (This matches the diagrams you drew with the parent pointers.)

For performance reasons, git-branchless indexes all local branches in this way on startup for each command, but doesn't index remote branches/refs at all. Many people fetch a lot of remote refs, corresponding to all the work that everyone else at their organization is doing, yet they tend to use very few of them in practice. The intended design is that git-branchless should scale linearly in the number of local branches, rather than the total number of refs.

In this case, there's no way for git-branchless to know what the descendant commits are, because it hasn't indexed them. For that reason, it doesn't rebase the remote branch's commits.

Default fetching

[aside] You could argue that it's a deficiency in the Git design to fetch everyone else's work all the time, even if you don't need it. However, you can see how it would be useful for primarily offline and decentralized development cases. You can configure this behavior in Git by setting your default fetch "refspec". I typically do this with new repositories/machines so that I only fetch the repository main branch and my own branches, which makes fetches faster. I explicitly fetch other users' branches when I want them. (Later versions of Git also support "partial clones" to perform lazy object downloads.)

Remote ref UX

[aside] Even if we indexed all remote commits, it's not practical in the general case from a UX perspective to mark all remote commits as "visible" and have them appear in the smartlog, etc. It would be too many commits and too messy/long for many users. git-branchless doesn't rebase commits that aren't visible.

Remote ref updating

[aside] It's generally inadvisable for tooling to update the commits that remote refs point to. They'll get out of sync with the "real" remote, which causes issues later with commands like git push --force-with-lease, because the local and remote refs point to different commits. In these cases, it's best to materialize a local branch and update where that branch points, and use normal Git collaboration mechanisms (pull/push/etc.) to deal with the local and remote branches getting out of sync.

Workaround

In this case, you should just create the local branch from the remote branch to start working on it. The simplest way should be git checkout B to create the local branch with remote-tracking info. Then git-branchless should also start indexing it and rebase commits in the way you expect. Let me know if that works for you.

[HAOCHENYE]

Thank you for your reply. In fact, I have already applied the workaround mentioned earlier to resolve this issue, and I fully agree with your points regarding the performance requirements and user experience concerns related to indexing remote references.

I'm not extremely well-versed in the underlying principles of Git, but the reason I used git move + remote ref was that I noticed git log <remote ref> allows me to see the commit ID and its parent nodes. Consequently, I naturally assumed that git-branchless could capture this information and successfully implement the move.

Anyway, hope this discussion might provide some inspiration for improving the git move experience.