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.