Topic: The future of history rewriting
Leader: Phillip Wood
11:30am-12:00pm PT
* Number of methods of history rewriting
* What do we want the future UI and operations to look like and be easy
* Want good commit histories
* JJ always in Elijah's edit mode demo, always interactive rebase.
* Always easy to rewrite commits.
* Always rebase descendants
* Use commands instead of verbs on rebase command
* Git would have a hard time adopting the ‘always rebasing' model
* For new users, git rebase is too complicated for simple use cases.
* Top level commands to easily do common operations
* ‘Git history'?
* Git history vs git replay
* Replay is plumbing used by server.
* History is porcelain used by user.
* Elijah - Building on rebase depends on sequencer
* Underpinnings more important than naming
* Lots of backwards compatibility assumptions
* Hooks and dependencies are pervasive, hard to clean up.
* When update-refs was added, it broke hooks
* Don't want to keep doing that.
* Wants to move beyond sequencer (git history uses sequencer)
* Sequencer frequently updates the work tree, not desirable
* Git history can move to use Git replay
* A cleaner version of git history would be nice so others can try it out
* Git replay is lacking features needed for git history
* Trying landing experimental version with sequencer underpinnings
* No promise of compatibility
* Phillip - users noticed when he broke Sequencer Hooks
* Disable hooks with flags?
* Way forward - land UI then iterate on underpinnings?
* Sequencer depends on shell parseable state files
* Lots to cleanup
* Minh - does this help solve problem of server rewriting history (ie force
push), leaving clients with incompatible forks?
* Out of scope
* Maybe change id is the more relevant conversation
* Conversation ended up on ChangeID
* Change ID loses predecessor tracking, which is more precise
* Hard to propagate without Mercurial style logs
* Mercurial predecessor graphs are independent of commits
* Change IDs would also help with first class conflicts
* Finding range-diffs is cheaper
* Range-diffs used fairly widely
* Git, rust, most mailing list flows
* Change IDs useful for tracking across repos, bugs, etc.
* Why are change IDs stalled in the mailing list?
* Disagreement on tracking predecessors
* Requires a protocol change
* Sending predecessors over protocol has lots of implications
* Gitster - disagreement on what it means to be a predecessor
* Parent? Cherrypick?
* Brian - changeId should be deterministic. Reject non-well formed ids
* Workflows rely on repetition
* ChangeIds should be optional, disableable.
* May track too much information unintentionally across commits, projects.
* Gitster - needs to be possible to expose changeId, predecessor without
exposing private information about private repos.
* ChangeID exposes less than predecessors do
* JJ can't access predecessors from ChangeID
* When rewriting commits, maybe we don't want the predecessor to be
viewable (eg secret keys)
* JJ can bump changeId when rewriting
* Gerrit keeps ChangeID in commit body
* Rebase and Cherrypick don't support arbitrary key:value pairs in commit
body
* ChangeID should propagate to be useful
* Eg across mailing list
* Can Git more generally and globally support headers in the commit?
* ChangeID should be more 1st class than other headers.
* Hard for client to tell when a ChangeID should change.
* Recent JJ commits were pushed with ChangeIDs
* Colleague branched off. Rewriting ids would have been useful.
* Squashes, amends etc lead to ambiguity about which ChangeID to keep.
* JJ keeps the parent.
* Gitster thinks it would be nicer for ChangeIDs to be kept even when
there are 2.
* When commits split, the children get 2 new ChangeIDs instead of keeping
old one.
Taylor Blau <me@ttaylorr.com>