* Re: Consensus on "Git"
From: Jeff King @ 2009-11-11 9:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Symonds, git
In-Reply-To: <20091111092731.GA17422@sigill.intra.peff.net>
On Wed, Nov 11, 2009 at 04:27:31AM -0500, Jeff King wrote:
> For a fun (ab)use of blame, you can see who wrote each of David's
> suspect lines with:
>
> git grep -n "\bGIT\b" |
> while IFS=: read file line junk; do
> git blame -f -L $line,$line $file
> done |
> less
>
> Many of them are variables (e.g., \b gets rid of "_", but we still have
> "-", so GIT-VERSION and such are still there). Many others are the title
> of the "GIT" section of the manpages. But there are some legitimate
> uses, too. Many of them blame to quite a long time ago, though (e.g.,
> Documentation/everyday.txt has two uses by you in 2005).
BTW, here is a much better grep (still a few false positives, but most
lines are meanginful):
git grep -n -E "(^|[^A-Z_-])GIT($|[^A-Z_-])" |
grep -v ':GIT$' |
while IFS=: read file line junk; do
git blame -f -L $line,$line $file
done |
less
You can really see that most of the uses of GIT are ancient. I wonder if
we should downcase the few that are in user-visible error messages. I
will let somebody else spend their time on such a conversion if they
want, though. I've already spent enough on this. :)
-Peff
^ permalink raw reply
* Re: Consensus on "Git"
From: Junio C Hamano @ 2009-11-11 9:36 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, David Symonds, git
In-Reply-To: <20091111092731.GA17422@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Except for the title of every set of release notes, which all start
> with:
>
> GIT vX.Y.Z Release Notes
>
> ? :)
Yeah these were copied from release to release and I do not pay much
attention to the minute details of how my tools I wrote long time ago
spells things ;-)
Perhaps I should update my scripts to generate them.
^ permalink raw reply
* Re: Consensus on "Git"
From: Johannes Schindelin @ 2009-11-11 9:33 UTC (permalink / raw)
To: David Symonds; +Cc: git
In-Reply-To: <ee77f5c20911110032r65a60653sfeef34e3de07d17e@mail.gmail.com>
Hi,
On Wed, 11 Nov 2009, David Symonds wrote:
> Is there consensus on "Git" being the standard capitalisation, versus
> "GIT"?
There is definitely no consensus.
Personally, I started to capitalize it as a reaction to business types
(apparently you have to turn in your sense of humor when you get an MBA),
who were not happy with the abbreviation "global information tracker"
(which would merit an all-capitalization a la CVS) [*1*], let alone with
the connotation as a British slang word.
Yes, in Open Source, we are used to crude, geeky humor, some of us even
accept blunt mails, but we are embedded in a world that is called
"reality".
In my experience, in this world it is much easier to tell people that your
program is called "Git" ("could have been John, either") and be done with
the questions.
Ciao,
Dscho
Footnote *1*: I tried once to reinterpret GIT as meaning "Git Is
Terrific", but that did not fly too well. :-)
^ permalink raw reply
* Re: Consensus on "Git"
From: Jeff King @ 2009-11-11 9:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Symonds, git
In-Reply-To: <7v8wedv3a3.fsf@alter.siamese.dyndns.org>
On Wed, Nov 11, 2009 at 01:06:44AM -0800, Junio C Hamano wrote:
> > Is there consensus on "Git" being the standard capitalisation, versus
> > "GIT"?
>
> I am not a consensus, but from day 1, Linus talked about "git" (all
> lowercase) and "Git" was used only when it came at the beginning of a
> sentence (an usual English capitalization rule) or in a section or book
> title where all words (except prepositions such as "in", "on") are
> capitalized, and I try to mimick it myself for consistency.
>
> As a corollary, unless I spell all the other words in capital to SHOUT, I
> never write GIT.
Except for the title of every set of release notes, which all start
with:
GIT vX.Y.Z Release Notes
? :)
For a fun (ab)use of blame, you can see who wrote each of David's
suspect lines with:
git grep -n "\bGIT\b" |
while IFS=: read file line junk; do
git blame -f -L $line,$line $file
done |
less
Many of them are variables (e.g., \b gets rid of "_", but we still have
"-", so GIT-VERSION and such are still there). Many others are the title
of the "GIT" section of the manpages. But there are some legitimate
uses, too. Many of them blame to quite a long time ago, though (e.g.,
Documentation/everyday.txt has two uses by you in 2005).
-Peff
^ permalink raw reply
* Re: Consensus on "Git"
From: Reece Dunn @ 2009-11-11 9:21 UTC (permalink / raw)
To: David Symonds; +Cc: git
In-Reply-To: <ee77f5c20911110032r65a60653sfeef34e3de07d17e@mail.gmail.com>
2009/11/11 David Symonds <dsymonds@gmail.com>:
> Hi folks,
>
> Is there consensus on "Git" being the standard capitalisation, versus
> "GIT"? I only really see "git" and "Git" on the mailing list and in
> most external documentation and websites (e.g. git-scm.com and
> github.com), but git's source tells a different picture:
>
> $ cat *.[ch] | egrep -o '\bG[Ii][Tt]\b' | sort | uniq -c
> 36 GIT
> 7 Git
> $ cat Documentation/* 2> /dev/null | egrep -o '\bG[Ii][Tt]\b' | sort | uniq -c
> 284 GIT
> 155 Git
All upper case in the sources and documentation will mean that it is
either an environment variable (e.g. GIT_INSTALL_DIR as Sverre has
noted), and for preprocessor constants/definitions.
However, those are not what you are searching for. I.e.
$ grep -P '\bGIT\b' *.[ch]
builtin-apply.c: * We have read "GIT binary patch\n"; what follows is a line
builtin-apply.c: static const char git_binary[] = "GIT binary patch\n";
builtin-cat-file.c: * GIT - The information manager from hell
builtin-check-ref-format.c: * GIT - The information manager from hell
builtin-commit-tree.c: * GIT - The information manager from hell
builtin-diff-files.c: * GIT - The information manager from hell
builtin-init-db.c: * GIT - The information manager from hell
builtin-ls-tree.c: * GIT - The information manager from hell
builtin-mktree.c: * GIT - the stupid content tracker
builtin-read-tree.c: * GIT - The information manager from hell
builtin-update-index.c: * GIT - The information manager from hell
builtin-write-tree.c: * GIT - The information manager from hell
config.c: * GIT - The information manager from hell
date.c: * GIT - The information manager from hell
diff.c: fprintf(file, "GIT binary patch\n");
diff-delta.c: * Rewritten for GIT by Nicolas Pitre <nico@fluxnic.net>,
(C) 2005-2007
fast-import.c: # GIT does not permit ':' in ref or tag strings.
fast-import.c: path ::= # GIT style file path, e.g. "a/b/c";
fast-import.c: ref ::= # GIT ref name, e.g.
"refs/heads/MOZ_GECKO_EXPERIMENT";
fast-import.c: tag ::= # GIT tag name, e.g. "FIREFOX_1_5";
fast-import.c: sha1exp ::= # Any valid GIT SHA1 expression;
fast-import.c: name ::= # valid GIT author/committer name;
fast-import.c: email ::= # valid GIT author/committer email;
fast-import.c: tz ::= # GIT style timezone;
fast-import.c: die("Branch name doesn't conform to GIT standards: %s", name);
hash-object.c: * GIT - The information manager from hell
progress.c: * Simple text-based progress display module for GIT
read-cache.c: * GIT - The information manager from hell
read-cache.c: * cache, ie the parts that aren't tracked by GIT, and only used
sha1_file.c: * GIT - The information manager from hell
sha1_file.c: " (try upgrading GIT to a newer version)",
sha1_file.c: return error("file %s is not a GIT packfile", p->pack_name);
sha1_file.c: " supported (try upgrading GIT to a newer version)",
trace.c: * GIT - The information manager from hell
usage.c: * GIT - The information manager from hell
var.c: * GIT - The information manager from hell
And selected extracts from:
$ grep -P '\bGIT\b' Documentation/*
Documentation/asciidoc.conf:# Show GIT link as: <command>(<section>);
if section is defined, else just show
Documentation/everyday.txt:Everyday GIT With 20 Commands Or So
Documentation/everyday.txt:My typical GIT day.::
Documentation/git-tools.txt: providing generally smoother user
experience than the "raw" Core GIT
Documentation/git-tools.txt: is now in core GIT.
Documentation/git-tools.txt: pg is a shell script wrapper around GIT
to help the user manage a set of
Documentation/git-tools.txt: Stacked GIT provides a quilt-like patch
management functionality in the
Documentation/git-tools.txt: GIT environment. You can easily manage
your patches in the scope of GIT
Documentation/git-tools.txt: gitk is a simple Tk GUI for browsing
history of GIT repositories easily.
Documentation/git-tools.txt: GITweb provides full-fledged web
interface for GIT repositories.
Documentation/git-tag.txt:GIT
Documentation/RelNotes-1.6.1.txt:GIT v1.6.1 Release Notes
- Reece
^ permalink raw reply
* Re: Consensus on "Git"
From: Junio C Hamano @ 2009-11-11 9:06 UTC (permalink / raw)
To: David Symonds; +Cc: git
In-Reply-To: <ee77f5c20911110032r65a60653sfeef34e3de07d17e@mail.gmail.com>
David Symonds <dsymonds@gmail.com> writes:
> Is there consensus on "Git" being the standard capitalisation, versus
> "GIT"?
I am not a consensus, but from day 1, Linus talked about "git" (all
lowercase) and "Git" was used only when it came at the beginning of a
sentence (an usual English capitalization rule) or in a section or book
title where all words (except prepositions such as "in", "on") are
capitalized, and I try to mimick it myself for consistency.
As a corollary, unless I spell all the other words in capital to SHOUT, I
never write GIT.
^ permalink raw reply
* Re: Consensus on "Git"
From: Sverre Rabbelier @ 2009-11-11 9:02 UTC (permalink / raw)
To: David Symonds; +Cc: git
In-Reply-To: <ee77f5c20911110032r65a60653sfeef34e3de07d17e@mail.gmail.com>
Heya,
On Wed, Nov 11, 2009 at 09:32, David Symonds <dsymonds@gmail.com> wrote:
> Is there consensus on "Git" being the standard capitalisation, versus
> "GIT"? I only really see "git" and "Git" on the mailing list and in
> most external documentation and websites (e.g. git-scm.com and
> github.com), but git's source tells a different picture:
Definitely "Git" or "git", the source code ones are probably from
variable names, something like "GIT_INSTALL_DIR" and whatnot.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v5 1/2] filter-branch: stop special-casing $filter_subdir argument
From: Johannes Sixt @ 2009-11-11 8:58 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <4AFA7B9A.4090005@viscovery.net>
Johannes Sixt schrieb:
> --- a/git-filter-branch.sh
> +++ b/git-filter-branch.sh
> @@ -266,7 +266,7 @@
>
> # we need "--" only if there are no path arguments in $@
> nonrevs=$(git rev-parse --no-revs "$@") || exit
> -dashdash=${nonrevs+"--"}
> +test -z "$nonrevs" && dashdash=-- || dashdash=
> rev_args=$(git rev-parse --revs-only "$@")
>
> case "$filter_subdir" in
Arrgh! I should have indented these lines so that they
do not count as patch text.
Sorry.
-- Hannes
^ permalink raw reply
* [PATCH v5 2/2] filter-branch: nearest-ancestor rewriting outside subdir filter
From: Johannes Sixt @ 2009-11-11 8:55 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <4AFA7B9A.4090005@viscovery.net>
From: Thomas Rast <trast@student.ethz.ch>
Date: Tue, 10 Nov 2009 22:04:51 +0100
Since a0e4639 (filter-branch: fix ref rewriting with
--subdirectory-filter, 2008-08-12) git-filter-branch has done
nearest-ancestor rewriting when using a --subdirectory-filter.
However, that rewriting strategy is also a useful building block in
other tasks. For example, if you want to split out a subset of files
from your history, you would typically call
git filter-branch -- <refs> -- <files>
But this fails for all refs that do not point directly to a commit
that affects <files>, because their referenced commit will not be
rewritten and the ref remains untouched.
The code was already there for the --subdirectory-filter case, so just
introduce an option that enables it independently.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Only resent for Junio's convenience. It is identical to your v4, but
with my SOB added.
-- Hannes
Documentation/git-filter-branch.txt | 13 ++++++++++++-
git-filter-branch.sh | 18 +++++++++++++-----
t/t7003-filter-branch.sh | 18 ++++++++++++++++++
3 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index 2b40bab..394a77a 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -159,7 +159,18 @@ to other tags will be rewritten to point to the underlying commit.
--subdirectory-filter <directory>::
Only look at the history which touches the given subdirectory.
The result will contain that directory (and only that) as its
- project root.
+ project root. Implies --remap-to-ancestor.
+
+--remap-to-ancestor::
+ Rewrite refs to the nearest rewritten ancestor instead of
+ ignoring them.
++
+Normally, positive refs on the command line are only changed if the
+commit they point to was rewritten. However, you can limit the extent
+of this rewriting by using linkgit:rev-list[1] arguments, e.g., path
+limiters. Refs pointing to such excluded commits would then normally
+be ignored. With this option, they are instead rewritten to point at
+the nearest ancestor that was not excluded.
--prune-empty::
Some kind of filters will generate empty commits, that left the tree
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index ed3db7d..6b8b6a4 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -125,6 +125,7 @@ filter_subdir=
orig_namespace=refs/original/
force=
prune_empty=
+remap_to_ancestor=
while :
do
case "$1" in
@@ -137,6 +138,11 @@ do
force=t
continue
;;
+ --remap-to-ancestor)
+ shift
+ remap_to_ancestor=t
+ continue
+ ;;
--prune-empty)
shift
prune_empty=t
@@ -182,6 +188,7 @@ do
;;
--subdirectory-filter)
filter_subdir="$OPTARG"
+ remap_to_ancestor=t
;;
--original)
orig_namespace=$(expr "$OPTARG/" : '\(.*[^/]\)/*$')/
@@ -354,12 +361,13 @@ while read commit parents; do
die "could not write rewritten commit"
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 unique nearest
-# ancestor that survived the pruning.
+# If we are filtering for paths, as in the 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.
+# Ancestor remapping fixes this by mapping these heads to the unique
+# nearest ancestor that survived the pruning.
-if test "$filter_subdir"
+if test "$remap_to_ancestor" = t
then
while read ref
do
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 329c851..9503875 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -288,4 +288,22 @@ test_expect_success 'Prune empty commits' '
test_cmp expect actual
'
+test_expect_success '--remap-to-ancestor with filename filters' '
+ git checkout master &&
+ git reset --hard A &&
+ test_commit add-foo foo 1 &&
+ git branch moved-foo &&
+ test_commit add-bar bar a &&
+ git branch invariant &&
+ orig_invariant=$(git rev-parse invariant) &&
+ git branch moved-bar &&
+ test_commit change-foo foo 2 &&
+ git filter-branch -f --remap-to-ancestor \
+ moved-foo moved-bar A..master \
+ -- -- foo &&
+ test $(git rev-parse moved-foo) = $(git rev-parse moved-bar) &&
+ test $(git rev-parse moved-foo) = $(git rev-parse master^) &&
+ test $orig_invariant = $(git rev-parse invariant)
+'
+
test_done
--
1.6.5.rc2.47.g49402
^ permalink raw reply related
* [PATCH v5 1/2] filter-branch: stop special-casing $filter_subdir argument
From: Johannes Sixt @ 2009-11-11 8:53 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <4AFA7624.5040400@viscovery.net>
From: Thomas Rast <trast@student.ethz.ch>
Handling $filter_subdir in the usual way requires a separate case at
every use, because the variable is empty when unused.
Furthermore, --subdirectory-filter supplies its own '--', and if the user
provided one himself, such as in
git filter-branch --subdirectory-filter subdir -- --all -- subdir/file
an extra '--' was used as path filter in the call to git-rev-list that
determines the commits that shall be rewritten.
To keep the argument handling sane, we filter $@ to contain only the
non-revision arguments, and store all revisions in $ref_args. The
$ref_args are easy to handle since only the SHA1s are needed; the
actual branch names have already been stored in $tempdir/heads at this
point.
An extra separating -- is only required if the user did not provide
any non-revision arguments, as the latter disambiguate the
$filter_subdir following after them (or fail earlier because they are
ambiguous themselves).
Thanks to Johannes Sixt for suggesting this solution.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Johannes Sixt schrieb:
> I'll submit a replacement patch.
Here it is. The interdiff to your version is merely
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -266,7 +266,7 @@
# we need "--" only if there are no path arguments in $@
nonrevs=$(git rev-parse --no-revs "$@") || exit
-dashdash=${nonrevs+"--"}
+test -z "$nonrevs" && dashdash=-- || dashdash=
rev_args=$(git rev-parse --revs-only "$@")
case "$filter_subdir" in
and I changed the commit message in the way I announced it.
-- Hannes
git-filter-branch.sh | 22 +++++++++++++++-------
1 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index a480d6f..ed3db7d 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -257,15 +257,24 @@ git read-tree || die "Could not seed the index"
# map old->new commit ids for rewriting parents
mkdir ../map || die "Could not create map/ directory"
+# we need "--" only if there are no path arguments in $@
+nonrevs=$(git rev-parse --no-revs "$@") || exit
+test -z "$nonrevs" && dashdash=-- || dashdash=
+rev_args=$(git rev-parse --revs-only "$@")
+
case "$filter_subdir" in
"")
- git rev-list --reverse --topo-order --default HEAD \
- --parents --simplify-merges "$@"
+ eval set -- "$(git rev-parse --sq --no-revs "$@")"
;;
*)
- git rev-list --reverse --topo-order --default HEAD \
- --parents --simplify-merges "$@" -- "$filter_subdir"
-esac > ../revs || die "Could not get the commits"
+ eval set -- "$(git rev-parse --sq --no-revs "$@" $dashdash \
+ "$filter_subdir")"
+ ;;
+esac
+
+git rev-list --reverse --topo-order --default HEAD \
+ --parents --simplify-merges $rev_args "$@" > ../revs ||
+ die "Could not get the commits"
commits=$(wc -l <../revs | tr -d " ")
test $commits -eq 0 && die "Found nothing to rewrite"
@@ -356,8 +365,7 @@ then
do
sha1=$(git rev-parse "$ref"^0)
test -f "$workdir"/../map/$sha1 && continue
- ancestor=$(git rev-list --simplify-merges -1 \
- $ref -- "$filter_subdir")
+ ancestor=$(git rev-list --simplify-merges -1 "$ref" "$@")
test "$ancestor" && echo $(map $ancestor) >> "$workdir"/../map/$sha1
done < "$tempdir"/heads
fi
--
1.6.5.rc2.47.g49402
^ permalink raw reply related
* Re: P4 Sync problem
From: Tor Arvid Lund @ 2009-11-11 8:43 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091110T145046-137@post.gmane.org>
On Tue, Nov 10, 2009 at 2:56 PM, Dmitry Smirnov <divis1969@gmail.com> wrote:
> Hi,
>
> I'm trying to import Perfoce client into Git repository.
> I had configured git-p4.clent=MYCLIENT and git-p4.useclientspec=true.
>
> When runnign git p4 sync --verbose I got the follwing:
>
> c:\p4\views\Git\p4client>git p4 sync --verbose
<snip>
> Traceback (most recent call last):
> File "/usr/sbin/git-core//git-p4", line 1929, in ?
> main()
> File "/usr/sbin/git-core//git-p4", line 1924, in main
> if not cmd.run(args):
> File "/usr/sbin/git-core//git-p4", line 1676, in run
> changes = p4ChangesForPaths(self.depotPaths, self.changeRange)
> File "/usr/sbin/git-core//git-p4", line 442, in p4ChangesForPaths
> assert depotPaths
> AssertionError
Hi. So - I think the problem is that git-p4 doesn't understand what it
is you want to sync. The git-p4.useclientspec flag was created for the
purpose where your perforce depot may look like this:
//depot/project1
//depot/project1/source_code
//depot/project1/documentation
//depot/project1/some_large_collection_of_binaries
Then - if I set up my client spec like:
//depot/...
-//depot/project1/some_large_collection_of_binaries
... and do
git p4 sync //depot/project1@all
... it should get all project1 files except the
"some_large_collection_of_binaries" subdirectory (provided that you
have set the git-p4.client and git-p4.useclientspec).
-Tor Arvid-
^ permalink raw reply
* Re: [PATCH] Define $PERL_PATH in test-lib.sh
From: Jeff King @ 2009-11-11 8:43 UTC (permalink / raw)
To: Philippe Bruhat (BooK); +Cc: Junio C Hamano, Johannes Sixt, git
In-Reply-To: <20091111084014.GE8896@plop>
On Wed, Nov 11, 2009 at 09:40:14AM +0100, Philippe Bruhat (BooK) wrote:
> > Hmm, but that means two separate definitions in ./Makefile and
> > t/test-lib.sh must be kept in sync forever, and there is not even a
> > comment next to the line that requires such care in your patch to help
> > people who might want to change these lines in the future.
>
> Is there a way to obtain whatever value was computed in the Makefile,
> or should I just add a comment in all-caps saying "keep this in sync
> with the default value in the top level Makefile"? (and a more detailed
> commit message)
Yes. Did you miss the second half of my other message?
http://article.gmane.org/gmane.comp.version-control.git/132561
-Peff
^ permalink raw reply
* Re: [PATCH] Define $PERL_PATH in test-lib.sh
From: Philippe Bruhat (BooK) @ 2009-11-11 8:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7v7hty6so9.fsf@alter.siamese.dyndns.org>
On Tue, Nov 10, 2009 at 12:17:26PM -0800, Junio C Hamano wrote:
> "Philippe Bruhat (BooK)" <book@cpan.org> writes:
>
> > On Tue, Nov 10, 2009 at 01:26:53PM +0100, Johannes Sixt wrote:
> >> >
> >> > +test -z "$NO_PERL" && test -z "$PERL_PATH" && export PERL_PATH=/usr/bin/perl
> >>
> >> Wouldn't
> >>
> >> ... && export PERL_PATH=perl
> >>
> >> be a safer fall-back?
> >
> > /usr/bin/perl is the value used in the top-level Makefile.
> > I used this for consistency.
>
> Hmm, but that means two separate definitions in ./Makefile and
> t/test-lib.sh must be kept in sync forever, and there is not even a
> comment next to the line that requires such care in your patch to help
> people who might want to change these lines in the future.
Is there a way to obtain whatever value was computed in the Makefile,
or should I just add a comment in all-caps saying "keep this in sync
with the default value in the top level Makefile"? (and a more detailed
commit message)
--
Philippe Bruhat (BooK)
Freedom is not an individual effort. Yours comes only when you grant others
theirs. (Moral from Groo The Wanderer #5 (Epic))
^ permalink raw reply
* Consensus on "Git"
From: David Symonds @ 2009-11-11 8:32 UTC (permalink / raw)
To: git
Hi folks,
Is there consensus on "Git" being the standard capitalisation, versus
"GIT"? I only really see "git" and "Git" on the mailing list and in
most external documentation and websites (e.g. git-scm.com and
github.com), but git's source tells a different picture:
$ cat *.[ch] | egrep -o '\bG[Ii][Tt]\b' | sort | uniq -c
36 GIT
7 Git
$ cat Documentation/* 2> /dev/null | egrep -o '\bG[Ii][Tt]\b' | sort | uniq -c
284 GIT
155 Git
Dave.
^ permalink raw reply
* Re: [PATCH v4 1/2] filter-branch: stop special-casing $filter_subdir argument
From: Johannes Sixt @ 2009-11-11 8:30 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <0280836a32983c848bbb0e3b441be256d3c8f4fa.1257885121.git.trast@student.ethz.ch>
Thomas Rast schrieb:
> Johannes Sixt wrote:
>> # we need "--" only if there are no path arguments in $@
>> nonrevs=$(git rev-parse --no-revs "$@") || exit
>> dashdash=${nonrevs+"--"}
>>
>> (including the comment; you can drop the dquotes in the dashdash
>> assignment if you think the result is still readable.)
>
> Ok. I was briefly scared that this was bash-specific syntax, but dash
> seems happy so I'll trust your advice.
You shouldn't. I'm wrong ;-)
In the snippet above, dashdash will always be set to "--" because a mere
'+' in the variable expansion only tests whether the variable ('nonrevs')
is unset, but it is always set. Even ${nonrevs:+"--"} is wrong, and your
earlier 'test -z' invocation was the correct way to set dashdash.
But...
I did some testing, and now I have to wonder about the use-case that you
present in the commit message:
> Furthermore, the case for --subdirectory-filter supplies its own --,
> so the user cannot provide one himself, so the following was
> impossible:
>
> git filter-branch --subdirectory-filter subdir -- --all -- subdir/file
If you try in git.git itself:
$ git rev-list --simplify-merges --all -- \
Documentation/git-commit.txt | wc -l
84
$ git rev-list --simplify-merges --all -- \
Documentation/git-commit.txt Documentation | wc -l
4624
I thought that the intention to give an extra path argument is to reduce
the number of commits that remain in the rewritten history. But by giving
--subdirectory-filter, the path filter actually loosened, and many more
commits are rewritten.
Since your intention to write this patch is actually to implement
--remap-to-ancestor, I suggest that we defer the question whether the
above use-case makes sense, and only rewrite this particular paragraph in
the commit message to point out the real bug:
-----
Furthermore, --subdirectory-filter supplies its own '--', and if the user
provided one himself, such as in
git filter-branch --subdirectory-filter subdir -- --all -- subdir/file
an extra '--' was used as path filter in the call to git-rev-list that
determines the commits that shall be rewritten.
-----
I'll submit a replacement patch.
-- Hannes
^ permalink raw reply
* Re: git-svn problem with v1.6.5
From: Pascal Obry @ 2009-11-11 8:11 UTC (permalink / raw)
To: Sam Vilain; +Cc: git list
In-Reply-To: <4AFA3751.7000709@vilain.net>
Sam,
> Did you copy the entire directory across using rsync/tar/etc or 'git
> clone' ?
I did a rsync of the .git directory so I expect all refs to be there.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* t5541-http-push hanging
From: Brian Gernhardt @ 2009-11-11 6:28 UTC (permalink / raw)
To: Git List
My build script for git has been hanging at t5541.2 and I haven't had the tuits to discover why. Here's what I've gotten so far, in case anyone can figure it out faster:
$ ./t5541-http-push.sh -v
Initialized empty Git repository in /Users/brian/dev/git/t/trash directory.t5541-http-push/.git/
* expecting success:
cd "$ROOT_PATH" &&
mkdir test_repo &&
cd test_repo &&
git init &&
: >path1 &&
git add path1 &&
test_tick &&
git commit -m initial &&
cd - &&
git clone --bare test_repo test_repo.git &&
cd test_repo.git &&
git config http.receivepack true &&
ORIG_HEAD=$(git rev-parse --verify HEAD) &&
cd - &&
mv test_repo.git "$HTTPD_DOCUMENT_ROOT_PATH"
Initialized empty Git repository in /Users/brian/dev/git/t/trash directory.t5541-http-push/test_repo/.git/
[master (root-commit) 0c973ae] initial
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 path1
/Users/brian/dev/git/t/trash directory.t5541-http-push
Initialized empty Git repository in /Users/brian/dev/git/t/trash directory.t5541-http-push/test_repo.git/
/Users/brian/dev/git/t/trash directory.t5541-http-push
* ok 1: setup remote repository
* expecting success:
cd "$ROOT_PATH" &&
git clone $HTTPD_URL/smart/test_repo.git test_repo_clone
Initialized empty Git repository in /Users/brian/dev/git/t/trash directory.t5541-http-push/test_repo_clone/.git/
error: RPC failed; result=22, HTTP code = 500
^CFATAL: Unexpected exit with code 130
brian@hermes t (master)$ cd trash\ directory.t5541-http-push/httpd/
brian@hermes httpd (master)$ cat error.log
[Wed Nov 11 06:19:39 2009] [notice] Apache/2.2.13 (Unix) configured -- resuming normal operations
[Wed Nov 11 06:19:39 2009] [error] [client 127.0.0.1] git-http-backend(59490) malloc: *** error for object 0x100200340: incorrect checksum for freed object - object was probably modified after being freed.
[Wed Nov 11 06:19:39 2009] [error] [client 127.0.0.1] *** set a breakpoint in malloc_error_break to debug
[Wed Nov 11 06:19:40 2009] [error] [client 127.0.0.1] Premature end of script headers: git-http-backend
[Wed Nov 11 06:24:23 2009] [notice] caught SIGTERM, shutting down
^ permalink raw reply
* [PATCH] bash: add the merge option --ff-only
From: Björn Gustavsson @ 2009-11-11 4:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index e3ddecc..a0917d1 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1224,7 +1224,7 @@ _git_log ()
__git_merge_options="
--no-commit --no-stat --log --no-log --squash --strategy
- --commit --stat --no-squash --ff --no-ff
+ --commit --stat --no-squash --ff --no-ff --ff-only
"
_git_merge ()
--
1.6.5.1.69.g36942
^ permalink raw reply related
* Re: Bug: "git svn clone" does not honor svn.authorsfile setting
From: Sam Vilain @ 2009-11-11 4:26 UTC (permalink / raw)
To: Curt Sampson, git
In-Reply-To: <20091110130913.GR19475@poetic.cynic.net>
Curt Sampson wrote:
> When using "git svn fetch" or "git svn clone", the --authors-file
> command line parameter does what it claims in the docs. Additionally,
> for "git svn fetch", an svn.authorsfile configuration parameter in
> ~/.gitconfig is used, if no command line argument is specified. However,
> svn.authorsfile is ignored by "git svn clone", though the documentation
> claims that clone "runs init and fetch."
>
> I have confirmed this bug is present in git versions 1.6.0.4 and 1.6.5.1.
>
Does moving the line:
command_oneline('config', 'svn.authorsfile', $_authors) if $_authors;
Immediately prior to the "fetch_all" line before it fix the problem? It
looks strange for it to set it afterwards...
Sam
^ permalink raw reply
* Re: [PATCH] gitk: Add ability to define an alternate temporary directory
From: David Aguilar @ 2009-11-11 4:07 UTC (permalink / raw)
To: Sam Vilain; +Cc: paulus, git
In-Reply-To: <4AFA368F.207@vilain.net>
On Wed, Nov 11, 2009 at 04:59:11PM +1300, Sam Vilain wrote:
> David Aguilar wrote:
> > gitk fails to show diffs when browsing a repository for which
> > we have read-only access. This is due to gitk's assumption
> > that the current directory is always writable.
> >
> > This teaches gitk to honor the GITK_TMPDIR environment
> > variable. This allows users to override the default location
> > used for writing temporary files.
> >
>
> Is there a good reason not to use the common TMPDIR or TMP environment
> variables for this?
I, personally, would not be opposed to that.
The only reason I chose a different variable was that I didn't
want to change the existing behavior (backwards-compat hat on).
Since TMPDIR and TMP are common then we'd be changing the
behavior.
That said, if there's a consensus that the path doesn't matter
much than we could change the behavior. I was just trying to be
careful.
--
David
^ permalink raw reply
* Re: git-svn problem with v1.6.5
From: Sam Vilain @ 2009-11-11 4:02 UTC (permalink / raw)
To: pascal; +Cc: git list
In-Reply-To: <4AF9E7FE.3060701@obry.net>
Pascal Obry wrote:
> Hello,
>
> A git-svn mirror is created using Git v1.6.4. When I copy this mirror
> into another machine which is using v1.6.5 I get the following error:
>
> $ git svn rebase
> fatal: Invalid revision range
> d2cf08bb67e4b7da33a250127aab784f1f2f58d3..refs/remotes/svn/trunk
> rev-list --pretty=raw --no-color --reverse
> d2cf08bb67e4b7da33a250127aab784f1f2f58d3..refs/remotes/svn/trunk --:
> command returned error: 128
>
> Using v1.6.4 instead I have no problem. Any idea to track this problem down?
>
Did you copy the entire directory across using rsync/tar/etc or 'git
clone' ? You'll need to make sure that the 'refs/remotes/*' refs look
exactly the same on the clone as they did on the original import repository.
Sam
^ permalink raw reply
* Re: git-svn not fetching all revisions
From: Sam Vilain @ 2009-11-11 4:00 UTC (permalink / raw)
To: Marcus Better; +Cc: git
In-Reply-To: <4AF9AC1A.5000100@better.se>
Marcus Better wrote:
> The problem is that the trunk was replaced by a branch at some point.
> When I do "git svn clone -s svn://host/repo/project" it only fetches the
> "old" trunk up to the time of the switch, and then stops. Newer
> revisions of the "new" trunk are not fetched and cannot be seen with
> "find-rev".
Yeah. Try doing it in parts - fetch the two stages of the history
explicitly using the revision range arguments to 'git svn fetch' - and
then graft the histories together and fix up with git filter-branch. A
bit of a hassle, but unfortunately there's not much other option...
Sam
^ permalink raw reply
* Re: [PATCH] gitk: Add ability to define an alternate temporary directory
From: Sam Vilain @ 2009-11-11 3:59 UTC (permalink / raw)
To: David Aguilar; +Cc: paulus, git
In-Reply-To: <1257904149-44381-1-git-send-email-davvid@gmail.com>
David Aguilar wrote:
> gitk fails to show diffs when browsing a repository for which
> we have read-only access. This is due to gitk's assumption
> that the current directory is always writable.
>
> This teaches gitk to honor the GITK_TMPDIR environment
> variable. This allows users to override the default location
> used for writing temporary files.
>
Is there a good reason not to use the common TMPDIR or TMP environment
variables for this?
Sam
^ permalink raw reply
* [PATCH] gitk: Document the $GITK_TMPDIR variable
From: David Aguilar @ 2009-11-11 1:49 UTC (permalink / raw)
To: paulus; +Cc: git, David Aguilar
In-Reply-To: <1257904149-44381-1-git-send-email-davvid@gmail.com>
Signed-off-by: David Aguilar <davvid@gmail.com>
---
Documentation/gitk.txt | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index cf465cb..7e184f3 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -100,6 +100,11 @@ Files
Gitk creates the .gitk file in your $HOME directory to store preferences
such as display options, font, and colors.
+Environment Variables
+---------------------
+Gitk honors the $GITK_TMPDIR environment when creating temporary
+files and directories.
+
SEE ALSO
--------
'qgit(1)'::
--
1.6.5.2.180.gc5b3e
^ permalink raw reply related
* [PATCH] gitk: Add ability to define an alternate temporary directory
From: David Aguilar @ 2009-11-11 1:49 UTC (permalink / raw)
To: paulus; +Cc: git, David Aguilar
gitk fails to show diffs when browsing a repository for which
we have read-only access. This is due to gitk's assumption
that the current directory is always writable.
This teaches gitk to honor the GITK_TMPDIR environment
variable. This allows users to override the default location
used for writing temporary files.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
gitk | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index db5ec54..9139ace 100755
--- a/gitk
+++ b/gitk
@@ -3170,11 +3170,15 @@ proc flist_hl {only} {
}
proc gitknewtmpdir {} {
- global diffnum gitktmpdir gitdir
+ global diffnum env gitktmpdir gitdir
if {![info exists gitktmpdir]} {
- set gitktmpdir [file join [file dirname $gitdir] \
- [format ".gitk-tmp.%s" [pid]]]
+ if {[info exists env(GITK_TMPDIR)]} {
+ set tmpdir $env(GITK_TMPDIR)
+ } else {
+ set tmpdir [file dirname $gitdir]
+ }
+ set gitktmpdir [file join $tmpdir [format ".gitk-tmp.%s" [pid]]]
if {[catch {file mkdir $gitktmpdir} err]} {
error_popup "[mc "Error creating temporary directory %s:" $gitktmpdir] $err"
unset gitktmpdir
--
1.6.5.2.180.gc5b3e
^ permalink raw reply related
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