* Re: [PATCH] git-grep: convert from bash to sh
From: Linus Torvalds @ 2005-12-18 19:57 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: Junio C Hamano, git
In-Reply-To: <20051218152639.5c14bc26.tihirvon@gmail.com>
On Sun, 18 Dec 2005, Timo Hirvonen wrote:
>
> sh does not support arrays so we have to use eval instead.
This seems horribly broken.
If I'm not mistaken, this breaks
git grep "it's a happy coincidence"
badly. I didn't test, just looking at the patch.
Dammit, I'd rather depend on "bash"/"ksh" than have a broken "git grep".
Tell people to get a real shell.
Linus
^ permalink raw reply
* Re: [PATCH] git-grep: convert from bash to sh
From: Junio C Hamano @ 2005-12-18 19:37 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051218145621.GX22159@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I'm kind of sensitive to this stuff. I still passionately hate scp
> making me to double-quote remote filenames. It's just evil.
OK.
> --ignored|--exclude=*|\
> --exclude-from=*|\--exclude-per-directory=*)
> - git_flags=("${git_flags[@]}" "$1")
> + git_flags="$git_flags '$1'"
SQs in --exclude= or --exclude-from= parameter? E.g.
git grep --exclude-from="/cygdrive/c/pasky's patterns/cvsignore" \
-e foobar
> -A|-B|-C|-D|-d|-f|-m)
> - flags=("${flags[@]}" "$1" "$2")
> + flags="$flags '$1' '$2'"
> shift
SQs in $2 for -f. About other flags, -[ABCm] take only numbers
and -[Dd] take read/skip/recurse, so as long as your user does
not screw up you are OK. And malicious users are shooting
themselves in the foot here so we might not care too much being
loose.
> @@ -46,5 +46,6 @@ done
> [ "$pattern" ] || {
> usage
> }
> -git-ls-files -z "${git_flags[@]}" "$@" |
> - xargs -0 grep "${flags[@]}" -e "$pattern"
> +pattern="$(echo "$pattern" | sed 's/[\\"]/\\&/g')"
> +eval git-ls-files -z "$git_flags" '"$@"' |
> + eval xargs -0 grep "$flags" -e '"$pattern"'
You are not expanding $pattern in the outer shell that builds
eval arguments (letting the inner shell expand "$pattern" and
use it), so I do not think you need that sed script to muck with
it there. The eval'ed string is literally "$pattern" including
double quotes because you have sq around the last parameter to
"eval" command, and eval would do the right thing, no?
Actually the use of sed script there is actively wrong. When a
file contains these lines:
printf("%s is not there\n");
printf("\"%s\" is not there\n");
the command to pick up the second line should be:
$ git-grep -e '\\"%s\\"'
but I think your version passes \\\\\"%s\\\\\ to underlying
grep. Removing that single line would make it do the right
thing, I think.
Enough nitpicking. If you want to stay in shell and want to
avoid shell array, you would either need to be a bit more
careful if you are going to use eval, or do something like what
I originally did, which made Linus' brain shut down and had him
gouge his eyes with a spoon. It is the one that this one is a
response to:
http://marc.theaimsgroup.com/?l=git&m=112656882627760
Not that I am suggesting the latter is better than a bit more
careful 'eval' construction ;-).
I am not happy with that [@] thing either. I have the attached
laying around in my working tree --- I do not remember if I
finished it or not; it's a WIP when I thought about this issue
last time and wondered if we might be better off rewriting the
whole thing.
-- >8 --
#!/usr/bin/perl
#
# Copyright (c) 2005 Junio C Hamano
#
use strict;
my (@git_flag, @grep_flag, $pattern);
my $nargs = 100;
my (%git_ls_files_flag) =
map { '--' . $_ => 1 }
qw{cached deleted others kiled ignored
exclude= exclude-from= exclude-per-directory=};
sub is_git_flag {
my ($arg) = @_;
$arg =~ s/^([^=]*)=/$1/;
return (exists $git_ls_files_flag{$arg});
}
while (@ARGV) {
my ($arg) = shift @ARGV;
if (is_git_flag($arg)) {
push @git_flag, $arg;
}
elsif ($arg eq '-e') {
$pattern = shift @ARGV;
}
elsif ($arg =~ /^-[ABCDdfm]$/) {
push @grep_flag, $arg, (shift @ARGV);
}
elsif ($arg =~ /^--$/) {
shift @ARGV;
last;
}
elsif ($arg =~ /^-/) {
push @grep_flag, $arg;
}
elsif (! defined $pattern) {
$pattern = $arg;
last;
}
else {
last;
}
}
my $ih;
open $ih, '-|', qw(git-ls-files -z), @git_flag, @ARGV;
$/ = "\0";
my @args = ();
while (<$ih>) {
chomp;
push @args, $_;
if ($nargs <= @args) {
system 'grep', @grep_flag, '-e', $pattern, @args;
@args = ();
}
}
close $ih;
if (@args) {
system 'grep', @grep_flag, '-e', $pattern, @args;
}
^ permalink raw reply
* Re: [PATCH] diff: --abbrev option
From: Junio C Hamano @ 2005-12-18 18:35 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051218114522.GW22159@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Ok, that's nice! :-) And if I'm going to machine-process this later,
> I can just trim the trailing dots anyway. And it seems that I can give
> --abbrev a number argument to specify the minimal abbreviation, even
> cooler! :-)
Well, it is not for machine consumption to begin with anyway.
It is an optional toy ;-).
^ permalink raw reply
* [ANNOUNCE qgit-1.0rc1]
From: Marco Costalba @ 2005-12-18 17:45 UTC (permalink / raw)
To: git
A good amount of small fixes and just few non intrusive features
added, biggest one are speed-up of ref reading at startup, a per
repository charset encoding using i18n.commitencoding git config
variable and an annotation progress bar.
I plan to relase 1.0 for end of next week, so I would like to catch
last minutes bugs with this rc1.
Thanks to Pavel and Junio for fixes and suggestions.
DOWNLOAD
Download tarball from sourceforge as usual:
http://prdownloads.sourceforge.net/qgit/qgit-1.0rc1.tar.bz2?download
Or directly from git repository:
http://digilander.libero.it/mcostalba/qgit.git
With Junio help, I setup the repository to work both with cg-clone and
git-clone and also
tags fetching is available now ;-)
INSTALLATION
You need scons and qt-mt developer libs, version 3.3.4 or better,
already installed.
qgit is NOT compatible with Qt4.
On some platforms (Debian) you should set QTDIR before to compile.
- unpack tar file
- make
- make install
qgit will be installed in $HOME/bin
CHANGELOG
- reselect current revision after a refresh or a tree filter/un-filter
- speed up startup refs reading deferring tag messages fetching
- print offending command line when running commands synchronously
- added fancy annotation progress bar
- use git variable i18n.commitencoding to store charset codec name
- converted to use git-peek-remote to read refs: slower but cleaner
- added python and perl file icons in tree view
- fix a long standing bug that filters out error reporting when a
process writes to stderr
- fix tree filtering when tree selected item is not visible
- fix error getting file sha
- add wait cursor while opening tree directory
- fix issue with mouse right-click that could freeze the UI in some cases
- always load names cache file if present
- fix graph in (rare) case of initial rev to be a fork
- fix enable/disable 'view diff' and 'view file' menus policy
- fix multi-tag commits display in status bar
- remove PGP signature from tag message
- fix file viewer sometimes opens on a wrong file when file is tree selected
Marco
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* Re: bad git pull
From: Nicolas Pitre @ 2005-12-18 17:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5juub9h.fsf@assigned-by-dhcp.cox.net>
On Sat, 17 Dec 2005, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> >> I do not see much difference either way,
> >
> > ORIG suggests "origin" to me,...
>
> Hmph.
>
> I always thought it was original-head before the operation
> happened, which is why I said it is no different from
> previous-head.
OK I agree.
Nicolas
^ permalink raw reply
* Re: [PATCH] git-grep: convert from bash to sh
From: Petr Baudis @ 2005-12-18 14:56 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: Junio C Hamano, git
In-Reply-To: <20051218152639.5c14bc26.tihirvon@gmail.com>
Dear diary, on Sun, Dec 18, 2005 at 02:26:39PM CET, I got a letter
where Timo Hirvonen <tihirvon@gmail.com> said that...
> sh does not support arrays so we have to use eval instead.
>
> Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
This version also makes it work properly with patterns containing quotes
and backslashes (not so unusual when you grep for C strings).
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
I'm kind of sensitive to this stuff. I still passionately hate scp
making me to double-quote remote filenames. It's just evil.
diff --git a/git-grep.sh b/git-grep.sh
index 2ed8e95..7e9e5bf 100755
--- a/git-grep.sh
+++ b/git-grep.sh
@@ -8,21 +8,21 @@ SUBDIRECTORY_OK='Yes'
. git-sh-setup
pattern=
-flags=()
-git_flags=()
+flags=
+git_flags=
while : ; do
case "$1" in
--cached|--deleted|--others|--killed|\
--ignored|--exclude=*|\
--exclude-from=*|\--exclude-per-directory=*)
- git_flags=("${git_flags[@]}" "$1")
+ git_flags="$git_flags '$1'"
;;
-e)
pattern="$2"
shift
;;
-A|-B|-C|-D|-d|-f|-m)
- flags=("${flags[@]}" "$1" "$2")
+ flags="$flags '$1' '$2'"
shift
;;
--)
@@ -31,7 +31,7 @@ while : ; do
break
;;
-*)
- flags=("${flags[@]}" "$1")
+ flags="$flags '$1'"
;;
*)
if [ -z "$pattern" ]; then
@@ -46,5 +46,6 @@ done
[ "$pattern" ] || {
usage
}
-git-ls-files -z "${git_flags[@]}" "$@" |
- xargs -0 grep "${flags[@]}" -e "$pattern"
+pattern="$(echo "$pattern" | sed 's/[\\"]/\\&/g')"
+eval git-ls-files -z "$git_flags" '"$@"' |
+ eval xargs -0 grep "$flags" -e '"$pattern"'
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply related
* Re: [PATCH] cg-completion: improve options and command listing
From: Jonas Fonseca @ 2005-12-18 14:34 UTC (permalink / raw)
To: Ben Clifford; +Cc: Git List, Petr Baudis
In-Reply-To: <EF827EE8-7B7A-4D19-A08D-8C67D6B74195@hawaga.org.uk>
Ben Clifford <benc@hawaga.org.uk> wrote Sun, Dec 18, 2005:
>
> On 12 Dec 2005, at 04:39, Jonas Fonseca wrote:
>
> >Complete help options and improve filtering for command name
> >completion.
> >
> >Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> >
>
> Hi. I've applied this patch to the dev branch cg-compl in my
> gitcompletion repo.
>
> I'm interested by what you mean by 'all sorts of garbage' - it seems
> ok on my machine.
~/src/cogito/cogito > __cg_cmdlist | head
cg-add Add files to the GIT repository.
cg-clean Clean unknown files from the working tree.
cg-clone Clone a remote GIT repository.
cg-commit Commit into a GIT repository.
cg-diff Make a diff between two GIT trees.
cg-export Exports a particular revision from a GIT repository.
cg-fetch Fetch changes from a remote branch to the local GIT repository.
cg-help Show help for Cogito commands.
cg-init Initialize a GIT repository.
cg-log Make a log of changes in a GIT branch.
Else I was thinking of maybe adding --list parameter to cg-help to have
it list all known commands.
--
Jonas Fonseca
^ permalink raw reply
* [PATCH] git-grep: convert from bash to sh
From: Timo Hirvonen @ 2005-12-18 13:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
sh does not support arrays so we have to use eval instead.
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
git-grep.sh | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
11c29a066288c5f05a67ff0d46e9ce17cd7a37da
diff --git a/git-grep.sh b/git-grep.sh
index 2ed8e95..2f0a297 100755
--- a/git-grep.sh
+++ b/git-grep.sh
@@ -8,21 +8,21 @@ SUBDIRECTORY_OK='Yes'
. git-sh-setup
pattern=
-flags=()
-git_flags=()
+flags=
+git_flags=
while : ; do
case "$1" in
--cached|--deleted|--others|--killed|\
--ignored|--exclude=*|\
--exclude-from=*|\--exclude-per-directory=*)
- git_flags=("${git_flags[@]}" "$1")
+ git_flags="$git_flags '$1'"
;;
-e)
pattern="$2"
shift
;;
-A|-B|-C|-D|-d|-f|-m)
- flags=("${flags[@]}" "$1" "$2")
+ flags="$flags '$1' '$2'"
shift
;;
--)
@@ -31,7 +31,7 @@ while : ; do
break
;;
-*)
- flags=("${flags[@]}" "$1")
+ flags="$flags '$1'"
;;
*)
if [ -z "$pattern" ]; then
@@ -46,5 +46,5 @@ done
[ "$pattern" ] || {
usage
}
-git-ls-files -z "${git_flags[@]}" "$@" |
- xargs -0 grep "${flags[@]}" -e "$pattern"
+eval git-ls-files -z "$git_flags" '"$@"' |
+ eval xargs -0 grep "$flags" -e '"$pattern"'
--
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] diff: --abbrev option
From: Petr Baudis @ 2005-12-18 11:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek4byuwg.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Dec 18, 2005 at 03:57:19AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > I was actually thinking to by default trim all the hashes Cogito show
> > to 12 or 16 characters. Seven still seems dangerously low to me, though;
> > it would be nice if the number of characters to trim would be
> > configurable (unless I've missed that).
>
> Well, I did better than you imagined this time, for a change ;-)
> It trims and adds extra as needed without breaking alignments,
> so you could get something like this:
>
> > :100755 100755 0266f46... b0e54ed... M git-branch.sh
> > :100755 100755 f241d4b9.. 36308d2ab. M git-checkout.sh
>
> That is, ... is not just distraction but are part of the
> design. Cut and paste is a byproduct.
Ok, that's nice! :-) And if I'm going to machine-process this later,
I can just trim the trailing dots anyway. And it seems that I can give
--abbrev a number argument to specify the minimal abbreviation, even
cooler! :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: bad git pull
From: Junio C Hamano @ 2005-12-18 7:15 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512172310060.26663@localhost.localdomain>
Nicolas Pitre <nico@cam.org> writes:
>> I do not see much difference either way,
>
> ORIG suggests "origin" to me,...
Hmph.
I always thought it was original-head before the operation
happened, which is why I said it is no different from
previous-head.
^ permalink raw reply
* Re: new file leaked onto release branch
From: Junio C Hamano @ 2005-12-18 7:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Brown, Len, git
In-Reply-To: <Pine.LNX.4.64.0512141150210.3292@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> git-merge does:
>
> common=$(git-merge-base --all $head "$@")
>
> and then it _should_ have triggered this case:
>
> case "$#,$common,$no_commit" in
> ..
> 1,"$1",*)
> # If head can reach all the merge then we are up to date.
> # but first the most common case of merging one remote
> echo "Already up-to-date."
> dropsave
> exit 0
> ;;
> ..
>
> and thus never have created any merge messages.
>...
> Hmm. It really looks like it should have been impossible to generate that
> commit with current git, which is why I'm still a bit suspicious.
Two good news (one puzzle fully explained, one bug fixed) and
one not so good news (one puzzle still remains).
First good news. I solved this puzzle. This has been fixed as
a part of a seemingly independent fix:
commit 9954f5b876abb6118f9bdf1d113239d86acca7bd
Author: Junio C Hamano <junkio@cox.net>
Date: Tue Dec 13 17:01:23 2005 -0800
[PATCH] allow merging any committish
Although "git-merge" is advertised as the end-user level command
(instead of being a "git-pull" backend), it was not prepared to
take tag objects that point at commits and barfed when fed one.
Sanitize the input while we validate them, for which we already
have a loop.
Signed-off-by: Junio C Hamano <junkio@cox.net>
There was a bug in git-merge which used the user input without
converting them to object names. When the part you quoted above
was executed, $1..${$#} were remote ref parameters from the
command line, so in the case of Len's commit, which did:
git merge "Auto-update from upstream" release linus
"$1" at that point was string "linus", not the object name
returned from "git-rev-parse --verify linus". The case pattern
match did not match because $common was object name and $1 was
not. This was fixed by the above commit; the user supplied refs
are already converted into object names at that point with the
current code.
I have never seen this problem myself because git-pull feeds
object names after converting refnames to git-merge, but people
who used the git-merge command themselves could have been
affected by the bug.
So I think I am done with the "this is "already-up-to-date"; why
does that commit exists in the first place?" commit we have
discussed in this thread.
Second good news. I have been working on a theory on the "where
did this file come from?" problem. I found a real bug that can
cause a bad mismerge that can introduce completely unrelated
changes to the tree, but after digging a bit deeper, I do not
think it matches Len's problematic commit. It still is a bug.
If you run the sequence attached at the end in an empty
repository, you will have a repository suitable for this
demonstration. After the script runs, the commit structure
would look like this:
! [heads/7589] add xyzzy
* [master] Merge 7589 branch
! [nitfol] add nitfol
---
+ [8eec60c] add xyzzy <tag 7589>
+ [db5bc99] edit frotz
+ [758916c] add nitfol
+++ [70c4319] initial
There are three branches: master, nitfol, and "7589".
They all start from the initial commit which has one file
"frotz" and each branch adds one commit. Also the tip of 7589
branch is tagged as "7589". Now, we will run this:
$ git merge "Merge 7589 branch" HEAD 7589
With this setup, the current tip of the "master" branch
mismerges and adds "nitfol" file which did not exist in either
branch heads (and it is not fixed with the 9954f5 commit above).
A change I introduced mid November causes get_sha1_basic() to
misinterpret "7589" to be neither the tag 7589 nor branch 7589
tip, but by mistake it does not outright fail, but returns the
758916c commit! This merge ends up pulling nitfol branch head
into master branch, not 7589 branch as the user intended. The
resulting merge commit has db5bc99 and 758916c as its parents.
The "revert misguided disambiguation" patch I posted earlier
fixes this problem. I'll push it out tonight.
This theory however does not seem to match what really happened.
Len did mention that he has "5165" branch (there is a commit
marked "Pull 5165 into release branch" near a problematic
merge), but he did not say he also has a 5165 tag; the bug does
not trigger if you do not have the tag of the same name. Also
if this theory holds true, the problematic commit should have a
commit whose object name begins with 5165 as the second parent
but that is not the case. And the problem happened with a
commit that is not a merge between release/test and topic
branch anyway; it is with an "Auto-update from upstream" commit.
So I am still puzzled by the "where did this file come from"
problem. The most plausible explanation was the driver error
mentioned already in the thread: "update-index --add" in the
middle of merge with manual committing.
----------------------------------------------------------------
#!/bin/sh
GIT_AUTHOR_DATE='1995-01-29T15:00:00 -0800'
GIT_AUTHOR_EMAIL='author@example.com'
GIT_AUTHOR_NAME='A U Thor'
GIT_COMMITTER_DATE='1995-01-29T15:00:00 -0800'
GIT_COMMITTER_EMAIL='committer@example.com'
GIT_COMMITTER_NAME='C O Mmitter'
export GIT_AUTHOR_DATE
export GIT_AUTHOR_EMAIL
export GIT_AUTHOR_NAME
export GIT_COMMITTER_DATE
export GIT_COMMITTER_EMAIL
export GIT_COMMITTER_NAME
git init-db
echo frotz >frotz
git add frotz
git commit -m 'initial'
git checkout -b nitfol
echo nitfol >nitfol
git add nitfol
git commit -m 'add nitfol'
git checkout -b 7589 master
echo xyzzy >xyzzy
git add xyzzy
git commit -m 'add xyzzy'
git tag 7589
git checkout master
echo FROTZ >frotz
git update-index frotz
git commit -m 'edit frotz'
^ permalink raw reply
* Re: bad git pull
From: Linus Torvalds @ 2005-12-18 6:31 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0512172310060.26663@localhost.localdomain>
On Sat, 17 Dec 2005, Nicolas Pitre wrote:
>
> ORIG suggests "origin" to me
It's meant to be short for ORIGinal, not ORIGin. That's how I wrote it and
have always read it ;)
Linus
^ permalink raw reply
* Re: bad git pull
From: Nicolas Pitre @ 2005-12-18 4:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v8xujyuna.fsf@assigned-by-dhcp.cox.net>
On Sat, 17 Dec 2005, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > One observation is that ORIG_HEAD should probably be named PREV_HEAD in
> > such context to make it more obvious what it is about.
>
> I do not see much difference either way,
ORIG suggests "origin" to me, something that was there first, or before
anything else. If you want to undo something, you want its "previous"
state restored relative to the current state, not the absolute previous
(first) one.
> but I suspect ORIG_HEAD
> is pretty much well established by now.
Well, cogito for one doesn't care at all, and it even doesn't make for
it to be created/updated.
But still it can remain for what it is now, and PREV_HEAD added for undo
purpose.
Not a big deal in any case though.
Nicolas
^ permalink raw reply
* Re: [PATCH] Remove misguided branch disambiguation.
From: Junio C Hamano @ 2005-12-18 3:03 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20051218000636.GA20874@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Right. The test 'Ambiguous' in t0000-basic is redundant now, btw
I reverted that in jc/tail branch (part of pu branch) as well.
^ permalink raw reply
* Re: bad git pull
From: Junio C Hamano @ 2005-12-18 3:02 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0512171601430.26663@localhost.localdomain>
Nicolas Pitre <nico@cam.org> writes:
> One observation is that ORIG_HEAD should probably be named PREV_HEAD in
> such context to make it more obvious what it is about.
I do not see much difference either way, but I suspect ORIG_HEAD
is pretty much well established by now.
^ permalink raw reply
* Re: [PATCH] diff: --abbrev option
From: Junio C Hamano @ 2005-12-18 2:57 UTC (permalink / raw)
To: git
In-Reply-To: <20051218001756.GS22159@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I was actually thinking to by default trim all the hashes Cogito show
> to 12 or 16 characters. Seven still seems dangerously low to me, though;
> it would be nice if the number of characters to trim would be
> configurable (unless I've missed that).
Well, I did better than you imagined this time, for a change ;-)
It trims and adds extra as needed without breaking alignments,
so you could get something like this:
> :100755 100755 0266f46... b0e54ed... M git-branch.sh
> :100755 100755 f241d4b9.. 36308d2ab. M git-checkout.sh
That is, ... is not just distraction but are part of the
design. Cut and paste is a byproduct.
^ permalink raw reply
* Re: How to clone-pack the HEAD?
From: Petr Baudis @ 2005-12-18 0:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyouricc.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Dec 15, 2005 at 07:21:23AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Junio C Hamano <junkio@cox.net> writes:
>
> > Also I might want to give --keep option to fetch-pack as well;
> > clone-pack has some static functions that we can extract out to
> > a common file to link to both.
>
> And this is the second installment, on top of the previous one.
> I am a bit reluctant about this one only because of its size,
> but I suspect it may be much easier to use for your purpose.
>
> I'll keep this in the proposed updates branch for now (the other
> one goes to master tonight), so if you like this one, please
> holler, test out and ack.
Well, I like this one, but you don't need to put this to master just for
me, I'm perfectly fine with the git-clone-pack fix - both commands are
now equally simple for me to use in Cogito. (And both seem to work fine
after some basic testing.)
But you are right that git-clone-pack is basically made obsolete by this
patch, and I tend to like that fact - that's why I have slight
preference to this patch anyway, despite its size (and it's mostly
common code being moved around anyway). It's probably too late to remove
git-clone-pack altogether, but you might at least deprecate it and print
a warning when it's being ran (or at least please print a warning when
it's being ran in a repository which is already populated, which is very
likely a driver error, and I've actually made it just a minute ago ;).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] cg-completion: improve options and command listing
From: Ben Clifford @ 2005-12-17 23:25 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Git List, Petr Baudis
In-Reply-To: <20051211190931.GF2960@diku.dk>
On 12 Dec 2005, at 04:39, Jonas Fonseca wrote:
> Complete help options and improve filtering for command name
> completion.
>
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
>
Hi. I've applied this patch to the dev branch cg-compl in my
gitcompletion repo.
I'm interested by what you mean by 'all sorts of garbage' - it seems
ok on my machine.
Ben
> ---
>
> The current filtering causes all sorts of garbage to be listed in the
> command listing.
>
> commit f0535e9952f1cace89d03649e8238aca69a6df44
> tree e05dfadb63bd92ead0dc29d326065b7a797e2109
> parent 3c14cded46e110396127fc5b5e65883eb5cd60b9
> author Jonas Fonseca <fonseca@diku.dk> Wed, 07 Dec 2005 20:58:50 +0100
> committer Jonas Fonseca <fonseca@antimatter.localdomain> Wed, 07
> Dec 2005 20:58:50 +0100
--
Ben • ベン • Бэн • 벤 • 班明
http://www.hawaga.org.uk/ben/
My email is high latency but best way to contact me. Alternatively,
SMS number(s) at above URL.
^ permalink raw reply
* Re: How to clone-pack the HEAD?
From: Petr Baudis @ 2005-12-18 0:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsnzq66x.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Dec 15, 2005 at 06:29:10AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Junio C Hamano <junkio@cox.net> writes:
>
> > Not really. I take this back. What you want to do I did not
> > understand well enough.
> >
> > HEAD is kinda special. A hack I can think of is to do ls-remote
> > first and do the guess clone-pack does for full clone case, and
> > then give a specific branch name to clone. That might work.
>
> ... and another way would be to do this; I'll put this (with
> fixes if there is some needed) in "master" tonight.
Thanks! This makes it work very nicely and exactly the way I want, even
giving git-fetch-pack-compatible output so I can seamlessly switch
between the two commands. Very nice!
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] diff: --abbrev option
From: Petr Baudis @ 2005-12-18 0:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bks12n6.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Dec 17, 2005 at 10:41:49AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> When I show transcripts to explain how something works, I often
> find myself hand-editing the diff-raw output to shorten various
> object names in the output.
>
> This adds --abbrev option to the diff family, which shortens
> diff-raw output and diff-tree commit id headers.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> ---
>
> * Earlier I announced that I have this toy in proposed updates
> without actually showing the code, so here it is. I have
> added code to find unique abbreviation as well. It is
> primarily useful to quote things in e-mail, like this:
>
> $ git-rev-parse master | git-diff-tree --pretty -r --abbrev --stdin
> diff-tree 01385e2... (from 6922471...)
> Author: Junio C Hamano <junkio@cox.net>
> Date: Fri Dec 16 23:12:33 2005 -0800
>
> Comment fixes.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> :100755 100755 0266f46... b0e54ed... M git-branch.sh
> :100755 100755 f241d4b... 36308d2... M git-checkout.sh
I think the '...' is just distracting. It makes cut'n'paste more
difficult, and it's usually fairly obvious that this is start of a hash,
and that the hash might not be complete.
I was actually thinking to by default trim all the hashes Cogito show
to 12 or 16 characters. Seven still seems dangerously low to me, though;
it would be nice if the number of characters to trim would be
configurable (unless I've missed that).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] Remove misguided branch disambiguation.
From: Alex Riesen @ 2005-12-18 0:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virto12u5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Sat, Dec 17, 2005 10:37:38 +0100:
> This removes the misguided attempt to refuse processing a branch
> name xyzzy and insist it to be given as either heads/xyzzy or
> tags/xyzzy when a tag xyzzy exists. There was no reason to do
> so --- the search order was predictable and well defined, so if
> the user says xyzzy we should have taken the tag xyzzy in such a
> case without complaining.
Right. The test 'Ambiguous' in t0000-basic is redundant now, btw
^ permalink raw reply
* Re: bad git pull
From: Nicolas Pitre @ 2005-12-17 21:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v4q582htm.fsf@assigned-by-dhcp.cox.net>
On Sat, 17 Dec 2005, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > That said, I think a lot of newbies might want to have a "git undo", and
> > not because of any BK history. Even if it just ends up being nothing but
> > shorthand for "git reset --hard ORIG_HEAD".
>
> I agree to this in principle, but I am afraid "git undo" is too
> generic and fuzzy a term. Things you might possibly want to
> undo depends on what you did last [*1*]. In most undoable
> cases, "reset --hard" is almost right but most likely would
> result in information loss.
One observation is that ORIG_HEAD should probably be named PREV_HEAD in
such context to make it more obvious what it is about.
Nicolas
^ permalink raw reply
* [PATCH] diff: --abbrev option
From: Junio C Hamano @ 2005-12-17 9:41 UTC (permalink / raw)
To: git
When I show transcripts to explain how something works, I often
find myself hand-editing the diff-raw output to shorten various
object names in the output.
This adds --abbrev option to the diff family, which shortens
diff-raw output and diff-tree commit id headers.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Earlier I announced that I have this toy in proposed updates
without actually showing the code, so here it is. I have
added code to find unique abbreviation as well. It is
primarily useful to quote things in e-mail, like this:
$ git-rev-parse master | git-diff-tree --pretty -r --abbrev --stdin
diff-tree 01385e2... (from 6922471...)
Author: Junio C Hamano <junkio@cox.net>
Date: Fri Dec 16 23:12:33 2005 -0800
Comment fixes.
Signed-off-by: Junio C Hamano <junkio@cox.net>
:100755 100755 0266f46... b0e54ed... M git-branch.sh
:100755 100755 f241d4b... 36308d2... M git-checkout.sh
Documentation/diff-options.txt | 7 +++++
diff-tree.c | 40 +++++++++++++++++-----------
diff.c | 57 ++++++++++++++++++++++++++++++++++++----
diff.h | 9 ++++++
sha1_name.c | 3 ++
5 files changed, 93 insertions(+), 23 deletions(-)
ea2d93b12d2deae007311d0898616b4bb2f299d2
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 6b496ed..3d1175e 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -18,6 +18,13 @@
object name of pre- and post-image blob on the "index"
line when generating a patch format output.
+--abbrev::
+ Instead of showing the full 40-byte hexadecimal object
+ name in diff-raw format output and diff-tree header
+ lines, show only handful prefix. This is independent of
+ --full-index option above, which controls the diff-patch
+ output format.
+
-B::
Break complete rewrite changes into pairs of delete and create.
diff --git a/diff-tree.c b/diff-tree.c
index d56d921..efa2b94 100644
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -14,11 +14,6 @@ static enum cmit_fmt commit_format = CMI
static struct diff_options diff_options;
-static void call_diff_setup_done(void)
-{
- diff_setup_done(&diff_options);
-}
-
static int call_diff_flush(void)
{
diffcore_std(&diff_options);
@@ -43,7 +38,6 @@ static int diff_tree_sha1_top(const unsi
{
int ret;
- call_diff_setup_done();
ret = diff_tree_sha1(old, new, base, &diff_options);
call_diff_flush();
return ret;
@@ -55,7 +49,6 @@ static int diff_root_tree(const unsigned
void *tree;
struct tree_desc empty, real;
- call_diff_setup_done();
tree = read_object_with_reference(new, "tree", &real.size, NULL);
if (!tree)
die("unable to read root tree (%s)", sha1_to_hex(new));
@@ -69,18 +62,29 @@ static int diff_root_tree(const unsigned
return retval;
}
-static const char *generate_header(const char *commit, const char *parent, const char *msg)
+static const char *generate_header(const unsigned char *commit_sha1,
+ const unsigned char *parent_sha1,
+ const char *msg)
{
static char this_header[16384];
int offset;
unsigned long len;
+ int abbrev = diff_options.abbrev;
if (!verbose_header)
- return commit;
+ return sha1_to_hex(commit_sha1);
len = strlen(msg);
- offset = sprintf(this_header, "%s%s (from %s)\n", header_prefix, commit, parent);
- offset += pretty_print_commit(commit_format, msg, len, this_header + offset, sizeof(this_header) - offset);
+
+ offset = sprintf(this_header, "%s%s ",
+ header_prefix,
+ diff_unique_abbrev(commit_sha1, abbrev));
+ offset += sprintf(this_header + offset, "(from %s)\n",
+ parent_sha1 ?
+ diff_unique_abbrev(parent_sha1, abbrev) : "root");
+ offset += pretty_print_commit(commit_format, msg, len,
+ this_header + offset,
+ sizeof(this_header) - offset);
return this_header;
}
@@ -99,18 +103,18 @@ static int diff_tree_commit(const unsign
/* Root commit? */
if (show_root_diff && !commit->parents) {
- header = generate_header(name, "root", commit->buffer);
+ header = generate_header(sha1, NULL, commit->buffer);
diff_root_tree(commit_sha1, "");
}
/* More than one parent? */
if (ignore_merges && commit->parents && commit->parents->next)
- return 0;
+ return 0;
for (parents = commit->parents; parents; parents = parents->next) {
struct commit *parent = parents->item;
- header = generate_header(name,
- sha1_to_hex(parent->object.sha1),
+ header = generate_header(sha1,
+ parent->object.sha1,
commit->buffer);
diff_tree_sha1_top(parent->object.sha1, commit_sha1, "");
if (!header && verbose_header) {
@@ -129,6 +133,7 @@ static int diff_tree_stdin(char *line)
int len = strlen(line);
unsigned char commit[20], parent[20];
static char this_header[1000];
+ int abbrev = diff_options.abbrev;
if (!len || line[len-1] != '\n')
return -1;
@@ -138,7 +143,9 @@ static int diff_tree_stdin(char *line)
if (isspace(line[40]) && !get_sha1_hex(line+41, parent)) {
line[40] = 0;
line[81] = 0;
- sprintf(this_header, "%s (from %s)\n", line, line+41);
+ sprintf(this_header, "%s (from %s)\n",
+ diff_unique_abbrev(commit, abbrev),
+ diff_unique_abbrev(parent, abbrev));
header = this_header;
return diff_tree_sha1_top(parent, commit, "");
}
@@ -239,6 +246,7 @@ int main(int argc, const char **argv)
diff_options.recursive = 1;
diff_tree_setup_paths(get_pathspec(prefix, argv));
+ diff_setup_done(&diff_options);
switch (nr_sha1) {
case 0:
diff --git a/diff.c b/diff.c
index 2e0797b..c815918 100644
--- a/diff.c
+++ b/diff.c
@@ -723,11 +723,13 @@ static void run_diff(struct diff_filepai
if (memcmp(one->sha1, two->sha1, 20)) {
char one_sha1[41];
- const char *index_fmt = o->full_index ? "index %s..%s" : "index %.7s..%.7s";
+ int abbrev = o->full_index ? 40 : DIFF_DEFAULT_INDEX_ABBREV;
memcpy(one_sha1, sha1_to_hex(one->sha1), 41);
len += snprintf(msg + len, sizeof(msg) - len,
- index_fmt, one_sha1, sha1_to_hex(two->sha1));
+ "index %.*s..%.*s",
+ abbrev, one_sha1, abbrev,
+ sha1_to_hex(two->sha1));
if (one->mode == two->mode)
len += snprintf(msg + len, sizeof(msg) - len,
" %06o", one->mode);
@@ -791,6 +793,8 @@ int diff_setup_done(struct diff_options
}
if (options->setup & DIFF_SETUP_USE_SIZE_CACHE)
use_size_cache = 1;
+ if (options->abbrev <= 0 || 40 < options->abbrev)
+ options->abbrev = 40; /* full */
return 0;
}
@@ -841,6 +845,10 @@ int diff_opt_parse(struct diff_options *
}
else if (!strcmp(arg, "--find-copies-harder"))
options->find_copies_harder = 1;
+ else if (!strcmp(arg, "--abbrev"))
+ options->abbrev = DIFF_DEFAULT_ABBREV;
+ else if (!strncmp(arg, "--abbrev=", 9))
+ options->abbrev = strtoul(arg + 9, NULL, 10);
else
return 0;
return 1;
@@ -947,14 +955,49 @@ void diff_free_filepair(struct diff_file
free(p);
}
+/* This is different from find_unique_abbrev() in that
+ * it needs to deal with 0{40} SHA1.
+ */
+const char *diff_unique_abbrev(const unsigned char *sha1, int len)
+{
+ int abblen;
+ const char *abbrev;
+ if (len == 40)
+ return sha1_to_hex(sha1);
+
+ abbrev = find_unique_abbrev(sha1, len);
+ if (!abbrev) {
+ if (!memcmp(sha1, null_sha1, 20)) {
+ char *buf = sha1_to_hex(null_sha1);
+ if (len < 37)
+ strcpy(buf + len, "...");
+ return buf;
+ }
+ else
+ return sha1_to_hex(sha1);
+ }
+ abblen = strlen(abbrev);
+ if (abblen < 37) {
+ static char hex[41];
+ if (len < abblen && abblen <= len + 2)
+ sprintf(hex, "%s%.*s", abbrev, len+3-abblen, "..");
+ else
+ sprintf(hex, "%s...", abbrev);
+ return hex;
+ }
+ return sha1_to_hex(sha1);
+}
+
static void diff_flush_raw(struct diff_filepair *p,
int line_termination,
int inter_name_termination,
- int output_format)
+ struct diff_options *options)
{
int two_paths;
char status[10];
+ int abbrev = options->abbrev;
const char *path_one, *path_two;
+ int output_format = options->output_format;
path_one = p->one->path;
path_two = p->two->path;
@@ -985,8 +1028,10 @@ static void diff_flush_raw(struct diff_f
}
if (output_format != DIFF_FORMAT_NAME_STATUS) {
printf(":%06o %06o %s ",
- p->one->mode, p->two->mode, sha1_to_hex(p->one->sha1));
- printf("%s ", sha1_to_hex(p->two->sha1));
+ p->one->mode, p->two->mode,
+ diff_unique_abbrev(p->one->sha1, abbrev));
+ printf("%s ",
+ diff_unique_abbrev(p->two->sha1, abbrev));
}
printf("%s%c%s", status, inter_name_termination, path_one);
if (two_paths)
@@ -1194,7 +1239,7 @@ void diff_flush(struct diff_options *opt
case DIFF_FORMAT_NAME_STATUS:
diff_flush_raw(p, line_termination,
inter_name_termination,
- diff_output_format);
+ options);
break;
case DIFF_FORMAT_NAME:
diff_flush_name(p,
diff --git a/diff.h b/diff.h
index 32b4780..c3486ff 100644
--- a/diff.h
+++ b/diff.h
@@ -44,6 +44,7 @@ struct diff_options {
int reverse_diff;
int rename_limit;
int setup;
+ int abbrev;
change_fn_t change;
add_remove_fn_t add_remove;
@@ -87,6 +88,9 @@ extern int diff_setup_done(struct diff_o
#define DIFF_PICKAXE_ALL 1
+#define DIFF_DEFAULT_INDEX_ABBREV 7 /* hex digits */
+#define DIFF_DEFAULT_ABBREV 7 /* hex digits */
+
extern void diffcore_std(struct diff_options *);
extern void diffcore_std_no_resolve(struct diff_options *);
@@ -98,7 +102,8 @@ extern void diffcore_std_no_resolve(stru
" -u synonym for -p.\n" \
" --name-only show only names of changed files.\n" \
" --name-status show names and status of changed files.\n" \
-" --full-index show full object name on index ines.\n" \
+" --full-index show full object name on index lines.\n" \
+" --abbrev abbreviate object names in diff-tree header and diff-raw.\n" \
" -R swap input file pairs.\n" \
" -B detect complete rewrites.\n" \
" -M detect renames.\n" \
@@ -137,4 +142,6 @@ extern void diff_flush(struct diff_optio
#define DIFF_STATUS_FILTER_AON '*'
#define DIFF_STATUS_FILTER_BROKEN 'B'
+extern const char *diff_unique_abbrev(const unsigned char *, int);
+
#endif /* DIFF_H */
diff --git a/sha1_name.c b/sha1_name.c
index bf8f0f0..875e2f8 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -188,7 +188,10 @@ const char *find_unique_abbrev(const uns
{
int status;
static char hex[41];
+
memcpy(hex, sha1_to_hex(sha1), 40);
+ if (len == 40)
+ return hex;
while (len < 40) {
unsigned char sha1_ret[20];
status = get_short_sha1(hex, len, sha1_ret, 1);
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH] Remove misguided branch disambiguation.
From: Junio C Hamano @ 2005-12-17 9:37 UTC (permalink / raw)
To: git
This removes the misguided attempt to refuse processing a branch
name xyzzy and insist it to be given as either heads/xyzzy or
tags/xyzzy when a tag xyzzy exists. There was no reason to do
so --- the search order was predictable and well defined, so if
the user says xyzzy we should have taken the tag xyzzy in such a
case without complaining.
This incidentally fixes another subtle bug related to this. If
such a duplicate branch/tag name happened to be a unique valid
prefix of an existing commit object name (say, "beef"), we did
not take the tag "beef" but after complaining used the commit
object whose name started with beef.
Another problem this fixes while introducing some confusion is
that there is no longer a reason to forbid a branch name HEAD
anymore. In other words, now "git pull . ref1:HEAD" would work
as expected, once we revert "We do not like HEAD branch" patch.
It creates "HEAD" branch under ${GIT_DIR-.git}/refs/heads (or
fast-forwards if already exists) using the tip of ref1 branch
from the current repository, and merges it into the current
branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
sha1_name.c | 33 +++------------------------------
1 files changed, 3 insertions(+), 30 deletions(-)
a012e1b2b5218729e148befd0705bd52962ac272
diff --git a/sha1_name.c b/sha1_name.c
index bf8f0f0..49e2cc3 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -238,7 +238,6 @@ static int get_sha1_basic(const char *st
NULL
};
const char **p;
- int found = 0;
if (len == 40 && !get_sha1_hex(str, sha1))
return 0;
@@ -249,36 +248,10 @@ static int get_sha1_basic(const char *st
for (p = prefix; *p; p++) {
char *pathname = git_path("%s/%.*s", *p, len, str);
-
- if (!read_ref(pathname, sha1)) {
- /* Must be unique; i.e. when heads/foo and
- * tags/foo are both present, reject "foo".
- */
- if (1 < found++)
- return -1;
- }
-
- /* We want to allow .git/description file and
- * "description" branch to exist at the same time.
- * "git-rev-parse description" should silently skip
- * .git/description file as a candidate for
- * get_sha1(). However, having garbage file anywhere
- * under refs/ is not OK, and we would not have caught
- * ambiguous heads and tags with the above test.
- */
- else if (**p && !access(pathname, F_OK)) {
- /* Garbage exists under .git/refs */
- return error("garbage ref found '%s'", pathname);
- }
- }
- switch (found) {
- case 0:
- return -1;
- case 1:
- return 0;
- default:
- return error("ambiguous refname '%.*s'", len, str);
+ if (!read_ref(pathname, sha1))
+ return 0;
}
+ return -1;
}
static int get_sha1_1(const char *name, int len, unsigned char *sha1);
--
0.99.9.GIT
^ permalink raw reply related
* What's in git.git tonight
From: Junio C Hamano @ 2005-12-17 9:37 UTC (permalink / raw)
To: git
Since 0.99.9n, there have been a couple of fixes and some
documentation updates. One notable is that we do not allow '?',
'*' and '[' in ref names anymore --- this was done after the
list discussion with Pasky and friends.
Another notable is "We do not like HEAD branch" patch, but I've
been thinking seriously about reverting it and replace its
effect by also reverting the misguided attempt to disambiguate
branch names and tag names. This patch with a commit message
will follow in a separate message; it currently lives in the
proposed updates branch. One positive effect this change brings
is that it fixes a corner case bug/confusion Johannes mentioned
the other day while diagnosing the trouble Len had with his
repository (I do not think the problem has anything to do with
Len's trouble, though). If you have a branch called "dead", and
you also have a tag called "dead", and if your repository has
only one object whose name begins with "dead"
(e.g. "deadbeef1234..."), "git rev-parse --verify dead" would
pick up the "deadbeef1234..." object, not "dead" tag nor "dead"
head. When no such object exists, "git rev-parse --verify dead"
fails, saying "dead" is ambiguous between heads and tags. This
is just confused, and "reverting the misguided disambiguation"
change will make it pick up the "dead" tag in either case. Most
likely I'll have it in "master" after further testing over the
weekend.
One important patch waiting in the proposed updates is to give
an option to git-fetch-pack to keep the downloaded pack without
unpacking it; this was primarily done to help Cogito, but I
haven't heard back about it from Pasky yet. The primary
difference between this and the clone-pack change that is
already in the master branch, from the user's point of view, is
that git-fetch-pack can be efficiently used in an already
populated repository [*1*]. Imagine cloning "master" branch
from linux-2.6 repository of Linus, and then fetching ALL branch
from libata-dev repository of Jeff --- the difference is large
enough that you would want to keep the downloaded stuff packed,
while you do want to take advantage of the fact that you already
have objects from Linus. Currently it saves exploding about a
~800K pack with 1100 objects in it. Although I mentioned we are
supposed to be in deep feature freeze, I feel it is worth to
have this one in 1.0.
[Footnote]
*1* Theoretically we could deprecate git-clone-pack and use
git-fetch-pack exclusively, if we are willing to create refs
matching what the remote has in the wrapper script git-clone.
^ 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