Name commits

[dgp1130]

Hi, I just started playing around with git branchless (loving it so far). I always found the way Git manipulates branches to be very awkward and unintuitive, so I really like the branchless approach here. However, Git generally relies on branches to provide ergonomic names for manipulating commits. If we're going branchless, then I think we need a separate solution which allows short names to refer to specific parts of the graph. Since everything is based around commits, I think naming commits would be the right approach here. This might look like:

# Detached head.
$ git checkout main --detach

# Implement feature 1
$ git record --name feature-1
# Implement feature 2
$ git record --name feature-2
# Fix something from feature 1
$ git record --name feature-1-fix

# Look at the status
$ git sl
◇ 8e8883e 59s (main) Initial commit.
┃
◯ 3fe2a54 53s (feature-1)
┃
◯ 91d1177 53s (feature-2)
┃
● de0f282 53s (ᐅ feature-1-fix)

# Move fix onto feature-1.
$ git move -s feature-1-fix -d feature-1
$ git sl
◇ 8e8883e 59s (main) Initial commit.
┃
◯ 3fe2a54 53s (feature-1)
┣━┓
┃ ● de0f283 41s (ᐅ feature-1-fix)
┃
◯ 91d1177 53s (feature-2)

Since commits are named, we don't need to use hashes to refer to things and the name is retained even when the hash changes. This allows the user to think more in terms of commits and less in terms of branches. Combined with empty commit messages it makes speculative commits much more ergonomic.

git sw kind of attempts to solve this by making commit messages more easily searchable and works reasonably well combined with git next and git prev. But all those are restricted to git checkout. Naming commits is much more flexible since it allows them to be referenced in any other operation (such as git move in this case). I think it makes a great primitive to build the rest of the system upon.

I only just started with git branchless, so maybe there is already a way to do this. I wasn't able to find anything in issues or discussions so I figured I'd suggest it here. I've used a pattern like this before at an internal VCS and really enjoyed it, so I would love to find a way to port that model into Git, and git branchless is the closest I've seen to these ideas.

[arxanas]

Welcome @dgp1130! In this case, it seems best to continue to use branches. For example, you can pass -c/--create to git record to create a new branch. Then you can continue to use git move using branch names, and the branch pointers will also be updated, like in your example.

The main problem is probably that branches are updated when you make a new commit. In those cases, you'll want to detach the branch before you switch to the commit (with e.g. -d/--detach to git sw) or detach the branch with -d/--detach as part of the git record invocation. You might also want to review the branchless.navigation.autoSwitchBranches option to ensure you don't accidentally switch to branches as part of other navigation commands.

[dgp1130]

Thanks @arxanas! I can see how branches can kind of serve this need in combination with -d to avoid advancing the currently checked out branch. git record --create my-feature -d sounds like what I want, though --create / -c doesn't seem to exist for git record?

$ git add . && git record --create foo -d
error: Found argument '--create' which wasn't expected, or isn't valid in this context

Usage: git-branchless record [OPTIONS]

For more information try '--help'

$ git branchless record --help
Create a commit by interactively selecting which changes to include

Usage: git-branchless record [OPTIONS]

Options:
  -C <WORKING_DIRECTORY>
          Change to the given directory before executing the rest of the program. (The option is called `-C` for symmetry with Git.)

  -m, --message <MESSAGE>
          The commit message to use. If not provided, will be prompted to provide a commit message interactively

      --color <COLOR>
          Flag to force enable or disable terminal colors

          Possible values:
          - auto:
            Automatically determine whether to display colors from the terminal and environment variables. This is the default behavior
          - always:
            Always display terminal colors
          - never:
            Never display terminal colors

  -i, --interactive
          Select changes to include interactively, rather than using the current staged/unstaged changes

  -d, --detach
          Detach the current branch before committing

  -h, --help
          Print help information (use `-h` for a summary)

It seems like this recently changed, but I'm on 0.6.0.

$ git branchless --version
git-branchless 0.6.0

I'm a little worried that leveraging branches like this might be easy to accidentally misuse. For example, a forgotten -d might inadvertently advance the wrong branch. I'd have to play with it for real to see how hard it is to mess up with this approach.