* [PATCH] Add to gitk an --argscmd flag to get the list of refs to draw at refresh time.
From: Yann Dirson @ 2007-06-03 22:49 UTC (permalink / raw)
To: paulus; +Cc: git
This flag is meant for porcelains which can modify the list of
meaningful refs to graph. It allows gitk's refresh operation to be
always up-to-date wrt the list of refs to graph.
Primary target is stg-gitk (in StGIT contrib/ dir), which requests
gitk to graph all patches in a stack: patches can be created and
deleted, so we need a way to tell gitk that something has changed.
This patch does not allow setting this parameter in a saved profile,
although it reserves a slot in the savefile format, and will read it
when it finds one.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
Documentation/gitk.txt | 6 ++++++
gitk | 28 +++++++++++++++++++++++-----
2 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index 48c5894..21d002b 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -41,6 +41,12 @@ frequently used options.
Show all branches.
+--argscmd=<command>::
+ Command to be run each time gitk has to determine the list of
+ <revs> to show. Use this instead of explicitely specifying
+ <revs> if the list of commits to show may vary between
+ refreshs.
+
<revs>::
Limit the revisions to show. This can be either a single revision
diff --git a/gitk b/gitk
index a57e84c..6d4d10a 100755
--- a/gitk
+++ b/gitk
@@ -19,12 +19,23 @@ proc gitdir {} {
proc start_rev_list {view} {
global startmsecs nextupdate
global commfd leftover tclencoding datemode
- global viewargs viewfiles commitidx
+ global viewargs viewargscmd viewfiles commitidx
set startmsecs [clock clicks -milliseconds]
set nextupdate [expr {$startmsecs + 100}]
set commitidx($view) 0
- set args $viewargs($view)
+ if {$viewargscmd($view) ne "None"} {
+ if {[catch {
+ set fd [open [concat | $viewargscmd($view)] r]
+ } err]} {
+ puts stderr "Error executing --argscmd command: $err"
+ exit 1
+ }
+ set args [read $fd 500000]
+ close $fd
+ } else {
+ set args $viewargs($view)
+ }
if {$viewfiles($view) ne {}} {
set args [concat $args "--" $viewfiles($view)]
}
@@ -823,7 +834,7 @@ proc savestuff {w} {
global canv canv2 canv3 ctext cflist mainfont textfont uifont
global stuffsaved findmergefiles maxgraphpct
global maxwidth showneartags
- global viewname viewfiles viewargs viewperm nextviewnum
+ global viewname viewfiles viewargs viewargscmd viewperm nextviewnum
global cmitmode wrapcomment
global colors bgcolor fgcolor diffcolors
@@ -856,7 +867,7 @@ proc savestuff {w} {
puts -nonewline $f "set permviews {"
for {set v 0} {$v < $nextviewnum} {incr v} {
if {$viewperm($v)} {
- puts $f "{[list $viewname($v) $viewfiles($v) $viewargs($v)]}"
+ puts $f "{[list $viewname($v) $viewfiles($v) $viewargs($v) $viewargscmd($v)]}"
}
}
puts $f "}"
@@ -6298,10 +6309,14 @@ catch {source ~/.gitk}
font create optionfont -family sans-serif -size -12
set revtreeargs {}
+set revtreeargscmd None
foreach arg $argv {
switch -regexp -- $arg {
"^$" { }
"^-d" { set datemode 1 }
+ "^--argscmd=" {
+ regexp {^--argscmd=(.*)} $arg match revtreeargscmd
+ }
default {
lappend revtreeargs $arg
}
@@ -6357,6 +6372,7 @@ set selectedhlview None
set viewfiles(0) {}
set viewperm(0) 0
set viewargs(0) {}
+set viewargscmd(0) None
set cmdlineok 0
set stopped 0
@@ -6367,7 +6383,7 @@ makewindow
wm title . "[file tail $argv0]: [file tail [pwd]]"
readrefs
-if {$cmdline_files ne {} || $revtreeargs ne {}} {
+if {$cmdline_files ne {} || $revtreeargs ne {} || $revtreeargscmd ne {}} {
# create a view for the files/dirs specified on the command line
set curview 1
set selectedview 1
@@ -6375,6 +6391,7 @@ if {$cmdline_files ne {} || $revtreeargs ne {}} {
set viewname(1) "Command line"
set viewfiles(1) $cmdline_files
set viewargs(1) $revtreeargs
+ set viewargscmd(1) $revtreeargscmd
set viewperm(1) 0
addviewmenu 1
.bar.view entryconf Edit* -state normal
@@ -6388,6 +6405,7 @@ if {[info exists permviews]} {
set viewname($n) [lindex $v 0]
set viewfiles($n) [lindex $v 1]
set viewargs($n) [lindex $v 2]
+ set viewargscmd($n) [lindex $v 3]
set viewperm($n) 1
addviewmenu $n
}
^ permalink raw reply related
* [PATCH] Support environment variables in config file
From: Martin Waitz @ 2007-06-03 22:37 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 4641 bytes --]
Environment variables (e.g. $HOME) can be helpful for the GIT configuration.
With this change you can use them with the normal shell "$" syntax.
If you want to insert a plain "$" in a variable, it can be escaped as \$
or put inside quotes (").
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
I found this particularly useful to be able to specify my own global
gitignore list via core.excludesfile.
Documentation/config.txt | 23 +++++++++++++++--------
config.c | 23 +++++++++++++++++++++--
t/t1300-repo-config.sh | 13 +++++++++++++
3 files changed, 49 insertions(+), 10 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5868d58..042a354 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -65,17 +65,24 @@ a string, an integer, or a boolean. Boolean values may be given as yes/no,
converting value to the canonical form using '--bool' type specifier;
`git-config` will ensure that the output is "true" or "false".
+You can use the $VARIABLE shell syntax to use environment variables
+in the configuration file. All alpha-numeric characters after the
+leading '`$`' will be interpreted as name of an environment variable
+and the value of this variable will be used instead.
+If the variable does not exist it will be treated as an empty string.
+
String values may be entirely or partially enclosed in double quotes.
You need to enclose variable value in double quotes if you want to
preserve leading or trailing whitespace, or if variable value contains
-beginning of comment characters (if it contains '#' or ';').
-Double quote '`"`' and backslash '`\`' characters in variable value must
-be escaped: use '`\"`' for '`"`' and '`\\`' for '`\`'.
-
-The following escape sequences (beside '`\"`' and '`\\`') are recognized:
-'`\n`' for newline character (NL), '`\t`' for horizontal tabulation (HT, TAB)
-and '`\b`' for backspace (BS). No other char escape sequence, nor octal
-char sequences are valid.
+beginning of comment characters (if it contains '#' or ';') or a dollar
+sign which would be interpreted as a variable.
+Double quote '`"`', backslash '`\`' and dollar '`$`' characters in variable
+value must be escaped: use '`\"`' for '`"`' and '`\\`' for '`\`'.
+
+The following escape sequences (beside '`\"`', '`\$"`' and '`\\`') are
+recognized: '`\n`' for newline character (NL), '`\t`' for horizontal tabulation
+(HT, TAB) and '`\b`' for backspace (BS). No other char escape sequence, nor
+octal char sequences are valid.
Variable value ending in a '`\`' is continued on the next line in the
customary UNIX fashion.
diff --git a/config.c b/config.c
index 0614c2b..058c0df 100644
--- a/config.c
+++ b/config.c
@@ -43,12 +43,27 @@ static int get_next_char(void)
static char *parse_value(void)
{
static char value[1024];
- int quote = 0, comment = 0, len = 0, space = 0;
+ int quote = 0, comment = 0, envvar = -1, len = 0, space = 0;
for (;;) {
int c = get_next_char();
if (len >= sizeof(value))
return NULL;
+ if ((envvar >= 0) && !isalnum(c)) {
+ const char *var;
+ value[len] = 0;
+ var = getenv(&value[envvar]);
+ if (var) {
+ strncpy(&value[envvar], var,
+ sizeof(value) - envvar);
+ if (value[sizeof(value)-1])
+ return NULL;
+ len = envvar + strlen(&value[envvar]);
+ } else {
+ len = envvar;
+ }
+ envvar = -1;
+ }
if (c == '\n') {
if (quote)
return NULL;
@@ -66,6 +81,10 @@ static char *parse_value(void)
comment = 1;
continue;
}
+ if (c == '$') {
+ envvar = len;
+ continue;
+ }
}
if (space) {
if (len)
@@ -87,7 +106,7 @@ static char *parse_value(void)
c = '\n';
break;
/* Some characters escape as themselves */
- case '\\': case '"':
+ case '\\': case '"': case '$':
break;
/* Reject unknown escape sequences */
default:
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 3f3fd2d..eb84437 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -513,5 +513,18 @@ git config --list > result
test_expect_success 'value continued on next line' 'cmp result expect'
+cat > .git/config <<\EOF
+[quoted]
+ withvar = "$HOME/foo"
+[unquoted]
+ withvar = $HOME/foo
+EOF
+
+test_expect_success 'quoted $VAR' \
+ 'test x"\$HOME/foo" = x$(git config quoted.withvar)'
+
+test_expect_success 'unquoted $VAR' \
+ 'test x"$HOME/foo" = x$(git config unquoted.withvar)'
+
test_done
--
1.5.2.1.112.gdb0c
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* [gitk bug] 'invalid command name ".bleft.ctext"' when exiting gitk
From: Yann Dirson @ 2007-06-03 22:25 UTC (permalink / raw)
To: paulus; +Cc: GIT list
If I run "./gitk" on the current git master
(c94bf41c9a78dc1c084f2a2895f95b6b6d8f79b1), and hit Ctrl-Q shortly
after gitk starts to fill the diff pane, I get the following error on
the tty:
|invalid command name ".bleft.ctext"
| while executing
|"$ctext conf -state normal"
| (procedure "dispneartags" line 7)
| invoked from within
|"dispneartags"
| (procedure "restartatags" line 31)
| invoked from within
|"restartatags"
| ("after" script)
This problem is not easy to reproduce at every try, I have to try
several times to see it, but it's still pretty easy to get the error.
Anyone knows what it's trying to do ? Is that a race condition
between "after idle restartatags" and the widgets being destroyed ?
--
Yann.
^ permalink raw reply
* Re: [PATCH] gitweb: use decode_utf8 directly
From: Ismail Dönmez @ 2007-06-03 22:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexandre Julliard, git, Jakub Narebski
In-Reply-To: <7vmyzgn14w.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 297 bytes --]
On Monday 04 June 2007 01:06:55 Junio C Hamano wrote:
> Ismail Dönmez <ismail@pardus.org.tr> writes:
> > I can try the patch if you can send me what you propose.
>
> Does the recent one from Jakub work for you?
It works fine here.
Regards,
ismail
--
Perfect is the enemy of good
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: use decode_utf8 directly
From: Junio C Hamano @ 2007-06-03 22:06 UTC (permalink / raw)
To: Ismail Dönmez; +Cc: Alexandre Julliard, git, Jakub Narebski
In-Reply-To: <200706012308.41335.ismail@pardus.org.tr>
Ismail Dönmez <ismail@pardus.org.tr> writes:
> I can try the patch if you can send me what you propose.
Does the recent one from Jakub work for you?
^ permalink raw reply
* Re: [PATCH] Show html help with git-help --html
From: Junio C Hamano @ 2007-06-03 22:04 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <20070602015341.GA26520@localhost.myhome.westell.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> This patch was inspired by ClearCase command 'ct man' which
> opens an html help file on Windows. I at first attempted to
> implement it for MinGW port only but found it so useful that I
> wanted to have it even in Linux.
>
> A new option '--help' is added to git. When git-help is called
> with --help, it will try to open html files located at
> $(sharedir)/html using xdg-open. HTML files are not installed
> by default so users have to install them manually or have their
> distributors to do that.
Do you mean a new option '--html'?
^ permalink raw reply
* Re: [PATCH] cvsimport: add support for new style remote layout
From: Junio C Hamano @ 2007-06-03 22:00 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <3a477a76f6c5396feee452678fb8110c@pinky>
Andy Whitcroft <apw@shadowen.org> writes:
> cvsimport creates any branches found in the remote CVS repository
> in the refs/heads namespace. This makes sense for a repository
> conversion. When using git as a sane interface to a remote CVS
> repository, that repository may well remain as the 'master'
> respository. In this model it makes sense to import the CVS
> repository into the refs/remotes namespace.
>
> Add a new option '-r <remote>' to set the remote name for
> this import. When this option is specified branches are named
> refs/remotes/<remote>/branch, with HEAD named as master matching
> git-clone separate remotes layout. Without branches are placed
> ion refs/heads, with HEAD named origin as before.
Sounds good. Docs?
^ permalink raw reply
* Re: [RFC] GIT_WORK_TREE
From: Sergio @ 2007-06-03 21:34 UTC (permalink / raw)
To: git
In-Reply-To: <20070603193203.GA24781@moooo.ath.cx>
Matthias Lederhofer <matled <at> gmx.net> writes:
> What I haven't thought through is if it could make sense to honor the
> GIT_WORK_TREE/core.worktree setting when such a .git-repo file is used
> or just use the directory containing the file as work tree.
I would do the first... for the following reason...
Suppose that by accident you move the working tree and you cd to some
point in the moved WT...
You issue a git command...
By climbing up the directory hierarchy, git gets to the .git-repo file
so now it knows where the repo is...
But running a command and following the core.worktree config it might
put output in the wrong output dir...
But actually I also see problems the other way round...
Suppose you have project A containing a dir B that is under its own git
tracking...
Also suppose that both A and B have repos separated from WT.
If for some reason WT of B misses its .git-repo, then there is trouble
on the way: when issuing a command in B, by climbing up git would find
the .git-repo of A, thinking that it is the git-repo of B...
A weird case, though.
Sergio
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Dana How @ 2007-06-03 21:20 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git, danahow
In-Reply-To: <alpine.LFD.0.99.0706031703140.12885@xanadu.home>
On 6/3/07, Nicolas Pitre <nico@cam.org> wrote:
> On Sat, 2 Jun 2007, Junio C Hamano wrote:
> > * dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit
> > - Enhance unpack-objects for live repo and large objects
> >
> > I saw nobody other than Dana jump up and down and say we must
> > have this, so I still parked this in 'pu' without merging it to
> > 'next'. Maybe a time for a quick poll?
>
> I did provide a followup comment to this patch. If the concerns I
> raised are addressed then I won't be against such a patch.
Hmm, I thought only your comments about incoherency were
still unaddressed and they applied only to the degunking patch,
but in any case I was planning to improve both patches in similar ways.
I won't be able to do this for a week or two (crunch time here).
I will first review the discussion for each patch in case my memory is wrong.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* [tig PATCH] Fix integer type mismatch on 64-bit systems
From: Steven Grimm @ 2007-06-03 21:12 UTC (permalink / raw)
To: git
fprintf wants an int parameter for the field width of a "%.*s" expression, but
the code was passing a size_t instead. This potentially broke systems where
sizeof(size_t) != sizeof(int). And even on systems where it did't break,
it still caused a compiler warning.
---
tig.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tig.c b/tig.c
index 6adfb33..b09d91b 100644
--- a/tig.c
+++ b/tig.c
@@ -1153,7 +1153,7 @@ read_option(char *opt, size_t optlen, char *value, size_t valuelen)
if (status == ERR) {
fprintf(stderr, "Error on line %d, near '%.*s': %s\n",
- config_lineno, optlen, opt, config_msg);
+ config_lineno, (int) optlen, opt, config_msg);
config_errors = TRUE;
}
--
1.5.2.35.ga334
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Nicolas Pitre @ 2007-06-03 21:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v6466oygl.fsf@assigned-by-dhcp.cox.net>
On Sat, 2 Jun 2007, Junio C Hamano wrote:
> * dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit
> - Enhance unpack-objects for live repo and large objects
>
> I saw nobody other than Dana jump up and down and say we must
> have this, so I still parked this in 'pu' without merging it to
> 'next'. Maybe a time for a quick poll?
I did provide a followup comment to this patch. If the concerns I
raised are addressed then I won't be against such a patch.
Nicolas
^ permalink raw reply
* [ANNOUNCE] qgit new "smart browsing" feature
From: Marco Costalba @ 2007-06-03 20:39 UTC (permalink / raw)
To: Git Mailing List
I've pushed a patch series to
git://git.kernel.org/pub/scm/qgit/qgit4.git that implement a new and
much improved way to browse a repo.
What
-------
- Possibility to switch from revision message to diff content in
bottom left pane of main view
- Possibility to jump to next/previous revision with link labels at
the pane corners
- Optional use of mouse wheel to perform all of the above actions
How
------
In the bottom left pane two labels have been added. Both contain some
links, a default one (big) and a secondary one (small), mouse wheel
action performs the default link action when scrolled out, above or
below the content view.
Links could be switched right clicking on them by the means of a popup
context menu.
Finally in Edit->settings menu a check box called 'Show always
revision message as first' has been added. When checked (suggested),
on jumping to a new revision the log message is shown first,
regardless of the previous pane content.
Notes
--------
Care has been taken to allow the wheel browsing experience to be as
natural as possible, in particular a way to avoid to switch when user
just wants to scroll has been implemented. Also, getting a responsive
scroll and switch command avoiding false positives was not immediate.
I have found, to my surprise, that more the natural behaviour was
obtained more the code amount was big. At the end a quite not trivial
class has been added just to let the user browsing without thinking on
how to do it.
Hope you enjoy it. Of course feedback is, a always, welcomed.
Marco
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: Pierre Habouzit @ 2007-06-03 20:32 UTC (permalink / raw)
To: Yann Dirson; +Cc: Linus Torvalds, git
In-Reply-To: <20070603201723.GG6992@nan92-1-81-57-214-146.fbx.proxad.net>
[-- Attachment #1: Type: text/plain, Size: 3681 bytes --]
On Sun, Jun 03, 2007 at 10:17:23PM +0200, Yann Dirson wrote:
> On Sun, Jun 03, 2007 at 12:22:20PM -0700, Linus Torvalds wrote:
> > On Sun, 3 Jun 2007, Pierre Habouzit wrote:
> > > Though there is a few design issues I have, that block me from doing
> > > first decisions about how to implement some kind of Proof of Concept. My
> > > main problem is: should I put this bug tracking system in the repository
> > > it tracks bugs for, or not.
> >
> > Make it a separate (and independent) branch of the repository you track,
> > and then you can do it - or not do it - as you want later.
>
> And since we have cheep branches, we can even have one BTS branch for
> each project branch.
>
> But then, since we probably want git-merge to merge the BTS branch
> when present in the local repo, that would mean adding some support in
> the core porcelain - eg. a config option declaring some coupling
> between a branch and its bug-tracking pal, so git-merge can be taught
> to merge it too.
In fact, I don't think so. In my answer to Linus, I was almost writing
the same thing as you. In fact, no, we don't want a BTS branch per
project branch. We just want to be able to list commits where we found
the bug, and commits where we didn't found them. Lets call them good and
bad commits (yeah, ring a bell ;p). One of the "good" commit will be
better than any other good one, as it'll be the "fixing" commit. Or one
of the fixing commits, as you may have different ones if you just
cherry-pick just the patch in a stable branch.
So what you need is a way to link a bug to git objects, namely
commits. Linking to files or subtrees also makes sense. In fact we need
to link bugs to well git objects (what a shock :D).
And if you want to know what affects a given branch, well, you need to
list bugs whose affected objects are present in that given branch. Even
if you have one branch per project branch, as the bug branch chronology
will not be the same as the project's one, you'll still need to answer
the previous question the very same way. And I don't think it's be more
complicated if all project's branches (or may project's branches) are
dealt with or not.
> > > I mean, the immediate idea is to have some .bugs/ directories (or
> > > alike). This has many good properties, e.g. for projects like the linux
> > > kernel with its many subsystems or driver, it would make sense to have
> > > per driver/subsystems/... bug packs, and move bugs from one pack to
> > > another would be the way of assigning bugs to different modules.
> >
> > I would suggest _not_ doing this kind of mixing. I think it might be
> > appropriate for some cases, but I don't think it's appropriate in general.
> > Partly because I don't think the people who change the bugs are at all
> > necessarily at all the same people who actually do development.
>
> The same functionality could probably be obtained through more
> annotations (ie. record which subsystem the bug relates to, just like
> any other property of the bug).
Well, annotations are certainly useful to create a [git object] ->
[bug #id] map. That way, listing bugs in a branch is "just" a matter of
listing still open bugs in the ancestry graph. Sadly, if I'm not
mistaken, this is at least a linear operation wrt the number of objects
in the branch (supposing that access to objects is O(1)). IMHO that's
not good enough, but I'm not really in the implementation stage yet.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: Yann Dirson @ 2007-06-03 20:31 UTC (permalink / raw)
To: david; +Cc: Pierre Habouzit, Johan Herland, git, Michael Poole
In-Reply-To: <Pine.LNX.4.64.0706031203220.6705@asgard.lang.hm>
On Sun, Jun 03, 2007 at 12:07:44PM -0700, david@lang.hm wrote:
> >>1. bug number doesn't work well in a distributed environment
> >
> > Sure, SCM revisions either. But git solved that once, I don't see why
> >the solution found at that time would be less of a solution now :)
>
> git's tracking of revisions works becouse it's tracking the content, it
> doesn't care _how_ the content got that way, if it's the same it's the
> same and will have the same hash.
>
> with bugs the reports aren't the same so you can use the sha1 to track a
> particular entry/tag/comment but not to identify the bug itself
Do you see any problem with taking as bug id the hash of the first
entry submitted ? Just like in a classical BTS, the bug id gets
allocated at submussion time. Further informations then get
associated with the initial report - here that would problably
translate into the initial report being an annotation to a source
commit, and further information being annotations to the initial
annotation.
> fine grained categorization is something that takes place long after the
> bug is reported, users don't know how to correctly categorize bugs any
> more then they know what code caused the bug.
Is that a problem ?
> > My experience with bugtracking is that the most efficient way to deal
> >it is to let the programmer in charge of the responsible module deal
> >with those bugs. What programmer aren't willing to do is the triaging,
> >and pulling the bugs off a distant database/UI/.. off something that
> >isn't in their usual workflow.
>
> this only works if someone goes to the work to send the bugs to the right
> programmer. in many cases this is non-trivial.
This is he work of a QA team, and although it is not as common in the
Free Software world as it should be, there are people willing to do
the job. This discussion is about giving these people a better tool
to help them focus on the tasks where a human being is really needed.
Best regards,
--
Yann.
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: Pierre Habouzit @ 2007-06-03 20:21 UTC (permalink / raw)
To: Yann Dirson
Cc: Johan Herland, git, Michael Poole, Karl Hasselström,
Catalin Marinas
In-Reply-To: <20070603200431.GF6992@nan92-1-81-57-214-146.fbx.proxad.net>
[-- Attachment #1: Type: text/plain, Size: 874 bytes --]
On Sun, Jun 03, 2007 at 10:04:31PM +0200, Yann Dirson wrote:
> One thing that I just thought about is how such a system would play
> with eg. StGIT.
I read the rest of the mail, but I don't know stgit at all, so I'm not
really able to tell how well it would integrate, especially since well,
it's still early.
But for sure, I'm launching that brainstorming thread because I want
as much input as possible to know what are people needs, and add the one
that make sense to the todo list, the one that would be good to the
wishlist. FWIW playing well with usual git tools (like stgit, guilt, and
whatever other evolved "thing" in the git nebula) is definitely in the
TODO list.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: Yann Dirson @ 2007-06-03 20:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Pierre Habouzit, git
In-Reply-To: <alpine.LFD.0.98.0706031216560.23741@woody.linux-foundation.org>
On Sun, Jun 03, 2007 at 12:22:20PM -0700, Linus Torvalds wrote:
> On Sun, 3 Jun 2007, Pierre Habouzit wrote:
> > Though there is a few design issues I have, that block me from doing
> > first decisions about how to implement some kind of Proof of Concept. My
> > main problem is: should I put this bug tracking system in the repository
> > it tracks bugs for, or not.
>
> Make it a separate (and independent) branch of the repository you track,
> and then you can do it - or not do it - as you want later.
And since we have cheep branches, we can even have one BTS branch for
each project branch.
But then, since we probably want git-merge to merge the BTS branch
when present in the local repo, that would mean adding some support in
the core porcelain - eg. a config option declaring some coupling
between a branch and its bug-tracking pal, so git-merge can be taught
to merge it too.
> > I mean, the immediate idea is to have some .bugs/ directories (or
> > alike). This has many good properties, e.g. for projects like the linux
> > kernel with its many subsystems or driver, it would make sense to have
> > per driver/subsystems/... bug packs, and move bugs from one pack to
> > another would be the way of assigning bugs to different modules.
>
> I would suggest _not_ doing this kind of mixing. I think it might be
> appropriate for some cases, but I don't think it's appropriate in general.
> Partly because I don't think the people who change the bugs are at all
> necessarily at all the same people who actually do development.
The same functionality could probably be obtained through more
annotations (ie. record which subsystem the bug relates to, just like
any other property of the bug).
Best regards,
--
Yann.
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: Pierre Habouzit @ 2007-06-03 20:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.98.0706031216560.23741@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 4078 bytes --]
On Sun, Jun 03, 2007 at 12:22:20PM -0700, Linus Torvalds wrote:
>
>
> On Sun, 3 Jun 2007, Pierre Habouzit wrote:
> >
> > Though there is a few design issues I have, that block me from doing
> > first decisions about how to implement some kind of Proof of Concept. My
> > main problem is: should I put this bug tracking system in the repository
> > it tracks bugs for, or not.
>
> Make it a separate (and independent) branch of the repository you track,
> and then you can do it - or not do it - as you want later.
>
> See as an example the git "todo" branch, ie you can always look at what
> Junio may or may not be planning with a
>
> git show remotes/origin/todo:TODO
>
> which just shows the "TODO" file in the "remotes/origin/todo" branch.
>
> The same approach could be done for bug tracking: you *could* check out
> the bug-tracking branch separately (and you can create a repository that
> has _only_ that bug tracking branch, or _only_ the actual development
> branch in it), but you could also access it without even checking it out
> at all, and mix the two projects in the same repository.
Well I went that way, but we loose the quite cool "if I branch my
repository I branch the bugs coming with them too"-feature. And I'd be
sad to give that up. But maybe it's an error to want to use git to
encode that relation.
[10 minutes of pondering later]
Well yes, I think it's basically an error to encode the bug
dependencies in git branches and so on, because bug tracking is often
done asynchronously from devel. So you'll have to assign bug to parts of
the history that are already cold from a devel point of view.
My conclusion is indeed that a separate branch is really the way to
go. That does not tells how I'll be able to answer the usual "what are
the current opened bugs in my branch" question fast, but well, one step
at a time.
> > I mean, the immediate idea is to have some .bugs/ directories (or
> > alike). This has many good properties, e.g. for projects like the linux
> > kernel with its many subsystems or driver, it would make sense to have
> > per driver/subsystems/... bug packs, and move bugs from one pack to
> > another would be the way of assigning bugs to different modules.
>
> I would suggest _not_ doing this kind of mixing. I think it might be
> appropriate for some cases, but I don't think it's appropriate in general.
> Partly because I don't think the people who change the bugs are at all
> necessarily at all the same people who actually do development.
>
> IOW, bug-reporters obviously have to have write access to *some*
> bug-tracking thing, and I don't think you want to try to merge the
> bug-tracking together with the real development.
I agree, but I don't see how it's very different from you not trusting
the average kernel contributor and wanting your lieutenants to ack
patches first. My point is, the user-exposed part doesn't *has* to be
pushed in the mainline repository, it could be in ... the bugs
repository, from which developpers could pull some bug reports that are
worth. Or you can also have more layers if you have a QA team in charge
of the bugs. Possibilities are endless, and well, I don't pretend to be
the one that will teach you that :)
Though I don't like 100% the idea of a .bugs repository. The reason
why I came up with that, is that (experience talking), as a
developper/maintainer/...whatever I have to get in touch with the
reporter. Most convenient way : mail. So I want to be able to use
`$MUA -f /path/to/bug/mbox` to answer, because this is the sole
operation that makes sense. Though I suppose it could be easy to make a
thin wrapper that does a local checkout calls $MUA, and commits the new
mail. So I'd easily give up on that, as I acknowledge I've no real
reasons to design it that way.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-p4import.py robustness changes
From: Scott Lamb @ 2007-06-03 20:12 UTC (permalink / raw)
To: Simon Hausmann; +Cc: Junio C Hamano, git
In-Reply-To: <200706031511.31157.simon@lst.de>
On Jun 3, 2007, at 6:11 AM, Simon Hausmann wrote:
> On the topic of git integration with perforce, what are the chances
> of getting
> git-p4 ( http://repo.or.cz/w/fast-export.git ) into git's contrib/
> fast-export
> area? :)
>
> git-p4 can do everything git-p4import can do plus a lot more (it
> can track
> multiple branches, it's a hell of a lot faster, it can export back
> to p4 and
> it also works on Windows!).
I missed that one...I just saw Tailor and the Perl script someone
else had written.
Ergh. git-p4 imports both "subprocess" and "popen2" and also uses
"system" and "os.popen". Why use four different modules to launch git
and p4?
The branch support's interesting. Have you considered tracking
integration history? I was pondering it and am not sure if it's
feasible. Perforce doesn't seem to have an efficient way of
displaying it (just "p4 integrates" that will fetch *all* revisions
even if you want incremental results and "p4 filelog" which would
have to be done on each file). Also, I think there's some mismatch
between the Perforce and git models.
git-p4import.py should work fine on Windows, too - the binary mode on
the pipe should be all handled by "subprocess", and git-p4's
data.replace("\r\n", "\n") is not necessary if you use "LineEnd:
unix" or "share" in the Perforce client specification.
As for performance...hmm. Looks like git-p4import.py runs these
commands for each Perforce revision:
realtime operation
3.4% p4 describe -s N
66.6% p4 sync ...@N
[*] 10.2% git ls-files -m -d -o -z | git update-index --add --
remove -z --stdin
2.6% git rev-parse --verify HEAD
4.2% git write-tree
2.8% git commit-tree xxxxxx
7.5% git tag -f p4/N xxxxxx
2.7% git update-ref HEAD xxxxxx
That's with Perforce running over the network. Are you running locally?
git-p4 seems to use "git fast-import". I guess the big performance
improvement there is removing the ls-files operation? So we're
talking about a 0-10% speedup, right? Plus some fork()/exec() overhead.
[*] - Note that I just discovered a big performance regression in my
patches. Reading the ls-files into Python, through a regexp, and back
out through update-index was a horrible idea. The times above are
with that fixed.
--
Scott Lamb <http://www.slamb.org/>
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: Yann Dirson @ 2007-06-03 20:04 UTC (permalink / raw)
To: Johan Herland, git, Michael Poole; +Cc: Karl Hasselström, Catalin Marinas
In-Reply-To: <20070603151921.GB30347@artemis>
One thing that I just thought about is how such a system would play
with eg. StGIT.
Precisely, if I stick a BTS note (found/not-found probably makes no
sense here, so that'd mostly be fixes/enhances notes) to a given
version of an StGIT patch, I probably want the BTS to be able to tell
that the next version of the patch "probably has" the same note - if a
given patch fixes a given bug, I infer the patch is primarily written
as a fix for that bug, so later revisions of the patch (eg. cleanups)
would also fix it. But maybe we'd want the patch author to
explicitely make such an assertion, in case a cleanup would have
broken the fix - both options could be useful in different cases.
Currently, old versions of an StGIT patch are only available through
StGIT patchlogs, which are not ancestors of later versions of the same
patch. That is, even the "subsequent versions inherit notes" policy
would need extra StGIT-aware stuff to work.
This may be something to keep in mind here - but that issue could also
be seen as belonging to the more general (and with ongoing work)
aspect of git/StGIT interactions. Even better if the 2 ongoing
reflexions cross-fertilisate :)
Best regards,
--
Yann.
^ permalink raw reply
* [PATCH] Add autoconf-based build infrastructure for tig
From: Steven Grimm @ 2007-06-03 19:35 UTC (permalink / raw)
To: git
In-Reply-To: <20070531215508.GB9260@diku.dk>
---
This is a first cut at building tig using autoconf. I'm including
a script to run the various autoconf tools rather than packaging
up a finished configure script. With this patch, tig configures
and builds on both Linux (FC4) and OS X. I left a lot of the code
from the original Makefile intact so as to (hopefully) not mess
up building release tarballs, etc.
INSTALL | 8 +++---
Makefile => Makefile.am | 44 +++++--------------------------------
autoconf.sh | 24 ++++++++++++++++++++
configure.ac | 55 +++++++++++++++++++++++++++++++++++++++++++++++
tig.c | 14 ++++++-----
version.sh | 23 +++++++++++++++++++
6 files changed, 120 insertions(+), 48 deletions(-)
rename Makefile => Makefile.am (75%)
create mode 100755 autoconf.sh
create mode 100644 configure.ac
create mode 100644 version.sh
diff --git a/INSTALL b/INSTALL
index 586878e..db7dcbf 100644
--- a/INSTALL
+++ b/INSTALL
@@ -8,16 +8,16 @@ available either in the tarballs or in the above repository in the branch named
To install tig simply run:
+ $ sh autoconf.sh
+ $ ./configure
$ make install
To install documentation run:
$ make install-doc
-Edit the Makefile if you need to configure specific compiler or linker flags.
-On FreeBSD for example the c library does not support the iconv interface and
-to compile tig you need to append `-L/usr/local/lib -liconv` to `LDLIBS` and
-`-I/usr/local/include` to the `CFLAGS` variable.
+If you had to install your own copy of libiconv, you'll probably want to pass
+the "--with-libiconv" option to the "configure" script to tell it where to look.
The following tools and packages are needed:
diff --git a/Makefile b/Makefile.am
similarity index 75%
rename from Makefile
rename to Makefile.am
index 91cb097..9f146f9 100644
--- a/Makefile
+++ b/Makefile.am
@@ -1,48 +1,18 @@
-prefix = $(HOME)
-bindir = $(prefix)/bin
-mandir = $(prefix)/man
-docdir = $(prefix)/share/doc
-# DESTDIR=
-
-# Get version either via git or from VERSION file. Allow either
-# to be overwritten by setting DIST_VERSION on the command line.
-ifneq (,$(wildcard .git))
-GITDESC = $(subst tig-,,$(shell git describe))
-WTDIRTY = $(if $(shell git-diff-index HEAD 2>/dev/null),-dirty)
-VERSION = $(GITDESC)$(WTDIRTY)
-else
-VERSION = $(shell test -f VERSION && cat VERSION || echo "unknown-version")
-endif
-ifdef DIST_VERSION
-VERSION = $(DIST_VERSION)
-endif
-
-RPM_VERSION = $(subst -,.,$(VERSION))
-
-LDLIBS = -lcurses
-CFLAGS = -Wall -O2
-DFLAGS = -g -DDEBUG -Werror
-PROGS = tig
+AM_CPPFLAGS = -DTIG_VERSION=\"`sh version.sh`\"
+AM_CFLAGS = -Wall -O2
+
+bin_PROGRAMS = tig
+tig_SOURCES = tig.c
+
MANDOC = tig.1 tigrc.5
HTMLDOC = tig.1.html tigrc.5.html manual.html README.html
ALLDOC = $(MANDOC) $(HTMLDOC) manual.html-chunked manual.pdf
TARNAME = tig-$(RPM_VERSION)
-override CFLAGS += '-DVERSION="$(VERSION)"'
-
-all: $(PROGS)
-all-debug: $(PROGS)
-all-debug: CFLAGS += $(DFLAGS)
doc: $(ALLDOC)
doc-man: $(MANDOC)
doc-html: $(HTMLDOC)
-install: all
- mkdir -p $(DESTDIR)$(bindir) && \
- for prog in $(PROGS); do \
- install -p -m 0755 $$prog $(DESTDIR)$(bindir); \
- done
-
install-doc-man: doc-man
mkdir -p $(DESTDIR)$(mandir)/man1 \
$(DESTDIR)$(mandir)/man5
@@ -107,8 +77,6 @@ release-dist: release-doc
tig.spec: tig.spec.in
sed -e 's/@@VERSION@@/$(RPM_VERSION)/g' < $< > $@
-tig: tig.c
-
manual.html: manual.toc
manual.toc: manual.txt
sed -n '/^\[\[/,/\(---\|~~~\)/p' < $< | while read line; do \
diff --git a/autoconf.sh b/autoconf.sh
new file mode 100755
index 0000000..5492de0
--- /dev/null
+++ b/autoconf.sh
@@ -0,0 +1,24 @@
+#!/bin/sh
+
+echo "aclocal..."
+ACLOCAL=${ACLOCAL:-aclocal-1.9}
+$ACLOCAL || aclocal-1.7 || aclocal-1.5 || aclocal || exit 1
+
+echo "autoheader..."
+AUTOHEADER=${AUTOHEADER:-autoheader}
+$AUTOHEADER || exit 1
+
+echo "automake..."
+# shut automake up about missing files
+touch missing NEWS AUTHORS ChangeLog
+AUTOMAKE=${AUTOMAKE:-automake-1.9}
+$AUTOMAKE --add-missing --foreign ||
+ automake-1.7 --add-missing --foreign ||
+ automake --add-missing --foreign ||
+ exit 1
+rm missing NEWS AUTHORS ChangeLog
+
+echo "autoconf..."
+AUTOCONF=${AUTOCONF:-autoconf}
+$AUTOCONF || exit 1
+
diff --git a/configure.ac b/configure.ac
new file mode 100644
index 0000000..2cdb320
--- /dev/null
+++ b/configure.ac
@@ -0,0 +1,55 @@
+AC_INIT([tig], [0],
+ [Jonas Fonesca <fonesca@diku.dk>],
+ [tig])
+AC_LANG([C])
+AM_CONFIG_HEADER(config.h)
+AC_CONFIG_SRCDIR(tig.c)
+AM_INIT_AUTOMAKE([no-dist])
+
+AC_ARG_WITH(libiconv,
+ AC_HELP_STRING([--with-libiconv=DIRECTORY],[base directory for libiconv]))
+if test "$with_libiconv" != ""
+then
+ CFLAGS="$CFLAGS -I$with_libiconv/include"
+ LDFLAGS="$LDFLAGS -L$with_libiconv/lib"
+fi
+
+dnl
+dnl See if we need to link with -liconv to get the iconv() function.
+dnl
+AC_SEARCH_LIBS([iconv], [iconv])
+AC_SEARCH_LIBS([wclear], [ncurses])
+
+if test "$ac_cv_search_iconv" = "no"
+then
+ AC_MSG_FAILURE([iconv() not found. Please install libiconv.],[1])
+fi
+
+dnl
+dnl See if iconv() requires a const char ** for the input buffer.
+dnl
+if test "$GCC" = "yes"
+then
+ OLD_CFLAGS="$CFLAGS"
+ CFLAGS="$CFLAGS -Werror"
+ AC_MSG_CHECKING([whether iconv needs const char **])
+ AC_COMPILE_IFELSE(
+ [AC_LANG_PROGRAM([[#include <iconv.h>]],
+ [[char **buf;
+ size_t *size;
+ iconv_t cd;
+ iconv(cd, buf, size, buf, size);]])],
+ [AC_DEFINE([ICONV_INBUF_TYPE],[char *],
+ [Type of iconv() input buffer])
+ AC_MSG_RESULT([no])],
+ [AC_DEFINE([ICONV_INBUF_TYPE],[const char *],
+ [Type of iconv() input buffer])
+ AC_MSG_RESULT([yes])])
+ CFLAGS="$OLD_CFLAGS"
+fi
+
+AC_PROG_CC
+AC_PROG_INSTALL
+
+AC_CONFIG_FILES([Makefile])
+AC_OUTPUT
diff --git a/tig.c b/tig.c
index 6adfb33..6648c4e 100644
--- a/tig.c
+++ b/tig.c
@@ -11,8 +11,8 @@
* GNU General Public License for more details.
*/
-#ifndef VERSION
-#define VERSION "unknown-version"
+#ifndef TIG_VERSION
+#define TIG_VERSION "unknown-version"
#endif
#ifndef DEBUG
@@ -40,6 +40,8 @@
#include <curses.h>
+#include "config.h"
+
#if __GNUC__ >= 3
#define __NORETURN __attribute__((__noreturn__))
#else
@@ -388,7 +390,7 @@ get_request(const char *name)
*/
static const char usage[] =
-"tig " VERSION " (" __DATE__ ")\n"
+"tig " TIG_VERSION " (" __DATE__ ")\n"
"\n"
"Usage: tig [options]\n"
" or: tig [options] [--] [git log options]\n"
@@ -513,7 +515,7 @@ parse_options(int argc, char *argv[])
}
if (check_option(opt, 'v', "version", OPT_NONE)) {
- printf("tig version %s\n", VERSION);
+ printf("tig version %s\n", TIG_VERSION);
return FALSE;
}
@@ -1918,7 +1920,7 @@ update_view(struct view *view)
line[linelen - 1] = 0;
if (opt_iconv != ICONV_NONE) {
- char *inbuf = line;
+ ICONV_INBUF_TYPE inbuf = line;
size_t inlen = linelen;
char *outbuf = out_buffer;
@@ -2245,7 +2247,7 @@ view_driver(struct view *view, enum request request)
break;
case REQ_SHOW_VERSION:
- report("tig-%s (built %s)", VERSION, __DATE__);
+ report("tig-%s (built %s)", TIG_VERSION, __DATE__);
return TRUE;
case REQ_SCREEN_RESIZE:
diff --git a/version.sh b/version.sh
new file mode 100644
index 0000000..2519876
--- /dev/null
+++ b/version.sh
@@ -0,0 +1,23 @@
+#!/bin/sh
+if [ -n "$DIST_VERSION" ]
+then
+ echo "$DIST_VERSION"
+ exit 0
+else
+ if [ -d .git ]
+ then
+ GITDESC="`git describe | sed s/tig-//`"
+ if git-diff-index HEAD 2> /dev/null > /dev/null
+ then
+ WTDIRTY="-dirty"
+ fi
+ echo $GITDESC$WTDIRTY
+ else
+ if [ -f VERSION ]
+ then
+ cat VERSION
+ else
+ echo "unknown-version"
+ fi
+ fi
+fi
--
1.5.2.35.ga334
^ permalink raw reply related
* Re: [RFC] GIT_WORK_TREE
From: Matthias Lederhofer @ 2007-06-03 19:32 UTC (permalink / raw)
To: Sergio; +Cc: git
In-Reply-To: <loom.20070603T175743-376@post.gmane.org>
Sergio <sergio.callegari@gmail.com> wrote:
> Matthias Lederhofer <matled <at> gmx.net> writes:
> If I am not wrong, with this we detach the WT from the REPO by letting git know
> our working tree if the working tree does not include a repo (.git) directory.
> And this is done either:
> - by setting the GIT_WORK_TREE environment variable whenever needed
> - by passing the --work-tree parameter to git when needed
> - by setting the core.worktree config option in the git repo, so that the
> repository knows where its default work tree is...
>
> Is this correct? or am I missing some other ways?
That's right, you'd set GIT_DIR and core.worktree/GIT_WORK_TREE.
> Would it make sense to make the _WT_ know where its repo is?
>
> I.e. having something like a .git-repo file a the top dir of a WT, so that when
> git is invoked within the WT it can scan up the WT until it finds the .git-repo
> file and automatically decide that GIT_WORK_TREE is at the dir containing that
> .git-repo file and that GIT_DIR is at the file pointed by that .git-repo?
Symlinking the .git directory is quite similar to this and works
already without this patch series. Anyway I spontaneously can think
of the following use cases, so it might be interesting to add this
feature:
- The use case Nguyen mentioned, e.g. the filesystem does not support
symlinks and for some reason it is not possible to use the git
repository next to the working tree.
- When executing potentially 'dangerous' programs in the working tree
it is safer to have a file pointing to the repository than placing
the repository or a symlink to the repository in the working tree
(breaking the .git-repo file might be confusing but is not as bad as
breaking the repository).
- In case of a publicly available working tree it might be ok to
publish the path to the repository accidentially (which might happen
if the permissions for the .git-repo file are too loose) but there
would be no risk that wrong permissions could disclose the
repository itself.
What I haven't thought through is if it could make sense to honor the
GIT_WORK_TREE/core.worktree setting when such a .git-repo file is used
or just use the directory containing the file as work tree.
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: Linus Torvalds @ 2007-06-03 19:22 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20070603114843.GA14336@artemis>
On Sun, 3 Jun 2007, Pierre Habouzit wrote:
>
> Though there is a few design issues I have, that block me from doing
> first decisions about how to implement some kind of Proof of Concept. My
> main problem is: should I put this bug tracking system in the repository
> it tracks bugs for, or not.
Make it a separate (and independent) branch of the repository you track,
and then you can do it - or not do it - as you want later.
See as an example the git "todo" branch, ie you can always look at what
Junio may or may not be planning with a
git show remotes/origin/todo:TODO
which just shows the "TODO" file in the "remotes/origin/todo" branch.
The same approach could be done for bug tracking: you *could* check out
the bug-tracking branch separately (and you can create a repository that
has _only_ that bug tracking branch, or _only_ the actual development
branch in it), but you could also access it without even checking it out
at all, and mix the two projects in the same repository.
> I mean, the immediate idea is to have some .bugs/ directories (or
> alike). This has many good properties, e.g. for projects like the linux
> kernel with its many subsystems or driver, it would make sense to have
> per driver/subsystems/... bug packs, and move bugs from one pack to
> another would be the way of assigning bugs to different modules.
I would suggest _not_ doing this kind of mixing. I think it might be
appropriate for some cases, but I don't think it's appropriate in general.
Partly because I don't think the people who change the bugs are at all
necessarily at all the same people who actually do development.
IOW, bug-reporters obviously have to have write access to *some*
bug-tracking thing, and I don't think you want to try to merge the
bug-tracking together with the real development.
Linus
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: david @ 2007-06-03 19:07 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Johan Herland, git, Michael Poole
In-Reply-To: <20070603184957.GE30347@artemis>
On Sun, 3 Jun 2007, Pierre Habouzit wrote:
>
> On Sun, Jun 03, 2007 at 10:35:48AM -0700, david@lang.hm wrote:
>> On Sun, 3 Jun 2007, Pierre Habouzit wrote:
>>
>>> On Sun, Jun 03, 2007 at 05:44:58PM +0200, Matthieu Moy wrote:
>>>> Pierre Habouzit <madcoder@debian.org> writes:
>>>>
>>>>> Yeah, now that I read that thread, well yeah, I think notes are a
>>>>> hell
>>>>> of a good concept for my ideas. I mean, a bug report would be
>>>>> basically
>>>>> a collection of notes:
>>>>> * the bug has been found at this commit ;
>>>>> * the bug has been not-found at this commit ;
>>>>> * this commit is a fix for that bug ;
>>>>
>>>> That's my feeling too. "Commiting" bug information in the tree is only
>>>> half of a good idea. You want to be able to say, after the fact, "This
>>>> commit had bug XYZ". OTOH, the idea (followed by bugs everywhere) that
>>>> merging a branch would automatically close bugs fixed by this branch
>>>> is a really cool thing.
>>>
>>> That would work with notes, as while merging you'll get the notes of
>>> the commit in your branch, *and* the note about the fixing patch. So
>>> there is no loss of "concept" here. In fact that was the thing that I
>>> looked for. Notes are good. They just may not be enough to write an
>>> in-git bugtracking tool, as a bug needs the "notes collection" concepts,
>>> and maybe a few other.
>>
>> how would you identify bugs in such a way that they will match up when
>> you merge different trees?
>
> well, because they will be sha1's, a git object. And when it's a
> duplicate, well, let's face it, not bugtracker helps *automatically*
> tracking duplicates. The merge work is up to the QA people. Yeah,
> bugtracker won't do all the tracking. In a way, that's good, that means
> there is still place for humans in that world :)
>
>> if you can manage to do this it sounds like a great idea. but I'm not
>> seeing a good way to do it at the moment. the answer may be a combination
>> of a number of factors.
>>
>> 1. bug number doesn't work well in a distributed environment
>
> Sure, SCM revisions either. But git solved that once, I don't see why
> the solution found at that time would be less of a solution now :)
git's tracking of revisions works becouse it's tracking the content, it
doesn't care _how_ the content got that way, if it's the same it's the
same and will have the same hash.
with bugs the reports aren't the same so you can use the sha1 to track a
particular entry/tag/comment but not to identify the bug itself
>> 2. something based on indentifying the cause of the bug (commit id + file
>> + line????) will only work after you know the real cause of the bug
>
> It does not work in a real world, where real user don't grok code.
>
>> 3. description is worthless, too many ways to describe things that have
>> the same underlying cause
>
> Sure, though it could help finding dupes. BUt in my experience what
> helps most, is fine grained categorizing, because you end up with few
> bugs for a given component, and "same" bugs end up actually being near
> in the UI or query tool. Of course it let space for bugs that get
> actually miscategorized. But hell, my experience is also that many bugs
> are discovered as beeing fixed years after the fix anyway.
fine grained categorization is something that takes place long after the
bug is reported, users don't know how to correctly categorize bugs any
more then they know what code caused the bug.
> I don't plan fixing all that stuff, it can't really be. I just would
> like to create a tool that isn't as painful for the programmer as
> bugzilla (or rt or ...) is, while it would still be as pleasant and easy
> to stick a web UI for the users over it, hence not making the user
> experience less pleasant.
>
> My experience with bugtracking is that the most efficient way to deal
> it is to let the programmer in charge of the responsible module deal
> with those bugs. What programmer aren't willing to do is the triaging,
> and pulling the bugs off a distant database/UI/.. off something that
> isn't in their usual workflow.
this only works if someone goes to the work to send the bugs to the right
programmer. in many cases this is non-trivial.
David Lang
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: Pierre Habouzit @ 2007-06-03 18:49 UTC (permalink / raw)
To: david; +Cc: Johan Herland, git, Michael Poole
In-Reply-To: <Pine.LNX.4.64.0706031031520.6705@asgard.lang.hm>
[-- Attachment #1: Type: text/plain, Size: 3709 bytes --]
On Sun, Jun 03, 2007 at 10:35:48AM -0700, david@lang.hm wrote:
> On Sun, 3 Jun 2007, Pierre Habouzit wrote:
>
> >On Sun, Jun 03, 2007 at 05:44:58PM +0200, Matthieu Moy wrote:
> >>Pierre Habouzit <madcoder@debian.org> writes:
> >>
> >>> Yeah, now that I read that thread, well yeah, I think notes are a
> >>>hell
> >>>of a good concept for my ideas. I mean, a bug report would be
> >>>basically
> >>>a collection of notes:
> >>> * the bug has been found at this commit ;
> >>> * the bug has been not-found at this commit ;
> >>> * this commit is a fix for that bug ;
> >>
> >>That's my feeling too. "Commiting" bug information in the tree is only
> >>half of a good idea. You want to be able to say, after the fact, "This
> >>commit had bug XYZ". OTOH, the idea (followed by bugs everywhere) that
> >>merging a branch would automatically close bugs fixed by this branch
> >>is a really cool thing.
> >
> > That would work with notes, as while merging you'll get the notes of
> >the commit in your branch, *and* the note about the fixing patch. So
> >there is no loss of "concept" here. In fact that was the thing that I
> >looked for. Notes are good. They just may not be enough to write an
> >in-git bugtracking tool, as a bug needs the "notes collection" concepts,
> >and maybe a few other.
>
> how would you identify bugs in such a way that they will match up when
> you merge different trees?
well, because they will be sha1's, a git object. And when it's a
duplicate, well, let's face it, not bugtracker helps *automatically*
tracking duplicates. The merge work is up to the QA people. Yeah,
bugtracker won't do all the tracking. In a way, that's good, that means
there is still place for humans in that world :)
> if you can manage to do this it sounds like a great idea. but I'm not
> seeing a good way to do it at the moment. the answer may be a combination
> of a number of factors.
>
> 1. bug number doesn't work well in a distributed environment
Sure, SCM revisions either. But git solved that once, I don't see why
the solution found at that time would be less of a solution now :)
> 2. something based on indentifying the cause of the bug (commit id + file
> + line????) will only work after you know the real cause of the bug
It does not work in a real world, where real user don't grok code.
> 3. description is worthless, too many ways to describe things that have
> the same underlying cause
Sure, though it could help finding dupes. BUt in my experience what
helps most, is fine grained categorizing, because you end up with few
bugs for a given component, and "same" bugs end up actually being near
in the UI or query tool. Of course it let space for bugs that get
actually miscategorized. But hell, my experience is also that many bugs
are discovered as beeing fixed years after the fix anyway.
I don't plan fixing all that stuff, it can't really be. I just would
like to create a tool that isn't as painful for the programmer as
bugzilla (or rt or ...) is, while it would still be as pleasant and easy
to stick a web UI for the users over it, hence not making the user
experience less pleasant.
My experience with bugtracking is that the most efficient way to deal
it is to let the programmer in charge of the responsible module deal
with those bugs. What programmer aren't willing to do is the triaging,
and pulling the bugs off a distant database/UI/.. off something that
isn't in their usual workflow.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: handle non UTF-8 text
From: Alexandre Julliard @ 2007-06-03 18:41 UTC (permalink / raw)
To: Jakub Narebski
Cc: Junio C Hamano, Martin Koegler, Petr Baudis, git, Martin Langhoff,
Martyn Smith, Robin Rosenberg
In-Reply-To: <200706031742.45216.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Alexandre, I hope that the patch attached would solve your problem.
Yes, it works fine for me, thanks!
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox