3 ms·

>You may think auto-sync will completely ruin your familiar “commit now, restructure later” workflow. It will not. As you’re working in your branch, you can sti

>You may think auto-sync will completely ruin your familiar “commit now, restructure later” workflow. It will not. As you’re working in your branch, you can still reorganise, restructure, reorder and rename commits in your branch. These changes will be incrementally synced to all other peoples’ machines as you go. They’ll initially see your mess, but then they’ll see all the changes you’re doing to make your branch look pretty. All happening without any manual button clicking/remotes selections/any other decisions from them. As this branch is yours, it’s a perfectly safe and does not require any human intervention. One of the biggest missed opportunities with git is metadata about rebase and history-rewrite operations. If git stuck that information into the log it would be trivial for clients to understand that these commits appear to have different hashes only due to a rebase. The client could even compute the deltas from both tress to compare the supposedly "common" commits, validating that they really are the same (or maybe allow slightly differences to account for rebasing). If the commits claim to have the same ancestry but different deltas it would be up to you to accept your peer's work or to go review/merge. No more "2 down / 5 up" commits because of a rebase; instead you'd see "3 new (2 rebased)".

jcranmer 10y ago
> One of the biggest missed opportunities with git is metadata about rebase and history-rewrite operations. If git stuck that information into the log it would be trivial for clients to understand that these commits appear to have different hashes only due to a rebase. The client could even compute the deltas from both tress to compare the supposedly "common" commits, validating that they really are the same (or maybe allow slightly differences to account for rebasing). If the commits claim to have the same ancestry but different deltas it would be up to you to accept your peer's work or to go review/merge. This is ripe for flaming, but this is how mercurial handles rebasing under changeset evolution, and it's pretty much the biggest area where hg gets something right that git got wrong. Basically, it keeps around the old changeset of the rebase and adds a new kind of edge to indicate the update of the rebase, as well as keeping the obsolete changesets from being seen by most users while maintaining them internally. This means that normal rebase operations can see the old and new versions of a changeset as if they were regular changesets. Combined with phases, it's also easy to set up your repositories so that you can never accidentally rebase your master branch.

jcranmer 10y ago

> One of the biggest missed opportunities with git is metadata about rebase and history-rewrite operations. If git stuck that information into the log it would be trivial for clients to understand that these commits appear to have different hashes only due to a rebase. The client could even compute the deltas from both tress to compare the supposedly "common" commits, validating that they really are the same (or maybe allow slightly differences to account for rebasing). If the commits claim to have the same ancestry but different deltas it would be up to you to accept your peer's work or to go review/merge. This is ripe for flaming, but this is how mercurial handles rebasing under changeset evolution, and it's pretty much the biggest area where hg gets something right that git got wrong. Basically, it keeps around the old changeset of the rebase and adds a new kind of edge to indicate the update of the rebase, as well as keeping the obsolete changesets from being seen by most users while maintaining them internally. This means that normal rebase operations can see the old and new versions of a changeset as if they were regular changesets. Combined with phases, it's also easy to set up your repositories so that you can never accidentally rebase your master branch.