On Wed, Oct 24, 2018 at 12:55:33AM -0700, David Aguilar wrote: > > So I think we should generally recommend against such generic names > > during the naming phase. At this point, I'm not sure the pain of > > changing now is any less than the pain of changing later if and when > > there's a conflict. > [...] > > Thanks for the recommendation. I'm open to changing the name in a > future major release. For users that already use the short "dag" name, > we can transition over to something else if it's relatively short and > sweet. Going from my paragraph above, I think it is probably OK to just leave it for now (unless you prefer to use a major version boundary to do the change rather than later possibly having to deal with it on a shorter timeframe). I have no real opinion on a replacement name. :) > There's also one more script, but it's never installed in the users's > $PATH and is more of an internal implementation detail. Git Cola > includes a GIT_SEQUENCE_EDITOR-compatible "git-xbase" command that > provides a visual interactive rebase feature. That command should > probably be renamed to "cola-git-seq-editor" to make that clearer, and > also to open up the possibility of installing it in bin/ in the future > since it is useful on its own. Yeah, agreed. If it's not in the PATH, then it doesn't need to be git-* at all, does it? > The rationale for two commands is that worktree diff+commit and history > inspection are our two primary use-cases. Everything else is provided > as a sub-command, "git cola rebase", "git cola stash", etc. so there's > not much pressure to add more top-level names, just these two. Makes sense. > Thoughts? Everything you said seems pretty reasonable to me. Thanks for being conscientious about the naming issues. -Peff
