Hello, Just re-reading our older discussions about the UI, now that I understand git-debrebase a lot better.
On Sat, Sep 02 2017, Sean Whitton wrote: > I think that my concerns about failing to leverage user's existing > understanding of git-rebase(1) can be answered by doing the following: > > - state that git-debrebase(1) is ONLY: a wrapper around git-rebase(1) > that magically knows the base > - have ALL arguments to git-debrebase(1) get passed straight to > git-rebase(1), i.e., no subsubcommands > - move the other functionality (`git debrebase push`, new upstream > version command) to other subcommands of `git`, e.g. `git > debpush`, `git debnewupstream` etc. > > The point of this is to make it much easier to get a grip on exactly > what `git debrebase` does. That is a foundational piece of > understanding of the workflows surrouding these tools. > > It might seem inelegant to have multiple subcommands (especially `git > debpush` which sounds almost like `dgit push`) but I think that it's a > price worth paying. There's also a mnemonic at work: "ah, `git > debrebase` is a wrapper around `git rebase`, and `git debpush` is a > wrapper around `git push`". I think there's still something to this argument against git-debrebase having subcommands, but it's probably mitigated by the current content of dgit-maint-debrebase(7). If we find that users really struggle with grokking the workflow, we might reconsider splitting out subcommands in the future, after talking to them and trying to determine whether my hunch in the quoted message is right. -- Sean Whitton
signature.asc
Description: PGP signature
