Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Known issues #1

Open
7 of 14 tasks
arxanas opened this issue Jan 12, 2021 · 0 comments
Open
7 of 14 tasks

Known issues #1

arxanas opened this issue Jan 12, 2021 · 0 comments
Labels
bug Something isn't working

Comments

@arxanas
Copy link
Owner

arxanas commented Jan 12, 2021

  • 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 git move enhancements #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.
  • 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.
  • 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.
  • 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 Align git undo view to corner #63.
  • Undo event view needs to take up less space. See Align git undo view to corner #63.
  • Some eyre::bail! calls can happen during normal operation. These should be fixed to use normal error messaging.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant