Git development
 help / color / mirror / Atom feed
* Re: [REPLACEMENT PATCH] git-checkout: Add a test case for relative paths use.
From: Andreas Ericsson @ 2007-11-08  9:23 UTC (permalink / raw)
  To: David Symonds; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <11945006082887-git-send-email-dsymonds@gmail.com>

David Symonds wrote:
> +'
> +
> +test_expect_failure 'checkout with relative path outside tree should fail (1)' \
> +	'git checkout HEAD - ../file0'
> +
> +test_expect_failure 'checkout with relative path outside tree should fail (2)' \
> +	'cd dir1 && git checkout HEAD - ./file0'
> +
> +test_expect_failure 'checkout with relative path outside tree should fail (2)' \
> +	'cd dir1 && git checkout HEAD - ../../file0'


Single-dashes on all of these?

Looks good otherwise.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

^ permalink raw reply

* Re: Inconsistencies with git log
From: Wincent Colaiuta @ 2007-11-08  9:19 UTC (permalink / raw)
  To: Jon Smirl; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <9e4733910711071503va92a653s25fd978989d5917d@mail.gmail.com>

El 8/11/2007, a las 0:03, Jon Smirl escribió:

> On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>
>>
>> We also tend to take the approach of viewing the history as that of
>> the whole project.
>
> But if you type 'git log' while cd'd into a subdirectory the whole log
> is almost never what you want. It's this kind of thing that makes git
> harder to use.

At least in my case, that's completely untrue. Whole-project history  
is basically *always* what I want even if I am cd'd into a  
subdirectory. If I wanted to path-limit the project history I'd do  
"git log ."

Cheers,
Wincent

^ permalink raw reply

* Re: stgit: cleaning up after using git branch delete commands
From: Catalin Marinas @ 2007-11-08  9:18 UTC (permalink / raw)
  To: Karl Hasselström; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <20071108055302.GA11230@diana.vm.bytemark.co.uk>

On 08/11/2007, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-11-07 11:11:42 -0500, Jon Smirl wrote:
>
> > how about a 'stg gc' command that gets rid of all the inaccessible
> > clutter?
>
> "stg assimilate" already has the job of fixing up stuff after the user
> has used git commands to move HEAD around. I think it would make sense
> to teach it to do this too -- and then rename it "stg repair" or
> something. That way, there's one command to fix every kind of "damage"
> that git can do to stgit.

"repair" sounds better than "gc" (which might also be confused with
the "git gc" command).

> Alternatively, "stg branch --create" and "stg init" and whoever else
> is bothered by the clutter could simply remove it themselves. That
> would be even more user-friendly, I guess.

I did some fixes for branch --delete but, since I use StGIT almost
exclusively, haven't thought that we need to relax the branch creation
as well.

-- 
Catalin

^ permalink raw reply

* Re: [PATCH] git-branch --with=commit
From: Andreas Ericsson @ 2007-11-08  9:17 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vejf140jd.fsf@gitster.siamese.dyndns.org>

Junio C Hamano wrote:
> Johannes Sixt <j.sixt@viscovery.net> writes:
> 
>> Junio C Hamano schrieb:
> 
>>> With this patch, I could do this to find out which topic
>>> branches already contain the faulty commit:
>>>
>>>     $ git branch --with=maint^ | grep /
>>>       xx/maint-fix-foo
>> It'd be helpful if you could construct the example in this commit
>> message such that you don't need the "grep /" here; otherwise, the
>> reader doesn't know which part of the effect is hidden by the grep.
> 
> Yeah, in the example sequence, I think only maint itself and
> xx/maint-fix-foo are shown, so there is no need for grep.

And "maint" could certainly be stripped by the code itself, since the
user can reasonably be expected to know that plain maint will have
everything maint^ has.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

^ permalink raw reply

* Re: [PATCH] git-sh-setup: fix parseopt `eval`.
From: Pierre Habouzit @ 2007-11-08  9:14 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6j15i3a.fsf@gitster.siamese.dyndns.org>

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

On Thu, Nov 08, 2007 at 07:09:29AM +0000, Junio C Hamano wrote:
> The 'automagic parseopt' support corrupted non option parameters
> that had IFS characters in them.  The worst case can be seen
> when it has a non option parameter like this:
> 
> 	$1=" * some string   blech"
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>

> -	parseopt_extra=
> -	[ -n "$OPTIONS_KEEPDASHDASH" ] &&
> -		parseopt_extra="$parseopt_extra --keep-dashdash"
> +	[ -n "$OPTIONS_KEEPDASHDASH" ] && parseopt_extra="--keep-dashdash"

  oh and this part is wrong because you're affected by $parseopt_extra
environment poisonning. And you have to fix git-clone.sh that uses
git-rev-parse --parsopt directly with the same call too (as it doesn't
use git-sh-setup).

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* Re: [PATCH v2] user-manual: add advanced topic "bisecting merges"
From: Johannes Sixt @ 2007-11-08  9:11 UTC (permalink / raw)
  To: Steffen Prohaska; +Cc: gitster, Ralf.Wildenhues, tsuna, git
In-Reply-To: <6E62E205-0951-4CCB-A807-AC107E40ACE1@zib.de>

Steffen Prohaska schrieb:
> 
> On Nov 8, 2007, at 8:19 AM, Johannes Sixt wrote:
> 
>> Steffen Prohaska schrieb:
>>> +If you linearize the history by rebasing the lower branch on
>>> +top of the upper, instead of merging, the bug becomes much easier to
>>> +find and understand.  Your history would instead be:
>>
>> At this point I'm missing the words
>>
>>     The solution is ...
>>
>> I.e.:
>>
>> The solution is to linearize the history by rebasing the lower branch on
>> top of the upper, instead of merging. Now the bug becomes much easier to
>> find and understand.  Your history would instead be:
> 
> Hmm. It might be a solution if you did not publish history.

This is about finding the commit that introduced a bug. Once you found it, 
better: you know how to fix the bug, you are expected to throw away the 
rebased branch, not to publish it! Maybe a note along these lines could be 
appended:

Now that you know what caused the error (and how to fix it), throw away the 
rebased branch, and commit a fix on top of D.

-- Hannes

^ permalink raw reply

* Re: [PATCH v2] user-manual: add advanced topic "bisecting merges"
From: Steffen Prohaska @ 2007-11-08  8:59 UTC (permalink / raw)
  To: Johannes Sixt; +Cc: gitster, Ralf.Wildenhues, tsuna, git
In-Reply-To: <4732B899.6000908@viscovery.net>


On Nov 8, 2007, at 8:19 AM, Johannes Sixt wrote:

