git-bug: Distributed bug tracker embedded in git

git-bug: Distributed bug tracker embedded in git

[Michael Muré]

Hi everyone,

I released today git-bug, a distributed bug tracker that embeds in
git. It use git's internal storage to store bugs information in a way
that can be merged without conflict. You can push/pull to the normal
git remote you are already using to interact with other people. Normal
code and bugs are completely separated and no files are added in the
regular branches.

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

The project is here [1].

It's a all-in-one binary that is picked up by git as a porcelain
command. It features a set of CLI command for simple interaction, an
interactive terminal UI and a rich web UI.

For more information about the internal design, please read this
document [2]. In short, bugs are stored as a series of edit operations
stored in git blobs and assembled in a linear chain of commits. This
allow to have conflict-free merge and to not pollute the regular
branches with bug data. Media embedding is also possible but not yet
finished.

I'd love to have some feedback from you. Contribution are also very
much welcomed.

Best regards,

[0]: https://news.ycombinator.com/item?id=17782121
[1]: https://github.com/MichaelMure/git-bug
[2]: https://github.com/MichaelMure/git-bug/blob/master/doc/model.md

-- 
Michael Muré

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

[Tacitus Aedifex]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit; format=flowed, Size: 366 bytes --]

I really like this idea. I've often wanted an integrated bug database like 
this. My solution has always been to have a subrepo storing bug reports and 
coments in .txt files and then using bash porcelain scripts to make a git-like 
interface. I think I like this better. My only nit is Go. That makes me sad.  
Someone should re-implement this in C or Rust.

//tæ

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

[Jonathan Nieder]

Hi,

Michael Muré wrote:

> I released today git-bug, a distributed bug tracker that embeds in
> git. It use git's internal storage to store bugs information in a way
> that can be merged without conflict. You can push/pull to the normal
> git remote you are already using to interact with other people. Normal
> code and bugs are completely separated and no files are added in the
> regular branches.

I am a bit unhappy about the namespace grab.  Not for trademark
reasons: the Git trademark rules are pretty clear about this kind of
usage being okay.  Instead, the unhappiness comes because a future Git
command like "git bug" to produce a bug report with appropriate
diagnostics for a bug in Git seems like a likely and useful thing to
get added to Git some day.  And now the name's taken.

Is it too late to ask if it's possible to come up with a less generic
name?

Separately from that, I'm happy to see progress being made in the
distributed bug tracker world; thanks for that!

Thanks,
Jonathan

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

[Ævar Arnfjörð Bjarmason]

On Sat, Aug 18 2018, Jonathan Nieder wrote:

> Hi,
>
> Michael Muré wrote:
>
>> I released today git-bug, a distributed bug tracker that embeds in
>> git. It use git's internal storage to store bugs information in a way
>> that can be merged without conflict. You can push/pull to the normal
>> git remote you are already using to interact with other people. Normal
>> code and bugs are completely separated and no files are added in the
>> regular branches.
>
> I am a bit unhappy about the namespace grab.  Not for trademark
> reasons: the Git trademark rules are pretty clear about this kind of
> usage being okay.  Instead, the unhappiness comes because a future Git
> command like "git bug" to produce a bug report with appropriate
> diagnostics for a bug in Git seems like a likely and useful thing to
> get added to Git some day.  And now the name's taken.
>
> Is it too late to ask if it's possible to come up with a less generic
> name?

Wouldn't we call such a thing "git-reportbug", or "git gitbug", with
reference to Debian reportbug or perl's perlbug?

Addressing the more general issue, if we're concerned with 3rd party
tools usurping the core namespace trying to convince individual authors
of 3rd party tools to change the names of those tools to something more
unique is pissing in the wind.

That's never going to make a dent in the vast amount of git-whatever
tools, most of which won't be discussed as ideas on this mailing list
before they're released.

I think we basically have these options:

1) Accept the status quo where people do create third party tools, much
   of which are way too obscure to matter (e.g. I'm sure someone's
   created a tool/alias called range-diff before, but we didn't
   care).

   If those tools become popular enough in the wild they get own that
   namespace, e.g. we're not going to ship a "git-annex" or "git-lfs"
   ourselves implementing some unrelated features (re parallel on-list
   discussion; "git annex" could also be a "git commit --amend" alias).

