Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> writes: > One thought that comes to mind -- perhaps it would be easier not to track the > special commit, but designate the branch as a special "proposed changes" > branch that could even "hide" the cover-letter merge commit (CLM) from most > operations. It's still a simple two-parent merge commit, so it can be > pushed/pulled with any existing remotes without requiring any changes on the > server side, but operations like adding a regular new commit to the tip of > the "proposed changes" branch would automatically move the merge commit so > it's back at the tip. This way "not sure what you're trying to do" situations > like this would be avoided: > > A--B--C--CLM--D--E > / / > Y----------- Sorry, you lost me. It is quite clear what the user is trying to do in this case. After preparing the initial cut of the topic that has three commits, A, B, and C, and writing about them in CLM, there were fix-ups and enhancements needed, which were implemented in D and E. The branch is waiting to be rebased into A--B--C--D--E--CLM' / / Y---------------- which gives you a chance to talk also about D and E in the updated iteration of CLM. Whether the "cover letter material in an empty commit at the tip" is a single-parent commit or a needless merge, there will be fallouts, such as "git branch --[no-]merged" becoming much less useful. I am sure there will be many others once we start seriously exploring these approaches.
