* Efficient retrieval of commit log info
From: Eirik Bjørsnøs @ 2007-12-12 14:36 UTC (permalink / raw)
To: git
Hi,
I'm developing a piece of software that grabs logs from various types
of SCMs and presents (hopefully) useful information about the history.
My current approach with Git is do a "git clone --n" and then parse
the output of "git log". To check for updates I do a "git pull"
followed by a new "git log".
This approach works fine, but cloning the whole repository just to get
the change log seems like a somewhat inefficient use of bandwidth and
storage.
What I would like to do is to fetch just the change log information
from the remote repository.
(Using the "CVS done right" tool I can do this with: "svn log --xml -v
-r<last, HEAD> http://svn.example.com/")
I haven't found a way to do this using the Git command line tools.
Is it at all possible using the git network protocols to fetch just
the commit log info, without transferring the contents?
I'd be happy to hear from anyone who has some insight into this.
Thanks,
Eirik.
^ permalink raw reply
* Re: [PATCH] Fix typo: we require Python 2.4, not 2.5
From: Catalin Marinas @ 2007-12-12 14:04 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Git Mailing List
In-Reply-To: <20071211142347.GA22879@diana.vm.bytemark.co.uk>
On 11/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> Yeah. So 0.14.1 (to be released very soon) should probably have this
> fix. :-)
OK, done. Thanks.
On the RPM side, I found a way to specify the required Python version
on the "setup.py bdist_rpm" command line but I don't think it makes
any difference since the installed files will go into the python2.5
directory.
Anyway, I linked the SRPMS as well from the website's page.
--
Catalin
^ permalink raw reply
* Re: Invalid dates in git log
From: Eirik Bjørsnøs @ 2007-12-12 14:19 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20071212092304.GA20799@coredump.intra.peff.net>
> Your best guess is probably the committer information. Try this:
Thanks Jeff, Junio,
I'll just use the committer date instead.
Being a Git newbie (only started looking at it yesterday) I'm not sure
my understanding of "author" and "committer" and how they releate to
dates is correct:
* author: Original source of the change. This person may typically
have sent a committer an email with a patch. It's the commiter's
responsibility to supply this information.
* author date: The commiter is free to specify a date for the contribution.
* committer: First committer to actually add this change to a repository
* committer date: Date of the actual commit, added by the git client
during the commit. Typically the system clock at the time of the
commit.
* A transfer of a commit across repositories (pull, push) will not
change the author, commit or date information
If I got some of this wrong, I'd be happy if someone would correct me.
Thanks,
Eirik.
^ permalink raw reply
* Re: [PATCH 2/2] git-help: add "web_or_man" and "web_or_info" config vars.
From: Johannes Schindelin @ 2007-12-12 11:22 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio Hamano, git
In-Reply-To: <20071212063325.92cd29a8.chriscool@tuxfamily.org>
Hi,
"web_or_man" is completely out of line with our existing CamelCase config
variables.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] builtin-clone: Implement git clone as a builtin command.
From: Johannes Schindelin @ 2007-12-12 11:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kristian Høgsberg, Daniel Barkalow, git
In-Reply-To: <7vejdsbo7d.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3184 bytes --]
Hi,
On Tue, 11 Dec 2007, Junio C Hamano wrote:
> Kristian Høgsberg <krh@redhat.com> writes:
>
> > On Tue, 2007-12-11 at 15:59 -0500, Daniel Barkalow wrote:
> >> On Tue, 11 Dec 2007, Kristian Høgsberg wrote:
> >>
> >> > Ok, don't flame me, I know this isn't appropriate at the moment
> >> > with stabilization for 1.5.4 going on, but I just wanted to post a
> >> > heads up on this work to avoid duplicate effort. It's one big
> >> > patch at this point and I haven't even run the test suite yet, but
> >> > that will change.
> >>
> >> Is that why you misspelled Junio's email address? :)
> >
> > Hehe, yeah, do not mess with maintainers in release mode :)
>
> Actually this is a bit unfortunate, regardless of everybody being in
> release and bugfix only mode.
I can understand that feeling, but I have to say that I am actually quite
pleased with the progress in direction of having most of git as builtins.
> I was hoping that the evolution path for clone would be to first make it
> a very thin wrapper around:
>
> git init
> git remote add -f
> git checkout
>
> sequence.
Yeah, I thought so too, but I'll also gladly take the builtin first.
> There are a handful issues in that approach with the current git-remote,
> and that was why I also thought recent "git remote in C" by Dscho a bit
> unfortunate, as enhancements and interface fixes (both user and machine)
> tend to be much easier in scripted version.
And here I have to disagree strongly. I _wasted_ a _week_ on trying to
fix that stupid "add --mirror && prune" bug in the scripted version. It
was absolutely horrible. And I felt like a moron after that week.
In contrast, it was easy as chocolate cake to fix it in the builtin
remote.
Now, if you not only hinted in some mail that something is wrong with
builtin-remote, but gave me some input, I could fix that in the builtin,
too.
> What the current "git clone" does that are not naturally expressed by
> the above sequence are:
>
> * HEAD discovery
>
> The code can be lifted from the scripted version and transplanted to
> git-remote. And to make "origin" and other remotes added by "git
> remote add", this logic needs to be moved to "git remote".
>
> However, before rewriting the "git remote" to C, it would be really
> nice if we can update the native protocol so that we can reliably
> find out which branch HEAD points at. The current code guesses, only
> because the native protocol does not carry that information [*1*].
> Worse yet, even though the current code _knows_ this information when
> going over dumb protocols, it discards it to use the same guessing
> logic as used by the native protocol.
I wonder why this should be easier with git remote in Perl. IMHO it is
easier with git remote in C.
> * --shared optimization
>
> This is a very easy addition to "git remote add". You make sure that
> the added remote repository is on a local machine, and set up
> alternates to point at its object store.
Concur.
Since I want to lose that dependency on cpio on Windows (which we fake by
using tar), I'll implement this in C anyway.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] clone: support cloning full bundles
From: Santi Béjar @ 2007-12-12 10:48 UTC (permalink / raw)
To: Git Mailing List; +Cc: Santi Béjar
It still fails for incremental bundles.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
Hi *,
Does anyone know how to create a repository from an incremental bundle?
Also, when a repo/bundle does not have a HEAD, clone does not setup the
remote configs, is this the desired behavior?
I know that Kristian is working in the C conversion, I'll rebase this
patch on top if that is prefered. Or maybe it will not be necessary at all,
as "git fetch" supports bundles.
Santi
git-clone.sh | 17 +++++++++++++----
t/t5701-clone-local.sh | 11 +++++++++++
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index ecf9d89..a4a2124 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -206,11 +206,14 @@ fi
if base=$(get_repo_base "$repo"); then
repo="$base"
local=yes
+elif [ -f "$repo" ] ; then
+ case "$repo" in /*);; *) repo="$PWD/$repo" ; esac
fi
dir="$2"
# Try using "humanish" part of source repo if user didn't specify one
[ -z "$dir" ] && dir=$(echo "$repo" | sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
+[ -f "$dir" ] && dir=$(expr "$repo" : '.*/\([^/]*\)\.[^/]*')
[ -e "$dir" ] && die "destination directory '$dir' already exists."
[ yes = "$bare" ] && unset GIT_WORK_TREE
[ -n "$GIT_WORK_TREE" ] && [ -e "$GIT_WORK_TREE" ] &&
@@ -359,11 +362,17 @@ yes)
fi
;;
*)
- case "$upload_pack" in
- '') git-fetch-pack --all -k $quiet $depth $no_progress "$repo";;
- *) git-fetch-pack --all -k $quiet "$upload_pack" $depth $no_progress "$repo" ;;
- esac >"$GIT_DIR/CLONE_HEAD" ||
+ if [ -f "$repo" ] ; then
+ git bundle unbundle "$repo" > "$GIT_DIR/CLONE_HEAD" ||
+ die "unbundle from '$repo' failed."
+ else
+ case "$upload_pack" in
+ '') git-fetch-pack --all -k $quiet $depth $no_progress "$repo";;
+ *) git-fetch-pack --all -k \
+ $quiet "$upload_pack" $depth $no_progress "$repo" ;;
+ esac >"$GIT_DIR/CLONE_HEAD" ||
die "fetch-pack from '$repo' failed."
+ fi
;;
esac
;;
diff --git a/t/t5701-clone-local.sh b/t/t5701-clone-local.sh
index 822ac8c..a7e5a31 100755
--- a/t/t5701-clone-local.sh
+++ b/t/t5701-clone-local.sh
@@ -9,6 +9,7 @@ test_expect_success 'preparing origin repository' '
: >file && git add . && git commit -m1 &&
git clone --bare . a.git &&
git clone --bare . x &&
+ git bundle create b1.bundle --all HEAD &&
test "$(GIT_CONFIG=a.git/config git config --bool core.bare)" = true &&
test "$(GIT_CONFIG=x/config git config --bool core.bare)" = true
'
@@ -63,4 +64,14 @@ test_expect_success 'Even without -l, local will make a hardlink' '
test 0 = $copied
'
+test_expect_success 'bundle clone with suffix' '
+ cd "$D" &&
+ git clone b1.bundle
+'
+
+test_expect_success 'bundle clone' '
+ cd "$D" &&
+ git clone b1.bundle bdl1
+'
+
test_done
--
1.5.3.7.2094.gff6c
^ permalink raw reply related
* Re: git annotate runs out of memory
From: Florian Weimer @ 2007-12-12 10:36 UTC (permalink / raw)
To: Daniel Berlin; +Cc: git
In-Reply-To: <4aca3dc20712110933i636342fbifb15171d3e3cafb3@mail.gmail.com>
* Daniel Berlin:
> On the gcc repository (which is now a 234 meg pack for me), git
> annotate ChangeLog takes > 800 meg of memory (I stopped it at about
> 1.6 gig, since it started swapping my machine).
> I assume it will run out of memory. I stopped it after 2 minutes.
A less unwieldy repository that shows the same problem is:
svn://svn.debian.org/secure-testing/
It's annotating the data/CVE/list file that uses tons of memory. I
guess you don't need to clone the full history to exhibit the problem.
--
Florian Weimer <fweimer@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
^ permalink raw reply
* Re: [PATCH (amend)] diff: Make numstat machine friendly also for renames (and copies)
From: Jakub Narebski @ 2007-12-12 10:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <200712120009.36560.jnareb@gmail.com>
BTW. I have noticed something strange with current (after my two
patches) diffstat code:
3606:[gitweb/web@git]# ./git diff-tree -C -C -r --stat gitweb/test~8
0456a2ba58efb0e1d5f7421d5a8a2278e3b15ebc
.../test/file with spaces\tand\ttabs" | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
3607:[gitweb/web@git]# ./git diff-tree -C -C -r --numstat gitweb/test~8
0456a2ba58efb0e1d5f7421d5a8a2278e3b15ebc
3 1 gitweb/test/file with spaces "gitweb/test/file with spaces\tand\ttabs"
but:
3603:[gitweb/web@git]# ./git diff-tree -C -C -r --stat gitweb/test~6
cfb9ef9ec73b37f44e9370c4f5d91e01d46ec6e4
gitweb/test/Documentation-symlink1 | 1 +
gitweb/test/Documentation-symlink2 | 1 +
.../{git-shortlog.8.html => git-shortlog.html} | 0
3 files changed, 2 insertions(+), 0 deletions(-)
So rename detection works. Strange.
P.S. gitweb/test branch can be found on
http://repo.or.cz/w/git/jnareb-git.git
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 4/9] gitk i18n: Initial German translation.
From: Christian Stimming @ 2007-12-12 8:23 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, git
In-Reply-To: <18271.7084.431598.815386@cargo.ozlabs.ibm.com>
Am Mittwoch, 12. Dezember 2007 00:22 schrieb Paul Mackerras:
> Christian Stimming writes:
> > ---
> > In order to test the i18n code, I prepared half-completed
> > German translation.
> >
> > po/de.po | 703
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files
> > changed, 703 insertions(+), 0 deletions(-)
> > create mode 100644 po/de.po
> >
> > diff --git a/po/de.po b/po/de.po
> > new file mode 100644
> > index 0000000..8c41069
> > --- /dev/null
> > +++ b/po/de.po
> > @@ -0,0 +1,703 @@
> > +# Translation of git-gui to German.
> > +# Copyright (C) 2007 Shawn Pearce, et al.
>
> Ummm? I think you forgot to change some things here. :)
I'll change those when I update the German translation. I'd ask you to commit
this one anyway so that there is at least one translation to play with.
Christian
^ permalink raw reply
* Re: [PATCH (amend)] diff: Make numstat machine friendly also for renames (and copies)
From: Jakub Narebski @ 2007-12-12 10:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabog9wyx.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > The previous patch is a fix (usability fix) for numstat output in the
> > presence of rename detection, making it truly machine friendly. Moreover
> > it should not break any scripts which parsed numstat output not
> > expecting to deal with renames (for example if repository has
> > diff.renames config option set), and might even fix them.
> >
> > The proposed - and implemented in patch below - change could break some
> > scripts not expecting to deal with new numstat output.
>
> I do not quite follow. If a script wanted -M and/or -C output in the
> older "common/{a => b}/common" format, either change would break it
> equally badly, either with or without -z. And I do not think adding
> status letter is necessary for --numstat; if the caller wants that
> information, it can ask for it explicitly with both options.
I meant it there that if an [older] script parsing numstat output
didn't expect to deal with renames (but had to for example because
of diff.renames set), and expected the numstat output format to be
either
<add> TAB <del> TAB <filename_q> LF
or (if running with -z option)
<add> TAB <del> TAB <filename> NUL
After first patch, but before second, those expectations were met, that
I meant by "and might even fix them" (the scripts).
BTW. beside the fact that for renames it was not filename (pathname),
it could be half-quoted; see also below.
> So I do not think there is anything more to solve, than the patch you
> just sent.
>
> The patch looks good. Thanks.
>
> > P.S. The numstat output format for renames should be probably described
> > in documentation, and not only in commit message, but I was not sure
> > where to put it (and even how it should be written).
>
> I started writing this, and then reviewed the result of squashing your
> two patches.
And because of the above I wanted that you'd rather _not_ squash those
patches, but apply them separately...
> Although everybody complains that most of git is run-once-and-exit, I
> wrote the original diff part fairly conservatively to make it leak-free,
> because of a single command, "diff-tree --stdin", that can be told to
> run millions of diffs inside a single process.
>
> But the diffstat part is horribly leaky, especially after your patch,
> and it has ugly workarounds such as refusing to show both diffstat and
> shortstat at the same time, not because it does not make much sense
> (admittedly it doesn't), but because show_stats() discards necessary
> information when it is done, making it impossible for shortstat to run.
>
> So I ended up restructuring the name allocation/free code a bit while at
> it.
...but as you did more surgery on diffstat, it is reasonable to do it
in one commit, not two.
> -- >8 --
> diff --numstat -z: make it machine readable
>
> The "-z" format is all about machine parsability, but showing renamed
> paths as "common/{a => b}/suffix" makes it impossible. The scripts would
> never have successfully parsed "--numstat -z -M" in the old format.
>
> This fixes the output format in a (hopefully minimally) backward
> incompatible way.
>
> * The output without -z is not changed. This has given a good way for
> humans to view added and deleted lines separately, and showing the
> path in combined, shorter way would preserve readability.
>
> * The output with -z is unchanged for paths that do not involve renames.
> Existing scripts that do not pass -M/-C are not affected at all.
>
> * The output with -z for a renamed path is shown in a format that can
> easily be distinguished from an unrenamed path.
This changes invariant what we had, that output with and without -z differ
only in [filename] quoting and record separator. Now those two have
different semantic: --numstat without -z is for easier reading, --numstat
with -z is for machine consumption.
But as output with and without -z has to differ (in the form) already
for renames, why not...
[...]
> include::diff-generate-patch.txt[]
> +
> +
> +other diff formats
> +------------------
> +
> +The `--summary` option describes newly added, deleted, renamed and
> +copied files. The `--stat` option adds diffstat(1) graph to the
> +output. These options can be combined with other options, such as
> +`-p`, and are meant for human consumption.
> +
> +When showing a change that involves a rename or a copy, `--stat` output
> +formats the pathnames compactly by combining common prefix and suffix of
> +the pathnames. For example, a change that moves `arch/i386/Makefile` to
> +`arch/x86/Makefile` while modifying 4 lines will be shown like this:
Perhaps it could be added there word about "table-like format", and about
column widths (total width, filename [column] width).
> +
> +------------------------------------
> +arch/{i386 => x86}/Makefile | 4 +--
I would add there example of shortened filename there, for example
+.../SubmittingPatches | 2 +
Do I understand correctly that code first tries to strip directories,
and only if the filename is too long it does shorten filename?
By the way the combining common prefix and suffix (pprint_rename) doesn't
play well with quoting: when only one of the source and destination names
are quoted it wouldn't of course find any common prefix/suffix. I think
that if one of filenames has to be quoted, both should be.
And shortening of filenames together with either combining common prefix,
and/or with filename quoting produces output with might be a bit strange
for some. But I don't have idea how (and if) it could be corrected.
> +------------------------------------
> +
> +The `--numstat` option gives the diffstat(1) information but is designed
> +for easier machine consumption. An entry in `--numstat` output looks
> +like this:
> +
> +----------------------------------------
> +1 2 README
> +3 1 arch/{i386 => x86}/Makefile
> +----------------------------------------
Note that filename is not shortened in --numstat (as it can be in --stat).
> +
> +When `-z` output option is in effect, the output is formatted this way:
> +
> +----------------------------------------
> +1 2 README NUL
> +3 1 NUL arch/i386/Makefile NUL arch/x86/Makefile NUL
> +----------------------------------------
I wanted to say that it would make it harder on "line"-based parsers...
but I have realized that it would not, as one can simply read next two
"lines" (records) for pre-image and post-image filename if 0-length
filename is detected.
[...]
> +static void fill_print_name(struct diffstat_file *file)
Nice idea to separate this into function.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 3/3] New version of pre-commit hook
From: Wincent Colaiuta @ 2007-12-12 10:03 UTC (permalink / raw)
To: git; +Cc: gitster, Wincent Colaiuta
In-Reply-To: <1197453788-3097-3-git-send-email-win@wincent.com>
Now that "git diff --check" indicates problems with its exit code the
pre-commit hook becomes a trivial one-liner.
A side effect of this is that when "git diff --check" learns to detect
problems according to core.whitespace in the future, the hook's
behaviour will evolve to match without any changes required.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
templates/hooks--pre-commit | 67 ++++--------------------------------------
1 files changed, 7 insertions(+), 60 deletions(-)
diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit
index 7092bae..f8c7be7 100644
--- a/templates/hooks--pre-commit
+++ b/templates/hooks--pre-commit
@@ -7,64 +7,11 @@
#
# To enable this hook, make this file executable.
-# This is slightly modified from Andrew Morton's Perfect Patch.
-# Lines you introduce should not have trailing whitespace.
-# Also check for an indentation that has SP before a TAB.
+git-diff-index -M --cached --check HEAD -- && exit 0
-if git-rev-parse --verify HEAD 2>/dev/null
-then
- git-diff-index -p -M --cached HEAD --
-else
- # NEEDSWORK: we should produce a diff with an empty tree here
- # if we want to do the same verification for the initial import.
- :
-fi |
-perl -e '
- my $found_bad = 0;
- my $filename;
- my $reported_filename = "";
- my $lineno;
- sub bad_line {
- my ($why, $line) = @_;
- if (!$found_bad) {
- print STDERR "*\n";
- print STDERR "* You have some suspicious patch lines:\n";
- print STDERR "*\n";
- $found_bad = 1;
- }
- if ($reported_filename ne $filename) {
- print STDERR "* In $filename\n";
- $reported_filename = $filename;
- }
- print STDERR "* $why (line $lineno)\n";
- print STDERR "$filename:$lineno:$line\n";
- }
- while (<>) {
- if (m|^diff --git a/(.*) b/\1$|) {
- $filename = $1;
- next;
- }
- if (/^@@ -\S+ \+(\d+)/) {
- $lineno = $1 - 1;
- next;
- }
- if (/^ /) {
- $lineno++;
- next;
- }
- if (s/^\+//) {
- $lineno++;
- chomp;
- if (/\s$/) {
- bad_line("trailing whitespace", $_);
- }
- if (/^\s* \t/) {
- bad_line("indent SP followed by a TAB", $_);
- }
- if (/^(?:[<>=]){7}/) {
- bad_line("unresolved merge conflict", $_);
- }
- }
- }
- exit($found_bad);
-'
+cat >&2 <<EOF
+fatal: commit aborted due to whitespace problems
+specify --no-verify to bypass these checks and commit anyway
+EOF
+
+exit 1
--
1.5.3.7.1159.g2f071-dirty
^ permalink raw reply related
* [PATCH 2/3] "diff --check" should affect exit status
From: Wincent Colaiuta @ 2007-12-12 10:03 UTC (permalink / raw)
To: git; +Cc: gitster, Wincent Colaiuta
In-Reply-To: <1197453788-3097-2-git-send-email-win@wincent.com>
"git diff" has a --check option that can be used to check for whitespace
problems but it only reported by printing warnings to the
console.
Now when the --check option is used we give a non-zero exit status,
making "git diff --check" nicer to use in scripts and hooks.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
Documentation/diff-options.txt | 4 +-
builtin-diff-files.c | 2 +
builtin-diff-index.c | 2 +
builtin-diff-tree.c | 28 ++++----
builtin-diff.c | 3 +-
diff.c | 37 +++++++----
diff.h | 1 +
t/t4015-diff-whitespace.sh | 131 ++++++++++++++++++++++++++++++++++++++++
8 files changed, 179 insertions(+), 29 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 5d22b7b..9ecc1d7 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -93,7 +93,9 @@ endif::git-format-patch[]
--check::
Warn if changes introduce trailing whitespace
- or an indent that uses a space before a tab.
+ or an indent that uses a space before a tab. Exits with
+ non-zero status if problems are found. Not compatible with
+ --exit-code.
--full-index::
Instead of the first handful characters, show full
diff --git a/builtin-diff-files.c b/builtin-diff-files.c
index 046b7e3..4afc872 100644
--- a/builtin-diff-files.c
+++ b/builtin-diff-files.c
@@ -33,5 +33,7 @@ int cmd_diff_files(int argc, const char **argv, const char *prefix)
result = run_diff_files_cmd(&rev, argc, argv);
if (DIFF_OPT_TST(&rev.diffopt, EXIT_WITH_STATUS))
return DIFF_OPT_TST(&rev.diffopt, HAS_CHANGES) != 0;
+ if (rev.diffopt.output_format & DIFF_FORMAT_CHECKDIFF)
+ return DIFF_OPT_TST(&rev.diffopt, CHECK_FAILED) != 0;
return result;
}
diff --git a/builtin-diff-index.c b/builtin-diff-index.c
index 556c506..532b284 100644
--- a/builtin-diff-index.c
+++ b/builtin-diff-index.c
@@ -46,5 +46,7 @@ int cmd_diff_index(int argc, const char **argv, const char *prefix)
result = run_diff_index(&rev, cached);
if (DIFF_OPT_TST(&rev.diffopt, EXIT_WITH_STATUS))
return DIFF_OPT_TST(&rev.diffopt, HAS_CHANGES) != 0;
+ if (rev.diffopt.output_format & DIFF_FORMAT_CHECKDIFF)
+ return DIFF_OPT_TST(&rev.diffopt, CHECK_FAILED) != 0;
return result;
}
diff --git a/builtin-diff-tree.c b/builtin-diff-tree.c
index 2e13716..9ab90cb 100644
--- a/builtin-diff-tree.c
+++ b/builtin-diff-tree.c
@@ -117,23 +117,23 @@ int cmd_diff_tree(int argc, const char **argv, const char *prefix)
break;
}
- if (!read_stdin)
- return DIFF_OPT_TST(&opt->diffopt, EXIT_WITH_STATUS)
- && DIFF_OPT_TST(&opt->diffopt, HAS_CHANGES);
+ if (read_stdin) {
+ if (opt->diffopt.detect_rename)
+ opt->diffopt.setup |= (DIFF_SETUP_USE_SIZE_CACHE |
+ DIFF_SETUP_USE_CACHE);
+ while (fgets(line, sizeof(line), stdin)) {
+ unsigned char sha1[20];
- if (opt->diffopt.detect_rename)
- opt->diffopt.setup |= (DIFF_SETUP_USE_SIZE_CACHE |
- DIFF_SETUP_USE_CACHE);
- while (fgets(line, sizeof(line), stdin)) {
- unsigned char sha1[20];
-
- if (get_sha1_hex(line, sha1)) {
- fputs(line, stdout);
- fflush(stdout);
+ if (get_sha1_hex(line, sha1)) {
+ fputs(line, stdout);
+ fflush(stdout);
+ }
+ else
+ diff_tree_stdin(line);
}
- else
- diff_tree_stdin(line);
}
+ if (opt->diffopt.output_format & DIFF_FORMAT_CHECKDIFF)
+ return DIFF_OPT_TST(&opt->diffopt, CHECK_FAILED) != 0;
return DIFF_OPT_TST(&opt->diffopt, EXIT_WITH_STATUS)
&& DIFF_OPT_TST(&opt->diffopt, HAS_CHANGES);
}
diff --git a/builtin-diff.c b/builtin-diff.c
index 1b61599..6aeea93 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -365,7 +365,8 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
ent, ents);
if (DIFF_OPT_TST(&rev.diffopt, EXIT_WITH_STATUS))
result = DIFF_OPT_TST(&rev.diffopt, HAS_CHANGES) != 0;
-
+ if (rev.diffopt.output_format & DIFF_FORMAT_CHECKDIFF)
+ return DIFF_OPT_TST(&rev.diffopt, CHECK_FAILED) != 0;
if (1 < rev.diffopt.skip_stat_unmatch)
refresh_index_quietly();
return result;
diff --git a/diff.c b/diff.c
index e74a303..e89c7ce 100644
--- a/diff.c
+++ b/diff.c
@@ -996,6 +996,7 @@ struct checkdiff_t {
const char *filename;
int lineno, color_diff;
unsigned ws_rule;
+ int status;
};
static void checkdiff_consume(void *priv, char *line, unsigned long len)
@@ -1022,6 +1023,7 @@ static void checkdiff_consume(void *priv, char *line, unsigned long len)
white_space_at_end = 1;
if (space_before_tab || white_space_at_end) {
+ data->status = 1;
printf("%s:%d: %s", data->filename, data->lineno, ws);
if (space_before_tab) {
printf("space before tab");
@@ -1412,7 +1414,7 @@ static void builtin_diffstat(const char *name_a, const char *name_b,
diff_free_filespec_data(two);
}
-static void builtin_checkdiff(const char *name_a, const char *name_b,
+static int builtin_checkdiff(const char *name_a, const char *name_b,
struct diff_filespec *one,
struct diff_filespec *two, struct diff_options *o)
{
@@ -1420,7 +1422,7 @@ static void builtin_checkdiff(const char *name_a, const char *name_b,
struct checkdiff_t data;
if (!two)
- return;
+ return 0;
memset(&data, 0, sizeof(data));
data.xm.consume = checkdiff_consume;
@@ -1449,6 +1451,7 @@ static void builtin_checkdiff(const char *name_a, const char *name_b,
free_and_return:
diff_free_filespec_data(one);
diff_free_filespec_data(two);
+ return data.status;
}
struct diff_filespec *alloc_filespec(const char *path)
@@ -2033,14 +2036,14 @@ static void run_diffstat(struct diff_filepair *p, struct diff_options *o,
builtin_diffstat(name, other, p->one, p->two, diffstat, o, complete_rewrite);
}
-static void run_checkdiff(struct diff_filepair *p, struct diff_options *o)
+static int run_checkdiff(struct diff_filepair *p, struct diff_options *o)
{
const char *name;
const char *other;
if (DIFF_PAIR_UNMERGED(p)) {
/* unmerged */
- return;
+ return 0;
}
name = p->one->path;
@@ -2049,7 +2052,7 @@ static void run_checkdiff(struct diff_filepair *p, struct diff_options *o)
diff_fill_sha1_info(p->one);
diff_fill_sha1_info(p->two);
- builtin_checkdiff(name, other, p->one, p->two, o);
+ return builtin_checkdiff(name, other, p->one, p->two, o);
}
void diff_setup(struct diff_options *options)
@@ -2079,7 +2082,12 @@ int diff_setup_done(struct diff_options *options)
if (options->output_format & DIFF_FORMAT_NAME_STATUS)
count++;
if (options->output_format & DIFF_FORMAT_CHECKDIFF)
+ {
count++;
+ if (DIFF_OPT_TST(options, QUIET) ||
+ DIFF_OPT_TST(options, EXIT_WITH_STATUS))
+ die("--check may not be used with --quiet or --exit-code");
+ }
if (options->output_format & DIFF_FORMAT_NO_OUTPUT)
count++;
if (count > 1)
@@ -2546,17 +2554,17 @@ static void diff_flush_stat(struct diff_filepair *p, struct diff_options *o,
run_diffstat(p, o, diffstat);
}
-static void diff_flush_checkdiff(struct diff_filepair *p,
+static int diff_flush_checkdiff(struct diff_filepair *p,
struct diff_options *o)
{
if (diff_unmodified_pair(p))
- return;
+ return 0;
if ((DIFF_FILE_VALID(p->one) && S_ISDIR(p->one->mode)) ||
(DIFF_FILE_VALID(p->two) && S_ISDIR(p->two->mode)))
- return; /* no tree diffs in patch format */
+ return 0; /* no tree diffs in patch format */
- run_checkdiff(p, o);
+ return run_checkdiff(p, o);
}
int diff_queue_is_empty(void)
@@ -2675,16 +2683,19 @@ static int check_pair_status(struct diff_filepair *p)
}
}
-static void flush_one_pair(struct diff_filepair *p, struct diff_options *opt)
+static int flush_one_pair(struct diff_filepair *p, struct diff_options *opt)
{
int fmt = opt->output_format;
if (fmt & DIFF_FORMAT_CHECKDIFF)
- diff_flush_checkdiff(p, opt);
+ return diff_flush_checkdiff(p, opt);
else if (fmt & (DIFF_FORMAT_RAW | DIFF_FORMAT_NAME_STATUS))
diff_flush_raw(p, opt);
else if (fmt & DIFF_FORMAT_NAME)
write_name_quoted(p->two->path, stdout, opt->line_termination);
+
+ /* return value only matters with DIFF_FORMAT_CHECKDIFF */
+ return 0;
}
static void show_file_mode_name(const char *newdelete, struct diff_filespec *fs)
@@ -2923,8 +2934,8 @@ void diff_flush(struct diff_options *options)
DIFF_FORMAT_CHECKDIFF)) {
for (i = 0; i < q->nr; i++) {
struct diff_filepair *p = q->queue[i];
- if (check_pair_status(p))
- flush_one_pair(p, options);
+ if (check_pair_status(p) && flush_one_pair(p, options))
+ DIFF_OPT_SET(options, CHECK_FAILED);
}
separator++;
}
diff --git a/diff.h b/diff.h
index a52496a..5d50d93 100644
--- a/diff.h
+++ b/diff.h
@@ -59,6 +59,7 @@ typedef void (*diff_format_fn_t)(struct diff_queue_struct *q,
#define DIFF_OPT_ALLOW_EXTERNAL (1 << 13)
#define DIFF_OPT_EXIT_WITH_STATUS (1 << 14)
#define DIFF_OPT_REVERSE_DIFF (1 << 15)
+#define DIFF_OPT_CHECK_FAILED (1 << 16)
#define DIFF_OPT_TST(opts, flag) ((opts)->flags & DIFF_OPT_##flag)
#define DIFF_OPT_SET(opts, flag) ((opts)->flags |= DIFF_OPT_##flag)
#define DIFF_OPT_CLR(opts, flag) ((opts)->flags &= ~DIFF_OPT_##flag)
diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh
index 79fdff3..5aaf2db 100755
--- a/t/t4015-diff-whitespace.sh
+++ b/t/t4015-diff-whitespace.sh
@@ -117,4 +117,135 @@ EOF
git diff -b > out
test_expect_success 'another test, with -b' 'git diff expect out'
+test_expect_success 'check with no whitespace errors' '
+
+ git commit -m "snapshot" &&
+ echo "foo();" > x &&
+ git diff --check
+
+'
+
+test_expect_failure 'check with trailing whitespace' '
+
+ echo "foo(); " > x &&
+ git diff --check
+
+'
+
+test_expect_failure 'check with space before tab in indent' '
+
+ echo " foo();" > x &&
+ git diff --check
+
+'
+
+test_expect_failure '--check and --exit-code are exclusive' '
+
+ git checkout x &&
+ git diff --check --exit-code
+
+'
+
+test_expect_failure '--check and --quiet are exclusive' '
+
+ git diff --check --quiet
+
+'
+
+test_expect_success 'check staged with no whitespace errors' '
+
+ echo "foo();" > x &&
+ git add x &&
+ git diff --cached --check
+
+'
+
+test_expect_failure 'check staged with trailing whitespace' '
+
+ echo "foo(); " > x &&
+ git add x &&
+ git diff --cached --check
+
+'
+
+test_expect_failure 'check staged with space before tab in indent' '
+
+ echo " foo();" > x &&
+ git add x &&
+ git diff --cached --check
+
+'
+
+test_expect_success 'check with no whitespace errors (diff-index)' '
+
+ echo "foo();" > x &&
+ git add x &&
+ git diff-index --check HEAD
+
+'
+
+test_expect_failure 'check with trailing whitespace (diff-index)' '
+
+ echo "foo(); " > x &&
+ git add x &&
+ git diff-index --check HEAD
+
+'
+
+test_expect_failure 'check with space before tab in indent (diff-index)' '
+
+ echo " foo();" > x &&
+ git add x &&
+ git diff-index --check HEAD
+
+'
+
+test_expect_success 'check staged with no whitespace errors (diff-index)' '
+
+ echo "foo();" > x &&
+ git add x &&
+ git diff-index --cached --check HEAD
+
+'
+
+test_expect_failure 'check staged with trailing whitespace (diff-index)' '
+
+ echo "foo(); " > x &&
+ git add x &&
+ git diff-index --cached --check HEAD
+
+'
+
+test_expect_failure 'check staged with space before tab in indent (diff-index)' '
+
+ echo " foo();" > x &&
+ git add x &&
+ git diff-index --cached --check HEAD
+
+'
+
+test_expect_success 'check with no whitespace errors (diff-tree)' '
+
+ echo "foo();" > x &&
+ git commit -m "new commit" x &&
+ git diff-tree --check HEAD^ HEAD
+
+'
+
+test_expect_failure 'check with trailing whitespace (diff-tree)' '
+
+ echo "foo(); " > x &&
+ git commit -m "another commit" x &&
+ git diff-tree --check HEAD^ HEAD
+
+'
+
+test_expect_failure 'check with space before tab in indent (diff-tree)' '
+
+ echo " foo();" > x &&
+ git commit -m "yet another" x &&
+ git diff-tree --check HEAD^ HEAD
+
+'
+
test_done
--
1.5.3.7.1159.g2f071-dirty
^ permalink raw reply related
* [PATCH 1/3] Use "whitespace" consistently
From: Wincent Colaiuta @ 2007-12-12 10:03 UTC (permalink / raw)
To: git; +Cc: gitster, Wincent Colaiuta
In-Reply-To: <1197453788-3097-1-git-send-email-win@wincent.com>
For consistency, change "white space" and "whitespaces" to
"whitespace", fixing a couple of adjacent grammar problems in the
docs.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
Documentation/diff-options.txt | 12 ++++++------
Documentation/glossary.txt | 2 +-
diff.c | 4 ++--
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index d0154bb..5d22b7b 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -175,19 +175,19 @@ endif::git-format-patch[]
Shorthand for "--text".
--ignore-space-at-eol::
- Ignore changes in white spaces at EOL.
+ Ignore changes in whitespace at EOL.
--ignore-space-change::
- Ignore changes in amount of white space. This ignores white
- space at line end, and consider all other sequences of one or
- more white space characters to be equivalent.
+ Ignore changes in amount of whitespace. This ignores whitespace
+ at line end, and considers all other sequences of one or
+ more whitespace characters to be equivalent.
-b::
Shorthand for "--ignore-space-change".
--ignore-all-space::
- Ignore white space when comparing lines. This ignores
- difference even if one line has white space where the other
+ Ignore whitespace when comparing lines. This ignores
+ differences even if one line has whitespace where the other
line has none.
-w::
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index fc18744..f9f5a32 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -245,7 +245,7 @@ This commit is referred to as a "merge commit", or sometimes just a
of the object's contents using the Secure Hash Algorithm
1 and usually represented by the 40 character hexadecimal encoding of
the <<def_hash,hash>> of the object (possibly followed by
- a white space).
+ whitespace).
[[def_object_type]]object type::
One of the identifiers
diff --git a/diff.c b/diff.c
index f780e3e..e74a303 100644
--- a/diff.c
+++ b/diff.c
@@ -1015,7 +1015,7 @@ static void checkdiff_consume(void *priv, char *line, unsigned long len)
if (line[i - 1] == '\t' && spaces)
space_before_tab = 1;
- /* check white space at line end */
+ /* check whitespace at line end */
if (line[len - 1] == '\n')
len--;
if (isspace(line[len - 1]))
@@ -1029,7 +1029,7 @@ static void checkdiff_consume(void *priv, char *line, unsigned long len)
putchar(',');
}
if (white_space_at_end)
- printf("white space at end");
+ printf("whitespace at end");
printf(":%s ", reset);
emit_line_with_ws(1, set, reset, ws, line, len,
data->ws_rule);
--
1.5.3.7.1159.g2f071-dirty
^ permalink raw reply related
* [RFC PATCH 0/3 UPDATED] diff --check enhancements
From: Wincent Colaiuta @ 2007-12-12 10:03 UTC (permalink / raw)
To: git; +Cc: gitster
[1/3] Use "whitespace" consistently
Same.
[2/3] "diff --check" should affect exit status
Additional tests added, and one correction (git diff-tree was only
setting the exit status if the --stdin option was passed).
[3/3] New version of pre-commit hook
A demonstration of the benefit of [2/3]; the pre-commit hook
effectively becomes a one-liner.
^ permalink raw reply
* Re: [PATCH 2/2] "diff --check" should affect exit status
From: Wincent Colaiuta @ 2007-12-12 9:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmysg8e8r.fsf@gitster.siamese.dyndns.org>
El 12/12/2007, a las 10:16, Junio C Hamano escribió:
> Wincent Colaiuta <win@wincent.com> writes:
>
>> "git diff" has a --check option that can be used to check for
>> whitespace
>> problems but it only reported by printing warnings to the
>> console.
>
> The primary use of this option used to be to see where the breakages
> are
> in order to fix them up (IOW, the option was not about seeing if
> breakage exists or not), but that is much easier with --color output
> these days.
>
> It is probably a good idea to do this, although I do not care much
> about
> it either way. It probably could replace the sample pre-commit hook
> currently implemented in Perl.
Actually, that's exactly why I prepared this patch; I was looking at
the pre-commit hook and though, surely there must be a simpler way
than this... And was surprised when I saw that "git diff --check"
didn't alter the exit code...
> As I happen to be fairly familiar with
> the area, I'll take a look at the patch if/when I find time.
Thanks. I'm about to resend this patch with more tests, and one fix
discovered while adding the tests ("git diff-tree" was only setting
the exit status with --stdin set), as well as a new version of the pre-
commit hook.
One nice thing about this change is that when "diff --check" learns
about the new core.whitespace stuff, the hook will automatically
inherit the new behaviour.
Cheers,
Wincent
^ permalink raw reply
* What to do if git-cvsimport/cvsps hangs?
From: Florian Weimer @ 2007-12-12 9:30 UTC (permalink / raw)
To: git
This is probably more of a cvsps question than a GIT question, but
AFAICT, the cvsps upstream is mostly inactive these days.
I tried to import the PostgreSQL repository, using
git-cvsimport -d :pserver:anoncvs@anoncvs.postgresql.org:/projects/cvsroot -k -C pgsql pgsql
However, after a bit of activity, git-cvsimport hangs at the following
line
cvs rlog: Logging pgsql/src/win32
strace doesn't show any system call activtiy in the cvsps process
(which consumes 100% CPU). cvsps is Debian's 2.1-2 version.
Is there some kind of replacement for cvsps which works more reliably?
--
Florian Weimer <fweimer@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
^ permalink raw reply
* Re: git-bisect run make -j64 kernel/ (was Re: git-bisect feature suggestion: "git-bisect diff")
From: Ingo Molnar @ 2007-12-12 9:43 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Junio C Hamano
In-Reply-To: <200712090633.36086.chriscool@tuxfamily.org>
* Christian Couder <chriscool@tuxfamily.org> wrote:
> Le samedi 8 décembre 2007, Ingo Molnar a écrit :
> > Currently, in the Linux kernel, if i do this:
> >
> > $ git-bisect run make -j64 kernel/
> >
> > it fails with:
> >
> > running make -j64 kernel/
> > CHK include/linux/version.h
> > CHK include/linux/utsrelease.h
> > CALL scripts/checksyscalls.sh
> > bisect run failed:
> > bisect_good exited with error code 1
> >
> > although the command "make -j64 kernel/" returns with 0.
> >
> > i have to write a script around "make -j64 kernel/" to get this to work
> > - it would be nice to have this "out of box".
>
> It seems to work for me. After creating a .config, I did:
>
> $ git bisect good v2.6.23
> $ git bisect bad HEAD
> $ git bisect run make -j64 kernel/
>
> Then I had to answer some configuration questions (I hit <enter> everytime)
> but it run fine.
>
> My git version is:
>
> git version 1.5.3.7.2200.g9275-dirty
i've got: git-core-1.5.3.6-1.fc8, so it's fairly recent. I'll try this
later and come back to you if there's still a problem.
Ingo
^ permalink raw reply
* Re: Invalid dates in git log
From: Junio C Hamano @ 2007-12-12 9:35 UTC (permalink / raw)
To: Jeff King; +Cc: Eirik Bjørsnøs, git
In-Reply-To: <20071212092304.GA20799@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Dec 12, 2007 at 10:11:12AM +0100, Eirik Bjørsnøs wrote:
>
>> My questions are:
>>
>> 1) Is this a problem in the Git software?
>
> No. Whoever made the commit probably just didn't have their clock set
> right. Git doesn't generally care about the timestamp for its
> operations; it just records it as a historical note.
"git show -s" with --pretty=fuller and --pretty=raw on these two
commiits reveal:
Author: Ursula Braun <braunu@de.ibm.com>
AuthorDate: Thu Jan 1 01:00:01 1970 +0100
Commit: Jeff Garzik <jeff@garzik.org>
CommitDate: Fri Oct 19 23:00:02 2007 -0400
author Ursula Braun <braunu@de.ibm.com> 1 +0100
committer Jeff Garzik <jeff@garzik.org> 1192849202 -0400
Author: Len Brown <len.brown@intel.com>
AuthorDate: Fri Apr 5 00:07:45 2019 -0500
Commit: Len Brown <len.brown@intel.com>
CommitDate: Tue Jul 12 00:12:09 2005 -0400
author Len Brown <len.brown@intel.com> 1554440865 -0500
committer Len Brown <len.brown@intel.com> 1121141529 -0400
So the former commit was made while seting GIT_AUTHOR_DATE explicitly to
1, which is quite likely a bug in some script Jeff used to create this
commit about two months ago.
I have no idea about the latter, though. It looks like quite a random
timestamp, and committer timestamp look reasonable, relative to the
other commits around it.
For a short while, between Nov 11th to Dec 8th this year on 'next' (and
between Dec 4th and Dec 8th on 'master'), git-commit-tree accepted an
empty GIT_AUTHOR_DATE and recorded a bogus "0" time in the commit by
mistake, but such a commit would have shown something like:
author A U Thor <au.thor@example.com>
without any timestamp, and both commits predate the gotcha, so I do not
think they are caused by that recent breakage.
^ permalink raw reply
* Re: git-cvsexportcommit fails for huge commits
From: Jeff King @ 2007-12-12 9:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Markus Klinik, git
In-Reply-To: <7vir348e0l.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 12, 2007 at 01:21:14AM -0800, Junio C Hamano wrote:
> > +sub xargs_safe_pipe_capture {
> > + my $MAX_ARG_LENGTH = 1024;
> > + my $cmd = shift;
> > + my @output;
> > + while(@_) {
> > + my @args;
> > + my $length = 0;
> > + while(@_ && $length < $MAX_ARG_LENGTH) {
> > + push @args, shift;
> > + $length += length($args[$#args]);
> > + }
> > + push @output, safe_pipe_capture(@$cmd, @args);
> > + }
> > + return @output;
> > +}
> > +
>
> Makes me wonder why you are not spawning xargs by doing it by hand. If
Because we are reading the output, and it is possible to get a pipe
deadlock. This could be avoided with a tempfile.
> the path at the beginning happens to be longer than 1024 then you will
> run path-less "cvs status"?
No, read the loop again. The length starts at 0, so we always go through
the loop body once.
-Peff
^ permalink raw reply
* Re: Invalid dates in git log
From: Jeff King @ 2007-12-12 9:23 UTC (permalink / raw)
To: Eirik Bjørsnøs; +Cc: git
In-Reply-To: <34660cca0712120111k3f11769fk1a8cefda3b82683e@mail.gmail.com>
On Wed, Dec 12, 2007 at 10:11:12AM +0100, Eirik Bjørsnøs wrote:
> My questions are:
>
> 1) Is this a problem in the Git software?
No. Whoever made the commit probably just didn't have their clock set
right. Git doesn't generally care about the timestamp for its
operations; it just records it as a historical note.
> 2) Or is it a data corruption issue in the repository?
No. You can check for corruption with git-fsck, but these commits were
actually created with bad dates.
> 3) Can it be fixed and should I contact anyone to get it fixed?
Changing the date will change the commit id (since the id is the sha1 of
the commit contents). Which would mean rewriting all of the history that
follows it. You could do it in your own repository, but then you might
have some trouble merging with Linus later on. Linus could do it, but I
doubt he will think it is worth the trouble.
> $ git log a27ac38efd6dc6dccebfc9bcc475ab4aa5fc4a56 -1
> commit a27ac38efd6dc6dccebfc9bcc475ab4aa5fc4a56
> Author: Len Brown <len.brown@intel.com>
> Date: Fri Apr 5 00:07:45 2019 -0500
Your best guess is probably the committer information. Try this:
git log a27ac38 -1 --pretty=format:'Author: %an %ad%nCommitter: %cn %cd'
-Peff
^ permalink raw reply
* Re: git-cvsexportcommit fails for huge commits
From: Junio C Hamano @ 2007-12-12 9:21 UTC (permalink / raw)
To: Jeff King; +Cc: Markus Klinik, git
In-Reply-To: <20071212083154.GB7676@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> @@ -335,6 +335,22 @@ sub safe_pipe_capture {
> return wantarray ? @output : join('',@output);
> }
>
> +sub xargs_safe_pipe_capture {
> + my $MAX_ARG_LENGTH = 1024;
> + my $cmd = shift;
> + my @output;
> + while(@_) {
> + my @args;
> + my $length = 0;
> + while(@_ && $length < $MAX_ARG_LENGTH) {
> + push @args, shift;
> + $length += length($args[$#args]);
> + }
> + push @output, safe_pipe_capture(@$cmd, @args);
> + }
> + return @output;
> +}
> +
Makes me wonder why you are not spawning xargs by doing it by hand. If
the path at the beginning happens to be longer than 1024 then you will
run path-less "cvs status"?
^ permalink raw reply
* git gui blame utf-8 bugs
From: Finn Arne Gangstad @ 2007-12-12 9:17 UTC (permalink / raw)
To: git, spearce
git gui has some utf-8 bugs:
If you do git gui blame <file>, and the file contains utf-8 text,
the lines are not parsed as utf-8, but seemingly as iso-8859-1 instead.
Also, the hovering comment is INITIALLY shown garbled (both Author and
commit message), but if you click on a line, so that the commit
message is shown in the bottom window, the hovering message is
magically corrected to utf-8.
The text in the lower window (showing specific commits) seems to
always be handled correctly.
To reproduce: Set your author name to include some utf-8 tokens, add a
line with some utf-8 tokens to a file, commit it with a commit message
including some utf-8 tokens, and do git gui blame on the file. The
line will be garbled in the top window, and the hovering message will
be garbled until you click on the line.
Verified with git-gui.git master
- Finn Arne
^ permalink raw reply
* Re: [PATCH 2/2] "diff --check" should affect exit status
From: Junio C Hamano @ 2007-12-12 9:16 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <1197447122-93416-3-git-send-email-win@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> "git diff" has a --check option that can be used to check for whitespace
> problems but it only reported by printing warnings to the
> console.
The primary use of this option used to be to see where the breakages are
in order to fix them up (IOW, the option was not about seeing if
breakage exists or not), but that is much easier with --color output
these days.
It is probably a good idea to do this, although I do not care much about
it either way. It probably could replace the sample pre-commit hook
currently implemented in Perl. As I happen to be fairly familiar with
the area, I'll take a look at the patch if/when I find time.
Thanks.
^ permalink raw reply
* Invalid dates in git log
From: Eirik Bjørsnøs @ 2007-12-12 9:11 UTC (permalink / raw)
To: git
Hi there,
I'm experiencing a date issue with certain commits in Git in Linus's
2.6 kernel repository.
One commit has a date from 2019, while another commit has a date from
1970. Although Git has been around for a while and seeing a Linux
commit from 2019 would be cool, I think there's something wrong here.
My questions are:
1) Is this a problem in the Git software?
2) Or is it a data corruption issue in the repository?
3) Can it be fixed and should I contact anyone to get it fixed?
I'm doing some log analysis and these two dates mess up my charts.
Steps to reproduce:
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
$ git log a27ac38efd6dc6dccebfc9bcc475ab4aa5fc4a56 -1
commit a27ac38efd6dc6dccebfc9bcc475ab4aa5fc4a56
Author: Len Brown <len.brown@intel.com>
Date: Fri Apr 5 00:07:45 2019 -0500
[ACPI] fix merge error that broke CONFIG_ACPI_DEBUG=y build
Signed-off-by: Len Brown <len.brown@intel.com>
$ git log 224426f168aa4af3dcb628e6edaa824d32d60e6f -1
commit 224426f168aa4af3dcb628e6edaa824d32d60e6f
Author: Ursula Braun <braunu@de.ibm.com>
Date: Thu Jan 1 01:00:01 1970 +0100
qeth: remove header_ops bug
Remove qeth bug caused by commit:
[NET]: Move hardware header operations out of netdevice.
Signed-off-by: Ursula Braun <braunu@de.ibm.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Thanks,
Eirik.
^ permalink raw reply
* Re: [PATCH 1/2] git-help: add "help.format" config variable.
From: Junio C Hamano @ 2007-12-12 9:04 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <20071212063320.3cbb1698.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> diff --git a/git.c b/git.c
> index 4f9876e..d46b63d 100644
> --- a/git.c
> +++ b/git.c
> @@ -324,7 +324,7 @@ static void handle_internal_command(int argc, const char **argv)
> { "gc", cmd_gc, RUN_SETUP },
> { "get-tar-commit-id", cmd_get_tar_commit_id },
> { "grep", cmd_grep, RUN_SETUP | USE_PAGER },
> - { "help", cmd_help },
> + { "help", cmd_help, RUN_SETUP },
> #ifndef NO_CURL
> { "http-fetch", cmd_http_fetch, RUN_SETUP },
> #endif
It would be _NICE_ if we read configuration when we are in a git
repository, but I am afraid this change is unnice -- the users used to
be able to say "git help" from anywhere didn't they? Now they will get
"Not a git repository". It needs to do an optional repository
discovery, not a mandatory one RUN_SETUP causes.
^ 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