2) #1, but hope we catch new tools early enough to convince their
   authors to change the names.

3) Make some structural change to git where only things we ourselves
   compile get to be called as "git <whatever>", and you'd need to call
   e.g. "git-bug" as "git ext::bug" or something. We'd need to have a
   large hardcoded list of older tools (lfs, annex, ...) to grandfather
   in if we went for this approach.

I think we should just go for #1, and if we're concerned about #1 not
being OK we really need something like #3, because #2 isn't going to
work.

> Separately from that, I'm happy to see progress being made in the
> distributed bug tracker world; thanks for that!
>
> Thanks,
> Jonathan

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

[Jonathan Nieder]

Hi,

Ævar Arnfjörð Bjarmason wrote:
> On Sat, Aug 18 2018, Jonathan Nieder wrote:
>> Michael Muré wrote:

>>> I released today git-bug, a distributed bug tracker
[...]
>> I am a bit unhappy about the namespace grab.  Not for trademark
>> reasons: the Git trademark rules are pretty clear about this kind of
>> usage being okay.  Instead, the unhappiness comes because a future Git
>> command like "git bug" to produce a bug report with appropriate
>> diagnostics for a bug in Git seems like a likely and useful thing to
>> get added to Git some day.  And now the name's taken.
>>
>> Is it too late to ask if it's possible to come up with a less generic
>> name?
>
> Wouldn't we call such a thing "git-reportbug", or "git gitbug", with
> reference to Debian reportbug or perl's perlbug?

I hope you're kidding about "git gitbug".

[...]
> 1) Accept the status quo where people do create third party tools, much
>    of which are way too obscure to matter (e.g. I'm sure someone's
>    created a tool/alias called range-diff before, but we didn't
>    care).
>
>    If those tools become popular enough in the wild they get own that
>    namespace, e.g. we're not going to ship a "git-annex" or "git-lfs"
>    ourselves implementing some unrelated features

That's fair.  Let me spell out my thinking a little more.

This framework would lead me to rephrase my question to Michael a
different way.  Instead of saying that I'm not happy with the
namespace grab, I should say something more severe:

  Don't be surprised if Git itself makes a "git bug" command in the
  future, and be prepared to rename.

Is that preferable, in your opinion?

I still think it's a reasonable thing for me to ask about, if only to
save Michael some trouble later.

Thanks,
Jonathan

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

[Ævar Arnfjörð Bjarmason]

On Sat, Aug 18 2018, Jonathan Nieder wrote:

> Hi,
>
> Ævar Arnfjörð Bjarmason wrote:
>> On Sat, Aug 18 2018, Jonathan Nieder wrote:
>>> Michael Muré wrote:
>
>>>> I released today git-bug, a distributed bug tracker
> [...]
>>> I am a bit unhappy about the namespace grab.  Not for trademark
>>> reasons: the Git trademark rules are pretty clear about this kind of
>>> usage being okay.  Instead, the unhappiness comes because a future Git
>>> command like "git bug" to produce a bug report with appropriate
>>> diagnostics for a bug in Git seems like a likely and useful thing to
>>> get added to Git some day.  And now the name's taken.
>>>
>>> Is it too late to ask if it's possible to come up with a less generic
>>> name?
>>
>> Wouldn't we call such a thing "git-reportbug", or "git gitbug", with
>> reference to Debian reportbug or perl's perlbug?
>
> I hope you're kidding about "git gitbug".

It sounds a bit silly, but such a tool is going to be rarely used enough
that we probably don't want to squat a 3 letter command to invoke it.

> [...]
>> 1) Accept the status quo where people do create third party tools, much
>>    of which are way too obscure to matter (e.g. I'm sure someone's
>>    created a tool/alias called range-diff before, but we didn't
>>    care).
>>
>>    If those tools become popular enough in the wild they get own that
>>    namespace, e.g. we're not going to ship a "git-annex" or "git-lfs"
>>    ourselves implementing some unrelated features
>
> That's fair.  Let me spell out my thinking a little more.
>
> This framework would lead me to rephrase my question to Michael a
> different way.  Instead of saying that I'm not happy with the
> namespace grab, I should say something more severe:
>
>   Don't be surprised if Git itself makes a "git bug" command in the
>   future, and be prepared to rename.
>
> Is that preferable, in your opinion?

