Hello Ian, Please excuse the limited extent to which I've grokked `git debrebase`. Hopefully the questions in this e-mail will help move me along. If you want to see the extent of my understanding you might watch the recording of the "git and Debian packaging" BoF from DebConf17, where I attempt to explain `git debrebase` when someone asks me a question about it.
On Tue, Jul 18 2017, Ian Jackson wrote: > I think I had imagined to expose A, C and D to the user and to compute > the state B on demand during push. That means that git-debrebase is > only required when starting a rebase, or before pushing. (And if the > extra step is forgotten before pushing, the user is stopped by the > push ff check.) Good point that they would be warned by git's standard checks. debrebase needs to warn the user that they should expect to see non-ff push errors from git until they finish the debrebase. It might even leave behind a hook so that after the non-ff push error, there could be a hint about finishing the debrebase, but that might be too unpleasant to implement. > I think you are proposing to expose A, B and D to the user and to hide > C by somehow always reattaching a pseudomerge after each rebase. But > I don't think git-rebase can do that. Why not? > This means the user would have to use `git-debrebase --continue'. If > they ran `git-rebase --continue' instead they would end up in the > to-them-anomalous state C. This would not show up in `git status' > (because `git status' is not extensible). > >> In the case of a debrebase, there will never be any conflicts to >> resolve, > > This is not true for upstream changes. It is also not true if the > user used fixup! and --autosquash, or something. > > Ie, the user might do > git-debrebase -i --autosquash I don't understand this command. In my head, debrebase performs two atomic operations: (i) laundering the branch; and (ii) reattaching the pseudomerge before push. So what can `git debrebase -i --autosquash` mean? Does it mean "launder the branch, and then call `git rebase` with the options I passed?" I'm also confused about what `git debrebase --continue` could mean. (ii) will always end the debrebase, but `git rebase --continue` doesn't always end the rebase. Is this another case where debrebase is wrapping a plain rebase? If I'm on the right lines, it might be unwise to wrap `git rebase`. Git users are pretty good at that command; if we leave them to invoke it, they stand a better chance of understanding the whole workflow. But I'm not sure. > The other reason to expose this state to the user is that it is one > that many other git tools already understand. If the user wants to > try to use stg or gbp pq or god-knows-what, they need a branch without > merges. > > > Also: there is more. > > Much of the code in git-debrebase will be useful for downstreams too. > In particular, the automatic pseudomerge handling and perhaps the > stripping of debian/patches. > > I have one person already trying to do rebase-with-pseudomerges as a > downstream. I just read the IRC log you posted in another bug; thanks for that. -- Sean Whitton
signature.asc
Description: PGP signature
