* [REPLACEMENT PATCH] Highlight keyboard shortcuts in git-add--interactive
From: Wincent Colaiuta @ 2007-12-01 14:29 UTC (permalink / raw)
To: git; +Cc: gitster, dzwell, peff, Matthieu.Moy, Wincent Colaiuta
In-Reply-To: <697AB37F-784D-4374-A290-0E6290712B29@wincent.com>
The user interface provided by the command loop in git-add--interactive
gives the impression that subcommands can only be launched by entering
an integer identifier from 1 through 8.
A "hidden" feature is that any string can be entered, and an anchored
regex search is used to find the uniquely matching option.
This patch makes this feature a little more obvious by highlighting the
first character of each subcommand (for example "patch" is displayed as
"[p]atch").
A new function is added to detect the shortest unique prefix and this
is used to decide what to highlight. Highlighting is also applied when
choosing files.
In the case where the common prefix may be unreasonably large
highlighting is omitted; in this patch the soft limit (above which the
highlighting will be omitted for a particular item) is 0 (in other words,
there is no soft limit) and the hard limit (above which highlighting will
be omitted for all items) is 3, but this can be tweaked.
The actual highlighting is done by the highlight_prefix function, which
will enable us to implement ANSI color code-based highlighting (most
likely using underline or boldface) in the future.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
I will go now and crawl under a rock.
git-add--interactive.perl | 110 ++++++++++++++++++++++++++++++++++++++++----
1 files changed, 100 insertions(+), 10 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index fb1e92a..0e358b5 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -44,7 +44,6 @@ my $status_fmt = '%12s %12s %s';
my $status_head = sprintf($status_fmt, 'staged', 'unstaged', 'path');
# Returns list of hashes, contents of each of which are:
-# PRINT: print message
# VALUE: pathname
# BINARY: is a binary path
# INDEX: is index different from HEAD?
@@ -122,8 +121,6 @@ sub list_modified {
}
push @return, +{
VALUE => $_,
- PRINT => (sprintf $status_fmt,
- $it->{INDEX}, $it->{FILE}, $_),
%$it,
};
}
@@ -159,10 +156,95 @@ sub find_unique {
return $found;
}
+# inserts string into trie and updates count for each character
+sub update_trie {
+ my ($trie, $string) = @_;
+ foreach (split //, $string) {
+ $trie = $trie->{$_} ||= {COUNT => 0};
+ $trie->{COUNT}++;
+ }
+}
+
+# returns an array of tuples (prefix, remainder)
+sub find_unique_prefixes {
+ my @stuff = @_;
+ my @return = ();
+
+ # any single prefix exceeding the soft limit is omitted
+ # if any prefix exceeds the hard limit all are omitted
+ # 0 indicates no limit
+ my $soft_limit = 0;
+ my $hard_limit = 3;
+
+ # build a trie modelling all possible options
+ my %trie;
+ foreach my $print (@stuff) {
+ if ((ref $print) eq 'ARRAY') {
+ $print = $print->[0];
+ }
+ elsif ((ref $print) eq 'HASH') {
+ $print = $print->{VALUE};
+ }
+ update_trie(\%trie, $print);
+ push @return, $print;
+ }
+
+ # use the trie to find the unique prefixes
+ for (my $i = 0; $i < @return; $i++) {
+ my $ret = $return[$i];
+ my @letters = split //, $ret;
+ my %search = %trie;
+ my ($prefix, $remainder);
+ my $j;
+ for ($j = 0; $j < @letters; $j++) {
+ my $letter = $letters[$j];
+ if ($search{$letter}{COUNT} == 1) {
+ $prefix = substr $ret, 0, $j + 1;
+ $remainder = substr $ret, $j + 1;
+ last;
+ }
+ else {
+ my $prefix = substr $ret, 0, $j;
+ return ()
+ if ($hard_limit && $j + 1 > $hard_limit);
+ }
+ %search = %{$search{$letter}};
+ }
+ if ($soft_limit && $j + 1 > $soft_limit) {
+ $prefix = undef;
+ $remainder = $ret;
+ }
+ $return[$i] = [$prefix, $remainder];
+ }
+ return @return;
+}
+
+# filters out prefixes which have special meaning to list_and_choose()
+sub is_valid_prefix {
+ my $prefix = shift;
+ return (defined $prefix) &&
+ !($prefix =~ /[\s,]/) && # separators
+ !($prefix =~ /^-/) && # deselection
+ !($prefix =~ /^\d+/) && # selection
+ ($prefix ne '*'); # "all" wildcard
+}
+
+# given a prefix/remainder tuple return a string with the prefix highlighted
+# for now use square brackets; later might use ANSI colors (underline, bold)
+sub highlight_prefix {
+ my $prefix = shift;
+ my $remainder = shift;
+ return $remainder unless defined $prefix;
+ return is_valid_prefix($prefix) ?
+ "[$prefix]$remainder" :
+ "$prefix$remainder";
+}
+
sub list_and_choose {
my ($opts, @stuff) = @_;
my (@chosen, @return);
my $i;
+ my @prefixes = find_unique_prefixes(@stuff) unless $opts->{LIST_ONLY};
TOPLOOP:
while (1) {
@@ -177,13 +259,21 @@ sub list_and_choose {
for ($i = 0; $i < @stuff; $i++) {
my $chosen = $chosen[$i] ? '*' : ' ';
my $print = $stuff[$i];
- if (ref $print) {
- if ((ref $print) eq 'ARRAY') {
- $print = $print->[0];
- }
- else {
- $print = $print->{PRINT};
- }
+ my $ref = ref $print;
+ my $highlighted = highlight_prefix(@{$prefixes[$i]})
+ if @prefixes;
+ if ($ref eq 'ARRAY') {
+ $print = $highlighted || $print->[0];
+ }
+ elsif ($ref eq 'HASH') {
+ my $value = $highlighted || $print->{VALUE};
+ $print = sprintf($status_fmt,
+ $print->{INDEX},
+ $print->{FILE},
+ $value);
+ }
+ else {
+ $print = $highlighted || $print;
}
printf("%s%2d: %s", $chosen, $i+1, $print);
if (($opts->{LIST_FLAT}) &&
--
1.5.3.6.953.gdffc
^ permalink raw reply related
* repo.or.cz problem with blame/history/raw links
From: Peter Oberndorfer @ 2007-12-01 16:04 UTC (permalink / raw)
To: Petr Baudis, git
Hi,
blame/history/raw links seems to be broken on repo.or.cz [1]
They have ARRAY(0x85bfb90) instead of the project name/path in the link
so the broken link looks like:
http://repo.or.cz/w/ARRAY(0x85bfb90)?a=blob_plain...
According to Jakub Narebski this does not happen on unmodified gitweb.
Since i have little to no idea about gitweb maybe somebody else can have a
look at it?
Greetings
Peter
[1]
for a example, follow the raw link on this page
http://repo.or.cz/w/stgit/kha.git?a=blob;f=stgit/commands/coalesce.py;h=e3e1629039e552dd8f1bd90cc3166c62a91adc5e;hb=c0a2dcbec69115469634c575dd3f281f08401ecf
^ permalink raw reply
* [PATCH] xdiff-interface.c (buffer_is_binary): Remove buffer size limitation
From: Dmitry V. Levin @ 2007-12-01 16:01 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
When checking buffer for NUL byte, do not limit size of buffer we check.
Otherwise we break git-rebase: git-format-patch may generate output which
git-mailinfo cannot handle properly.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
---
t/t3407-rebase-binary.sh | 32 ++++++++++++++++++++++++++++++++
xdiff-interface.c | 3 ---
2 files changed, 32 insertions(+), 3 deletions(-)
create mode 100755 t/t3407-rebase-binary.sh
diff --git a/t/t3407-rebase-binary.sh b/t/t3407-rebase-binary.sh
new file mode 100755
index 0000000..213dc9d
--- /dev/null
+++ b/t/t3407-rebase-binary.sh
@@ -0,0 +1,32 @@
+#!/bin/sh
+
+test_description='rebase binary test'
+
+. ./test-lib.sh
+
+yes 1234567 |head -n 2003 >text
+yes 1234567 |head -n 2000 >bin && printf 'binary\0bin\n' >>bin && yes 1234567 |head -n 3 >>bin
+
+test_expect_success setup '
+
+ cat text >file &&
+ git add file &&
+ git commit -m"text" &&
+
+ git branch bin &&
+
+ echo side >side &&
+ git add side &&
+ git commit -m"side" &&
+
+ git checkout bin &&
+ cat bin >file &&
+ git commit -a -m"bin"
+'
+
+test_expect_success rebase '
+
+ git rebase master
+'
+
+test_done
diff --git a/xdiff-interface.c b/xdiff-interface.c
index be866d1..fa9f58d 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -122,11 +122,8 @@ int read_mmfile(mmfile_t *ptr, const char *filename)
return 0;
}
-#define FIRST_FEW_BYTES 8000
int buffer_is_binary(const char *ptr, unsigned long size)
{
- if (FIRST_FEW_BYTES < size)
- size = FIRST_FEW_BYTES;
return !!memchr(ptr, 0, size);
}
--
ldv
^ permalink raw reply related
* [PATCH] install-sh from automake does not like -m without delimiting space
From: Robert Schiele @ 2007-12-01 17:05 UTC (permalink / raw)
To: git; +Cc: gitster
The install-sh script as shipped with automake requires a space between
the -m switch and its argument. Since this is also the regular way of
doing it with other install implementations this change inserts the
missing space in all makefiles.
Signed-off-by: Robert Schiele <rschiele@gmail.com>
---
Documentation/Makefile | 16 ++++++++--------
Makefile | 4 ++--
git-gui/Makefile | 12 ++++++------
templates/Makefile | 2 +-
4 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index d886641..2de4b8b 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -79,16 +79,16 @@ man7: $(DOC_MAN7)
info: git.info
install: man
- $(INSTALL) -d -m755 $(DESTDIR)$(man1dir)
- $(INSTALL) -d -m755 $(DESTDIR)$(man5dir)
- $(INSTALL) -d -m755 $(DESTDIR)$(man7dir)
- $(INSTALL) -m644 $(DOC_MAN1) $(DESTDIR)$(man1dir)
- $(INSTALL) -m644 $(DOC_MAN5) $(DESTDIR)$(man5dir)
- $(INSTALL) -m644 $(DOC_MAN7) $(DESTDIR)$(man7dir)
+ $(INSTALL) -d -m 755 $(DESTDIR)$(man1dir)
+ $(INSTALL) -d -m 755 $(DESTDIR)$(man5dir)
+ $(INSTALL) -d -m 755 $(DESTDIR)$(man7dir)
+ $(INSTALL) -m 644 $(DOC_MAN1) $(DESTDIR)$(man1dir)
+ $(INSTALL) -m 644 $(DOC_MAN5) $(DESTDIR)$(man5dir)
+ $(INSTALL) -m 644 $(DOC_MAN7) $(DESTDIR)$(man7dir)
install-info: info
- $(INSTALL) -d -m755 $(DESTDIR)$(infodir)
- $(INSTALL) -m644 git.info $(DESTDIR)$(infodir)
+ $(INSTALL) -d -m 755 $(DESTDIR)$(infodir)
+ $(INSTALL) -m 644 git.info $(DESTDIR)$(infodir)
if test -r $(DESTDIR)$(infodir)/dir; then \
$(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) git.info ;\
else \
diff --git a/Makefile b/Makefile
index e869b85..7d23aec 100644
--- a/Makefile
+++ b/Makefile
@@ -1024,8 +1024,8 @@ remove-dashes:
### Installation rules
install: all
- $(INSTALL) -d -m755 '$(DESTDIR_SQ)$(bindir_SQ)'
- $(INSTALL) -d -m755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
+ $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
+ $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
$(INSTALL) git$X '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
diff --git a/git-gui/Makefile b/git-gui/Makefile
index e860319..4f8b7c8 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -43,11 +43,11 @@ endif
RM_RF ?= rm -rf
RMDIR ?= rmdir
-INSTALL_D0 = $(INSTALL) -d -m755 # space is required here
+INSTALL_D0 = $(INSTALL) -d -m 755 # space is required here
INSTALL_D1 =
-INSTALL_R0 = $(INSTALL) -m644 # space is required here
+INSTALL_R0 = $(INSTALL) -m 644 # space is required here
INSTALL_R1 =
-INSTALL_X0 = $(INSTALL) -m755 # space is required here
+INSTALL_X0 = $(INSTALL) -m 755 # space is required here
INSTALL_X1 =
INSTALL_A0 = find # space is required here
INSTALL_A1 = | cpio -pud
@@ -71,11 +71,11 @@ ifndef V
QUIET_2DEVNULL = 2>/dev/null
INSTALL_D0 = dir=
- INSTALL_D1 = && echo ' ' DEST $$dir && $(INSTALL) -d -m755 "$$dir"
+ INSTALL_D1 = && echo ' ' DEST $$dir && $(INSTALL) -d -m 755 "$$dir"
INSTALL_R0 = src=
- INSTALL_R1 = && echo ' ' INSTALL 644 `basename $$src` && $(INSTALL) -m644 $$src
+ INSTALL_R1 = && echo ' ' INSTALL 644 `basename $$src` && $(INSTALL) -m 644 $$src
INSTALL_X0 = src=
- INSTALL_X1 = && echo ' ' INSTALL 755 `basename $$src` && $(INSTALL) -m755 $$src
+ INSTALL_X1 = && echo ' ' INSTALL 755 `basename $$src` && $(INSTALL) -m 755 $$src
INSTALL_A0 = src=
INSTALL_A1 = && echo ' ' INSTALL ' ' `basename "$$src"` && find "$$src" | cpio -pud
diff --git a/templates/Makefile b/templates/Makefile
index 6f4dbd3..ebd3a62 100644
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -46,6 +46,6 @@ clean:
$(RM) -r blt boilerplates.made
install: all
- $(INSTALL) -d -m755 '$(DESTDIR_SQ)$(template_dir_SQ)'
+ $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_dir_SQ)'
(cd blt && $(TAR) cf - .) | \
(cd '$(DESTDIR_SQ)$(template_dir_SQ)' && $(TAR) xf -)
--
1.5.2.4
^ permalink raw reply related
* Re: Some git performance measurements..
From: Linus Torvalds @ 2007-12-01 17:19 UTC (permalink / raw)
To: Joachim B Haga; +Cc: git
In-Reply-To: <85abou8x5n.fsf@lupus.ig3.net>
On Sat, 1 Dec 2007, Joachim B Haga wrote:
>
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> > The pack-files (both index and data) are accessed somewhat randomly, but
> > there is still enough locality that doing read-ahead and clustering really
> > does help.
>
> They are dense enough that slurping them in whole is 20% faster, at
> least here. And much less noisy! These are both cache-cold tests.
With BK, I used to have a "readahead" script to something close to this.
The problem with that approach is that it works wonderfully well for
people who (a) have tons of memory and (b) really only care about the
source tree and almost nothing else, but it doesn't work that well at all
for others.
So yes, for me, forcing a page-in of all the data is actually worth it. I
commonly do something like
git grep quieuiueriueirue &
on my main machine when I reboot it for testing - just to bring in the
working tree into cache, so that subsequent "git diff" and "git grep"
operations will be faster.
> $ time git read-tree -m -u HEAD HEAD
>
> real 0m9.255s
> user 0m0.832s
> sys 0m0.196s
>
> $ time (cat .git/objects/pack/* .git/index >/dev/null; git read-tree -m -u HEAD HEAD)
>
> real 0m7.141s
> user 0m0.936s
> sys 0m1.912s
>
> Now, I don't know how useful this is since git doesn't know if the
> data are cached. Is it perhaps possible to give a hint to the
> readahead logic that it should try to read as far as possible?
You have a much faster disk drive than I do on that slow laptop that I
wanted to optimize for.
I get
[torvalds@hp linux]$ time git read-tree -m -u HEAD HEAD
real 0m12.849s
user 0m0.232s
sys 0m0.124s
for the cold-cache case, but then for populating the whole thing:
time cat .git/objects/pack/* .git/index >/dev/null
real 0m31.350s
user 0m0.040s
sys 0m0.468s
whoops. Can you say "pitiful"?
(In contrast, my desktop does the same it in seven seconds - laptop disks
really are *much* slower than a reasonable desktop one).
Linus
^ permalink raw reply
* Re: git pack-objects input list
From: Linus Torvalds @ 2007-12-01 17:49 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20071201104502.GA1457@glandium.org>
On Sat, 1 Dec 2007, Mike Hommey wrote:
>
> While playing around with git-pack-objects, it seemed to me that the
> input it can take is not a simple list of object SHA1s.
Well, it *can* take a simple list of object SHA1's. But yes, the preferred
format is a list of "SHA1 <basename>", where the basename is used as part
of the heuristics on what other objects to try doing a delta against.
But if you give no basename, that heuristic just won't have the name hint,
and things will still *work*, it's just more likely (but not certain) that
the resulting packfile will be larger.
> Could someone knowing the delta calculation internals enlighten me ?
The delta calculations simply create a small hash based on the basename,
and use that to clump blobs/trees with the same basename together. That's
*usually* a huge win in terms of finding good deltas, since the most
likely delta is for a previous version of the same file (or tree!) and
since we don't try to find deltas against *all* other blobs, but just use
a sliding window, having good delta candidates close to each other is
going to help a lot.
Without the basename information, the delta list will just be sorted by
type and size, which works fine, but generally finds fewer deltas.
But it's all a heuristic, and if can go both ways. If you have lots of
renames (which aren't just cross-directory ones, but actually change the
basename), then the basename information may actually hurt.
(Btw: the hash we generate is on purpose not a very good one. It actually
thinks that the last characters are "more important", so it tends to hash
files that end in the same few characters together. So *.c files clump
together etc. At least that's the intent).
See builtin-pack-objects.c:
- type_size_sort(): this is the rule for sortign objects for deltaing.
Type is most important (ie we always sort commits, trees, blobs
separately and clump them together and effectively delta them only
against objects of the same type)
Then comes the basename hash (so that we sort objects with the same
name together, and *.c files closer to each other than to *.h files,
for example).
Then comes the preferred_base (so that we sort things that already have
specific delta bases together), and then the size (so that we sort
files that are similar in size).
And finally, if everything else is equal (the size will generally be
identical for tree objects of the same directory with no new files but
just SHA1 changes, for example) we sort by the order they were found in
the history ("recency") by just comparing the pointer itself, since
the original thing will be just one big array filled in by order of
objects.
- find_deltas() - this is the actual thing that does the "look through
the object window and try to find good deltas", which operates on the
array that was created by the type_size_sort.
Hope that clarified something.
Linus
^ permalink raw reply
* [PATCH] hg-to-git: do not include the branch name as the first line of commit msg
From: Mark Drago @ 2007-12-01 17:56 UTC (permalink / raw)
To: stelian, gitster; +Cc: git
Signed-off-by: Mark Drago <markdrago@gmail.com>
---
contrib/hg-to-git/hg-to-git.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/hg-to-git/hg-to-git.py b/contrib/hg-to-git/hg-to-git.py
index 7a1c3e4..6bff49b 100755
--- a/contrib/hg-to-git/hg-to-git.py
+++ b/contrib/hg-to-git/hg-to-git.py
@@ -158,7 +158,7 @@ for cset in range(int(tip) + 1):
mparent = None
(fdcomment, filecomment) = tempfile.mkstemp()
- csetcomment = os.popen('hg log -r %d -v | grep -v ^changeset: | grep -v ^parent: | grep -v ^user: | grep -v ^date | grep -v ^files: | grep -v ^description: | grep -v ^tag:' % cset).read().strip()
+ csetcomment = os.popen('hg log -r %d -v | grep -v ^changeset: | grep -v ^parent: | grep -v ^user: | grep -v ^date | grep -v ^files: | grep -v ^description: | grep -v ^tag: | grep -v ^branch:' % cset).read().strip()
os.write(fdcomment, csetcomment)
os.close(fdcomment)
--
1.5.2.4
^ permalink raw reply related
* [PATCH] hg-to-git: handle an empty dir in hg by combining git commits
From: Mark Drago @ 2007-12-01 17:59 UTC (permalink / raw)
To: stelian, gitster; +Cc: git
I had a subversion repository which was then converted to hg and now is moving
in to git. The first commit in the svn repo was just the creation of the empty
directory. This made its way in to the hg repository fine, but converting from
hg to git would cause an error. The problem was that hg-to-git.py tries to
commit the change, git-commit fails, and then hg-to-git.py tries to checkout
the new revision and that fails (b/c it was not created). This may have only
caused an error because it was the first commit in the repository. If an empty
directory was added in the middle of the repo somewhere things might have
worked out fine.
This patch will detect that there are no changes to commit (using git-status),
and will not perform the commit, but will instead combine the log messages of
that (non-)commit with the next commit.
Signed-off-by: Mark Drago <markdrago@gmail.com>
---
contrib/hg-to-git/hg-to-git.py | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/contrib/hg-to-git/hg-to-git.py b/contrib/hg-to-git/hg-to-git.py
index 6bff49b..06e1b41 100755
--- a/contrib/hg-to-git/hg-to-git.py
+++ b/contrib/hg-to-git/hg-to-git.py
@@ -139,6 +139,7 @@ if not hgvers.has_key("0"):
os.system('git-init-db')
# loop through every hg changeset
+previous_comment = None
for cset in range(int(tip) + 1):
# incremental, already seen
@@ -159,6 +160,8 @@ for cset in range(int(tip) + 1):
(fdcomment, filecomment) = tempfile.mkstemp()
csetcomment = os.popen('hg log -r %d -v | grep -v ^changeset: | grep -v ^parent: | grep -v ^user: | grep -v ^date | grep -v ^files: | grep -v ^description: | grep -v ^tag: | grep -v ^branch:' % cset).read().strip()
+ if (previous_comment):
+ csetcomment += previous_comment
os.write(fdcomment, csetcomment)
os.close(fdcomment)
@@ -181,8 +184,8 @@ for cset in range(int(tip) + 1):
print 'tag:', tag
print '-----------------------------------------'
- # checkout the parent if necessary
- if cset != 0:
+ # checkout the parent if there is a repo to checkout from
+ if hgvers.has_key("0"):
if hgbranch[str(cset)] == "branch-" + str(cset):
print 'creating new branch', hgbranch[str(cset)]
os.system('git-checkout -b %s %s' % (hgbranch[str(cset)], hgvers[parent]))
@@ -210,6 +213,14 @@ for cset in range(int(tip) + 1):
# delete removed files
os.system('git-ls-files -x .hg --deleted | git-update-index --remove --stdin')
+ # is there something that git will commit (maybe just empty dir was added)
+ stat = os.system('git-status -a')
+ if (stat != 0):
+ print "No changes git notices, will combine log with next commit (maybe empty dir?)"
+ previous_comment = "\n\n--- hg-to-git merged commit ---\n\n" + csetcomment
+ continue
+ previous_comment = None
+
# commit
os.system(getgitenv(user, date) + 'git-commit -a -F %s' % filecomment)
os.unlink(filecomment)
--
1.5.2.4
^ permalink raw reply related
* Re: [PATCH] Do check_repository_format() early
From: Junio C Hamano @ 2007-12-01 18:58 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0711302250ldfb543evd6d5f70d95ae51f7@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On Dec 1, 2007 9:36 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Looks sensible, but can this be accompanied with a trivial test to
>> demonstrate the existing breakage?
>
> How can I reliably check setup_git_directory_gently()? I can pick one
> command that uses setup_git_directory_gently(). But commands change.
> Once they turn to setup_git_directory(), the test will no longer be
> valid.
The commands' implementation may change but what I meant was to test the
intent.
What's the difference between commands that call "gently" kind and
non-gently kind? The former is "I do not _have_ to be in a git
repository but if I am then I want to know about it and use some
information from that repository", as opposed to "I need to be in a git
repository and will find one otherwise I barf" which is the latter kind.
The intent of the change, from reading your patch, is that currently the
former kind of commands that take "an optional git repository" are happy
if they find a directory that looks like a git repository and go ahead
with their operation without checking the repository format version, and
your patch addresses this issue by making sure that the git repository
found via "gently" are also checked for the format version.
Examples of commands that do not necessarily require a valid git
repository are:
* apply: when being used as a "patch that is better than GNU", that is,
without --index, --cached, nor --check option.
* bundle: when verifying and listing the contained head of an existing
bundle file.
* config: without being in a git repository, you can still interact with
$HOME/.gitconfig and /etc/gitconfig [*1*].
* ls-remote: without being in a git repository, you can still list refs
from a remote repository. If you are in a git repository, you can
use nicknames you have in your repositories' remote.$nickname.url
configuration.
So what I would suggest would be:
* The directory your tests run in, t/trash, is a valid git repository.
Leave it as is.
* mkdir test inside t/trash, cd there, and run "git init" there to
initialize t/trash/test/.git (the shell function test_create_repo can
be used for this).
* corrupt this by updating the core.repositoryformatversion to a large
value, by doing something like:
V=$(git config core.repositoryformatversion)
(
cd test
N=$(( ${V:-0} + 99 ))
git config core.repositoryformatversion $N
)
* make sure t/trash/test/.git/config file, and not t/trash/.git/config
file, got that change by doing something like:
GIT_CONFIG=.git/config git config core.repositoryformatversion
GIT_CONFIG=test/.git/config git config core.repositoryformatversion
The former would report the current version ($V above) while the
latter should error out.
Up to this step is the "test setup". The actual tests would be done in
t/trash/test directory.
* Use a few commands that have the "we can run in git repository but we
do not have to" behaviour, in modes that _require_ git repository.
For example, "git apply --check" wants a valid repository to check
the patch against the index. They should fail because the repository
format is too new for them to understand.
* Similarly, run a few commands in modes that do not require git
repository. For example, "git apply --stat" of an existing patch
should be viewable no matter where you are (that is just a "better
diffstat" mode), so ideally it should not barf only because you
happen to be in a repository that is too new for you to understand.
I do not know offhand how your patch would handle this situation.
Note that making sure the latter works is tricky to do right, for a few
reasons.
(1) It is not absolutely clear what the right behaviour is. It could
be argued that we should just barf saying we found a repository we
do not understand, refraining from doing any damange on it [*2*].
(2) If we choose not to barf on such a repository, it remains to be
decided what "gently" should do --- if it should still treat
t/trash/test (which has too new a version) as the found repository,
or ignore it and use t/trash (which we can understand) as the found
repository. I think it should do the former.
IOW, the repository we are working against is t/trash/test/.git in
this case, and not t/trash/.git. We do not actually touch the
repository because we do not know the repository format version of
it, but we do not barf when doing operations that we do not have to
touch it. And we never touch t/trash/.git. We need to make sure
of these, which means that it is not enough to make sure
non-repository operations do not barf in t/trash/test. We also need
to make sure the reason they do not barf is not because we ignored
that repository with unknown version and went one level up and
found a repository with a known version. The reason for success
must be because we correctly ignored the version mismatch because
we knew the operations do not affect the repository.
[Footnotes]
*1* Tangent. "git grep etc/gitconfig" reveals a few instances of
$(prefix)/etc/gitconfig left behind, which was corrected in
v1.5.1.3. We need documentation updates.
*2* However, "we do not have to be in git repository" mode of operations
by definition do not touch any repository data (only work tree
files), so I do not think it is justfied to barf in such a case.
^ permalink raw reply
* Re: [PATCH] transport.c: call dash-less form of receive-pack and upload-pack on remote
From: Junio C Hamano @ 2007-12-01 19:30 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Eyvind Bernhardsen, Nicolas Pitre, Nguyen Thai Ngoc Duy,
Jan Hudec, git
In-Reply-To: <Pine.LNX.4.64.0712010959180.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I only eyeball-tested it and looks Okay, but that does not assure us
>> much ;-). Is this change easy to test using local transport?
>
> Seems like it breaks down with git-shell. But then, I think that we just
> have to fix execv_git_cmd() to call builtins via "git" instead.
So in execv_git_cmd(), instead of doing the strbuf_addf(), we do
something like this (and drop your patch)?
---
exec_cmd.c | 34 +++++++++++++---------------------
1 files changed, 13 insertions(+), 21 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 2d0a758..2920335 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -65,32 +65,24 @@ void setup_path(const char *cmd_path)
int execv_git_cmd(const char **argv)
{
- struct strbuf cmd;
- const char *tmp;
-
- strbuf_init(&cmd, 0);
- strbuf_addf(&cmd, "git-%s", argv[0]);
-
- /*
- * argv[0] must be the git command, but the argv array
- * belongs to the caller, and may be reused in
- * subsequent loop iterations. Save argv[0] and
- * restore it on error.
- */
- tmp = argv[0];
- argv[0] = cmd.buf;
-
- trace_argv_printf(argv, -1, "trace: exec:");
+ int i;
+ const char **args;
+
+ for (i = 0; argv[i]; i++)
+ ;
+ args = xcalloc(i + 1, sizeof(*args));
+ for (i = 0; argv[i]; i++)
+ args[i+1] = argv[i];
+ args[0] = "git";
+ args[i+1] = NULL;
+ trace_argv_printf(args, -1, "trace: exec:");
/* execvp() can only ever return if it fails */
- execvp(cmd.buf, (char **)argv);
+ execvp(args[0], (char **)args);
trace_printf("trace: exec failed: %s\n", strerror(errno));
- argv[0] = tmp;
-
- strbuf_release(&cmd);
-
+ free(args);
return -1;
}
^ permalink raw reply related
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Junio C Hamano @ 2007-12-01 19:32 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Linus Torvalds, Jeff King, Santi B?jar, Steffen Prohaska,
Junio C Hamano, Johannes Schindelin, Jan Hudec, git
In-Reply-To: <fcaeb9bf0711302234l32460a1fqbf9825fc8055f99d@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On Nov 30, 2007 10:50 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> Well, different people will want different viewers *anyway* (ie some will
>> prefer qgit etc), so how about making "git view" be something that
>> literally acts as a built-in alias that just defaults to running gitk (if
>> for no other reason than the fact that gitk is the one that ships with
>> git, and simply has most users).
>
> We already have "git show", now we gonna get "git view", git trainers
> may have hard time explaining this one shows you a particular object
> while the other one shows you history. How about "git lshistory" (from
> clearcase land) or git show --history?
Heh, we have "bisect visualize". How about "git visualize"?
^ permalink raw reply
* Re: [PATCH] git-cvsserver runs hooks/post-receive
From: Junio C Hamano @ 2007-12-01 19:38 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <BFDB9A00-6E92-4880-9FE7-3D0E392D18A9@mit.edu>
Michael Witten <mfwitten@MIT.EDU> writes:
> On 30 Nov 2007, at 9:37:01 PM, Junio C Hamano wrote:
>
>> I'll queue your patch, but I think it should be enhanced to support
>> post-update for consistency.
>
> I'll send another patch that includes support for post-update.
>
>> I'll queue your patch,
>
> Will the old patch already be in place?
Although I would encourage total replacement patch for things not in
'next' yet, in this case, I think we both would prefer a separate patch
that builds on top of the old patch that teaches the server that it
should call post-update as well.
I think it is potentially a sensible thing to do to eventually deprecate
and then remove post-update hook (as your first patch that is queued
already suggests). I was just saying that 'eventually' is not now.
When that time comes, if you have a separate patch to teach post-update,
that single patch can be reverted independently from the old patch,
which should be less error prone than yanking the support out by hand.
^ permalink raw reply
* Re: [PATCH] xdiff-interface.c (buffer_is_binary): Remove buffer size limitation
From: Junio C Hamano @ 2007-12-01 19:46 UTC (permalink / raw)
To: Dmitry V. Levin; +Cc: Git Mailing List
In-Reply-To: <20071201160113.GA20849@nomad.office.altlinux.org>
"Dmitry V. Levin" <ldv@altlinux.org> writes:
> When checking buffer for NUL byte, do not limit size of buffer we check.
> Otherwise we break git-rebase: git-format-patch may generate output which
> git-mailinfo cannot handle properly.
I think this is tackling a valid problem but it is a wrong solution.
The change penalizes text changes which is the majority, just in case
there is an unusual change that has an embedded NUL far into the file
(iow, exception).
Perhaps mailinfo can be updated to handle embedded NUL.
Another alternative (I've been trying to find time to do so for quite a
while now but dealing with list traffic always takes priority on my time
allotment) is to update rebase not to rely on "format-patch piped to
am", and I think that is more correct solution in the longer term.
In the meantime, a workaround would be to use "rebase -i". It uses
cherry-pick machinery instead of "format-patch piped to am", and
hopefully would handle NULs better. It probably is slower than non
interactive one exactly because it uses cherry-pick, and that is the
reason I am first working on updating cherry-pick before actually making
the non-interactive rebase to use it.
^ permalink raw reply
* Re: [PATCH] hg-to-git: handle an empty dir in hg by combining git commits
From: Junio C Hamano @ 2007-12-01 20:02 UTC (permalink / raw)
To: Mark Drago; +Cc: stelian, git
In-Reply-To: <4751A0FB.6090705@gmail.com>
Mark Drago <markdrago@gmail.com> writes:
> This patch will detect that there are no changes to commit (using git-status),
> and will not perform the commit, but will instead combine the log messages of
> that (non-)commit with the next commit.
I think a better approach would be to implement --no-tree-change-is-ok
option to git-commit, strictly for use by foreign scm interface scripts
like yours. It does not usually make sense to record a commit that has
the exact same tree as its sole parent commit and that is why git-commit
prevents you from making that mistake, but when data from foreign scm is
involved, it is a different story. We are equipped to represent such a
(perhaps insane, perhaps by mistake, or perhaps done on purpose) change
and it is better to represent it bypassing the safety valve for native
use.
^ permalink raw reply
* Re: [PATCH v2] Teach 'git pull' about --rebase
From: Björn Steinbrink @ 2007-12-01 20:37 UTC (permalink / raw)
To: Junio C Hamano
Cc: Lars Hjemli, Johannes Schindelin, Steven Grimm, Linus Torvalds,
git
In-Reply-To: <7vhcj63uhw.fsf@gitster.siamese.dyndns.org>
On 2007.11.28 13:55:39 -0800, Junio C Hamano wrote:
> "Lars Hjemli" <hjemli@gmail.com> writes:
>
> > On 11/28/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >> On Wed, 28 Nov 2007, Steven Grimm wrote:
> >> > I wonder if this shouldn't be branch.<name>.pulltype or something like
> >> > that, so we can represent more than just "rebase or not." Values could
> >> > be "rebase", "merge" (the default) and maybe even "manual" to specify
> >> > that git-pull should neither merge nor rebase a particular branch even
> >> > if it matches a wildcard refspec.
> >>
> >> I am not convinced that this is a good thing... We already have
> >> branch.<name>.mergeOptions for proper merges, and I want to make clear
> >> that this is about rebase, and not about merge.
> >
> > Maybe branch.<name>.pullOptions ?
>
> Maybe not make this part of git-pull at all? merge and rebase have
> totally different impact on the resulting history, so perhaps a separate
> command that is a shorthand for "git fetch && git rebase" may help
> unconfuse the users.
Hm, why not tackle the whole thing the other way around? IMHO the
primary action is the merge/rebase, not the fetch. So choosing which
action you want in addition to the fetch seems a bit backwards. git-svn
already includes a fetch from svn in its rebase operation, which is
really handy, because you rebase quite often with that beast.
And it's likely that you want to merge with/rebase against the latest available
remote commit all the time anyway and on the few(?) occassions
where you have no connectivity, but already fetched some remote stuff
which you want to incorporate into your local branches now, it's
hopefully bearable to pass --no-fetch.
So how about adding --fetch/--no-fetch (maybe with a configurable
default?) to git-merge/git-rebase and deprecate git-pull over time?
Björn
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Jeff King @ 2007-12-01 21:26 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nguyen Thai Ngoc Duy, Linus Torvalds, Santi B?jar,
Steffen Prohaska, Johannes Schindelin, Jan Hudec, git
In-Reply-To: <7vve7i43ec.fsf@gitster.siamese.dyndns.org>
On Sat, Dec 01, 2007 at 11:32:27AM -0800, Junio C Hamano wrote:
> > We already have "git show", now we gonna get "git view", git trainers
> > may have hard time explaining this one shows you a particular object
> > while the other one shows you history. How about "git lshistory" (from
> > clearcase land) or git show --history?
>
> Heh, we have "bisect visualize". How about "git visualize"?
Yes, in retrospect "view" is probably not the best. "lshistory" just
looks awful, and I think it's wrong for an option to "git show" to
change it from a terminal application into a GUI application.
"visualize" is actually pretty good, except that it would be painful to
type. On the other hand, I will probably still just type "gitk". I
actually think these sorts of aliases may be most useful for user-facing
scripts to say "and now show the dataset in the user's graphical history
browser of choice."
-Peff
^ permalink raw reply
* [ANNOUNCE] GIT 1.5.3.7
From: Junio C Hamano @ 2007-12-01 21:38 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <7vve7ztad4.fsf@gitster.siamese.dyndns.org>
The latest maintenance release GIT 1.5.3.7 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.3.7.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.3.7.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.3.7.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.3.7-1.$arch.rpm (RPM)
What's cooking for upcoming feature release v1.5.4 has been stablizing,
and hopefully this will be the last of v1.5.3 maintenance series.
By the way, if you are the package maintainer of git for a distro, or
the editor of an OSS oriented publication, and if you would like a copy
of release announcements, please let me know, so that I can add your
e-mail address to Bcc: on future announcement mails. Sorry, but I
cannot handle subscription requests from individuals.
----------------------------------------------------------------
GIT v1.5.3.7 Release Notes
==========================
Fixes since v1.5.3.6
--------------------
* git-send-email added 8-bit contents to the payload without
marking it as 8-bit in a CTE header.
* "git-bundle create a.bndl HEAD" dereferenced the symref and
did not record the ref as 'HEAD'; this prevented a bundle
from being used as a normal source of git-clone.
* The code to reject nonsense command line of the form
"git-commit -a paths..." and "git-commit --interactive
paths..." were broken.
* Adding a signature that is not ASCII-only to an original
commit that is ASCII-only would make the result non-ASCII.
"git-format-patch -s" did not mark such a message correctly
with MIME encoding header.
* git-add sometimes did not mark the resulting index entry
stat-clean. This affected only cases when adding the
contents with the same length as the previously staged
contents, and the previous staging made the index entry
"racily clean".
* git-commit did not honor GIT_INDEX_FILE the user had in the
environment.
* When checking out a revision, git-checkout did not report where the
updated HEAD is if you happened to have a file called HEAD in the
work tree.
* "git-rev-list --objects" mishandled a tree that points at a
submodule.
* "git cvsimport" was not ready for packed refs that "git gc" can
produce and gave incorrect results.
* Many scripted Porcelains were confused when you happened to have a
file called "HEAD" in your work tree.
Also it contains updates to the user manual and documentation.
----------------------------------------------------------------
Changes since v1.5.3.6 are as follows:
Björn Steinbrink (3):
git-commit.sh: Fix usage checks regarding paths given when they do not make sense
t7005-editor.sh: Don't invoke real vi when it is in GIT_EXEC_PATH
git-commit: Add tests for invalid usage of -a/--interactive with paths
Brian Downing (2):
config: correct core.loosecompression documentation
config: clarify compression defaults
J. Bruce Fields (7):
git-remote.txt: fix example url
user-manual: mention "..." in "Generating diffs", etc.
Documentation: Fix references to deprecated commands
user-manual: define "branch" and "working tree" at start
user-manual: failed push to public repository
user-manual: clarify language about "modifying" old commits
user-manual: recovering from corruption
Jan Hudec (1):
Improve description of git-branch -d and -D in man page.
Jeff King (5):
send-email: add transfer encoding header with content-type
Add basic cvsimport tests
cvsimport: use rev-parse to support packed refs
cvsimport: miscellaneous packed-ref fixes
cvsimport: fix usage of cvsimport.module
Johannes Schindelin (2):
bundle create: keep symbolic refs' names instead of resolving them
Replace the word 'update-cache' by 'update-index' everywhere
Johannes Sixt (1):
t7003-filter-branch: Fix test of a failing --msg-filter.
Junio C Hamano (11):
format-patch -s: add MIME encoding header if signer's name requires so
test format-patch -s: make sure MIME content type is shown as needed
ce_match_stat, run_diff_files: use symbolic constants for readability
git-add: make the entry stat-clean after re-adding the same contents
t2200: test more cases of "add -u"
Make test scripts executable.
Fix sample pre-commit hook
git-checkout: describe detached head correctly
scripts: do not get confused with HEAD in work tree
Fix typo in t4008 test title
GIT 1.5.3.7
Linus Torvalds (1):
Fix rev-list when showing objects involving submodules
Matthieu Moy (1):
Doc fix for git-reflog: mention @{...} syntax, and <ref> in synopsys.
Rémi Vanicat (1):
Make GIT_INDEX_FILE apply to git-commit
Steffen Prohaska (1):
user-manual: Add section "Why bisecting merge commits can be harder ..."
^ permalink raw reply
* Re: [PATCH 6/6] builtin-commit: Add newline when showing which commit was created
From: Jeff King @ 2007-12-01 22:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, krh, gitster
In-Reply-To: <Pine.LNX.4.64.0711111736440.4362@racer.site>
On Sun, Nov 11, 2007 at 05:36:52PM +0000, Johannes Schindelin wrote:
> The function log_tree_commit() does not break the line, so we have to
> do it ourselves.
Johannes,
Can you explain the rationale for this change in more detail?
When I run builtin-commit from the tip of next, I always get an extra
newline (as compared to the shell behavior):
-- >8 --
$ git version &&
mkdir test && cd test && git init &&
touch file && git add file && git commit -m added &&
echo content >file && git commit -a -m updated &&
echo done
git version 1.5.3.6.2090.g4ece0
Initialized empty Git repository in .git/
Created initial commit b3cbe63: added
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file
Created commit 7a6b446: updated
1 files changed, 1 insertions(+), 0 deletions(-)
done
-- 8< --
where the shell behavior omits the extra newlines. Is there some other
input for which log_tree_commit actually needs the newline?
-Peff
^ permalink raw reply
* Re: git pack-objects input list
From: Mike Hommey @ 2007-12-01 22:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.9999.0712010933370.8458@woody.linux-foundation.org>
On Sat, Dec 01, 2007 at 09:49:00AM -0800, Linus Torvalds wrote:
> Hope that clarified something.
Thanks, that helped me understand my observations when trying to pack
with and without file names in pack-objects input on different kind of
datasets, where some would be best packed with and others would be without.
I'll try to add some words about the pack-objects input format in the
documentation. I don't know if it's worth adding information about the
packing process itself in the manual page. Or maybe that should be added
to a more technical document about git (a bit like "git for computer
scientists")
Mike
^ permalink raw reply
* Re: [PATCH 6/6] builtin-commit: Add newline when showing which commit was created
From: Johannes Schindelin @ 2007-12-01 22:41 UTC (permalink / raw)
To: Jeff King; +Cc: git, krh, gitster
In-Reply-To: <20071201222106.GA27102@coredump.intra.peff.net>
Hi,
On Sat, 1 Dec 2007, Jeff King wrote:
> On Sun, Nov 11, 2007 at 05:36:52PM +0000, Johannes Schindelin wrote:
>
> > The function log_tree_commit() does not break the line, so we have to
> > do it ourselves.
>
> Johannes,
>
> Can you explain the rationale for this change in more detail?
Basically, I ran a test case in which the shell script was different from
the builtin version, and this was the patch that fixed it for me.
Maybe it should have been
if (log_tree_commit(&rev, commit))
printf("\n");
at the end of print_summary() instead. Can you try if that fixes it for
you?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] transport.c: call dash-less form of receive-pack and upload-pack on remote
From: Johannes Schindelin @ 2007-12-01 23:03 UTC (permalink / raw)
To: Junio C Hamano
Cc: Eyvind Bernhardsen, Nicolas Pitre, Nguyen Thai Ngoc Duy,
Jan Hudec, git
In-Reply-To: <7vzlwu43i4.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 1 Dec 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> I only eyeball-tested it and looks Okay, but that does not assure us
> >> much ;-). Is this change easy to test using local transport?
> >
> > Seems like it breaks down with git-shell. But then, I think that we just
> > have to fix execv_git_cmd() to call builtins via "git" instead.
>
> So in execv_git_cmd(), instead of doing the strbuf_addf(), we do
> something like this (and drop your patch)?
You know what is really funny? I have this in my stash:
-- snip --
exec_cmd.c | 30 ++++++++++++------------------
t/t0020-crlf.sh | 2 +-
2 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 2d0a758..7d022a2 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -65,31 +65,25 @@ void setup_path(const char *cmd_path)
int execv_git_cmd(const char **argv)
{
- struct strbuf cmd;
- const char *tmp;
+ int i;
+ char **new_argv;
- strbuf_init(&cmd, 0);
- strbuf_addf(&cmd, "git-%s", argv[0]);
+ for (i = 0; argv[i]; i++)
+ ; /* do nothing */
+ new_argv = xmalloc((i + 2) * sizeof(*new_argv));
+ new_argv[0] = "git";
+ for (i = 0; argv[i]; i++)
+ new_argv[i + 1] = (char *)argv[i];
+ new_argv[i] = NULL;
- /*
- * argv[0] must be the git command, but the argv array
- * belongs to the caller, and may be reused in
- * subsequent loop iterations. Save argv[0] and
- * restore it on error.
- */
- tmp = argv[0];
- argv[0] = cmd.buf;
-
- trace_argv_printf(argv, -1, "trace: exec:");
+ trace_argv_printf((const char **)new_argv, -1, "trace: exec:");
/* execvp() can only ever return if it fails */
- execvp(cmd.buf, (char **)argv);
+ execvp(new_argv[0], new_argv);
trace_printf("trace: exec failed: %s\n", strerror(errno));
- argv[0] = tmp;
-
- strbuf_release(&cmd);
+ free(new_argv);
return -1;
}
diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
index 62bc4bb..275379d 100755
--- a/t/t0020-crlf.sh
+++ b/t/t0020-crlf.sh
@@ -36,7 +36,7 @@ test_expect_success setup '
for w in Some extra lines here; do echo $w; done >>one &&
git diff >patch.file &&
- patched=`git hash-object --stdin <one` &&
+ patched=`GIT_TRACE=2 git hash-object --stdin <one` &&
git read-tree --reset -u HEAD &&
echo happy.
-- snap --
Which looks awfully like your patch (except that I called it new_argv, I
think).
Now you might ask why there is such a funny patch to t0020? Well, the
patch does not work as-is.
Will investigate right now,
Dscho
^ permalink raw reply related
* Re: [PATCH] transport.c: call dash-less form of receive-pack and upload-pack on remote
From: Johannes Schindelin @ 2007-12-01 23:15 UTC (permalink / raw)
To: Junio C Hamano
Cc: Eyvind Bernhardsen, Nicolas Pitre, Nguyen Thai Ngoc Duy,
Jan Hudec, git
In-Reply-To: <Pine.LNX.4.64.0712012300440.27959@racer.site>
Hi,
On Sat, 1 Dec 2007, Johannes Schindelin wrote:
> Will investigate right now,
The problem is that "git <command>" will call execv_git_cmd() for
non-builtins, which in turn will execute "git <command>", ... ad
infinitum.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-show: only chdir(prefix) when prefix is not NULL, and check for success
From: Johannes Schindelin @ 2007-12-02 1:42 UTC (permalink / raw)
To: git, gitster
We blindly called "chdir(prefix);" and did not even check if it succeeded.
Found by valgrind.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
builtin-log.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 21f3b0f..0f38579 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -285,7 +285,8 @@ int cmd_show(int argc, const char **argv, const char *prefix)
struct object_array_entry *objects;
int i, count, ret = 0;
- chdir(prefix);
+ if (prefix && chdir(prefix))
+ die ("Could not change directory to '%s'", prefix);
git_config(git_log_config);
init_revisions(&rev, prefix);
--
1.5.3.6.2112.ge2263
^ permalink raw reply related
* Re: [PATCH] transport.c: call dash-less form of receive-pack and upload-pack on remote
From: Junio C Hamano @ 2007-12-02 1:57 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Eyvind Bernhardsen, Nicolas Pitre, Nguyen Thai Ngoc Duy,
Jan Hudec, git
In-Reply-To: <Pine.LNX.4.64.0712012314190.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sat, 1 Dec 2007, Johannes Schindelin wrote:
>
>> Will investigate right now,
>
> The problem is that "git <command>" will call execv_git_cmd() for
> non-builtins, which in turn will execute "git <command>", ... ad
> infinitum.
Ok, then the ".. then try the external ones" in git.c needs to do the
execvp itself, which should not be a big deal.
Very funny ;-).
^ permalink raw reply
* Re: git pack-objects input list
From: Nicolas Pitre @ 2007-12-02 2:23 UTC (permalink / raw)
To: Mike Hommey; +Cc: Linus Torvalds, git
In-Reply-To: <20071201223849.GA15110@glandium.org>
On Sat, 1 Dec 2007, Mike Hommey wrote:
> On Sat, Dec 01, 2007 at 09:49:00AM -0800, Linus Torvalds wrote:
> > Hope that clarified something.
>
> Thanks, that helped me understand my observations when trying to pack
> with and without file names in pack-objects input on different kind of
> datasets, where some would be best packed with and others would be without.
>
> I'll try to add some words about the pack-objects input format in the
> documentation. I don't know if it's worth adding information about the
> packing process itself in the manual page. Or maybe that should be added
> to a more technical document about git (a bit like "git for computer
> scientists")
Look at Documentation/technical/ for existing technically oriented
documents. The pack format and packing heuristics have documents of
their own already. If you feel like adding more documentation there
please just go ahead.
Nicolas
^ 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