* Re: [PATCH 3/3] Added diff hunk coloring to git-add--interactive
From: Junio C Hamano @ 2007-11-11 10:00 UTC (permalink / raw)
To: Dan Zwell
Cc: Jeff King, Shawn O. Pearce, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <20071110180344.05a81497@paradox.zwell.net>
Dan Zwell <dzwell@zwell.net> writes:
> +sub colored_diff_hunk {
> + my ($text) = @_;
> + # return the text, so that it can be passed to print()
> + my @ret;
> + for (@$text) {
> + if (!$diff_use_color) {
> + push @ret, $_;
> + next;
> + }
It would be better to do the "if (!$diff_use_color)" part
upfront before entering the loop, wouldn't it?
sub colored_diff_hunk {
my ($text) = @_;
if (!$diff_use_color) {
return @$text;
}
my @ret;
for (@$text) {
...
}
}
^ permalink raw reply
* Re: [PATCH 3/3] --format=pretty: avoid calculating expensive expansions twice
From: Junio C Hamano @ 2007-11-11 10:29 UTC (permalink / raw)
To: René Scharfe
Cc: Jeff King, Paul Mackerras, Git Mailing List, Pierre Habouzit,
Johannes Schindelin
In-Reply-To: <47359382.1010600@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> +static int add_again(struct strbuf *sb, struct chunk *chunk)
> +{
> + if (chunk->len) {
> + strbuf_adddup(sb, chunk->off, chunk->len);
> + return 1;
> + }
> +
> + /*
> + * We haven't seen this chunk before. Our caller is surely
> + * going to add it the hard way now. Remember the most likely
> + * start of the to-be-added chunk: the current end of the
> + * struct strbuf.
> + */
> + chunk->off = sb->len;
> + return 0;
> +}
> +
> static void parse_commit_header(struct format_commit_context *context)
> {
> const char *msg = context->commit->buffer;
> @@ -447,15 +469,21 @@ static void format_commit_item(struct strbuf *sb, const char *placeholder,
> strbuf_addstr(sb, sha1_to_hex(commit->object.sha1));
> return;
> case 'h': /* abbreviated commit hash */
> + if (add_again(sb, &c->abbrev_commit_hash))
> + return;
> strbuf_addstr(sb, find_unique_abbrev(commit->object.sha1,
> DEFAULT_ABBREV));
> + c->abbrev_commit_hash.len = sb->len - c->abbrev_commit_hash.off;
> return;
Brilliant. Doubly brilliant is the adddup abstraction that does
not suffer from underlying strbuf being reallocated.
Me likee..
^ permalink raw reply
* Re: Subject: [PATCH 2/3] Let git-add--interactive read colors from .gitconfig
From: Junio C Hamano @ 2007-11-11 10:34 UTC (permalink / raw)
To: Dan Zwell
Cc: Jeff King, Shawn O. Pearce, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <7vve89f6qy.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Makes me wonder if you are better off with two new helper
> functions defined in Git.pm, as in:
>
> $prompt_color = $repo->config_color("interactive.prompt") || "bold blue")
> $normal_color = Git::color_to_ansi_code("normal");
Sorry, but please disregard. "bold blue" part was also
parameter to the string-to-ansi-color-escape function, so the
above does not make much sense.
^ permalink raw reply
* Re: gitk/git-gui misfeature: saving the geometry can the window out of reach
From: Shawn O. Pearce @ 2007-11-11 10:44 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Git Mailing List
In-Reply-To: <8700373A-4878-4EBD-BA27-D4F31BE44907@lrde.epita.fr>
Benoit Sigoure <tsuna@lrde.epita.fr> wrote:
> On Nov 11, 2007, at 6:11 AM, Shawn O. Pearce wrote:
> >Benoit Sigoure <tsuna@lrde.epita.fr> wrote:
> >>gitk (and I think git-gui too) save their "geometry" (which includes
> >>X/Y position) in ~/.gitk. So far so good. The problem is that I
> >>often use 2 screens at work (one is the screen of my laptop, the
> >>other one is above) and I happen to put my gitk/git-gui windows on
> >>the 2nd screen. When I go back home, I don't have a second screen
> >>and gitk/git-gui open their windows out of reach.
> >
> >Actually git-gui saves the geometry to .git/config so I'm not sure
> >why the sed line above would correct git-gui's display issues. But I
> >have also noticed this problem on my Mac OS X laptop when running
> >again after leaving either git-gui or gitk on the external display.
>
> it's been a long time since I last used Tcl/Tk but if you give me a
> hint as to where to look / what should be done, I can give it a try.
Look in git-gui.sh for "-- Load geometry"; in my current master
it is on line 2625. This is the block where we have taken the
geometry data back in from .git/config and are trying to update
the UI to match what it says. Unfortunately we set a coordinate
that is off the desktop using a standard X geometry string in the
"wm geometry . [lindex $gm 0]" call...
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Simplify strchrnul() compat code
From: Junio C Hamano @ 2007-11-11 10:44 UTC (permalink / raw)
To: Andreas Ericsson
Cc: René Scharfe, Pierre Habouzit, Git Mailing List,
Johannes Schindelin, Jakub Narebski
In-Reply-To: <4735BA79.5020102@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> René Scharfe wrote:
>> -#ifdef NO_STRCHRNUL
>> +#if !defined(__GLIBC__) && !__GLIBC_PREREQ(2, 1)
>
> This will break things for users of glibc-2.1.1 (the first release still
> available from ftp://sources.redhat.com/pub/glibc/old-releases that
> includes the strchrnul() function), since __GLIBC_PREREQ() was invented
> after strchrnul() was introduced.
>
> Replacing __GLIBC__ with __GLIBC_PREREQ (as in the original patch) will
> solve it nicely. Users of glibc-2.1.1 will be the odd minority where
> strchrnul() is available in their libc but not used.
Do you mean this on top of René's patch? Although I do not
think I saw "the original patch" that did it this way, I think
it makes sense.
diff --git a/git-compat-util.h b/git-compat-util.h
index 11e6df6..dd96f7a 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -183,7 +183,7 @@ void *gitmemmem(const void *haystack, size_t haystacklen,
const void *needle, size_t needlelen);
#endif
-#if !defined(__GLIBC__) && !__GLIBC_PREREQ(2, 1)
+#if !defined(__GLIBC_PREREQ) && !__GLIBC_PREREQ(2, 1)
#define strchrnul gitstrchrnul
static inline char *gitstrchrnul(const char *s, int c)
{
^ permalink raw reply related
* Re: [PATCH 3/3] git-svn log: handle unreachable revisions like "svn log"
From: Benoit Sigoure @ 2007-11-11 10:51 UTC (permalink / raw)
To: David D Kilzer; +Cc: git, gitster
In-Reply-To: <1194761435-7286-4-git-send-email-ddkilzer@kilzer.net>
[-- Attachment #1: Type: text/plain, Size: 4837 bytes --]
Hi David,
thanks for the patches, the series looks good to me, I added some
comments below, for this patch.
On Nov 11, 2007, at 7:10 AM, David D Kilzer wrote:
> When unreachable revisions are given to "svn log", it displays all
> commit
> logs in the given range that exist in the current tree. (If no commit
> logs are found in the current tree, it simply prints a single
> commit log
> separator.) This patch makes "git-svn log" behave the same way.
>
> Ten tests added to t/t9116-git-svn-log.sh.
>
> Signed-off-by: David D Kilzer <ddkilzer@kilzer.net>
> ---
> git-svn.perl | 58 +++++++++++++++++++++++++++
> +--------------
> t/t9116-git-svn-log.sh | 66 +++++++++++++++++++++++++++++++++++++
> +++++++++++
> 2 files changed, 105 insertions(+), 19 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 39585d8..c584715 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -2257,9 +2257,10 @@ sub rev_db_get {
> }
>
> sub find_rev_before {
> - my ($self, $rev, $eq_ok) = @_;
> + my ($self, $rev, $eq_ok, $min_rev) = @_;
Could you please document this function? I guess that you had to
figure out what each argument was for, so please save the time of the
contributors that will read this code after you :)
> --$rev unless $eq_ok;
> - while ($rev > 0) {
> + $min_rev ||= 1;
> + while ($rev >= $min_rev) {
> if (my $c = $self->rev_db_get($rev)) {
> return ($rev, $c);
> }
> @@ -2268,6 +2269,19 @@ sub find_rev_before {
> return (undef, undef);
> }
>
> +sub find_rev_after {
> + my ($self, $rev, $eq_ok, $max_rev) = @_;
> + ++$rev unless $eq_ok;
> + $max_rev ||= $self->rev_db_max();
> + while ($rev <= $max_rev) {
> + if (my $c = $self->rev_db_get($rev)) {
> + return ($rev, $c);
> + }
> + ++$rev;
> + }
> + return (undef, undef);
> +}
> +
Too much code duplication. It should be possible to write a sub
find_rev_ (or _find_rev, don't know what's the naming convention for
internal details) that takes a 5th argument, an anonymous sub that
does the comparison. So that basically, find_rev_before will be
something along these (untested) lines:
sub find_rev_before {
my ($self, $rev, $eq_ok, $min_rev) = @_;
return find_rev_($self, $rev, $eq_ok, $min_rev, sub { my ($a, $b) =
@_; return $a >= $b; });
}
> sub _new {
> my ($class, $repo_id, $ref_id, $path) = @_;
> unless (defined $repo_id && length $repo_id) {
> @@ -3587,19 +3601,19 @@ sub git_svn_log_cmd {
> push @cmd, $c;
> }
> } elsif (defined $r_max) {
> - my ($c_min, $c_max);
> - $c_max = $gs->rev_db_get($r_max);
> - $c_min = $gs->rev_db_get($r_min);
> - if (defined $c_min && defined $c_max) {
> - if ($r_max > $r_min) {
> - push @cmd, "--boundary", "$c_min..$c_max";
> - } else {
> - push @cmd, "--boundary", "$c_max..$c_min";
> - }
> - } elsif ($r_max > $r_min) {
> - push @cmd, $c_max;
> + if ($r_max < $r_min) {
> + ($r_min, $r_max) = ($r_max, $r_min);
> + }
> + my (undef, $c_max) = $gs->find_rev_before($r_max, 1, $r_min);
> + my (undef, $c_min) = $gs->find_rev_after($r_min, 1, $r_max);
> + # If there are no commits in the range, both $c_max and $c_min
> + # will be undefined. If there is at least 1 commit in the
> + # range, both will be defined.
> + return () if !defined $c_min;
Fair enough but I'd strengthen the test by writing something like:
return () if not defined $c_min || not defined $c_max;
unless you can prove that `rev_db_get' can never return `undef' or
something like that.
> + if ($c_min eq $c_max) {
> + push @cmd, '--max-count=1', $c_min;
> } else {
> - push @cmd, $c_min;
> + push @cmd, '--boundary', "$c_min..$c_max";
> }
> }
> return (@cmd, @files);
> @@ -3705,9 +3719,13 @@ sub show_commit_changed_paths {
> print "Changed paths:\n", @{$c->{changed}};
> }
>
> +sub commit_log_separator {
> + return ('-' x 72) . "\n";
> +}
> +
This is basically a constant, I think that declaring it with a
prototype helps Perl to optimize it:
sub commit_log_separator() {
> sub show_commit_normal {
> my ($c) = @_;
> - print '-' x72, "\nr$c->{r} | ";
> + print commit_log_separator(), "r$c->{r} | ";
> print "$c->{c} | " if $show_commit;
> print "$c->{a} | ", strftime("%Y-%m-%d %H:%M:%S %z (%a, %d %b %Y)",
> localtime($c->{t_utc})), ' | ';
> diff --git a/t/t9116-git-svn-log.sh b/t/t9116-git-svn-log.sh
> index 5000892..56dd8fe 100755
> --- a/t/t9116-git-svn-log.sh
> +++ b/t/t9116-git-svn-log.sh
> @@ -59,4 +65,64 @@ test_expect_success 'test descending revision
> range' "
[...]
> +
> +echo
> ----------------------------------------------------------------------
> -- > expected-separator
This will choke on shells with buggy/fragile `echo'. I think it'd be
safer to use printf here.
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: Deprecate git-fetch-pack?
From: Johannes Schindelin @ 2007-11-11 11:05 UTC (permalink / raw)
To: Ask Bjørn Hansen; +Cc: Junio C Hamano, Daniel Barkalow, git
In-Reply-To: <74415967-7F49-426C-8BF5-1A0210C337AB@develooper.com>
Hi,
On Sat, 10 Nov 2007, Ask Bj?rn Hansen wrote:
> For new users the superfluous programs are a burden making it harder to
> learn how everything works.
This should be a non-issue. We really should start deprecating
"git-<command>" in favour of "git <command>" for real.
New users should not even be told that this is correct usage.
My reason? We have plumbing, and we will always have plumbing, as
commands. A regular git user does not _want_ to see that. Without said
deprecation she _will_, however.
Ciao,
Dscho
^ permalink raw reply
* Re: git packs
From: Derek Fawcus @ 2007-11-11 11:09 UTC (permalink / raw)
To: bob; +Cc: git
In-Reply-To: <134659C4-BA10-4B9E-9C64-2754A90D93F8@mac.com>
On Sat, Nov 10, 2007 at 01:01:46PM -0500, bob wrote:
> It is fairly disappointing as far as indicating the problem. Here is
> the entire report since it was so short.
> Error Formulating Crash Report:
> *** -[NSCFDictionary setObject:forKey:]: attempt to insert nil value
> (key: VMUSignaturePath)
huh? The above looks like an ObjC invocation. Last I checked, git was C.
So why is that in the frame?
DF
^ permalink raw reply
* Re: git-gui messes up the diff view on non ASCII characters
From: Johannes Schindelin @ 2007-11-11 11:20 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Michele Ballabio, git, Peter Baumann
In-Reply-To: <20071111055959.GW14735@spearce.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1765 bytes --]
Hi,
On Sun, 11 Nov 2007, Shawn O. Pearce wrote:
> Michele Ballabio <barra_cuda@katamail.com> wrote:
> > On Friday 09 November 2007, Peter Baumann wrote:
> > > I'm managing some UTF-8 encoded LaTeX files in git, which include some
> > > non ASCII characters like the german ä,ö and ü. If I view the diff with
> > > git-diff on an UTF8 enabled terminal, all looks nice. So does the diff
> > > view in gitk after I commited my changes. Only git-gui shows some
> > > "strange" characters, so I assume it is an encoding problem.
> > >
> > > I have to admit that I'm totally unaware how this should work, but at
> > > least I think my configuration is correct here, because otherwise git-diff
> > > or gitk would show the same behaviour. Is there anything which could be
> > > done to make git-gui happy, too?
> >
> > It's a known issue, and already on Shawn's ToDo list. I have to add that
> > viewing untracked UTF8 files in git-gui works just fine. Weird.
>
> Cute. That's because in the untracked case we open the file and
> let the platform's chosen encoding be used to convert it into the
> text viewer. In the tracked diff case we force the encoding to
> be in binary.
>
> Now gitk works because it assumes the diff is in the same character
> encoding as the commit message itself. Since commit messages are
> typically in UTF-8 (as that is the Git default encoding) then a
> UTF-8 encoded file shows correctly in gitk.
>
> What's the right behavior here? Just assume the platform encoding
> is correct for the file we are showing and show it? Assume the
> commit encoding configured in i18n.commitencoding is the correct
> one for the file content? Something else?
My twopence: assume utf-8, but make it a _git-gui_ config variable.
Ciao,
Dscho
^ permalink raw reply
* Re: Dose git-fetch need --reference option like git-clone?
From: Yin Ping @ 2007-11-11 11:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsl3dgovv.fsf@gitster.siamese.dyndns.org>
On Nov 11, 2007 4:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> No, there is no such thing.
>
> I think what you are talking about is a reasonable thing to
> want. It would have been easier to hack in back when git-fetch
> was a script, but now you would need to work a bit harder in the
> C code. On the other hand, however, I suspect the resulting
> code would be cleaner without having to actually create and
> delete temporary refs in refs/reference-tmp/ namespace but fake
> them only in-core, with a proper transport API enhancements.
>
> But if you only want a quick-and-dirty workaround, you can
> manually do refs/reference-tmp and objects/info/alternates dance
> that is done by git-clone before running a git-fetch from such
> "nearby" remote.
Now my workaround is
$ git remote add remoteA path/to/remoteACloned
$ git fetch remoteA
Then update .git/config to let remote.remoteA.url=git://remoteAUrl
$ git fetch
--
Ping Yin
^ permalink raw reply
* [PATCH v3] Make GIT_INDEX_FILE apply to git-commit
From: Rémi Vanicat @ 2007-11-11 12:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Currently, when committing, git-commit ignore the value of
GIT_INDEX_FILE, and always use $GIT_DIR/index. This patch
fix it.
Signed-off-by: Rémi Vanicat <vanicat@debian.org>
---
git-commit.sh | 2 +-
t/t7500-commit.sh | 13 +++++++++++++
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index fcb8443..6490045 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -26,7 +26,7 @@ refuse_partial () {
}
TMP_INDEX=
-THIS_INDEX="$GIT_DIR/index"
+THIS_INDEX="${GIT_INDEX_FILE:-$GIT_DIR/index}"
NEXT_INDEX="$GIT_DIR/next-index$$"
rm -f "$NEXT_INDEX"
save_index () {
diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh
index abbf54b..3e5abef 100755
--- a/t/t7500-commit.sh
+++ b/t/t7500-commit.sh
@@ -93,4 +93,17 @@ test_expect_success 'commit message from file should override template' '
commit_msg_is "standard input msg"
'
+test_expect_success 'using GIT_INDEX_FILE' '
+
+ echo "some new content" >file &&
+ GIT_INDEX_FILE=.git/another_index git add file &&
+ GIT_INDEX_FILE=.git/another_index \
+ git commit -m "commit using another index" &&
+ git reset HEAD &&
+ git diff HEAD -- file >current &&
+ touch empty-file &&
+ diff empty-file current
+
+'
+
test_done
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH] Simplify strchrnul() compat code
From: Andreas Ericsson @ 2007-11-11 12:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: René Scharfe, Pierre Habouzit, Git Mailing List,
Johannes Schindelin, Jakub Narebski
In-Reply-To: <7v6409f4eh.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>> René Scharfe wrote:
>>> -#ifdef NO_STRCHRNUL
>>> +#if !defined(__GLIBC__) && !__GLIBC_PREREQ(2, 1)
>> This will break things for users of glibc-2.1.1 (the first release still
>> available from ftp://sources.redhat.com/pub/glibc/old-releases that
>> includes the strchrnul() function), since __GLIBC_PREREQ() was invented
>> after strchrnul() was introduced.
>>
>> Replacing __GLIBC__ with __GLIBC_PREREQ (as in the original patch) will
>> solve it nicely. Users of glibc-2.1.1 will be the odd minority where
>> strchrnul() is available in their libc but not used.
>
> Do you mean this on top of René's patch?
Yes.
> Although I do not
> think I saw "the original patch" that did it this way,
My memory seems to be failing. I never committed my proposal to my repo,
and the one I sent out was the __GLIBC__ || !__GLIBC_PREREQ thing. My
apologies.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* git diff and file deleted from the cache
From: Remi Vanicat @ 2007-11-11 12:43 UTC (permalink / raw)
To: git
The manual of git-diff tell me that :
git-diff [--options] <commit> [--] [<path>...]
This form is to view the changes you have in your working tree
relative to the named <commit>. You can use HEAD to compare it with
the latest commit, or a branch name to compare with the tip of a
different branch.
So the following seem strange :
$ echo foo > bar
$ git commit -m "committing bar" -a
Created commit 074893b: committing bar
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 bar
$ git rm --cached bar
rm 'bar'
$ git diff HEAD --
diff --git a/bar b/bar
deleted file mode 100644
index 257cc56..0000000
--- a/bar
+++ /dev/null
@@ -1 +0,0 @@
-foo
I excepted the diff to be empty, as HEAD and the working directory are
synchronized, I've only modified the cache.
--
Rémi Vanicat
^ permalink raw reply related
* Re: git packs
From: bob @ 2007-11-11 12:54 UTC (permalink / raw)
To: Derek Fawcus; +Cc: git
In-Reply-To: <20071111110942.A4013@edi-view2.cisco.com>
Well, there are actually two problems here. The first is that
crashreporter crashed trying to create the crash report of
the git failure. The second was the error in git itself.
Hope that helps.
I am submitting an Apple bugreport on the first and
Nicolas Pitre is probably correct in his fix. When I
was looking at index-pack.c everything was using 32
bit unsigned and signed number where off_t was
64-bit which is what a stat() would return. My problem
is that I was not familiar enough with git internals to
figure out the solution. My review was the first time
that I ever looked at git source.
Thanks, Nicolas
On Nov 11, 2007, at 6:09 AM, Derek Fawcus wrote:
> On Sat, Nov 10, 2007 at 01:01:46PM -0500, bob wrote:
>> It is fairly disappointing as far as indicating the problem. Here is
>> the entire report since it was so short.
>
>> Error Formulating Crash Report:
>> *** -[NSCFDictionary setObject:forKey:]: attempt to insert nil value
>> (key: VMUSignaturePath)
>
> huh? The above looks like an ObjC invocation. Last I checked,
> git was C.
> So why is that in the frame?
>
> DF
^ permalink raw reply
* (unknown)
From: Michael Dressel @ 2007-11-11 13:08 UTC (permalink / raw)
To: git
>Michael Dressel wrote:
>Ok nice. Another thing is that git-push will push all the tracking
>branches in refs/remotes/origin.
I learned that I only have to edit the .git/config file to avoid that
git-push pushes everything.
I modified the remotes names and added push lines explicitly.
Is that the recommended way?
In my example (git-branch -a -v):
* exp aa854c6 shtest 4
master 34924b9 mastertest 1
origin/exp aa854c6 shtest 4
origin/master b68e7a9 brt master 1
I used the following .git/config:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin1"]
url = /home/repo/src
fetch = +refs/heads/master:refs/remotes/origin/master
push = +refs/heads/master:refs/heads/master
[remote "origin2"]
url = /home/repo/src
fetch = +refs/heads/exp:refs/remotes/origin/exp
push = +refs/heads/exp:refs/heads/exp
[branch "master"]
remote = origin1
merge = refs/heads/master
[branch "exp"]
remote = origin2
merge = refs/heads/exp
Cheers,
Michael
^ permalink raw reply
* Re: cogito remote branch
From: Michael Dressel @ 2007-11-11 13:11 UTC (permalink / raw)
To: git
>Michael Dressel wrote:
>Ok nice. Another thing is that git-push will push all the tracking
>branches in refs/remotes/origin.
I learned that I only have to edit the .git/config file to avoid that
git-push pushes everything.
I modified the remotes names and added push lines explicitly.
Is that the recommended way?
In my example (git-branch -a -v):
* exp aa854c6 shtest 4
master 34924b9 mastertest 1
origin/exp aa854c6 shtest 4
origin/master b68e7a9 brt master 1
I used the following .git/config:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin1"]
url = /home/repo/src
fetch = +refs/heads/master:refs/remotes/origin/master
push = +refs/heads/master:refs/heads/master
[remote "origin2"]
url = /home/repo/src
fetch = +refs/heads/exp:refs/remotes/origin/exp
push = +refs/heads/exp:refs/heads/exp
[branch "master"]
remote = origin1
merge = refs/heads/master
[branch "exp"]
remote = origin2
merge = refs/heads/exp
Cheers,
Michael
^ permalink raw reply
* [PATCH 5/6] push: use same rules as git-rev-parse to resolve refspecs
From: Steffen Prohaska @ 2007-11-11 14:01 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
In-Reply-To: <11947897083265-git-send-email-prohaska@zib.de>
This commit changes the rules for resolving refspecs to match the
rules for resolving refs in rev-parse. git-rev-parse uses clear rules
to resolve a short ref to its full name, which are well documented.
The rules for resolving refspecs documented in git-send-pack were
less strict and harder to understand. This commit replaces them by
the rules of git-rev-parse.
The unified rules are easier to understand and better resolve ambiguous
cases. You can now push from a repository containing several branches
ending on the same short name.
Note, this may break existing setups. For example "master" will no longer
resolve to "origin/master".
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/git-send-pack.txt | 4 +++-
remote.c | 5 +----
t/t5516-fetch-push.sh | 12 +++++++++++-
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
index 2fa01d4..a2d9cb6 100644
--- a/Documentation/git-send-pack.txt
+++ b/Documentation/git-send-pack.txt
@@ -85,7 +85,9 @@ Each pattern pair consists of the source side (before the colon)
and the destination side (after the colon). The ref to be
pushed is determined by finding a match that matches the source
side, and where it is pushed is determined by using the
-destination side.
+destination side. The rules used to match a ref are the same
+rules used by gitlink:git-rev-parse[1] to resolve a symbolic ref
+name.
- It is an error if <src> does not match exactly one of the
local refs.
diff --git a/remote.c b/remote.c
index bec2ba1..28d8eb7 100644
--- a/remote.c
+++ b/remote.c
@@ -519,10 +519,7 @@ static int count_refspec_match(const char *pattern,
char *name = refs->name;
int namelen = strlen(name);
- if (namelen < patlen ||
- memcmp(name + namelen - patlen, pattern, patlen))
- continue;
- if (namelen != patlen && name[namelen - patlen - 1] != '/')
+ if (!ref_abbrev_matches_full_with_rules(pattern, name, ref_rev_parse_rules))
continue;
/* A match is "weak" if it is with refs outside
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index b0ff488..fd5f284 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -145,11 +145,21 @@ test_expect_success 'push with no ambiguity (1)' '
test_expect_success 'push with no ambiguity (2)' '
mk_test remotes/origin/master &&
- git push testrepo master:master &&
+ git push testrepo master:origin/master &&
check_push_result $the_commit remotes/origin/master
'
+test_expect_success 'push with colon-less refspec, no ambiguity' '
+
+ mk_test heads/master heads/t/master &&
+ git branch -f t/master master &&
+ git push testrepo master &&
+ check_push_result $the_commit heads/master &&
+ check_push_result $the_first_commit heads/t/master
+
+'
+
test_expect_success 'push with weak ambiguity (1)' '
mk_test heads/master remotes/origin/master &&
--
1.5.3.5.578.g886d
^ permalink raw reply related
* [PATCH 6/6] refactor fetch's ref matching to use ref_abbrev_matches_full_with_rules()
From: Steffen Prohaska @ 2007-11-11 14:01 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
In-Reply-To: <1194789709671-git-send-email-prohaska@zib.de>
The old rules used by fetch were coded as a series of ifs. The old
rules are:
1) match full refname if it starts with "refs/" or matches "HEAD"
2) verify that full refname starts with "refs/"
3) match abbreviated name in "refs/" if it starts with "heads/",
"tags/", or "remotes/".
4) match abbreviated name in "refs/heads/"
This is replaced by the new rules
a) match full refname
b) match abbreviated name prefixed with "refs/"
c) match abbreviated name prefixed with "refs/heads/"
The details of the new rules are different from the old rules. We no
longer verify that the full refname starts with "refs/". The new rule
(a) matches any full string. The old rules (1) and (2) were stricter.
Now, the caller is responsible for using sensible full refnames. This
should be the case for the current code. The new rule (b) is less
strict than old rule (3). The new rule accepts abbreviated names that
start with a non-standard prefix below "refs/".
Despite this modifications the new rules should handle all cases as
expected. Two tests are added to verify that fetch does not resolve
short tags or HEAD in remotes.
We may even think about loosening the rules a bit more and unify them
with the rev-parse rules. This would be done by replacing
ref_ref_fetch_rules with ref_ref_parse_rules. Note, the two new test
would break.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
cache.h | 1 +
refs.c | 7 +++++++
remote.c | 23 ++---------------------
t/t5510-fetch.sh | 25 +++++++++++++++++++++++++
4 files changed, 35 insertions(+), 21 deletions(-)
diff --git a/cache.h b/cache.h
index d36b91d..1313378 100644
--- a/cache.h
+++ b/cache.h
@@ -411,6 +411,7 @@ extern int dwim_log(const char *str, int len, unsigned char *sha1, char **ref);
extern int ref_abbrev_matches_full_with_rules(const char *abbrev_name, const char *full_name, const char **rules);
extern const char *ref_rev_parse_rules[];
+extern const char *ref_fetch_rules[];
extern int create_symref(const char *ref, const char *refs_heads_master, const char *logmsg);
extern int validate_headref(const char *ref);
diff --git a/refs.c b/refs.c
index 4bb16e5..7db2146 100644
--- a/refs.c
+++ b/refs.c
@@ -665,6 +665,13 @@ const char *ref_rev_parse_rules[] = {
NULL
};
+const char *ref_fetch_rules[] = {
+ "%.*s",
+ "refs/%.*s",
+ "refs/heads/%.*s",
+ NULL
+};
+
int ref_abbrev_matches_full_with_rules(const char *abbrev_name, const char *full_name, const char **rules)
{
const char **p;
diff --git a/remote.c b/remote.c
index 28d8eb7..2dfce70 100644
--- a/remote.c
+++ b/remote.c
@@ -417,25 +417,6 @@ int remote_has_url(struct remote *remote, const char *url)
return 0;
}
-/*
- * Returns true if, under the matching rules for fetching, name is the
- * same as the given full name.
- */
-static int ref_matches_abbrev(const char *name, const char *full)
-{
- if (!prefixcmp(name, "refs/") || !strcmp(name, "HEAD"))
- return !strcmp(name, full);
- if (prefixcmp(full, "refs/"))
- return 0;
- if (!prefixcmp(name, "heads/") ||
- !prefixcmp(name, "tags/") ||
- !prefixcmp(name, "remotes/"))
- return !strcmp(name, full + 5);
- if (prefixcmp(full + 5, "heads/"))
- return 0;
- return !strcmp(full + 11, name);
-}
-
int remote_find_tracking(struct remote *remote, struct refspec *refspec)
{
int find_src = refspec->src == NULL;
@@ -804,7 +785,7 @@ int branch_merge_matches(struct branch *branch,
{
if (!branch || i < 0 || i >= branch->merge_nr)
return 0;
- return ref_matches_abbrev(branch->merge[i]->src, refname);
+ return ref_abbrev_matches_full_with_rules(branch->merge[i]->src, refname, ref_fetch_rules);
}
static struct ref *get_expanded_map(struct ref *remote_refs,
@@ -843,7 +824,7 @@ static struct ref *find_ref_by_name_abbrev(struct ref *refs, const char *name)
{
struct ref *ref;
for (ref = refs; ref; ref = ref->next) {
- if (ref_matches_abbrev(name, ref->name))
+ if (ref_abbrev_matches_full_with_rules(name, ref->name, ref_fetch_rules))
return ref;
}
return NULL;
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index aad863d..2025742 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -95,6 +95,31 @@ test_expect_success 'fetch following tags' '
'
+test_expect_failure 'fetch must not resolve short tag name' '
+
+ cd "$D" &&
+
+ mkdir five &&
+ cd five &&
+ git init &&
+
+ git fetch .. anno:five
+
+'
+
+test_expect_failure 'fetch must not resolve short remote name' '
+
+ cd "$D" &&
+ git-update-ref refs/remotes/six/HEAD HEAD
+
+ mkdir six &&
+ cd six &&
+ git init &&
+
+ git fetch .. six:six
+
+'
+
test_expect_success 'create bundle 1' '
cd "$D" &&
echo >file updated again by origin &&
--
1.5.3.5.578.g886d
^ permalink raw reply related
* [REPLACEMENT PATCH 0/6] improve refspec handling in push, refactor matching in fetch
From: Steffen Prohaska @ 2007-11-11 14:01 UTC (permalink / raw)
To: git
This is a replacement for sp/push-refspec. It is rebased to the current master.
Documentation/git-push.txt | 4 ++--
Documentation/git-send-pack.txt | 4 +++-
builtin-push.c | 11 +++++++++++
cache.h | 4 ++++
refs.c | 31 +++++++++++++++++++++++++++++++
remote.c | 28 +++-------------------------
sha1_name.c | 14 ++------------
t/t5510-fetch.sh | 25 +++++++++++++++++++++++++
t/t5516-fetch-push.sh | 29 ++++++++++++++++++++++++++++-
transport.c | 8 ++++++--
transport.h | 1 +
11 files changed, 116 insertions(+), 43 deletions(-)
[PATCH 1/6] push: mention --verbose option in documentation
Push uses parseopts, which supports '--verbose'.
[PATCH 2/6] push: teach push to pass --verbose option to transport layer
Adapted to paresopts changes.
[PATCH 3/6] push: support pushing HEAD to real branch name
Same as before.
[PATCH 4/6] add ref_abbrev_matches_full_with_rules()
[PATCH 5/6] push: use same rules as git-rev-parse to resolve refspecs
[PATCH 6/6] refactor fetch's ref matching to use ref_abbrev_matches_full_with_rules()
Start unification of refspec matching rules.
^ permalink raw reply
* [PATCH 4/6] add ref_abbrev_matches_full_with_rules()
From: Steffen Prohaska @ 2007-11-11 14:01 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
In-Reply-To: <11947897083159-git-send-email-prohaska@zib.de>
We use at least two rulesets for matching abbreviated refnames with
full refnames (starting with 'refs/'). git-rev-parse and git-fetch
use slightly different rules.
This commit introduces a new function
ref_abbrev_matches_full_with_rules(
const char *abbrev_name, const char *full_name, const char **rules).
abbrev_name is expanded using the rules and matched against full_name.
If a match is found the function returns true. rules is a NULL-terminate
list of format patterns with "%.*s", for example
const char *ref_rev_parse_rules[] = {
"%.*s",
"refs/%.*s",
"refs/tags/%.*s",
"refs/heads/%.*s",
"refs/remotes/%.*s",
"refs/remotes/%.*s/HEAD",
NULL
};
Asterisks are included in the format strings because this is the form
required in sha1_name.c. Sharing the list with the functions there is
a good idea to avoid duplicating the rules. Hopefully this
facilitates unified matching rules in the future.
This commit makes the rules used by rev-parse for resolving refs to
sha1s available for string comparison. Before this change, the rules
were buried in get_sha1*() and dwim_ref().
A follow-up commit will refactor the rules used by fetch.
ref_abbrev_matches_full_with_rules() will be used for matching
refspecs in git-send-pack.
Thanks to Daniel Barkalow <barkalow@iabervon.org> for pointing
out that ref_matches_abbrev in remote.c solves a similar problem
and care should be taken to avoid confusion.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
cache.h | 3 +++
refs.c | 24 ++++++++++++++++++++++++
sha1_name.c | 14 ++------------
3 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/cache.h b/cache.h
index f0a25c7..d36b91d 100644
--- a/cache.h
+++ b/cache.h
@@ -409,6 +409,9 @@ extern const char *resolve_ref(const char *path, unsigned char *sha1, int, int *
extern int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref);
extern int dwim_log(const char *str, int len, unsigned char *sha1, char **ref);
+extern int ref_abbrev_matches_full_with_rules(const char *abbrev_name, const char *full_name, const char **rules);
+extern const char *ref_rev_parse_rules[];
+
extern int create_symref(const char *ref, const char *refs_heads_master, const char *logmsg);
extern int validate_headref(const char *ref);
diff --git a/refs.c b/refs.c
index aff02cd..4bb16e5 100644
--- a/refs.c
+++ b/refs.c
@@ -655,6 +655,30 @@ int check_ref_format(const char *ref)
}
}
+const char *ref_rev_parse_rules[] = {
+ "%.*s",
+ "refs/%.*s",
+ "refs/tags/%.*s",
+ "refs/heads/%.*s",
+ "refs/remotes/%.*s",
+ "refs/remotes/%.*s/HEAD",
+ NULL
+};
+
+int ref_abbrev_matches_full_with_rules(const char *abbrev_name, const char *full_name, const char **rules)
+{
+ const char **p;
+ const int abbrev_name_len = strlen(abbrev_name);
+
+ for (p = rules; *p; p++) {
+ if (!strcmp(full_name, mkpath(*p, abbrev_name_len, abbrev_name))) {
+ return 1;
+ }
+ }
+
+ return 0;
+}
+
static struct ref_lock *verify_lock(struct ref_lock *lock,
const unsigned char *old_sha1, int mustexist)
{
diff --git a/sha1_name.c b/sha1_name.c
index 2d727d5..d364244 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -239,23 +239,13 @@ static int ambiguous_path(const char *path, int len)
return slash;
}
-static const char *ref_fmt[] = {
- "%.*s",
- "refs/%.*s",
- "refs/tags/%.*s",
- "refs/heads/%.*s",
- "refs/remotes/%.*s",
- "refs/remotes/%.*s/HEAD",
- NULL
-};
-
int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
{
const char **p, *r;
int refs_found = 0;
*ref = NULL;
- for (p = ref_fmt; *p; p++) {
+ for (p = ref_rev_parse_rules; *p; p++) {
unsigned char sha1_from_ref[20];
unsigned char *this_result;
@@ -277,7 +267,7 @@ int dwim_log(const char *str, int len, unsigned char *sha1, char **log)
int logs_found = 0;
*log = NULL;
- for (p = ref_fmt; *p; p++) {
+ for (p = ref_rev_parse_rules; *p; p++) {
struct stat st;
unsigned char hash[20];
char path[PATH_MAX];
--
1.5.3.5.578.g886d
^ permalink raw reply related
* [PATCH 3/6] push: support pushing HEAD to real branch name
From: Steffen Prohaska @ 2007-11-11 14:01 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska, Steffen Prohaska
In-Reply-To: <11947897081278-git-send-email-prohaska@zib.de>
From: Steffen Prohaska <gitster@pobox.com>
This teaches "push <remote> HEAD" to resolve HEAD on the local
side to its real branch name, e.g. master, and then act as if
the real branch name was specified. So we have a shorthand for
pushing the current branch. Besides HEAD, no other symbolic ref
is resolved.
Thanks to Daniel Barkalow <barkalow@iabervon.org> for suggesting
this implementation, which is much simpler than the
implementation proposed before.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-push.c | 9 +++++++++
t/t5516-fetch-push.sh | 17 +++++++++++++++++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 6d1da07..a99ba0c 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -44,6 +44,15 @@ static void set_refspecs(const char **refs, int nr)
strcat(tag, refs[i]);
ref = tag;
}
+ if (!strcmp("HEAD", ref)) {
+ unsigned char sha1_dummy[20];
+ ref = resolve_ref(ref, sha1_dummy, 1, NULL);
+ if (!ref)
+ die("HEAD cannot be resolved.");
+ if (strncmp(ref, "refs/heads/", 11))
+ die("HEAD cannot be resolved to branch.");
+ ref = xstrdup(ref + 11);
+ }
add_refspec(ref);
}
}
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 86f9b53..b0ff488 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -244,6 +244,23 @@ test_expect_success 'push with colon-less refspec (4)' '
'
+test_expect_success 'push with HEAD' '
+
+ mk_test heads/master &&
+ git checkout master &&
+ git push testrepo HEAD &&
+ check_push_result $the_commit heads/master
+
+'
+
+test_expect_success 'push with HEAD nonexisting at remote' '
+
+ mk_test heads/master &&
+ git checkout -b local master &&
+ git push testrepo HEAD &&
+ check_push_result $the_commit heads/local
+'
+
test_expect_success 'push with dry-run' '
mk_test heads/master &&
--
1.5.3.5.578.g886d
^ permalink raw reply related
* [PATCH 2/6] push: teach push to pass --verbose option to transport layer
From: Steffen Prohaska @ 2007-11-11 14:01 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska, Steffen Prohaska
In-Reply-To: <11947897083381-git-send-email-prohaska@zib.de>
From: Steffen Prohaska <gitster@pobox.com>
A --verbose option to push should also be passed to the
transport layer, i.e. git-send-pack, git-http-push.
git push is modified to do so.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-push.c | 2 ++
transport.c | 8 ++++++--
transport.h | 1 +
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 2c56195..6d1da07 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -115,6 +115,8 @@ int cmd_push(int argc, const char **argv, const char *prefix)
flags |= TRANSPORT_PUSH_FORCE;
if (dry_run)
flags |= TRANSPORT_PUSH_DRY_RUN;
+ if (verbose)
+ flags |= TRANSPORT_PUSH_VERBOSE;
if (tags)
add_refspec("refs/tags/*");
if (all)
diff --git a/transport.c b/transport.c
index fa5cfbb..e8a2608 100644
--- a/transport.c
+++ b/transport.c
@@ -386,7 +386,7 @@ static int curl_transport_push(struct transport *transport, int refspec_nr, cons
int argc;
int err;
- argv = xmalloc((refspec_nr + 11) * sizeof(char *));
+ argv = xmalloc((refspec_nr + 12) * sizeof(char *));
argv[0] = "http-push";
argc = 1;
if (flags & TRANSPORT_PUSH_ALL)
@@ -395,6 +395,8 @@ static int curl_transport_push(struct transport *transport, int refspec_nr, cons
argv[argc++] = "--force";
if (flags & TRANSPORT_PUSH_DRY_RUN)
argv[argc++] = "--dry-run";
+ if (flags & TRANSPORT_PUSH_VERBOSE)
+ argv[argc++] = "--verbose";
argv[argc++] = transport->url;
while (refspec_nr--)
argv[argc++] = *refspec++;
@@ -655,7 +657,7 @@ static int git_transport_push(struct transport *transport, int refspec_nr, const
int argc;
int err;
- argv = xmalloc((refspec_nr + 11) * sizeof(char *));
+ argv = xmalloc((refspec_nr + 12) * sizeof(char *));
argv[0] = "send-pack";
argc = 1;
if (flags & TRANSPORT_PUSH_ALL)
@@ -664,6 +666,8 @@ static int git_transport_push(struct transport *transport, int refspec_nr, const
argv[argc++] = "--force";
if (flags & TRANSPORT_PUSH_DRY_RUN)
argv[argc++] = "--dry-run";
+ if (flags & TRANSPORT_PUSH_VERBOSE)
+ argv[argc++] = "--verbose";
if (data->receivepack) {
char *rp = xmalloc(strlen(data->receivepack) + 16);
sprintf(rp, "--receive-pack=%s", data->receivepack);
diff --git a/transport.h b/transport.h
index df12ea7..2f80ab4 100644
--- a/transport.h
+++ b/transport.h
@@ -30,6 +30,7 @@ struct transport {
#define TRANSPORT_PUSH_ALL 1
#define TRANSPORT_PUSH_FORCE 2
#define TRANSPORT_PUSH_DRY_RUN 4
+#define TRANSPORT_PUSH_VERBOSE 8
/* Returns a transport suitable for the url */
struct transport *transport_get(struct remote *, const char *);
--
1.5.3.5.578.g886d
^ permalink raw reply related
* Re: git rm --cached
From: Jan Hudec @ 2007-11-11 14:05 UTC (permalink / raw)
To: git
In-Reply-To: <20071102021711.GA28703@fawkes.hq.digizenstudio.com>
[-- Attachment #1: Type: text/plain, Size: 679 bytes --]
On Thu, Nov 01, 2007 at 22:17:11 -0400, Jing Xue wrote:
> In the following scenario, why do I have to run 'git reset' following
> 'git rm --cached 1.txt' to revert to exactly where I was before 'git add
> 1.txt'? Shouldn't 'git rm --cached' have done that already?
The message in git-commit suggesting to use 'git rm --cached' to unstage is
just plain wrong. It really should mention 'git reset'.
git rm, as the name suggests, *removes* the file.
git reset, as the name suggests, reverts it to the state it was before (but,
somewhat confusingly, with path limit only resets the index, so no --cached
option there).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 1/6] push: mention --verbose option in documentation
From: Steffen Prohaska @ 2007-11-11 14:01 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska, Steffen Prohaska
In-Reply-To: <1194789708646-git-send-email-prohaska@zib.de>
From: Steffen Prohaska <gitster@pobox.com>
Before this commit, only '-v' was documented.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/git-push.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index e5dd4c1..4a68aab 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git-push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
- [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]
+ [--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...]
DESCRIPTION
-----------
@@ -95,7 +95,7 @@ the remote repository.
transfer spends extra cycles to minimize the number of
objects to be sent and meant to be used on slower connection.
--v::
+-v, \--verbose::
Run verbosely.
include::urls-remotes.txt[]
--
1.5.3.5.578.g886d
^ permalink raw reply related
* Re: [PATCH 1/6] push: mention --verbose option in documentation
From: Steffen Prohaska @ 2007-11-11 14:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <11947897083381-git-send-email-prohaska@zib.de>
On Nov 11, 2007, at 3:01 PM, Steffen Prohaska wrote:
> From: Steffen Prohaska <gitster@pobox.com>
This is obviously wrong. I have no clear idea how this happend.
I remember I took the topic branch sp/push-refspec from pu and
started to refactor. I used 'rebase' and 'rebase -i' a couple
of times and now I have my name with Junios email address.
I'll investigate how this could happen.
Steffen
^ 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