* Re: [PATCH] t3419-*.sh: Fix arithmetic expansion syntax error
From: Clemens Buchacher @ 2010-12-22 18:42 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <4D10F707.1000206@ramsay1.demon.co.uk>
On Tue, Dec 21, 2010 at 06:50:47PM +0000, Ramsay Jones wrote:
>
> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Thanks.
> Note that this test is unique in having an '#!/bin/bash' line (rather
> than '#!/bin/sh'), which was (indirectly) responsible for me not
> noticing this failure for a while. I don't see anything that would
> require bash, so I suspect this is not intensional.
Indeed. I actually removed all bashisms from the script, but then
apparently forgot to get rid of #!/bin/bash as well.
Clemens
^ permalink raw reply
* Re: Expected behaviour of 'git log -S' when searching in a merged/deleted file?
From: Junio C Hamano @ 2010-12-22 18:17 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Git Mailing List
In-Reply-To: <AANLkTimXk6ei6EAQfvTTfnMzdBqYHkNoaxkEab+atnHd@mail.gmail.com>
Jonathan del Strother <jdelstrother@gmail.com> writes:
> I was trying to find a particular string in my project this morning.
> 'git grep mystring' suggested that the string didn't exist in my repo,
> but 'git log -Smystring' turned up a single commit that had added it.
> It took me a long time to figure out that in the past, a branch had
> added that string to foo.c, but a second branch deleted foo.c, and the
> two branches were later merged (deleting foo.c and ignoring mystring).
This is a typical case of the history simplification in action, isn't it?
"log" will give you one possible and simplest explanation of how the
project came into the current shape. Because side branches with changes
that were discarded before merging it to the history that lead to the
commit you run "log" from do not contribute anything to the end result,
"log" will not traverse the entire side branch when it sees the merge.
Try your "log" with --full-history, perhaps?
^ permalink raw reply
* Re: [PATCH v5] convert filter: supply path to external driver
From: Junio C Hamano @ 2010-12-22 18:10 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: Jonathan Nieder, git, Jeff King, Johannes Sixt
In-Reply-To: <20101222144013.GA22089@honk.padd.com>
Just FYI.
As I build stuff with -Werror to be on the safe side, I had to fix this up
a bit before queueing the patch.
convert.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/convert.c b/convert.c
index 0b24790..d5aebed 100644
--- a/convert.c
+++ b/convert.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "attr.h"
#include "run-command.h"
+#include "quote.h"
/*
* convert.c - convert a file when checking it out and checking it in.
@@ -335,8 +336,8 @@ static int filter_buffer(int in, int out, void *data)
struct strbuf cmd = STRBUF_INIT;
struct strbuf path = STRBUF_INIT;
struct strbuf_expand_dict_entry dict[] = {
- "f", NULL,
- NULL, NULL,
+ { "f", NULL, },
+ { NULL, NULL, },
};
/* quote the path to preserve spaces, etc. */
^ permalink raw reply related
* [PATCH/RFC] get_sha1: allow users to extend ..^{%..} syntax
From: Nguyễn Thái Ngọc Duy @ 2010-12-22 15:33 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
This allows users to add abitrary sth^{%foo} syntax that translates
from an SHA-1 to another SHA-1, where "foo" refers to an alias
"sha1-foo" or "foo". If either is found, %sha1% in the alias will be
replaced with SHA-1 of "sth". The alias command is supposed to print
translated SHA-1 to stdout.
Another syntax is sth^{%foo:args} where %arg% in the alias will be
replaced with "args" from the syntax. This gives users much more
flexibilty in extending SHA-1 syntax. I'm not sure if I should support
multiple arguments though.
My mind is still with the :/ syntax. So as an example,
git config alias.sha1-topic 'rev-list --merges --grep=%arg% --max-count=1 %sha1%'
git rev-parse origin/pu^{%topic:nd/struct-pathspec}
would give me sha-1 of my topic. This is supposed to be faster than
standard :/ syntax because it only searches merges. I can also make it
more accurate to my liking by adjust --grep= freely. Unfortunately
git-rev-list takes ~1 sec to run. Maybe I can detect rev-list command
and run it internally without run_command().
The intention is that a similar syntax can be used for branch
translation too, i.e ref@{%...}.
One of the rising issues is that every time this syntax is evaluated,
external process will be run again. Some cache might help. I should
also take alias code out of git.c for reuse here.
So comments? (This patch looks bad, I know)
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
sha1_name.c | 87 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 87 insertions(+), 0 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index c5c59ce..6b40cec 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -6,6 +6,7 @@
#include "tree-walk.h"
#include "refs.h"
#include "remote.h"
+#include "run-command.h"
static int get_sha1_oneline(const char *, unsigned char *, struct commit_list *);
@@ -529,6 +530,86 @@ struct object *peel_to_type(const char *name, int namelen,
}
}
+static int peel_alias_onion(const char *name, int len, const char *sp,
+ unsigned char *sha1)
+{
+ int alias_len;
+ struct strbuf sb = STRBUF_INIT;
+ struct strbuf cmd = STRBUF_INIT;
+ struct child_process cp;
+ const char **argv;
+ int count, hex_len;
+ char *s, *arg;
+ char hex[40];
+
+ len--; /* remove the last '}' */
+ arg = strchr(sp, ':');
+ if (arg)
+ alias_len = arg - sp;
+ else
+ alias_len = len - (sp - name);
+ strbuf_add(&sb, "sha1-", 5);
+ strbuf_add(&sb, sp, alias_len);
+ s = alias_lookup(sb.buf);
+ if (!s) {
+ strbuf_reset(&sb);
+ strbuf_add(&sb, sp, alias_len);
+ s = alias_lookup(sb.buf);
+ }
+ strbuf_release(&sb);
+ if (!s)
+ return error("unable to find alias for %s", name);
+
+ strbuf_attach(&cmd, s, strlen(s), strlen(s)+1);
+ s = strstr(cmd.buf, "%sha1%");
+ if (!s) {
+ error("%%sha1%% not found, not an sha1 alias:\n%s", cmd.buf);
+ strbuf_release(&cmd);
+ return -1;
+ }
+ strbuf_splice(&cmd, s - cmd.buf, 6, sha1_to_hex(sha1), 40);
+ if (arg) {
+ int arg_len = len - (++arg - name);
+ s = strstr(cmd.buf, "%arg%");
+ if (!s) {
+ error("%%arg%% not found, not an sha1 alias:\n%s", cmd.buf);
+ strbuf_release(&cmd);
+ return -1;
+ }
+ strbuf_splice(&cmd, s - cmd.buf, 5, arg, arg_len);
+ }
+
+ count = split_cmdline(cmd.buf, &argv);
+ if (count < 0) {
+ error("Bad alias.%s string: %s", cmd.buf, split_cmdline_strerror(count));
+ strbuf_release(&cmd);
+ return -1;
+ }
+
+ memset(&cp, 0, sizeof(cp));
+ cp.git_cmd = 1;
+ cp.in = 0;
+ cp.out = -1;
+ cp.argv = argv;
+ trace_argv_printf(argv, "trace: sha1 alias expansion: %s =>", cmd.buf);
+ if (start_command(&cp)) {
+ error("Failed to run %s", cmd.buf);
+ strbuf_release(&cmd);
+ return -1;
+ }
+ hex_len = xread(cp.out, hex, 40);
+ close(cp.out);
+ if (finish_command(&cp)) {
+ error("Failed to finish %s", cmd.buf);
+ strbuf_release(&cmd);
+ return -1;
+ }
+ strbuf_release(&cmd);
+ if (hex_len != 40 || get_sha1_hex(hex, sha1))
+ return error("failed to get result SHA-1 from ...%s", sp-3);
+ return 0;
+}
+
static int peel_onion(const char *name, int len, unsigned char *sha1)
{
unsigned char outer[20];
@@ -566,6 +647,12 @@ static int peel_onion(const char *name, int len, unsigned char *sha1)
expected_type = OBJ_NONE;
else if (sp[0] == '/')
expected_type = OBJ_COMMIT;
+ else if (sp[0] == '%') {
+ if (get_sha1_1(name, sp - name - 2, outer))
+ return -1;
+ hashcpy(sha1, outer);
+ return peel_alias_onion(name, len, sp + 1, sha1);
+ }
else
return -1;
--
1.7.3.3.476.g10a82
^ permalink raw reply related
* Re: [PATCH 44/47] Remove all logic from get_git_work_tree()
From: Junio C Hamano @ 2010-12-22 15:17 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <AANLkTikOOaKSf333UzawEgAf_=t-WBrWLu7tmiOrqO8V@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> 2010/12/22 Junio C Hamano <gitster@pobox.com>:
>>> const char *get_git_work_tree(void)
>>> {
>>> - if (startup_info && !startup_info->setup_explicit) {
>>> -...
>>> - }
>>> return work_tree;
>>> }
>>
>> Would it be a bug in the new set-up code if this function gets called and
>> work_tree is still NULL?
>>
>> There are quite a few callers that call get_git_work_tree() and expect
>> that it will always return a non NULL pointer. Perhaps we would want an
>> assertion here?
>>
>
> While the assertion sounds good, it does not work well. The old
> function can return NULL in bare repos. is_bare_repository() and
> is_inside_work_tree() expect NULL from get_git_work_tree() sometimes.
Ok, don't bother changing anything in that case---it won't help us much.
^ permalink raw reply
* Re: Rebasing multiple branches
From: Leonid Podolny @ 2010-12-22 14:54 UTC (permalink / raw)
To: weigelt; +Cc: git
In-Reply-To: <20101222143654.GA4829@nibiru.local>
On 12/22/2010 04:36 PM, Enrico Weigelt wrote:
> Why not this way ?
>
> git checkout D
> git rebase -p -i D~3 --onto C'
>
> (C' is the merged branch of A' and B').
>
>
> So:
>
> git checkout branch_A -b rebasing_A
> git rebase master # rebase old A to master
> git checkout branch_B -b rebasing_B
> git rebase master # rebase old B to master
> git checkout -b rebased_merge
> git merge rebasing_A # we're on B', merge in A'
> git checkout branch_C
> git rebase -p -i C --onto rebased_merge # set D~3..D ontop of it
>
>
> cu
Ah, nice. I didn't notice the -p option. However, the man page advises
against using -p and -i together.
^ permalink raw reply
* Re: Rebasing multiple branches
From: Enrico Weigelt @ 2010-12-22 14:36 UTC (permalink / raw)
To: git
In-Reply-To: <4D10B44D.5090309@viscovery.net>
* Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 12/21/2010 14:40, schrieb Leonid Podolny:
> > B--o--o--o--o--o--o <--branch A
> > / \
> > o--o--A--o--E <--master C--o--o--o--D <--branch C
> > \ /
> > C--o--o--o--o--o--o <--branch B
> >
> > I would like to rebase all three branches A, B and C onto commit E,...
>
> git rebase master A
> git rebase master B
> git merge A
> git rebase -i HEAD C
>
> The last rebase I propose as interactive so that you can remove those
> commits before D~3 that you have already rebased, because they are likely
> to conflict unnecessarily, and you would --skip them anyway.
Why not this way ?
git checkout D
git rebase -p -i D~3 --onto C'
(C' is the merged branch of A' and B').
So:
git checkout branch_A -b rebasing_A
git rebase master # rebase old A to master
git checkout branch_B -b rebasing_B
git rebase master # rebase old B to master
git checkout -b rebased_merge
git merge rebasing_A # we're on B', merge in A'
git checkout branch_C
git rebase -p -i C --onto rebased_merge # set D~3..D ontop of it
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
^ permalink raw reply
* [PATCH v5] convert filter: supply path to external driver
From: Pete Wyckoff @ 2010-12-22 14:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git, Jeff King, Johannes Sixt
In-Reply-To: <7vzkry7rb4.fsf@alter.siamese.dyndns.org>
Filtering to support keyword expansion may need the name of
the file being filtered. In particular, to support p4 keywords
like
$File: //depot/product/dir/script.sh $
the smudge filter needs to know the name of the file it is
smudging.
Allow "%f" in the custom filter command line specified in the
configuration. This will be substituted by the filename
inside a single-quote pair to be passed to the shell.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
gitster@pobox.com wrote on Tue, 21 Dec 2010 13:24 -0800:
> [detailed review]
Changes from v4:
- Updated commit message, docs per Junio mods
- Removed space after shell redirection ">"
- Simplified test case per Junio recommendations
Hopefully this is the last round of review and it is
safe to stage now. Thanks,
-- Pete
Documentation/gitattributes.txt | 10 +++++++++
convert.c | 22 +++++++++++++++++++-
t/t0021-conversion.sh | 42 +++++++++++++++++++++++++++++++++++++++
3 files changed, 73 insertions(+), 1 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 564586b..8c2fdd1 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -317,6 +317,16 @@ command is "cat").
smudge = cat
------------------------
+Sequence "%f" on the filter command line is replaced with the name of
+the file the filter is working on. A filter might use this in keyword
+substitution. For example:
+
+------------------------
+[filter "p4"]
+ clean = git-p4-filter --clean %f
+ smudge = git-p4-filter --smudge %f
+------------------------
+
Interaction between checkin/checkout attributes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/convert.c b/convert.c
index e41a31e..8f020bc 100644
--- a/convert.c
+++ b/convert.c
@@ -317,6 +317,7 @@ struct filter_params {
const char *src;
unsigned long size;
const char *cmd;
+ const char *path;
};
static int filter_buffer(int in, int out, void *data)
@@ -329,7 +330,23 @@ static int filter_buffer(int in, int out, void *data)
int write_err, status;
const char *argv[] = { NULL, NULL };
- argv[0] = params->cmd;
+ /* apply % substitution to cmd */
+ struct strbuf cmd = STRBUF_INIT;
+ struct strbuf path = STRBUF_INIT;
+ struct strbuf_expand_dict_entry dict[] = {
+ "f", NULL,
+ NULL, NULL,
+ };
+
+ /* quote the path to preserve spaces, etc. */
+ sq_quote_buf(&path, params->path);
+ dict[0].value = path.buf;
+
+ /* expand all %f with the quoted path */
+ strbuf_expand(&cmd, params->cmd, strbuf_expand_dict_cb, &dict);
+ strbuf_release(&path);
+
+ argv[0] = cmd.buf;
memset(&child_process, 0, sizeof(child_process));
child_process.argv = argv;
@@ -349,6 +366,8 @@ static int filter_buffer(int in, int out, void *data)
status = finish_command(&child_process);
if (status)
error("external filter %s failed %d", params->cmd, status);
+
+ strbuf_release(&cmd);
return (write_err || status);
}
@@ -376,6 +395,7 @@ static int apply_filter(const char *path, const char *src, size_t len,
params.src = src;
params.size = len;
params.cmd = cmd;
+ params.path = path;
fflush(NULL);
if (start_async(&async))
diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
index 828e35b..aacfd00 100755
--- a/t/t0021-conversion.sh
+++ b/t/t0021-conversion.sh
@@ -93,4 +93,46 @@ test_expect_success expanded_in_repo '
cmp expanded-keywords expected-output
'
+# The use of %f in a filter definition is expanded to the path to
+# the filename being smudged or cleaned. It must be shell escaped.
+# First, set up some interesting file names and pet them in
+# .gitattributes.
+test_expect_success 'filter shell-escaped filenames' '
+ cat >argc.sh <<-EOF &&
+ #!$SHELL_PATH
+ echo argc: \$# "\$@"
+ EOF
+ normal=name-no-magic &&
+ special="name with '\''sq'\'' and \$x" &&
+ echo some test text >"$normal" &&
+ echo some test text >"$special" &&
+ git add "$normal" "$special" &&
+ git commit -q -m "add files" &&
+ echo "name* filter=argc" >.gitattributes &&
+
+ # delete the files and check them out again, using a smudge filter
+ # that will count the args and echo the command-line back to us
+ git config filter.argc.smudge "sh ./argc.sh %f" &&
+ rm "$normal" "$special" &&
+ git checkout -- "$normal" "$special" &&
+
+ # make sure argc.sh counted the right number of args
+ echo "argc: 1 $normal" >expect &&
+ test_cmp expect "$normal" &&
+ echo "argc: 1 $special" >expect &&
+ test_cmp expect "$special" &&
+
+ # do the same thing, but with more args in the filter expression
+ git config filter.argc.smudge "sh ./argc.sh %f --my-extra-arg" &&
+ rm "$normal" "$special" &&
+ git checkout -- "$normal" "$special" &&
+
+ # make sure argc.sh counted the right number of args
+ echo "argc: 2 $normal --my-extra-arg" >expect &&
+ test_cmp expect "$normal" &&
+ echo "argc: 2 $special --my-extra-arg" >expect &&
+ test_cmp expect "$special" &&
+ :
+'
+
test_done
--
1.7.2.3
^ permalink raw reply related
* Expected behaviour of 'git log -S' when searching in a merged/deleted file?
From: Jonathan del Strother @ 2010-12-22 13:37 UTC (permalink / raw)
To: Git Mailing List
Hi,
I was trying to find a particular string in my project this morning.
'git grep mystring' suggested that the string didn't exist in my repo,
but 'git log -Smystring' turned up a single commit that had added it.
It took me a long time to figure out that in the past, a branch had
added that string to foo.c, but a second branch deleted foo.c, and the
two branches were later merged (deleting foo.c and ignoring mystring).
I was surprised that 'git log -S' didn't show the merge commit as the
point at which the string had been removed.
I've attached a testcase which I would expect to pass (perhaps
naively), but doesn't. Is this a git bug, or do I misunderstand git
log -S?
--
#!/bin/sh
test_description='git log'
. ./test-lib.sh
test_expect_success setup '
echo haystack\\nhaystack\\nhaystack\\nhaystack\\n > haystack &&
git add haystack &&
test_tick &&
git commit -m initial &&
git checkout -b branchA &&
echo needle >haystack &&
git add haystack &&
test_tick &&
git commit -m "adding needle" &&
git checkout -b branchB HEAD~1 &&
git rm haystack &&
test_tick &&
git commit -m "removing haystack" &&
git merge branchA || git rm haystack &&
test_tick &&
git commit -m "merging: haystack and needle removed"
'
printf "merging: haystack and needle removed\nadding needle" > expect
test_expect_success 'log -S in a merge-deleted file' '
git log -Sneedle --pretty="format:%s" > actual &&
test_cmp expect actual
'
test_done
^ permalink raw reply
* Re: "git pull" doesn't respect --work-tree parameter
From: Nguyen Thai Ngoc Duy @ 2010-12-22 11:55 UTC (permalink / raw)
To: Alexey Zakhlestin; +Cc: git
In-Reply-To: <AANLkTi=JrOe=z4LNZtxfsDvkG2jYCtemYESftv=61ZrJ@mail.gmail.com>
On Wed, Dec 22, 2010 at 6:50 PM, Alexey Zakhlestin <indeyets@gmail.com> wrote:
> 1) returns correct path:
> /Users/indy/Documents/Sources/_mine/midgard/mvc/_rdf/midgardmvc_core/.git
> 2) false
> 3) returns correct path, again:
> /Users/indy/Documents/Sources/_mine/midgard/mvc/_rdf/midgardmvc_core
>
> just to make myself clear: $PWD is another path, not related to repository path
OK. git-pull does not automatically move to worktree (while git-status
does) and thus won't work when $PWD is outside worktree. I remember
there's a similar report this year. I'll see if I can make a patch for
it.
Thank you for your report.
--
Duy
^ permalink raw reply
* Network problems during "git svn dcommit": need help!
From: Josef Wolf @ 2010-12-22 11:50 UTC (permalink / raw)
To: git
Hello,
I am using git-svn to track a subversion repository. This used to work
fine so far. But today, I got a network outage during a "git svn dcommit"
operation. I can see with gitk, that not all of my commits made it to
the svn repositoy. I tried "git svn rebase" and "git svn dcommit" to
resume, but they act as if I had no local commits.
Any hints how to fix the situation?
^ permalink raw reply
* Re: "git pull" doesn't respect --work-tree parameter
From: Alexey Zakhlestin @ 2010-12-22 11:50 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <AANLkTimM9Ah+D6uYnOuZDjYzKfN2-YVArOAwegO9dbSD@mail.gmail.com>
On Wed, Dec 22, 2010 at 2:44 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Wed, Dec 22, 2010 at 6:40 PM, Alexey Zakhlestin <indeyets@gmail.com> wrote:
>> On Wed, Dec 22, 2010 at 2:20 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>>> On Tue, Dec 21, 2010 at 11:04 PM, Alexey Zakhlestin <indeyets@gmail.com> wrote:
>>>> I am trying to use the following command:
>>>>
>>>> git '--git-dir=/path/to/repository/.git' '--work-tree=/path/to/repository' pull
>>>>
>>>> and get this error:
>>>> "git-pull cannot be used without a working tree"
>>>
>>> It works fine for me. What's the result of
>>>
>>> git '--git-dir=/path/to/repository/.git'
>>> '--work-tree=/path/to/repository' --git-dir
>>
>> No directory given for --git-dir.
>>
>>> git '--git-dir=/path/to/repository/.git'
>>> '--work-tree=/path/to/repository' --is-inside-work-tree
>>
>> Unknown option: --is-inside-work-tree
>>
>>> git '--git-dir=/path/to/repository/.git'
>>> '--work-tree=/path/to/repository' --show-toplevel
>>
>> Unknown option: --show-toplevel
>
> Sorry I forgot the command name (rev-parse). The full command should
> be "git --git-dir=... --work-tree=... rev-parse <option>" where option
> is --git-dir, --is-inside-work-tree, --show-toplevel. Can you please
> try again?
1) returns correct path:
/Users/indy/Documents/Sources/_mine/midgard/mvc/_rdf/midgardmvc_core/.git
2) false
3) returns correct path, again:
/Users/indy/Documents/Sources/_mine/midgard/mvc/_rdf/midgardmvc_core
just to make myself clear: $PWD is another path, not related to repository path
--
Alexey Zakhlestin, http://twitter.com/jimi_dini
http://www.milkfarmsoft.com/
^ permalink raw reply
* Re: "git pull" doesn't respect --work-tree parameter
From: Nguyen Thai Ngoc Duy @ 2010-12-22 11:44 UTC (permalink / raw)
To: Alexey Zakhlestin; +Cc: git
In-Reply-To: <AANLkTinGPJRQCOVz5JeqL4xnUG9V=5fkJhz6C5Mi1A3o@mail.gmail.com>
On Wed, Dec 22, 2010 at 6:40 PM, Alexey Zakhlestin <indeyets@gmail.com> wrote:
> On Wed, Dec 22, 2010 at 2:20 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>> On Tue, Dec 21, 2010 at 11:04 PM, Alexey Zakhlestin <indeyets@gmail.com> wrote:
>>> I am trying to use the following command:
>>>
>>> git '--git-dir=/path/to/repository/.git' '--work-tree=/path/to/repository' pull
>>>
>>> and get this error:
>>> "git-pull cannot be used without a working tree"
>>
>> It works fine for me. What's the result of
>>
>> git '--git-dir=/path/to/repository/.git'
>> '--work-tree=/path/to/repository' --git-dir
>
> No directory given for --git-dir.
>
>> git '--git-dir=/path/to/repository/.git'
>> '--work-tree=/path/to/repository' --is-inside-work-tree
>
> Unknown option: --is-inside-work-tree
>
>> git '--git-dir=/path/to/repository/.git'
>> '--work-tree=/path/to/repository' --show-toplevel
>
> Unknown option: --show-toplevel
Sorry I forgot the command name (rev-parse). The full command should
be "git --git-dir=... --work-tree=... rev-parse <option>" where option
is --git-dir, --is-inside-work-tree, --show-toplevel. Can you please
try again?
--
Duy
^ permalink raw reply
* Re: "git pull" doesn't respect --work-tree parameter
From: Andreas Ericsson @ 2010-12-22 11:42 UTC (permalink / raw)
To: Alexey Zakhlestin; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <AANLkTinGPJRQCOVz5JeqL4xnUG9V=5fkJhz6C5Mi1A3o@mail.gmail.com>
On 12/22/2010 12:40 PM, Alexey Zakhlestin wrote:
> On Wed, Dec 22, 2010 at 2:20 PM, Nguyen Thai Ngoc Duy<pclouds@gmail.com> wrote:
>> On Tue, Dec 21, 2010 at 11:04 PM, Alexey Zakhlestin<indeyets@gmail.com> wrote:
>>> I am trying to use the following command:
>>>
>>> git '--git-dir=/path/to/repository/.git' '--work-tree=/path/to/repository' pull
>>>
>>> and get this error:
>>> "git-pull cannot be used without a working tree"
>>
>> It works fine for me. What's the result of
>>
>> git '--git-dir=/path/to/repository/.git'
>> '--work-tree=/path/to/repository' --git-dir
>
> No directory given for --git-dir.
>
You added an extra --git-dir without an argument at the end of
the command. Remove it and try again.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: "git pull" doesn't respect --work-tree parameter
From: Alexey Zakhlestin @ 2010-12-22 11:40 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <AANLkTik9s0cLc_P=NWvpO=DhytOkLNASEM7sjzoscHo3@mail.gmail.com>
On Wed, Dec 22, 2010 at 2:20 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Tue, Dec 21, 2010 at 11:04 PM, Alexey Zakhlestin <indeyets@gmail.com> wrote:
>> I am trying to use the following command:
>>
>> git '--git-dir=/path/to/repository/.git' '--work-tree=/path/to/repository' pull
>>
>> and get this error:
>> "git-pull cannot be used without a working tree"
>
> It works fine for me. What's the result of
>
> git '--git-dir=/path/to/repository/.git'
> '--work-tree=/path/to/repository' --git-dir
No directory given for --git-dir.
> git '--git-dir=/path/to/repository/.git'
> '--work-tree=/path/to/repository' --is-inside-work-tree
Unknown option: --is-inside-work-tree
> git '--git-dir=/path/to/repository/.git'
> '--work-tree=/path/to/repository' --show-toplevel
Unknown option: --show-toplevel
> Also what version of git are you using?
1.7.3.4
--
Alexey Zakhlestin, http://twitter.com/jimi_dini
http://www.milkfarmsoft.com/
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
From: Andreas Ericsson @ 2010-12-22 11:39 UTC (permalink / raw)
To: Thiago Farina; +Cc: Junio C Hamano, git
In-Reply-To: <AANLkTin_u9FiZf-hbnhY0Dp+LifctxH8wKDL=yRrSpm+@mail.gmail.com>
On 12/22/2010 12:05 PM, Thiago Farina wrote:
>
> [1] Hope I will learn what this means and avoid it, something like,
> unnecessary, stupid, really trivial, etc...
churn:
Work for little or no benefit.
A patch that adds little or no value to the codebase by itself.
A patch that fixes a problem that isn't there in the real world but
could be there if some system somewhere followed some obscure standard
to the very letter is a typical example of code-churn.
A patch that introduces an poorly thought-out feature that nobody uses
is another common example, as is modifying code to accommodate adding
undefined features later. If the code-modifying is promptly followed
by a patch to introduce a new feature that relies on the new behaviour,
it's not considered churn since the new feature is already defined.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: "git pull" doesn't respect --work-tree parameter
From: Nguyen Thai Ngoc Duy @ 2010-12-22 11:20 UTC (permalink / raw)
To: Alexey Zakhlestin; +Cc: git
In-Reply-To: <AANLkTi=UtZuPQcTNnwS_fXgzRn4MHAUGS8zyTMqX9E2J@mail.gmail.com>
On Tue, Dec 21, 2010 at 11:04 PM, Alexey Zakhlestin <indeyets@gmail.com> wrote:
> I am trying to use the following command:
>
> git '--git-dir=/path/to/repository/.git' '--work-tree=/path/to/repository' pull
>
> and get this error:
> "git-pull cannot be used without a working tree"
It works fine for me. What's the result of
git '--git-dir=/path/to/repository/.git'
'--work-tree=/path/to/repository' --git-dir
git '--git-dir=/path/to/repository/.git'
'--work-tree=/path/to/repository' --is-inside-work-tree
git '--git-dir=/path/to/repository/.git'
'--work-tree=/path/to/repository' --show-toplevel
?
Also what version of git are you using?
--
Duy
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
From: Thiago Farina @ 2010-12-22 11:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlj3i5zz9.fsf@alter.siamese.dyndns.org>
On Tue, Dec 21, 2010 at 11:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
> * tf/commit-list-prefix (2010-11-26) 1 commit
> (merged to 'next' on 2010-12-21 at 16e1351)
> + commit: Add commit_list prefix in two function names.
>
> This churn
Since you said that, can could you drop this patch? I don't mind if
you discard this patch since you consider it a CHURN[1].
> already introduced an unnecessary conflict.
Which conflict? If you say, I could try to fix it.
> It is not by itself a biggie, but these things tend to add up.
How *these things* add a conflict? This is a new thing to me really.
[1] Hope I will learn what this means and avoid it, something like,
unnecessary, stupid, really trivial, etc...
^ permalink raw reply
* Re: Dangerous "git am --abort" behavior
From: Peter Krefting @ 2010-12-22 9:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <AANLkTinP4SArMkjvTXOEG=tf=8EcEdP9fPAB7F=iitSc@mail.gmail.com>
Linus Torvalds:
> I just noticed this, and I wonder if it has bitten me before without
> me noticing: "git am --abort" can be really dangerous.
Indeed, I have been bitten by that several times, having worked heavily on
applying patches at $dayjob for a while now. I have taken to habit to always
do the same "rm -rf .git/rebase-apply" that you mention before doing anything
involving am or rebase...
> Or maybe we could just introduce a new "git am --clean" that just flushes
> any old pending state (ie does that "clean_abort" thing, which is
> basically just the "rm -rf" I've done by hand).
That would be very helpful, as manually doing a "rm -rf" inside the .git
directory does make me nervous each time I do it...
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH 44/47] Remove all logic from get_git_work_tree()
From: Nguyen Thai Ngoc Duy @ 2010-12-22 7:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpqsu6059.fsf@alter.siamese.dyndns.org>
2010/12/22 Junio C Hamano <gitster@pobox.com>:
>> const char *get_git_work_tree(void)
>> {
>> - if (startup_info && !startup_info->setup_explicit) {
>> -...
>> - }
>> return work_tree;
>> }
>
> Would it be a bug in the new set-up code if this function gets called and
> work_tree is still NULL?
>
> There are quite a few callers that call get_git_work_tree() and expect
> that it will always return a non NULL pointer. Perhaps we would want an
> assertion here?
>
While the assertion sounds good, it does not work well. The old
function can return NULL in bare repos. is_bare_repository() and
is_inside_work_tree() expect NULL from get_git_work_tree() sometimes.
I'll see if I can move is_inside_work_tree() over environment.c (so
that both callers can access work_tree var directly) and have a clean
"make test". It does not look feasible though because of the static
variable inside_work_tree in setup.c.
--
Duy
^ permalink raw reply
* Re: [PATCH 36/47] rev-parse: prints --git-dir relative to user's cwd
From: Nguyen Thai Ngoc Duy @ 2010-12-22 7:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvd2m605f.fsf@alter.siamese.dyndns.org>
2010/12/22 Junio C Hamano <gitster@pobox.com>:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> git_dir variable in environment.c is relative to git's cwd, not user's
>> cwd. Convert the relative path (actualy by making it absolute path)
>> before printing out.
>>
>> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>> ---
>> builtin/rev-parse.c | 6 +++++-
>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>
>> diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
>> index a5a1c86..65c287b 100644
>> --- a/builtin/rev-parse.c
>> +++ b/builtin/rev-parse.c
>> @@ -647,7 +647,11 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
>> static char cwd[PATH_MAX];
>> int len;
>> if (gitdir) {
>> - puts(gitdir);
>> + if (is_absolute_path(gitdir) || !prefix) {
>> + puts(gitdir);
>> + continue;
>> + }
>> + puts(make_absolute_path(gitdir));
>> continue;
>> }
>> if (!prefix) {
>
> I do not quite understand this change. I can obtain GIT_DIR in a relative
> form without this patch already:
>
> $ cd t/
> $ git --git-dir=../.git rev-parse --git-dir HEAD
> ../.git
> c7511731675da8b50c0d5243aa04a98c8a5ee316
>
> Could we please have a new test case to demonstrate what is broken without
> this patch?
>
Um.. GIT_DIR can be changed by set_git_dir() inside
setup_directory_gently() and be relative to git's internal (movable)
cwd. The current code won't fall to that code path because GIT_DIR is
made absolute in most cases. A few cases we keep GIT_DIR relative,
we're sure cwd is not moved, or $GIT_DIR is not set and handled by
rev-parse code.
I reverted the patch and ran "make test". Passed. When an attempt to
make $GIT_DIR relative to worktree as much as possible happens, this
may be needed. But for now, I'm OK if you take this patch out. I'll
put it back on when I make such an attempt.
--
Duy
^ permalink raw reply
* Re: cvsimport still not working with cvsnt
From: Guy Rouillier @ 2010-12-22 5:43 UTC (permalink / raw)
To: Emil Medve
Cc: Jonathan Nieder, git, Pascal Obry, Clemens Buchacher,
Martin Langhoff
In-Reply-To: <4D112586.2060904@Freescale.com>
On 12/21/2010 5:09 PM, Emil Medve wrote:
> Hello Guy,
>
>
> On 12/20/10 15:36, Jonathan Nieder wrote:
>> (+cc: Emil, some cvsimport people)
>>
>> Guy Rouillier wrote:
>
> Sometimes, on some particularly nasty CVS repos, I noticed better
> results when using http://cvs2svn.tigris.org
>
>>> I'm going to try sending this blind, as the mailing list has sent me
>>> the promised authorization key after 24 hrs.
>>
>> No problem. Actually a subscription is not required --- the
>> convention on this list is to always reply-to-all.
>>
>>> I finally found the problems, both of which were reported in 2008
>>> here:
>>>
>>> http://kerneltrap.org/mailarchive/git/2008/3/13/1157364
>>
>> Seems to have received no replies[1].
>
> I don't remember why, but that patch didn't get enough interest
>
>>> I do see one possible issue with the supplied modifications. At
>>> work, we upgraded from CVS to CVSNT. So, my home directory has both
>>> .cvspass (from the original CVS) and .cvs/cvspass (after the
>>> conversion to CVSNT.) Sloppy housekeeping on my part, I admit, but
>>> probably not uncommon. The supplied patch would pick up the
>>> original CVS file and would fail. (BTW, this is true only of the
>>> git-cvsimport.perl script itself; cvsps must shell out to the
>>> installed CVS client (in my case, cvsnt), because when I invoked
>>> that manually, it worked.)
>>>
>>> So, I would advise checking to see if both files exist, and if so
>>> exit with an error. Unless cvsimport wants to get real fancy and
>>> shell out to the installed cvs client to try to figure out what is
>>> installed, there is no way to tell which cvspass file is actively
>>> being used. I don't recommend trying to figure this out, as the
>>> user's intent is unclear.
>>
>> Thanks, sounds sane to me. Care to write a patch?
>
> If you care enough about this scenario, how about search for the
> relevant<CVSROOT, password> in both files. If you find just one pair or
> if you find a pair in both files and they are "equal" then just use it.
> If you find two pairs, one in each file, use the one from the file with
> a newer modified time-stamp. In a migration scenario such as this, you'd
> imaging the "old" file will get stale after a while. Not perfect, but
> some informational messages in case of a duplicate would help the user
> clarify their intentions
>
> Additionally/Alternatively just add a command line parameter to allow
> the user to explicitly specify a cvspass file
Emil and Jonathan, thanks for the feedback. Perl is not my strong
point, but I'll take a crack at it over the upcoming holidays. I'm
inclined not to get too fancy and try to second-guess the user's
environment. Perhaps he has both cvs and cvsnt installed for some
reason (testing one, using the other for regular work); perhaps a tool
installed one or the other and he doesn't even know he has them both. Etc.
So, at most I can see, as Emil suggested, seeing if the entry exists in
both files and is the same in both. If so, or if the entry is only in
one of them, then just use the entry. However, if the entry is in both
files and is different, I'd prefer to just exit with an error and have
the user clarify his environment.
--
Guy Rouillier
^ permalink raw reply
* What's cooking in git.git (Dec 2010, #06; Tue, 21)
From: Junio C Hamano @ 2010-12-22 1:59 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
I'd like to merge nd/setup, nd/struct-pathspec, and everything in
tonight's 'next' soon and tag 1.7.4-rc1 but I might be being a bit too
ambitious.
--------------------------------------------------
[Graduated to "master"]
* jk/maint-decorate-01-bool (2010-12-18) 1 commit
(merged to 'next' on 2010-12-20 at 72471ca)
+ handle arbitrary ints in git_config_maybe_bool
* jk/t2107-now-passes (2010-12-18) 1 commit
(merged to 'next' on 2010-12-20 at c9156b5)
+ t2107: mark passing test as success
* jn/maint-gitweb-pathinfo-fix (2010-12-14) 1 commit
(merged to 'next' on 2010-12-14 at 1af8cca)
+ gitweb: Fix handling of whitespace in generated links
* ks/blame-worktree-textconv-cached (2010-12-18) 2 commits
(merged to 'next' on 2010-12-20 at 459c940)
+ fill_textconv(): Don't get/put cache if sha1 is not valid
+ t/t8006: Demonstrate blame is broken when cachetextconv is on
* nd/oneline-sha1-name-from-specific-ref (2010-12-15) 4 commits
(merged to 'next' on 2010-12-20 at 553cf37)
+ get_sha1: handle special case $commit^{/}
+ get_sha1: support $commit^{/regex} syntax
+ get_sha1_oneline: make callers prepare the commit list to traverse
+ get_sha1_oneline: fix lifespan rule of temp_commit_buffer variable
* tc/completion-reflog (2010-12-16) 1 commit
(merged to 'next' on 2010-12-20 at 2fa91e0)
+ bash completion: add basic support for git-reflog
--------------------------------------------------
[New Topics]
* jk/commit-die-on-bogus-ident (2010-12-20) 2 commits
(merged to 'next' on 2010-12-21 at 7785c31)
+ commit: die before asking to edit the log message
+ ident: die on bogus date format
* jc/maint-am-abort-safely (2010-12-21) 1 commit
(merged to 'next' on 2010-12-21 at 81602bc)
+ am --abort: keep unrelated commits since the last failure and warn
--------------------------------------------------
[Stalled]
* mg/cvsimport (2010-11-28) 3 commits
- cvsimport.txt: document the mapping between config and options
- cvsimport: fix the parsing of uppercase config options
- cvsimport: partial whitespace cleanup
I was being lazy and said "Ok" to "cvsimport.capital-r" but luckily other
people injected sanity to the discussion. Weatherbaloon patch sent, but
not queued here.
* nd/index-doc (2010-09-06) 1 commit
- doc: technical details about the index file format
Half-written but it is a good start. I may need to give some help in
describing more recent index extensions.
* cb/ignored-paths-are-precious (2010-08-21) 1 commit
- checkout/merge: optionally fail operation when ignored files need to be overwritten
This needs tests; also we know of longstanding bugs in related area that
needs to be addressed---they do not have to be part of this series but
their reproduction recipe would belong to the test script for this topic.
It would hurt users to make the new feature on by default, especially the
ones with subdirectories that come and go.
* jk/tag-contains (2010-07-05) 4 commits
- Why is "git tag --contains" so slow?
- default core.clockskew variable to one day
- limit "contains" traversals based on commit timestamp
- tag: speed up --contains calculation
The idea of the bottom one is probably Ok, except that the use of object
flags needs to be rethought, or at least the helper needs to be moved to
builtin/tag.c to make it clear that it should not be used outside the
current usage context.
* tr/config-doc (2010-10-24) 2 commits
. Documentation: complete config list from other manpages
. Documentation: Move variables from config.txt to separate file
This unfortunately heavily conflicts with patches in flight...
--------------------------------------------------
[Cooking]
* rj/maint-difftool-cygwin-workaround (2010-12-14) 1 commit
(merged to 'next' on 2010-12-21 at 74b9069)
+ difftool: Fix failure on Cygwin
* rj/maint-test-fixes (2010-12-14) 5 commits
(merged to 'next' on 2010-12-21 at 8883a0c)
+ t9501-*.sh: Fix a test failure on Cygwin
+ lib-git-svn.sh: Add check for mis-configured web server variables
+ lib-git-svn.sh: Avoid setting web server variables unnecessarily
+ t9142: Move call to start_httpd into the setup test
+ t3600-rm.sh: Don't pass a non-existent prereq to test #15
* rj/test-fixes (2010-12-14) 4 commits
- t4135-*.sh: Skip the "backslash" tests on cygwin
- t3032-*.sh: Do not strip CR from line-endings while grepping on MinGW
- t3032-*.sh: Pass the -b (--binary) option to sed on cygwin
- t6038-*.sh: Pass the -b (--binary) option to sed on cygwin
* tr/maint-branch-no-track-head (2010-12-14) 1 commit
- branch: do not attempt to track HEAD implicitly
Probably needs a re-roll to exclude either (1) any ref outside the
hierarchies for branches (i.e. refs/{heads,remotes}/), or (2) only refs
outside refs/ hierarchies (e.g. HEAD, ORIG_HEAD, ...). The latter feels
safer and saner.
* by/log-l (2010-12-14) 8 commits
. log -L: implement move/copy detection (-M/-C)
. log -L: add --full-line-diff option
. log -L: add --graph prefix before output
. log -L: support parent rewriting
. Implement line-history search (git log -L)
. Export rewrite_parents() for 'log -L'
. Export three functions from diff.c
. Refactor parse_loc
Seems to have some bad interactions with nd/struct-pathspec.
* hv/mingw-fs-funnies (2010-12-14) 5 commits
- mingw_rmdir: set errno=ENOTEMPTY when appropriate
- mingw: add fallback for rmdir in case directory is in use
- mingw: make failures to unlink or move raise a question
- mingw: work around irregular failures of unlink on windows
- mingw: move unlink wrapper to mingw.c
Can somebody remind me what the status of this series is?
* tf/commit-list-prefix (2010-11-26) 1 commit
(merged to 'next' on 2010-12-21 at 16e1351)
+ commit: Add commit_list prefix in two function names.
This churn already introduced an unnecessary conflict. It is not by
itself a biggie, but these things tend to add up.
* pd/bash-4-completion (2010-12-15) 3 commits
(merged to 'next' on 2010-12-21 at dbf80ff)
+ Merge branch 'master' (early part) into pd/bash-4-completion
+ bash: simple reimplementation of _get_comp_words_by_ref
+ bash: get --pretty=m<tab> completion to work with bash v4
* jn/svn-fe (2010-12-06) 18 commits
- vcs-svn: Allow change nodes for root of tree (/)
- vcs-svn: Implement Prop-delta handling
- vcs-svn: Sharpen parsing of property lines
- vcs-svn: Split off function for handling of individual properties
- vcs-svn: Make source easier to read on small screens
- vcs-svn: More dump format sanity checks
- vcs-svn: Reject path nodes without Node-action
- vcs-svn: Delay read of per-path properties
- vcs-svn: Combine repo_replace and repo_modify functions
- vcs-svn: Replace = Delete + Add
- vcs-svn: handle_node: Handle deletion case early
- vcs-svn: Use mark to indicate nodes with included text
- vcs-svn: Unclutter handle_node by introducing have_props var
- vcs-svn: Eliminate node_ctx.mark global
- vcs-svn: Eliminate node_ctx.srcRev global
- vcs-svn: Check for errors from open()
- vcs-svn: Allow simple v3 dumps (no deltas yet)
- vcs-svn: Error out for v3 dumps
Some RFC patches, to give them early and wider exposure.
* nd/maint-fix-add-typo-detection (2010-11-27) 5 commits
(merged to 'next' on 2010-12-21 at 87c702b)
+ Revert "excluded_1(): support exclude files in index"
+ unpack-trees: fix sparse checkout's "unable to match directories"
+ unpack-trees: move all skip-worktree checks back to unpack_trees()
+ dir.c: add free_excludes()
+ cache.h: realign and use (1 << x) form for CE_* constants
* jh/gitweb-caching (2010-12-03) 4 commits
. gitweb: Minimal testing of gitweb caching
. gitweb: File based caching layer (from git.kernel.org)
. gitweb: add output buffering and associated functions
. gitweb: Prepare for splitting gitweb
Previous iteration; dropped.
* jh/gitweb-caching-8 (2010-12-09) 18 commits
. gitweb: Add better error handling for gitweb caching
. gitweb: Prepare for cached error pages & better error page handling
. gitweb: When changing output (STDOUT) change STDERR as well
. gitweb: Add show_warning() to display an immediate warning, with refresh
. gitweb: add print_transient_header() function for central header printing
. gitweb: Add commented url & url hash to page footer
. gitweb: Change file handles (in caching) to lexical variables as opposed to globs
. gitweb: add isDumbClient() check
. gitweb: Adding isBinaryAction() and isFeedAction() to determine the action type
. gitweb: Revert reset_output() back to original code
. gitweb: Change is_cacheable() to return true always
. gitweb: Revert back to $cache_enable vs. $caching_enabled
. gitweb: Add more explicit means of disabling 'Generating...' page
. gitweb: Regression fix concerning binary output of files
. gitweb: Minimal testing of gitweb caching
. gitweb: File based caching layer (from git.kernel.org)
. gitweb: add output buffering and associated functions
. gitweb: Prepare for splitting gitweb
It appears that John and Jakub are finally working together to help
producing something that we can ship in-tree, finally. I am looking
forward to seeing the conclusion of the discussion.
* nd/setup (2010-11-26) 47 commits
- git.txt: correct where --work-tree path is relative to
- Revert "Documentation: always respect core.worktree if set"
- t0001: test git init when run via an alias
- Remove all logic from get_git_work_tree()
- setup: rework setup_explicit_git_dir()
- setup: clean up setup_discovered_git_dir()
- t1020-subdirectory: test alias expansion in a subdirectory
- setup: clean up setup_bare_git_dir()
- setup: limit get_git_work_tree()'s to explicit setup case only
- Use git_config_early() instead of git_config() during repo setup
- Add git_config_early()
- rev-parse: prints --git-dir relative to user's cwd
- git-rev-parse.txt: clarify --git-dir
- t1510: setup case #31
- t1510: setup case #30
- t1510: setup case #29
- t1510: setup case #28
- t1510: setup case #27
- t1510: setup case #26
- t1510: setup case #25
- t1510: setup case #24
- t1510: setup case #23
- t1510: setup case #22
- t1510: setup case #21
- t1510: setup case #20
- t1510: setup case #19
- t1510: setup case #18
- t1510: setup case #17
- t1510: setup case #16
- t1510: setup case #15
- t1510: setup case #14
- t1510: setup case #13
- t1510: setup case #12
- t1510: setup case #11
- t1510: setup case #10
- t1510: setup case #9
- t1510: setup case #8
- t1510: setup case #7
- t1510: setup case #6
- t1510: setup case #5
- t1510: setup case #4
- t1510: setup case #3
- t1510: setup case #2
- t1510: setup case #1
- t1510: setup case #0
- Add t1510 and basic rules that run repo setup
- builtins: print setup info if repo is found
Need to re-read this series to move it forward.
* yd/dir-rename (2010-10-29) 5 commits
- Allow hiding renames of individual files involved in a directory rename.
- Unified diff output format for bulk moves.
- Add testcases for the --detect-bulk-moves diffcore flag.
- Raw diff output format for bulk moves.
- Introduce bulk-move detection in diffcore.
Need to re-queue the reroll.
* nd/struct-pathspec (2010-12-15) 21 commits
- t7810: overlapping pathspecs and depth limit
- grep: drop pathspec_matches() in favor of tree_entry_interesting()
- grep: use writable strbuf from caller for grep_tree()
- grep: use match_pathspec_depth() for cache/worktree grepping
- grep: convert to use struct pathspec
- Convert ce_path_match() to use match_pathspec_depth()
- Convert ce_path_match() to use struct pathspec
- struct rev_info: convert prune_data to struct pathspec
- pathspec: add match_pathspec_depth()
- tree_entry_interesting(): optimize wildcard matching when base is matched
- tree_entry_interesting(): support wildcard matching
- tree_entry_interesting(): fix depth limit with overlapping pathspecs
- tree_entry_interesting(): support depth limit
- tree_entry_interesting(): refactor into separate smaller functions
- diff-tree: convert base+baselen to writable strbuf
- glossary: define pathspec
- Move tree_entry_interesting() to tree-walk.c and export it
- tree_entry_interesting(): remove dependency on struct diff_options
- Convert struct diff_options to use struct pathspec
- diff-no-index: use diff_tree_setup_paths()
- Add struct pathspec
(this branch is used by en/object-list-with-pathspec.)
Rerolled again. Getting nicer by the round ;-)
* en/object-list-with-pathspec (2010-09-20) 2 commits
- Add testcases showing how pathspecs are handled with rev-list --objects
- Make rev-list --objects work together with pathspecs
(this branch uses nd/struct-pathspec.)
* tr/merge-unborn-clobber (2010-08-22) 1 commit
- Exhibit merge bug that clobbers index&WT
* ab/i18n (2010-10-07) 161 commits
- po/de.po: complete German translation
- po/sv.po: add Swedish translation
- gettextize: git-bisect bisect_next_check "You need to" message
- gettextize: git-bisect [Y/n] messages
- gettextize: git-bisect bisect_replay + $1 messages
- gettextize: git-bisect bisect_reset + $1 messages
- gettextize: git-bisect bisect_run + $@ messages
- gettextize: git-bisect die + eval_gettext messages
- gettextize: git-bisect die + gettext messages
- gettextize: git-bisect echo + eval_gettext message
- gettextize: git-bisect echo + gettext messages
- gettextize: git-bisect gettext + echo message
- gettextize: git-bisect add git-sh-i18n
- gettextize: git-stash drop_stash say/die messages
- gettextize: git-stash "unknown option" message
- gettextize: git-stash die + eval_gettext $1 messages
- gettextize: git-stash die + eval_gettext $* messages
- gettextize: git-stash die + eval_gettext messages
- gettextize: git-stash die + gettext messages
- gettextize: git-stash say + gettext messages
- gettextize: git-stash echo + gettext message
- gettextize: git-stash add git-sh-i18n
- gettextize: git-submodule "blob" and "submodule" messages
- gettextize: git-submodule "path not initialized" message
- gettextize: git-submodule "[...] path is ignored" message
- gettextize: git-submodule "Entering [...]" message
- gettextize: git-submodule $errmsg messages
- gettextize: git-submodule "Submodule change[...]" messages
- gettextize: git-submodule "cached cannot be used" message
- gettextize: git-submodule $update_module say + die messages
- gettextize: git-submodule die + eval_gettext messages
- gettextize: git-submodule say + eval_gettext messages
- gettextize: git-submodule echo + eval_gettext messages
- gettextize: git-submodule add git-sh-i18n
- gettextize: git-pull "rebase against" / "merge with" messages
- gettextize: git-pull "[...] not currently on a branch" message
- gettextize: git-pull "You asked to pull" message
- gettextize: git-pull split up "no candidate" message
- gettextize: git-pull eval_gettext + warning message
- gettextize: git-pull eval_gettext + die message
- gettextize: git-pull die messages
- gettextize: git-pull add git-sh-i18n
- gettext docs: add "Testing marked strings" section to po/README
- gettext docs: the Git::I18N Perl interface
- gettext docs: the git-sh-i18n.sh Shell interface
- gettext docs: the gettext.h C interface
- gettext docs: add "Marking strings for translation" section in po/README
- gettext docs: add a "Testing your changes" section to po/README
- po/pl.po: add Polish translation
- po/hi.po: add Hindi Translation
- po/en_GB.po: add British English translation
- po/de.po: add German translation
- Makefile: only add gettext tests on XGETTEXT_INCLUDE_TESTS=YesPlease
- gettext docs: add po/README file documenting Git's gettext
- gettextize: git-am printf(1) message to eval_gettext
- gettextize: git-am core say messages
- gettextize: git-am "Apply?" message
- gettextize: git-am clean_abort messages
- gettextize: git-am cannot_fallback messages
- gettextize: git-am die messages
- gettextize: git-am eval_gettext messages
- gettextize: git-am multi-line getttext $msg; echo
- gettextize: git-am one-line gettext $msg; echo
- gettextize: git-am add git-sh-i18n
- gettext tests: add GETTEXT_POISON tests for shell scripts
- gettext tests: add GETTEXT_POISON support for shell scripts
- Makefile: MSGFMT="msgfmt --check" under GNU_GETTEXT
- Makefile: add GNU_GETTEXT, set when we expect GNU gettext
- gettextize: git-shortlog basic messages
- gettextize: git-revert split up "could not revert/apply" message
- gettextize: git-revert literal "me" messages
- gettextize: git-revert "Your local changes" message
- gettextize: git-revert basic messages
- gettextize: git-notes "Refusing to %s notes in %s" message
- gettextize: git-notes GIT_NOTES_REWRITE_MODE error message
- gettextize: git-notes basic commands
- gettextize: git-gc "Auto packing the repository" message
- gettextize: git-gc basic messages
- gettextize: git-describe basic messages
- gettextize: git-clean clean.requireForce messages
- gettextize: git-clean basic messages
- gettextize: git-bundle basic messages
- gettextize: git-archive basic messages
- gettextize: git-status "renamed: " message
- gettextize: git-status "Initial commit" message
- gettextize: git-status "Changes to be committed" message
- gettextize: git-status shortstatus messages
- gettextize: git-status "nothing to commit" messages
- gettextize: git-status basic messages
- gettextize: git-push "prevent you from losing" message
- gettextize: git-push basic messages
- gettextize: git-tag tag_template message
- gettextize: git-tag basic messages
- gettextize: git-reset "Unstaged changes after reset" message
- gettextize: git-reset reset_type_names messages
- gettextize: git-reset basic messages
- gettextize: git-rm basic messages
- gettextize: git-mv "bad" messages
- gettextize: git-mv basic messages
- gettextize: git-merge "Wonderful" message
- gettextize: git-merge "You have not concluded your merge" messages
- gettextize: git-merge "Updating %s..%s" message
- gettextize: git-merge basic messages
- gettextize: git-log "--OPT does not make sense" messages
- gettextize: git-log basic messages
- gettextize: git-grep "--open-files-in-pager" message
- gettextize: git-grep basic messages
- gettextize: git-fetch split up "(non-fast-forward)" message
- gettextize: git-fetch update_local_ref messages
- gettextize: git-fetch formatting messages
- gettextize: git-fetch basic messages
- gettextize: git-diff basic messages
- gettextize: git-commit advice messages
- gettextize: git-commit "enter the commit message" message
- gettextize: git-commit print_summary messages
- gettextize: git-commit formatting messages
- gettextize: git-commit "middle of a merge" message
- gettextize: git-commit basic messages
- gettextize: git-checkout "Switched to a .. branch" message
- gettextize: git-checkout "HEAD is now at" message
- gettextize: git-checkout describe_detached_head messages
- gettextize: git-checkout: our/their version message
- gettextize: git-checkout basic messages
- gettextize: git-branch "(no branch)" message
- gettextize: git-branch "git branch -v" messages
- gettextize: git-branch "Deleted branch [...]" message
- gettextize: git-branch "remote branch '%s' not found" message
- gettextize: git-branch basic messages
- gettextize: git-add refresh_index message
- gettextize: git-add "remove '%s'" message
- gettextize: git-add "pathspec [...] did not match" message
- gettextize: git-add "Use -f if you really want" message
- gettextize: git-add "no files added" message
- gettextize: git-add basic messages
- gettextize: git-clone "Cloning into" message
- gettextize: git-clone basic messages
- gettext tests: test message re-encoding under C
- po/is.po: add Icelandic translation
- gettext tests: mark a test message as not needing translation
- gettext tests: test re-encoding with a UTF-8 msgid under Shell
- gettext tests: test message re-encoding under Shell
- gettext tests: add detection for is_IS.ISO-8859-1 locale
- gettext tests: test if $VERSION exists before using it
- gettextize: git-init "Initialized [...] repository" message
- gettextize: git-init basic messages
- gettext tests: skip lib-gettext.sh tests under GETTEXT_POISON
- gettext tests: add GETTEXT_POISON=YesPlease Makefile parameter
- gettext.c: use libcharset.h instead of langinfo.h when available
- gettext.c: work around us not using setlocale(LC_CTYPE, "")
- builtin.h: Include gettext.h
- Makefile: use variables and shorter lines for xgettext
- Makefile: tell xgettext(1) that our source is in UTF-8
- Makefile: provide a --msgid-bugs-address to xgettext(1)
- Makefile: A variable for options used by xgettext(1) calls
- gettext tests: locate i18n lib&data correctly under --valgrind
- gettext: setlocale(LC_CTYPE, "") breaks Git's C function assumptions
- gettext tests: rename test to work around GNU gettext bug
- gettext: add infrastructure for translating Git with gettext
- builtin: use builtin.h for all builtin commands
- tests: use test_cmp instead of piping to diff(1)
- t7004-tag.sh: re-arrange git tag comment for clarity
It is getting ridiculously painful to keep re-resolving the conflicts with
other topics in flight, even with the help with rerere.
Needs a bit more minor work to get the basic code structure right.
^ permalink raw reply
* Re: [PATCH 44/47] Remove all logic from get_git_work_tree()
From: Junio C Hamano @ 2010-12-22 1:56 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1290785563-15339-45-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> This logic is now only used by cmd_init_db(). setup_* functions do not
> rely on it any more. Move all the logic to cmd_init_db() and turn
> get_git_work_tree() into a simple function.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> diff --git a/environment.c b/environment.c
> index d811049..149c132 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -137,36 +137,20 @@ static int git_work_tree_initialized;
> */
> ...
> const char *get_git_work_tree(void)
> {
> - if (startup_info && !startup_info->setup_explicit) {
> -...
> - }
> return work_tree;
> }
Would it be a bug in the new set-up code if this function gets called and
work_tree is still NULL?
There are quite a few callers that call get_git_work_tree() and expect
that it will always return a non NULL pointer. Perhaps we would want an
assertion here?
^ permalink raw reply
* Re: [PATCH 36/47] rev-parse: prints --git-dir relative to user's cwd
From: Junio C Hamano @ 2010-12-22 1:56 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1290785563-15339-37-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> git_dir variable in environment.c is relative to git's cwd, not user's
> cwd. Convert the relative path (actualy by making it absolute path)
> before printing out.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> builtin/rev-parse.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
> index a5a1c86..65c287b 100644
> --- a/builtin/rev-parse.c
> +++ b/builtin/rev-parse.c
> @@ -647,7 +647,11 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
> static char cwd[PATH_MAX];
> int len;
> if (gitdir) {
> - puts(gitdir);
> + if (is_absolute_path(gitdir) || !prefix) {
> + puts(gitdir);
> + continue;
> + }
> + puts(make_absolute_path(gitdir));
> continue;
> }
> if (!prefix) {
I do not quite understand this change. I can obtain GIT_DIR in a relative
form without this patch already:
$ cd t/
$ git --git-dir=../.git rev-parse --git-dir HEAD
../.git
c7511731675da8b50c0d5243aa04a98c8a5ee316
Could we please have a new test case to demonstrate what is broken without
this patch?
^ 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