Re: git-bug: Distributed bug tracker embedded in git

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 [off-list ref]:

(cc-ing Elijah Newren for the points about merging)
Hi again,

To avoid the other thread shadowing more important things:

Michael Muré wrote:

quoted

Someone suggested in the Hacker News thread [0] to post it here as well.

Thanks to Ævar for that.

[...]

quoted

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.

[...]

quoted

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.

quoted

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