* Re: git diff/log --check exitcode and PAGER environment variable
From: Junio C Hamano @ 2008-08-08 9:44 UTC (permalink / raw)
To: Peter Valdemar Mørch (Lists); +Cc: git
In-Reply-To: <489C145B.5090400@sneakemail.com>
"Peter Valdemar Mørch (Lists)" <4ux6as402@sneakemail.com> writes:
> There is this old thread:
> "[PATCH 1/5] "diff --check" should affect exit status"
> http://thread.gmane.org/gmane.comp.version-control.git/68145/focus=68148
> which seemed not to reach a conclusion.
Conclusion was (1) if you really care about the exit code, do not use
pager; (2) after 1.6.0 we will swap the child/parent between git and pager
to expose exit code from us, but not before.
Or am I mistaken?
^ permalink raw reply
* Re: git diff/log --check exitcode and PAGER environment variable
From: "Peter Valdemar Mørch (Lists)" @ 2008-08-08 10:04 UTC (permalink / raw)
Cc: git
In-Reply-To: <7vfxpfet8a.fsf@gitster.siamese.dyndns.org>
Junio C Hamano gitster-at-pobox.com |Lists| wrote:
>> There is this old thread:
>> "[PATCH 1/5] "diff --check" should affect exit status"
>> http://thread.gmane.org/gmane.comp.version-control.git/68145/focus=68148
>> which seemed not to reach a conclusion.
>
> Conclusion was (1) if you really care about the exit code, do not use
> pager; (2) after 1.6.0 we will swap the child/parent between git and pager
> to expose exit code from us, but not before.
>
> Or am I mistaken?
Perhaps a more correct statement on my part would have been that I
couldn't find the conclusion. :-)
It ended with Junio C Hamano saying:
> Heh, I am about to push out fixed-up results, so it might save both of
> us some time if you looked at it first and then complained on my
> screwups.
I wasn't subscribed to the list back then and couldn't follow beyond
that thread in GMane.
Regardless of what happened or not back then, the current documentation
does not match the current code. Not for git-diff, and certainly not for
git-log.
Or am I mistaken?
I didn't see a reference in that thread to post 1.6.0 changes or to
child/parent relationships, but if this is known and planned for
post-1.6.0, then cool: I'll get on with my life and let you get on with
yours!
Peter
--
Peter Valdemar Mørch
http://www.morch.com
^ permalink raw reply
* Re* git diff/log --check exitcode and PAGER environment variable
From: Junio C Hamano @ 2008-08-08 10:15 UTC (permalink / raw)
To: git; +Cc: Peter Valdemar Mørch (Lists)
In-Reply-To: <7vfxpfet8a.fsf@gitster.siamese.dyndns.org>
As this is not limited to diff command at all, let's do this instead.
-- >8 --
Document use of pager means you will see exit code from the pager
Whenever we run pager (either a subcommand that implies use of pager by
default, or by explicit request with "git -p cmd"), the main git process
becomes the upstream of the pipe that feed the pager, and the exit code
from the command as a whole comes from the pager. Long time users may
have already got used to this without being documented, but it should be
documented.
We may be swapping the process ordering in the future so that the exit
code from the main git process is always exposed, and at that point this
comment should be removed.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git.txt | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index b1cb972..d6ca400 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -150,7 +150,9 @@ help ...`.
-p::
--paginate::
- Pipe all output into 'less' (or if set, $PAGER).
+ Pipe all output into 'less' (or if set, $PAGER). Note that this
+ implies that the exit code you see from the command will be that
+ of the pager, not git.
--no-pager::
Do not pipe git output into a pager.
^ permalink raw reply related
* Re: [PATCH 3/3] Enable parallel tests
From: Johannes Schindelin @ 2008-08-08 10:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvdycf17a.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 7 Aug 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Parallel mode also triggers removal of the trash directory in the test
> > itself if everything went fine, so that the trash directories do not
> > pile up only to be removed at the very end.
>
> I think making the tests remove their own mess makes sense regardless.
When I add tests, I first run the appropriate t/t*.sh, then expect what is
in trash directory, then extend the test. So at least I need an option to
keep the directory.
> > clean:
> > - $(RM) -r 'trash directory' test-results
> > + $(RM) -rf 'trash directory' test-results
>
> This is not needed, I think, as RM is defined with -f already.
Okay, thanks.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] tests: use $TEST_DIRECTORY to refer to the t/ directory
From: Johannes Schindelin @ 2008-08-08 10:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, git
In-Reply-To: <7vod43etuw.fsf_-_@gitster.siamese.dyndns.org>
Hi,
On Fri, 8 Aug 2008, Junio C Hamano wrote:
> | # Test repository
> | -test="trash directory"
> | +test="trash directory/another level/yet another"
Oh my. If you continue like that, we are soon going to hit PATH_MAX on
some systems (*cough* Windows *cough*), badly.
> t/t0022-crlf-rename.sh | 4 ++--
> t/t1000-read-tree-m-3way.sh | 2 +-
> t/t3900-i18n-commit.sh | 18 +++++++++---------
> t/t3901-i18n-patch.sh | 28 ++++++++++++++--------------
> t/t4000-diff-format.sh | 2 +-
> t/t4001-diff-rename.sh | 2 +-
> t/t4002-diff-basic.sh | 2 +-
> t/t4003-diff-rename-1.sh | 6 +++---
> t/t4004-diff-rename-symlink.sh | 2 +-
> t/t4005-diff-rename-2.sh | 6 +++---
> t/t4007-rename-3.sh | 4 ++--
> t/t4008-diff-break-rewrite.sh | 6 +++---
> t/t4009-diff-rename-4.sh | 6 +++---
> t/t4010-diff-pathspec.sh | 2 +-
> t/t4011-diff-symlink.sh | 2 +-
> t/t4012-diff-binary.sh | 2 +-
> t/t4013-diff-various.sh | 2 +-
> t/t4015-diff-whitespace.sh | 2 +-
> t/t4020-diff-external.sh | 2 +-
> t/t4022-diff-rewrite.sh | 4 ++--
> t/t4023-diff-rename-typechange.sh | 14 +++++++-------
> t/t4027-diff-submodule.sh | 2 +-
> t/t4100-apply-stat.sh | 4 ++--
> t/t4101-apply-nonl.sh | 2 +-
> t/t5100-mailinfo.sh | 18 +++++++++---------
> t/t5515-fetch-merge-logic.sh | 4 ++--
> t/t5540-http-push.sh | 2 +-
> t/t6002-rev-list-bisect.sh | 2 +-
> t/t6003-rev-list-topo-order.sh | 2 +-
> t/t6023-merge-file.sh | 2 +-
> t/t6027-merge-binary.sh | 2 +-
> t/t6101-rev-parse-parents.sh | 2 +-
> t/t6200-fmt-merge-msg.sh | 4 ++--
> t/t7001-mv.sh | 4 ++--
> t/t7004-tag.sh | 2 +-
> t/t7101-reset.sh | 10 +++++-----
> t/t7500-commit.sh | 16 ++++++++--------
> t/t8001-annotate.sh | 2 +-
> t/t8002-blame.sh | 2 +-
> t/t9110-git-svn-use-svm-props.sh | 2 +-
> t/t9111-git-svn-use-svnsync-props.sh | 2 +-
> t/t9115-git-svn-dcommit-funky-renames.sh | 2 +-
> t/t9121-git-svn-fetch-renamed-dir.sh | 2 +-
> t/t9200-git-cvsexportcommit.sh | 14 +++++++-------
> t/t9300-fast-import.sh | 2 +-
> t/t9301-fast-export.sh | 2 +-
> t/t9500-gitweb-standalone-no-errors.sh | 16 ++++++++--------
> t/t9700-perl-git.sh | 2 +-
> t/t9700/test.pl | 3 ---
> t/test-lib.sh | 2 +-
> 50 files changed, 123 insertions(+), 126 deletions(-)
Frankly, I do not have the time. It is not only about looking what you
changed, but also what you did not change.
Besides, I do not see the point. "clean" can just as well
$(RM) -r 'trash directory.t'[0-9]*
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] Enable parallel tests
From: Johannes Schindelin @ 2008-08-08 10:37 UTC (permalink / raw)
To: René Scharfe; +Cc: git, gitster
In-Reply-To: <489BF95F.1070000@lsrfire.ath.cx>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1000 bytes --]
Hi,
On Fri, 8 Aug 2008, René Scharfe wrote:
> Johannes Schindelin schrieb:
>
> > This commit does so, by inspecting the MAKEFLAGS variable to detect if
> > the option "-j" or "--jobs" was passed to make. In that case, the
> > test is run with the new "--parallel" option.
>
> How about making the test harness be able to run multiple tests in
> parallel by default, i.e. always use a different trash directory name
> for each test, without adding the new option? The implementation would
> be a bit simpler (no -j detection needed) and the documentation would be
> simpler, too.
I am totally opposed to dropping the -j detection. This is what cost me 3
hours to research/implement. *sighs*
> > *)
> > break ;;
> > esac
> > @@ -449,6 +454,11 @@ test_done () {
> > # we will leave things as they are.
> >
> > say_color pass "passed all $msg"
> > +
> > + test ! -z = "$remove_trash" &&
>
> This test succeeds always, because = is not an empty string.
Thanks.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] Enable parallel tests
From: Junio C Hamano @ 2008-08-08 10:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0808081225000.9611@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Thu, 7 Aug 2008, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > Parallel mode also triggers removal of the trash directory in the test
>> > itself if everything went fine, so that the trash directories do not
>> > pile up only to be removed at the very end.
>>
>> I think making the tests remove their own mess makes sense regardless.
>
> When I add tests, I first run the appropriate t/t*.sh, then expect what is
> in trash directory, then extend the test. So at least I need an option to
> keep the directory.
That's easy. I do the same as you but do so by disabling "test_done" ;-)
^ permalink raw reply
* Re: [PATCH] Documentation: commit-tree: remove 16 parents restriction
From: Johannes Schindelin @ 2008-08-08 10:38 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, gitster
In-Reply-To: <1218181975-12093-1-git-send-email-trast@student.ethz.ch>
Hi,
On Fri, 8 Aug 2008, Thomas Rast wrote:
> ef98c5ca lifted the 16 parents restriction in builtin-commit-tree.c,
> but forgot to update the documentation.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
> Documentation/git-commit-tree.txt | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt
> index feec584..92ab3ab 100644
> --- a/Documentation/git-commit-tree.txt
> +++ b/Documentation/git-commit-tree.txt
> @@ -16,12 +16,12 @@ This is usually not what an end user wants to run directly. See
> linkgit:git-commit[1] instead.
>
> Creates a new commit object based on the provided tree object and
> -emits the new commit object id on stdout. If no parent is given then
> -it is considered to be an initial tree.
> +emits the new commit object id on stdout.
Oops.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] tests: use $TEST_DIRECTORY to refer to the t/ directory
From: Junio C Hamano @ 2008-08-08 10:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: René Scharfe, git
In-Reply-To: <alpine.DEB.1.00.0808081232210.9611@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Frankly, I do not have the time. It is not only about looking what you
> changed, but also what you did not change.
That's Ok. You are not (and you shouldn't be) the only person who is
capable of reviewing and helping the development process ;-)
Hint, hint...
^ permalink raw reply
* Re: Re* git diff/log --check exitcode and PAGER environment variable
From: "Peter Valdemar Mørch (Lists)" @ 2008-08-08 11:02 UTC (permalink / raw)
To: git
In-Reply-To: <7v1w0zersg.fsf_-_@gitster.siamese.dyndns.org>
Junio C Hamano gitster-at-pobox.com |Lists| wrote:
> --paginate::
> - Pipe all output into 'less' (or if set, $PAGER).
> + Pipe all output into 'less' (or if set, $PAGER). Note that this
> + implies that the exit code you see from the command will be that
> + of the pager, not git.
Thank you for the attention, Junio.
I don't want to be a troll... But in my original post, I write that git
log exits with 0 even when there are --check failures *and* --no-pager
is used.
$ PAGER=cat git --no-pager log HEAD~20..HEAD --check --exit-code
$ echo $?
0
Here I don't think the pager is involved, and so perhaps this is an
unrelated issue.
Since the pager/exit code issue is going to be looked at post 1.6.0
herhaps this is low-priority: Nowhere in man git-diff does it mention
the pager or less or that git-diff by default behaves as if
-p/--paginate from "man git" had been given. I personally would not have
thought to look there or caught the connection. But perhaps I'm
bikeshedding.
If I'm percieved as trolling: Please let me know. This documentation
string took time out of my day. (Less, though than this thread has! :D)
Peter
--
Peter Valdemar Mørch
http://www.morch.com
^ permalink raw reply
* [PATCH 3/3 v2] Enable parallel tests
From: Johannes Schindelin @ 2008-08-08 11:08 UTC (permalink / raw)
To: René Scharfe; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0808081236010.9611@pacific.mpi-cbg.de.mpi-cbg.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2143 bytes --]
On multiprocessor machines, or with I/O heavy tests (that leave the
CPU waiting a lot), it makes sense to parallelize the tests.
However, care has to be taken that the different jobs use different
trash directories.
This commit does so, by creating the trash directories with a suffix
that is unique with regard to the test, as it is the test's base name.
Further, the trash directory is removed in the test itself if
everything went fine, so that the trash directories do not
pile up only to be removed at the very end.
If a test failed, the trash directory is not removed. Chances are
that the exact error message is lost in the clutter, but you can still
see what test failed from the name of the trash directory, and repeat
the test (without -j).
If all was good, you will see the aggregated results.
Suggestions to simplify this commit came from Junio and René.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
> On Fri, 8 Aug 2008, René Scharfe wrote:
>
> > The implementation would be a bit simpler (no -j detection
> > needed) and the documentation would be simpler, too.
Oh well, here it goes.
t/Makefile | 1 -
t/test-lib.sh | 8 +++++++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/t/Makefile b/t/Makefile
index aa952e1..ed49c20 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -39,4 +39,3 @@ full-svn-test:
$(MAKE) $(TSVN) GIT_SVN_NO_OPTIMIZE_COMMITS=0 LC_ALL=en_US.UTF-8
.PHONY: pre-clean $(T) aggregate-results clean
-.NOTPARALLEL:
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 11c0275..75c8a36 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -449,6 +449,11 @@ test_done () {
# we will leave things as they are.
say_color pass "passed all $msg"
+
+ test ! -z "$remove_trash" &&
+ cd "$(dirname "$remove_trash")" &&
+ rm -rf "$(basename "$remove_trash")"
+
exit 0 ;;
*)
@@ -485,7 +490,8 @@ fi
. ../GIT-BUILD-OPTIONS
# Test repository
-test="trash directory"
+test="trash directory.$(basename "$0" .sh)"
+remove_trash="$(pwd)/$test"
rm -fr "$test" || {
trap - exit
echo >&5 "FATAL: Cannot prepare test area"
--
1.6.0.rc2.23.gd08e9
^ permalink raw reply related
* Re: Re* git diff/log --check exitcode and PAGER environment variable
From: Johannes Schindelin @ 2008-08-08 11:23 UTC (permalink / raw)
To: Peter Valdemar Mørch (Lists); +Cc: git
In-Reply-To: <489C27DD.90603@sneakemail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1107 bytes --]
Hi,
On Fri, 8 Aug 2008, "Peter Valdemar Mørch (Lists)" wrote:
> I don't want to be a troll... But in my original post, I write that git
> log exits with 0 even when there are --check failures *and* --no-pager
> is used.
You seem to care enough. That is good. Because I will give you a few
pointers to help yourself, and you can in return help us by submitting a
patch:
- the code to be changed lives in log-tree.c. Look for calls to the
function log_tree_diff_flush(). You need to check the exit status
after that (needs to be done only when DIFF_OPT_TST(opt->diffopt,
EXIT_WITH_STATUS).
- you can get at the exit status with the call
diff_result_code(opt->diffopt, 0) (see the implementation in diff.c to
find out what the 0 means, and why it is correct).
- you need to accumulate the exit status (plural, with a long u) over all
calls to log_tree_diff(), best thing would be to add a member to the
log_info struct.
- you need to test rev->loginfo->exit_code in the end, and return failure
if it is non-zero. I think the place is in cmd_log_walk().
Bon chance,
Dscho
^ permalink raw reply
* Re: git filter-branch --subdirectory-filter, still a mistery
From: Jan Wielemaker @ 2008-08-08 11:25 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200808080148.27384.trast@student.ethz.ch>
Hi Thomas,
On Friday 08 August 2008 01:48:05 Thomas Rast wrote:
> This appears to be a bug. I've whipped up a patch that will follow
> and should fix the bug. It has nothing to do with packed-refs; the
> current filter-branch chokes on annotated tags during
> --subdirectory-filter, even though there is support for tag rewriting.
>
> However, to enable tag rewriting, you need to say --tag-name-filter
> cat.
That works!
> > Now it runs to the end. Unfortunagtely the history is completely
> > screwed up :-(:
> >
> > * There are a lot of commits that are not related to the dir
> > * Commits start long before the directory came into existence,
> > Looks like it just shows the whole project at this place.
>
> For some reason the ancestor detection does not work right. I'm also
> following up with an RFH patch that significantly improves the success
> rate (in terms of branches and tags successfully mapped to a rewritten
> commit) in the case of your repository. I doubt more staring at the
> code would yield any more ideas at this hour, so ideas would be
> appreciated.
>
> The rest is just the other commits/tags showing a lot of the history.
> I don't know of any built-in way to prune the branches and tags that
> aren't part of the new master, but
>
> git branch -a --no-merged master
>
> can tell you which branches aren't ancestors of master.
I retried with your two patches. That looks a *lot* better. After using
the above and deleting the reported branches there are still some
branches left, but at least switching to them doesn't bring the complete
project back.
Now there are a few weird tags left, some of these may well be the
result of weird things in the repository. The repository was on CVS
until about a year ago and was converted (using SVN as intermediate).
The big problem is anything that relates to the days before the filtered
directory was part of the project. There are lots of tags there and
switching to them brings back the old project. I'd guess the correct
behaviour is that either all these tags refer to an empty tree or (which
I would prefer) all such tags are deleted.
Is this a bug? Is there a trick here? git clone --depth doesn't
seem appropriate.
Cheers --- Jan
^ permalink raw reply
* Re: [RFH] filter-branch: ancestor detection weirdness
From: Johannes Schindelin @ 2008-08-08 11:42 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Jan Wielemaker
In-Reply-To: <1218153242-18837-1-git-send-email-trast@student.ethz.ch>
Hi,
On Fri, 8 Aug 2008, Thomas Rast wrote:
> diff --git a/git-filter-branch.sh b/git-filter-branch.sh
> index 182822a..52b2bdf 100755
> --- a/git-filter-branch.sh
> +++ b/git-filter-branch.sh
> @@ -325,15 +325,9 @@ while read ref
> do
> sha1=$(git rev-parse "$ref"^0)
> test -f "$workdir"/../map/$sha1 && continue
> - # Assign the boundarie(s) in the set of rewritten commits
> - # as the replacement commit(s).
> - # (This would look a bit nicer if --not --stdin worked.)
> - for p in $( (cd "$workdir"/../map; ls | sed "s/^/^/") |
> - git rev-list $ref --boundary --stdin |
> - sed -n "s/^-//p")
> - do
> - map $p >> "$workdir"/../map/$sha1
> - done
> + # Assign the first commit not pruned as the replacement.
> + candidate=$(git rev-list $ref -1 -- "$filter_subdir")
Is it not just a question of adding '-- "$filter_subdir"' to the rev-list
call you removed?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Documentation: commit-tree: remove 16 parents restriction
From: Thomas Rast @ 2008-08-08 11:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0808081238250.9611@pacific.mpi-cbg.de.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 550 bytes --]
Johannes Schindelin wrote:
>
> On Fri, 8 Aug 2008, Thomas Rast wrote:
>
> > Creates a new commit object based on the provided tree object and
> > -emits the new commit object id on stdout. If no parent is given then
> > -it is considered to be an initial tree.
> > +emits the new commit object id on stdout.
>
> Oops.
I deliberately removed that sentence because I wanted to enumerate all
options in the new second paragraph (0, 1, or many), and felt it would
be redundant.
- Thomas
--
Thomas Rast
trast@student.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Can't get git clone over https with proxy and invalid certificate...
From: Giovanni Funchal @ 2008-08-08 11:48 UTC (permalink / raw)
To: git
Hi all,
I've been trying without success to clone a git repository over https.
I've got a complicated situation because I have a proxy which only
allows http/https and the server I'm trying to connect to has an
invalid certificate. I'm using git 1.5.6.4 and curl 7.18.1 compiled on
x86_64.
Ok, so I have created the following ~/.curlrc:
netrc
proxytunnel
insecure
proxy = http://proxyserver.com:8080
proxy-user = proxyuser:proxypassword
accompanied by the following ~/.netrc:
machine remoteserver.com
login remoteuser
password remotepassword
and the following ~/.gitconfig:
[user]
name = My Name
email = my.em@il.com
[http]
sslVerify = false
All above files permissions are set to 600 and I have also set the
environment variables http_proxy, https_proxy and all_proxy (one never
knows) to:
http://proxyuser:proxypassword@proxyserver.com:8080
Ok, now lets try:
$ wget -q --no-check-certificate
https://remoteuser@remoteserver.com/.git/HEAD && cat HEAD && rm HEAD
ref: refs/heads/master
$ curl https://remoteuser@remoteserver.com/.git/HEAD
ref: refs/heads/master
$ git clone https://remoteuser@remoteserver.com/.git/
Initialized empty Git repository in /home/user/.git/
error: Proxy requires authorization!
warning: remote HEAD refers to nonexistent ref, unable to checkout.
Both wget and curl work, but git won't! Any clues?
Thanks in advance and best regards,
-- Giovanni
^ permalink raw reply
* How to fix (and find) many git-* --check errors?
From: "Peter Valdemar Mørch (Lists)" @ 2008-08-08 12:49 UTC (permalink / raw)
To: git
We have > 37000 white space "errors" in HEAD, mostly trailing
whitespace, and I'm looking for a
$ git diff --check | git??? --whitespace=fix
command.
Is there such a beast?
I see that git-apply has a --whitespace=<action> option, but I don't
seem to grock how to be able to use it for fixing my working directory.
Details follow:
I can create a perl script that does this for me (e.g. inspired by
1.5.6's hooks/pre-commit's perl version of git diff --check) and post it
here if anybody would like it, but I'd rather use some well-tested
method if one exists. And it seems git-apply has the functionality somehow.
Of course, I can also:
$ git diff --check > tmpcfile
# (Or some other command to find all of them under ./)
$ vim
:cfile tmpcfile
Thank you for --check having a handy output format, BTW! But I prefer
automation (and automated auditing of the results) for 37000 lines.
Also the way I found them is like this:
$ git diff --check $(git log --pretty=format:%H | tail -1)..HEAD .
(The diff between "the empty commit" and HEAD - well between the first
commit and HEAD anyway. Is there a ref for "totally empty" or the
revision before the first commit? Or a more elegant way to get this list?)
Peter
--
Peter Valdemar Mørch
http://www.morch.com
^ permalink raw reply
* Re: git diff/log --check exitcode and PAGER environment variable
From: Jeff King @ 2008-08-08 13:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Valdemar Mørch (Lists), git
In-Reply-To: <7vfxpfet8a.fsf@gitster.siamese.dyndns.org>
On Fri, Aug 08, 2008 at 02:44:37AM -0700, Junio C Hamano wrote:
> "Peter Valdemar Mørch (Lists)" <4ux6as402@sneakemail.com> writes:
>
> > There is this old thread:
> > "[PATCH 1/5] "diff --check" should affect exit status"
> > http://thread.gmane.org/gmane.comp.version-control.git/68145/focus=68148
> > which seemed not to reach a conclusion.
>
> Conclusion was (1) if you really care about the exit code, do not use
> pager; (2) after 1.6.0 we will swap the child/parent between git and pager
> to expose exit code from us, but not before.
>
> Or am I mistaken?
Yes, all of his testing with "git diff" is hampered by the pager hiding
the exit code. And that is dealt with by the patches in next (and I
tested his examples with 'next', and they work fine).
But that still leaves the part about "git log" not changing its exit
code. I don't think it has ever been designed to, and I'm not even sure
what the semantics would be (exit code != 0 if any logged commit has a
whitespace problem? That seems the most logical, and it might be useful
for limited ranges).
-Peff
^ permalink raw reply
* Re: git diff/log --check exitcode and PAGER environment variable
From: Jeff King @ 2008-08-08 13:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Valdemar Mørch (Lists), git
In-Reply-To: <20080808131759.GA19705@sigill.intra.peff.net>
On Fri, Aug 08, 2008 at 09:17:59AM -0400, Jeff King wrote:
> Yes, all of his testing with "git diff" is hampered by the pager hiding
> the exit code. And that is dealt with by the patches in next (and I
> tested his examples with 'next', and they work fine).
>
> But that still leaves the part about "git log" not changing its exit
> code. I don't think it has ever been designed to, and I'm not even sure
> what the semantics would be (exit code != 0 if any logged commit has a
> whitespace problem? That seems the most logical, and it might be useful
> for limited ranges).
...and then after writing this I realized that all of this was dealt
with later in the thread. Sorry for the noise.
-Peff
^ permalink raw reply
* Re: How to fix (and find) many git-* --check errors?
From: Jeff King @ 2008-08-08 13:23 UTC (permalink / raw)
To: "Peter Valdemar Mørch (Lists)"; +Cc: git
In-Reply-To: <489C40BC.8000008@sneakemail.com>
On Fri, Aug 08, 2008 at 02:49:00PM +0200, "Peter Valdemar Mørch (Lists)" wrote:
> (The diff between "the empty commit" and HEAD - well between the first
> commit and HEAD anyway. Is there a ref for "totally empty" or the
> revision before the first commit? Or a more elegant way to get this
> list?)
It is not advertised, but we always recognize the empty sha1 of the
empty tree:
git diff --check 4b825dc642cb6eb9a060e54bf8d69288fbee4904
In fact, just the other day I was using this for the Nth time and got
tired of looking it up in the code, so I wrote the patch below. I don't
know if it is too crazy to be included in mainline git (it was discussed
a long time ago, but I think the general response was "what would it be
good for?").
---
cache.h | 4 ++++
refs.c | 4 ++++
sha1_file.c | 3 +--
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index 30f1d62..4aa02ae 100644
--- a/cache.h
+++ b/cache.h
@@ -567,6 +567,10 @@ static inline unsigned int hexval(unsigned char c)
#define MINIMUM_ABBREV 4
#define DEFAULT_ABBREV 7
+#define EMPTY_TREE_SHA1 \
+ "\x4b\x82\x5d\xc6\x42\xcb\x6e\xb9\xa0\x60" \
+ "\xe5\x4b\xf8\xd6\x92\x88\xfb\xee\x49\x04"
+
extern int get_sha1(const char *str, unsigned char *sha1);
extern int get_sha1_with_mode(const char *str, unsigned char *sha1, unsigned *mode);
extern int get_sha1_hex(const char *hex, unsigned char *sha1);
diff --git a/refs.c b/refs.c
index 39a3b23..0acbcbc 100644
--- a/refs.c
+++ b/refs.c
@@ -427,6 +427,10 @@ const char *resolve_ref(const char *ref, unsigned char *sha1, int reading, int *
}
list = list->next;
}
+ if (!strcmp(ref, "EMPTY")) {
+ hashcpy(sha1, (unsigned char *)EMPTY_TREE_SHA1);
+ return ref;
+ }
if (reading || errno != ENOENT)
return NULL;
hashclr(sha1);
diff --git a/sha1_file.c b/sha1_file.c
index 2aff59b..38aad13 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1985,8 +1985,7 @@ static int cached_object_nr, cached_object_alloc;
static struct cached_object empty_tree = {
/* empty tree sha1: 4b825dc642cb6eb9a060e54bf8d69288fbee4904 */
- "\x4b\x82\x5d\xc6\x42\xcb\x6e\xb9\xa0\x60"
- "\xe5\x4b\xf8\xd6\x92\x88\xfb\xee\x49\x04",
+ EMPTY_TREE_SHA1,
OBJ_TREE,
"",
0
--
1.6.0.rc1.260.g4782
^ permalink raw reply related
* Re: How to fix (and find) many git-* --check errors?
From: Björn Steinbrink @ 2008-08-08 13:28 UTC (permalink / raw)
To: Peter Valdemar Mørch (Lists); +Cc: git
In-Reply-To: <489C40BC.8000008@sneakemail.com>
On 2008.08.08 14:49:00 +0200, "Peter Valdemar Mørch (Lists)" wrote:
> We have > 37000 white space "errors" in HEAD, mostly trailing
> whitespace, and I'm looking for a
>
> $ git diff --check | git??? --whitespace=fix
>
> command.
>
> Is there such a beast?
>
> I see that git-apply has a --whitespace=<action> option, but I don't
> seem to grock how to be able to use it for fixing my working directory.
I'd probably do something like:
# Create a commit with an empty tree
rm .git/index
git commit -m tmp
rm -r * (include dotfiles if required, ie. remove all tracked files)
git diff -R HEAD^ | git apply --index --whitespace=fix
git commit --amend -m "Whitespace fixed up"
But probably there's some smarter way than that.
Björn
^ permalink raw reply
* [PATCH] gitweb: shortlog now also obeys $hash_parent
From: Giuseppe Bilotta @ 2008-08-08 14:12 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Giuseppe Bilotta
If $hash_parent is defined, shortlog now limits the list of commits at
those between $hash_parent (exclusive) and $hash (inclusive).
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index a12ce87..d811dd4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5472,7 +5472,11 @@ sub git_shortlog {
}
my $refs = git_get_references();
- my @commitlist = parse_commits($hash, 101, (100 * $page));
+ my $commit_hash = $hash;
+ if (defined $hash_parent) {
+ $commit_hash = "$hash_parent..$hash";
+ }
+ my @commitlist = parse_commits($commit_hash, 101, (100 * $page));
my $paging_nav = format_paging_nav('shortlog', $hash, $head, $page, $#commitlist >= 100);
my $next_link = '';
--
1.5.6.3
^ permalink raw reply related
* Re: [RFH] filter-branch: ancestor detection weirdness
From: Thomas Rast @ 2008-08-08 14:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Jan Wielemaker
In-Reply-To: <alpine.DEB.1.00.0808081341170.9611@pacific.mpi-cbg.de.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 3376 bytes --]
Johannes Schindelin wrote:
>
> On Fri, 8 Aug 2008, Thomas Rast wrote:
>
> > diff --git a/git-filter-branch.sh b/git-filter-branch.sh
> > index 182822a..52b2bdf 100755
> > --- a/git-filter-branch.sh
> > +++ b/git-filter-branch.sh
> > @@ -325,15 +325,9 @@ while read ref
> > do
> > sha1=$(git rev-parse "$ref"^0)
> > test -f "$workdir"/../map/$sha1 && continue
> > - # Assign the boundarie(s) in the set of rewritten commits
> > - # as the replacement commit(s).
> > - # (This would look a bit nicer if --not --stdin worked.)
> > - for p in $( (cd "$workdir"/../map; ls | sed "s/^/^/") |
> > - git rev-list $ref --boundary --stdin |
> > - sed -n "s/^-//p")
> > - do
> > - map $p >> "$workdir"/../map/$sha1
> > - done
> > + # Assign the first commit not pruned as the replacement.
> > + candidate=$(git rev-list $ref -1 -- "$filter_subdir")
I think I see the actual problem. I made a small testing repository
with history that looks like this:
* a6f2213... (refs/heads/master) Merge branch 'side'
|\
| * 311f888... (refs/heads/side) outside
| * 472893d... inside dir
* | 9bd52bc... (refs/heads/stale) outside
* | d1b451a... inside dir
|/
* 1c48eea... initial
It is available at
git://persephone.dnsalias.net/git/filtertest.git
if you want to try. All commits labelled 'inside dir' do something in
dir/; the others don't. (You can disregard the 'other' branch for
now; I wanted to test the behaviour on completely disconnected history
too, since that's the case with Jan's repo.)
Let's depict this as the following for now, where capitals stand for
"interesting" commits under the subdirectory filter:
i -- A -- b(stale) -- M(master)
\ /
\- C -- d(side) --/
When saying
$ git filter-branch --subdirectory-filter dir -- --all'
I would expect the history to look like:
A(stale) -- M(master)
/
C(side) --/
I think treating it this way makes a lot of sense; you get the last
state that your subdirectory had on the corresponding branch or tag.
(Similarly, a leaf branch that does not affect 'dir' should be backed
up until it hits an ancestor that survives the filter.)
Now the problem with the above ancestor detection is the following.
Consider that at this point, the 'map' directory contains the
(unfiltered) SHA1 for every commit that was rewritten during the
filtering process, i.e.
$ g rev-list --all -- dir | git name-rev --stdin
093c591b3d751ce778b4a6e5c2a0906b097b5868 (other~1)
a6f22134f8ab8bcc762949df53f674e3410f7fc3 (master)
d1b451a4b0657ea894fd772fc609f7863b7dfd15 (stale~1)
472893d579383f56f006ff42c563dcbb730bc5b8 (side~1)
So 'map' has the values for M, A, and C. Now if you expand the call
(cd "$workdir"/../map; ls | sed "s/^/^/") |
git rev-list $ref --boundary --stdin
you'll find that during ref=refs/heads/side, it is equivalent to
$ git rev-list side --boundary ^master ^side~1 ^stale~1 ^other~1
[no output!]
Oops, it seems that wasn't what we wanted. The '^master', which
reaches 'side' already, precludes all output.
So now that I've finally understood what is going on, I think a more
careful use of rev-list -1 is actually a correct and easy way to
figure out an ancestor. Patch follows.
- Thomas
--
Thomas Rast
trast@student.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] filter-branch: fix ancestor discovery for --subdirectory-filter
From: Thomas Rast @ 2008-08-08 14:16 UTC (permalink / raw)
To: git; +Cc: gitster, Johannes Schindelin, Jan Wielemaker
In-Reply-To: <200808081614.44422.trast@student.ethz.ch>
The previous code failed on any refs that are (pre-rewrite) ancestors
of commits marked for rewriting. This means that in a situation
A -- B(topic) -- C(master)
where B is dropped by --subdirectory-filter pruning, the 'topic' is
not moved up to A as intended, but left unrewritten.
Fix this by using a more stupid approach: we let 'rev-list -1' figure
out a nearby ancestor, which handles the pruning automatically.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
I guarded it with a $filter_subdir check to not cause any unintended
harm. It might be useful in some border cases of rev-list arguments
given to filter-branch too, but I can't figure out a safe way to
handle that.
Either way, this fixes the problem.
- Thomas
git-filter-branch.sh | 27 +++++++++++----------------
1 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index a324cf0..7924aa1 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -317,24 +317,19 @@ done <../revs
# In case of a subdirectory filter, it is possible that a specified head
# is not in the set of rewritten commits, because it was pruned by the
-# revision walker. Fix it by mapping these heads to the next rewritten
-# ancestor(s), i.e. the boundaries in the set of rewritten commits.
+# revision walker. Fix it by mapping these heads to a (random!) nearby
+# ancestor that survived the pruning.
-# NEEDSWORK: we should sort the unmapped refs topologically first
-while read ref
-do
- sha1=$(git rev-parse "$ref"^0)
- test -f "$workdir"/../map/$sha1 && continue
- # Assign the boundarie(s) in the set of rewritten commits
- # as the replacement commit(s).
- # (This would look a bit nicer if --not --stdin worked.)
- for p in $( (cd "$workdir"/../map; ls | sed "s/^/^/") |
- git rev-list $ref --boundary --stdin |
- sed -n "s/^-//p")
+if test "$filter_subdir"
+then
+ while read ref
do
- map $p >> "$workdir"/../map/$sha1
- done
-done < "$tempdir"/heads
+ sha1=$(git rev-parse "$ref"^0)
+ test -f "$workdir"/../map/$sha1 && continue
+ ancestor=$(git rev-list -1 $ref -- "$filter_subdir")
+ test "$ancestor" && echo $(map $ancestor) >> "$workdir"/../map/$sha1
+ done < "$tempdir"/heads
+fi
# Finally update the refs
--
1.6.0.rc2.22.g7d28.dirty
^ permalink raw reply related
* Re: Can't get git clone over https with proxy and invalid certificate...
From: Shawn O. Pearce @ 2008-08-08 14:28 UTC (permalink / raw)
To: Giovanni Funchal; +Cc: git
In-Reply-To: <c475e2e60808080448x40683db1wadcd834e94d7d263@mail.gmail.com>
Giovanni Funchal <gafunchal@gmail.com> wrote:
> Ok, so I have created the following ~/.curlrc:
> netrc
> proxytunnel
> insecure
> proxy = http://proxyserver.com:8080
> proxy-user = proxyuser:proxypassword
...
> $ git clone https://remoteuser@remoteserver.com/.git/
> Initialized empty Git repository in /home/user/.git/
> error: Proxy requires authorization!
> warning: remote HEAD refers to nonexistent ref, unable to checkout.
Last time I used Git with an HTTP proxy that required authentication
I was doing it with an environment variable:
http_proxy=http://me:pass@proxyserver.com:8080 git clone ...
Fortunately this was on a Windows desktop where I was the only
user who was logged into the system, so leaking my password into my
environment for a short duration was about the same risk as putting
into a ~/. file.
--
Shawn.
^ 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