git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Herland <johan@herland.net>
To: git@vger.kernel.org
Cc: Pierre Habouzit <madcoder@debian.org>,
	Michael Poole <mdpoole@troilus.org>
Subject: Re: [RFC] git integrated bugtracking
Date: Sun, 03 Jun 2007 15:48:29 +0200	[thread overview]
Message-ID: <200706031548.30111.johan@herland.net> (raw)
In-Reply-To: <20070603133109.GD14336@artemis>

On Sunday 03 June 2007, Pierre Habouzit wrote:
> On Sun, Jun 03, 2007 at 08:59:18AM -0400, Michael Poole wrote:
> > Pierre Habouzit writes:
> >
> > >   The other problem I see is that at the time a bug gets reported, the
> > > user knows it's found at a commit say 'X'. But it could in fact have
> > > been generated at a commit Y, with this pattern:
> > >
> > >   --o---o---Y---o---o---o---o---X---o---o--> master
> > >                      \
> > >                       o---o---o---o---o---o--> branch B
> > 
> > Mainly for that reason, I would suggest having it outside the code
> > base's namespace: probably a different root in the same $GIT_DIR, but
> > I can see people wanting to have a separate $GIT_DIR.  If the database
> > tracks bugs by what commit(s) introduce or expose the bug -- at least
> > once that is known -- then you get nearly free tracking of which
> > branches have the bug without having to check out largely redundant
> > trees.
> 
>   Sure, but if it's completely out-of-tree, then cloning a repository
> don't allow you to get the bug databases with it for free. I mean it'd
> be great to have it somehow linked to the repository, but also I agree
> that not everybody wants to clone the whole bugs databases. So maybe it
> should just be in another shadow branch that annotates the devel ones.
> Hmmm I definitely need to read the git-note thread...

I guess I'm the one responsible for starting that git-note thread...

For the moment, I'm busy implementing some concepts that came out of that 
discussion (refactoring tag objects and building some infrastructure needed 
to support notes without the drawbacks present in my first version).

Hopefully I'll have a proof-of-concept ready before too long. In the 
meantime I'll be happy to answer questions you might have.

Regarding the notes themselves, I thought about possibly using them as a 
link between the repo and the bug tracker, with some glue code in between 
for making the connections. I haven't thought about integrating them more 
deeply into a bug tracker, but it might be worth thinking along those 
lines, especially for the kind of system you're proposing.

Now, back to hacking...


Have fun! :)

...Johan


-- 
Johan Herland, <johan@herland.net>
www.herland.net

  reply	other threads:[~2007-06-03 13:48 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-03 11:48 [RFC] git integrated bugtracking Pierre Habouzit
2007-06-03 12:35 ` Yann Dirson
2007-06-03 13:23   ` Pierre Habouzit
2007-06-03 12:59 ` Michael Poole
2007-06-03 13:31   ` Pierre Habouzit
2007-06-03 13:48     ` Johan Herland [this message]
2007-06-03 15:19       ` Pierre Habouzit
2007-06-03 15:44         ` Matthieu Moy
2007-06-03 16:07           ` Pierre Habouzit
2007-06-03 17:35             ` david
2007-06-03 18:49               ` Pierre Habouzit
2007-06-03 19:07                 ` david
2007-06-03 20:31                   ` Yann Dirson
2007-06-03 17:10         ` Yann Dirson
2007-06-03 20:04         ` Yann Dirson
2007-06-03 20:21           ` Pierre Habouzit
2007-06-04 22:03         ` Yann Dirson
2007-06-04 22:25           ` Pierre Habouzit
2007-06-03 19:22 ` Linus Torvalds
2007-06-03 20:16   ` Pierre Habouzit
2007-06-03 23:07     ` Martin Waitz
2007-06-04  9:32       ` Rogan Dawes
     [not found]         ` <20070604102037.GB7758@.intersec.eu>
2007-06-04 13:29           ` Rogan Dawes
2007-06-03 20:17   ` Yann Dirson
2007-06-03 20:32     ` Pierre Habouzit
2007-06-09 12:12 ` Pierre Habouzit
2007-06-09 16:23   ` Jakub Narebski
2007-06-10  2:44   ` Daniel Barkalow
2007-06-10  7:44     ` Johannes Schindelin
2007-06-10  6:59   ` Martin Langhoff
2007-06-10  7:35     ` Junio C Hamano
2007-06-10  8:38       ` Martin Langhoff
2007-06-10  8:50       ` Jan Hudec
2007-06-11 18:51         ` Jon Loeliger
2007-06-12  8:54           ` Guilhem Bonnefille
2007-06-10  8:37     ` Jan Hudec
2007-06-10  8:55       ` Martin Langhoff
2007-06-10 10:16         ` Pierre Habouzit
2007-06-10 23:14           ` Martin Langhoff
2007-06-11  8:45             ` Pierre Habouzit
2007-06-11 10:00               ` Martin Langhoff
2007-06-10 10:49         ` Jan Hudec
2007-06-10 22:07       ` Matthieu Moy
2007-06-10 13:34     ` Pierre Habouzit
2007-06-10 13:43     ` Pierre Habouzit
2007-06-10 14:02     ` Pierre Habouzit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200706031548.30111.johan@herland.net \
    --to=johan@herland.net \
    --cc=git@vger.kernel.org \
    --cc=madcoder@debian.org \
    --cc=mdpoole@troilus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).