* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-24 8:24 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Dmitry Potapov, Johannes Schindelin, git
In-Reply-To: <20080723170120.GC17648@leksak.fem-net>
On Wed, 23 July 2008, Stephan Beyer wrote:
> Dmitry Potapov wrote:
>> On Wed, Jul 23, 2008 at 11:53:27AM +0200, Johannes Schindelin wrote:
>>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
>>>>
>>>> 11. Why did you choose Git? (if you use Git)
>>>> What do you like about using Git?
>>>> (free form, not to be tabulated)
>>>
>>> Again, to avoid hassles with free-form:
>>>
>>> Mandatory: work, mandatory: open source project I am participating
>>> in, speed, scalability, It's What Linus Uses, Other.
>>
>> If we move away from free-form, it should be much more choices here.
>>
>> - Ability to work offline
>> - Cryptographic authentication of history.
>> - Distributed development (pull/push from/to more than one remote repo)
>> - Easy to extend functionality through scripting
>> - Efficient storage model
>> - Elegant design
>> - Fast
>> - Good community support
>> - Rewriting patches before publishing (git rebase, commit --amend)
>> - Scalability (Efficient handling of large projects)
>> - Strong support for non-linear development
>> - Support of wide range of protocols for synchronization.
>> ...
>
> Heh, I can imagine git users reading that survey and thinking
> "What? Git allows me to rewrite patches before publishing?
> And it provides cryptographic integrity? Sounds good. *click*"
>
> Nevertheless, the list is fine ;)
> Perhaps also: "Good reputation".
Perhaps also: "Because it is popular (hype)", and I hope that
"Ability to track code movement" would have any takers. Although
it is hard to distinguish between 'reasons to choose' and 'favourite
features' list; let's make it more 'reasons to choose' (like "feature
rich").
"Good documentation", perhaps, too?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-24 8:15 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Schindelin, git
In-Reply-To: <20080723171745.GC5283@blimp.local>
On Wed, 23 Jul 2008, Alex Riesen wrote:
> Johannes Schindelin, Wed, Jul 23, 2008 11:53:27 +0200:
> > >
> > > 19. How do you publish/propagate your changes?
> > > (zero or more: multiple choice)
> > > - push, pull request, format-patch + email, bundle, other
> >
> > git svn
> >
>
> a converter using fast-import/fast-export/plumbing
So it would be now:
19. How do you publish/propagate your changes?
(zero or more: multiple choice)
- push, git-svn, foreign SCM (not via git-svn), pull request,
format-patch + email, bundle, other(*)
+ (*)If the way you publish your changes is not on above list,
please explain how do you publish your changes.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Preserve cwd in setup_git_directory()
From: Nguyen Thai Ngoc Duy @ 2008-07-24 8:12 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Johannes Schindelin, Geoff Russell
In-Reply-To: <48882628.7030305@viscovery.net>
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 setup 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>
---
On Thu, Jul 24, 2008 at 08:50:16AM +0200, Johannes Sixt wrote:
> Nguyễn Thái Ngọc Duy schrieb:
> > --- 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);
>
> This needs an error check.
Check added.
setup.c | 5 +++++
t/t1501-worktree.sh | 13 ++++++++++++-
2 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/setup.c b/setup.c
index 6cf9094..fa1d696 100644
--- a/setup.c
+++ b/setup.c
@@ -577,10 +577,15 @@ 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;
+ if (!getcwd(cwd, PATH_MAX))
+ die ("Could not get the current working directory");
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..d53d66a 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
* [PATCH v2] t6030 (bisect): work around Mac OS X "ls"
From: Jonathan Nieder @ 2008-07-24 7:43 UTC (permalink / raw)
To: Mike Hommey; +Cc: Christian Couder, git
In-Reply-To: <20080724060647.GA24587@glandium.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1513 bytes --]
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 look at
its output instead.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Mike Hommey wrote:
> On Thu, Jul 24, 2008 at 07:57:26AM +0200, Christian Couder wrote:
>> Le jeudi 24 juillet 2008, Jonathan Nieder a écrit :
>>> - test_must_fail ls .git/BISECT_* &&
>>> + echo .git/BISECT_* | test_must_fail grep BISECT_[^*] &&
>>
>> Perhaps the following is simpler:
>>
>> + test -z "$(ls .git/BISECT_*)" &&
>
> That is still a useless use of ls ;)
It is much better than what I wrote, at least.
Good night (well, good morning I guess), and thanks.
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..244fda6 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_* &&
+ test -z "$(ls .git/BISECT_* 2>/dev/null)" &&
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
* Re: [PATCH] In perforce, RCS keywords are case-sensitive
From: Simon Hausmann @ 2008-07-24 7:05 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.LNX.1.00.0807221235000.19665@iabervon.org>
On Tuesday 22 July 2008 18:48:57 Daniel Barkalow wrote:
> At least, this is true in 2007.2, according to the documentation.
>
> Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Acked-By: Simon Hausmann <simon@lst.de>
Thanks,
Simon
> A line of perl with the variable $file in a string followed by a different
> variable not in the string, for example, doesn't get mangled by p4 and may
> therefore appear in a p4 depot.
>
> I don't know if the "old-style keyword expansion" is case-sensitive,
> though, so I'm leaving that alone.
>
> contrib/fast-import/git-p4 | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> index d8de9f6..1ee612e 100755
> --- a/contrib/fast-import/git-p4
> +++ b/contrib/fast-import/git-p4
> @@ -902,7 +902,7 @@ class P4Sync(Command):
> if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
> text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
> elif stat['type'] in ('text+k', 'ktext', 'kxtext',
> 'unicode+k', 'binary+k'): - text =
> re.sub(r'(?i)\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\
>$',r'$\1$', text) + text =
> re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r
>'$\1$', text)
>
> contents[stat['depotFile']] = text
^ permalink raw reply
* Re: [PATCH] builtin-branch.c: optimize --merged and --no-merged
From: Lars Hjemli @ 2008-07-24 7:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ingo Molnar, SZEDER Gábor, git
In-Reply-To: <7vtzeg9rhh.fsf_-_@gitster.siamese.dyndns.org>
On Thu, Jul 24, 2008 at 12:15 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Instead, we can let the revision machinery traverse the history as if we
> are running:
>
> $ git rev-list --branches --not $commit
>
> by queueing the tips of branches we encounter as positive refs (this
> mimicks the "--branches" option in the above command line) and then
> appending the merge_filter_ref commit as a negative one, and finally
> calling prepare_revision_walk() to limit the list..
Nice.
> @@ -213,6 +211,7 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
> {
> struct ref_list *ref_list = (struct ref_list*)(cb_data);
> struct ref_item *newitem;
> + struct commit *commit;
> int kind;
> int len;
> static struct commit_list branch;
I think you can drop the 'branch' here.
> @@ -239,12 +242,8 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
> branch.item = lookup_commit_reference_gently(sha1, 1);
> if (!branch.item)
> die("Unable to lookup tip of branch %s", refname);
..and here.
- if (merge_filter == SHOW_NOT_MERGED &&
- has_commit(merge_filter_ref, &branch))
- return 0;
- if (merge_filter == SHOW_MERGED &&
- !has_commit(merge_filter_ref, &branch))
- return 0;
+ add_pending_object(&ref_list->revs,
+ (struct object *)branch.item, refname);
..and use 'commit' instead of 'branch.item' here.
> @@ -305,7 +304,13 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
> {
> char c;
> int color;
> - struct commit *commit;
> + struct commit *commit = item->commit;
> +
> + if (merge_filter != NO_FILTER) {
> + int is_merged = !!(item->commit->object.flags & UNINTERESTING);
> + if (is_merged != (merge_filter == SHOW_MERGED))
> + return;
> + }
A possible issue here is that `git branch -v --[no]-merged` might use
a wrong maxwidth, but I'm not sure if it's even worth fixing.
Thanks for cleaning up my mess.
--
larsh
^ permalink raw reply
* BUG: fetch incorrect interpretation of globing patterns in refspecs
From: marc zonzon @ 2008-07-24 7:07 UTC (permalink / raw)
To: git
Helo
I have a repository repo1 with four branches b_first, b_second,
b/third, b/fourth.
In a repository repo2 I put a remote config with: fetch =
+refs/heads/b/*:refs/remotes/b/* and I expect a fetch to apply to both
b/third and b/fourth.
But fetch will also catch b_first and b_second even if they don't
match the globing pattern.
I give the full script to reproduce the bug.
Marc
---------------------------------------------------------------------------------
Script started on Thu 24 Jul 2008 08:23:26 AM CEST
$ mkdir repo1
$ cd repo1
$ git init
Initialized empty Git repository in /shared/home/marc/gits/testbed/repo1/.git/
$ echo "master branch" > README
$ git add README
$ git commit README -m'initial commit in master'
Created initial commit 9ebc74c: initial commit in master
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 README
$ git checkout -b b_first
Switched to a new branch "b_first"
$ echo "branch b_first" >| README
$ git add README
$ git commit README -m'commit in b_first'
Created commit 40d985a: commit in b_first
1 files changed, 1 insertions(+), 1 deletions(-)
$ git checkout -b b_second
Switched to a new branch "b_second"
$ echo "branch b_second" >| README
$ git add README
$ git commit README -m'commit in b_second'
Created commit 661fe61: commit in b_second
1 files changed, 1 insertions(+), 1 deletions(-)
$ git checkout -b b/third master
Switched to a new branch "b/third"
$ echo "branch b/third" >| README
$ git add README
$ git commit README -m'commit in b/third'
Created commit 4f02216: commit in b/third
1 files changed, 1 insertions(+), 1 deletions(-)
$ git checkout -b b/fourth master
Switched to a new branch "b/fourth"
$ echo "branch b/fourth" >| README
$ git add README
$ git commit README -m'commit in b/fourth'
Created commit 068f9da: commit in b/fourth
1 files changed, 1 insertions(+), 1 deletions(-)
$ cd ..
$ mkdir repo2
$ cd repo2
$ git init
Initialized empty Git repository in /shared/home/marc/gits/testbed/repo2/.git/
$ git config --add remote.repo1.url ../repo1
$ git config --add remote.repo1.fetch '+refs/heads/b/*:refs/remotes/b/*'
$ git fetch -v repo1
warning: no common commits
remote: Counting objects: 15, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 15 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (15/15), done.
From ../repo1
* [new branch] b/fourth -> b/fourth
* [new branch] b/third -> b/third
* [new branch] b_first -> b_first
* [new branch] b_second -> b_second
^ permalink raw reply
* Re: git status in clean working dir
From: Ask Bjørn Hansen @ 2008-07-24 6:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, David Bremner
In-Reply-To: <7vtzeir68z.fsf@gitster.siamese.dyndns.org>
On Jul 21, 2008, at 19:40, Junio C Hamano wrote:
> (2) Then why are we even allowing to configure the plumbing to page?
I don't have an opinion on the the appropriateness of paging various
commands, but to solve the problem of scripts getting tripped up by
the paging, couldn't the plumping check if STDOUT is a tty and only do
the paging if so?
(In Perl "page_output(...) if $pager_configured and -t STDOUT")
- ask
--
http://develooper.com/ - http://askask.com/
^ permalink raw reply
* Re: [PATCH] Preserve cwd in setup_git_directory()
From: Johannes Sixt @ 2008-07-24 6:50 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Johannes Schindelin, Geoff Russell
In-Reply-To: <20080724031441.GA26072@laptop>
Nguyễn Thái Ngọc Duy schrieb:
> --- 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);
This needs an error check.
-- Hannes
^ permalink raw reply
* Re: [PATCH] t6030 (bisect): work around Mac OS X "ls"
From: Mike Hommey @ 2008-07-24 6:06 UTC (permalink / raw)
To: Christian Couder; +Cc: Jonathan Nieder, git
In-Reply-To: <200807240757.26290.chriscool@tuxfamily.org>
On Thu, Jul 24, 2008 at 07:57:26AM +0200, Christian Couder wrote:
> Le jeudi 24 juillet 2008, Jonathan Nieder a écrit :
> > 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_[^*] &&
>
> Perhaps the following is simpler:
>
> + test -z "$(ls .git/BISECT_*)" &&
That is still a useless use of ls ;)
Mike
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Steffen Prohaska @ 2008-07-24 6:06 UTC (permalink / raw)
To: Dmitry Potapov, Johannes Schindelin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20080723114022.GP2925@dpotapov.dyndns.org>
On Jul 23, 2008, at 1:40 PM, Dmitry Potapov wrote:
> On Wed, Jul 23, 2008 at 07:49:20AM +0200, Steffen Prohaska wrote:
>>
>> On Jul 23, 2008, at 3:31 AM, Johannes Schindelin wrote:
>>
>>>
>>> - if ((action == CRLF_BINARY) || !auto_crlf || !len)
>>> + if ((action == CRLF_BINARY) || (!auto_crlf && action < 0) || !len)
>>
>> I think we should strictly follow the documentation, so this should
>> read
>>
>> + if ((action == CRLF_BINARY) || (!auto_crlf && action !=
>> CRLF_INPUT) || !len)
>
> Well, your expression is correct if we choose to strictly follow to
> what
> the current documentation says, but it is not well written in this
> place,
> and, more importantly, I don't see any use case where you would want
> to
> set crlf=input in .gitattributes, because it is shared among users on
> different platforms. What you want to specify in it is whether a
> file is
> text or binary. If crlf is set, it means a text file; if unset, it
> is a
> binary file. Regardless of what autocrlf value, I don't see why a text
> file should be checked in with CRs. So, Dscho's patch makes more sense
> to me. This requires correction to the documentation though:
Ok, this and Dscho's earlier mail convinced me. My patch does not
make sense at all. I should have had thought a bit harder ;-)
I have however a related question:
Dscho,
Is the following your use case?
"I am the maintainer of this project. I know that this project needs
crlf conversion, because it is a cross-platform project. Therefore,
I want to force crlf conversion for this specific project, even if
the user did not configure core.autocrlf=input on Unix."
Your patch provides a solution, though not a very comfortable one. With
your patch applied, you could explicitly list all files (or filetypes)
that are text and mark them with 'crlf'. Git would not let CRLFs enter
the repository for these files. You could also specify 'crlf=input',
but I don't understand why you want to specify this. Anyway, you would
need to explicitly list all text filetypes and explicitly *not list* the
binary filetypes because they must not be converted. This is no very
comfortable, no?
I think what you really want to do is to tell git that the *automatic*
crlf detection shall be used for all files of your specific project,
even if the user did not configure core.autocrlf=input. This would
avoid listing each filetype separately.
Maybe we could allow 'crlf=guess' in .gitattributes with the following
documentation:
-- 8< --
Set to string value "guess"::
Setting `guess` tells git to apply conversion upon checkin
if the file content looks like text. On checkout, however,
git applies the conversion specified in `core.autocrlf`.
Setting `guess` can be useful to force automatic file type
detection for a specific project.
-- >8 --
> diff --git a/Documentation/gitattributes.txt b/Documentation/
> gitattributes.txt
> index d7b4114..448857b 100644
> --- a/Documentation/gitattributes.txt
> +++ b/Documentation/gitattributes.txt
> @@ -99,9 +99,9 @@ This attribute controls the line-ending convention.
> Set::
>
> Setting the `crlf` attribute on a path is meant to mark
> - the path as a "text" file. 'core.autocrlf' conversion
> - takes place without guessing the content type by
> - inspection.
> + the path as a "text" file. Line endings in a text file
> + are converted to LF upon checkin, and if 'core.autocrlf'
> + is true then to CRLF upon checkout.
>
> Unset::
Makes sense.
Steffen
^ permalink raw reply
* Re: [PATCH] t6030 (bisect): work around Mac OS X "ls"
From: Christian Couder @ 2008-07-24 5:57 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <Pine.GSO.4.62.0807232014030.14945@harper.uchicago.edu>
Le jeudi 24 juillet 2008, Jonathan Nieder a écrit :
> 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_[^*] &&
Perhaps the following is simpler:
+ test -z "$(ls .git/BISECT_*)" &&
> git bisect start &&
> test_must_fail git bisect good foo $HASH1 &&
> test_must_fail git bisect good $HASH1 bar &&
Thanks,
Christian.
^ permalink raw reply
* [PATCH] Document disabling core.whitespace values trailing-space and space-before-tab
From: "Peter Valdemar Mørch (Lists)" @ 2008-07-24 5:34 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]
From http://article.gmane.org/gmane.comp.version-control.git/68146 I got
the syntax that works:
git config core.whitespace "-trailing-space"
Is it me, or is this not readable from git help config which says:
> A comma separated list of common whitespace problems to notice. git
> diff will use color.diff.whitespace to highlight them, and git apply
> --whitespace=error will consider them as errors:
>
> · trailing-space treats trailing whitespaces at the end of the line
> as an error (enabled by default).
The '-trailing-space' syntax to disable the trailing-space setting is
not obvious and not documented as far as I can see. I would have assumed
a value of '' would disable it.
Is there a documentation bug here? If so, I suggest this patch. I didn't
find anywhere else where the '-setting' syntax was used to disable
something.
My first-ever git patch is attached, because Thunderbird messes up due
to wrapping. I realize that SubmittingPatches has a mini-guide for
reconfiguring Thunderbird (ver 1!), but I really prefer not to have to
add extensions and reconfigure Thunderbird to send patches. (Comments to
this and how the patch was made are welcome and encouraged)
Peter
--
Peter Valdemar Mørch
http://www.morch.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Document-disabling-core.whitespace-values-trailing-s.patch --]
[-- Type: text/x-patch; name="0001-Document-disabling-core.whitespace-values-trailing-s.patch", Size: 1424 bytes --]
>From 900455ce5a4e8bf771aea2e3dbdbab38e440cdf4 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Peter=20Valdemar=20M=C3=B8rch?= <peter@morch.com>
Date: Thu, 24 Jul 2008 07:18:48 +0200
Subject: [PATCH] Document disabling core.whitespace values trailing-space and space-before-tab
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Peter Valdemar Mørch <peter@morch.com>
---
Documentation/config.txt | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index e784805..a198b3c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -361,10 +361,12 @@ core.whitespace::
consider them as errors:
+
* `trailing-space` treats trailing whitespaces at the end of the line
- as an error (enabled by default).
+ as an error (enabled by default - disable with 'git config core.whitespace
+ "-trailing-space"').
* `space-before-tab` treats a space character that appears immediately
before a tab character in the initial indent part of the line as an
- error (enabled by default).
+ error (enabled by default - disable with 'git config core.whitespace
+ "-space-before-tab"').
* `indent-with-non-tab` treats a line that is indented with 8 or more
space characters as an error (not enabled by default).
* `cr-at-eol` treats a carriage-return at the end of line as
--
1.5.6
^ permalink raw reply related
* Re: [RFC] Git User's Survey 2008
From: david @ 2008-07-24 5:02 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Jakub Narebski, Robin Rosenberg, Johannes Schindelin, git
In-Reply-To: <20080723235359.GB12754@leksak.fem-net>
On Thu, 24 Jul 2008, Stephan Beyer wrote:
> 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.
there are non-programmers who use git to track projects that they want to
be able to run the latest versions of. they don't program, just git pull;
make;make install
David Lang
^ permalink raw reply
* [PATCH] document that git-tag can tag more than heads
From: Jonathan Nieder @ 2008-07-24 5:01 UTC (permalink / raw)
To: git
After looking the git-tag manpage, someone on #git wondered how
to tag a commit that is not a branch head. This patch changes
the synopsis to say "<commit-ish> | <object>" instead of
"<head>" to address his question.
Samuel Bronson had the idea of putting "<commit-ish> | <object>"
for "<object>" because most tags point to commits (and for the
rest of the manpage, all tags point to commits).
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Documentation/git-tag.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index b8dc88f..1ce1d7d 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -9,7 +9,8 @@ git-tag - Create, list, delete or verify a tag object signed with GPG
SYNOPSIS
--------
[verse]
-'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] <name> [<head>]
+'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>]
+ <name> [<commit-ish> | <object>]
'git tag' -d <name>...
'git tag' [-n[<num>]] -l [<pattern>]
'git tag' -v <name>...
--
1.5.6.3.549.g8ca11
^ permalink raw reply related
* 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
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