* [PATCH 5/5] Show Difflinks in an other color
From: Martin Koegler @ 2007-09-02 14:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Martin Koegler
In-Reply-To: <11887443693825-git-send-email-mkoegler@auto.tuwien.ac.at>
Suggested by Petr Baudis
The style for the links was randomly selected.
No sign-off, as somebody else should select a suiteable style.
---
gitweb/gitweb.css | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 1b88879..ac15c0e 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -499,3 +499,7 @@ span.match {
div.binary {
font-style: italic;
}
+
+span.difflinks a {
+ color: #ff0000;
+}
--
1.5.3.rc7.849.g2f5f
^ permalink raw reply related
* [PATCH 3/5] gitweb: Add treediff view
From: Martin Koegler @ 2007-09-02 14:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Martin Koegler
In-Reply-To: <11887443693783-git-send-email-mkoegler@auto.tuwien.ac.at>
git_treediff supports comparing different trees. A tree can be specified
either as hash or as base hash and filename.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
---
gitweb/gitweb.perl | 116 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 116 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 5f67d73..4081f51 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -549,6 +549,8 @@ my %actions = (
"tag" => \&git_tag,
"tags" => \&git_tags,
"tree" => \&git_tree,
+ "treediff" => \&git_treediff,
+ "treediff_plain" => \&git_treediff_plain,
"snapshot" => \&git_snapshot,
"object" => \&git_object,
# those below don't need $project
@@ -4962,6 +4964,120 @@ sub git_commitdiff_plain {
git_commitdiff('plain');
}
+sub git_treediff {
+ my $format = shift || 'html';
+ my $expires = '+1d';
+
+ # non-textual hash id's can be cached
+ if (defined $hash && $hash !~ m/^[0-9a-fA-F]{40}$/) {
+ $expires = undef;
+ } elsif (defined $hash_parent && $hash_parent !~ m/^[0-9a-fA-F]{40}$/) {
+ $expires = undef;
+ } elsif (defined $hash_base && $hash_base !~ m/^[0-9a-fA-F]{40}$/) {
+ $expires = undef;
+ } elsif (defined $hash_parent_base && $hash_parent_base !~ m/^[0-9a-fA-F]{40}$/) {
+ $expires = undef;
+ }
+
+ # we need to prepare $formats_nav before any parameter munging
+ my $formats_nav;
+ if ($format eq 'html') {
+ $formats_nav =
+ $cgi->a({-href => href(action=>"treediff_plain",
+ hash=>$hash, hash_parent=>$hash_parent,
+ hash_base=>$hash_base, hash_parent_base=>$hash_parent_base,
+ file_name=>$file_name, file_parent=>$file_parent)},
+ "raw");
+ }
+
+ if (!defined $hash) {
+ if (!defined $hash_base) {
+ die_error(undef,'tree parameter missing');
+ }
+ $hash = $hash_base;
+ $hash .= ":".$file_name if (defined $file_name);
+ }
+
+ if (!defined $hash_parent) {
+ if (!defined $hash_parent_base) {
+ die_error(undef,'tree parameter missing');
+ }
+ $hash_parent = $hash_parent_base;
+ $hash_parent .= ":".$file_parent if (defined $file_parent);
+ }
+
+ # read treediff
+ my $fd;
+ my @difftree;
+ if ($format eq 'html') {
+ open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
+ "--no-commit-id", "--patch-with-raw", "--full-index",
+ $hash_parent, $hash, "--"
+ or die_error(undef, "Open git-diff-tree failed");
+
+ while (my $line = <$fd>) {
+ chomp $line;
+ # empty line ends raw part of diff-tree output
+ last unless $line;
+ push @difftree, $line;
+ }
+
+ } elsif ($format eq 'plain') {
+ open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
+ '-p', $hash_parent, $hash, "--"
+ or die_error(undef, "Open git-diff-tree failed");
+
+ } else {
+ die_error(undef, "Unknown treediff format");
+ }
+
+ # write header
+ if ($format eq 'html') {
+ git_header_html(undef, $expires);
+ if (defined $hash_base && (my %co = parse_commit($hash_base))) {
+ git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);
+ git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
+ } else {
+ print "<div class=\"page_nav\"><br/>$formats_nav<br/></div>\n";
+ print "<div class=\"title\">$hash vs $hash_parent</div>\n";
+ }
+ print "<div class=\"page_body\">\n";
+
+ } elsif ($format eq 'plain') {
+ my $filename = basename($project) . "-$hash-$hash_parent.patch";
+
+ print $cgi->header(
+ -type => 'text/plain',
+ -charset => 'utf-8',
+ -expires => $expires,
+ -content_disposition => 'inline; filename="' . "$filename" . '"');
+
+ print "X-Git-Url: " . $cgi->self_url() . "\n\n";
+ print "---\n\n";
+ }
+
+ # write patch
+ if ($format eq 'html') {
+ git_difftree_body(\@difftree, $file_parent, $file_name, $hash_base, $hash_parent_base);
+ print "<br/>\n";
+
+ git_patchset_body($fd, \@difftree, $file_parent, $file_name, $hash_base, $hash_parent_base);
+ close $fd;
+ print "</div>\n"; # class="page_body"
+ git_footer_html();
+
+ } elsif ($format eq 'plain') {
+ local $/ = undef;
+ print <$fd>;
+ close $fd
+ or print "Reading git-diff-tree failed\n";
+ }
+}
+
+sub git_treediff_plain {
+ git_treediff('plain');
+}
+
sub git_history {
if (!defined $hash_base) {
$hash_base = git_get_head_hash($project);
--
1.5.3.rc7.849.g2f5f
^ permalink raw reply related
* [PATCH 0/5] gitweb: Support for arbitrary diffs
From: Martin Koegler @ 2007-09-02 14:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Martin Koegler
Resend of the complete patch serie (again next).
Patch 1-3 are unchanged.
Patch 4 now only generates the links, if they are enabled.
The header contains a new link to show/hide the links.
The state is remembered via a cookie across pages.
Patch 5 is the foundation for showing the base/diff links
in an other color.
mfg Martin Kögler
PS:
I develop the patches via StGit. If you think that I should publish them
in a different way, please tell me.
^ permalink raw reply
* Re: [PATCH] rebase--interactive: do not use one-or-more (\+) in sed.
From: Johannes Schindelin @ 2007-09-02 14:20 UTC (permalink / raw)
To: Simon 'corecode' Schubert; +Cc: Junio C Hamano, Johannes Sixt, git
In-Reply-To: <46DABD15.4030208@fs.ei.tum.de>
Hi,
On Sun, 2 Sep 2007, Simon 'corecode' Schubert wrote:
> Junio C Hamano wrote:
> > > Just for the record: I believe that \{1,\} might be portable.
> >
> > Yeah, I obviously looked at the page I quoted that describes
> > what's in and what's not in BRE definition ;-)
> >
> > But in practice, I do not recall ever seeing an older sed that
> > did not understand one-or-more \+ *and* understood \{1,\}. Do
> > you?
>
> Yes, BSD sed (at least DragonFly's, so probably as well FreeBSD-4 (dunno
> about later)):
>
> chlamydia % echo 5ab123x | sed -e 's/[a-z]\+/AAA/'
> 5ab123x
> chlamydia % echo 5ab123x | sed -e 's/[a-z]\{1,\}/AAA/'
> 5AAA123x
> chlamydia % echo 5ab123x | sed -E -e 's/[a-z]+/AAA/'
> 5AAA123x
Thank you for a proper argument. I usually ignore hand-waving POSIX
arguments, but a real-world case changes the situation.
Ciao,
Dscho
^ permalink raw reply
* Re: Buffer overflows
From: Johan Herland @ 2007-09-02 13:42 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Reece Dunn, Timo Sirainen, Linus Torvalds
In-Reply-To: <7vtzqg7jrn.fsf@gitster.siamese.dyndns.org>
On Friday 31 August 2007, Junio C Hamano wrote:
> It is well and widely understood idiom to use strlcpy to a
> fixed-sized buffer and checking the resulting length to make
> sure the result would not have overflowed (and if it would have,
> issue an error and die). I would not have anything against a
> set of patches to follow such a pattern.
>
> But a patch to add a non-standard API that nobody else uses,
> without any patch to show the changes to a few places that could
> use the API to demonstrate that the use of API vastly cleans the
> code up and makes it infinitely harder to make mistakes?
>
> The API needs to justify itself to convince the people who needs
> to learn and adjust to that the benefit far outweighes deviation
> from better known patterns, and I do not see that happening in
> Timo's patch.
So in general, git people seem to be saying that:
1. Yes, we agree that the C string library suX0rs badly.
2. There are more than 0 string manipulation bugs (e.g. buffer overflows) in
git. The number may be small or large, but I have yet to see anyone claim
it's _zero_.
3. Timo's patches (in their current form) are not the way to go, because of
non-standard API, implementation problems, whatever...
So why does the discussion end there? Lukas proposed an interesting
alternative in "The Better String Library" (
http://bstring.sourceforge.net/ ). Why has there been lots of bashing on
Timo's efforts, but no critique of bstring? I'd be very keen to know what
the git developers think of it. AFAICS, it seems to fulfill at least _some_
of the problems people find in Timo's patches. Specifically, it claims:
- High performance (better than the C string library)
- Simple usage
I'd also say it's probably more widely used than Timo's patches.
If the only response to Timo's highlighting of string manipulation problems
in git, is for us to flame his patches and leave it at that, then I have no
choice but to agree with him in that security does not seem to matter to
us.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] rebase--interactive: do not use one-or-more (\+) in sed.
From: Simon 'corecode' Schubert @ 2007-09-02 13:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Kastrup, Johannes Sixt, git, Johannes Schindelin
In-Reply-To: <7vfy1xr1lz.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>> Just for the record: I believe that \{1,\} might be portable.
>
> Yeah, I obviously looked at the page I quoted that describes
> what's in and what's not in BRE definition ;-)
>
> But in practice, I do not recall ever seeing an older sed that
> did not understand one-or-more \+ *and* understood \{1,\}. Do
> you?
Yes, BSD sed (at least DragonFly's, so probably as well FreeBSD-4 (dunno
about later)):
chlamydia % echo 5ab123x | sed -e 's/[a-z]\+/AAA/'
5ab123x
chlamydia % echo 5ab123x | sed -e 's/[a-z]\{1,\}/AAA/'
5AAA123x
chlamydia % echo 5ab123x | sed -E -e 's/[a-z]+/AAA/'
5AAA123x
cheers
simon
^ permalink raw reply
* [PATCH] Fix typo in 1.5.3 release notes
From: Miklos Vajna @ 2007-09-02 12:46 UTC (permalink / raw)
To: git, gitster
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/RelNotes-1.5.3.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/RelNotes-1.5.3.txt b/Documentation/RelNotes-1.5.3.txt
index 317c8b9..d03894b 100644
--- a/Documentation/RelNotes-1.5.3.txt
+++ b/Documentation/RelNotes-1.5.3.txt
@@ -152,7 +152,7 @@ Updates since v1.5.2
cloning locally.
- URL used for "git clone" and friends can specify nonstandard SSH port
- by using sh://host:port/path/to/repo syntax.
+ by using ssh://host:port/path/to/repo syntax.
- "git bundle create" can now create a bundle without negative refs,
i.e. "everything since the beginning up to certain points".
--
1.5.2.2
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.5.3
From: Arkadiusz Miskiewicz @ 2007-09-02 12:36 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0709021157120.28586@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Sun, 2 Sep 2007, Arkadiusz Miskiewicz wrote:
>
>> Junio C Hamano wrote:
>>
>> > The latest feature release GIT 1.5.3 is available at the usual
>> > places:
>>
>> Hm,
>>
>> [...]
>>
>> *** t0001-init.sh ***
>> * FAIL 1: plain
>>
>> (
>> unset GIT_DIR GIT_WORK_TREE &&
>> mkdir plain &&
>> cd plain &&
>> git init
>> ) &&
>> check_config plain/.git false unset
>
> Please try the verbose mode: cd t/ && sh t0001-init.sh -i -v. If that
> does not show you _what_ the problem is, try "sh -x [...]".
>
> If you still cannot find what the problem is, please tell us what platform
> you're running on, and show us the output of the "-i -v" invocation.
Found out why this happens. My /bin/sh is pdksh (not bash).
AAAA was never set and:
/bin/sh (pdksh)
[arekm@carme-pld ~]$ unset AAAA
[arekm@carme-pld ~]$ echo $?
1
/bin/bash
[arekm@carme-pld ~]$ unset AAAA
[arekm@carme-pld ~]$ echo $?
0
It's pdksh bug, susv3 says "Unsetting a variable or function that was not
previously set shall not be considered an error and does not cause the
shell to abort."
Going to fix pdksh then.
> Ciao,
> Dscho
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
^ permalink raw reply
* Re: [PATCH] send-email: Add support for SSL and SMTP-AUTH
From: Johannes Schindelin @ 2007-09-02 12:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Douglas Stockwell, git, Douglas Stockwell
In-Reply-To: <7vveatpklg.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 2 Sep 2007, Junio C Hamano wrote:
> Thanks for the patch. I think SMTP-AUTH is a worthy addition.
>
> I however have a bit of reservation about making the password
> itself a configuration variable.
Why not have the password in $HOME/.netrc, and ask interactively if none
was found?
Ciao,
Dscho
^ permalink raw reply
* Re: git-gui i18n status?
From: Johannes Schindelin @ 2007-09-02 12:29 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Christian Stimming, Miklos Vajna, Nanako Shiraishi,
Michele Ballabio, Paolo Ciarrocchi, Xudong Guan,
Harri Ilari Tapio Liusvaara, Junio C Hamano, Irina Riesen, git
In-Reply-To: <20070902014242.GJ18160@spearce.org>
Hi,
On Sat, 1 Sep 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > I'll also try to bug Christian into looking through the output of
> >
> > git grep \" -- \*.sh \*.tcl | grep -vwe mc -e bind | less
> >
> > to make sure that we did not forget a string. ATM the output consists
> > of 300+ lines, so it is a bit boring. Maybe I can improve that
> > command, too...
I'll have a look at them; no need to have them in the initial i18n commit,
right? Especially since the translations cannot contain them yet.
Ciao,
Dscho
P.S.: I seem to remember that Christian is away, so maybe we should just
move forward. So I'll first prepare the patch series (minus the changes
you have in pu).
^ permalink raw reply
* Re: git-gui i18n status?
From: Johannes Schindelin @ 2007-09-02 12:20 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Christian Stimming, Miklos Vajna, Nanako Shiraishi,
Michele Ballabio, Paolo Ciarrocchi, Xudong Guan,
Harri Ilari Tapio Liusvaara, Junio C Hamano, Irina Riesen, git
In-Reply-To: <20070902022444.GK18160@spearce.org>
Hi,
On Sat, 1 Sep 2007, Shawn O. Pearce wrote:
> "Shawn O. Pearce" <spearce@spearce.org> wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > Hmm. I am not enough involved in i18n stuff to form a proper opinion
> > > here... Do you suggest to move the initialisation earlier?
> >
> > Yea, I think that's what we are going to have to do here. If we don't
> > setup the directory for the .msg files early enough than we cannot do
> > translations through [mc]. Unfortunately that means we have to also
> > break up the library initialization.
> >
> > I'll try to work up a patch that does this.
>
> This two patch series is based on my current master (gitgui-0.8.2).
> Its also now in my pu branch.
Sound both good to me. Christian?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Teach "git remote add" a mirror mode
From: Johannes Schindelin @ 2007-09-02 11:45 UTC (permalink / raw)
To: gitster, git
When using the "--mirror" option to "git remote add", the refs will not
be stored in the refs/remotes/ namespace, but in refs/heads/.
This option probably only makes sense in a bare repository.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/git-remote.txt | 6 +++++-
git-remote.perl | 10 +++++++++-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 61a6022..94b9f17 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git-remote'
-'git-remote' add [-t <branch>] [-m <branch>] [-f] <name> <url>
+'git-remote' add [-t <branch>] [-m <branch>] [-f] [--mirror] <name> <url>
'git-remote' show <name>
'git-remote' prune <name>
'git-remote' update [group]
@@ -45,6 +45,10 @@ multiple branches without grabbing all branches.
With `-m <master>` option, `$GIT_DIR/remotes/<name>/HEAD` is set
up to point at remote's `<master>` branch instead of whatever
branch the `HEAD` at the remote repository actually points at.
++
+In mirror mode, enabled with `--mirror`, the refs will not be stored
+in the 'refs/remotes/' namespace, but in 'refs/heads/'. This option
+only makes sense in bare repositories.
'show'::
diff --git a/git-remote.perl b/git-remote.perl
index 01cf480..e00b340 100755
--- a/git-remote.perl
+++ b/git-remote.perl
@@ -276,9 +276,13 @@ sub add_remote {
$git->command('config', "remote.$name.url", $url);
my $track = $opts->{'track'} || ["*"];
+ my $prefix = "refs/remotes/$name/";
+ if ($opts->{'mirror'}) {
+ $prefix = "refs/heads/";
+ }
for (@$track) {
$git->command('config', '--add', "remote.$name.fetch",
- "+refs/heads/$_:refs/remotes/$name/$_");
+ "+refs/heads/$_:$prefix/$_");
}
if ($opts->{'fetch'}) {
$git->command('fetch', $name);
@@ -409,6 +413,10 @@ elsif ($ARGV[0] eq 'add') {
shift @ARGV;
next;
}
+ if ($opt eq '--mirror') {
+ $opts{'mirror'} = 1;
+ next;
+ }
add_usage();
}
if (@ARGV != 3) {
--
1.5.3.2.g46909
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.5.3
From: Alex Riesen @ 2007-09-02 11:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Arkadiusz Miskiewicz, git
In-Reply-To: <Pine.LNX.4.64.0709021157120.28586@racer.site>
Johannes Schindelin, Sun, Sep 02, 2007 12:59:04 +0200:
> Hi,
>
> On Sun, 2 Sep 2007, Arkadiusz Miskiewicz wrote:
>
> > Junio C Hamano wrote:
> >
> > > The latest feature release GIT 1.5.3 is available at the usual
> > > places:
> >
> > Hm,
> >
> > [...]
> >
> > *** t0001-init.sh ***
> > * FAIL 1: plain
> >
> > (
> > unset GIT_DIR GIT_WORK_TREE &&
> > mkdir plain &&
> > cd plain &&
> > git init
> > ) &&
> > check_config plain/.git false unset
>
> Please try the verbose mode: cd t/ && sh t0001-init.sh -i -v. If that
> does not show you _what_ the problem is, try "sh -x [...]".
if that is buggy bash-2.05b the problem will just disappear.
I don't remember what it was when I first met this, but it seemed to be
very specific to this particular version of bash.
^ permalink raw reply
* Re: [PATCH] send-email: Add support for SSL and SMTP-AUTH
From: David Symonds @ 2007-09-02 11:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Douglas Stockwell, git, Douglas Stockwell
In-Reply-To: <7vveatpklg.fsf@gitster.siamese.dyndns.org>
On 02/09/07, Junio C Hamano <gitster@pobox.com> wrote:
> So it might be better to split the configuration variables in this
> way:
>
> (1) in ~/.gitconfig (that is hopefully readable only by the
> user):
Perhaps git should then start warning if ~/.gitconfig is world (and
probably group) readable/writeable, a la ssh's ~/.ssh/X (for various
values of X)?
Dave.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3
From: Johannes Schindelin @ 2007-09-02 10:59 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: git
In-Reply-To: <fbdt3q$lcf$1@sea.gmane.org>
Hi,
On Sun, 2 Sep 2007, Arkadiusz Miskiewicz wrote:
> Junio C Hamano wrote:
>
> > The latest feature release GIT 1.5.3 is available at the usual
> > places:
>
> Hm,
>
> [...]
>
> *** t0001-init.sh ***
> * FAIL 1: plain
>
> (
> unset GIT_DIR GIT_WORK_TREE &&
> mkdir plain &&
> cd plain &&
> git init
> ) &&
> check_config plain/.git false unset
Please try the verbose mode: cd t/ && sh t0001-init.sh -i -v. If that
does not show you _what_ the problem is, try "sh -x [...]".
If you still cannot find what the problem is, please tell us what platform
you're running on, and show us the output of the "-i -v" invocation.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Improve bash prompt to detect merge / rebase in progress
From: Robin Rosenberg @ 2007-09-02 10:40 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano, spearce
In-Reply-To: <20070902101825.1938C576FA@dx.sixt.local>
söndag 02 september 2007 skrev Johannes Sixt:
> Robin Rosenberg wrote:
> > + if [ -d "$g/../.dotest" ]
> > + then
> > + ...
> > + else
> > + if [ -d "$g/.dotest-merge" ]
> > + then
> > + ...
> > + else
> > + if [ -f "$g/MERGE_HEAD" ]
> > + then
> > + ...
> > + else
> > + ...
> > + fi
> > + fi
> > + fi
>
> You can use 'elif' to avoid the increasing indentation.
>
> -- Hannes
Ofcourse :)
-- robin
From a0cce4fd418dc3ba715566980aa901dd12791b66 Mon Sep 17 00:00:00 2001
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Date: Sat, 1 Sep 2007 12:20:48 +0200
Subject: [PATCH] Improve bash prompt to detect various states like an unfinished merge
This patch makes the git prompt (when enabled) show if a merge or a
rebase is unfinished. It also detects if a bisect is being done as
well as detached checkouts.
An uncompleted git-am cannot be distinguised from a rebase (the
non-interactive version). Instead of having an even longer prompt
we simply ignore that and hope the power users that use git-am knows
the difference.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
contrib/completion/git-completion.bash | 33 ++++++++++++++++++++++++++++---
1 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 5ed1821..433be3a 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -64,12 +64,37 @@ __gitdir ()
__git_ps1 ()
{
- local b="$(git symbolic-ref HEAD 2>/dev/null)"
- if [ -n "$b" ]; then
+ local g="$(git rev-parse --git-dir 2>/dev/null)"
+ if [ -n "$g" ]; then
+ local r
+ local b
+ if [ -d "$g/../.dotest" ]
+ then
+ local b="$(git symbolic-ref HEAD 2>/dev/null)"
+ r="|REBASING"
+ elif [ -d "$g/.dotest-merge" ]
+ then
+ r="|REBASING"
+ b="$(cat $g/.dotest-merge/head-name)"
+ elif [ -f "$g/MERGE_HEAD" ]
+ then
+ r="|MERGING"
+ b="$(git symbolic-ref HEAD 2>/dev/null)"
+ else
+ if [ -f $g/BISECT_LOG ]
+ then
+ r="|BISECTING"
+ fi
+ if ! b="$(git symbolic-ref HEAD 2>/dev/null)"
+ then
+ b="$(cut -c1-7 $g/HEAD)..."
+ fi
+ fi
+
if [ -n "$1" ]; then
- printf "$1" "${b##refs/heads/}"
+ printf "$1" "${b##refs/heads/}$r"
else
- printf " (%s)" "${b##refs/heads/}"
+ printf " (%s)" "${b##refs/heads/}$r"
fi
fi
}
--
1.5.3
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.5.3
From: Alex Riesen @ 2007-09-02 10:28 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: git, linux-kernel
In-Reply-To: <fbdt3q$lcf$1@sea.gmane.org>
Arkadiusz Miskiewicz, Sun, Sep 02, 2007 10:43:38 +0200:
> *** t0001-init.sh ***
> * FAIL 1: plain
>
> (
> unset GIT_DIR GIT_WORK_TREE &&
> mkdir plain &&
> cd plain &&
> git init
> ) &&
> check_config plain/.git false unset
>
> * ok 2: plain with GIT_WORK_TREE
> * FAIL 3: plain bare
>
> (
> unset GIT_DIR GIT_WORK_TREE GIT_CONFIG &&
> mkdir plain-bare-1 &&
> cd plain-bare-1 &&
> git --bare init
> ) &&
> check_config plain-bare-1 true unset
>
Do you have bash-2.05b as /bin/sh ?
^ permalink raw reply
* Re: [PATCH] Improve bash prompt to detect merge / rebase in progress
From: Johannes Sixt @ 2007-09-02 10:18 UTC (permalink / raw)
To: Robin Rosenberg, git, Junio C Hamano, spearce
In-Reply-To: <200709020152.30070.robin.rosenberg@dewire.com>
Robin Rosenberg wrote:
> + if [ -d "$g/../.dotest" ]
> + then
> + ...
> + else
> + if [ -d "$g/.dotest-merge" ]
> + then
> + ...
> + else
> + if [ -f "$g/MERGE_HEAD" ]
> + then
> + ...
> + else
> + ...
> + fi
> + fi
> + fi
You can use 'elif' to avoid the increasing indentation.
-- Hannes
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3
From: H. Peter Anvin @ 2007-09-02 9:57 UTC (permalink / raw)
To: David Kastrup; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <85odgltrtj.fsf@lola.goethe.zz>
David Kastrup wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>> Junio C Hamano wrote:
>>> * For people who need to import from Perforce, a front-end for
>>> fast-import is in contrib/fast-import/.
>>>
>> There seems to be an issue with this and RPMS.
>>
>> In particular, there is no longer a git-p4 RPMS, which prevents git
>> from getting upgraded at all by yum.
>>
>> Anyone who knows yum well enough to explain what needs to be done so
>> that yum knows this is obsolete?
>
> Probably a matter of the correct spec file. In auctex.spec, we have
>
From the looks of it, there is still a git-p4, it just moved to contrib
and uses fast-import, so removing its rpm package was probably broken in
the first place.
"make rpm" is also broken for "dirty" builds, which is bad for testing.
-hpa
^ permalink raw reply
* Re: [PATCH] send-email: Add support for SSL and SMTP-AUTH
From: Wincent Colaiuta @ 2007-09-02 9:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Douglas Stockwell, git, Douglas Stockwell
In-Reply-To: <7vveatpklg.fsf@gitster.siamese.dyndns.org>
El 2/9/2007, a las 9:55, Junio C Hamano escribió:
> So it might be better to split the configuration variables in this
> way:
>
> (1) in ~/.gitconfig (that is hopefully readable only by the
> user):
>
> [sendemail "default"]
> server = mail.isp.com
> user = junkio
> pass = junkio-password-for-mail-isp-com
>
> [sendemail "git"]
> server = mail.git.xz
> user = gitster
> pass = gitster-password-for-mail-git.xz
>
> This defines two "mail identities" I could use, depending
> on which project's repository I run send-email.
>
> (2) in project/.git/config:
>
> [sendemail]
> identity = git
>
> This defines which "mail identity" I want to use for this
> particular project.
>
> This way, you can maintain more than one identity by having
> multiple [sendemail "$identity"] sections in ~/.gitconfig, and
> avoid having to expose and duplicate user/pass in various
> project's .git/config.
Sounds like a good plan.
Wincent
^ permalink raw reply
* git clone over http
From: Robin Rosenberg @ 2007-09-02 9:23 UTC (permalink / raw)
To: git
git clone (1.5.3) with http is somewhat unreliable. I've noticed if can actually give
me different versions of a branch each time I run it, eventually yielding
the one I'm expecting. And now this:
(Using master, just after rc7)
$ git clone http://unix.schottelius.org/git/cLinux/cinit.git
Initialized empty Git repository in /home/me/tmp/cinit/.git/
got c56b79346e5058762db82cb98647628ddf3d6ebd
walk c56b79346e5058762db82cb98647628ddf3d6ebd
got c0d6c3ae3b4999892d7cbc22fd719c0e9797be59
got 73dc306099bdb21abf22e4a015d3059e8577bb49
got 6943289356f8431073cb8c7708bb7c9c05888333
walk 6943289356f8431073cb8c7708bb7c9c05888333
Getting alternates list for http://unix.schottelius.org/git/cLinux/cinit.git
got 3912109b5cd65a68039d473c11c9f7ac2303e06d
got 0fbf76f58b248f6b11421db5aa9c02fe12b0ce7d
Getting pack list for http://unix.schottelius.org/git/cLinux/cinit.git
got 3ac57ee54f4c4e350622888c4e37213a7d2337b7
got a170a50db31947dfae0b27d5dd8bb54b5ac97b20
got 00f2651b7c63c56fda93d2f94cc2a2b7c28ac86b
Getting index for pack 119f90491743d6454866ba8761f49757e359cec1
got eec4105805e9f57b27158f847c9ce1b2b6eb40c7
got 8a686b4ae9cbb91a74ff71984baee0c944950c05
Getting index for pack 22000d3bf6fc9fdf439f63c8b33817f5786298f6
got dc4d9d9a69310c7d4f8e1fdf6517c10e8c6ab227
Getting index for pack 41850f3f697748a77d37d4d210415031bc6c73c4
/usr/local/bin/git-clone: line 40: 14823 Segmenteringsfel git-http-fetch $v -a -w "$tname" "$sha1" "$1"
It doesn't repeat itself, but I cannot clone because it always crashes.
[me@lathund tmp]$ git clone http://unix.schottelius.org/git/cLinux/cinit.git
Initialized empty Git repository in /home/me/tmp/cinit/.git/
got c56b79346e5058762db82cb98647628ddf3d6ebd
walk c56b79346e5058762db82cb98647628ddf3d6ebd
got c0d6c3ae3b4999892d7cbc22fd719c0e9797be59
got 73dc306099bdb21abf22e4a015d3059e8577bb49
got 6943289356f8431073cb8c7708bb7c9c05888333
walk 6943289356f8431073cb8c7708bb7c9c05888333
got 0fbf76f58b248f6b11421db5aa9c02fe12b0ce7d
Getting alternates list for http://unix.schottelius.org/git/cLinux/cinit.git
got 3912109b5cd65a68039d473c11c9f7ac2303e06d
!! now wait a minute. Why isn't it getting 0fbf76f58b248f6b11421db5aa9c02fe12b0ce7d
here like it did?
Getting pack list for http://unix.schottelius.org/git/cLinux/cinit.git
got a170a50db31947dfae0b27d5dd8bb54b5ac97b20
got 00f2651b7c63c56fda93d2f94cc2a2b7c28ac86b
Getting index for pack 119f90491743d6454866ba8761f49757e359cec1
got eec4105805e9f57b27158f847c9ce1b2b6eb40c7
etc a hundred objects or so:
got f0d2e75fa8247f246aeb8ecdadd94d307481ea78
got 3b01bfe1a064a4407bd6308cc4f02fcc2ac0d9a7
got 3c54e71aca555fcfc163809669aa39426cb52421
got 750e330305676e09479f63532782ce93462e71f5
*** glibc detected *** git-http-fetch: corrupted double-linked list: 0x080dd9f0 ***
======= Backtrace: =========
/lib/i686/libc.so.6[0x44c99516]
/lib/i686/libc.so.6[0x44c9b728]
/lib/i686/libc.so.6(__libc_malloc+0x85)[0x44c9d075]
/lib/libz.so.1(zcalloc+0x20)[0x44d9dfd0]
git-http-fetch[0x804cb78]
git-http-fetch[0x804ae2b]
git-http-fetch[0x804aeab]
git-http-fetch[0x804d265]
git-http-fetch[0x804a732]
git-http-fetch[0x804c240]
/lib/i686/libc.so.6(__libc_start_main+0xdc)[0x44c4bd8c]
git-http-fetch[0x804a071]
I'll spare you the detfailt unless you want it.
-- robin
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3
From: Arkadiusz Miskiewicz @ 2007-09-02 8:43 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <7vodglr32i.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> The latest feature release GIT 1.5.3 is available at the usual
> places:
Hm,
/usr/bin/make -C t/ all
make[1]: Entering directory `/home/users/arekm/rpm/BUILD/git-1.5.3/t'
*** t0000-basic.sh ***
* ok 1: .git/objects should be empty after git init in an empty repo.
* ok 2: .git/objects should have 3 subdirectories.
* ok 3: git update-index without --add should fail adding.
* ok 4: git update-index with --add should succeed.
* ok 5: writing tree out with git write-tree
* ok 6: validate object ID of a known tree.
* ok 7: git update-index without --remove should fail removing.
* ok 8: git update-index with --remove should be able to remove.
* ok 9: git write-tree should be able to write an empty tree.
* ok 10: validate object ID of a known tree.
* ok 11: adding various types of objects with git update-index --add.
* ok 12: showing stage with git ls-files --stage
* ok 13: validate git ls-files output for a known tree.
* ok 14: writing tree out with git write-tree.
* ok 15: validate object ID for a known tree.
* ok 16: showing tree with git ls-tree
* ok 17: git ls-tree output for a known tree.
* ok 18: showing tree with git ls-tree -r
* ok 19: git ls-tree -r output for a known tree.
* ok 20: showing tree with git ls-tree -r -t
* ok 21: git ls-tree -r output for a known tree.
* ok 22: writing partial tree out with git write-tree --prefix.
* ok 23: validate object ID for a known tree.
* ok 24: writing partial tree out with git write-tree --prefix.
* ok 25: validate object ID for a known tree.
* ok 26: put invalid objects into the index.
* ok 27: writing this tree without --missing-ok.
* ok 28: writing this tree with --missing-ok.
* ok 29: git read-tree followed by write-tree should be idempotent.
* ok 30: validate git diff-files output for a know cache/work tree state.
* ok 31: git update-index --refresh should succeed.
* ok 32: no diff after checkout and git update-index --refresh.
* ok 33: git commit-tree records the correct tree in a commit.
* ok 34: git commit-tree records the correct parent in a commit.
* ok 35: git commit-tree omits duplicated parent in a commit.
* ok 36: update-index D/F conflict
* ok 37: absolute path works as expected
* passed all 37 test(s)
*** t0001-init.sh ***
* FAIL 1: plain
(
unset GIT_DIR GIT_WORK_TREE &&
mkdir plain &&
cd plain &&
git init
) &&
check_config plain/.git false unset
* ok 2: plain with GIT_WORK_TREE
* FAIL 3: plain bare
(
unset GIT_DIR GIT_WORK_TREE GIT_CONFIG &&
mkdir plain-bare-1 &&
cd plain-bare-1 &&
git --bare init
) &&
check_config plain-bare-1 true unset
* ok 4: plain bare with GIT_WORK_TREE
* ok 5: GIT_DIR bare
* ok 6: GIT_DIR non-bare
* ok 7: GIT_DIR & GIT_WORK_TREE (1)
* ok 8: GIT_DIR & GIT_WORK_TREE (2)
* failed 2 among 8 test(s)
make[1]: *** [t0001-init.sh] Error 1
make[1]: Leaving directory `/home/users/arekm/rpm/BUILD/git-1.5.3/t'
verified on 2 machines (so /dev/ is ok this time)
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
^ permalink raw reply
* Git User's Survey 2007 partial summary
From: Jakub Narebski @ 2007-09-02 8:33 UTC (permalink / raw)
To: git
In-Reply-To: <200708190128.43515.jnareb@gmail.com>
This is partial summary of Git User's Survey 2007 after 2 weeks of
running. It is based on "View Text Results" page:
http://www.survey.net.nz/members.php?page=results&qn=1304
The same information but in graphical form you can see at
http://www.survey.net.nz/results.php?94e135ff41e871a1ea5bcda3ee1856d9
10. What other SCM did/do you use?
Note that this question does not distinguish between SCMs/VCSs which
were used prior to Git and used no longer, SCMs which are used beside
(in parallel) to Git perhaps interacting with Git, and SCMs which are
used instead of Git. Also note that this is _Git User's_ survey, so it
those number for example do not represent number of e.g. users of
Mercurial as compared to e.g. users of Subversion.
Below there is table of SCM used, sorted by the number of responses.
Note that annotations (like "a little CVS") were not weighted here.
There were 502 responses, 25 null responses (eviovalent to "none").
Only SCMs which has count more that 10 are shown. One person can (and
usually did) chose more than one SCM.
Name Count
--------------------------------------------------
Subversion 399
CVS 362
Mercurial 73
Darcs 59
GNU Arch 52
RCS 45
Bazaar-NG 40
Perforce 34
ClearCase 31
Monotone 23
BitKeeper 23
Bazaar 17
SVK 16
SourceSafe 11
SCCS 10
tla+baz+bzr 109
As you can see two most popular SCMs are Subversion ('svn') and CVS,
with Subversion being slightly more popular. Among distributed SCMs
with most count are Mercurial ('hg') and Arch and its descendants
('tla', 'baz', 'bzr').
35. How does GIT compare to other SCM tools you have used?
Answer Count
------------------------------------------------
Better 388
Comparable (equal) 73
Worse 24
TOTAL 485 (129 null)
Clearly Git is superior SCM! (In the minds of _Git users_) ;-)
Seriously, one should take into consideration that those results
are biased, because it is _Git User's_ Survey, and people usually
choose SCM because they think it is best choice.
No answer (null answer) might mean that responder does not use and did
not use other SCMs to compare, or at least think that he/she does not
have sufficient basis for a comparison.
====================================================================
26. Which porcelains do you use?
Multiple answers (one can use more than one porcelain).
Porcelain Count
------------------------------------------------
core-git 428
Cogito (deprecated) 45
Patch management interface layers:
..................................
StGIT 37
Guilt (formerly gq) 13
pg (deprecated, abandoned) 7
my own scripts 74
other 11
It is understandable that Cogito still has some users, even though it is
deprecated, and [I think] all of its functionality can be found in
git-core porcelain. It was meant as SCM / porcelain layer when git-core
didn't have it and consisted almost only of plumbing commands.
Quite a bit of people use patch management interface: StGIT, Guilt, even
deprecated and abandoned pg (Patchy Git). StGIT has more users than
Guilt, although that might be caused by the fact that StGIT was here
longer...
It is interesting that quite a bit of responders script their git usage:
74 "my own script" users.
I am wondering what those 11 other are...
27. Which git GUI do you use?
Multiple answers (one can use more than one GUI). Note that for the
first week and a bit of survey "CLI" answer had no explanation that it
means command line interface, so results might be bit skewed.
GUI Count
------------------------------------------------
CLI (command line) 295
gitk 266
git-gui 91
qgit 68
giggle 43
gitview 13
instaweb 13
tig 38
(h)gct 3
qct 3
KGit 7
git.el 25
other 10
giggle + gitview 56
As one can see almost as many people use gitk as CLI. Most used GUI are
gitk and git-gui, most probably because they are distributed with git,
and because they are portable. QGit is also quite popular, although
GTK+ viewers, namely giggle and gitview have the same count summary
(note that there might be instances of users using both giggle and
gitview). I am a bit suprised about Giggle, I'd say.
Tig (text-mode interface for git) and git.el (GIT mode for Emacs) are
also quite popular.
I wonder what are those 10 other GUI... and I didn't provide "What is
this 'other GUI'?" question...
=====================================================================
44. Do you use the GIT wiki?
233 yes, 239 no, 112 no answer
56. Do you read the mailing list?
168 yes, 303 no, 114 no answer
59. Do you use the IRC channel (#git on irc.freenode.net)?
148 yes, 281 no, 198 no answer
(I do wonder a bit about "no answer" here. Does it mean: "There is git
wiki/git mailing list/#git IRC channel?!? I didn't know."? Or does it
mean something else: "I was too tired to answer this question...")
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [ANNOUNCE] git/gitweb.git repository
From: Jakub Narebski @ 2007-09-01 17:54 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Luben Tuikov
In-Reply-To: <20070831000149.GK1219@pasky.or.cz>
On Friday, 31 August 2007, Petr Baudis wrote:
> Please feel encouraged to make random forks for your development
> efforts, or push your random patches (preferrably just bugfixes,
> something possibly controversial should be kept in safe containment
> like a fork or separate branch) to the mob branch.
What are the rules of pushing to the mob branch? Fetch, rebase, push?
Does mob branch allows non fast-forward pushes?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3
From: David Kastrup @ 2007-09-02 8:06 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <46DA5F33.2020005@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Junio C Hamano wrote:
>>
>> * For people who need to import from Perforce, a front-end for
>> fast-import is in contrib/fast-import/.
>>
>
> There seems to be an issue with this and RPMS.
>
> In particular, there is no longer a git-p4 RPMS, which prevents git
> from getting upgraded at all by yum.
>
> Anyone who knows yum well enough to explain what needs to be done so
> that yum knows this is obsolete?
Probably a matter of the correct spec file. In auctex.spec, we have
Summary: Enhanced TeX modes for Emacsen
Name: auctex
Version: 11.84
Release: 1%{distri}
License: GPL
Group: %{commongroup}
URL: http://www.gnu.org/software/auctex/
Source0: ftp://ftp.gnu.org/pub/gnu/auctex/%{name}-%{version}.tar.gz
BuildArchitectures: noarch
BuildRoot: %{_tmppath}/%{name}-root
%description
AUCTeX is [...]
%package emacs
Summary: Enhanced TeX modes for GNU Emacs
Group: %{commongroup}
Requires: emacs >= 21
Obsoletes: ge_auc emacs-auctex auctex preview-latex-emacs
Conflicts: emacspeak < 18
Provides: auctex
So auctex-emacs obsoletes the previous "auctex" package and some other
packages. It also provides "auctex" since some other packages might
require it.
Basically, you need to provide everything that a third-party package
might have asked for, and you need to obsolete everything that you
intend to replace.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ 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