arxanas / git-branchless

High-velocity, monorepo-scale workflow for Git

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Known issues

arxanas opened this issue · comments

  • Restacking a stick produces spurious abandoned commit warnings. The child commit is abandoned, but it's immediately restacked in the next step, so this is an unnecessary warning. This would be easier to suppress if transactions were implemented.
  • When abandoning a commit, the "this operation abandoned X commits" only counts immediate descendants, not all un-hidden descendants. This can be confusing since it oftentimes doesn't convey the magnitude of the abandonment.
  • When rewriting a public commit (pointed to by the remote main branch), a warning that the remote branch has been abandoned is produced. This warning should probably only apply to local branches.
  • git next doesn't complain if you try to go ahead more commits than exist. (Instead, it just goes to the last possible commit.) There should probably be a specific flag to go the maximum number of commits forward instead.
  • When rebasing a sequence of commits from a source to a destination, if some commit are already in the destination, they are not applied again. In this case, the source commits remain visible in the smartlog, but they should be hidden (since they were logically rewritten into the destination commits).
    • Actually, if any commits are dropped altogether during a regular interactive rebase, they aren't detected, so they still appear in the smartlog.
    • In my opinion, it's a bug in the specification or implementation of the post-rewrite hook. There is no way to recover the knowledge of which commits were dropped after the fact.
    • Extracted to #34.
  • git branchless init should autodetect the main branch name. For example, if there is no branch named master in the current repository, but there is a branch named main, then we should automatically configure branchless to use main in that case.
    • Addressed in #31.
  • git reset with --soft/--hard leaves the old commit in the smartlog. It would probably be best to remedy this by adding additional primitives which solve the use-cases for git reset, such as git split and/or git uncommit commands.
  • Aborted git rebases leave any applied commits in the smartlog.
  • Hook installation assumes that the present hook, if any, is written in shell. It could be made language-agnostic by moving the old hook and invoking it after our hook is done. Also, I bet the hook update code is buggy.
    • Nobody has reported any problems with this so far, and it's expected to appear in a future version of Git, so maybe not worth fixing ourselves. See discussion at #116 (comment).
  • git undo returns you to a historical commit, but doesn't check out the appropriate branch attached to that commit, if any. Fixing this requires a database schema change.
  • git restack loops forever for some merge commits.
    • Addressed in #33.
  • Need to establish some solid terminology around "history" in the documentation, which makes it clear whether we are referring to the history of the code (expressed by commits) or the history of the commit graph (expressed by the event log). See #63.
  • Undo event view needs to take up less space. See #63.
  • Some eyre::bail! calls can happen during normal operation. These should be fixed to use normal error messaging.