* Re: Please pull mergetool.git
From: Theodore Tso @ 2007-06-10 21:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v1wgj8tzy.fsf@assigned-by-dhcp.cox.net>
On Sun, Jun 10, 2007 at 12:55:13PM -0700, Junio C Hamano wrote:
> But I hope you would not be offended if I said I do not want to.
>
> This is not such a strong objection, but I really wish that you
> did not mix in the .gitignore change; it does not belong to this
> "series".
OK, no problem. It was something I noticed while I was preparing the
series, and I thought it was non-controverisal enough to just throw it
in. It's at the tail of the series, so it's easy enough for me to do a
git reset --hard HEAD^
on the mergetool branch.... OK, done. If you pull from
git://repo.or.cz/git/mergetool.git mergetool
You'll only get the first two changes to git-mergetool, and the
.gitignore change has been dropped.
Regards,
- Ted
^ permalink raw reply
* Re: git-svn set-tree bug
From: Eric Wong @ 2007-06-10 21:33 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: git
In-Reply-To: <1181496086.30670.115.camel@gentoo-jocke.transmode.se>
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> On Sat, 2007-06-09 at 18:47 -0700, Eric Wong wrote:
> > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > > trying to do git-svn set-tree remotes/trunk..svn
> > > in my new git-svn repo I get:
> > > config --get svn-remote.svn.fetch :refs/remotes/git-svn$: command returned error: 1
> >
> > You need to specify "-i trunk" in the command-line
> >
> > git-svn set-tree -i trunk remotes/trunk..svn
> >
>
> Thanks
>
> I have found a bug or two. Run this script and
> see what happens ant the end.
<snip>
> git pull . merge
This is a non-fast-forward merge, giving you non-linear history. git
understands non-linear history without problems, but svn does not.
> git svn dcommit # this fails
If you have non-linear history, don't use dcommit, use set-tree. Linear
history is cleaner and easier to manage, which is why I recommend
format-patch/am/dcommit/rebase, and avoid using pull/merge unless it's
fast-forward.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Port git-tag.sh to C.
From: Junio C Hamano @ 2007-06-10 21:36 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Kristian Høgsberg, git
In-Reply-To: <200706101437.50441.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
> söndag 10 juni 2007 skrev Kristian Høgsberg:
>> Junio C Hamano wrote:
>> > Kristian Høgsberg <krh@redhat.com> writes:
>> > ...
>> > I think your name in your commit message is in UTF-8 but munged your
>> > mail was mismarked as iso-8859-1.
>>
>> That's odd both the email I cc'ed to my redhat.com address and the one I got
>> on gmail.com through the list have
>>
>> Content-Type: text/plain; charset=utf-8
>>
>> and saving the raw message and asking /usr/bin/file, it tells me its
>>
>> /home/krh/Desktop/hep: UTF-8 Unicode mail text
>
> Maybe Junio's mail server has a problem with the impliction of this header line?
>
> "Content-Transfer-Encoding: 8bit" ?
The copy of Kristian's message gmane has says:
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
I do not think it is just me.
^ permalink raw reply
* Re: [ANNOUNCE] qgit-2.0rc1
From: Marco Costalba @ 2007-06-10 21:36 UTC (permalink / raw)
To: Jan Hudec
Cc: Ismail Dönmez, Git Mailing List, Pavel Roskin, Andy Parkins
In-Reply-To: <20070610175628.GI4084@efreet.light.src>
On 6/10/07, Jan Hudec <bulb@ucw.cz> wrote:
>
> On another side, is there a measurable compilation time improvement with -frepo?
>
No, compilation time is indeed much slower with -frepo, theoretically
we should gain something in bin file size.
But anyway I have removed the option from CXXFLAGS as suggested by
Ismail and pushed the patch. It will be included in rc2.
Thanks a lot to Ismail reporting and fixing and to you for explaining the stuff.
Marco
P.S: In case someone is interested I have found these docs
http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Template-Instantiation.html#Template-Instantiation
^ permalink raw reply
* [StGIT PATCH not for master, v2] Use gitk --argscmd in contrib/stg-gitk.
From: Yann Dirson @ 2007-06-10 21:40 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
This allows to ask gitk to recompute the list of patches to show at
every refresh. Before this, we had problems with 'stg-gitk --all':
- deleting a patch that was existing at startup time would trigger an
"unknown ref" error from gitk and force to quit/restart manually;
- patches created since startup were only visible when applied, or
when below one of the startup patches.
---
This version fixes a couple of glitches when using stg-gitk to display
several branches simultaneously, introduced by the 1st version. This
is a sure sign that this script should be pythonized soon :)
Still not to apply to master, since the gitk patch it depends has not
been applied.
contrib/stg-gitk | 32 +++++++++++++++++++++++++-------
1 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/contrib/stg-gitk b/contrib/stg-gitk
index dd01ef0..c258caf 100755
--- a/contrib/stg-gitk
+++ b/contrib/stg-gitk
@@ -7,7 +7,6 @@ set -e
# patch logs.
# LIMITATIONS:
-# - asking gitk to "update" won't detect any new ref
# - no support for spaces in branch names
# Copyright (c) 2007 Yann Dirson <ydirson@altern.org>
@@ -20,11 +19,16 @@ usage()
}
allbranches=0
-case "$1" in
---all) allbranches=1; shift ;;
---*) usage ;;
-*) break ;;
-esac
+refsonly=0
+while [ "$#" -gt 0 ]; do
+ case "$1" in
+ --refs) refsonly=1 ;;
+ --all) allbranches=1 ;;
+ --*) usage ;;
+ *) break ;;
+ esac
+ shift
+done
if [ $allbranches = 1 ] && [ "$#" -gt 0 ]; then
usage
@@ -58,4 +62,18 @@ else
done
fi
-gitk $(find $refdirs -type f -not -name '*.log' | cut -c${GIT_DIR_SPKIPLEN}- )
+printrefs()
+{
+ find $refdirs -type f -not -name '*.log' | cut -c${GIT_DIR_SPKIPLEN}-
+}
+
+if [ $refsonly = 1 ]; then
+ printrefs
+else
+ # let's use a hack to pass --all, which was consumed during command-line parsing
+ if [ $allbranches = 1 ]; then
+ gitk --argscmd="$0 --refs --all"
+ else
+ gitk --argscmd="$0 --refs $*"
+ fi
+fi
^ permalink raw reply related
* Re: Documentation updates
From: Junio C Hamano @ 2007-06-10 21:43 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20070610205430.GA27119@fieldses.org>
Thanks.
^ permalink raw reply
* Re: [PATCH 2/4] Introduce optional "keywords" on tag objects
From: Junio C Hamano @ 2007-06-10 21:43 UTC (permalink / raw)
To: Johan Herland; +Cc: Johannes Schindelin, git
In-Reply-To: <200706102104.48440.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> For now, I couldn't find a good reason why the set of allowed characters
> for keywords should be smaller than for the tag name.
The set of allowed tag names excludes shell metacharacters,
primarily to help scripting. I think keywords can share the
same reasoning to exclude them.
It also excludes '^', '~' and ':', because tag names can be used
in revision range expressions (i.e. prefix '^' is the "exclude
from the resulting set" operation, postfix "~<number>" is the
"Nth generation ancestor" operation) and general SHA-1
expression (i.e. infix ':' is the "find in the tree-ish the
object at path" operation). These reasons would not apply to
keywords.
Having said all of that, I suspect it is premature to talk about
keywords, as it is unclear what their intended use is. What
kind of operations are useful on them?
It does not count that "git cat-file tag" would show "keywords
blah" on the header instead of in body. It is not a compelling
enough reason to introduce a new header type. grep would work
just fine for such a use.
On the other hand, for example, if (the syntax is totally made
up) we make '::keywords=foo::' expand to set of all tags that
have the specified keyword 'foo', and it turns out to be useful
to be able to say "git show ::keywords=foo::" instead of listing
individual tags, that kind of use case may make it a good reason
to add such a new header type.
^ permalink raw reply
* Re: [PATCH] git-svn: cache max revision in rev_db databases
From: Eric Wong @ 2007-06-10 21:47 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <20070610091304.C3E0413A4F8@magnus.utsl.gen.nz>
Sam Vilain <sam@vilain.net> wrote:
> Cache the maximum revision for each rev_db URL rather than looking it
> up each time. This saves a lot of time when rebuilding indexes on a
> freshly cloned repository.
It looks correct, but I'm not sure how often we can even hit this
optimization to make it worth it.
Any live repositories and benchmarks you've run this on?
(without the rev-list => log patch applied, which would be a big
performance improvement if all log messages were under 16k).
> Signed-off-by: Sam Vilain <sam@vilain.net>
> ---
> git-svn.perl | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 610563c..c9758a0 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -804,6 +804,7 @@ sub working_head_info {
> my ($head, $refs) = @_;
> my ($fh, $ctx) = command_output_pipe('log', $head);
> my $hash;
> + my %max;
> while (<$fh>) {
> if ( m{^commit ($::sha1)$} ) {
> $hash = $1;
> @@ -812,11 +813,14 @@ sub working_head_info {
> next unless s{^\s+(git-svn-id:)}{$1};
> my ($url, $rev, $uuid) = extract_metadata($_);
> if (defined $url && defined $rev) {
> + next if $max{$url} and $max{$url} < $rev;
> if (my $gs = Git::SVN->find_by_url($url)) {
> my $c = $gs->rev_db_get($rev);
> if ($c && $c eq $hash) {
> close $fh; # break the pipe
> return ($url, $rev, $uuid, $gs);
> + } else {
> + $max{$url} ||= $gs->rev_db_max;
> }
> }
> }
--
Eric Wong
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: Matthieu Moy @ 2007-06-10 22:07 UTC (permalink / raw)
To: Jan Hudec; +Cc: Martin Langhoff, git
In-Reply-To: <20070610083754.GC4084@efreet.light.src>
Jan Hudec <bulb@ucw.cz> writes:
> A related thing is Bazaar's "Bundle Buggy". It tracks patch submission rather
> than bugs, but it is roughly what I meant by the "mailing list integration"
> above. It "reads" the mailing list, watching for anything labeled [PATCH] or
> [BUNDLE]
Indeed, the bundle buggy is inspired from the "Bug goo" developed
earlier for GNU Arch. This one was watching mails labeled with [BUG]
on the mailing list.
I found the idea really good. Indeed, as a user, when I find a bug in
a piece of software, I often hesitate between using the bugtracker (in
which case my bug is often mostly ignored), or reporting it on the
mailing list (in which case, a long discussion can follow, at the end
of which everybody thinks that someone else will fix the bug, and no
one actually does). With the bug goo, the bugtracker becomes the
mailing list, with all the advantage of it (discussions easy to
follow, threaded, ...), and a few additions, the biggest of which is
status tracking, in particular, the ability to list all unsolved bugs.
Unfortunately, as most of the GNU Arch stuff, it started with good
ideas, but was abandonned before it started being interesting :-\.
--
Matthieu
^ permalink raw reply
* Re: [Qgit RFC] commit --amend
From: Marco Costalba @ 2007-06-10 22:10 UTC (permalink / raw)
To: Jan Hudec; +Cc: git
In-Reply-To: <20070610150839.GG4084@efreet.light.src>
On 6/10/07, Jan Hudec <bulb@ucw.cz> wrote:
> Hello,
>
> I am thinking about adding commit --amend support to Qgit.
>
Good!
> However I see three ways to do it, so I'd like to ask whether anybody knows
> some reason why any of them is better or worse, which I don't:
>
> - Add a button for "Amend". This would fit with what is there currently,
> because with stgit it has buttons "New patch" and "Add to top" (refresh),
> which correspond exactly to core git's "commit" and "commit --amend"
> respectively.
>
>From 'Edit->commit' menu it is possible to open a dialog to commit
modified files in working dir.
Currently, at the bottom of the dialog there are 4 buttons:
- Settings (to open settings dialog on 'commit options' tab)
- Cancel (to cancel ;-) )
- Sync (to update the index but without writing a new tree)
- Commit (to commit a new revision)
In case the repository is under a StGIT stack the buttons are slightly
different, in particular:
Sync --> becames 'Add to top' (to fold and refresh changes)
Commit --> becames 'New patch' (to create a new patch with selected
modified files)
If I have understood correctly you plan to substitute 'Sync' button
with 'Amend'. Is it correct?
> Disadvantage (for current approach too) is, that when amending (resp.
> refreshing) the previous commit message is not there to be edited.
>
Yes but see below.
> - Add a radio button the way git-gui does. Switching the button to "amend"
> would load the previous commit message.
>
> This would be more invasive change, but it would allow editing the commit
> message when amending/refreshing. I fear it will be more user-error-prone
> too, though.
>
I agree.
> - Add a separate action to the menu. This action would take over the refresh
> (Add to top) operation when using stgit.
>
> I believe this has lower risk of user errors than the previous option. It
> also has the advantage, that I don't have to touch the disabling logic for
> the commit action. Amending last commit is always possible, even if there
> are no changes, because you might want to edit the message (eg. if you
> forget to sign-off or forget to mention some change or something).
>
Yes. But amending is an option of commit (also in git) so probably the
amend action will fire the commit dialog anyway and we are back to
previous situation. The only advantage is that we can load the message
of the tip revision as default instead of git-status output as the
current.
> I'll try doing the first option now, unless somebody persuades me that it's
> a nonsense.
>
I think it's the best: 'Sync' button is very seldom used (I think I've
never used it but for testing that it works) and updating the index is
something very plumbing anyway.
What we could add is another button 'Load prev msg' to do what it
says, so we would end up with 5 buttons:
- Settings /Cancel/ Load prev msg / Amend /Commit
I don't see a reason to set 'Load prev msg' as a check button, you may
want to reload the prev msg as many times as you need, (re)clicking
everytime on the button, also for a normal commit where as example you
want to keep the header or part of the subject of the previous
revision.
Please let me know if and where you find something obscure/messy with
the code, I will be happy to help you.
Marco
^ permalink raw reply
* Re: [PATCH] Introduce light weight commit annotations
From: Junio C Hamano @ 2007-06-10 22:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster, Johan Herland
In-Reply-To: <Pine.LNX.4.64.0706091854330.4059@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> With the provided script, edit-commit-annotations, you can add
> after-the-fact annotations to commits, which will be shown by
> the log if the config variable core.showannotations is set.
>
> The annotations are tracked in a new ref, refs/annotations/commits,
> in the same fan-out style as .git/objects/??/*, only that they only
> exist in the object database now.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> I have the hunch that this will be relatively fast and scalable,
> since the tree objects are sorted by name (the name being the
> object name of the to-be-annotated commit).
The entries of tree are sorted but not necessarily of uniform
length so you end up needing linear search anyway. The fan-out
would help with the current tree objects.
It will hurt _if_ we introduce a new tree object format that
would give you a quick random-access at an entry, but it is
premature to worry about that now.
^ permalink raw reply
* Re: [PATCH] Port git-tag.sh to C.
From: Jeff King @ 2007-06-10 22:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kristian Høgsberg, git
In-Reply-To: <7v7iqdf0gn.fsf@assigned-by-dhcp.cox.net>
On Sat, Jun 09, 2007 at 11:26:48AM -0700, Junio C Hamano wrote:
> > Signed-off-by: Kristian Høgsberg <krh@redhat.com>
> I think your name in your commit message is in UTF-8 but munged your
> mail was mismarked as iso-8859-1.
This is the same git-send-email bug that we fixed recently (missing
MIME-Version header). Just look for the vger "we munged your message"
headers in the version you received.
-Peff
^ permalink raw reply
* Re: [PATCH] Port git-tag.sh to C.
From: Junio C Hamano @ 2007-06-10 22:19 UTC (permalink / raw)
To: Jeff King; +Cc: Kristian Høgsberg, git
In-Reply-To: <20070610221306.GF27340@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> This is the same git-send-email bug that we fixed recently (missing
> MIME-Version header). Just look for the vger "we munged your message"
> headers in the version you received.
Ahh. You are right. The message does have these:
X-Warning: Original message contained 8-bit characters, however during
the SMTP transport session the receiving system did not announce
capability of receiving 8-bit SMTP (RFC 1651-1653), and as this
message does not have MIME headers (RFC 2045-2049) to enable
encoding change, we had very little choice.
X-Warning: We ASSUME it is less harmful to add the MIME headers, and
convert the text to Quoted-Printable, than not to do so,
and to strip the message to 7-bits.. (RFC 1428 Appendix A)
X-Warning: We don't know what character set the user used, thus we had to
write these MIME-headers with our local system default value.
^ permalink raw reply
* Re: [PATCH] Port git-tag.sh to C.
From: Jeff King @ 2007-06-10 22:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kristian Høgsberg, git
In-Reply-To: <7vzm375u7f.fsf@assigned-by-dhcp.cox.net>
On Sun, Jun 10, 2007 at 03:19:00PM -0700, Junio C Hamano wrote:
> > This is the same git-send-email bug that we fixed recently (missing
> > MIME-Version header). Just look for the vger "we munged your message"
> > headers in the version you received.
>
> Ahh. You are right. The message does have these:
Yes, it's easy for me to tell because I get his messages intact. :) Not
to mention his X-Mailer mentions git-send-email 1.5.0.6.
Kristian, the fix is in git 1.5.1.5 and later, if it's not too much
trouble to upgrade.
-Peff
^ permalink raw reply
* Re: [PATCH 1/4] Make tag names (i.e. the tag object's "tag" line) optional
From: Junio C Hamano @ 2007-06-10 22:46 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Johannes Schindelin
In-Reply-To: <200706101349.33280.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> The tag line is now optional. If not given in the tag object data, it
> defaults to the empty string ("") in the parsed tag object.
Sorry, I may have missed the discussion. I recall that we
talked about tagger line which may not exist for historical
reasons, but have we heard any reasoning behind this?
^ permalink raw reply
* Re: [PATCH] Introduce light weight commit annotations
From: Alex Riesen @ 2007-06-10 22:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster, Johan Herland
In-Reply-To: <Pine.LNX.4.64.0706091854330.4059@racer.site>
Johannes Schindelin, Sat, Jun 09, 2007 19:55:10 +0200:
> +MESSAGE="$GIT_DIR"/COMMIT_ANNOTATION.$$
> +git log -1 $COMMIT | sed "s/^/#/" > "$MESSAGE"
> +
> +GIT_INDEX_FILE="$MESSAGE".idx
Because of pid in the filenames, you probably want to cleanup after
the annotation is commited.
^ permalink raw reply
* Re: [PATCH 1/4] Make tag names (i.e. the tag object's "tag" line) optional
From: Johan Herland @ 2007-06-10 23:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vps435sy0.fsf@assigned-by-dhcp.cox.net>
On Monday 11 June 2007, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
>
> > The tag line is now optional. If not given in the tag object data, it
> > defaults to the empty string ("") in the parsed tag object.
>
> Sorry, I may have missed the discussion. I recall that we
> talked about tagger line which may not exist for historical
> reasons, but have we heard any reasoning behind this?
In the discussion that followed the first proof-of-concept of 'notes',
I argued that the "tag" header is _really_ only needed for
signed tag objects (although we want it for annotated tags as well),
and that it doesn't make sense to specify a tag name for unnamed 'note'
objects.
If the "tag" line remains mandatory, I'll have to construct an
artificial name for unnamed 'notes'...
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] Introduce light weight commit annotations
From: Johannes Schindelin @ 2007-06-10 23:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johan Herland
In-Reply-To: <7v4plf7948.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 10 Jun 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > With the provided script, edit-commit-annotations, you can add
> > after-the-fact annotations to commits, which will be shown by
> > the log if the config variable core.showannotations is set.
> >
> > The annotations are tracked in a new ref, refs/annotations/commits,
> > in the same fan-out style as .git/objects/??/*, only that they only
> > exist in the object database now.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >
> > I have the hunch that this will be relatively fast and scalable,
> > since the tree objects are sorted by name (the name being the
> > object name of the to-be-annotated commit).
>
> The entries of tree are sorted but not necessarily of uniform
> length so you end up needing linear search anyway. The fan-out
> would help with the current tree objects.
I do not understand... the entries of a tree object are sorted
alphabetically, right? Including the convention that if one is a prefix of
another, it is "smaller".
While I think that the length would not be any problem, the entries' names
of refs/annotations/commit^{tree} are _all_ of length two, and point to
other tree objects. _Those_ tree objects contain _only_ entries whose
names contain exactly 38 characters.
> It will hurt _if_ we introduce a new tree object format that would give
> you a quick random-access at an entry, but it is premature to worry
> about that now.
I do not see that. Care to enlighten me?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: Martin Langhoff @ 2007-06-10 23:14 UTC (permalink / raw)
To: git, Martin Langhoff
In-Reply-To: <20070610101616.GF2951@artemis>
On 6/10/07, Pierre Habouzit <madcoder@debian.org> wrote:
> On Sun, Jun 10, 2007 at 06:59:13PM +1200, Martin Langhoff wrote:
> >
> > Call me a fool, but writing a <new> bugtracker looks like a
> > boil-the-oceans scheme.
>
> Sure, what if I like it anyway ?
Be my guest. It might turn out to be a beautiful project, but has low
chances of helping GIT-BTS integration in general.
> > Adding git & gitweb support to traq, bugzilla, mantis, gforge, etc is
> > what is going to make the difference. Most of those have already the
> > ability to "link" to one or more commits -- after the commits are done
> > and in GIT.
>
> Sure, you can do that and still inherit from the many downsides of
> those tools: central, needs another separate tool to work with, and a
> tool that nowadays tends to eat 500Mb of your memory if you take the
> most hype implementation of it (Yes I'm describing a web browser), that
> is slow like hell (because yes, there is many clients at the same time
> on the central server, that is overloaded like hell), and so on.
Most usable BTSs work on lighter webbrowsers, and can be tuned to work
reasonably. That's not a dead-end per se.
> You can like central web UIs, your choice. And I suppose if grit works
> well, there will be one at some point.
Bugtrackers are communication tools between developers and users. In
many spaces, they are _teaching tools_, teaching the users about info
developers need. That's why BTSs have explicit fields asking for
important variables like OS, Arch, and version you are reporting a bug
against. That's also why the BTS gains a lot from being web-based:
extreme portability, reachability, zero-install for users.
> > So you can tell your bugtracker
> > - which commit fixed it -- usually auto-linked if you include the
> > bugnumber in the commit message
> > - which commit added the test -- auto linked as above
> > - which commit introduced the bug -- if such thing exists and someone
> > digs it up
>
> yeah, that is what bugtrackers already do. Though, that's of no use
> for release managers. What is useful is what people call "milestones" in
> trac e.g., meaning a set of bugs that has been flagged as needing to be
> fixed. And what a release manager need is a tool to deal with this set
> of bugs as a whole.
Hmmm. Most BTSs have milestones, and the integration of the above with
milestones is useful for release managers. How about the _rest_ of the
BTS-using populace?
> That's the same argument that Linus has against per-file tracking.
> Also atm when you e.g. backport a patch that fixes this or this bug,
> you're no BTS helps you tagging the bug as fixed in that branch as well.
> Not to mention that BTS I know do not make any use of the commits DAG.
> And for a very good reason, there is no real DAG in many existing tools
> (svn, cvs, ...).
Making the BTS DAG-aware is overkill. The BTS can ask for every update
on every branch "what commits does it bring into branch X?" and that's
all you need. If you backport a patch and mention the original patch
SHA1 the BTS can do its job.
And all of that can be done SCM-agnostic - except for the regex to
spot a commitid.
> > And definitely, if you use git as an alibi to write a new bugtracker,
> > don't use the "works only with git" as a feature. It should work with
> > as many SCMs as possible.
>
> No it should not, because it can't. I want the distributed and
> Bug status spanning-DAGS be a central feature.
But you lose portability. And gain... what that you can't do portably?
> You're a lucky guy. All bug trackers I've used suck a way or another,
> that impedes my workflow a lot. Let's cite a couple:
Ok - but BTSs are a compromise, something that must work for users,
and developers.
> > Bugtrackers are co-owned by developers, users and (where they exist)
> > project managers.
>
> That's exactly why distributed rock. Because everyone could _really_
> own _his_ bugtracker. This solves the same range of ACLish issues git
> solves with respect to the code.
Don't think I've seen politics over who owns the bugtracker ;-) but I
_have_ seen politics over specific bugs (developers close unfixed
bugs, flamefests ensue). I guess with a DBTS everyone can have their
own status for the bug... but does that help the user? Or the
developer?
> > Well - hmmm. Git's database is great at tracking _content identity_.
> > But a bug's content identity (description+comments+status) changes all
> > the time. I don't think it's naturally a good match.
>
> Oh, because the code never changes. Doh, how stupid I am :)
> No, really, you name your bug after the sha hash of the first report,
> I think that's pretty obvious. That gives you a bug name. Then you ask
> git for "what's the current sha for this bug in the tip of the BTS
> branch", then you ask "so now what this new sha is pointing to in the
> code". That's a small indirection that I suppose is bearable.
Of course, you _can_ map the DBTS storage on git's storage. But git's
storage has been designed to match the task. While I'm sure there are
some good tricks to reuse, I don't think that it's a good fit.
> > And at git's end we can get the smooth integration using/abusing that
> > loose coupling strategy. So if git-log/gitk/qgit grow some hooks that
> > can be used to perform a lookup... I can think of a perl script that
> > gets events for each SHA1 that git-rev-list produces and returns one
> > bug number, url and title (or more than one) that then git-log / gitk
> > / qgit / annotate can use to further "decorate" the commit info in a
> > similar style to what gitk is doing now with head names in each
> > commit.
> >
> > Would that fit your vision of a nicely integrated tracker?
>
> Honestly ? No, because that would be horribly slow (but I'd love to be
> proven wrong).
What part would be slow?
cheers
martin
^ permalink raw reply
* Re: [PATCH 2/4] Introduce optional "keywords" on tag objects
From: Johan Herland @ 2007-06-10 23:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vabv77ael.fsf@assigned-by-dhcp.cox.net>
On Sunday 10 June 2007, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
> > For now, I couldn't find a good reason why the set of allowed characters
> > for keywords should be smaller than for the tag name.
>
> The set of allowed tag names excludes shell metacharacters,
> primarily to help scripting.
It already does? Or are you proposing this? Right now the code doesn't
enforce anything like this, AFAICS...
> I think keywords can share the same reasoning to exclude them.
>
> It also excludes '^', '~' and ':', because tag names can be used
> in revision range expressions (i.e. prefix '^' is the "exclude
> from the resulting set" operation, postfix "~<number>" is the
> "Nth generation ancestor" operation) and general SHA-1
> expression (i.e. infix ':' is the "find in the tree-ish the
> object at path" operation). These reasons would not apply to
> keywords.
I have nothing against limiting keywords to fairly small set, say
alphanumerics plus a couple of "safe" symbols. It just didn't make
sense to do this when I made the patch without doing it to the
tag name at the same time, and I'm not sure what that restricted
set should be, so I held off on it. Feel free to fix.
> Having said all of that, I suspect it is premature to talk about
> keywords, as it is unclear what their intended use is. What
> kind of operations are useful on them?
>
> It does not count that "git cat-file tag" would show "keywords
> blah" on the header instead of in body. It is not a compelling
> enough reason to introduce a new header type. grep would work
> just fine for such a use.
>
> On the other hand, for example, if (the syntax is totally made
> up) we make '::keywords=foo::' expand to set of all tags that
> have the specified keyword 'foo', and it turns out to be useful
> to be able to say "git show ::keywords=foo::" instead of listing
> individual tags, that kind of use case may make it a good reason
> to add such a new header type.
Yes, this is what I'm thinking; using keywords to filter tag objects in
various settings. Haven't thought much about the syntax yet, but as it
would have to work on the command-line (possibly together with the other
weird characters git uses for specifying revisions), I imagine a character
set similar to the one for tag names should be good.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] Introduce light weight commit annotations
From: Alex Riesen @ 2007-06-10 23:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster, Johan Herland
In-Reply-To: <Pine.LNX.4.64.0706091854330.4059@racer.site>
Johannes Schindelin, Sat, Jun 09, 2007 19:55:10 +0200:
>
> With the provided script, edit-commit-annotations, you can add
> after-the-fact annotations to commits, which will be shown by
> the log if the config variable core.showannotations is set.
>
> The annotations are tracked in a new ref, refs/annotations/commits,
> in the same fan-out style as .git/objects/??/*, only that they only
> exist in the object database now.
>
I like it too. And "notes" _is_ less to type :)
BTW, the annotations are a bit cumbersome to merge, if this
implementation is to stay (and I personally would like it to) we may
have to mention this little inconvenience somewhere.
And can I suggest an interface like the below?
git notes [[--show] <commit>+] [-d|--delete <commit>+] [-e|--edit <commit>]
With the annotations file being completely removed if it is empty.
^ permalink raw reply
* RE: git-svn set-tree bug
From: Joakim Tjernlund @ 2007-06-10 23:27 UTC (permalink / raw)
To: 'Eric Wong'; +Cc: 'git'
In-Reply-To: <20070610213322.GB12222@muzzle>
> -----Original Message-----
> From: Eric Wong [mailto:normalperson@yhbt.net]
> Sent: den 10 juni 2007 23:33
> To: Joakim Tjernlund
> Cc: git
> Subject: Re: git-svn set-tree bug
>
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > On Sat, 2007-06-09 at 18:47 -0700, Eric Wong wrote:
> > > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > > > trying to do git-svn set-tree remotes/trunk..svn
> > > > in my new git-svn repo I get:
> > > > config --get svn-remote.svn.fetch
> :refs/remotes/git-svn$: command returned error: 1
> > >
> > > You need to specify "-i trunk" in the command-line
> > >
> > > git-svn set-tree -i trunk remotes/trunk..svn
> > >
> >
> > Thanks
> >
> > I have found a bug or two. Run this script and
> > see what happens ant the end.
>
> <snip>
>
> > git pull . merge
>
> This is a non-fast-forward merge, giving you non-linear history. git
> understands non-linear history without problems, but svn does not.
>
> > git svn dcommit # this fails
>
> If you have non-linear history, don't use dcommit, use
> set-tree. Linear
> history is cleaner and easier to manage, which is why I recommend
> format-patch/am/dcommit/rebase, and avoid using pull/merge unless it's
> fast-forward.
I see, I figured git-svn could work around that.
So I should do a git svn set-tree -i trunk remotes/trunk..svn
and then git svn rebase? That makes the git history hard to
follow.
hmm, is it wise to mix set-tree and dcommit in one repo?
Is there a way to tell set-tree to commit the whole "merge" branch
as one svn commit?
If I merge the latest kernel into my tree there will
be a lot of commits that I don't want in svn.
Jocke
Jocke
^ permalink raw reply
* Re: [PATCH] Introduce light weight commit annotations
From: Junio C Hamano @ 2007-06-10 23:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Johan Herland
In-Reply-To: <Pine.LNX.4.64.0706102333050.4059@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I do not understand... the entries of a tree object are sorted
> alphabetically, right? Including the convention that if one is a prefix of
> another, it is "smaller".
>
> While I think that the length would not be any problem, the entries' names
> of refs/annotations/commit^{tree} are _all_ of length two, and point to
> other tree objects. _Those_ tree objects contain _only_ entries whose
> names contain exactly 38 characters.
That is ONLY true if you are introducing a specialized tree
object parser that knows it is dealing with the tree used in
your annotation scheme that has entries of uniform size. In
such a tree parser, you could bisect or Newton-Raphson a tree
object data to find an entry more efficiently than for normal
trees with enries of variable size.
But I do not think you are planning to do that (nor I would
recommend you to). With the normal tree parser, the lookup for
"refs/annotations/commit:??/?{38}" you have in your code would
open one tree (the commit's tree), find the one with leading 2
hexdigits you would want among up to 256 entries with linear
search (see tree-walk.c::find_tree_entry()), open that entry
which is another tree, and do the same linear search to find the
entry with the remaining 38 hexdigits. Finding annotation for
commit 0000abcd... is much less expensive than ffff4567...
>> It will hurt _if_ we introduce a new tree object format that would give
>> you a quick random-access at an entry, but it is premature to worry
>> about that now.
>
> I do not see that. Care to enlighten me?
At some point (probably git v3.0.0) we _might_ enhance/extend
the tree object format so that it has an auxiliary hash table to
help you look up an arbitrary entry in a huge tree object (huge
in the sense that readdir(3) returns many entries, not in the
sense that find(1) returns many results) more efficiently. Pack
v4 is rumored to have something like that for in-pack trees.
If that happens, "refs/annotations/commit:?{40}" format would
let you look up an annotation for a given commit much more
efficiently than "refs/annotations/commit:??/?{38}", because it
would have to open only one tree object, instead of two.
^ permalink raw reply
* Re: Please pull mergetool.git
From: Brian Gernhardt @ 2007-06-10 23:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Theodore Ts'o, Git Mailing List
In-Reply-To: <7v1wgj8tzy.fsf@assigned-by-dhcp.cox.net>
On Jun 10, 2007, at 3:55 PM, Junio C Hamano wrote:
> I do not see problems in the mergetool part, other than that I
> mildly suspect that opendiff -- actually FileMerge -- might want
> to be in the test -n "$DISPLAY" section, but that is inherited
> from the previous iteration so in that sense leaving outside is
> a sane thing to do.
Actually, opendiff (as FileMerge.app) is available under OS X, where
$DISPLAY is not set.
~~ Brian
^ permalink raw reply
* Re: git-svn set-tree bug
From: Steven Grimm @ 2007-06-10 23:37 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: 'Eric Wong', 'git'
In-Reply-To: <002a01c7abb6$de2b3680$0e67a8c0@Jocke>
Joakim Tjernlund wrote:
> Is there a way to tell set-tree to commit the whole "merge" branch
> as one svn commit?
> If I merge the latest kernel into my tree there will
> be a lot of commits that I don't want in svn.
>
You want a "squash" merge. Something like this:
git checkout -b tempbranch origin/svn-branch-to-commit-merge-to
git merge --squash branch-with-commits-you-want-to-merge
git commit
git svn dcommit
The "merge" command will merge in the changes but will not commit
anything; when you do the explicit "commit" command afterwards, you get
the contents of the merge but from git's point of view it's just a
regular commit so git-svn doesn't get confused.
After you do git svn dcommit, you may want to edit .git/info/grafts to
tell git after the fact that this commit was a merge. It won't hurt
git-svn at that point and it will mean you can do another merge later
without git getting confused about what has already been merged.
Take a look at the script I posted a while back, which does something
similar:
http://www.spinics.net/lists/git/msg29119.html
-Steve
^ 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