> Steffen Prohaska schrieb:
>> +If you linearize the history by rebasing the lower branch on
>> +top of the upper, instead of merging, the bug becomes much easier to
>> +find and understand.  Your history would instead be:
>
> At this point I'm missing the words
>
> 	The solution is ...
>
> I.e.:
>
> The solution is to linearize the history by rebasing the lower  
> branch on
> top of the upper, instead of merging. Now the bug becomes much  
> easier to
> find and understand.  Your history would instead be:

Hmm. It might be a solution if you did not publish history.

How about leaving the text as is and adding an introductory
paragraph at the beginning of the section?

I.e:

This section discusses how gitlink:git-bisect[1] plays
with differently shaped histories. If you did not yet
publish a branch you can use either gitlink:git-merge[1] or
gitlink:git-rebase[1] to integrate changes from a second
branch. The two approaches create differently shaped
histories. So it might be interesting to know about the
implications on gitlink:git-bisect[1].


	Steffen

^ permalink raw reply

* Re: [PATCH] Re: git-svn fetch doesn't like spaces in branch names
From: Benoit Sigoure @ 2007-11-08  8:49 UTC (permalink / raw)
  To: Alex Riesen; +Cc: Michael J. Cohen, Git Mailing List
In-Reply-To: <20071108072918.GC3170@steel.home>

[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]

On Nov 8, 2007, at 8:29 AM, Alex Riesen wrote:

> Michael J. Cohen, Thu, Nov 08, 2007 01:53:07 +0100:
>>> mini:TextMateBundles mjc$ git-svn fetch
>>> Found possible branch point:
>>> http://macromates.com/svn/Bundles/trunk/Tools/Dialog PlugIn =>
>>> http://macromates.com/svn/Bundles/branches/Dialog PlugIn  
>>> Completion Menu,
>>> 8089
>>> Initializing parent: Dialog PlugIn Completion Menu@8089
>>> Bad URL passed to RA layer: Malformed URL for repository at
>>> /opt/local/bin/git-svn line 1607
>>>
>>> looks like that might need to be %20 ?
>>
>>
>> Hacky, but it works.
>>
>> Signed-off-by: Michael J. Cohen <mjc@cruiseplanners.com>
>>
>> diff --git a/git-svn.perl b/git-svn.perl
>> index dd93e32..5dc3b9c 100755
>> --- a/git-svn.perl
>> +++ b/git-svn.perl
>> @@ -1976,6 +1976,7 @@ sub find_parent_branch {
>> 	my $r = $i->{copyfrom_rev};
>> 	my $repos_root = $self->ra->{repos_root};
>> 	my $url = $self->ra->{url};
>> +	$branch_from =~ s@([\s])@sprintf("%%%02X", ord($1))@seg;
>
> You don't need "[" and "]".

You don't even need the "(" and ")"

$branch_from =~ s@\s@sprintf("%%%02X", ord($&))@seg;

But I think it'd be better to fix this properly.  I guess some people  
use branch names with accentuated characters such as é è ü whatever.   
What about this instead (untested):

$branch_from =~ s@[^\w\d_]@sprintf("%%%02X", ord($&))@seg;

Otherwise there are various existing Perl modules such as http:// 
search.cpan.org/dist/URI/URI/Escape.pm but this seems overkill / not  
portable (unless we distribute these files along with Git).

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: [PATCH MISC 1/1] Make gcc warning about empty if body go away.
From: Andreas Ericsson @ 2007-11-08  8:41 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Pierre Habouzit, git
In-Reply-To: <7vode57awg.fsf@gitster.siamese.dyndns.org>

Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
> 
>> diff --git a/builtin-diff.c b/builtin-diff.c
>> index f77352b..80392a8 100644
>> --- a/builtin-diff.c
>> +++ b/builtin-diff.c
>> @@ -204,7 +204,7 @@ static void refresh_index_quietly(void)
>>  		if (write_cache(fd, active_cache, active_nr) ||
>>  		    close(fd) ||
>>  		    commit_locked_index(lock_file))
>> -			; /*
>> +			(void)0; /*
>>  			   * silently ignore it -- we haven't mucked
>>  			   * with the real index.
>>  			   */
> 
> Wouldn't this be much easier to read, by the way?
> 
> The point is that if we touched the active_cache, we try to
> write it out and make it the index file for later users to use
> by calling "commit", but we do not really care about the failure
> from this sequence because it is done purely as an optimization.
> 
> The original code called three functions primarily for their
> side effects, which is admittedly a bad style.
> 
>  builtin-diff.c |   12 +++---------
>  1 files changed, 3 insertions(+), 9 deletions(-)
> 
> diff --git a/builtin-diff.c b/builtin-diff.c
> index f77352b..906c924 100644
> --- a/builtin-diff.c
> +++ b/builtin-diff.c
> @@ -200,15 +200,9 @@ static void refresh_index_quietly(void)
>  	discard_cache();
>  	read_cache();
>  	refresh_cache(REFRESH_QUIET|REFRESH_UNMERGED);
> -	if (active_cache_changed) {
> -		if (write_cache(fd, active_cache, active_nr) ||
> -		    close(fd) ||
> -		    commit_locked_index(lock_file))
> -			; /*
> -			   * silently ignore it -- we haven't mucked
> -			   * with the real index.
> -			   */
> -	}
> +	if (active_cache_changed &&
> +	    !write_cache(fd, active_cache, active_nr) && !close(fd))
> +		commit_locked_index(lock_file);
>  	rollback_lock_file(lock_file);
>  }
>  

Ack, obviously, as it no longer requires a comment to explain it, although
I'd prefer an empty line after commit_locked_index(lock_file); so as to not
confuse the rollback_lock_file() statement as being part of the conditional
path.

First I thought the rollback_lock_file() was the *only* statement to the
condition, and everyone who uses 4 for tabsize) will have double trouble
since commit_locked_index(lock_file) aligns with the second line of the
condition.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

^ permalink raw reply

