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
Each commit knows what its parents and children are in the database. In theory, we could have the "next" and "previous" buttons that toggle through commits allow choosing between multiple children/parents for merge/branch commits. This is relatively easy. Harder would be to make the list views of commits allow for walking the true structure, since a graph can't really be mapped cleanly to a list.
Any thoughts on what would be a more useful linear organization of commits? Currently we just sort by commit time in a single branch, but after a different branch is merged in, all of its commits become part of the mainline branch, and time-ordering does not guarantee that one commit is a parent of the next in the list.
The text was updated successfully, but these errors were encountered:
I think just sticking with next/previous (following parent/child links) but when you get to a merge point then there would be two previous buttons.
git rev-parse HASH^@
gets you the commit hashes of all the parents. I don't think we'll want general merges anyway so for now we can sweep the problem away and not handle merges (only fast forward merges which put everything at the head commit)
Each commit knows what its parents and children are in the database. In theory, we could have the "next" and "previous" buttons that toggle through commits allow choosing between multiple children/parents for merge/branch commits. This is relatively easy. Harder would be to make the list views of commits allow for walking the true structure, since a graph can't really be mapped cleanly to a list.
Any thoughts on what would be a more useful linear organization of commits? Currently we just sort by commit time in a single branch, but after a different branch is merged in, all of its commits become part of the mainline branch, and time-ordering does not guarantee that one commit is a parent of the next in the list.
The text was updated successfully, but these errors were encountered: