* Re: General support for ! in git-config values
From: Junio C Hamano @ 2012-02-01 22:21 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Jeff King, Git Mailing List
In-Reply-To: <CACBZZX5mX55Rh8b2GYv7wKbCCypCkrn5AiM9BpXydgcYxHWdQA@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>> I.e., everything pertaining to "!" happens after we get the config
>> string. So what is it that you want "git config --with-exec" to do?
>
> I agree that that's how it should work, I just suggested --with-exec
> in case anyone complained about the backwards compatibility issue of
> changing the meaning of "!" for existing configs.
Now you made me utterly confused.
What "backwards compatibility" issue do you have in mind? If I name
myself '!me' with "user.name = !me", do I suddenly break backwards
compatibility of Git with previous versions somehow? If so how?
The --with-exec option you talk about seems to me the option about the
backward compatibility of the _calling script_ of "git config". The old
version of git-blorl script may have used foo.bar as a mere string, but a
new version of it may (optionally) interpret foo.bar's value in a special
way when it begins with a "!", introducing a backward compatibility issues
to git-blorl script, and users who want to take advantage of that feature
may want to run it as "git-blorl --with-exec", and the relevant part of
the "git-blorl" script might look like this:
foo_bar=$(git config foo.bar)
case "$with_exec,$foo_bar" in
yes,\!*)
foo_bar=$(eval ${foo_bar#\!}) ;;
esac
... then do something interesting using $foo_bar ...
^ permalink raw reply
* Re: [PATCH] Don't search files with an unset "grep" attribute
From: Jeff King @ 2012-02-01 22:14 UTC (permalink / raw)
To: Conrad Irwin; +Cc: Junio C Hamano, git, Nguyen Thai Ngoc Duy, Dov Grobgeld
In-Reply-To: <CAOTq_ptj06aNGsQRjV0fVRxnQFBHmU2FFSXwWDUUk9MM77k2LQ@mail.gmail.com>
On Wed, Feb 01, 2012 at 01:28:47AM -0800, Conrad Irwin wrote:
> > But there's more. Respecting binary attributes does mean looking up
> > attributes for _every_ file. And that has a noticeable impact. My
> > best-of-five for "git grep foo" on linux-2.6 went from 0.302s to 0.392s.
> > Yuck.
>
> The first time I introduced this behaviour[1], I made it conditional
> on a preference — those who wanted "good" grep could set the
> preference, while those who wanted "fast" grep could not. I think
> that's not a good idea, though if the performance issues are
> show-stoppers, I'd suggest the opposite preference (so speed-freaks
> can disable the checks).
I've been able to get somewhat better performance by hoisting the
attribute lookup into the parent thread. That means it happens in order
(which lets the attr code's stack optimizations work), and there's no
lock contention.
I'll post finished patches with numbers in a few minutes.
> Tests from [1] included below in case they're still useful (they pass
> with your change)
Thanks, I'll include them.
-Peff
^ permalink raw reply
* Re: [PATCH v3 1/2] Factor find_pack_entry()'s core out
From: Junio C Hamano @ 2012-02-01 22:03 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <alpine.LFD.2.02.1202011056140.2759@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
>> +static int find_pack_entry_1(const unsigned char *sha1,
>> + struct packed_git *p, struct pack_entry *e)
>
> This looks all goot but the name. Pretty please, try to find something
> that is more descriptive than "1". Suggestions:
> "find_pack_entry_lookup", "find_pack_entry_inner", etc.
Perhaps "find_pack_entry_in_pack(sha1, e, p)"?
That would go well with the caller "find_pack_entry(sha1, e)".
^ permalink raw reply
* Re: logging disjoint sets of commits in a single command
From: Bryan O'Sullivan @ 2012-02-01 22:01 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git@vger.kernel.org
In-Reply-To: <20120201030300.GA9969@sigill.intra.peff.net>
On 2012-01-31 19:03 , "Jeff King" <peff@peff.net> wrote:
>
>That sounds kind of slow. Is your repository really gigantic?
Bigger than a kernel tree, but not as many commits. Beyond that, can't say.
> Have you packed
>everything?
Yep.
> I'm just curious if there's some other way to make things
>faster.
It would be nice if there was, but the fundamental problem is the lack of
an index from filename to commit. Walking every commit is the limiting
factor, I believe.
> Is the repository publicly available?
No, sorry.
^ permalink raw reply
* AW: Project structure of .NET-Projects using git submodule or something different
From: Harald Heigl @ 2012-02-01 21:07 UTC (permalink / raw)
To: git
In-Reply-To: <4F29A0BE.8000803@web.de>
Hi, thanks for your answer!
> -----Ursprüngliche Nachricht-----
> Von: Jens Lehmann [mailto:Jens.Lehmann@web.de]
> Gesendet: Mittwoch, 01. Februar 2012 21:30
> An: Harald Heigl
> Cc: git@vger.kernel.org
> Betreff: Re: Project structure of .NET-Projects using git submodule or
> something different
>
> Am 31.01.2012 23:41, schrieb Harald Heigl:
> > Let's assume following Project structure (Dependencies and
> Subdependencies
> > are submodules and submodules of the submodules)
> > Project
> > Dependency 1
> > Dependency 2
> > Dependency 3
> > Dependency 4
> > Dependency 2
> >
> >
> > The problem is if I want to build them I need to build 2+3, then 1, 4
and 2
> > again and then the project. As you may see project 2 is a submodule of
> > dependency 1 and also of project. I don't feel comfortable with this
setup.
> > What do you think?
>
> Hmm, we try to avoid that kind of setup as having checked out different
> versions of the "Dependency 2" submodule could have rather surprising
> effects. We get along really well with "Dependency 2" only being present
> in the superproject and having "Dependency 1" reference that instead of
> having its own copy (So we have submodules which are depending on having
> other submodules right next to them). Then the superproject is responsible
> for tying it all together.
I think you're right, my first thoughts were that if I start a new project I
just "git submodule dependency1" and get all the required dependencies and
the dependencies within the dependencies and so on ... .
With your solution I "git submodule dependency1" and have to think about the
dependencies it depends on. On the other hand we are just a small company
and the number of submodules is not too big and the missing references in a
new project would be easily identifiable, so ... .
And if I want to checkout dependency 1 individually (for whatever reason), I
could still do something like this:
SuperDependency1 (with solution-File)
Dependency1 (as submodule)
Dependency2 (dependency of dependency1 - as submodule)
Dependency3 (dependency of dependency1 - as submodule)
Thanks again, I see my concept causes some trouble ...
Any other thoughts or other workflows with git or with tools build around
git?
Thanks again,
Harald
^ permalink raw reply
* rebase -i reword runs pre-commit hook with curious results
From: Neal Kreitzinger @ 2012-02-01 21:50 UTC (permalink / raw)
To: git
I'm confused on why and/or how interactive rebase runs the pre-commit hook
when doing the reword command for commit (a). My pre-commit hook does
keyword expansion on the worktree copy of the modified index files and then
re-adds them to effect a user-date-stamp when committed. However, the
user-date-stamps don't get updated when reword runs the pre-commit hook.
IOW, the pre-commit hook does not get the same results as if I were doing a
commandline git-commit of a modified index. I suppose reword is protecting
the preservation of all the contents of commit (a) except the commit message
which makes sense, but I don't understand how it goes about doing this while
still attempting to somehow honor the pre-commit hook. (git 1.7.1)
v/r,
neal
^ permalink raw reply
* Re: rebase -i reword converts to pick on pre-commit non-zero exit
From: Neal Kreitzinger @ 2012-02-01 21:28 UTC (permalink / raw)
To: git; +Cc: git
In-Reply-To: <jgcaoh$d9q$1@dough.gmane.org>
On 2/1/2012 3:27 PM, Neal Kreitzinger wrote:
> When interactive rebase does the reword command it runs the pre-commit hook
> for that commit (a). If the pre-commit hook gives a non-zero exit then
> interactive rebase picks commit (a) and continues to the next commit (b) in
> the rebase-to-do-list. Instead of picking commit (a) when the pre-commit
> hook exits non-zero on the reword command, shouldn't interactive rebase
> learn to edit commit (a) and tell the user that because the pre-commit hook
> exited non-zero they need to either remedy the pre-commit hook violations
> and run git commit --amend or run git commit --amend --no-verify to bypass
> the pre-commit hook? Otherwise, you have to run another rebase after the
> rejected rewords and edit those commits to accomplish the rewords.
>
git 1.7.1
v/r,
neal
^ permalink raw reply
* rebase -i reword converts to pick on pre-commit non-zero exit
From: Neal Kreitzinger @ 2012-02-01 21:27 UTC (permalink / raw)
To: git
When interactive rebase does the reword command it runs the pre-commit hook
for that commit (a). If the pre-commit hook gives a non-zero exit then
interactive rebase picks commit (a) and continues to the next commit (b) in
the rebase-to-do-list. Instead of picking commit (a) when the pre-commit
hook exits non-zero on the reword command, shouldn't interactive rebase
learn to edit commit (a) and tell the user that because the pre-commit hook
exited non-zero they need to either remedy the pre-commit hook violations
and run git commit --amend or run git commit --amend --no-verify to bypass
the pre-commit hook? Otherwise, you have to run another rebase after the
rejected rewords and edit those commits to accomplish the rewords.
v/r,
neal
^ permalink raw reply
* Re: [PATCH v2] Use correct grammar in diffstat summary line
From: Junio C Hamano @ 2012-02-01 21:26 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Thomas Dickey, Jonathan Nieder, Ævar Arnfjörð,
Frederik Schwarzer, Brandon Casey, dickey
In-Reply-To: <1328100907-20397-1-git-send-email-pclouds@gmail.com>
Nice. Will queue with a minor update to the log message:
commit 3f29ab34372ee11946439da3bde307eb90ad9031
Author: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Date: Wed Feb 1 19:55:07 2012 +0700
Use correct grammar in diffstat summary line
"git diff --stat" and "git apply --stat" now learn to print the line
"%d files changed, %d insertions(+), %d deletions(-)" in singular form
whenever applicable. "0 insertions" and "0 deletions" are also omitted
unless they are both zero.
This matches how versions of "diffstat" that are not prehistoric produced
their output, and also makes this line translatable.
[jc: with help from Thomas Dickey in archaeology of "diffstat"]
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
And also this bit on top:
diff --git a/diff.c b/diff.c
index 5c31b36..5f3ce97 100644
--- a/diff.c
+++ b/diff.c
@@ -1329,7 +1329,7 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)
if (!files) {
assert(insertions == 0 && deletions == 0);
- return fputs(_(" no changes\n"), fp);
+ return fputs(_(" 0 files changed\n"), fp);
}
strbuf_addf(&sb,
^ permalink raw reply related
* Re: General support for ! in git-config values
From: Ævar Arnfjörð Bjarmason @ 2012-02-01 21:25 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20120201184020.GA29374@sigill.intra.peff.net>
On Wed, Feb 1, 2012 at 19:40, Jeff King <peff@peff.net> wrote:
> On Wed, Feb 01, 2012 at 06:33:47PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> For a program I'm working on (git-deploy) I'd like to have this as a
>> general facility, i.e. users can specify either:
>>
>> foo.bar = value
>>
>> Or:
>>
>> foo.bar = !cat /some/path
>>
>> I'm wondering why git-config doesn't do this already, if there's no
>> reason in particular I can just patch it in, either as a new option:
>>
>> git config --with-exec --get foo.bar
>
> I'm not clear on what you want --with-exec to do. By default, config
> values are strings. I would expect the "!" to be a special marker that
> the caller would recognize in the string, and then act appropriately.
>
> So if I were implementing git aliases in the shell, the code would look
> like:
>
> v=$(git config alias.$alias)
> case "$v" in
> "")
> die "no such alias: $alias" ;;
> "!*)
> cmd="${v#!}" ;;
> *)
> cmd="git $v" ;;
> esac
> eval "$cmd"
>
> I.e., everything pertaining to "!" happens after we get the config
> string. So what is it that you want "git config --with-exec" to do?
I agree that that's how it should work, I just suggested --with-exec
in case anyone complained about the backwards compatibility issue of
changing the meaning of "!" for existing configs.
^ permalink raw reply
* Re: [PATCH v5 2/5] gitweb: add project_filter to limit project list to a subdirectory
From: Junio C Hamano @ 2012-02-01 20:55 UTC (permalink / raw)
To: Bernhard R. Link; +Cc: Jakub Narebski, git
In-Reply-To: <20120201165902.GA14706@server.brlink.eu>
"Bernhard R. Link" <brl+git@mail.brlink.eu> writes:
> Look liks a change like that is actually needed...
> ... So it looks for forks in a directory named '1'
Yeah, that was exactly what was causing failures in 9502. Fixed locally
so no further action is required.
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2012, #08; Tue, 31)
From: Junio C Hamano @ 2012-02-01 20:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Bernhard R. Link
In-Reply-To: <7v39au47dt.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I am getting
>
> 7ad1b64084ff003f71fe749a3e5a74d071a193d8 is the first bad commit
> commit 7ad1b64084ff003f71fe749a3e5a74d071a193d8
> Author: Bernhard R. Link <brl+git@mail.brlink.eu>
> Date: Mon Jan 30 21:05:47 2012 +0100
>
> gitweb: move hard coded .git suffix out of git_get_projects_list
>
> *** t9502-gitweb-standalone-parse-output.sh ***
> ...
> not ok - 14 forks: "forks" action for forked repository
> #
> # gitweb_run "p=foo.git;a=forks" &&
> # grep -q ">foo/foo-forked\\.git<" gitweb.body &&
> # grep -q ">fork of foo<" gitweb.body
> #
> ok 15 - forks: can access forked repository
> ok 16 - forks: project_index lists all projects (incl. forks)
> # failed 1 among 16 test(s)
>
> The output file gitweb.body has this in it:
>
> <div class="page_body">
> <br /><br />
> 404 - No forks found
> <br />
> </div>
> <div class="page_footer">
And of course the culprit turns out to be that "cute" expression.
-- >8 --
Subject: gitweb: do not use assignment with regexp replace in parameter
A recent patch made the code to generate a parameter to git_get_projects_list
a bit too cute, by introducing a new variable, assigning a value to it, and
then munging that value with s/// replacement, all in the parameter list.
The whole expression returns the number of replacements, not the resulting
value in the variable after s/// operation.
Split them into separate expressions, which also would make the resulting
lines shorter and less taxing on the brain.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
gitweb/gitweb.perl | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b764d51..e074cd7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6003,7 +6003,9 @@ sub git_forks {
die_error(400, "Unknown order parameter");
}
- my @list = git_get_projects_list((my $filter = $project) =~ s/\.git$//);
+ my $filter = $project;
+ $filter =~ s/\.git$//;
+ my @list = git_get_projects_list($filter);
if (!@list) {
die_error(404, "No forks found");
}
@@ -6062,7 +6064,9 @@ sub git_summary {
if ($check_forks) {
# find forks of a project
- @forklist = git_get_projects_list((my $filter = $project) =~ s/\.git$//);
+ my $filter = $project;
+ $filter =~ s/\.git$//;
+ @forklist = git_get_projects_list($filter);
# filter out forks of forks
@forklist = filter_forks_from_projects_list(\@forklist)
if (@forklist);
^ permalink raw reply related
* Re: What's cooking in git.git (Jan 2012, #08; Tue, 31)
From: Junio C Hamano @ 2012-02-01 20:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Bernhard R. Link
In-Reply-To: <m3fweudaf6.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Hmmm... strange. I have applied my patches on top of earlier version
> of project_filter commits:
>
> - gitweb: Make project search respect project_filter
> - gitweb: Improve projects search form
> - gitweb: place links to parent directories in page header
> - gitweb: add project_filter to limit project list to a subdirectory
>
> and all gitweb tests passes.
>
> I will investigate.
I am getting
7ad1b64084ff003f71fe749a3e5a74d071a193d8 is the first bad commit
commit 7ad1b64084ff003f71fe749a3e5a74d071a193d8
Author: Bernhard R. Link <brl+git@mail.brlink.eu>
Date: Mon Jan 30 21:05:47 2012 +0100
gitweb: move hard coded .git suffix out of git_get_projects_list
*** t9502-gitweb-standalone-parse-output.sh ***
ok 1 - setup
ok 2 - snapshot: full sha1
ok 3 - snapshot: shortened sha1
ok 4 - snapshot: almost full sha1
ok 5 - snapshot: HEAD
ok 6 - snapshot: short branch name (master)
ok 7 - snapshot: short tag name (first)
ok 8 - snapshot: full branch name (refs/heads/master)
ok 9 - snapshot: full tag name (refs/tags/first)
ok 10 - snapshot: hierarchical branch name (xx/test)
ok 11 - forks: setup
ok 12 - forks: not skipped unless "forks" feature enabled
ok 13 - forks: forks skipped if "forks" feature enabled
not ok - 14 forks: "forks" action for forked repository
#
# gitweb_run "p=foo.git;a=forks" &&
# grep -q ">foo/foo-forked\\.git<" gitweb.body &&
# grep -q ">fork of foo<" gitweb.body
#
ok 15 - forks: can access forked repository
ok 16 - forks: project_index lists all projects (incl. forks)
# failed 1 among 16 test(s)
The output file gitweb.body has this in it:
<div class="page_body">
<br /><br />
404 - No forks found
<br />
</div>
<div class="page_footer">
^ permalink raw reply
* Re: Project structure of .NET-Projects using git submodule or something different
From: Jens Lehmann @ 2012-02-01 20:29 UTC (permalink / raw)
To: Harald Heigl; +Cc: git
In-Reply-To: <002401cce069$75ecc1a0$61c644e0$@heigl-online.at>
Am 31.01.2012 23:41, schrieb Harald Heigl:
> Let's assume following Project structure (Dependencies and Subdependencies
> are submodules and submodules of the submodules)
> Project
> Dependency 1
> Dependency 2
> Dependency 3
> Dependency 4
> Dependency 2
>
>
> The problem is if I want to build them I need to build 2+3, then 1, 4 and 2
> again and then the project. As you may see project 2 is a submodule of
> dependency 1 and also of project. I don't feel comfortable with this setup.
> What do you think?
Hmm, we try to avoid that kind of setup as having checked out different
versions of the "Dependency 2" submodule could have rather surprising
effects. We get along really well with "Dependency 2" only being present
in the superproject and having "Dependency 1" reference that instead of
having its own copy (So we have submodules which are depending on having
other submodules right next to them). Then the superproject is responsible
for tying it all together.
^ permalink raw reply
* Bug report: stash in upstream caused remote fetch to fail
From: Andrew Walrond @ 2012-02-01 16:59 UTC (permalink / raw)
To: andrew
A bit of cut and paste will explain better than me...
LOCAL $ git remote update
Fetching origin
remote: Counting objects: 25, done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 13 (delta 10), reused 0 (delta 0)
Unpacking objects: 100% (13/13), done.
fatal: bad object fa0da15b2ea5cc3e4eb9ed414b99d6a9d7da7864
error: git://git.heresymail.org/lib%2Fmpfr did not send all necessary
objects
UPSTREAM $ git fsck
dangling blob ded848b21db04fcadf77a4a5d9f81955b4315c9f
dangling blob 9c3976919b3cee56eabc3c9c9dfe5d223ce32686
dangling blob e17ab25a3a91bed830ddb06da4af1132434d5ee4
dangling blob 20a612ab361058838f680d72c1f4f8cb462ce1a2
UPSTREAM $ git gc
Counting objects: 974, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (954/954), done.
Writing objects: 100% (974/974), done.
Total 974 (delta 572), reused 0 (delta 0)
LOCAL $ git remote update
Fetching origin
remote: Counting objects: 25, done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 13 (delta 3), reused 11 (delta 2)
Unpacking objects: 100% (13/13), done.
fatal: bad object fa0da15b2ea5cc3e4eb9ed414b99d6a9d7da7864
error: git://git.heresymail.org/lib%2Fmpfr did not send all necessary
objects
LOCAL $ DELETE LOCAL REPO
LOCAL $ git clone <upstream>
Cloning into bare repository '/src/lib/mpfr'...
remote: Counting objects: 972, done.
remote: Compressing objects: 100% (382/382), done.
remote: Total 972 (delta 570), reused 971 (delta 570)
Receiving objects: 100% (972/972), 2.01 MiB, done.
Resolving deltas: 100% (570/570), done.
error: refs/stash does not point to a valid object!
UPSTREAM $ git stash list
stash@{0}: WIP on (no branch): f648dd0 Import 3.1.0 from tarball
UPSTREAM $ git stash clear
LOCAL $ DELETE LOCAL REPO
LOCAL $ git clone <upstream>
Cloning into bare repository '/src/lib/mpfr'...
remote: Counting objects: 972, done.
remote: Compressing objects: 100% (382/382), done.
remote: Total 972 (delta 570), reused 971 (delta 570)
Receiving objects: 100% (972/972), 2.01 MiB, done.
Resolving deltas: 100% (570/570), done.
UPSTREAM $ git version
git version 1.7.8.2
LOCAL $ git version
git version 1.7.8.2
Hope that's useful!
Andrew Walrond
^ permalink raw reply
* Re: Rebase regression in v1.7.9?
From: Felipe Contreras @ 2012-02-01 19:30 UTC (permalink / raw)
To: Andrew Wong; +Cc: git
In-Reply-To: <4F29761E.1030605@sohovfx.com>
On Wed, Feb 1, 2012 at 7:27 PM, Andrew Wong <andrew.w@sohovfx.com> wrote:
> On 01/31/2012 05:56 PM, Felipe Contreras wrote:
>> The rebase will finish, but there will be a .git/CHERRY_PICK_HEAD file.
>>
> Ah, good catch. I can reproduce the issue. This is only happening in
> "rebase -i" because interactive rebase relies on cherry-pick, but not
> regular rebase. And now cherry-pick creates a state when there's a
> conflict (since 1.7.5?), which "rebase -i" didn't expect before. We
> probably just need to do a manual clean up before "rebase -i" continues.
>
> I'll try to come up with a patch for this. In the mean time, doing a
> "git reset" will remove that dangling file. Of course, you could always
> manually remove it. Does the dangling file cause a subsequent git
> command to fail?
No, it's just annoying with the __git_ps1 prompt stuff. Yeah, 'git
reset' solves the problem, but it's much better to type 'git skip'
instead... for now.
--
Felipe Contreras
^ permalink raw reply
* Re: General support for ! in git-config values
From: Jeff King @ 2012-02-01 18:40 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git Mailing List
In-Reply-To: <CACBZZX6U+1Fmdaz2ikbbc6zUyF=pMGQOqUGVOWCkUFBUkovCBw@mail.gmail.com>
On Wed, Feb 01, 2012 at 06:33:47PM +0100, Ævar Arnfjörð Bjarmason wrote:
> For a program I'm working on (git-deploy) I'd like to have this as a
> general facility, i.e. users can specify either:
>
> foo.bar = value
>
> Or:
>
> foo.bar = !cat /some/path
>
> I'm wondering why git-config doesn't do this already, if there's no
> reason in particular I can just patch it in, either as a new option:
>
> git config --with-exec --get foo.bar
I'm not clear on what you want --with-exec to do. By default, config
values are strings. I would expect the "!" to be a special marker that
the caller would recognize in the string, and then act appropriately.
So if I were implementing git aliases in the shell, the code would look
like:
v=$(git config alias.$alias)
case "$v" in
"")
die "no such alias: $alias" ;;
"!*)
cmd="${v#!}" ;;
*)
cmd="git $v" ;;
esac
eval "$cmd"
I.e., everything pertaining to "!" happens after we get the config
string. So what is it that you want "git config --with-exec" to do?
-Peff
^ permalink raw reply
* Re: [PATCH] i18n: po for zh_cn
From: Ævar Arnfjörð Bjarmason @ 2012-02-01 17:48 UTC (permalink / raw)
To: Jiang Xin; +Cc: Git List, Junio C Hamano
In-Reply-To: <1328111436-58925-1-git-send-email-worldhello.net@gmail.com>
On Wed, Feb 1, 2012 at 16:50, Jiang Xin <worldhello.net@gmail.com> wrote:
> Git can speak Chinese now.
That's very nice, and it passes the msgfmt --check test as well, so
all looks good.
As an aside doesn't the bug / workaround described in
https://github.com/git/git/blob/master/gettext.c#L35 impact chinese
especially badly? I'd expect any place where we use strerror() to show
up as total gibberish.
Nothing to be done about that though than providing non-broken printf
functions though, just curious.
> +#: wt-status.c:207
> +msgid "bug"
> +msgstr "bug"
It also looks like we could do away with making this available for
translation, and it should actually be something like "if you see this
report a bug in Git" instead.
^ permalink raw reply
* Re: [PATCH] i18n: format_tracking_info "Your branch is behind" message
From: Ævar Arnfjörð Bjarmason @ 2012-02-01 17:39 UTC (permalink / raw)
To: Jiang Xin; +Cc: Git List
In-Reply-To: <1328116914-61381-1-git-send-email-worldhello.net@gmail.com>
On Wed, Feb 1, 2012 at 18:21, Jiang Xin <worldhello.net@gmail.com> wrote:
> Function format_tracking_info in remote.c is called by
> wt_status_print_tracking in wt-status.c, which will print
> branch tracking message in git-status. git-checkout also
> show these messages through it's report_tracking function.
>
> Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
> ---
> remote.c | 18 +++++++++---------
> 1 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/remote.c b/remote.c
> index 73a38..51853 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -1572,18 +1572,18 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb)
> base = branch->merge[0]->dst;
> base = shorten_unambiguous_ref(base, 0);
> if (!num_theirs)
> - strbuf_addf(sb, "Your branch is ahead of '%s' "
> - "by %d commit%s.\n",
> - base, num_ours, (num_ours == 1) ? "" : "s");
> + strbuf_addf(sb, _("Your branch is ahead of '%s' "
> + "by %d %s.\n"),
> + base, num_ours, Q_("commit", "commits", num_ours));
> else if (!num_ours)
> - strbuf_addf(sb, "Your branch is behind '%s' "
> - "by %d commit%s, "
> - "and can be fast-forwarded.\n",
> - base, num_theirs, (num_theirs == 1) ? "" : "s");
> + strbuf_addf(sb, _("Your branch is behind '%s' "
> + "by %d %s, "
> + "and can be fast-forwarded.\n"),
> + base, num_theirs, Q_("commit", "commits", num_theirs));
These two should be something like:
_Q("Your branch is behind '%s' by %d commit",
"Your branch is behind '%s' by %d commits",
base,
num_theirs);
Otherwise we're imposing word order in the translation.
> else
> - strbuf_addf(sb, "Your branch and '%s' have diverged,\n"
> + strbuf_addf(sb, _("Your branch and '%s' have diverged,\n"
> "and have %d and %d different commit(s) each, "
> - "respectively.\n",
> + "respectively.\n"),
> base, num_ours, num_theirs);
And this is a nice example of where gettext really can't do the right
thing, it only deals with messages with one numeric counter ;/
It's probably best to just pick one, probably the latter one.
^ permalink raw reply
* General support for ! in git-config values
From: Ævar Arnfjörð Bjarmason @ 2012-02-01 17:33 UTC (permalink / raw)
To: Git Mailing List
alias.* values can start with !, in which case a shell command will be
executed with the arguments you give.
For a program I'm working on (git-deploy) I'd like to have this as a
general facility, i.e. users can specify either:
foo.bar = value
Or:
foo.bar = !cat /some/path
I'm wondering why git-config doesn't do this already, if there's no
reason in particular I can just patch it in, either as a new option:
git config --with-exec --get foo.bar
Or as the default behavior.
^ permalink raw reply
* Re: Rebase regression in v1.7.9?
From: Andrew Wong @ 2012-02-01 17:27 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s1EAwHjQ7S2ArLvhNg5qkR05DRJ70tQmP8sXYdOP=i_zQ@mail.gmail.com>
On 01/31/2012 05:56 PM, Felipe Contreras wrote:
> The rebase will finish, but there will be a .git/CHERRY_PICK_HEAD file.
>
Ah, good catch. I can reproduce the issue. This is only happening in
"rebase -i" because interactive rebase relies on cherry-pick, but not
regular rebase. And now cherry-pick creates a state when there's a
conflict (since 1.7.5?), which "rebase -i" didn't expect before. We
probably just need to do a manual clean up before "rebase -i" continues.
I'll try to come up with a patch for this. In the mean time, doing a
"git reset" will remove that dangling file. Of course, you could always
manually remove it. Does the dangling file cause a subsequent git
command to fail?
^ permalink raw reply
* [PATCH] i18n: diff/apply statistics
From: Jiang Xin @ 2012-02-01 17:22 UTC (permalink / raw)
To: Git List, avarab; +Cc: Jiang Xin
translate oneline statistics of diff/apply.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
---
builtin/apply.c | 2 +-
diff.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index c24d..e289e 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3241,7 +3241,7 @@ static void stat_patch_list(struct patch *patch)
show_stats(patch);
}
- printf(" %d files changed, %d insertions(+), %d deletions(-)\n", files, adds, dels);
+ printf(_(" %d files changed, %d insertions(+), %d deletions(-)\n"), files, adds, dels);
}
static void numstat_patch_list(struct patch *patch)
diff --git a/diff.c b/diff.c
index 7e1542..b9115 100644
--- a/diff.c
+++ b/diff.c
@@ -1476,7 +1476,7 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
}
fprintf(options->file, "%s", line_prefix);
fprintf(options->file,
- " %d files changed, %d insertions(+), %d deletions(-)\n",
+ _(" %d files changed, %d insertions(+), %d deletions(-)\n"),
total_files, adds, dels);
}
@@ -1507,7 +1507,7 @@ static void show_shortstats(struct diffstat_t *data, struct diff_options *option
options->output_prefix_data);
fprintf(options->file, "%s", msg->buf);
}
- fprintf(options->file, " %d files changed, %d insertions(+), %d deletions(-)\n",
+ fprintf(options->file, _(" %d files changed, %d insertions(+), %d deletions(-)\n"),
total_files, adds, dels);
}
--
1.7.9.3.g1fbd7
^ permalink raw reply
* [PATCH] i18n: format_tracking_info "Your branch is behind" message
From: Jiang Xin @ 2012-02-01 17:21 UTC (permalink / raw)
To: Git List, avarab; +Cc: Jiang Xin
Function format_tracking_info in remote.c is called by
wt_status_print_tracking in wt-status.c, which will print
branch tracking message in git-status. git-checkout also
show these messages through it's report_tracking function.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
---
remote.c | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/remote.c b/remote.c
index 73a38..51853 100644
--- a/remote.c
+++ b/remote.c
@@ -1572,18 +1572,18 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb)
base = branch->merge[0]->dst;
base = shorten_unambiguous_ref(base, 0);
if (!num_theirs)
- strbuf_addf(sb, "Your branch is ahead of '%s' "
- "by %d commit%s.\n",
- base, num_ours, (num_ours == 1) ? "" : "s");
+ strbuf_addf(sb, _("Your branch is ahead of '%s' "
+ "by %d %s.\n"),
+ base, num_ours, Q_("commit", "commits", num_ours));
else if (!num_ours)
- strbuf_addf(sb, "Your branch is behind '%s' "
- "by %d commit%s, "
- "and can be fast-forwarded.\n",
- base, num_theirs, (num_theirs == 1) ? "" : "s");
+ strbuf_addf(sb, _("Your branch is behind '%s' "
+ "by %d %s, "
+ "and can be fast-forwarded.\n"),
+ base, num_theirs, Q_("commit", "commits", num_theirs));
else
- strbuf_addf(sb, "Your branch and '%s' have diverged,\n"
+ strbuf_addf(sb, _("Your branch and '%s' have diverged,\n"
"and have %d and %d different commit(s) each, "
- "respectively.\n",
+ "respectively.\n"),
base, num_ours, num_theirs);
return 1;
}
--
1.7.9.3.g1fbd7
^ permalink raw reply
* [PATCH] i18n: git-commit whence_s "merge/cherry-pick" message
From: Jiang Xin @ 2012-02-01 17:20 UTC (permalink / raw)
To: Git List, avarab; +Cc: Jiang Xin
Mark the "merge/cherry-pick" messages in whence_s for translation.
These messages returned from whence_s function are used as argument
to build other messages.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
---
builtin/commit.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index eba137..663e1 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -202,10 +202,10 @@ static const char *whence_s(void)
case FROM_COMMIT:
break;
case FROM_MERGE:
- s = "merge";
+ s = _("merge");
break;
case FROM_CHERRY_PICK:
- s = "cherry-pick";
+ s = _("cherry-pick");
break;
}
--
1.7.9.3.g1fbd7
^ permalink raw reply
* Re: [PATCH v5 2/5] gitweb: add project_filter to limit project list to a subdirectory
From: Bernhard R. Link @ 2012-02-01 16:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7v39axaq0v.fsf@alter.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> [120130 21:34]:
> Thanks; I'll queue them in 'pu' for now (if Jakub wants to Ack the pieces,
> I'll amend them).
>
> Regarding the first patch in the series, while it may be a valid perl to
> introduce a new variable, assign to it and then munge its contents with
> s///, all inside a parameter list of a function call, it is doing a bit
> too much and makes it hard to see if the variable may or may not later be
> used in the same scope (in this case, it is not).
>
> I am tempted to squash the following in.
Look liks a change like that is actually needed. I made the mistake of
assuming
(my $filter = $project) =~ s/\.git$//;
was the same like
$project =~ s/\.git$//r;
but the latter returns the changed string, the former returns the number
of arguments. (So it looks for forks in a directory named '1').
(Should have tested it again after this last change)...
Can you squash it in (with the correction of Jakub Narebski), or do you
prefer a new patch?
Bernhard R. Link
^ 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