We're not going to make some blanket policy that doesn't recognize the
difference between say git-lfs and git-tool_nobody_has_ever_heard_of,
and then decide that it would be just as reasonable for us to ship a new
git-lfs ourselves (which would do something different) as it were for us
to ship git-tool_nobody_has_ever_heard_of.

The reason I can drop a "git-whatever" in my $PATH and invoke it as "git
whatever" is just a historical accident of how git was implemented.

But because that feature has been exposed since the very beginning it's
become an implicit API. There's thousands of git-whatever tools, and
people do use these. The likes of git-lfs and git-annex are used a *lot*
more than some builtins we ship.

So we don't get to say "you never asked us about git-annex, we're using
that name now" without considering how widely used it is. It's us who
decided to expose the API of seamlessly integrating 3rd party tools.

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

[Jonathan Nieder]

Ævar Arnfjörð Bjarmason wrote:

> The reason I can drop a "git-whatever" in my $PATH and invoke it as "git
> whatever" is just a historical accident of how git was implemented.

No.  This is a very deliberate design decision, to allow people to
prototype new Git commands (and to create the kind of ecosystem that
allows commands to be implemented outside Git.

[...]
> So we don't get to say "you never asked us about git-annex, we're using
> that name now" without considering how widely used it is. It's us who
> decided to expose the API of seamlessly integrating 3rd party tools.

I think we're talking past each other.  I haven't proposed any blanket
policy.  I'm saying that "git bug" is a bad name for this tool:

 - it's hard to find with search engines
 - it conflicts with some likely good future changes to Git
 - it assumes that no one else will have some other refinement of the
   Git bugtracker concept, that it is the only "git bug" tool

It's a namespace grab.  There's nothing stopping someone from naming a
command "bug", either, but that doesn't make it a good idea.  (I'm not
saying that was the intent --- that's just the effect.)

Meanwhile it looks like a neat tool, and I'm very supportive of the
idea.  But you certainly still have not convinced me that the name is
a good idea, or that I shouldn't be bringing this up.

I'm not sure *what* you're trying to convince me of, actually.

Jonathan

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

[Ævar Arnfjörð Bjarmason]

On Sat, Aug 18 2018, Jonathan Nieder wrote:

> Ævar Arnfjörð Bjarmason wrote:
>
>> The reason I can drop a "git-whatever" in my $PATH and invoke it as "git
>> whatever" is just a historical accident of how git was implemented.
>
> No.  This is a very deliberate design decision, to allow people to
> prototype new Git commands (and to create the kind of ecosystem that
> allows commands to be implemented outside Git.
>
> [...]
>> So we don't get to say "you never asked us about git-annex, we're using
>> that name now" without considering how widely used it is. It's us who
>> decided to expose the API of seamlessly integrating 3rd party tools.
>
> I think we're talking past each other.  I haven't proposed any blanket
> policy.  I'm saying that "git bug" is a bad name for this tool:
>
>  - it's hard to find with search engines
>  - it conflicts with some likely good future changes to Git
>  - it assumes that no one else will have some other refinement of the
>    Git bugtracker concept, that it is the only "git bug" tool
>
> It's a namespace grab.  There's nothing stopping someone from naming a
> command "bug", either, but that doesn't make it a good idea.  (I'm not
> saying that was the intent --- that's just the effect.)
>
> Meanwhile it looks like a neat tool, and I'm very supportive of the
> idea.  But you certainly still have not convinced me that the name is
> a good idea, or that I shouldn't be bringing this up.
>
> I'm not sure *what* you're trying to convince me of, actually.

I'm not saying the git-bug name is a good idea, or that it isn't. I
don't care about this particular case when it comes to naming.

I'm just pointing out in the more general case that if someone comes up
with a badly named git-xyz it doesn't scale to try to point this out to
them before git-xyz is widely deployed.

So we must either let it go (solution #1), or come up with some
API-level solution that makes it a non-issue (my #3).

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

[Jonathan Nieder]

Ævar Arnfjörð Bjarmason wrote:

> I'm just pointing out in the more general case that if someone comes up
> with a badly named git-xyz it doesn't scale to try to point this out to
> them before git-xyz is widely deployed.
>
> So we must either let it go (solution #1), or come up with some
> API-level solution that makes it a non-issue (my #3).

How about solution #4: live and let live when it comes down to it, but
act like actual people and talk to avoid negative consequences?

Some social problems don't have technical solutions.

Talking scales, in strange ways.  For example, people are able to look
at the list archive, people are able to spread thoughts they have
found interesting, and so on.

Jonathan

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

[Jeff King]

On Sat, Aug 18, 2018 at 03:08:21PM -0700, Jonathan Nieder wrote:

> > So we don't get to say "you never asked us about git-annex, we're using
> > that name now" without considering how widely used it is. It's us who
> > decided to expose the API of seamlessly integrating 3rd party tools.
> 
> I think we're talking past each other.  I haven't proposed any blanket
> policy.  I'm saying that "git bug" is a bad name for this tool:
> 
>  - it's hard to find with search engines
>  - it conflicts with some likely good future changes to Git
>  - it assumes that no one else will have some other refinement of the
>    Git bugtracker concept, that it is the only "git bug" tool
> 
> It's a namespace grab.  There's nothing stopping someone from naming a
> command "bug", either, but that doesn't make it a good idea.  (I'm not
> saying that was the intent --- that's just the effect.)

Right, I think this is a sensible way to think about it. When the time
comes later to call something "git bug", obviously we'd consider the
overall ecosystem and weigh that. But that does not make it a good idea
to pick a name that is likely to get stomped on.

And the most we can do is recommend against it and let them make the
decision.  The Microsoft GVFS folks are in a similar situation. They are
renaming the project and thinking about using git-vfs for the command
name. IMHO that is too generic, and I've mentioned that, but ultimately
I think it is their choice.

-Peff

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

[Junio C Hamano]

Michael Muré <batolettre@gmail.com> writes:

> I released today git-bug, a distributed bug tracker that embeds in
> git. It use git's internal storage to store bugs information in a way
> that can be merged without conflict. You can push/pull to the normal
> git remote you are already using to interact with other people. Normal
> code and bugs are completely separated and no files are added in the
> regular branches.

This reminds me of a demo Scott Chacon showed us ages ago, the name
of which escapes me.  I guess great minds think alike, or something?

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

[Jonathan Nieder]

(cc-ing Scott)
Hi Junio,

Junio C Hamano wrote:
> Michael Muré <batolettre@gmail.com> writes:

>> I released today git-bug, a distributed bug tracker that embeds in
>> git. It use git's internal storage to store bugs information in a way
>> that can be merged without conflict. You can push/pull to the normal
>> git remote you are already using to interact with other people. Normal
>> code and bugs are completely separated and no files are added in the
>> regular branches.
>
> This reminds me of a demo Scott Chacon showed us ages ago, the name
> of which escapes me.  I guess great minds think alike, or something?

I believe you're thinking of TicGit[1].

Some other related work is listed at [2].  Most of these projects have
gone quiet:

- ditz[3]
- git-issues[4]
- cil[5]
- Bugs Everywhere[6]
- milli by Steve Kemp, which I haven't found a copy of
- simple defects[7]
- kipling[8]

http://www.cs.unb.ca/~bremner/blog/posts/git-issue-trackers/ gives a
nice overview, though it's rather old.

This area seems to have gone mostly quiet since 2014, so it's nice to
see new work.

Thanks,
Jonathan

[1] https://github.com/jeffWelling/ticgit
[2] https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools#Bug.2Fissue_trackers.2C_etc.
[3] https://github.com/jashmenn/ditz
[4] https://github.com/duplys/git-issues
[5] https://github.com/chilts/cil
[6] http://bugseverywhere.org/
[7] https://syncwith.us/sd/, https://gitorious.org/prophet/sd
[8] https://gitorious.org/kipling/mainline

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

[Kyle Meyer]

[+cc Stefan Monnier]

Jonathan Nieder <jrnieder@gmail.com> writes:

> (cc-ing Scott)

[...]

> I believe you're thinking of TicGit[1].
>
> Some other related work is listed at [2].  Most of these projects have
> gone quiet:
>
> - ditz[3]
> - git-issues[4]
> - cil[5]
> - Bugs Everywhere[6]
> - milli by Steve Kemp, which I haven't found a copy of
> - simple defects[7]
> - kipling[8]

To add to that list: There's also BuGit [1,2], though it too seems to
have gone quiet.

[1]: https://gitlab.com/monnier/bugit
[2]: https://public-inbox.org/git/jwva8psr6vr.fsf-monnier+gmane.comp.version-control.git@gnu.org/


-- 
Kyle

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

[Jonathan Nieder]

(+ git-dit authors)
Kyle Meyer wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:

>> I believe you're thinking of TicGit[1].
>>
>> Some other related work is listed at [2].  Most of these projects have
>> gone quiet:
>>
>> - ditz[3]
>> - git-issues[4]
>> - cil[5]
>> - Bugs Everywhere[6]
>> - milli by Steve Kemp, which I haven't found a copy of
>> - simple defects[7]
>> - kipling[8]
>
> To add to that list: There's also BuGit [1,2], though it too seems to
> have gone quiet.

I just found a good list on a non Git-specific wiki[3] that is more
helpful (more up to date and has more discussion) than the list on the
Git wiki.

It might be a good place to coordinate and compare notes.  git-dit[4]
in particular seems to have very similar goals and a similar data
model.  In my ideal world there may be a path forward that involves
working more closely together.

Thanks,
Jonathan

> [1]: https://gitlab.com/monnier/bugit
> [2]: https://public-inbox.org/git/jwva8psr6vr.fsf-monnier+gmane.comp.version-control.git@gnu.org/
[3] https://dist-bugs.branchable.com/software/
[4] https://github.com/neithernut/git-dit

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

[Jonathan Nieder]

(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

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

[Michael Muré]

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@gmail.com>:
> (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

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

[Michael Muré]

> There's been some recent work to make
> Git's merge code (also used for cherry-pick) less reliant on the index
> and worktree.

Yes please ! In the mean time, someone suggested another trick [0].

> Can you say more about the federation model it intends to support?

My goal is to have a workflow similar as what git does, to be
versatile and leave to the users the choice of the topology they want
to use. Obviously, it will be most of the time a single remote where
they collaborate.

As a bug tracker is a different workflow than regular code, there will
be some tooling to help. For instance, automatic push/pull will help
make it easier to use and more "out of the way".

In the data model, each commit in the linear chain link to an array of
new edit operations. That means that each commit is strictly
independent from the others. When you get updates for a bug and you
need to merge them, you will simply rebase your new commits on top of
the linear chain.

This design has several properties:

- the merge happen on the user repo where git-bug is installed and can
validate new data
- the remote used doesn't have to be aware of git-bug
- when pushing an update of a ref, the remote will make sure that it's
fast forward, that is, no previous edit operations has been removed.
It ensure that the history is append only.

So for now, collaboration is based on push/pull to whatever remote you
want, as git does, with the exception of the Web UI. The goal here is
to have it running locally for each user but also to make it a public
interface for users that don't have write access to the repo, much
like any bug tracker has.

In the future, it could be possible to have more fancy features like a
federated forge with ActivityPub, but that's way outside of the scope
of the project for now.

[0]: https://github.com/MichaelMure/git-bug/issues/15

2018-08-19 2:45 GMT+02:00 Michael Muré <batolettre@gmail.com>:
> 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@gmail.com>:
>> (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



-- 
Michael

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

[Elijah Newren]

On Sat, Aug 18, 2018 at 3:50 PM Jonathan Nieder <jrnieder@gmail.com> wrote:
> (cc-ing Elijah Newren for the points about merging)

> [...]
> > 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>

Yes, indeed, after the merge refactoring/rewriting stuff is complete,
this is one thing already on my list that I wanted to do with it.
Another thing I'd like to investigate with it is how much "in-memory"
merges could speed up interactive rebases, as suggested by Dscho[1].
Once we do "in-memory" merges for interactive rebases for performance
reasons, we're pretty close to having a
rebase-without-touching-index-or-worktree that we can make accessible
to other scripts like git-bug.  However, we have to have a pretty good
answer about what to do when we hit conflicts.

[1] https://public-inbox.org/git/nycvar.QRO.7.76.6.1806100006000.77@tvgsbejvaqbjf.bet/