Here was my reasoning for the naming choice: - I need something meaningful - I need something that encompass the idea and features of a bug tracker because the narrower ideas and actions will be in sub commands - other projects already used other words, in particular "issue" - it kind of sounds and looks good You say that it's a namespace grab and I understand that, but in the other hand, there is not that much freedom when choosing a name. Sorry if I'm stepping on someone's toe :-| 2018-08-19 0:50 GMT+02:00 Jonathan Nieder <jrnieder@xxxxxxxxx>: > (cc-ing Elijah Newren for the points about merging) > Hi again, > > To avoid the other thread shadowing more important things: > > Michael Muré wrote: > >> Someone suggested in the Hacker News thread [0] to post it here as well. > > Thanks to Ævar for that. > > [...] >> git-bug use as identifier the hash of the first commit in the chain >> of commit of the bug. > > Clever! I like this approach to the naming problem. > > [...] >> Git doesn't provide a low-level command to rebase a branch onto >> another without touching the index. > > Thanks for pointing this out. There's been some recent work to make > Git's merge code (also used for cherry-pick) less reliant on the index > and worktree. See https://crbug.com/git/12 for some references. > There's also been some heavy refactoring of "git rebase" code to be in > C and be able to make use of library functions instead of being a > shell script. > > That's all to say that we're in a pretty good place to consider > introducing commands like > > git cherry-pick --onto=<branch> <revisions> > > In absence of that kind of thing, you can run commands that need to > touch the index (but not the working tree) by setting the GIT_INDEX > environment variable to point to a temporary index file. > >> I'd love to have some feedback from you. Contribution are also very >> much welcomed. > > Can you say more about the federation model it intends to support? > For example, do you imagine > > - having multiple copies of a git bugs repo that automatically fetch > updates from each other > > - having explicit "pull request" synchronization moments when the > owners of one copy of a bug tracker push or request a fetch of > changes that have been happening on another > > - individual contributors using an offline copy of the bug tracker > and pushing push/pull mostly to synchronize with a single > centralized copy > > - something else? > > Thanks, > Jonathan -- Michael