* Re: [PATCH 4/3] git-fetch: test avoiding unnecessary copying from alternates
From: Shawn O. Pearce @ 2007-11-08  8:34 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <20071108082213.GA17054@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> wrote:
> This test verifies my prior "avoid local fetching from alternate"
> patch is functional and doesn't regress in the future during any
> additional improvements made to git.
...
> +test_expect_success 'quickfetch should not copy from alternate' '
> +
> +	(
> +		mkdir quickclone &&
> +		cd quickclone &&
> +		git init-db &&
> +		(cd ../.git/objects && pwd) >.git/objects/info/alternates &&
> +		git remote add origin .. &&
> +		git fetch -k -k

Hmmph.  On second thought I think this is a little sketchy for
a test.  Versions without my quickfetch patch fail this test and
versions with it pass.  But it depends on the implementation of
`-k -k` to always call index-pack over unpack-objects.

I'm using -k -k here to ensure we keep the pack fetched as we're only
fetching 6 objects and they are already reachable in the quickclone
repository thanks to the alternate ODB.  If we use unpack-objects
during this fetch we will still pass this test because the objects
won't be unpacked if they are already reachable locally.

Of course this test is for a performance optimization.  For 6
tiny objects it really doesn't matter if we copy them or not, or
if we copy them over a pipe only to discard them because they are
already reachable.  It does however matter when you are talking
about nearly 300MB worth of objects.  :-\

-- 
Shawn.

^ permalink raw reply

* Re: [PATCH] git-checkout: Handle relative paths containing "..".
From: Junio C Hamano @ 2007-11-08  8:30 UTC (permalink / raw)
  To: David Symonds; +Cc: git, Johannes Schindelin
In-Reply-To: <1194489192-20021-1-git-send-email-dsymonds@gmail.com>

David Symonds <dsymonds@gmail.com> writes:

> diff --git a/git-checkout.sh b/git-checkout.sh
> index 8993920..b2c50aa 100755
> --- a/git-checkout.sh
> +++ b/git-checkout.sh
> @@ -134,9 +134,10 @@ Did you intend to checkout '$@' which can not be resolved as commit?"
>  	fi
>  
>  	# Make sure the request is about existing paths.
> -	git ls-files --error-unmatch -- "$@" >/dev/null || exit
> -	git ls-files -- "$@" |
> -	git checkout-index -f -u --stdin
> +	git ls-files --full-name --error-unmatch -- "$@" >/dev/null || exit
> +	git ls-files --full-name -- "$@" |
> +		(cd "$(git-rev-parse --show-cdup)" &&
> +		 git checkout-index -f -u --stdin)

Have you tested this patch from the toplevel of any tree, where
"git-rev-parse --show-cdup" would yield an empty string?

I also wonder how this patch (with an obvious fix to address the
above point) would interact with GIT_DIR and/or GIT_WORK_TREE in
the environment.

^ permalink raw reply

* Re: Inconsistencies with git log
From: Peter Baumann @ 2007-11-08  8:29 UTC (permalink / raw)
  To: Andreas Ericsson
  Cc: David Symonds, Brian Gernhardt, Jon Smirl, Johannes Schindelin,
	Git Mailing List
In-Reply-To: <47325415.1070205@op5.se>

On Thu, Nov 08, 2007 at 01:11:01AM +0100, Andreas Ericsson wrote:
> David Symonds wrote:
>> On Nov 8, 2007 10:19 AM, Brian Gernhardt <benji@silverinsanity.com> wrote:
>>> However, Dave's suggestion of altering git-status output to be
>>> relative to (but not limited by) CWD has merit.  Too bad I don't have
>>> time to work on it right now.
>>
>> I am happy to hack on this if there's not widespread revolt against the concept.
>>
>
> I'd definitely like that feature, but I wonder how many people will run
> "git commit -a" in a subdir after seeing only what they want to see in the
> output, and then accidentally committing junk somewhere else in the repo.
>
> So perhaps git-commit -a should also be path-delimited, but where would we
> end up then? It might be better to just let git-status accept a path
> delimiter and let the path delimiter default to current work-dir.
>

I agree that 'git status' should show the *whole* tree and if it will work
in subdirectories with 'git status .' or 'git status Documentation', it
would be a nice UI improvement.

But please don't make it always show only the current subdir.

-Peter

^ permalink raw reply

* Re: [PATCH 2/2] git status: show relative paths when run in a subdirectory
From: Junio C Hamano @ 2007-11-08  8:26 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: David Symonds, Brian Gernhardt, Jon Smirl, Git Mailing List,
	gitster
In-Reply-To: <Pine.LNX.4.64.0711080011170.4362@racer.site>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> -static const char *quote_crlf(const char *in, char *buf, size_t sz)
> +static const char *quote_crlf(const char *in, int len, char *buf, size_t sz,
> +	const char *prefix)
>  {

This is not quote_*crlf* anymore.

> @@ -118,8 +150,8 @@ static void wt_status_print_filepair(struct wt_status *s,
>  	const char *one, *two;
>  	char onebuf[PATH_MAX], twobuf[PATH_MAX];
>  
> -	one = quote_crlf(p->one->path, onebuf, sizeof(onebuf));
> -	two = quote_crlf(p->two->path, twobuf, sizeof(twobuf));
> +	one = quote_crlf(p->one->path, -1, onebuf, sizeof(onebuf), s->prefix);
> +	two = quote_crlf(p->two->path, -1, twobuf, sizeof(twobuf), s->prefix);

I wonder if it makes more sense to use strbuf here...

^ permalink raw reply

* Re: Inconsistencies with git log
From: Andreas Ericsson @ 2007-11-08  0:16 UTC (permalink / raw)
  To: Jon Smirl; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <9e4733910711071609t3e5412f1mf02e501b2d820bb3@mail.gmail.com>

Jon Smirl wrote:
> On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> It is consistent, when you realise that the path arguments are interpreted
>> relative to the project root.
> 
> Then why doesn't this work?
> 
> jonsmirl@terra:~/mpc5200b$ git log Documentation
> all the log for Documentation....
> jonsmirl@terra:~/mpc5200b$ cd Documentation
> jonsmirl@terra:~/mpc5200b/Documentation$ git log Documentation
> fatal: ambiguous argument 'Documentation': unknown revision or path
> not in the working tree.
> Use '--' to separate paths from revisions
> jonsmirl@terra:~/mpc5200b/Documentation$
> 

Because your current working directory, relative to the project root, is
prepended to the path you're in, so git sees "Documentation/Documentation".
I'm unsure why

	cd Documentation; git log -- /Documentation

doesn't do the trick though. I know that particular trick used to work for
some other command a while back anyways.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

^ permalink raw reply

* Re: Inconsistencies with git log
From: Andreas Ericsson @ 2007-11-08  0:11 UTC (permalink / raw)
  To: David Symonds
  Cc: Brian Gernhardt, Jon Smirl, Johannes Schindelin, Git Mailing List
In-Reply-To: <ee77f5c20711071531q5acc4d06u264f5daad7c04cc4@mail.gmail.com>

David Symonds wrote:
> On Nov 8, 2007 10:19 AM, Brian Gernhardt <benji@silverinsanity.com> wrote:
>> However, Dave's suggestion of altering git-status output to be
>> relative to (but not limited by) CWD has merit.  Too bad I don't have
>> time to work on it right now.
> 
> I am happy to hack on this if there's not widespread revolt against the concept.
> 

I'd definitely like that feature, but I wonder how many people will run
"git commit -a" in a subdir after seeing only what they want to see in the
output, and then accidentally committing junk somewhere else in the repo.

So perhaps git-commit -a should also be path-delimited, but where would we
end up then? It might be better to just let git-status accept a path
delimiter and let the path delimiter default to current work-dir.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

^ permalink raw reply

* [PATCH 4/3] git-fetch: test avoiding unnecessary copying from alternates
From: Shawn O. Pearce @ 2007-11-08  8:22 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

This test verifies my prior "avoid local fetching from alternate"
patch is functional and doesn't regress in the future during any
additional improvements made to git.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 t/t5502-quickfetch.sh |   33 +++++++++++++++++++++++++++++++++
 1 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/t/t5502-quickfetch.sh b/t/t5502-quickfetch.sh
index b4760f2..16eadd6 100755
--- a/t/t5502-quickfetch.sh
+++ b/t/t5502-quickfetch.sh
@@ -86,4 +86,37 @@ test_expect_success 'quickfetch should not leave a corrupted repository' '
 
 '
 
+test_expect_success 'quickfetch should not copy from alternate' '
+
+	(
+		mkdir quickclone &&
+		cd quickclone &&
+		git init-db &&
+		(cd ../.git/objects && pwd) >.git/objects/info/alternates &&
+		git remote add origin .. &&
+		git fetch -k -k
+	) &&
+	obj_cnt=$( (
+		cd quickclone &&
+		git count-objects | sed -e "s/ *objects,.*//"
+	) ) &&
+	pck_cnt=$( (
+		cd quickclone &&
+		git count-objects -v | sed -n -e "/packs:/{
+				s/packs://
+				p
+				q
+			}"
+	) ) &&
+	origin_master=$( (
+		cd quickclone &&
+		git rev-parse origin/master
+	) ) &&
+	echo "loose objects: $obj_cnt, packfiles: $pck_cnt" &&
+	test $obj_cnt -eq 0 &&
+	test $pck_cnt -eq 0 &&
+	test z$origin_master = z$(git rev-parse master)
+
+'
+
 test_done
-- 
1.5.3.5.1590.gfadfad

^ permalink raw reply related

* Re: [PATCH DIFF-CLEANUP 1/2] Make the diff_options bitfields be an unsigned with explicit masks.
From: Pierre Habouzit @ 2007-11-08  8:17 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7d95ji1.fsf@gitster.siamese.dyndns.org>

[-- Attachment #1: Type: text/plain, Size: 2688 bytes --]

On Thu, Nov 08, 2007 at 06:39:02AM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
> 
> > reverse_diff was a bit-value in disguise, it's merged in the flags now.
> >
> > Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> 
> Just my first impression, as I am in the middle of unrelated
> bisect.  I haven't read beyond diff-lib.c changes.
> 
> > diff --git a/builtin-diff-tree.c b/builtin-diff-tree.c
> > index 0b591c8..e71841a 100644
> > --- a/builtin-diff-tree.c
> > +++ b/builtin-diff-tree.c
> > @@ -118,12 +118,12 @@ int cmd_diff_tree(int argc, const char **argv, const char *prefix)
> >  	}
> >  
> >  	if (!read_stdin)
> > -		return opt->diffopt.exit_with_status ?
> > -		    opt->diffopt.has_changes: 0;
> > +		return DIFF_OPT_TST(&opt->diffopt, EXIT_WITH_STATUS)
> > +			&& DIFF_OPT_TST(&opt->diffopt, HAS_CHANGES);
> 
> Had to think a bit about this, although it is correct.
> 
> >  	if (opt->diffopt.detect_rename)
> >  		opt->diffopt.setup |= (DIFF_SETUP_USE_SIZE_CACHE |
> > -				       DIFF_SETUP_USE_CACHE);
> > +							   DIFF_SETUP_USE_CACHE);
> 
> I wonder what this is about.

  err I code with tabs of size 4 and I believe my editor was
over-zealous when I asked to reindent some part that I changed :P

> > diff --git a/combine-diff.c b/combine-diff.c
> > index fe5a2a1..3cab04b 100644
> > --- a/combine-diff.c
> > +++ b/combine-diff.c
> > @@ -664,7 +664,7 @@ static void show_patch_diff(struct combine_diff_path *elem, int num_parent,
> >  	int mode_differs = 0;
> >  	int i, show_hunks;
> >  	int working_tree_file = is_null_sha1(elem->sha1);
> > -	int abbrev = opt->full_index ? 40 : DEFAULT_ABBREV;
> > +        int abbrev = DIFF_OPT_TST(opt, FULL_INDEX) ? 40 : DEFAULT_ABBREV;
> 
> Indent?

  will fix.

> > diff --git a/diff-lib.c b/diff-lib.c
> > index da55713..69b5dc9 100644
> > --- a/diff-lib.c
> > +++ b/diff-lib.c
> > @@ -188,8 +188,7 @@ static int handle_diff_files_args(struct rev_info *revs,
> >  		else if (!strcmp(argv[1], "-n") ||
> >  				!strcmp(argv[1], "--no-index")) {
> >  			revs->max_count = -2;
> > -			revs->diffopt.exit_with_status = 1;
> > -			revs->diffopt.no_index = 1;
> > +			revs->diffopt.flags |= DIFF_OPT_EXIT_WITH_STATUS | DIFF_OPT_NO_INDEX;
> >  		}
> 
> Now this looks harder to read that everybody else uses
> DIFF_OPT_SET() for this, without DIFF_OPT_ prefix for the
> bitmask names.

  that could be splitted in two DIFF_OPT_SET indeed. will do.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* Re: [PATCH] git-sh-setup: fix parseopt `eval`.
From: Pierre Habouzit @ 2007-11-08  8:15 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6j15i3a.fsf@gitster.siamese.dyndns.org>

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

On Thu, Nov 08, 2007 at 07:09:29AM +0000, Junio C Hamano wrote:
> The 'automagic parseopt' support corrupted non option parameters
> that had IFS characters in them.  The worst case can be seen
> when it has a non option parameter like this:

hu sorry about that, I should have put "" around the ``. I knew it also
but it slipped my mind too.  I believe this works as well:

eval "$(echo "$OPTIONS_SPEC" | git rev-parse --parseopt $parseopt_extra -- "$@" || echo exit $?)"

I like it better because you will then exit with an exit 129 wich is
what we want (and what I documented would work too :P)

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* Re: [PATCH] git-branch --with=commit
From: Junio C Hamano @ 2007-11-08  8:13 UTC (permalink / raw)
  To: Johannes Sixt; +Cc: git
In-Reply-To: <4732BC6F.7070005@viscovery.net>

Johannes Sixt <j.sixt@viscovery.net> writes:

> Junio C Hamano schrieb:
>>      $ git checkout -b xx/maint-fix-foo
>>      $ git am -3 -s ,xx-maint-fix-foo.patch
>
> Is this comma a hidden feature?

No, just my personal convention to queue e-mails from my mailbox.

>> With this patch, I could do this to find out which topic
>> branches already contain the faulty commit:
>>
>>     $ git branch --with=maint^ | grep /
>>       xx/maint-fix-foo
>
> It'd be helpful if you could construct the example in this commit
> message such that you don't need the "grep /" here; otherwise, the
> reader doesn't know which part of the effect is hidden by the grep.

Yeah, in the example sequence, I think only maint itself and
xx/maint-fix-foo are shown, so there is no need for grep.

^ permalink raw reply

* Re: [PATCH MISC 1/1] Make gcc warning about empty if body go away.
From: Pierre Habouzit @ 2007-11-08  8:12 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7vode57awg.fsf@gitster.siamese.dyndns.org>

[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]

On Thu, Nov 08, 2007 at 02:01:51AM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
> 
> > diff --git a/builtin-diff.c b/builtin-diff.c
> > index f77352b..80392a8 100644
> > --- a/builtin-diff.c
> > +++ b/builtin-diff.c
> > @@ -204,7 +204,7 @@ static void refresh_index_quietly(void)
> >  		if (write_cache(fd, active_cache, active_nr) ||
> >  		    close(fd) ||
> >  		    commit_locked_index(lock_file))
> > -			; /*
> > +			(void)0; /*
> >  			   * silently ignore it -- we haven't mucked
> >  			   * with the real index.
> >  			   */
> 
> Wouldn't this be much easier to read, by the way?
> 
> The point is that if we touched the active_cache, we try to
> write it out and make it the index file for later users to use
> by calling "commit", but we do not really care about the failure
> from this sequence because it is done purely as an optimization.
> 
> The original code called three functions primarily for their
> side effects, which is admittedly a bad style.

  Well all I care is that the warning goes away, it prevents me to build
in -Werror and it's bad :)


-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-11-08  8:08 UTC (permalink / raw)
  To: git
In-Reply-To: <7vr6j6ve90.fsf@gitster.siamese.dyndns.org>

Here are the topics that have been cooking.  Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.  The topics list the commits in reverse chronological
order.

----------------------------------------------------------------
[Will merge to 'master' this weekend]

* js/parseopt-abbrev-fix (Mon Nov 5 13:15:21 2007 +0000) 1 commit
 + parse-options: abbreviation engine fix.

* js/reset (Sat Nov 3 15:21:21 2007 +0000) 2 commits
 + builtin-reset: avoid forking "update-index --refresh"
 + builtin-reset: do not call "ls-files --unmerged"

* js/upload-pack (Sun Nov 4 20:46:48 2007 +0100) 1 commit
 + upload-pack: Use finish_{command,async}() instead of waitpid().

----------------------------------------------------------------
[Will cook til next week and then merge to 'master']

* bg/format-patch-N (Tue Nov 6 10:04:24 2007 +1100) 3 commits
 + Rearrange git-format-patch synopsis to improve clarity.
 + format-patch: Test --[no-]numbered and format.numbered
 + format-patch: Add configuration and off switch for --numbered

* db/remote-builtin (Tue Nov 6 20:29:20 2007 -0500) 6 commits
 + Reteach builtin-ls-remote to understand remotes
 + Build in ls-remote
 + Use built-in send-pack.
 + Build-in send-pack, with an API for other programs to call.
 + Build-in peek-remote, using transport infrastructure.
 + Miscellaneous const changes and utilities

* jc/stash-create (Wed Nov 7 15:10:27 2007 -0600) 5 commits
 + git-stash: Fix listing stashes
 + git-merge: no reason to use cpio anymore
 + Revert "rebase: allow starting from a dirty tree."
 + rebase: allow starting from a dirty tree.
 + stash: implement "stash create"

* lt/rev-list-interactive (Mon Nov 5 13:22:34 2007 -0800) 4 commits
 + revision walker: mini clean-up
 + Enhance --early-output format
 + Add "--early-output" log flag for interactive GUI use
 + Simplify topo-sort logic

* jk/terse-push (Mon Nov 5 00:12:18 2007 -0500) 6 commits
 + send-pack: require --verbose to show update of tracking refs
 + receive-pack: don't mention successful updates
 + more terse push output
 + Build-in send-pack, with an API for other programs to call.
 + Build-in peek-remote, using transport infrastructure.
 + Miscellaneous const changes and utilities

* mh/retag (Sun Nov 4 01:11:15 2007 +0100) 2 commits
 + Add tests for git tag
 + Reuse previous annotation when overwriting a tag

* np/progress (Tue Nov 6 16:30:28 2007 -0500) 6 commits
 + make display of total transferred fully accurate
 + remove dead code from the csum-file interface
 + git-fetch: be even quieter.
 + make display of total transferred more accurate
 + sideband.c: ESC is spelled '\033' not '\e' for portability.
 + fix display overlap between remote and local progress

----------------------------------------------------------------
[Actively cooking]

* ph/parseopt-sh (Wed Nov 7 23:04:38 2007 -0800) 14 commits
 + git-sh-setup: fix parseopt `eval` string underquoting
 + Give git-am back the ability to add Signed-off-by lines.
 + git-rev-parse --parseopt
 + scripts: Add placeholders for OPTIONS_SPEC
 + Migrate git-repack.sh to use git-rev-parse --parseopt
 + Migrate git-quiltimport.sh to use git-rev-parse --parseopt
 + Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-
   dashdash
 + Migrate git-instaweb.sh to use git-rev-parse --parseopt
 + Migrate git-merge.sh to use git-rev-parse --parseopt
 + Migrate git-am.sh to use git-rev-parse --parseopt
 + Migrate git-clone to use git-rev-parse --parseopt
 + Migrate git-clean.sh to use git-rev-parse --parseopt.
 + Update git-sh-setup(1) to allow transparent use of git-rev-parse -
   -parseopt
 + Add a parseopt mode to git-rev-parse to bring parse-options to
   shell scripts.

We are still finding breakages and applying fixes.

* rs/pretty (Wed Nov 7 00:17:14 2007 +0100) 1 commit
 - pretty=format: Avoid some expensive calculations when not needed

The numbers are impressive and the code is reasonably clean, but
René seems to have further improvements to the API?

* sb/clean (Sun Nov 4 13:02:21 2007 -0600) 1 commit
 - Make git-clean a builtin

I ran out of time to look at the replacement patch.  Sorry.

* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits
 - Make git-svn rebase --dirty pass along --dirty to git-rebase.
 - Implement --dirty for git-rebase--interactive.
 - Introduce --dirty option to git-rebase, allowing you to start from
   a dirty state.

Really need to look at this series to merge to 'next'.  Sorry.

* sp/push-refspec (Sun Oct 28 18:46:20 2007 +0100) 5 commits
 - push: teach push to pass --verbose option to transport layer
 - push: use same rules as git-rev-parse to resolve refspecs
 - add ref_abbrev_matches_full_with_rev_parse_rules() comparing
   abbrev with full ref name
 - rename ref_matches_abbrev() to
   ref_abbrev_matches_full_with_fetch_rules()
 - push: support pushing HEAD to real branch name

Really need to look at this series to merge to 'next'.  Sorry.

----------------------------------------------------------------
[Stalled]

* bs/maint-commit-options (Mon Nov 5 20:36:33 2007 +0100) 1 commit
 - git-commit.sh: Fix usage checks regarding paths given when they do
   not make sense

This is waiting for tests.  Then merge to 'next', 'master' and
then to 'maint'.

* nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit
 + Add missing inside_work_tree setting in setup_git_directory_gently

This is waiting for tests.  Then merge to 'next', 'master' and
then to 'maint'.

* rr/cvsexportcommit-w (Wed Oct 31 23:12:20 2007 +0100) 1 commit
 + cvsexportcommit: Add switch to specify CVS workdir

Need success stories, but pushing it out to 'master' may be the
only way to get users' attention.

* jc/spht (Fri Nov 2 17:46:55 2007 -0700) 3 commits
 + core.whitespace: add test for diff whitespace error highlighting
 + git-diff: complain about >=8 consecutive spaces in initial indent
 + War on whitespace: first, a bit of retreat.

Remaining tasks are:

 1. teach "git-apply --whitespace=[warn|strip]" the same;
 2. (possibly) use gitattributes instead of config.

* dz/color-addi (Mon Oct 22 16:08:01 2007 -0500) 2 commits
 - Let git-add--interactive read colors from .gitconfig
 - Added basic color support to git add --interactive

There was a RFH to avoid "require Term::ANSIColor" in Git.pm and
a suggestion in response to it, but I do not recall
anything happened afterwards.  Stalled.

* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
 + Teach "git reflog" a subcommand to delete single entries

This does not have a in-tree user yet.

* kh/commit (Fri Nov 2 11:33:09 2007 -0400) 3 commits
 - Implement git commit and status as a builtin commands.
 - Export launch_editor() and make it accept ':' as a no-op editor.
 - Add testcase for ammending and fixing author in git commit.

This does not pass tests.

* sp/fetch-fix (Tue Nov 6 21:41:18 2007 -0500) 2 commits
 - git-fetch: avoid local fetching from alternate (again)
 - run-command: allow discarding the standard error output

This does not pass tests (breaks shallow clone deepening).

* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits
 - handle renames using similarity engine
 - introduce generic similarity library
 - change hash table calling conventions

This does not pass tests.

* jc/maint-format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits
 - test format-patch -s: make sure MIME content type is shown as
   needed
 - format-patch -s: add MIME encoding header if signer's name
   requires so

This is already in 'master' but rebased for 'maint', just in
case we would want a maint release with this series.

* jc/branch-contains (Wed Nov 7 14:58:09 2007 -0800) 1 commit
 - git-branch --with=commit

This was just for fun.

* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits
 - pathspec_can_match(): move it from builtin-ls-tree.c to tree.c
 - ls-tree.c: refactor show_recursive() and rename it.
 - tree-diff.c: split out a function to match a single pattern.

My pet peeve.  Completely stalled.

* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
 - merge-nu: a new merge backend without using unpack_trees()
 - read_tree: take an explicit index structure
 - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix

Seriously stalled.

^ permalink raw reply

* What's in git.git (stable)
From: Junio C Hamano @ 2007-11-08  8:06 UTC (permalink / raw)
  To: git
In-Reply-To: <7vpryqwtt7.fsf@gitster.siamese.dyndns.org>

On 'master' front:

 - git-p4 in contrib/ has updates.  As I cannot test it myself
   and did not hear any success/failure stories from the list,
   the only way to make sure is to push it out and see if
   anybody screams.

 - "git lost-found" is going to be deprecated (not removed) in
   the next feature release.

 - Unspecified clean.requireForce defaults to true; this would
   make "git clean" require "-f" by default.

 - "git send-email --suppress-from" does not CC yourself even
   when your name is on S-o-b: or Cc: lines in the body of the
   message.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

Ask Bjørn Hansen (1):
  When exec() fails include the failing command in the error message

David D Kilzer (2):
  RelNotes-1.5.3.5: fix typo
  RelNotes-1.5.3.5: fix another typo

Eric Wong (2):
  git-svn: fix dcommit clobbering when committing a series of diffs
  git-svn: t9114: verify merge commit message in test

Gerrit Pape (3):
  git-diff.txt: add section "output format" describing the diff
      formats
  git-cvsimport: really convert underscores in branch names to dots
      with -u
  git-daemon: fix remote port number in log entry

Johannes Schindelin (1):
  Add Documentation/CodingGuidelines

Junio C Hamano (1):
  grep with unmerged index

Marco Costalba (1):
  Remove a couple of duplicated include

Mike Hommey (1):
  Delay pager setup in git blame


* The 'master' branch has these since the last announcement
  in addition to the above.

Benoit Sigoure (1):
  git-svn: sort the options in the --help message.

Brian Gernhardt (1):
  t3502: Disambiguate between file and rev by adding --

Chris Pettitt (2):
  git-p4: Add a helper function to parse the full git diff-tree
      output.
  git-p4: Detect changes to executable bit and include them in p4
      submit.

Daniel Barkalow (1):
  Use parseopts in builtin-push

David Symonds (1):
  Improve accuracy of check for presence of deflateBound.

Gerrit Pape (4):
  git-reset: add -q option to operate quietly
  contrib/hooks/post-receive-email: fix typo
  contrib/hooks/post-receive-email: reformat to wrap comments at 76
      chars
  contrib/hooks/post-receive-email: make subject prefix configurable

Heikki Orsila (1):
  git-clone: honor "--" to end argument parsing

J. Bruce Fields (1):
  errors: "strict subset" -> "ancestor"

Jakub Narebski (9):
  gitweb: Always set 'from_file' and 'to_file' in
      parse_difftree_raw_line
  gitweb: Add 'status_str' to parse_difftree_raw_line output
  gitweb: Remove CGI::Carp::set_programname() call from t9500 gitweb
      test
  gitweb: Easier adding/changing parameters to current URL
  gitweb: Use href(-replay=>1, page=>...) to generate pagination
      links
  gitweb: Use href(-replay=>1, action=>...) to generate alternate
      views
  gitweb: Add tests for overriding gitweb config with repo config
  gitweb: Read repo config using 'git config -z -l'
  gitweb: Use config file for repository description and URLs

Johannes Schindelin (3):
  git-reset: do not be confused if there is nothing to reset
  Split off the pretty print stuff into its own file
  Deprecate git-lost-found

Johannes Sixt (1):
  Fix an infinite loop in sq_quote_buf().

Junio C Hamano (6):
  revert/cherry-pick: work on merge commits as well
  format-patch -s: add MIME encoding header if signer's name requires
      so
  cherry-pick/revert -m: add tests
  test format-patch -s: make sure MIME content type is shown as
      needed
  clean: require -f to do damage by default
  gc: --prune prunes unreferenced objects.

Mike Hommey (5):
  Refactor working tree setup
  Use setup_work_tree() in builtin-ls-files.c
  Don't always require working tree for git-rm
  Make git-blame fail when working tree is needed and we're not in
      one
  Small code readability improvement in show_reference() in
      builtin-tag.c

Nicolas Pitre (4):
  make the pack index version configurable
  pack-objects: get rid of an ugly cast
  git-fetch: more terse fetch output
  restore fetching with thin-pack capability

Pierre Habouzit (1):
  Some better parse-options documentation.

Ralf Wildenhues (1):
  Fix minor nits in configure.ac

Shawn Bohrer (1):
  Add more tests for git-clean

Simon Sasburg (1):
  Make mailsplit and mailinfo strip whitespace from the start of the
      input

Steffen Prohaska (1):
  Fix comment in strbuf.h to use correct name strbuf_avail()

Steven Grimm (1):
  builtin-fetch: Add "-q" as a synonym for "--quiet"

Uwe Kleine-König (1):
  send-email: apply --suppress-from to S-o-b and cc-cmd

^ permalink raw reply

* Re: [PATCH] git-fetch: avoid local fetching from alternate (again)
From: Shawn O. Pearce @ 2007-11-08  8:04 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsl3iefoj.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > Back in e3c6f240fd9c5bdeb33f2d47adc859f37935e2df Junio taught
> > git-fetch to avoid copying objects when we are fetching from
> > a repository that is already registered as an alternate object
> > database.  In such a case there is no reason to copy any objects
> > as we can already obtain them through the alternate.
> 
> The regression the patch fixes should be testable with a
> script.  Please have a new test for it.

Hmmph.  t5502-quickfetch should have covered this.  It obviously
wasn't testing the right thing here.  I'll figure out why and post
a patch to fix t5502.

-- 
Shawn.

^ permalink raw reply

* [PATCH 3/3] git-fetch: avoid local fetching from alternate (again)
From: Shawn O. Pearce @ 2007-11-08  8:00 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Back in e3c6f240fd9c5bdeb33f2d47adc859f37935e2df Junio taught
git-fetch to avoid copying objects when we are fetching from
a repository that is already registered as an alternate object
database.  In such a case there is no reason to copy any objects
as we can already obtain them through the alternate.

However we need to ensure the objects are all reachable, so we
run `git rev-list --objects $theirs --not --all` to verify this.
If any object is missing or unreadable then we need to fetch/copy
the objects from the remote.  When a missing object is detected
the git-rev-list process will exit with a non-zero exit status,
making this condition quite easy to detect.

Although git-fetch is currently a builtin (and so is rev-list)
we cannot invoke the traverse_objects() API at this point in the
transport code.  The object walker within traverse_objects() calls
die() as soon as it finds an object it cannot read.  If that happens
we want to resume the fetch process by calling do_fetch_pack().
To get aroaund this we spawn git-rev-list into a background process
to prevent a die() from killing the foreground fetch process,
thus allowing the fetch process to resume into do_fetch_pack()
if copying is necessary.

We aren't interested in the output of rev-list (a list of SHA-1
object names that are reachable) or its errors (a "spurious" error
about an object not being found as we need to copy it) so we redirect
both stdout and stderr to /dev/null.

We run this git-rev-list based check before any fetch as we may
already have the necessary objects local from a prior fetch.  If we
don't then its very likely the first $theirs object listed on the
command line won't exist locally and git-rev-list will die very
quickly, allowing us to start the network transfer.  This test even
on remote URLs may save bandwidth if someone runs `git pull origin`,
sees a merge conflict, resets out, then redoes the same pull just
a short time later.  If the remote hasn't changed between the two
pulls and the local repository hasn't had git-gc run in it then
there is probably no need to perform network transfer as all of
the objects are local.

Documentation for the new fetch_local_nocopy function was suggested
and written by Junio, based on his original comment in git-fetch.sh.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 transport.c |   68 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 65 insertions(+), 3 deletions(-)

diff --git a/transport.c b/transport.c
index f4577b7..d37864e 100644
--- a/transport.c
+++ b/transport.c
@@ -615,17 +615,76 @@ static struct ref *get_refs_via_connect(struct transport *transport)
 	return refs;
 }
 
+/*
+ * We would want to bypass the object transfer altogether if
+ * everything we are going to fetch already exists and connected
+ * locally.
+ *
+ * The refs we are going to fetch are in to_fetch (nr_heads in
+ * total).  If running
+ *
+ *  $ git-rev-list --objects to_fetch[0] to_fetch[1] ... --not --all
+ *
+ * does not error out, that means everything reachable from the
+ * refs we are going to fetch exists and is connected to some of
+ * our existing refs.
+ */
+static int fetch_local_nocopy(struct transport *transport,
+			       int nr_heads, struct ref **to_fetch)
+{
+	struct git_transport_data *data = transport->data;
+	struct child_process revlist;
+	char **argv;
+	int i, j, err;
+
+	/*
+	 * If we are deepening a shallow clone we already have these
+	 * objects reachable.  Running rev-list here will return with
+	 * a good (0) exit status and we'll bypass the fetch that we
+	 * really need to perform.  Claiming failure now will ensure
+	 * we perform the network exchange to deepen our history.
+	 */
+	if (data->depth)
+		return -1;
+
+	i = 0;
+	argv = xmalloc(sizeof(*argv) * (nr_heads + 6));
+	argv[i++] = xstrdup("rev-list");
+	argv[i++] = xstrdup("--no-output");
+	argv[i++] = xstrdup("--objects");
+	for (j = 0; j < nr_heads; j++)
+		argv[i++] = xstrdup(sha1_to_hex(to_fetch[j]->old_sha1));
+	argv[i++] = xstrdup("--not");
+	argv[i++] = xstrdup("--all");
+	argv[i++] = NULL;
+
+	memset(&revlist, 0, sizeof(revlist));
+	revlist.argv = (const char**)argv;
+	revlist.git_cmd = 1;
+	revlist.no_stdin = 1;
+	revlist.no_stdout = 1;
+	revlist.no_stderr = 1;
+	err = run_command(&revlist);
+
+	for (i = 0; argv[i]; i++)
+		free(argv[i]);
+	free(argv);
+	return err;
+}
+
 static int fetch_refs_via_pack(struct transport *transport,
 			       int nr_heads, struct ref **to_fetch)
 {
 	struct git_transport_data *data = transport->data;
-	char **heads = xmalloc(nr_heads * sizeof(*heads));
-	char **origh = xmalloc(nr_heads * sizeof(*origh));
+	char **heads, **origh;
 	struct ref *refs;
-	char *dest = xstrdup(transport->url);
+	char *dest;
 	struct fetch_pack_args args;
 	int i;
 
+	if (!fetch_local_nocopy(transport, nr_heads, to_fetch))
+		return 0;
+
 	memset(&args, 0, sizeof(args));
 	args.uploadpack = data->uploadpack;
 	args.keep_pack = data->keep;
@@ -634,6 +693,9 @@ static int fetch_refs_via_pack(struct transport *transport,
 	args.verbose = transport->verbose > 0;
 	args.depth = data->depth;
 
+	heads = xmalloc(nr_heads * sizeof(*heads));
+	origh = xmalloc(nr_heads * sizeof(*origh));
+	dest = xstrdup(transport->url);
 	for (i = 0; i < nr_heads; i++)
 		origh[i] = heads[i] = xstrdup(to_fetch[i]->name);
 	refs = fetch_pack(&args, dest, nr_heads, heads, &transport->pack_lockfile);
-- 
1.5.3.5.1590.gfadfad

^ permalink raw reply related

* [PATCH 2/3] rev-list: Introduce --no-output to avoid /dev/null redirects
From: Shawn O. Pearce @ 2007-11-08  8:00 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Some uses of git-rev-list are to run it with --objects to see if
a range of objects between two or more commits is fully connected
or not.  In such a case the caller doesn't care about the actual
object names or hash hints so formatting this data only for it to
be dumped to /dev/null by a redirect is a waste of CPU time.  If
all the caller needs is the exit status then --no-output can be
used to bypass the commit and object formatting.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 Documentation/git-rev-list.txt |    9 +++++++++
 builtin-rev-list.c             |   26 ++++++++++++++++++++++----
 2 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 4852804..66ddbd3 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -20,6 +20,7 @@ SYNOPSIS
 	     [ \--not ]
 	     [ \--all ]
 	     [ \--stdin ]
+	     [ \--no-output ]
 	     [ \--topo-order ]
 	     [ \--parents ]
 	     [ \--timestamp ]
@@ -270,6 +271,14 @@ limiting may be applied.
 	In addition to the '<commit>' listed on the command
 	line, read them from the standard input.
 
+--no-output::
+
+	Don't print anything to standard output.  This form of
+	git-rev-list is primarly meant to allow the caller to
+	test the exit status to see if a range of objects is fully
+	connected (or not).  It is faster than redirecting stdout
+	to /dev/null as the output does not have to be formatted.
+
 --cherry-pick::
 
 	Omit any commit that introduces the same change as
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 2dec887..634b1f4 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -26,6 +26,7 @@ static const char rev_list_usage[] =
 "    --remove-empty\n"
 "    --all\n"
 "    --stdin\n"
+"    --no-output\n"
 "  ordering output:\n"
 "    --topo-order\n"
 "    --date-order\n"
@@ -50,6 +51,7 @@ static int show_timestamp;
 static int hdr_termination;
 static const char *header_prefix;
 
+static void noshow_commit(struct commit *commit);
 static void show_commit(struct commit *commit)
 {
 	if (show_timestamp)
@@ -93,6 +95,11 @@ static void show_commit(struct commit *commit)
 		strbuf_release(&buf);
 	}
 	maybe_flush_or_die(stdout, "stdout");
+	noshow_commit(commit);
+}
+
+static void noshow_commit(struct commit *commit)
+{
 	if (commit->parents) {
 		free_commit_list(commit->parents);
 		commit->parents = NULL;
@@ -101,6 +108,12 @@ static void show_commit(struct commit *commit)
 	commit->buffer = NULL;
 }
 
+static void noshow_object(struct object_array_entry *p)
+{
+	if (p->item->type == OBJ_BLOB && !has_sha1_file(p->item->sha1))
+		die("missing blob object '%s'", sha1_to_hex(p->item->sha1));
+}
+
 static void show_object(struct object_array_entry *p)
 {
 	/* An object with name "foo\n0000000..." can be used to
@@ -108,9 +121,7 @@ static void show_object(struct object_array_entry *p)
 	 */
 	const char *ep = strchr(p->name, '\n');
 
-	if (p->item->type == OBJ_BLOB && !has_sha1_file(p->item->sha1))
-		die("missing blob object '%s'", sha1_to_hex(p->item->sha1));
-
+	noshow_object(p);
 	if (ep) {
 		printf("%s %.*s\n", sha1_to_hex(p->item->sha1),
 		       (int) (ep - p->name),
@@ -527,6 +538,7 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
 	int read_from_stdin = 0;
 	int bisect_show_vars = 0;
 	int bisect_find_all = 0;
+	int nooutput = 0;
 
 	git_config(git_default_config);
 	init_revisions(&revs, prefix);
@@ -565,6 +577,10 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
 			read_revisions_from_stdin(&revs);
 			continue;
 		}
+		if (!strcmp(arg, "--no-output")) {
+			nooutput = 1;
+			continue;
+		}
 		usage(rev_list_usage);
 
 	}
@@ -640,7 +656,9 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
 		}
 	}
 
-	traverse_commit_list(&revs, show_commit, show_object);
+	traverse_commit_list(&revs,
+		nooutput ? noshow_commit : show_commit,
+		nooutput ? noshow_object : show_object);
 
 	return 0;
 }
-- 
1.5.3.5.1590.gfadfad

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox