headers
Jakub Narebski | 1 Nov 2007 01:22
Picon
Gravatar

Re: remote#branch

Mike Hommey wrote:
> On Wed, Oct 31, 2007 at 10:03:16AM +0100, Andreas Ericsson <ae <at> op5.se> wrote:
>>>
>>>Or copied from gitweb.
>>>
>> Perhaps, but I've never seen that done. Partly because you can't be sure
>> the HTTP url is the same as the git address (perhaps people are used to
>> this from CVS and the likes), and partly because you'd, for most cases,
>> want to use git:// or ssh transport instead of http.
>> 
>> It might be nifty to have gitweb print some git-valid locator for a repo
>> though, or even a full copy-pastable "git clone git://host/path/to/repo.git"
>> command-line thingie. I'll look into it when I have leisure.
> 
> Hum... it already does print http and git "Mirror URL"s which are ready to
> be copy/pasted to feed git clone arguments.

The only thing to add (for absolutely no gain IMHO) would be code
which would add quotes (single or double) around URL/path which
contain spaces:

  Mirror URL    'git://repo.or.cz/repo with spaces.git'
                'http://repo.or.cz/r/repo with spaces.git'
  Push URL      'repo.or.cz:/srv/git/repo with spaces.git'  

--

-- 
Jakub Narebski
Poland
Permalink | Reply | 1 comment |
headers
Linus Torvalds | 1 Nov 2007 01:46
Gravatar

Re: [PATCH] Don't use cpio in git-clone when not installed


On Wed, 31 Oct 2007, Mike Hommey wrote:
> +	if type cpio > /dev/null 2>&1; then
> +		local=yes
> +	fi

Isn't "type" a bashism?

Maybe just do

	if echo . | cpio -o > /dev/null 2>&1; then

instead? Maybe even doing this at install time to avoid the overhead of 
executing another process..

		Linus
Permalink | Reply | 5 comments |
headers
Jakub Narebski | 1 Nov 2007 02:00
Picon
Gravatar

Re: [PATCH] Don't use cpio in git-clone when not installed

Linus Torvalds wrote:

> 
> 
> On Wed, 31 Oct 2007, Mike Hommey wrote:
>> +    if type cpio > /dev/null 2>&1; then
>> +            local=yes
>> +    fi
> 
> Isn't "type" a bashism?
> 
> Maybe just do
> 
>       if echo . | cpio -o > /dev/null 2>&1; then
> 
> instead? Maybe even doing this at install time to avoid the overhead of 
> executing another process..

Or perhaps trap / check actual execution of cpio in git-clone, and
fallback to ln -s / link if it fails...

--

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Permalink | Reply | 0 comments |
headers
Nguyen Thai Ngoc Duy | 1 Nov 2007 02:05
Picon
Gravatar

Re: [PATCH] Don't use cpio in git-clone when not installed

On 11/1/07, Linus Torvalds <torvalds <at> linux-foundation.org> wrote:
>
>
> On Wed, 31 Oct 2007, Mike Hommey wrote:
> > +     if type cpio > /dev/null 2>&1; then
> > +             local=yes
> > +     fi
>
> Isn't "type" a bashism?

busybox ash has "type". I'm happy.

--

-- 
Duy
Permalink | Reply | 0 comments |
headers
Nguyen Thai Ngoc Duy | 1 Nov 2007 02:09
Picon
Gravatar

Re: [PATCH] Don't use cpio in git-clone when not installed

BTW, you have workaround for git-merge also? It uses cpio to save/restore state.

On 11/1/07, Mike Hommey <mh <at> glandium.org> wrote:
>
> Signed-off-by: Mike Hommey <mh <at> glandium.org>
> ---
>  git-clone.sh |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/git-clone.sh b/git-clone.sh
> index 0ea3c24..57e96ae 100755
> --- a/git-clone.sh
> +++ b/git-clone.sh
>  <at>  <at>  -191,7 +191,9  <at>  <at>  fi
>  # it is local
>  if base=$(get_repo_base "$repo"); then
>         repo="$base"
> -       local=yes
> +       if type cpio > /dev/null 2>&1; then
> +               local=yes
> +       fi
>  fi
>
>  dir="$2"
> --
> 1.5.3.4
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 715 comments |
headers
Junio C Hamano | 1 Nov 2007 02:12
Picon
Picon
Favicon
Gravatar

Re: [PATCH] Don't use cpio in git-clone when not installed

Linus Torvalds <torvalds <at> linux-foundation.org> writes:

> On Wed, 31 Oct 2007, Mike Hommey wrote:
>> +	if type cpio > /dev/null 2>&1; then
>> +		local=yes
>> +	fi
>
> Isn't "type" a bashism?

I seem to recall that it is in POSIX.
Permalink | Reply | 0 comments |
headers
Junio C Hamano | 1 Nov 2007 02:15
Picon
Picon
Favicon
Gravatar

Re: [PATCH] Don't use cpio in git-clone when not installed

"Nguyen Thai Ngoc Duy" <pclouds <at> gmail.com> writes:

> BTW, you have workaround for git-merge also? It uses cpio to save/restore state.

Why do people want "workaround"?  Is installing cpio such a
hassle?
Permalink | Reply | 4 comments |
headers
Nguyen Thai Ngoc Duy | 1 Nov 2007 02:25
Picon
Gravatar

Re: [PATCH] Don't use cpio in git-clone when not installed

On 11/1/07, Junio C Hamano <gitster <at> pobox.com> wrote:
> "Nguyen Thai Ngoc Duy" <pclouds <at> gmail.com> writes:
>
> > BTW, you have workaround for git-merge also? It uses cpio to save/restore state.
>
> Why do people want "workaround"?  Is installing cpio such a
> hassle?

It is on Windows because busybox cpio is not really good and busybox
tar is even worse (for cpio emulation). Maybe I should just improve
busybox cpio :-)
--

-- 
Duy
Permalink | Reply | 1 comment |
headers
Nicolas Pitre | 1 Nov 2007 03:27

Re: Newbie: report of first experience with git-rebase.

On Wed, 31 Oct 2007, Junio C Hamano wrote:

> A rebase conflict resolution that results in emptiness is a
> rather rare event (especially because rebase drops upfront the
> identical changes from the set of commits to be replayed), but
> it does happen.  One could argue that "rebase --continue" can
> notice that the resolved index is identical to the tree of the
> HEAD commit and skip it automatically.
> 
> Given an index that is identical to HEAD, however, it is not
> easy to safely determine if that is because the patch did not
> apply at all, or the patch was applied with conflicts _and_ the
> user decided to make the patch a no-op by resolving.  The
> automatic droppage of the commit needs to happen only on the
> latter and never on the former.

Probably some additional clue could be displayed for the user benefit.  
This might solve the issue nicely.

Nicolas
Permalink | Reply | 0 comments |
headers
Shawn O. Pearce | 1 Nov 2007 03:58
Gravatar

Re: [PATCH 1/5] prune-packed: don't call display_progress() for every file

Nicolas Pitre <nico <at> cam.org> wrote:
> The progress count is per fanout directory, so it is useless to call
> it for every file as the count doesn't change that often.

If you go back into the history and look at the commit message for
when I introduced this per-object display_progress() call we find
the following:

 commit b5d72f0a4cd3cce945ca0d37e4fa0ebbfcdcdb52
 Author: Shawn O. Pearce <spearce <at> spearce.org>
 Date:   Fri Oct 19 00:08:37 2007 -0400

[...snip...]
    We perform the display_progress() call from within the very innermost
    loop in case we spend more than 1 second within any single object
    directory.  This ensures that a progress_update event from the
    timer will still trigger in a timely fashion and allow the user to
    see the progress meter.

During my testing with a 40,000 loose object case (yea, I fully
unpacked a git.git clone I had laying around) my system stalled
hard in the first object directory.  A *lot* longer than 1 second.
So I got no progress meter for a long time, and then a progress
meter appeared on the second directory.

The display_progress() call already does a reasonably cheap
comparsion to see if the timer has tripped or if the percent complete
has changed.  So I figured it was more useful to get feedback to
the user that we were working, but were going to take a while,
than it was to optimize a few machine instructions out of that
(Continue reading)

Permalink | Reply | 1 comment |

Gmane