av stack restack drops commits

[lzulauf]

This appears to happen if you try to split a branch containing two commits into two branches. If you first create the second branch with both commits, then switch to the first branch and git reset to drop the second commit, when you restack it will blow the commit away in the second branch as well.

I'm attaching a script that repro's the issue (in my case I also committed a followup change on the first branch - unclear if that's necessary to repro or not).
bug_repro.txt (it's a bash script)
bug_output.txt

[draftcode]

Communicated in a separate channel. Put the summary here.

---

In order to track stacks of branches, av keeps track of not only the parent branch, but also the commit where it's branched off. In your repro case, branch-1 parent is dev. branch-2 parent is branch-1 and branched off at Added B commit. With this structure, branch-1 has commits Added A and Added B, and branch-2 has no commits.

Then, when you do git reset --hard, it makes branch-1 to have Added A and branch-2 to have no commit. This is because av calculates which commit belong to which branch is based on the commit where it's branched off, not based on the parent branch currently points at. This in total when you run av stack restack, av thinks that branch-1 has Added A, branch-2 has no commit, and rebase in that way.

Now then you wonder why we track this "commit where a branch was branched off of".

Let's say a commit is amended on branch-1 instead of reset. In this case we have

* Added B (branch-2)
|
| * Added B and modified (branch-1)
|/
* Added A
|
* (dev)
*

In this setting, if av were implemented to calculate "which commit belong to which branch" based on the parent branch, it would think "Added A and Added B and modified belongs to branch-1, and Added B belongs to branch-2". From human's point of view, we can tell Added B and Added B and modified are the "same" commit. However av cannot tell that. They are the different commits. To avoid this, we track the "commit where a branch is branched off".

---

We can add more safeguard to this.

• Add an easy way to split the branch.
• Take a snapshot of the branches (e.g. Map<Branch, Commit>) before the av operations, so that when something happens, we can revive the branches without going through reflog (e.g. provide av rollback-previous-command to recover the branch state).
• If the branch has no commits that distinguish it from the parent branch, warn the user that they might not want to continue. (Heuristic)

[jainankit]

Also worth mentioning that to change the order of the branches, av stack reorder is probably a better way to avoid this scenario.

[Brookke]

We can add more safeguard to this.

• Add an easy way to split the branch.

I think my proposal here would help with this

#397 (comment)