Possible new commands

[arxanas]

• git top/git bottom to traverse an entire series of commits. (Names need to be revised, since the ordering may be reverse of what's expected.)
  • Actually, these might be better as flags to git next/git prev.
  • Implemented in Add -a/--all flag to git next/git prev #191
• Interactive git checkout, operating on nodes on the smartlog graph. Could include fuzzy-filtering or EasyMotion-style commit selection.
  • Implemented in Interactive next/checkout #138.
• git move as a replacement for git rebase, to move entire subtrees. Proposal: --dest, --base, --restack, and --main flags.
• git sync XXX to rebase in-progress work onto main branch (or git sync --all, or git sync --onto).
• git stage to interactively stage a commit. Should see what tig does for this.
• git split to split the current commit (or a provided commit) using repeated git stages. Splitting should not check out to a different commit, since it shouldn't affect the working copy.
• git absorb (there's already an implementation of git absorb out there, but it doesn't work unless you have a branch checked out). Absorbing should not check out to a different commit, since it shouldn't affect the working copy.
• git amend to amend the current commit contents, but not its message. May automatically restack, or have an option to automatically restack?
  • Implemented in feat(amend): Initial amend command #170
• git reword to amend the current commit message, but not its contents. Should be able to safely automatically restack, since it doesn't touch the working copy.
  • Extracted to Implement a git reword command #179
• git uncommit as a replacement for git reset --soft HEAD^, since the latter is unergonomic, and it doesn't hide the given commit from the smartlog. It may be desirable to unstage the previously-committed changes as well; I've never personally wanted to keep them staged after a git reset --soft HEAD^.

[krobelus]

git absorb (there's already an implementation of git absorb out there, but it doesn't work unless you have a branch checked out).

https://github.com/torbiak/git-autofixup/ should do the job

[arxanas]

For a git absorb command, there's a good discussion here on how Mercurial does it: jj-vcs/jj#170. In particular, they use a weave-based strategy instead of a hunk-based strategy (as in git-absorb), which seems to produce better results. I don't know which strategy git-autofixup uses.

That being said, it would probably be easier to implement a hunk-based strategy, especially considering that git-absorb is already written in Rust and licensed permissively.

[epage]

I'm torn on the value of all of these functions. On one hand, they can be convenient, without even considering the value of preserving the commit tree (a lot of people have similar aliases). On the other hand, the larger the specialized ecosystem, the more disconnected people become from git and this starts to look like a different system than git (more like jj).

[arxanas]

Actually, all of these commands are just to get to parity with big-company Mercurial!

But personally, I think that Git has been stagnating on the user-interface front (and it was never particularly good there anyways), so major rethinkings are warranted. I don't think it's a problem to evolve Git into a source control system approaching Jujutsu.

[steveluscher]

I would love absorb. It’s like the last thing I miss from big-company Mercurial.

[claytonrcarter]

If we're voting for new commands, I would love to see some commands that allow more rebase-type actions directly on the command line, in-memory (if possble?) and without having to have the branch checked out. (Like how git move allows rebasing of branches while not checked out.) These come to mind:

• git drop <commit> as an in-memory equivalent for git rebase -i; <find commit in list>; <change command from picktodrop>; <save & quit>
• git squash <commit>..<commit> ... ditto, but for squashing/combining commits on the fly w/o having to drop in and out of an editor several times (first to set the plan, then to edit the commit message)
• git move --exact as mentioned at Support moving individual commits without their descendants #176

Complaining about rebase -i makes me feel really lazy 😄, but git move feels really frictionless, and bringing some of that joy to dropping and squashing would feel really great.

[claytonrcarter]

+1 for squash.

FYI this is in the works in #545. It should address the "final rebase requires a checkout" issue.

git query -r "roots($revset)" | xargs git reword "$revset - roots($revset)" --fixup

1. Don't forget to add roots($revset) as the argument to `--fixup
2. This works if the commits in your $revset is contiguous, so that that roots($revset) resolves to a single commit, but if root(...) could return multiple commits you may end up with problems.

I have been, uh, exploring this space a lot recently as I've been writing a script to clean up all of the repetitive commits created by git absorb. The revset that I came up to find the "rootiest root" so to say is:

    ROOT_QUERY="
        intersection(
            stack(),
            sole(
                roots(
                    intersection(
                        ancestors($revset),
                        descendants($revset)
                     )
                )
            )
        )
    "

[pokey]

FYI this is in the works in #545. It should address the "final rebase requires a checkout" issue.

awesome!! looking forward to that one 😊

1. Don't forget to add roots($revset) as the argument to `--fixup

that's what the xargs is doing 😊

This works if the commits in your $revset is contiguous

Ah right yeah hadn't thought about the fact that roots() could return something that is a descendent of another commit in the set of you have holes

Your query is neat, but I don't see why you intersect it with stack()

[claytonrcarter]

that's what the xargs is doing

Oh, of course! 🤦

I don't see why you intersect it with stack()

Just to prevent me from rewriting unintended commits by limiting the scope of $revset to my current working branch/stack. If $revset is crafted carefully enough, that wouldn't be needed.

commit to check out can't even be specified in terms of the original $revset because those commits have been rewritten

I had just recently thinking about a rewritten(...) revset fn that would resolve possibly rewritten/rebased commits into their most current SHA/version/location/whatever. This would allow something like git move -x abc123 && git reword 'rewritten(abc123)'.

[pokey]

Yeah I like rewritten

Tho some way of referring to the commits themselves would be even better, particularly if we introduced #551

I think the extended revset language above could work, or maybe having the move command have a --raw flag where it just outputs the new commits

[arxanas]

Mercurial calls the relevant functions predecessors and successors, although I'm not sure if they're one step or transitive.

@claytonrcarter instead of intersection(descendants(x), ancestors(y)) , you can use range or just write x:y.

[bsima]

git absorb and git split would be awesome, I definitely could have used both of these multiple times in the last week or two..