* Re: [PATCH] Simplify strchrnul() compat code
From: Jakub Narebski @ 2007-11-12 10:07 UTC (permalink / raw)
To: git
In-Reply-To: <ee77f5c20711120152i4955ed3bh484c9ac76a7f1f5c@mail.gmail.com>
David Symonds wrote:
> On Nov 12, 2007 8:50 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> -#if !defined(__GLIBC_PREREQ) && !__GLIBC_PREREQ(2, 1)
>> +#ifdef __GLIBC_PREREQ
>> +#if __GLIBC_PREREQ(2, 1)
>> +#define HAVE_STRCHRNUL
>> +#endif
>> +#endif
>> +
>> +#ifndef HAVE_STRCHRNUL
>>
>> #define strchrnul gitstrchrnul
>> static inline char *gitstrchrnul(const char *s, int c)
>> {
>
> Yep, that works just fine. Ack.
This version has also the following advantage that you can set
HAVE_STRCHRNULL if above test does not detect it in your library.
Althought you'd better write then:
+#if __GLIBC_PREREQ(2, 1) && !defined(HAVE_STRCHRNUL)
Ack.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Fix preprocessor logic that determines the availablity of strchrnul().
From: Johannes Sixt @ 2007-11-12 10:09 UTC (permalink / raw)
To: David Symonds, Junio C Hamano
Cc: Andreas Ericsson, René Scharfe, Pierre Habouzit,
Git Mailing List, Johannes Schindelin, Jakub Narebski
In-Reply-To: <ee77f5c20711120152i4955ed3bh484c9ac76a7f1f5c@mail.gmail.com>
Apart from the error in the condition (&& should actually be ||), the
construct
#if !defined(A) || !A
leads to a syntax error in the C preprocessor if A is indeed not defined.
Tested-by: David Symonds <dsymonds@gmail.com>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
git-compat-util.h | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 3d147b6..276a437 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -184,7 +184,13 @@ void *gitmemmem(const void *haystack, size_t haystacklen,
const void *needle, size_t needlelen);
#endif
-#if !defined(__GLIBC_PREREQ) && !__GLIBC_PREREQ(2, 1)
+#ifdef __GLIBC_PREREQ
+#if __GLIBC_PREREQ(2, 1)
+#define HAVE_STRCHRNUL
+#endif
+#endif
+
+#ifndef HAVE_STRCHRNUL
#define strchrnul gitstrchrnul
static inline char *gitstrchrnul(const char *s, int c)
{
--
1.5.3.5.578.g1f8ec
^ permalink raw reply related
* Re: Deprecate git-fetch-pack?
From: Andreas Ericsson @ 2007-11-12 10:15 UTC (permalink / raw)
To: Theodore Tso
Cc: Johannes Schindelin, Junio C Hamano, Ask Bjørn Hansen,
Daniel Barkalow, git
In-Reply-To: <20071111235819.GB7392@thunk.org>
Theodore Tso wrote:
> On Sun, Nov 11, 2007 at 10:50:26PM +0000, Johannes Schindelin wrote:
>> I beg to differ. The biggest problem with a new user seeing all those
>> completions is that this user is scared.
>
> Well, if we introduce the new user only to "git subcomand", and the
> documentation is relatively gentle, I would suspect would solve most
> of the problem. Note BTW, that if your thesis is true, "git help -a"
> (which is recommended in the last line of output by "git help") should
> cause the typical new user to faint dead away. :-)
>
> Some other areas that would be worth fixing, in terms of user usability.
>
> 1) The references to the tutorial, everyday git, etc., don't actually
> have working references in the git man page. (i.e., what you see when
> you run the command "man git"). It would be nice if that were fixed.
>
> 2) The command which are displayed by "git help" should use some
> serious rethinking. Ideally, it would be nice if the output fit in a
> single 24-line terminal window. Some candidates for removal:
>
> a) prune: "git prune" definitely doesn't deserve to be on the
> front and center as displayed by "git help". Maybe replace it
> with "gc", but now that we have gc.auto, I'm not sure it's
> worth it at all.
>
prune is definitely scary, and users don't need to know about it until
they've worked with git for quite some time.
> b) revert: Is that really that common of a command?
>
I think I've used it once ;-)
> c) show-branch: The output is terrifying without explanation
>
Indeed. I still don't grok it fully. I tend to use gitk/qgit and some
brainpower to obtain the same result.
> There are other commands I'm not so sure about, but it is worth
> flagging them. One way that might be helpful is to group the commands
> into subcommands, much like gdb does, so you could do something like
> "git help other-repos" (where all commands that involve interacting
> with other repositories are summarized), and so on.
>
Ack on that. I suggested it a while back and it appears many liked the
idea. I'm really bad at writing docs though, so it's one of those things
I've been putting off for "some other day".
>> But yes, I was only proposing to deprecate all usage of git-<bla> in the
>> documentation.
>
> I agree that de-emphasizing git-<blah> isn't a bad thing. But I think
> we need to look at the big picture here, since "git help" is often one
> of the first things a new user might try (and obviously very few git
> developers look at it, or "prune" probably would have been removed
> from git help a long time ago :-), and the last thing that git help
> suggests (and so therefore it will very visible to the newbie user),
> is "git help -a" --- and that displays every single git command under
> creation, porcelain or plumbing, in one gigantic sorted list.
>
> Oops, so much for first impressions. :-)
>
I agree. Culling the list output by "git help -a" to only show the
porcelain commands would definitely be worthwhile. I'm not sure if it's
worth having a way of showing every installed git command at all (I
know I've never used it anyway).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive
From: Andreas Ericsson @ 2007-11-12 10:21 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20071112062222.GA17462@thunk.org>
Theodore Tso wrote:
>
> They probably would be submitting changes back upstream using e-mail
> before they learn how to publish their own repository, so commands I'd
> be tempted to add would include git-format-patch, git-send-email, and
> git-cherry. But these commands are pretty complicated for beginners....
>
git format-patch could probably go in, but skip the others. I've never
used git cherry in my entire life and it's not, strictly speaking,
necessary for users to have it. There are other and easier ways to
find the same information.
I'd keep cherry-pick though. It's incredibly useful, and especially
when a commit ends up on the wrong branch which is something newbies
are likely to do when they start trying out the topic-branch workflow.
I still do it sometimes, but hardly ever stop thinking about it since
it's so easy to fix thanks to cherry-pick.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive
From: Mike Hommey @ 2007-11-12 10:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Theodore Tso, Git Mailing List
In-Reply-To: <7vhcjr53hp.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 11, 2007 at 11:26:10PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> > My mental model for git newbies is that they would probably be pulling
> > from upstream repositories (so I was tempted to remove git-init from
> > the common commands list), but they would rarely be cherry-picking or
> > reverting other people's changes.
>
> I'd agree with that, but reverting and cherry-picking would also
> be done on the commits the user builds on top of other people's
> changes.
On the other hand, cherry-picking and reverting are just the same thing,
except one applies a reversed patch. Wouldn't it make sense to merge these
two in one command ?
Mike
^ permalink raw reply
* Re: git diff woes
From: Andreas Ericsson @ 2007-11-12 10:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711120958500.4362@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 12 Nov 2007, Andreas Ericsson wrote:
>
>> I recently ran into an oddity with the excellent git diff output
>> format. When a function declaration changes in the same patch as
>> something else in a function, the old declaration is used with the
>> diff hunk-headers.
>>
>> [...]
>>
>> It definitely looks like a bug, but really isn't, since an earlier hunk
>> (pasted below) changes the declaration.
>>
>> [...]
>>
>> This makes it impossible to trust the hunk-header info if the declaration
>> changes.
>
> Huh? You admit yourself that it is not a bug.
In the check_ntpd.c program, there is no bug. I found the git diff output
surprising, so I reported it.
> And sure you can trust the
> hunk header. Like most of the things, the relate to the _original_
> version, since the diff is meant to be applied as a forward patch.
>
> So for all practical matters, the diff shows the correct thing: "in this
> hunk, which (still) belongs to that function, change this and this."
>
> Of course, that is only the case if you accept that the diff should be
> applied _in total_, not piecewise. IOW if you are a fan of GNU patch
> which happily clobbers your file until it fails with the last hunk, you
> will not be happy.
>
You're right. GNU patch will apply one hunk and then happily churn on even
if it fails. git-apply will apply all hunks or none, so all hunks can assume
that all previous hunks were successfully applied. So what was your point
again?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: cogito remote branch
From: MichaelTiloDressel @ 2007-11-12 10:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711120954460.4362@racer.site>
Johannes Schindelin wrote:
>> A push is needed somewhere in order to prevent every remote to be
pushed
>> by default, right?
>You mean a "push" config variable? No. I think I mentioned in my
first
>reply that
> git push <remote> <branch>...
>works quite wonderfully.
I mean a push = .. line in the [remote <name>] block.
And if there is such a line than git-push without arguments will push
only
the current branch. For me that is nice, because if I forgot to give
an argument to git-push it will not push other branches.
If there is no such line all the remotes (that don't have a push line?)
get pushed.
Cheers,
Michael
^ permalink raw reply
* Re: git diff woes
From: Johannes Schindelin @ 2007-11-12 10:50 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <47382C84.50408@op5.se>
Hi,
On Mon, 12 Nov 2007, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
>
> > And sure you can trust the hunk header. Like most of the things, the
> > relate to the _original_ version, since the diff is meant to be
> > applied as a forward patch.
> >
> > So for all practical matters, the diff shows the correct thing: "in
> > this hunk, which (still) belongs to that function, change this and
> > this."
> >
> > Of course, that is only the case if you accept that the diff should be
> > applied _in total_, not piecewise. IOW if you are a fan of GNU patch
> > which happily clobbers your file until it fails with the last hunk,
> > you will not be happy.
> >
>
> You're right. GNU patch will apply one hunk and then happily churn on
> even if it fails. git-apply will apply all hunks or none, so all hunks
> can assume that all previous hunks were successfully applied. So what
> was your point again?
My point was that this diff is not to be read as if the previous hunks had
been applied. Just look at the context: it is also the original file.
It seems I am singularly unable to explain plain concepts as this: a diff
assumes that the file is yet unchanged.
So I'll stop.
Ciao,
Dscho
^ permalink raw reply
* Re: git push mirror mode V4 (replacement stack)
From: Andy Whitcroft @ 2007-11-12 11:00 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Johannes Schindelin
In-Reply-To: <20071109233041.GC301@shadowen.org>
On Fri, Nov 09, 2007 at 11:30:41PM +0000, Andy Whitcroft wrote:
> Following this mail is a complete replacement git push mirror mode
> stack (V4). It folds down all the various patches into a logical
> sequence (thanks Dscho). This stack passes the entire test suite,
> and I have been using the same code for real work here.
Ok, I have spotted one oddity with this feature. The symbolic refs are
getting converted to real refs in the mirror. Generally speaking this
is the <remote>/HEAD refs but I guess it may be possible to have others.
I have had a looked about and I am actually confused as to whether we
maintain remote symbolic refs at all? Cirtainly git-clone.sh seems to
do some hoop jumping, comparing the sha1's of all of the fetched branches
and replacing the HEAD reference with a symbolic reference should it find
a match.
I am unsure if this a huge problem or not. Its not preventing me using
it as an effective mirror, but if we assume one is making the mirror as
a backup, then there would be slightly more than an rsync to convert the
the repo back into your original, though I guess there already is as you
would want to insert your config into the remote also.
Perhaps someone with a better understanding could point me to where we
we maintain these refs, if we indeed do?
-apw
^ permalink raw reply
* Re: [StGit PATCH 0/5] A few small fixes
From: Catalin Marinas @ 2007-11-12 11:02 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, David Kågedal
In-Reply-To: <20071111193545.18868.62490.stgit@yoghurt>
On 11/11/2007, Karl Hasselström <kha@treskal.com> wrote:
> These are available from
>
> git://repo.or.cz/stgit/kha.git safe
Thanks. Merged.
> Let some commands work with detached HEAD
[...]
> stgit/commands/add.py | 2
My plan after 0.14 is to remove the implementation of add/rm etc.
commands. I'd like to keep them as just synonyms to the equivalent git
commands which stgit would invoke (this is mainly for convenience as I
usually type "stg" rather than "git").
BTW, I'll review this week the bugs already logged and clean as many
as possible (help appreciated :-)) and try to release 0.14 in 1-2
weeks.
--
Catalin
^ permalink raw reply
* [BUG] fast-import producing very deep tree deltas
From: Brian Downing @ 2007-11-12 11:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
I've happened upon a case where fast-import produces deep tree deltas.
How deep? Really deep. 6035 entries deep to be precise for this case:
depths: count 135970 total 120567366 min 0 max 6035 mean 886.72 median 3 std_dev 1653.48
27b8a20bdf39fecd917e8401d3499013e49449d0 tree 32 99609547 6035 0000000000000000000000000000000000000000
This was with git-fast-import from 'next' as of a couple days ago,
run with the default options (no --depth passed in).
Needless to say the pack that resulted was just about useless. Trying to
repack it resulted in the "counting objects" phase running at about five
objects per second.
I don't know much about the fast-import code, but I'd guess that the
delta_depth member for the tree_content struct is either getting cleared
inappropriately or is not being propagated correctly. I added a printout
of the depth just before the store_object call in store_tree and it is
never non-zero, even though the pack file clearly was generated with
plenty of deltas.
I may have time to look at this more later this week, but I just wanted
it to be known that this problem existed.
-bcd
^ permalink raw reply
* [BUG] fast-import quoting broken for renames
From: Brian Downing @ 2007-11-12 11:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071112110354.GP6212@lavos.net>
While I'm at it...
$ GIT_DIR=foo.git git init
$ GIT_DIR=foo.git git fast-import <<EOC
commit refs/import
committer foo <foo> 0 +0000
data <<EOF
test
EOF
M 644 inline "foo"
data <<EOF
foo
EOF
R foo "bar"
EOC
fatal: Garbage after dest in: R foo "bar"
$ GIT_DIR=foo.git git fast-import <<EOC
commit refs/import
committer foo <foo> 0 +0000
data <<EOF
test
EOF
M 644 inline "foo"
data <<EOF
foo
EOF
R "foo" bar
EOC
fatal: Missing space after source: R "foo" bar
-bcd
^ permalink raw reply
* Re: git diff woes
From: Andreas Ericsson @ 2007-11-12 11:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711121047590.4362@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 12 Nov 2007, Andreas Ericsson wrote:
>
>> Johannes Schindelin wrote:
>>
>>> And sure you can trust the hunk header. Like most of the things, the
>>> relate to the _original_ version, since the diff is meant to be
>>> applied as a forward patch.
>>>
>>> So for all practical matters, the diff shows the correct thing: "in
>>> this hunk, which (still) belongs to that function, change this and
>>> this."
>>>
>>> Of course, that is only the case if you accept that the diff should be
>>> applied _in total_, not piecewise. IOW if you are a fan of GNU patch
>>> which happily clobbers your file until it fails with the last hunk,
>>> you will not be happy.
>>>
>> You're right. GNU patch will apply one hunk and then happily churn on
>> even if it fails. git-apply will apply all hunks or none, so all hunks
>> can assume that all previous hunks were successfully applied. So what
>> was your point again?
>
> My point was that this diff is not to be read as if the previous hunks had
> been applied. Just look at the context: it is also the original file.
>
The context is ambiguous, as it must be present in both the new and the
old file for it to actually *be* context. Otherwise it would be part of
the +- diff text.
> It seems I am singularly unable to explain plain concepts as this: a diff
> assumes that the file is yet unchanged.
>
Sure, but the useraid with writing the apparent function declaration in
the hunk header *will* be confusing if the function declaration changes
in the same patch as other things in the function.
> So I'll stop.
>
Give me something valuable instead, such as your opinion on whether it
would be better to not print the function declaration at all if it will
be changed by applying the same patch, or if one should pick one of the
declarations from old or new and, if so, which one to pick.
I simply refuse to believe that you wouldn't immediately think the hunk
below holds an obvious bug. I thought so because of the helpful function
context git diff prints (which is a helper for human reviewers, and not
something git-apply or GNU patch needs to work), and now I want to do
something about it so others won't have to suffer the same confusion.
@@ -583,75 +346,100 @@ double jitter_request(const char *host, int *status){
if(verbose) printf("%d candiate peers available\n", num_candidates);
if(verbose && syncsource_found) printf("synchronization source found\n")
if(! syncsource_found){
- *status = STATE_UNKNOWN;
+ status = STATE_WARNING;
if(verbose) printf("warning: no synchronization source found\n")
}
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 0/5] some shell portability fixes
From: Nguyen Thai Ngoc Duy @ 2007-11-12 11:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ralf Wildenhues, git
In-Reply-To: <7v3avhbxdq.fsf@gitster.siamese.dyndns.org>
On Nov 8, 2007 3:42 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
> > On 11/7/07, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> >> On 11/7/07, Junio C Hamano <gitster@pobox.com> wrote:
> >> > [2/5] Gaah, AIX sed X-<. I am not opposed to this patch but
> >> > would want to get Yays from people with non GNU sed. Is
> >> > busybox sed good enough to grok our scripts these days?
> >> > Please ask help and collect Acks at least from folks on
> >> > Solaris, MacOS, FBSD, and OBSD.
> >>
> >> I haven't extensively used all the scripts. There seems to be no
> >> sed-related failure from git testsuite results in my git-box branch.
> >> So I would say for now it's good enough.
> >
> > Argh, should have made it clear, busybox sed is good enough.
>
> Thanks. And you can also happy grok Ralf's rewritten construct,
> right?
>
> That is, existing
>
> $ sed -e 's/foo/\n/' file
>
> will be rewritten by the patch [2/5] to
>
> $ sed -e 's/foo/\
> /' file
>
>
Yes it worked well
--
Duy
^ permalink raw reply
* [PATCH] setup_git_directory: Setup cwd properly if worktree is found
From: Nguyễn Thái Ngọc Duy @ 2007-11-12 11:24 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin
This makes sure (if possible) the current working directory is at
root worktree. "git rev-parse --show-cwd" is added to aid the tests.
Also the first test is for "Add missing inside_work_tree" commit.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin-rev-parse.c | 6 ++++++
setup.c | 7 ++++++-
t/t1501-worktree.sh | 33 +++++++++++++++++++++++++++++++++
3 files changed, 45 insertions(+), 1 deletions(-)
diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
index 8d78b69..933875c 100644
--- a/builtin-rev-parse.c
+++ b/builtin-rev-parse.c
@@ -319,6 +319,12 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
puts(prefix);
continue;
}
+ if (!strcmp(arg, "--show-cwd")) {
+ char cwd[PATH_MAX+1];
+ getcwd(cwd, sizeof(cwd));
+ printf("%s\n", cwd);
+ continue;
+ }
if (!strcmp(arg, "--show-cdup")) {
const char *pfx = prefix;
if (!is_inside_work_tree()) {
diff --git a/setup.c b/setup.c
index 6f8f769..d90f65e 100644
--- a/setup.c
+++ b/setup.c
@@ -360,7 +360,12 @@ const char *setup_git_directory(void)
if (retval && chdir(retval))
die ("Could not jump back into original cwd");
rel = get_relative_cwd(buffer, PATH_MAX, get_git_work_tree());
- return rel && *rel ? strcat(rel, "/") : NULL;
+ if (rel && *rel) {
+ if (chdir(get_git_work_tree()))
+ die ("Could not chdir to %s", get_git_work_tree());
+ return strcat(rel, "/");
+ }
+ return NULL;
}
return retval;
diff --git a/t/t1501-worktree.sh b/t/t1501-worktree.sh
index 7ee3820..a4e1f72 100755
--- a/t/t1501-worktree.sh
+++ b/t/t1501-worktree.sh
@@ -30,6 +30,18 @@ test_rev_parse() {
mkdir -p work/sub/dir || exit 1
mv .git repo.git || exit 1
+export SAVED_WORK_DIR=$(pwd)/work
+
+say "GIT_WORK_TREE without core.worktree"
+
+export GIT_DIR="$(pwd)"/repo.git
+export GIT_CONFIG="$GIT_DIR"/config
+export GIT_WORK_TREE="$(pwd)"/work
+
+test_expect_success 'cwd is set properly' '
+ (cd work/sub &&
+ test "$(git rev-parse --show-cwd)" = "$SAVED_WORK_DIR")
+'
say "core.worktree = relative path"
export GIT_DIR=repo.git
@@ -47,6 +59,11 @@ export GIT_CONFIG="$(pwd)"/$GIT_DIR/config
test_rev_parse 'subdirectory' false false true sub/dir/
cd ../../.. || exit 1
+test_expect_success 'cwd is set properly' '
+ (cd work/sub &&
+ test "$(GIT_DIR=../../repo.git git rev-parse --show-cwd)" = "$SAVED_WORK_DIR")
+'
+
say "core.worktree = absolute path"
export GIT_DIR=$(pwd)/repo.git
export GIT_CONFIG=$GIT_DIR/config
@@ -58,6 +75,11 @@ cd sub/dir || exit 1
test_rev_parse 'subdirectory' false false true sub/dir/
cd ../../.. || exit 1
+test_expect_success 'cwd is set properly' '
+ (cd work/sub &&
+ test "$(git rev-parse --show-cwd)" = "$SAVED_WORK_DIR")
+'
+
say "GIT_WORK_TREE=relative path (override core.worktree)"
export GIT_DIR=$(pwd)/repo.git
export GIT_CONFIG=$GIT_DIR/config
@@ -72,7 +94,13 @@ export GIT_WORK_TREE=../..
test_rev_parse 'subdirectory' false false true sub/dir/
cd ../../.. || exit 1
+test_expect_success 'cwd is set properly' '
+ (cd work/sub &&
+ test "$(GIT_WORK_TREE=.. git rev-parse --show-cwd)" = "$SAVED_WORK_DIR")
+'
+
mv work repo.git/work
+export SAVED_WORK_DIR=$(pwd)/repo.git/work
say "GIT_WORK_TREE=absolute path, work tree below git dir"
export GIT_DIR=$(pwd)/repo.git
@@ -89,6 +117,11 @@ cd sub/dir || exit 1
test_rev_parse 'in repo.git/sub/dir' false true true sub/dir/
cd ../../../.. || exit 1
+test_expect_success 'cwd is set properly' '
+ (cd repo.git/work/sub &&
+ test "$(git rev-parse --show-cwd)" = "$SAVED_WORK_DIR")
+'
+
test_expect_success 'repo finds its work tree' '
(cd repo.git &&
: > work/sub/dir/untracked &&
--
1.5.3.5.475.gd7a30
^ permalink raw reply related
* Re: [PATCH] setup_git_directory: Setup cwd properly if worktree is found
From: Johannes Schindelin @ 2007-11-12 11:57 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <20071112112408.GA5420@laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1605 bytes --]
Hi,
On Mon, 12 Nov 2007, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/setup.c b/setup.c
> index 6f8f769..d90f65e 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -360,7 +360,12 @@ const char *setup_git_directory(void)
> if (retval && chdir(retval))
> die ("Could not jump back into original cwd");
> rel = get_relative_cwd(buffer, PATH_MAX, get_git_work_tree());
> - return rel && *rel ? strcat(rel, "/") : NULL;
> + if (rel && *rel) {
> + if (chdir(get_git_work_tree()))
> + die ("Could not chdir to %s", get_git_work_tree());
> + return strcat(rel, "/");
> + }
> + return NULL;
Hmm. Maybe this needs a bit more clarification?
When setup_git_directory() returns, the cwd is supposed to be the current
working tree's root. Your patch fixes that nicely when the worktree
setting was overridden by the config (which is read in
check_repository_format()).
But what about setup_git_directory_gently()? If the working tree is
overridden by the config, this function is still bogus, right?
As far as I see, setup_git_directory_gently() only works correctly when
core.worktree is _not_ set, unless GIT_WORK_TREE is set (which is supposed
to override the config setting). Note: I treat GIT_WORK_TREE the same as
--work-tree, since at that time they are identical.
Maybe the config stuff has to move into _gently()?
Ciao,
Dscho
P.S.: Thanks for picking up the ball. At some stage I got so fed up with
the work-tree stuff that I had to take a long break from it. It is a
messy concept, and the implementation is messy, partly because of it, and
partly because I wrote it.
^ permalink raw reply
* git-log --pretty=format:%s doesn't honor option i18n.logoutputencoding?
From: Ping Yin @ 2007-11-12 12:04 UTC (permalink / raw)
To: Git Mailing List
$ gtcf --get-regexp i18n.*
i18n.logoutputencoding GBK
$ locale | grep LC_CTYPE
LC_CTYPE=zh_CN.GBK
$ git --version
git version 1.5.3.4
And my terminal encoding is GBK
$ git log --pretty=oneline
msgs with chinese character displayed correctly
However
$ git log --pretty=format:%s
the chinese character doesn't display correctly
--
Ping Yin
^ permalink raw reply
* [PATCH] git-quiltimport.sh fix --patches handling
From: Andy Whitcroft @ 2007-11-12 12:07 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Pierre Habouzit
When converting git-quiltimport.sh to the new git-rev-part --parseopt
system, the handling of --patches was broken. We inadvertantly always
attempt to use '--patches' as the value.
This was introduced in the following commit:
commit e01fbf1a8f185bf6722e828286862a4122269ef7
Author: Pierre Habouzit <madcoder@debian.org>
Date: Sun Nov 4 11:31:01 2007 +0100
Migrate git-quiltimport.sh to use git-rev-parse --parseopt
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
git-quiltimport.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index 56c9569..6b0c4d2 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -23,8 +23,8 @@ do
dry_run=1
;;
--patches)
- QUILT_PATCHES="$1"
shift
+ QUILT_PATCHES="$1"
;;
--)
shift
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2007-11-12 12:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsso3poo.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 11 Nov 2007, Junio C Hamano wrote:
> * js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit
> + rebase: operate on a detached HEAD
Note: this might have a subtle bug when the last patch in the series
failed. If I was not too tired this morning (which might well have been
the case), rebase could not switch back to the branch correctly with this.
> ----------------------------------------------------------------
> [Approaching 'next']
>
> * kh/commit (Sun Nov 11 17:36:52 2007 +0000) 12 commits
> - builtin-commit: Add newline when showing which commit was created
> - builtin-commit: resurrect behavior for multiple -m options
> - builtin-commit --s: add a newline if the last line was not a S-o-b
> - builtin-commit: fix --signoff
> - git status: show relative paths when run in a subdirectory
> - builtin-commit: fix author date with --amend --author=<author>
> - builtin-commit: Refresh cache after adding files.
> - builtin-commit: fix reflog message generation
> - launch_editor(): read the file, even when EDITOR=:
> - Port git commit to C.
> - Export launch_editor() and make it accept ':' as a no-op editor.
> - Add testcase for ammending and fixing author in git commit.
>
> Dscho fixed a handful obvious glitches. I am hoping that this
> series should be in "testable" shape now. Will merge to "next"
> after giving it a final round of eyeballing.
FWIW I am running 'next'+builtin-commit+a couple of other patches I am
brewing. These issues are on my TODO list (most pressing first):
- commit --amend <file> erroneously commits other files that were
git-add'ed
- under certain circumstances (my maildir update script) does not
show newly created and deleted files anymore.
- do not rebuild the whole index when committing just one file,
instead use the old index, and then adjust it to the HEAD.
- remove "launching editor, logfile (null)" message
- forward port 6d4bbebd35e3a6e8091d7188f1c4d49af7f054e3 to builtin-commit
- when a message is given and no editor should be launched, avoid
lengthy runstatus calculation
Clarification for the "do not rebuild" thingie: ATM it seems that there
is a lengthy calculation going on, even if the index is clean and you only
passed one single filename on the command line.
> * sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
> - refactor fetch's ref matching to use refname_match()
> - push: use same rules as git-rev-parse to resolve refspecs
> - add refname_match()
> - push: support pushing HEAD to real branch name
>
> This changes the semantics slightly but I think it is a move in
> the right direction.
We could add a "--matching" option and output a warning when it is not
passed. I would like this pretty soon, and would not be sad if it went
into 'next' before this topic.
> * cr/tag-options (Fri Nov 9 14:42:56 2007 +0100) 1 commit
> - Make builtin-tag.c use parse_options.
>
> This changes the handling of multiple -m option without much
> good reason. It should be a simple fix, once we know what we
> want. I think the existing behaviour of refusing multiple -m
> is probably the most sane at this point.
I tend to agree.
> * sb/clean (Tue Nov 6 23:18:51 2007 -0600) 1 commit
> - Make git-clean a builtin
Time is fleeting, so I could not yet look into the ambiguity problem where
help was requested.
> ----------------------------------------------------------------
> [Others]
>
> * jc/branch-contains (Wed Nov 7 14:58:09 2007 -0800) 1 commit
> - git-branch --with=commit
>
> I did this just for my own fun.
As I already said, I'd like this, but renamed to --containing=. In fact,
I just scrapped a script of mine to do the same, in excited expectation of
this feature.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive
From: Johannes Schindelin @ 2007-11-12 12:23 UTC (permalink / raw)
To: Mike Hommey; +Cc: Junio C Hamano, Theodore Tso, Git Mailing List
In-Reply-To: <20071112102412.GA24803@glandium.org>
Hi,
On Mon, 12 Nov 2007, Mike Hommey wrote:
> On Sun, Nov 11, 2007 at 11:26:10PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> > > My mental model for git newbies is that they would probably be pulling
> > > from upstream repositories (so I was tempted to remove git-init from
> > > the common commands list), but they would rarely be cherry-picking or
> > > reverting other people's changes.
> >
> > I'd agree with that, but reverting and cherry-picking would also
> > be done on the commits the user builds on top of other people's
> > changes.
>
> On the other hand, cherry-picking and reverting are just the same thing,
> except one applies a reversed patch. Wouldn't it make sense to merge
> these two in one command ?
Technically, they are. That's why both of them live in builtin-revert.c.
But conceptually, they are not. At least _I_ found it hard at first, to
accept that reverting a patch really was a reverse cherry-picking.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-clean: Fix error message if clean.requireForce is not set.
From: Pierre Habouzit @ 2007-11-12 12:24 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List, Shawn Bohrer
In-Reply-To: <4738119F.2030901@viscovery.net>
[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]
On Mon, Nov 12, 2007 at 08:41:03AM +0000, Johannes Sixt wrote:
> Pierre Habouzit schrieb:
> >On Mon, Nov 12, 2007 at 08:27:35AM +0000, Johannes Sixt wrote:
> >>It was distracting to see this error message:
> >>
> >> clean.requireForce set and -n or -f not given; refusing to clean
> >>
> >>even though clean.requireForce was not set at all. This patch
> >>distinguishes
> >>the cases and gives a different message depending on whether the
> >>configuration variable is not set or set to true.
> > Note that your patch won't apply to next as is :)
>
> You mean because of the builtinification of git-clean? I was hoping that
> Shawn (Bohrer) is listening and will update his patch. ;) It has the same
> problem.
No, afaict the builtin git-clean isn't in next yet. Though the
git-rev-parse --parseopt-ification is :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Pierre Habouzit @ 2007-11-12 12:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711121203150.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 938 bytes --]
On Mon, Nov 12, 2007 at 12:21:34PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 11 Nov 2007, Junio C Hamano wrote:
>
> > * js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit
> > + rebase: operate on a detached HEAD
>
> Note: this might have a subtle bug when the last patch in the series
> failed. If I was not too tired this morning (which might well have been
> the case), rebase could not switch back to the branch correctly with this.
OOOH so this was what happened to me today then. I did a rebase, there
was a commit to skip, the last one, and I ended up on a detached head.
As I didn't had my coffee yet, I assumed this was my fault and did
something stupid. So after all it seems it wasn't the case then :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] setup_git_directory: Setup cwd properly if worktree is found
From: Johannes Schindelin @ 2007-11-12 12:31 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <fcaeb9bf0711120413w180c07e1qbf1b186753593d7@mail.gmail.com>
Hi,
On Mon, 12 Nov 2007, Nguyen Thai Ngoc Duy wrote:
> On Nov 12, 2007 6:57 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > But what about setup_git_directory_gently()? If the working tree is
> > overridden by the config, this function is still bogus, right?
>
> Hmm.. thinking a little bit more. I guess you're right because
> GIT_WORK_TREE takes precedence over core.worktree. Maybe some more bits
> for check_repository_format_version(). Tough decision because, from the
> value of inside_work_tree, we don't know if we can safely skip
> overriding inside_work_tree.
I was thinking about adding check_repository_format_version() and a check
for inside_work_tree < 0 with obvious handling in two places, probably as
a function: first, when we have a gitdirenv but no work_tree_env, and
second, at the end of _gently() when we found a git dir but only if
work_tree_env was not set.
> > As far as I see, setup_git_directory_gently() only works correctly
> > when core.worktree is _not_ set, unless GIT_WORK_TREE is set (which is
> > supposed to override the config setting). Note: I treat GIT_WORK_TREE
> > the same as --work-tree, since at that time they are identical.
> >
> > Maybe the config stuff has to move into _gently()?
>
> Well, it could be a bit more complicated because you need to know
> GIT_DIR first before reading config. I'd rather not move as _gently()
> is complicated already.
AFAICT it is not a question of complexity, but of correctness. Wouldn't
you agree that the prefix _gently() returns is wrong if we don't fix it?
Besides, it might be needed anyway if we are serious about the version
check. This check, however, would have to be done _whenever_ we found a
git directory, not only when work_tree_env is NULL.
But we could break down _gently() quite nicely. ATM it both handles the
cases when gitdirenv was set, and when it was unset. Even if those are
really two pretty different situations.
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2007-11-12 12:33 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git
In-Reply-To: <20071112122652.GC20482@artemis.corp>
Hi,
On Mon, 12 Nov 2007, Pierre Habouzit wrote:
> On Mon, Nov 12, 2007 at 12:21:34PM +0000, Johannes Schindelin wrote:
>
> > On Sun, 11 Nov 2007, Junio C Hamano wrote:
> >
> > > * js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit
> > > + rebase: operate on a detached HEAD
> >
> > Note: this might have a subtle bug when the last patch in the series
> > failed. If I was not too tired this morning (which might well have
> > been the case), rebase could not switch back to the branch correctly
> > with this.
>
> OOOH so this was what happened to me today then. I did a rebase, there
> was a commit to skip, the last one, and I ended up on a detached head.
> As I didn't had my coffee yet, I assumed this was my fault and did
> something stupid. So after all it seems it wasn't the case then :)
Thanks for acknowleding, and sorry for the bug.
Will work on a fix,
Dscho
^ permalink raw reply
* Re: [PATCH] setup_git_directory: Setup cwd properly if worktree is found
From: Johannes Sixt @ 2007-11-12 12:53 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <20071112112408.GA5420@laptop>
Nguyễn Thái Ngọc Duy schrieb:
> +export SAVED_WORK_DIR=$(pwd)/work
> +export GIT_DIR="$(pwd)"/repo.git
> +export GIT_CONFIG="$GIT_DIR"/config
> +export GIT_WORK_TREE="$(pwd)"/work
These are not very portable; use:
GIT_DIR="$(pwd)"/repo.git
GIT_CONFIG="$GIT_DIR"/config
GIT_WORK_TREE="$(pwd)"/work
export GIT_DIR GIT_CONFIG GIT_WORK_TREE
The first one also needs $(pwd) quoted.
-- Hannes
^ 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