You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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.post-rewrite
hook. There is no way to recover the knowledge of which commits were dropped after the fact.git move
enhancements #34.git branchless init
should autodetect the main branch name. For example, if there is no branch namedmaster
in the current repository, but there is a branch namedmain
, then we should automatically configure branchless to usemain
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 forgit reset
, such asgit split
and/orgit uncommit
commands.git rebase
s leave any applied commits in the smartlog.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.restack
appears to enter infinite loop when it encounters a merge conflict #33.git undo
view to corner #63.git undo
view to corner #63.eyre::bail!
calls can happen during normal operation. These should be fixed to use normal error messaging.The text was updated successfully, but these errors were encountered: