* Re: [PATCH v2] If `egrep` is aliased, temporary disable it in bash.completion
From: Junio C Hamano @ 2012-11-29 17:03 UTC (permalink / raw)
To: Adam Tkac; +Cc: git, SZEDER Gábor, Felipe Contreras
In-Reply-To: <20121129151418.GA19169@redhat.com>
Adam Tkac <atkac@redhat.com> writes:
> Subject: Re: [PATCH v2] If `egrep` is aliased, temporary disable it in bash.completion
The code does not seem to do anything special if it is not aliased,
though, so "If ..." part does not sound correct; perhaps you meant
"just in case egrep is aliased to something totally wacky" or
something?
The script seems to use commands other than 'egrep' that too can be
aliased to do whatever unexpected things. How does this patch get
away without backslashing them all, like
\echo ...
\sed ...
\test ...
\: comment ...
\git args ...
and still fix problems for users? Can't the same solution you would
give to users who alias one of the above to do something undesirable
be applied to those who alias egrep?
Puzzled...
> Originally reported as https://bugzilla.redhat.com/show_bug.cgi?id=863780
>
> Signed-off-by: Adam Tkac <atkac@redhat.com>
> Signed-off-by: Holger Arnold <holgerar@gmail.com>
> ---
> contrib/completion/git-completion.bash | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 0960acc..79073c2 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -565,7 +565,7 @@ __git_complete_strategy ()
> __git_list_all_commands ()
> {
> local i IFS=" "$'\n'
> - for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
> + for i in $(git help -a| \egrep '^ [a-zA-Z0-9]')
> do
> case $i in
> *--*) : helper pattern;;
> --
> 1.8.0
^ permalink raw reply
* [PATCH 2/2 v2] git-remote-mediawiki: escape ", \, and LF in file names
From: Matthieu Moy @ 2012-11-29 17:00 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1354208455-21228-1-git-send-email-Matthieu.Moy@imag.fr>
A mediawiki page can contain, and even start with a " character, we have
to escape it when generating the fast-export stream, as well as \
character. While we're there, also escape newlines, but I don't think we
can get them from MediaWiki pages.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
contrib/mw-to-git/git-remote-mediawiki | 16 +++++++++++++---
contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh | 26 ++++++++++++++++++++++++++
2 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki b/contrib/mw-to-git/git-remote-mediawiki
index 68555d4..094129d 100755
--- a/contrib/mw-to-git/git-remote-mediawiki
+++ b/contrib/mw-to-git/git-remote-mediawiki
@@ -711,6 +711,14 @@ sub fetch_mw_revisions {
return ($n, @revisions);
}
+sub fe_escape_path {
+ my $path = shift;
+ $path =~ s/\\/\\\\/g;
+ $path =~ s/"/\\"/g;
+ $path =~ s/\n/\\n/g;
+ return '"' . $path . '"';
+}
+
sub import_file_revision {
my $commit = shift;
my %commit = %{$commit};
@@ -738,15 +746,17 @@ sub import_file_revision {
print STDOUT "from refs/mediawiki/$remotename/master^0\n";
}
if ($content ne DELETED_CONTENT) {
- print STDOUT "M 644 inline $title.mw\n";
+ print STDOUT "M 644 inline " .
+ fe_escape_path($title . ".mw") . "\n";
literal_data($content);
if (%mediafile) {
- print STDOUT "M 644 inline $mediafile{title}\n";
+ print STDOUT "M 644 inline "
+ . fe_escape_path($mediafile{title}) . "\n";
literal_data_raw($mediafile{content});
}
print STDOUT "\n\n";
} else {
- print STDOUT "D $title.mw\n";
+ print STDOUT "D " . fe_escape_path($title . ".mw") . "\n";
}
# mediawiki revision number in the git note
diff --git a/contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh b/contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh
index 246d47d..b6405ce 100755
--- a/contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh
+++ b/contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh
@@ -318,4 +318,30 @@ test_expect_success 'git push with \ in format control' '
'
+test_expect_success 'fast-import meta-characters in page name (mw -> git)' '
+ wiki_reset &&
+ wiki_editpage \"file\"_\\_foo "expect to be called \"file\"_\\_foo" false &&
+ git clone mediawiki::'"$WIKI_URL"' mw_dir_21 &&
+ test_path_is_file mw_dir_21/\"file\"_\\_foo.mw &&
+ wiki_getallpage ref_page_21 &&
+ test_diff_directories mw_dir_21 ref_page_21
+'
+
+
+test_expect_success 'fast-import meta-characters in page name (git -> mw) ' '
+ wiki_reset &&
+ git clone mediawiki::'"$WIKI_URL"' mw_dir_22 &&
+ (
+ cd mw_dir_22 &&
+ echo "this file is called \"file\"_\\_foo.mw" >\"file\"_\\_foo &&
+ git add . &&
+ git commit -am "file \"file\"_\\_foo" &&
+ git pull &&
+ git push
+ ) &&
+ wiki_getallpage ref_page_22 &&
+ test_diff_directories mw_dir_22 ref_page_22
+'
+
+
test_done
--
1.8.0.319.g8abfee4
^ permalink raw reply related
* [PATCH 1/2] git-fast-import.txt: improve documentation for quoted paths
From: Matthieu Moy @ 2012-11-29 17:00 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <vpq624omjn4.fsf@grenoble-inp.fr>
The documentation mentionned only newlines and double quotes as
characters needing escaping, but the backslash also needs it. Also, the
documentation was not clearly saying that double quotes around the file
name were required (double quotes in the examples could be interpreted as
part of the sentence, not part of the actual string).
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Documentation/git-fast-import.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 6603a7a..35b909c 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -558,8 +558,9 @@ A `<path>` string must use UNIX-style directory separators (forward
slash `/`), may contain any byte other than `LF`, and must not
start with double quote (`"`).
-If an `LF` or double quote must be encoded into `<path>` shell-style
-quoting should be used, e.g. `"path/with\n and \" in it"`.
+If an `LF`, backslash or double quote must be encoded into `<path>`
+shell-style quoting should be used, and the complete name should be
+surrounded with double quotes e.g. `"path/with\n, \\ and \" in it"`.
The value of `<path>` must be in canonical form. That is it must not:
--
1.8.0.319.g8abfee4
^ permalink raw reply related
* Re: [PATCH] git-remote-mediawiki: escape double quotes and LF in file names
From: Matthieu Moy @ 2012-11-29 16:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy5hkqsut.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> +sub fe_escape_path {
>> + my $path = shift;
>> + $path =~ s/"/\\"/g;
>> + $path =~ s/\n/\\n/g;
>> + return $path;
>> +}
>
> Is this sufficient?
>
> My reading of the big comment at the beginning of fast-import.c is
> that you would also want to quote each backslash;
Nice catch, thanks.
Also, I was lacking the double-quotes around $path. In my defense, I had
only read the doc, not the code, and git-fast-import.txt was less
complete than fast-import.c. New patch follows, fixing the doc too.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Junio C Hamano @ 2012-11-29 16:42 UTC (permalink / raw)
To: esr
Cc: Felipe Contreras, Steven Michalske, Thomas Berg, Jeff King,
Shawn Pearce, git
In-Reply-To: <20121129103847.GA9264@thyrsus.com>
"Eric S. Raymond" <esr@thyrsus.com> writes:
> Felipe Contreras <felipe.contreras@gmail.com>:
>> On Thu, Nov 29, 2012 at 8:11 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> > Steven Michalske <smichalske@gmail.com> writes:
>> >
>> >> Would having arbitrary key value pairs be useful in the git data
>> >> model?
>> >
>> > My answer to the question is that it is harmful to the data model,
>> > but the benefit of going against the data model _may_ outweigh the
>> > downside. It is all relative.
>
> My use case for a capability like this is one of the more common ones.
> I want to be able to store a fossil commit-ID inherited from another
> VCS outside the commit comment.
That is exactly why I said it is all relative. If it helps your
application, you can weigh the pros-and-cons yourself and choose to
throw "junk" extended header fields in the commit objects you
create, using hash-object (or commit-tree). You can read it out
using cat-file and do whatever you want to do with it, and modern
Git (v1.5.0 was from early 2007) and tools that are designed to work
with Git know to ignore such "junk" field.
> The absence of a key/value store forces me into some annoying
> kludges.
Do not do annoying kludge, then. Come up with a method to encode
your list of (key,value) tuples into a single string, throw a
custom extra header after all the standard header fields in, perhaps
like this:
tree 0664b9c82d87269b335ff78f32d0e4a504f58cfc
author A U Thor <author@example.xz> 1355999999 +0900
committer C O Mitter <committer@example.xz> 1355999999 +0900
encoding iso-2022-jp
reposurgeon-metadata your-serialized-list-of-key-value-tuples
second-line-of-such-serialization
third-line-of-such-serialization
My first commit
Signed-off-by: A U Thor <author@example.xz>
Signed-off-by: C O Mitter <committer@example.xz>
^ permalink raw reply
* Re: [RFC] git-submodule update: Add --commit option
From: W. Trevor King @ 2012-11-29 16:27 UTC (permalink / raw)
To: Heiko Voigt, Git
Cc: Junio C Hamano, Jeff King, Phil Hord, Shawn Pearce, Jens Lehmann,
Nahor
In-Reply-To: <20121129161216.GB23580@odin.tremily.us>
[-- Attachment #1: Type: text/plain, Size: 571 bytes --]
On Thu, Nov 29, 2012 at 11:12:16AM -0500, W. Trevor King wrote:
> + test "$(git log -1 --oneline)" = "bbdbe2d Updated submodules: submodule"
s/bbdbe2d/cd69713/
I forgot to update the SHA-1 here after tweaking the commit message
format. I'd like to rewrite this test so it won't use the SHA-1, but
this was the quickest way to check that the commit message and gitlink
were both changed appropriately.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] git-remote-mediawiki: escape double quotes and LF in file names
From: Junio C Hamano @ 2012-11-29 16:25 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1354192413-9959-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> A mediawiki page can contain, and even start with a " character, we have
> to escape it when generating the fast-export stream. While we're there,
> also escape newlines, but I don't think we can get them from MediaWiki
> pages.
>
> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
> ---
> contrib/mw-to-git/git-remote-mediawiki | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/contrib/mw-to-git/git-remote-mediawiki b/contrib/mw-to-git/git-remote-mediawiki
> index 68555d4..e7a0e7b 100755
> --- a/contrib/mw-to-git/git-remote-mediawiki
> +++ b/contrib/mw-to-git/git-remote-mediawiki
> @@ -711,6 +711,13 @@ sub fetch_mw_revisions {
> return ($n, @revisions);
> }
>
> +sub fe_escape_path {
> + my $path = shift;
> + $path =~ s/"/\\"/g;
> + $path =~ s/\n/\\n/g;
> + return $path;
> +}
Is this sufficient?
My reading of the big comment at the beginning of fast-import.c is
that you would also want to quote each backslash; otherwise a
character (or an octal) after it will be taken as a C-style quoted
special letter, no?
> sub import_file_revision {
> my $commit = shift;
> my %commit = %{$commit};
> @@ -738,15 +745,17 @@ sub import_file_revision {
> print STDOUT "from refs/mediawiki/$remotename/master^0\n";
> }
> if ($content ne DELETED_CONTENT) {
> - print STDOUT "M 644 inline $title.mw\n";
> + print STDOUT "M 644 inline " .
> + fe_escape_path($title . ".mw") . "\n";
> literal_data($content);
> if (%mediafile) {
> - print STDOUT "M 644 inline $mediafile{title}\n";
> + print STDOUT "M 644 inline "
> + . fe_escape_path($mediafile{title}) . "\n";
> literal_data_raw($mediafile{content});
> }
> print STDOUT "\n\n";
> } else {
> - print STDOUT "D $title.mw\n";
> + print STDOUT "D " . fe_escape_path($title . ".mw") . "\n";
> }
>
> # mediawiki revision number in the git note
^ permalink raw reply
* Re: [RFC] git-submodule update: Add --commit option
From: W. Trevor King @ 2012-11-29 16:21 UTC (permalink / raw)
To: Heiko Voigt, Git
Cc: Junio C Hamano, Jeff King, Phil Hord, Shawn Pearce, Jens Lehmann,
Nahor
In-Reply-To: <20121129161216.GB23580@odin.tremily.us>
[-- Attachment #1: Type: text/plain, Size: 443 bytes --]
On Thu, Nov 29, 2012 at 11:12:16AM -0500, W. Trevor King wrote:
> + test "a" = "b"
This kills the test (with --immediate) so you can look at the
generated commit. If you actually want the test to pass (e.g. if this
becomes a PATCH and not an RFC), this line should be removed.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] t4049: avoid test failures on filemode challenged file systems (Windows)
From: Junio C Hamano @ 2012-11-29 16:13 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Antoine Pelisse
In-Reply-To: <50B71B33.1090000@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
>> It turns out that there are at least two bugs in the diffstat
>> counting code. This series comes on top of the earlier 74faaa1 (Fix
>> "git diff --stat" for interesting - but empty - file changes,
>> 2012-10-17) to fix them.
>
> The tests still fail on Windows. I am not sure whether there is a
> difference in comparing the file system against the index or a commit.
> If there is, then the updated tests might not test the same thing.
The hunks in the patch look fine. The last one that tests unmerged
entries do not have to have "chmod" if it gives you trouble (you
would need to reduce number of files from 4 to 3 if you go that
route, I think).
^ permalink raw reply
* [RFC] git-submodule update: Add --commit option
From: W. Trevor King @ 2012-11-29 16:12 UTC (permalink / raw)
To: Heiko Voigt, Git
Cc: Junio C Hamano, Jeff King, Phil Hord, Shawn Pearce, Jens Lehmann,
Nahor
In-Reply-To: <cover.1354130656.git.wking@tremily.us>
[-- Attachment #1: Type: text/plain, Size: 6638 bytes --]
This option triggers automatic commits when `submodule update` changes
any gitlinked submodule SHA-1s. The commit message contains a
`shortlog` summary of the changes for each changed submodule.
---
On Tue, Nov 27, 2012 at 07:51:42PM +0100, Heiko Voigt wrote:
> BTW, I am more and more convinced that an automatically manufactured
> commit on update with --branch should be the default. What do other
> think? Sascha raised a concern that he would not want this, but as far as
> I understood he let the CI-server do that so I see no downside to
> natively adding that to git. People who want to manually craft those
> commits can still amend the generated commit. Since this is all about
> helping people keeping their submodules updated why not go the full way?
Here's a first pass (without documentation) for automatic commits on
submodule updates. There have been a number of requests for
automatically-committed submodule updates due to submodule upstreams.
This patch shows how you can do that (if applied with my `submodule
update --remote` series), and reuse the same logic to automatically
commit changes due to local submodule changes (as shown here in the
new test).
I think the logic is pretty good, but the implementation is pretty
ugly due to POSIX shell variable limitations. I'm basically trying to
pass an array of [(name, sm_path, sha1, subsha1), ...] into
commit_changes(). I though about perling-out in commit_changes(), but
I lack sufficient perl-fu to know how to tie clear_local_git_env, cd,
and shortlog up in a single open2 call. If anyone can give me some
implementation pointers, that would be very helpful.
This is against v1.8.0 (without my --remote series). To apply on top
of the --remote series, you'd have to save the original gitlinked
$sha1 and use that original value when constructing changed_modules.
I can attach this to the end of the --remote series if desired, but I
think this patch could also stand on its own.
Obviously this still needs documentation, etc., but I wanted feedback
on the implementation before I started digging into that.
Cheers,
Trevor
---
git-submodule.sh | 67 ++++++++++++++++++++++++++++++++++++++++++++-
t/t7406-submodule-update.sh | 19 +++++++++++++
2 files changed, 85 insertions(+), 1 deletion(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..d9a59af 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -8,7 +8,7 @@ dashless=$(basename "$0" | sed -e 's/-/ /')
USAGE="[--quiet] add [-b branch] [-f|--force] [--reference <repository>] [--] <repository> [<path>]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
or: $dashless [--quiet] init [--] [<path>...]
- or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
+ or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--commit] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
or: $dashless [--quiet] foreach [--recursive] <command>
or: $dashless [--quiet] sync [--] [<path>...]"
@@ -21,6 +21,7 @@ require_work_tree
command=
branch=
force=
+commit=
reference=
cached=
recursive=
@@ -240,6 +241,52 @@ module_clone()
}
#
+# Commit changed submodule gitlinks
+#
+# $1 = name-a;sha1-a;subsha1-a\n[name-b;sha1-b;subsha1-b\n...]
+#
+commit_changes()
+{
+ echo "commiting $1"
+ OIFS="$IFS"
+ IFS=";"
+ paths=$(echo "$1" |
+ while read name sm_path sha1 subsha1
+ do
+ echo "$sm_path"
+ done
+ )
+ names=$(echo "$1" |
+ while read name sm_path sha1 subsha1
+ do
+ printf ' %s' "$name"
+ done
+ )
+ summary="$(eval_gettext "Updated submodules:")$names"
+ body=$(echo "$1" |
+ while read name sm_path sha1 subsha1
+ do
+ if test "$name" = "$sm_path"
+ then
+ printf 'Changes to %s:\n\n' "$name"
+ else
+ printf 'Changes to %s (%s):\n\n' "$name" "$sm_path"
+ fi
+ (
+ clear_local_git_env
+ cd "$sm_path" &&
+ git shortlog "${sha1}..${subsha1}" ||
+ die "$(eval_gettext "Unable to generate shortlog in submodule path '\$sm_path'")"
+ )
+ done
+ )
+ IFS="$OIFS"
+ message="$(printf '%s\n\n%s\n' "$summary" "$body")"
+ echo "message: [$message]"
+ git commit -m "$message" $paths
+}
+
+#
# Add a new submodule to the working tree, .gitmodules and the index
#
# $@ = repo path
@@ -515,6 +562,9 @@ cmd_update()
-f|--force)
force=$1
;;
+ --commit)
+ commit=1
+ ;;
-r|--rebase)
update="rebase"
;;
@@ -557,6 +607,7 @@ cmd_update()
fi
cloned_modules=
+ changed_modules=
module_list "$@" | {
err=
while read mode sha1 stage sm_path
@@ -660,6 +711,15 @@ Maybe you want to use 'update --init'?")"
err="${err};$die_msg"
continue
fi
+
+ subsha1=$(clear_local_git_env; cd "$sm_path" &&
+ git rev-parse --verify HEAD) ||
+ die "$(eval_gettext "Unable to find new revision in submodule path '\$sm_path'")"
+
+ if test "$subsha1" != "$sha1"
+ then
+ changed_modules=$(printf '%s%s\n' "$changed_modules" "$name;$sm_path;$sha1;$subsha1")
+ fi
fi
if test -n "$recursive"
@@ -680,6 +740,11 @@ Maybe you want to use 'update --init'?")"
fi
done
+ if test -z "$err" -a -n "$commit" -a -n "$changed_modules"
+ then
+ commit_changes "$changed_modules"
+ fi
+
if test -n "$err"
then
OIFS=$IFS
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index 1542653..4c8bb5d 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -163,6 +163,25 @@ test_expect_success 'submodule update --merge staying on master' '
)
'
+test_expect_success 'submodule update --commit --rebase should commit gitlink changes' '
+ (cd super/submodule &&
+ git reset --hard HEAD~1 &&
+ echo "local change" > local-file &&
+ git add local-file &&
+ test_tick &&
+ git commit -m "local change"
+ ) &&
+ (cd super &&
+ git submodule update --commit --rebase submodule &&
+ test "$(git log -1 --oneline)" = "bbdbe2d Updated submodules: submodule"
+ ) &&
+ (cd submodule &&
+ git remote add super-submodule ../super/submodule &&
+ git pull super-submodule master
+ ) &&
+ test "a" = "b"
+'
+
test_expect_success 'submodule update - rebase in .git/config' '
(cd super &&
git config submodule.submodule.update rebase
--
1.8.0.1.gaaf2ac7.dirty
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* [PATCH] DESTDIR support in contrib/subtree/Makefile
From: Adam Tkac @ 2012-11-29 15:41 UTC (permalink / raw)
To: git
Signed-off-by: Adam Tkac <atkac@redhat.com>
---
It is a good habit in Makefiles to honor DESTDIR variable to support
`make DESTDIR=/instalroot install`
syntax.
Comments are welcomed.
Regards, Adam
contrib/subtree/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile
index 05cdd5c..36ae3e4 100644
--- a/contrib/subtree/Makefile
+++ b/contrib/subtree/Makefile
@@ -30,12 +30,12 @@ $(GIT_SUBTREE): $(GIT_SUBTREE_SH)
doc: $(GIT_SUBTREE_DOC)
install: $(GIT_SUBTREE)
- $(INSTALL) -m 755 $(GIT_SUBTREE) $(libexecdir)
+ $(INSTALL) -m 755 $(GIT_SUBTREE) $(DESTDIR)$(libexecdir)
install-doc: install-man
install-man: $(GIT_SUBTREE_DOC)
- $(INSTALL) -m 644 $^ $(man1dir)
+ $(INSTALL) -m 644 $^ $(DESTDIR)$(man1dir)
$(GIT_SUBTREE_DOC): $(GIT_SUBTREE_XML)
xmlto -m $(MANPAGE_NORMAL_XSL) man $^
--
1.8.0
--
Adam Tkac, Red Hat, Inc.
^ permalink raw reply related
* [PATCH v2] If `egrep` is aliased, temporary disable it in bash.completion
From: Adam Tkac @ 2012-11-29 15:14 UTC (permalink / raw)
To: git
Originally reported as https://bugzilla.redhat.com/show_bug.cgi?id=863780
Signed-off-by: Adam Tkac <atkac@redhat.com>
Signed-off-by: Holger Arnold <holgerar@gmail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0960acc..79073c2 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -565,7 +565,7 @@ __git_complete_strategy ()
__git_list_all_commands ()
{
local i IFS=" "$'\n'
- for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
+ for i in $(git help -a| \egrep '^ [a-zA-Z0-9]')
do
case $i in
*--*) : helper pattern;;
--
1.8.0
--
Adam Tkac, Red Hat, Inc.
^ permalink raw reply related
* gitk: highlighting commits "touching path" with globs doesn't work for files list
From: Yaroslav Halchenko @ 2012-11-29 13:51 UTC (permalink / raw)
To: git
Hi GIT Gurus,
Highlighting files (in patch view) and commits which modified those
files is a really nice feature to have. Often it is needed to
highlight based on a glob expression for files, e.g. '*Makefile*'
-- that seems to highlight the commits but files in the patch view
are no longer highlighted, which significantly reduces usefulness of
such a feature.
Also, those choices (Exact/IgnCase/Regexp) seems to have no relation
with the edit box when looking for "touching path" files, so shouldn't
it be somehow disabled/emptied to avoid users trying to create the
ultimate filepattern regexp for no good reason? (the same for next
field on where to search through -- All Fields/... ) ;)
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
^ permalink raw reply
* Re: git describe not matching git log
From: Michael J Gruber @ 2012-11-29 14:06 UTC (permalink / raw)
To: Steven Penny; +Cc: git, Jeff King
In-Reply-To: <CAAXzdLWNb7E1qincviX5y_uEsT71bbepuUtLR7Q_+Exm8Od6yw@mail.gmail.com>
Steven Penny venit, vidit, dixit 29.11.2012 10:04:
> It seems "git describe" is not matching "git log" as detailed in the help, in
> some cases. From git describe --help
>
> [torvalds@g5 git]$ git describe parent
> v1.0.4-14-g2414721
>
> The number of additional commits is the number of commits which would
> be displayed by "git log v1.0.4..parent".
>
> GOOD
>
> $ git clone git://github.com/antirez/redis.git
>
> $ cd redis
>
> $ git describe unstable
> with-deprecated-diskstore-1050-g7383c3b
>
> $ git log --oneline with-deprecated-diskstore..unstable | wc
> 1050 11779 78709
>
> BAD
>
> $ git clone git://github.com/git/git.git
>
> $ cd git
>
> $ git describe master
> v1.8.0.1-264-g226dcb5
>
> $ git log --oneline v1.8.0.1..master | wc
> 260 1650 14154
>
This is due to date skew: git-describe uses "insert_by_date" when it
traverses the dag, and this can go wrong.
Interestingling, this seems to get fixed by using Jeff's generation
numbers and "insert_by_generation" instead, so it does seem go wrong for
226dcb5~60 or so. git-describe's logic is a bit convoluted and may
depend on how we insert when generation numbers are the same... Have to
do more testing.
Michael
^ permalink raw reply
* Ubuntu: gitweb always looks for projects in /var/cache/git (“404 - no projects found”)
From: Alfonso Muñoz-Pomer Fuentes @ 2012-11-29 13:55 UTC (permalink / raw)
To: git
I’ve discovered this weird behaviour in gitweb and documented a workaround in
StackOverflow:
http://stackoverflow.com/questions/13609475/ubuntu-gitweb-always-looks-for-projects-in-var-cache-git-404-no-projects-f
Basically, the variable $projectroot in gitweb.cgi in the beginning is reset to
the system default value in git_get_projects_list, when it is declared again.
Is this a known bug? Or am I missing something?
^ permalink raw reply
* Re: reposurgeon now writes Subversion repositories
From: Eric S. Raymond @ 2012-11-29 13:55 UTC (permalink / raw)
To: Daniel Shahaf; +Cc: dev, git
In-Reply-To: <20121129134203.GJ3424@lp-shahaf.local>
Daniel Shahaf <danielsh@elego.de>:
> I don't see the kludge here --- git has a "author" != "committer"
> distinction, svn doesn't, so if you want to grow that distinction the
> most natural way is a new property. Storing additional information in
> svn:author is a separate issue.
See my advocacy to Branko of going to Internet-scoped IDs. The kludge
would be maintaining the local and Internet-scoped identifications
as different properties and having to decide which one to key on
ad-hoc. Nothing to do with the author/committer distinction.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* AW: reposurgeon now writes Subversion repositories
From: Markus Schaber @ 2012-11-29 13:43 UTC (permalink / raw)
To: esr@thyrsus.com, Daniel Shahaf
Cc: dev@subversion.apache.org, git@vger.kernel.org
In-Reply-To: <20121129114637.GB9264@thyrsus.com>
Hi,
Von: Eric S. Raymond [mailto:esr@thyrsus.com]
> > How does reposurgeon handle empty directories with (node) properties?
>
> Currently by ignoring all of them except svn:ignore, which it turns
> into .gitignore content on the gitspace side. And now vice-versa, too.
>
> Not clear what else it *could* do. I'd take suggestions.
AFAIR, SvnBridge (which bridges SVN to Team Foundation Server for CodePlex) creates a hidden .svnproperties file where all the properties of the directory and files are stored.
I'm not really sure, but maybe this could be used as some standard to bridge svn properties to non-svn VCSes.
Best regards
Markus Schaber
CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH
Inspiring Automation Solutions
3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50
E-Mail: m.schaber@codesys.com | Web: http://www.codesys.com
CODESYS internet forum: http://forum.codesys.com
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
^ permalink raw reply
* Re: reposurgeon now writes Subversion repositories
From: Daniel Shahaf @ 2012-11-29 13:42 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: dev, git
In-Reply-To: <20121129114637.GB9264@thyrsus.com>
(note, other half of the thread is on dev@svn only..)
Eric S. Raymond wrote on Thu, Nov 29, 2012 at 06:46:37 -0500:
> Daniel Shahaf <danielsh@elego.de>:
> > You might also seek community consensus to reserve an svn:foo name for
> > the "original author" property --- perhaps svn:original-author --- so
> > that reposurgeon and other git->svn tools can interoperate in the way
> > they transfer the "original author" information.
>
> OK. But I like the idea of letting the users set their own author
> content string better. Instead of another layer of kluges, why
I don't see the kludge here --- git has a "author" != "committer"
distinction, svn doesn't, so if you want to grow that distinction the
most natural way is a new property. Storing additional information in
svn:author is a separate issue.
> > > Subversion has a concept of "flows"; that is, named segments of
> > > history corresponding to files or directories that are created when
> > > the path is added, cloned when the path is copied, and deleted when
> > > the path is deleted. This information is not preserved in import
> > > streams or the internal representation that reposurgeon uses. Thus,
> > > after editing, the flow boundaries of a Subversion history may be
> > > arbitrarily changed.
> > >
> > > This is me being obsessive about documenting the details. I think it
> > > is doubtful that most Subversion users even know flows exist.
> >
> > I think you're saying that adds might turn into copies, and vice-versa.
> > That is something users would notice --- it is certainly exposed in the
> > UI --- even though node-id's are not exposed to clients.
>
> I'm saying nobody thinks of flows when they do branch copies. It's
> not just that users don't see node IDs, it's that no part of most users'
> mental model of how Subversion works resembles them.
I'm still not sure what you have in mind. I note that 'svn log' and
'svn blame' cross both file copies and branch creation --- that's one
effect of "'svn cp foo bar; svn ci' causes bar to be related to foo".
> --
> <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* [PATCH] git-remote-mediawiki: escape double quotes and LF in file names
From: Matthieu Moy @ 2012-11-29 12:33 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
A mediawiki page can contain, and even start with a " character, we have
to escape it when generating the fast-export stream. While we're there,
also escape newlines, but I don't think we can get them from MediaWiki
pages.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
contrib/mw-to-git/git-remote-mediawiki | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki b/contrib/mw-to-git/git-remote-mediawiki
index 68555d4..e7a0e7b 100755
--- a/contrib/mw-to-git/git-remote-mediawiki
+++ b/contrib/mw-to-git/git-remote-mediawiki
@@ -711,6 +711,13 @@ sub fetch_mw_revisions {
return ($n, @revisions);
}
+sub fe_escape_path {
+ my $path = shift;
+ $path =~ s/"/\\"/g;
+ $path =~ s/\n/\\n/g;
+ return $path;
+}
+
sub import_file_revision {
my $commit = shift;
my %commit = %{$commit};
@@ -738,15 +745,17 @@ sub import_file_revision {
print STDOUT "from refs/mediawiki/$remotename/master^0\n";
}
if ($content ne DELETED_CONTENT) {
- print STDOUT "M 644 inline $title.mw\n";
+ print STDOUT "M 644 inline " .
+ fe_escape_path($title . ".mw") . "\n";
literal_data($content);
if (%mediafile) {
- print STDOUT "M 644 inline $mediafile{title}\n";
+ print STDOUT "M 644 inline "
+ . fe_escape_path($mediafile{title}) . "\n";
literal_data_raw($mediafile{content});
}
print STDOUT "\n\n";
} else {
- print STDOUT "D $title.mw\n";
+ print STDOUT "D " . fe_escape_path($title . ".mw") . "\n";
}
# mediawiki revision number in the git note
--
1.8.0.319.g8abfee4
^ permalink raw reply related
* Re: reposurgeon now writes Subversion repositories
From: Eric S. Raymond @ 2012-11-29 11:46 UTC (permalink / raw)
To: Daniel Shahaf; +Cc: dev, git
In-Reply-To: <20121129075829.GE3424@lp-shahaf.local>
Daniel Shahaf <danielsh@elego.de>:
> > Subversion's metadata doesn't have separate author and committer
> > properties, and doesn't store anything but a Unix user ID as
> > attribution. I don't see any way around this.
>
> You're not fully informed, then.
>
> 1) svn:author revprops can contain any UTF-8 string. They are not
> restricted to Unix user id's. (For example, they can contain full
> names, if the administrator so chooses.)
Right. At one point during the development of this feature I was
accidentally storing the full email field in this property. So I
already knew that this is allowed at some level.
And, I have no trouble believing that svn log will cheerfully echo
anything that I choose to stuff in that field.
But...
(1) How much work would it be it to set up a Subversion installation
so that when I svn commit, the tool does the right thing, e.g. puts
a DVCS-style fullname/email string in there?
(2) Have the tools been tested for bugs arising from having whitespace
in that data?
Really, if it's actually easy to set up DVCS-style globally unique IDs you
Subversion guys ought to be shouting it from the housetops. The absence
of this capability is a serious PITA in several situations, including
for example migrating projects between forges.
RFC: If I wrote a patch that let Subversion users set their own
content string for the author field in ~/.subversion/config, would
you merge it? Because I'd totally write that.
> 2) You can define custom revision properties. In your case, the easiest
> way would be to set an reposurgeon:author property, alongside the
> svn:author property.
Yeah, sure, I've assumed all along this wouldn't break if I tried it.
If I actually thought you guys were capable of designing a data model
with a perfectly general-looking store of key/value pairs and then
arbitrarily restricting the key set so I couldn't do that, I'd almost
have to find each and every one of you and kick your asses into next
Tuesday on account of blatant stupidity. I have no such plans :-).
But...what good does this capability do? OK, it would assist
round-tripping back to gitspace, but while that's kind of cool I don't
see any help for a normal Subversion workflow here.
> You might also seek community consensus to reserve an svn:foo name for
> the "original author" property --- perhaps svn:original-author --- so
> that reposurgeon and other git->svn tools can interoperate in the way
> they transfer the "original author" information.
OK. But I like the idea of letting the users set their own author
content string better. Instead of another layer of kluges, why
shouldn't Subversion join the DVCSes in the happy land of
Internet-scoped attributions?
> How does reposurgeon handle empty directories with (node) properties?
Currently by ignoring all of them except svn:ignore, which it turns
into .gitignore content on the gitspace side. And now vice-versa, too.
Not clear what else it *could* do. I'd take suggestions.
> > Subversion has a concept of "flows"; that is, named segments of
> > history corresponding to files or directories that are created when
> > the path is added, cloned when the path is copied, and deleted when
> > the path is deleted. This information is not preserved in import
> > streams or the internal representation that reposurgeon uses. Thus,
> > after editing, the flow boundaries of a Subversion history may be
> > arbitrarily changed.
> >
> > This is me being obsessive about documenting the details. I think it
> > is doubtful that most Subversion users even know flows exist.
>
> I think you're saying that adds might turn into copies, and vice-versa.
> That is something users would notice --- it is certainly exposed in the
> UI --- even though node-id's are not exposed to clients.
I'm saying nobody thinks of flows when they do branch copies. It's
not just that users don't see node IDs, it's that no part of most users'
mental model of how Subversion works resembles them.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [RFC/PATCH] l10n: de.po: translate 825 new messages
From: Michael J Gruber @ 2012-11-29 11:40 UTC (permalink / raw)
To: Ralf Thielow; +Cc: trast, git, jk, stimming
In-Reply-To: <1354126970-5356-1-git-send-email-ralf.thielow@gmail.com>
Ralf Thielow venit, vidit, dixit 28.11.2012 19:22:
>> Hi Ralf,
>>
>> This is the middle third of my review. Sorry for the long wait! I hope
>> it can still be useful.
>>
>
> Hi Thomas,
>
> no problem. Thanks for your review. Of course it's very useful.
> Some of the mistakes I made are so obvious that I can't say what
> I've had in mind when translation these messages :/ But some aren't,
> so thanks for the further explanations within your review.
>
>> I don't really share your apparent aversion to just using "<n>" :-)
> I don't really have one :) so I'm fine with using <n>.
>
>> This would be a good time to settle on a good translation for
>> "rewriting". Perhaps "neu schreiben". "Überschreiben" to me implies
> On some other places we actually use "neu schreiben".
How about "umschreiben"? "neu schreiben" is more like "write from
scratch", whereas "rewrite" is more often about taking a given base and
modifying it.
>>> -msgstr ""
>>> +msgstr "erzeugt kleinere Pakete"
>>
>> Smaller is not really the point: they are packs that do not have the
> [...]
>> You could call them "abgespeckt" ;-)
> I used "dünner"!?
>
> Furthermore I've unified the translation of "email" to "Email",
> not "eMail". You'll see the result below. I hope I haven't missed
> something.
>
> Thanks,
> Ralf
>
> ---
> po/de.po | 95 ++++++++++++++++++++++++++++++++--------------------------------
> 1 file changed, 47 insertions(+), 48 deletions(-)
>
> diff --git a/po/de.po b/po/de.po
> index fe6e8cf..1a75ea2 100644
> --- a/po/de.po
> +++ b/po/de.po
...
> #: builtin/fsck.c:608
> msgid "git fsck [options] [<object>...]"
> @@ -4521,7 +4521,7 @@ msgstr "erzeugt Kopfknoten des Referenzprotokolls (Standard)"
>
> #: builtin/fsck.c:620
> msgid "also consider packs and alternate objects"
> -msgstr "betrachtet auch Pakete und wechselnde Objekte"
> +msgstr ""
"alternate objects" (hopefully) don't change much, so that "wechselnde"
is misleading.
Is there a set translation standard for the "alternative object store"
mechanism in git (alternates)? Otherwise "alternative Objekte" may be
choice which is close to the original and conveys the aspect that they
are objects from an alternative store.
> #: builtin/grep.c:817
> msgid "indicate hit with exit status without output"
> -msgstr "kennzeichnet Übereinstimmungen mit Beendigungsstatus, ohne Ausgabe"
> +msgstr "zeigt Übereinstimmungen mit Beendigungsstatus, ohne Ausgabe"
maybe "zeigt Übereinstimmungen nur durch Beendigungsstatus an"
"mit" sounds like "including", "additionally". Also, nothing is shown
("zeigt"), but something is indicated ("zeigt an").
> #: builtin/log.c:102
> msgid "decorate options"
> -msgstr "Ausgabeoptionen"
> +msgstr "decorate Optionen"
"decorate-Optionen" (unless we want to match the standard set by the bad
old K&R translation ;) )
> #: builtin/log.c:1098
> msgid "add To: header"
> -msgstr "fügt Kopfteil \"To:\" hinzu"
> +msgstr "fügt \"To:\" Header hinzu"
Here and in the following I'd a "-", e.g.
msgstr "fügt \"To:\"-Header hinzu"
> #: builtin/log.c:1100
> msgid "add Cc: header"
> -msgstr "fügt Kopteil \"Cc:\" hinzu"
> +msgstr "fügt \"Cc:\" Header hinzu"
...
> -"lädt Konfiguration für <Kommando> beim Überschreiben von Versionen "
> +"lädt Konfiguration für <Kommando> beim Neuschreiben von Versionen "
> "(impliziert --stdin)"
"Umschreiben" (if that becomes the agreed upon term for "rewrite").
Just my two Pfennig ;)
Michael
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Eric S. Raymond @ 2012-11-29 10:38 UTC (permalink / raw)
To: Felipe Contreras
Cc: Junio C Hamano, Steven Michalske, Thomas Berg, Jeff King,
Shawn Pearce, git
In-Reply-To: <CAMP44s3ShoR7iR5QLYn_u+u_nNGnS1jumpt+iseWYKx0PX9UEA@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com>:
> On Thu, Nov 29, 2012 at 8:11 AM, Junio C Hamano <gitster@pobox.com> wrote:
> > Steven Michalske <smichalske@gmail.com> writes:
> >
> >> Would having arbitrary key value pairs be useful in the git data
> >> model?
> >
> > My answer to the question is that it is harmful to the data model,
> > but the benefit of going against the data model _may_ outweigh the
> > downside. It is all relative.
>
> If git doesn't provide the capability, people will keep using the
> commit message to store that extra information, which I would think is
> even more harmful. An standard 'commit-extra' note or something would
> help deal with that.
Agreed.
My use case for a capability like this is one of the more common ones.
I want to be able to store a fossil commit-ID inherited from another
VCS outside the commit comment. The absence of a key/value store forces
me into some annoying kludges.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: reposurgeon now writes Subversion repositories
From: Branko Čibej @ 2012-11-29 10:31 UTC (permalink / raw)
To: dev; +Cc: Eric S. Raymond, git
In-Reply-To: <20121129075829.GE3424@lp-shahaf.local>
On 29.11.2012 08:58, Daniel Shahaf wrote:
> I think you're saying that adds might turn into copies, and
> vice-versa. That is something users would notice --- it is certainly
> exposed in the UI --- even though node-id's are not exposed to clients.
... yet. But there are plans underway to expose them.
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
^ permalink raw reply
* Re: Please pull l10n updates for 1.8.1 round 1
From: Jiang Xin @ 2012-11-29 9:40 UTC (permalink / raw)
To: Trần Ngọc Quân
Cc: Junio C Hamano, Git List, Peter Krefting,
Nguyễn Thái Ngọc Duy
In-Reply-To: <50b70eb8.46c5440a.38b1.3f66@mx.google.com>
Hi,
New pull request with updates on Vietnamese for git 1.8.1 from Tran:
The following changes since commit 2d242fb3fc19fc9ba046accdd9210be8b9913f64:
Update draft release notes for 1.8.1 (2012-11-21 13:32:58 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po master
for you to fetch changes up to f93483ac94c21660422a19175f67cd3f8e87c531:
Merge git://github.com/vnwildman/git (2012-11-29 16:25:40 +0800)
----------------------------------------------------------------
Jiang Xin (2):
l10n: Update git.pot (14 new, 3 removed messages)
Merge git://github.com/vnwildman/git
Peter Krefting (1):
l10n: Update Swedish translation (1975t0f0u)
Tran Ngoc Quan (2):
l10n: vi.po: update to git-v1.7.12-437-g1084f
l10n: vi.po: Update follow git-v1.8.0-273-g2d242
po/git.pot | 1224 ++++++++++++++++++++------------------
po/sv.po | 1246 ++++++++++++++++++++------------------
po/vi.po | 1951 +++++++++++++++++++++++++++++++-----------------------------
3 files changed, 2305 insertions(+), 2116 deletions(-)
2012/11/29 Trần Ngọc Quân <vnwildman@gmail.com>:
> Hello JX,
> You missing pull from my repo (2 commits instead of one, v1.7 and v1.8): dcc52a0449c7ee10690e23152e63b9798f8a332f
>
> $ git log -n 2
> commit dcc52a0449c7ee10690e23152e63b9798f8a332f
> Author: Tran Ngoc Quan <vnwildman@gmail.com>
> Date: Sat Nov 24 07:37:35 2012 +0700
>
> l10n: vi.po: Update follow git-v1.8.0-273-g2d242
>
> Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
>
> commit 131fa518f10521b4a534863331decbfef2875f24
> Author: Tran Ngoc Quan <vnwildman@gmail.com>
> Date: Wed Oct 31 08:19:59 2012 +0700
>
> l10n: vi.po: update to git-v1.7.12-437-g1084f
>
> * updated all new messages (1967t0f0u)
> * make quote become more good-looking
>
> Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
>
> https://github.com/vnwildman/git.git master
> Thanks,
> Trần Ngọc Quân
>
> -----Original Message-----
> From: Jiang Xin [mailto:worldhello.net@gmail.com]
> Sent: Thursday, November 29, 2012 8:19 AM
> To: Junio C Hamano
> Cc: Git List; Peter Krefting; Trần Ngọc Quân; Nguyễn Thái Ngọc Duy
> Subject: Please pull l10n updates for 1.8.1 round 1
>
> Hi, Junio
>
> The following changes since commit 2d242fb3fc19fc9ba046accdd9210be8b9913f64:
>
> Update draft release notes for 1.8.1 (2012-11-21 13:32:58 -0800)
>
> are available in the git repository at:
>
> git://github.com/git-l10n/git-po.git master
>
> for you to fetch changes up to 647d5183b8dc36b38d19c7a3f388108f245b11d3:
>
> l10n: Update Swedish translation (1975t0f0u) (2012-11-23 08:59:11 +0100)
>
> ----------------------------------------------------------------
> Jiang Xin (1):
> l10n: Update git.pot (14 new, 3 removed messages)
>
> Peter Krefting (1):
> l10n: Update Swedish translation (1975t0f0u)
>
> Tran Ngoc Quan (1):
> l10n: vi.po: update to git-v1.7.12-437-g1084f
>
> po/git.pot | 1224 ++++++++++++++++++++++++----------------------
> po/sv.po | 1246 +++++++++++++++++++++++++----------------------
> po/vi.po | 1597 ++++++++++++++++++++++++++++++------------------------------
> 3 files changed, 2097 insertions(+), 1970 deletions(-)
>
> --
> Jiang Xin
>
^ permalink raw reply
* git describe not matching git log
From: Steven Penny @ 2012-11-29 9:04 UTC (permalink / raw)
To: git
It seems "git describe" is not matching "git log" as detailed in the help, in
some cases. From git describe --help
[torvalds@g5 git]$ git describe parent
v1.0.4-14-g2414721
The number of additional commits is the number of commits which would
be displayed by "git log v1.0.4..parent".
GOOD
$ git clone git://github.com/antirez/redis.git
$ cd redis
$ git describe unstable
with-deprecated-diskstore-1050-g7383c3b
$ git log --oneline with-deprecated-diskstore..unstable | wc
1050 11779 78709
BAD
$ git clone git://github.com/git/git.git
$ cd git
$ git describe master
v1.8.0.1-264-g226dcb5
$ git log --oneline v1.8.0.1..master | wc
260 1650 14154
^ 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