* Re: [PATCH 5/9 v2] Allow the built-in exec path to be relative to the command invocation path
From: Junio C Hamano @ 2008-07-24 4:21 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200807232112.18352.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> It also fixes 'make install' of git-gui as well (sigh!) by not exporting
> gitexecdir - assuming that Shawn applies the git-gui patch.
Yeah, this seems to break the install quite badly without git-gui patch.
If your PATH does not include the bindir you are installing the freshly
built git, then the Makefile in git-gui runs:
ifndef gitexecdir
gitexecdir := $(shell git --exec-path)
endif
and miserably fails. We can assume that somebody who builds and installs
git-gui as a standalone project already *has* an installed, working git on
$PATH, so the above ifndef is Ok, but when git-gui is built as part of
git.git tree, we really should avoid triggering that codepath.
^ permalink raw reply
* [EGIT PATCH] Support linked resources
From: Richie Vos @ 2008-07-24 3:34 UTC (permalink / raw)
To: git
I have a project that outputs to a linked directory (for example the
project is in /projects/foo and the project outputs to /projects/bar).
This was causing egit to throw a bunch of "file is not in working
path" errors whenever I rebuilt the project or otherwise interacted
with that linked directory. I tracked it down to GitIndex's add/remove
being called on these files even though these files are not part of
the actual index.
It seems like egit shouldn't be trying to interact with the index on
these files, and after looking at it, I decided the best solution
would be to realize in the RepositoryMapping that these files do not
point to a repository.
I wasn't sure what the best solution for deciding if a file was in the
same location as the project it is referenced in, but I somewhat
modeled it off of the way GitIndex's makeKey does its validation.
Patch:
Fixed 'Path is not in working directory' error for linked resources
Signed-off-by: Reg Vos <jerry.vos@gmail.com>
---
.../egit/core/project/RepositoryMapping.java | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/org.spearce.egit.core/src/org/spearce/egit/core/project/RepositoryMapping.java
b/org.spearce.egit.core/src/org/spearce/egit/core/project/RepositoryMapping.java
index 6a0b56f..5863a49 100644
--- a/org.spearce.egit.core/src/org/spearce/egit/core/project/RepositoryMapping.java
+++ b/org.spearce.egit.core/src/org/spearce/egit/core/project/RepositoryMapping.java
@@ -236,6 +236,8 @@ public class RepositoryMapping {
IProject project = resource.getProject();
if (project == null)
return null;
+ if (!project.getLocation().isPrefixOf(resource.getLocation()))
+ return null;
RepositoryProvider provider = RepositoryProvider.getProvider(project);
if (!(provider instanceof GitProvider))
return null;
--
1.5.4.2
^ permalink raw reply related
* [PATCH] Preserve cwd in setup_git_directory()
From: Nguyễn Thái Ngọc Duy @ 2008-07-24 3:14 UTC (permalink / raw)
To: git, Johannes Schindelin, Geoff Russell
When GIT_DIR is not set, cwd is used to determine where .git is.
If core.worktree is set, setup_git_directory() needs to jump back
to the original cwd in order to calculate worktree, this leads to
incorrect .git location later in setup_work_tree().
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
setup.c | 4 ++++
t/t1501-worktree.sh | 13 ++++++++++++-
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/setup.c b/setup.c
index 6cf9094..ef58761 100644
--- a/setup.c
+++ b/setup.c
@@ -577,10 +577,14 @@ const char *setup_git_directory(void)
/* If the work tree is not the default one, recompute prefix */
if (inside_work_tree < 0) {
static char buffer[PATH_MAX + 1];
+ static char cwd[PATH_MAX + 1];
char *rel;
+ getcwd(cwd, PATH_MAX);
if (retval && chdir(retval))
die ("Could not jump back into original cwd");
rel = get_relative_cwd(buffer, PATH_MAX, get_git_work_tree());
+ if (retval && chdir(cwd))
+ die ("Could not jump back into original cwd");
return rel && *rel ? strcat(rel, "/") : NULL;
}
diff --git a/t/t1501-worktree.sh b/t/t1501-worktree.sh
index 2ee88d8..64f8dea 100755
--- a/t/t1501-worktree.sh
+++ b/t/t1501-worktree.sh
@@ -29,7 +29,18 @@ test_rev_parse() {
}
mkdir -p work/sub/dir || exit 1
-mv .git repo.git || exit 1
+
+git config core.worktree "$(pwd)"/work
+mv .git work || exit 1
+test_expect_success '--git-dir with relative .git' '
+ (
+ MYPWD="$(pwd)"
+ cd work/sub/dir &&
+ test "$MYPWD"/work/.git = "$(git rev-parse --git-dir)"
+ )
+'
+
+mv work/.git repo.git || exit 1
say "core.worktree = relative path"
GIT_DIR=repo.git
--
1.5.5.GIT
^ permalink raw reply related
* Re: git-svn does not seems to work with crlf convertion enabled.
From: Alexander Litvinov @ 2008-07-24 3:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807231356540.8986@racer>
> Note that you will have to do your digging using msysGit (i.e. the
> developer's pack, not the installer for plain Git), since git-svn will be
> removed from the next official "Windows Git" release, due to lack of
> fixers.
You will not believe me. I use git under Linux, develop under windows on
network drive :-)
^ permalink raw reply
* Re: Moving .git around
From: Geoff Russell @ 2008-07-24 2:36 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0807231912t6f20d508va1381f324a8981aa@mail.gmail.com>
On Thu, Jul 24, 2008 at 11:42 AM, Nguyen Thai Ngoc Duy
<pclouds@gmail.com> wrote:
> On 7/24/08, Geoff Russell <geoffrey.russell@gmail.com> wrote:
>> For reasons which would take a while to explain, I'm building a repository
>> in a directory using "--git-dir=xxxx/.git --work-tree=." and
>> then doing an "mv xxxx/.git ./.git" and then trying to work with
>> that repository --- but can't
>>
>> Below is a sample script. The last line (git add) fails with
>>
>> fatal: unable to create
>> '/usr/local/AusTop/AuPrograms/AuServer/testgit/aaa/bbb/.git/index.lock':
>> No such file or directory
>>
>> git doesn't seem to realise that there is a .git back up the tree.
>
> It's because when you did git --work-tree=. init, worktree is stored
> in .git/config. The code that chdir() in setup_git_directory()
> probably forgot to chdir() back to toplevel worktree. Workaround could
> be just remove core.worktree in .git/config.
Many thanks, the work-around works. I'm not sure if this is a bug or
a feature, but I'm happy either way.
Cheers,
Geoff Russell
>
>> I'm using 1.5.5.1
>>
>> Cheers,
>> Geoff Russell
>>
>> ------------------------ sample script
>> #!/bin/sh
>> if [ -d "testgit" ] ; then
>> echo "remove testgit"
>> /bin/rm -rf testgit
>> fi
>> mkdir testgit && echo yyyy >testgit/sample.sh && cd testgit
>> mkdir aaa && mkdir aaa/bbb
>> echo xxxx > aaa/bbb/sample2.sh
>> mkdir xxx
>> git --git-dir=xxx/.git --work-tree=. init
>> git --git-dir=xxx/.git --work-tree=. add *.sh
>> git --git-dir=xxx/.git --work-tree=. commit -m demo
>> mv xxx/.git .
>> cd aaa/bbb
>> git add sample2.sh
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
> --
> Duy
>
--
6 Fifth Ave,
St Morris, S.A. 5068
Australia
Ph: 041 8805 184 / 08 8332 5069
^ permalink raw reply
* Re: Moving .git around
From: Nguyen Thai Ngoc Duy @ 2008-07-24 2:12 UTC (permalink / raw)
To: geoffrey.russell; +Cc: git
In-Reply-To: <93c3eada0807231832o6b7689c4j2913253d7ced62ba@mail.gmail.com>
On 7/24/08, Geoff Russell <geoffrey.russell@gmail.com> wrote:
> For reasons which would take a while to explain, I'm building a repository
> in a directory using "--git-dir=xxxx/.git --work-tree=." and
> then doing an "mv xxxx/.git ./.git" and then trying to work with
> that repository --- but can't
>
> Below is a sample script. The last line (git add) fails with
>
> fatal: unable to create
> '/usr/local/AusTop/AuPrograms/AuServer/testgit/aaa/bbb/.git/index.lock':
> No such file or directory
>
> git doesn't seem to realise that there is a .git back up the tree.
It's because when you did git --work-tree=. init, worktree is stored
in .git/config. The code that chdir() in setup_git_directory()
probably forgot to chdir() back to toplevel worktree. Workaround could
be just remove core.worktree in .git/config.
> I'm using 1.5.5.1
>
> Cheers,
> Geoff Russell
>
> ------------------------ sample script
> #!/bin/sh
> if [ -d "testgit" ] ; then
> echo "remove testgit"
> /bin/rm -rf testgit
> fi
> mkdir testgit && echo yyyy >testgit/sample.sh && cd testgit
> mkdir aaa && mkdir aaa/bbb
> echo xxxx > aaa/bbb/sample2.sh
> mkdir xxx
> git --git-dir=xxx/.git --work-tree=. init
> git --git-dir=xxx/.git --work-tree=. add *.sh
> git --git-dir=xxx/.git --work-tree=. commit -m demo
> mv xxx/.git .
> cd aaa/bbb
> git add sample2.sh
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Duy
^ permalink raw reply
* Re: [PATCH 2/2] git-checkout: improve error messages, detect ambiguities.
From: Junio C Hamano @ 2008-07-24 2:07 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <7v7ibc9p93.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Pierre Habouzit <madcoder@debian.org> writes:
>
>> The patch is twofold: it moves the option consistency checks just under
>> the parse_options call so that it doesn't get in the way of the tree
>> reference vs. pathspecs desambiguation.
>
> I think this goes a bit too far.
>
> Even if you have a file called 'master' tracked in your project, when you
> say:
>
> $ git checkout master
>
> that's almost always branch switching. Forcing "git checkout master --"
> disambiguation for such a common case is simply a wrong thing to do from
> the usability point of view.
So something like this on top of your patch.
builtin-checkout.c | 19 +++++++++++++++----
t/t2010-checkout-ambiguous.sh | 15 +++++++++++++--
2 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index d99c1c0..411cc51 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -460,7 +460,10 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
*
* case 3: git checkout <something> [<paths>]
*
- * <something> shall not be ambiguous.
+ * With no paths, if <something> is a commit, that is to
+ * switch to the branch or detach HEAD at it.
+ *
+ * Otherwise <something> shall not be ambiguous.
* - If it's *only* a reference, treat it like case (1).
* - If it's only a path, treat it like case (2).
* - else: fail.
@@ -474,7 +477,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
}
arg = argv[0];
- has_dash_dash = argc > 1 && !strcmp(argv[1], "--");
+ has_dash_dash = (argc > 1) && !strcmp(argv[1], "--");
if (get_sha1(arg, rev)) {
if (has_dash_dash) /* case (1) */
@@ -500,8 +503,16 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
if (!source_tree) /* case (1): want a tree */
die("reference is not a tree: %s", arg);
- if (!has_dash_dash) /* case (3 -> 1) */
- verify_non_filename(NULL, arg);
+ if (!has_dash_dash) {/* case (3 -> 1) */
+ /*
+ * Do not complain the most common case
+ * git checkout branch
+ * even if there happen to be a file called 'branch';
+ * it would be extremely annoying.
+ */
+ if (argc)
+ verify_non_filename(NULL, arg);
+ }
else {
argv++;
argc--;
diff --git a/t/t2010-checkout-ambiguous.sh b/t/t2010-checkout-ambiguous.sh
index 50d1f43..7cc0a35 100755
--- a/t/t2010-checkout-ambiguous.sh
+++ b/t/t2010-checkout-ambiguous.sh
@@ -32,8 +32,19 @@ test_expect_success 'non ambiguous call' '
git checkout all
'
-test_expect_success 'ambiguous call' '
- test_must_fail git checkout world
+test_expect_success 'allow the most common case' '
+ git checkout world &&
+ test "refs/heads/world" = "$(git symbolic-ref HEAD)"
+'
+
+test_expect_success 'check ambiguity' '
+ test_must_fail git checkout world all
+'
+
+test_expect_success 'disambiguate checking out from a tree-ish' '
+ echo bye > world &&
+ git checkout world -- world &&
+ git diff --exit-code --quiet
'
test_done
^ permalink raw reply related
* Re: [PATCH] editor.c: Libify launch_editor()
From: Stephan Beyer @ 2008-07-24 1:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <20080723230923.GA12754@leksak.fem-net>
Stephan Beyer wrote:
> Well, I've seen that *a lot* of lib code (15 functions, see below) is in
> the builtins.
>
> Cleaning that up seems to be good to have a real separation between
> libgit and builtins, but I guess such a change would not find its way
> into 1.6.0, would it?
>
> Regards,
> Stephan
>
> PS: I've spontaneously decided to make a list:
>
> defined-in func-name - used in builtin-\1.c
Of course my list was not complete.
(My regex was too simple.)
I add some:
> builtin-add.c:
> add_files_to_cache() - add, checkout, commit
> interactive_add() - add, commit
>
> builtin-archive.c:
> parse_pathspec_arg() - archive, upload-archive
parse_treeish_arg() - archive, upload-archive
parse_archive_args() - archive, upload-archive
builtin-commit-tree.c:
commit_tree() - commit-tree, merge
builtin-fetch-pack.c:
fetch_pack() - also used in transport.c
> builtin-init-db.c:
> init_db() - init-db, clone
>
> builtin-ls-files.c:
> overlay_tree_on_cache() - ls-files, commit
> report_path_error() - ls-files, checkout, commit
pathspec_match() - ls-files, checkout, commit
> builtin-mailsplit.c:
> read_line_with_nul() - mailsplit, mailinfo
>
> builtin-merge-recursive.c:
> write_tree_from_memory() - merge-recursive, checkout
merge_trees() - merge-recursive, checkout
merge_recursive() - merge-recursive (used nowhere else)
> builtin-prune-packed.c:
> prune_packed_objects() - prune-packed, prune
builtin-send-pack.c:
send_pack() - also used in transport.c
> builtin-shortlog.c:
> shortlog_add_commit() - shortlog, log
> shortlog_init() - shortlog, log
> shortlog_output() - shortlog, log
> shortlog_init() - shortlog, log
>
> builtin-stripspace.c:
> stripspace() - stripspace, commit, tag
>
> And launch_editor() that is handled by the patch in this thread.
So keep everything or is it worth splitting that somehow up?
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* [PATCH] t6030 (bisect): work around Mac OS X "ls"
From: Jonathan Nieder @ 2008-07-24 1:37 UTC (permalink / raw)
To: git; +Cc: Christian Couder
t6030-bisect-porcelain.sh relies on "ls" exiting with nonzero
status when asked to list nonexistent files. Unfortunately,
/bin/ls on Mac OS X 10.3 exits with exit code 0. So use "echo
<shell glob pattern>" and grep instead.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
With this change, all the non-git-svn tests pass on my machine.
I think the fix is portable but I do not have the experience to
be sure. So I would be happier if someone looks it over.
t/t6030-bisect-porcelain.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 0626544..d19fc1c 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -76,7 +76,7 @@ test_expect_success 'bisect fails if given any junk instead of revs' '
test_must_fail git bisect start foo $HASH1 -- &&
test_must_fail git bisect start $HASH4 $HASH1 bar -- &&
test -z "$(git for-each-ref "refs/bisect/*")" &&
- test_must_fail ls .git/BISECT_* &&
+ echo .git/BISECT_* | test_must_fail grep BISECT_[^*] &&
git bisect start &&
test_must_fail git bisect good foo $HASH1 &&
test_must_fail git bisect good $HASH1 bar &&
--
1.5.6.3.549.g8ca11
^ permalink raw reply related
* Moving .git around
From: Geoff Russell @ 2008-07-24 1:32 UTC (permalink / raw)
To: git
For reasons which would take a while to explain, I'm building a repository
in a directory using "--git-dir=xxxx/.git --work-tree=." and
then doing an "mv xxxx/.git ./.git" and then trying to work with
that repository --- but can't
Below is a sample script. The last line (git add) fails with
fatal: unable to create
'/usr/local/AusTop/AuPrograms/AuServer/testgit/aaa/bbb/.git/index.lock':
No such file or directory
git doesn't seem to realise that there is a .git back up the tree.
I'm using 1.5.5.1
Cheers,
Geoff Russell
------------------------ sample script
#!/bin/sh
if [ -d "testgit" ] ; then
echo "remove testgit"
/bin/rm -rf testgit
fi
mkdir testgit && echo yyyy >testgit/sample.sh && cd testgit
mkdir aaa && mkdir aaa/bbb
echo xxxx > aaa/bbb/sample2.sh
mkdir xxx
git --git-dir=xxx/.git --work-tree=. init
git --git-dir=xxx/.git --work-tree=. add *.sh
git --git-dir=xxx/.git --work-tree=. commit -m demo
mv xxx/.git .
cd aaa/bbb
git add sample2.sh
^ permalink raw reply
* Re: [PATCH] (unnamed)
From: Junio C Hamano @ 2008-07-24 0:58 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <7vej5k8719.fsf@gitster.siamese.dyndns.org>
Ooops.
I sent out before I can decide what the title should be. Sorry, will
think of something.
^ permalink raw reply
* Re: [PATCH] t/: Replace diff [-u|-U0] with test_cmp to allow compilation with old diff
From: Brandon Casey @ 2008-07-24 0:55 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20080724001916.GP32057@genesis.frugalware.org>
Miklos Vajna wrote:
> On Tue, Jul 22, 2008 at 04:17:43PM -0500, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>> t/t0002-gitfile.sh | 2 +-
>> t/t1002-read-tree-m-u-2way.sh | 12 ++++++------
>> t/t2201-add-update-typechange.sh | 10 +++++-----
>> 3 files changed, 12 insertions(+), 12 deletions(-)
>
> Hmm, after applying this patch, I have:
>
> ~/git/t$ git grep 'diff -U'
> t1002-read-tree-m-u-2way.sh: diff -U0 M.out 4.out >4diff.out
> t1002-read-tree-m-u-2way.sh: diff -U0 M.out 5.out >5diff.out
> t1002-read-tree-m-u-2way.sh: diff -U0 M.out 14.out >14diff.out
> t1002-read-tree-m-u-2way.sh: diff -U0 M.out 15.out >15diff.out
>
> Any reason you left this out? ;-)
I have the patch below in my repo so I can run this test. (copy/pasted
and white-space corrupted since I haven't figured out how to reply to a
message and import a patch correctly using thunderbird).
As you can see I just replaced the 'diff -U0' with 'git diff -U0' and then
stripped off the git bits from the diff in the compare_change() function.
I think there is probably a better way to fix this, so I left it out.
Thinking about it now, it would have made sense to hold off on the part of
the patch I submitted which applies to t1002-read-tree-m-u-2way.sh until I
had a solution for the rest of these 'diff -U0's.
-brandon
diff --git a/t/t1002-read-tree-m-u-2way.sh b/t/t1002-read-tree-m-u-2way.sh
index aa9dd58..5e40cec 100755
--- a/t/t1002-read-tree-m-u-2way.sh
+++ b/t/t1002-read-tree-m-u-2way.sh
@@ -14,6 +14,8 @@ _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
compare_change () {
sed >current \
+ -e '1{/^diff --git /d;}' \
+ -e '2{/^index /d;}' \
-e '/^--- /d; /^+++ /d; /^@@ /d;' \
-e 's/^\(.[0-7][0-7][0-7][0-7][0-7][0-7]\) '"$_x40"' /\1 X /' "$1"
test_cmp expected current
@@ -75,7 +77,7 @@ test_expect_success \
git update-index --add yomin &&
git read-tree -m -u $treeH $treeM &&
git ls-files --stage >4.out || return 1
- diff -U0 M.out 4.out >4diff.out
+ git diff -U0 --no-index M.out 4.out >4diff.out
compare_change 4diff.out expected &&
check_cache_at yomin clean &&
sum bozbar frotz nitfol >actual4.sum &&
@@ -94,7 +96,7 @@ test_expect_success \
echo yomin yomin >yomin &&
git read-tree -m -u $treeH $treeM &&
git ls-files --stage >5.out || return 1
- diff -U0 M.out 5.out >5diff.out
+ git diff -U0 --no-index M.out 5.out >5diff.out
compare_change 5diff.out expected &&
check_cache_at yomin dirty &&
sum bozbar frotz nitfol >actual5.sum &&
@@ -206,7 +208,7 @@ test_expect_success \
git update-index --add nitfol &&
git read-tree -m -u $treeH $treeM &&
git ls-files --stage >14.out || return 1
- diff -U0 M.out 14.out >14diff.out
+ git diff -U0 --no-index M.out 14.out >14diff.out
compare_change 14diff.out expected &&
sum bozbar frotz >actual14.sum &&
grep -v nitfol M.sum > expected14.sum &&
@@ -227,7 +229,7 @@ test_expect_success \
echo nitfol nitfol nitfol >nitfol &&
git read-tree -m -u $treeH $treeM &&
git ls-files --stage >15.out || return 1
- diff -U0 M.out 15.out >15diff.out
+ git diff -U0 --no-index M.out 15.out >15diff.out
compare_change 15diff.out expected &&
check_cache_at nitfol dirty &&
sum bozbar frotz >actual15.sum &&
--
1.5.6.2
^ permalink raw reply related
* Re: [PATCH] bring description of git diff --cc up to date
From: Jonathan Nieder @ 2008-07-24 0:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3am09oqe.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Let's just do this. I think it is clear enough.
Works for me. Thanks, and sorry I dragged this on so.
^ permalink raw reply
* [PATCH]
From: Junio C Hamano @ 2008-07-24 0:22 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
f2eba66 (Enable HEAD@{...} and make it independent from the current
branch, 2007-02-03) introduced dwim_log() to handle <refname>@{...}
syntax, and as part of its processing, it checks if the ref exists by
calling refsolve_ref(). It should call it as a reader to make sure the
call returns NULL for a nonexistent ref (not as a potential writer in
which case it does not return NULL).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I found this purely by accident. "echo >.git/logs/refs/heads/HEAD"
would make your "git rev-parse HEAD@{1}" complain about a refname
'HEAD' being ambiguous without this patch.
sha1_name.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index b0b2167..4fb77f8 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -273,7 +273,7 @@ int dwim_log(const char *str, int len, unsigned char *sha1, char **log)
const char *ref, *it;
strcpy(path, mkpath(*p, len, str));
- ref = resolve_ref(path, hash, 0, NULL);
+ ref = resolve_ref(path, hash, 1, NULL);
if (!ref)
continue;
if (!stat(git_path("logs/%s", path), &st) &&
^ permalink raw reply related
* Re: [PATCH] t/: Replace diff [-u|-U0] with test_cmp to allow compilation with old diff
From: Miklos Vajna @ 2008-07-24 0:19 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <E23rxnPh0xeYPsUuTseZ3Y6bteX3uHIcbLzTlyVPsX_N5fqcvRp1vA@cipher.nrlssc.navy.mil>
[-- Attachment #1: Type: text/plain, Size: 666 bytes --]
On Tue, Jul 22, 2008 at 04:17:43PM -0500, Brandon Casey <casey@nrlssc.navy.mil> wrote:
> t/t0002-gitfile.sh | 2 +-
> t/t1002-read-tree-m-u-2way.sh | 12 ++++++------
> t/t2201-add-update-typechange.sh | 10 +++++-----
> 3 files changed, 12 insertions(+), 12 deletions(-)
Hmm, after applying this patch, I have:
~/git/t$ git grep 'diff -U'
t1002-read-tree-m-u-2way.sh: diff -U0 M.out 4.out >4diff.out
t1002-read-tree-m-u-2way.sh: diff -U0 M.out 5.out >5diff.out
t1002-read-tree-m-u-2way.sh: diff -U0 M.out 14.out >14diff.out
t1002-read-tree-m-u-2way.sh: diff -U0 M.out 15.out >15diff.out
Any reason you left this out? ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: gitk highlighting descendents/ancestors
From: Matt Seitz (matseitz) @ 2008-07-24 0:12 UTC (permalink / raw)
To: git
"Paul Mackerras" <paulus@samba.org> wrote in message news:<17530.60026.636981.60532@cargo.ozlabs.ibm.com>...
> I have implemented a feature in gitk (on the "new" branch) where it
> can highlight the commits that are, or are not, descendents or
> ancestors of the selected commit. For now it is invoked via a
> drop-down menu.
Is this feature still available? I don't see the menu running 1.5.6 on Cygwin. A coworker running 1.5.0.7 on Linux sees it.
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-24 0:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vwsjcft5g.fsf@gitster.siamese.dyndns.org>
On Wed, 23 July 2008, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> On Wed, 23 Jul 2008, Johannes Schindelin wrote:
>>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
>>>
>>> Some people prefer to stay anonymous, so I think email is out.
>>>
>>>> 04. Which programming languages you are proficient with?
>>>> (The choices include programming languages used by git)
>>>> (zero or more: multiple choice)
>>>> - C, shell, Perl, Python, Tcl/Tk
>>>> + (should we include other languages, like C++, Java, PHP,
>>>> Ruby,...?)
>>>
>>> Yes, I think this should be a long list.
>>
>> I'd rather not have a "laundry list" of languages. I have put C++
>> because QGit uses it, Java because of egit/jgit, PHP for web
>> interfaces, Ruby because of GitHub and because of Ruby comminity
>> choosing Git. I should perhaps add Emacs Lisp, HTML+CSS and
>> JavaScript here. What other languages should be considered?
>
> I refrained saying this in my initial response, but my initial reaction
> was "Why are you even asking this?".
>
> Yes, "getting to know you" demographics are customary done in surveys, and
> you kept it to the minimum which is also good, but I do not think this
> particular question is very interesting. For one thing, the question
> assumes the participant is a programmer, and we are giving an impression
> that we are interested in better programmers. Do we *still* require users
> to be a programmer to use git? I do not think so. Having to answer "none
> of these" to this question would make you feel unnecessarily bad, even if
> you are not a programmer and you know at the intellectual level that it is
> not your flaw not to be proficient in any.
The idea, I think, was to gauge which parts of Git would be hard to
find developers for, because of small number of people proficient in
the programming language the part is written in. I'm thinking here
about Tcl/Tk and gitk and git-gui, see
http://git.or.cz/gitwiki/GitSurvey2007#head-ecb5564d71e4093e2e93e508380407a26dbcbdea
Nevertheless, _if_ this question is to stay (I am not sure one way or
another), we would better add "I am not programmer" or something like
that to the list of possible answers.
> Asking about geographic location and preferred human languages might help
> to gauge what l10n are desired for GUIs, but even there, don't forget that
> we are no company. We do not research markets and translate messages to
> missing languages, however popular, before being asked. That's not how we
> operate. So the result of these questions will be mainly to satisfy our
> curiosity, nothing more.
It would also answer question if adding support for i18n in git, for
example support for translating git commands messages, is something
which people would want or not. If they would be translated or not
it would depend on people, but one cannot even begin translation
efforts if there is no infrastructure in place.
But as the rest of localization / internationalization / translation
questions ("What do you need translated?" for example) were removed
from proposed set of questions for this year survey, perhaps this
question should be removed as well.
> "What kind of content do you track" might also be an equally interesting
> question. It also falls into the curiosity department, though.
True.
What should be the list of possible choices? Source code,
documentation, configuration, backup, binary files, other?
>> I'm not sure about having multiple choice vs. free-form question here.
>> Multiple choice is easier to analyze, especially if one would want
>> histogram of replies...
>
> And when you expect very many respondents, (1) you cannot afford to
> free-form; and (2) statistics over multiple choices, as long as choices
> are well seeded, will give you a good enough overview picture.
I wonder how many responses will we get this year. In 2006 there were
around 117 responses (but IIRC it was announced only on git mailing
list, wasn't it?), in 2007 survey there were 683 individual responses.
Git is even more popular now, I think...
OTOH there are some questions, like "feature requests/proposals"
question which *do require* free-form question. But they should
be few, and preferably for questions for which we don't need
histogram of replies.
I'll convert as much questions as possible to multiple choice
(pre-seeded), trying to come up with a good set of canned responses.
A question: if analysis of responses was not a problem, do you prefer
free form, or "select a choice" question?
>> Again: free form has some hassles, but so does coming up with good
>> choice of fixed answers in multiple choice question.
>
> You need to do at least one or the other, and I do not think there is any
> way to avoid that. Without a good choices, histogram would become useless
> (not necessarily because the answer will be dominated by "Other", but the
> seeing the choices tends to set the frame of mind when/before somebody
> answers the question). With free-form, you will spend the rest of your
> life analyzing to get any useful insight.
True... well, depending of course on the number of replies. Analysing
around 50 free-form replies (half of 100 individual responses to survey)
is not impossible; analysing 250+ is a lot of work.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Git Documentation
From: Karl Hasselström @ 2008-07-24 0:31 UTC (permalink / raw)
To: Pedro Melo; +Cc: Scott Chacon, git
In-Reply-To: <EDFF27AB-9B74-4868-A0BF-61AC8ED75037@simplicidade.org>
On 2008-07-22 11:15:40 +0100, Pedro Melo wrote:
> I also point them to Tommi Virtanen "Git for Computer
> Scientists":http://eagain.net/articles/git-for-computer-scientists/.
> It was that article that made it all "click" for me regarding git.
Me too.
I've found that starting off by explaining how git represents history
with blobs, trees, and commits (no need to mention tags or other
objects just yet), and how branches and merging just fall out
naturally from the commit DAG, is a good way to get people to
appreciate just how simple git's data model is. After that five-minute
introduction, they have a reasonable mental model of what the git
commands operate on -- then they just need to fill in the details,
like what commands there are and how they work.
(I've never taught git to anyone who didn't already know what a DAG or
a cryptographic hash is -- presumably, that would make it take more
than five minutes.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] bash completion: Add completion for 'git help'
From: Lee Marlow @ 2008-07-24 0:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Lee Marlow
In-Reply-To: <1216854795-51155-1-git-send-email-lee.marlow@gmail.com>
Renamed cached __git_commandlist to __git_porcelain_commandlist
and added __git_all_commandlist that only filters out *--* helpers.
Completions for 'git help' will use the __git_all_commandlist, while
__git_porcelain_commandlist is used for git command completion.
Users who actually read man pages may want to see help for plumbing
commands.
Options added: --all --info --man --web
Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
---
This version fixes a small error in the __git_all_commands
contrib/completion/git-completion.bash | 46 +++++++++++++++++++++++++++-----
1 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 2edb341..f3bdea4 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -349,10 +349,10 @@ __git_complete_revlist ()
esac
}
-__git_commands ()
+__git_all_commands ()
{
- if [ -n "$__git_commandlist" ]; then
- echo "$__git_commandlist"
+ if [ -n "$__git_all_commandlist" ]; then
+ echo "$__git_all_commandlist"
return
fi
local i IFS=" "$'\n'
@@ -360,6 +360,24 @@ __git_commands ()
do
case $i in
*--*) : helper pattern;;
+ *) echo $i;;
+ esac
+ done
+}
+__git_all_commandlist=
+__git_all_commandlist="$(__git_all_commands 2>/dev/null)"
+
+__git_porcelain_commands ()
+{
+ if [ -n "$__git_porcelain_commandlist" ]; then
+ echo "$__git_porcelain_commandlist"
+ return
+ fi
+ local i IFS=" "$'\n'
+ for i in "help" $(__git_all_commands)
+ do
+ case $i in
+ *--*) : helper pattern;;
applymbox) : ask gittus;;
applypatch) : ask gittus;;
archimport) : import;;
@@ -427,8 +445,8 @@ __git_commands ()
esac
done
}
-__git_commandlist=
-__git_commandlist="$(__git_commands 2>/dev/null)"
+__git_porcelain_commandlist=
+__git_porcelain_commandlist="$(__git_porcelain_commands 2>/dev/null)"
__git_aliases ()
{
@@ -767,6 +785,18 @@ _git_gc ()
COMPREPLY=()
}
+_git_help ()
+{
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --*)
+ __gitcomp "--all --info --man --web"
+ return
+ ;;
+ esac
+ __gitcomp "$(__git_all_commands)"
+}
+
_git_ls_remote ()
{
__gitcomp "$(__git_remotes)"
@@ -1369,7 +1399,8 @@ _git ()
case "$i" in
--git-dir=*) __git_dir="${i#--git-dir=}" ;;
--bare) __git_dir="." ;;
- --version|--help|-p|--paginate) ;;
+ --version|-p|--paginate) ;;
+ --help) command="help"; break ;;
*) command="$i"; break ;;
esac
c=$((++c))
@@ -1389,7 +1420,7 @@ _git ()
--help
"
;;
- *) __gitcomp "$(__git_commands) $(__git_aliases)" ;;
+ *) __gitcomp "$(__git_porcelain_commands) $(__git_aliases)" ;;
esac
return
fi
@@ -1414,6 +1445,7 @@ _git ()
fetch) _git_fetch ;;
format-patch) _git_format_patch ;;
gc) _git_gc ;;
+ help) _git_help ;;
log) _git_log ;;
ls-remote) _git_ls_remote ;;
ls-tree) _git_ls_tree ;;
--
1.6.0.rc0.14.g95f8
^ permalink raw reply related
* Re: [PATCH] t9700/test.pl: backwards compatibility improvements
From: Brandon Casey @ 2008-07-24 0:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vtzeg89cj.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> I have applied everything except for this one. I think it is Ok, but
> let's hear success or breakage stories from the list first and then remind
> me if the patch seems Ok, please?
will do.
^ permalink raw reply
* [PATCH] bash completion: Add completion for 'git help'
From: Lee Marlow @ 2008-07-24 0:07 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Lee Marlow
In-Reply-To: <1216854795-51155-1-git-send-email-lee.marlow@gmail.com>
Renamed cached __git_commandlist to __git_porcelain_commandlist
and added __git_all_commandlist that only filters out *--* helpers.
Completions for 'git help' will use the __git_all_commandlist, while
__git_porcelain_commandlist is used for git command completion.
Users who actually read man pages may want to see help for plumbing
commands.
Options added: --all --info --man --web
Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
---
This version fixes a small error in the __git_all_commands
contrib/completion/git-completion.bash | 46 +++++++++++++++++++++++++++-----
1 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 2edb341..f3bdea4 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -349,10 +349,10 @@ __git_complete_revlist ()
esac
}
-__git_commands ()
+__git_all_commands ()
{
- if [ -n "$__git_commandlist" ]; then
- echo "$__git_commandlist"
+ if [ -n "$__git_all_commandlist" ]; then
+ echo "$__git_all_commandlist"
return
fi
local i IFS=" "$'\n'
@@ -360,6 +360,24 @@ __git_commands ()
do
case $i in
*--*) : helper pattern;;
+ *) echo $i;;
+ esac
+ done
+}
+__git_all_commandlist=
+__git_all_commandlist="$(__git_all_commands 2>/dev/null)"
+
+__git_porcelain_commands ()
+{
+ if [ -n "$__git_porcelain_commandlist" ]; then
+ echo "$__git_porcelain_commandlist"
+ return
+ fi
+ local i IFS=" "$'\n'
+ for i in "help" $(__git_all_commands)
+ do
+ case $i in
+ *--*) : helper pattern;;
applymbox) : ask gittus;;
applypatch) : ask gittus;;
archimport) : import;;
@@ -427,8 +445,8 @@ __git_commands ()
esac
done
}
-__git_commandlist=
-__git_commandlist="$(__git_commands 2>/dev/null)"
+__git_porcelain_commandlist=
+__git_porcelain_commandlist="$(__git_porcelain_commands 2>/dev/null)"
__git_aliases ()
{
@@ -767,6 +785,18 @@ _git_gc ()
COMPREPLY=()
}
+_git_help ()
+{
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --*)
+ __gitcomp "--all --info --man --web"
+ return
+ ;;
+ esac
+ __gitcomp "$(__git_all_commands)"
+}
+
_git_ls_remote ()
{
__gitcomp "$(__git_remotes)"
@@ -1369,7 +1399,8 @@ _git ()
case "$i" in
--git-dir=*) __git_dir="${i#--git-dir=}" ;;
--bare) __git_dir="." ;;
- --version|--help|-p|--paginate) ;;
+ --version|-p|--paginate) ;;
+ --help) command="help"; break ;;
*) command="$i"; break ;;
esac
c=$((++c))
@@ -1389,7 +1420,7 @@ _git ()
--help
"
;;
- *) __gitcomp "$(__git_commands) $(__git_aliases)" ;;
+ *) __gitcomp "$(__git_porcelain_commands) $(__git_aliases)" ;;
esac
return
fi
@@ -1414,6 +1445,7 @@ _git ()
fetch) _git_fetch ;;
format-patch) _git_format_patch ;;
gc) _git_gc ;;
+ help) _git_help ;;
log) _git_log ;;
ls-remote) _git_ls_remote ;;
ls-tree) _git_ls_tree ;;
--
1.6.0.rc0.14.g95f8
^ permalink raw reply related
* Re: [PATCH] perl/Makefile: update NO_PERL_MAKEMAKER section
From: Brandon Casey @ 2008-07-23 23:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vy73s89hv.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> The perl modules must be copied to blib/lib so they are available for
>> testing.
>
> True, but private-Error needs to be handled a bit more carefully, I
> think.
>
> How about this on top of your patch?
That works. Error.pm is not available on my system and the statements
to copy private-Error.pm to Error.pm are correctly placed in perl.mak.
I should have gotten a clue when a file named _private_-Error.pm was
being copied to Error.pm and taken a look at Makefile.PL.
Thanks.
-brandon
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Stephan Beyer @ 2008-07-23 23:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Robin Rosenberg, Johannes Schindelin, git
In-Reply-To: <200807240130.31649.jnareb@gmail.com>
Hi,
Jakub Narebski wrote:
> Dnia ?roda 23. lipca 2008 16:54, Robin Rosenberg napisa?:
> > onsdagen den 23 juli 2008 15.18.40 skrev Johannes Schindelin:
> >> On Wed, 23 Jul 2008, Jakub Narebski wrote:
> >>> On Wed, 23 Jul 2008, Johannes Schindelin wrote:
> >>>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
> >>>>
> >>>>> 04. Which programming languages you are proficient with?
> >>>>> (The choices include programming languages used by git)
> >>>>> (zero or more: multiple choice)
> >>>>> - C, shell, Perl, Python, Tcl/Tk
> >>>>> + (should we include other languages, like C++, Java, PHP,
> >>>>> Ruby,...?)
[...]
>
> The idea is, I think, to know what languages people could contribute
> to Git; see analysis of this question at GitSurvey2007 page on git wiki:
> http://git.or.cz/gitwiki/GitSurvey2007#head-ecb5564d71e4093e2e93e508380407a26dbcbdea
Oha, is this a Git User's Survey or a Git Potential Contributor's Survey?
I thought this is some kind of demographic question about the "programming
background" of the user.
> And of course "I am not programmer" response...
This doesn't make sense, does it?
I know that there are non-programmer's who use git for there
configuration files and other non-programming track files, but
this looks somehow wrong in this survey.
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-23 23:49 UTC (permalink / raw)
To: Jean-François Veillette; +Cc: Git, Miguel Arroz
In-Reply-To: <169F15EC-1A58-4C2A-84FC-3D14F7B4F1C5@yahoo.ca>
Dnia środa 23. lipca 2008 17:14, Jean-François Veillette napisał:
> Le 08-07-22 à 21:25, Jakub Narebski a écrit :
>
> > First there is a question about the form of survey. Should we use web
> > based survey, as the survey before (http://www.survey.net.nz), sending
> > emails with link to this survey, or perhaps do email based survey,
> > with email Reply-To: address put for this survey alone? Should we use
> > the same web survey service as before (found by Paolo Ciarrocchi for
> > first, 2006 survey, and used also for 2007 survey), or is there one
> > better (it would better be free, and without limitations on the number
> > of responses; in 2006 there were around 117 responses, in 2007 there
> > were 683 individual responses).
>
> Consider
> http://www.survs.com
> It is still in beta but already years ahead of the proposed solution.
> I don't know about the specific of the beta (cost, availability,
> etc.) but I had a live presentation of the product and it is an
> amazingly great product !
It certainly _looks_ nice, but it lacks one very important feature
(or at least I was not able to find it): the ability to download *RAW*
data to analyse it off-line using more advanced tools (like for
example Perl script to clean-up responses; spreadsheet like Excel or
Gnumeric, or some statictics tool like R to analyze data, for example
do a correlation between responses to different questions).
http://www.survey.net.nz allows to download raw data in modified
CSV format (modified as it allows for line continuation). See for
example raw data for Git User's Survey 2007 results:
http://git.or.cz/gitwiki/GitSurvey2007?action=AttachFile&do=get&target=surveydata.csv
There is another nice thing that http://www.survey.net.nz is supposed
to have (but it doesn't unfortunately work; at least downloading
current layout of survey to tweak off-line doesn't/didn't work),
namely ability to create survey off-line using some specified text
format, and upload it, instead of creating it on-line (which might be
much work for large surveys).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: HP-UX issues (WAS: Re: [RFC] Git User's Survey 2008)
From: Miklos Vajna @ 2008-07-23 23:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <200807232338.04340.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]
On Wed, Jul 23, 2008 at 11:38:00PM +0200, Jakub Narebski <jnareb@gmail.com> wrote:
> > 2) Have coreutils installed. (But then I think it would be good to list
> > this dependency in INSTALL.)
>
> It would be good idea, although "POSIX-compliant shells" implies
> coreutils somewhat; shell scripts usually do require some utilities,
> like sed, grep, cat, test etc.
Sure, but we already use test_cmp instead of diff -u, avoid grep -a,
etc. These tricks are for running without GNU coreutils, I guess.
> > 3) Patch git to use automake's install-sh. (Would such a patch be ever
> > accepted?)
>
> I think it would. It would allow us also to uncomment the
> AC_PROG_INSTALL line in configure.ac file to find 'install'
> automatically (autoconf requires having install.sh or install-sh
> fallback in the sources).
>
> The problem is coming up with minimal yet portable (at least as
> portable as git itself) fallback install.sh script.
I just checked automake-1.10.1's install-sh script, it works properly
with HP-UX's ksh.
I think it would be possible to:
1) Just use it: in long-term this would mean no additional maintenance
cost, since if any problem occurs, it could be just updated from
automake.
2) Or make it as minimal as possible: As far as I see the current git
build system just uses the -d and -m switches, so the support for the
-c, -C, -g, -o, -s, -t and -T switches could be removed. This way we
would get a minimal install-sh, but then it would have to be maintained
inside git.git.
I think 1) would be better.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ 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