* Re: ssh username environment variable
From: Shawn O. Pearce @ 2010-01-08 20:29 UTC (permalink / raw)
To: Chris Packham; +Cc: git
In-Reply-To: <a038bef51001081224l33164526y51e5ca064b82b73a@mail.gmail.com>
Chris Packham <judge.packham@gmail.com> wrote:
> Just wondering if there is an environment variable I can use to tell
> git or ssh what user name to use for the ssh transport?
No. But you can hack around it:
cat >$HOME/bin/git-ssh
#!/bin/sh
ssh -l $GIT_SSH_USER "$@"
^D
GIT_SSH=$HOME/bin/git-ssh GIT_SSH_USER=myname git clone ...
--
Shawn.
^ permalink raw reply
* Re: [PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax
From: Avery Pennarun @ 2010-01-08 20:31 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Nanako Shiraishi, Johannes Schindelin, git
In-Reply-To: <fabb9a1e1001081222q7122872bu72cea4e393f272ac@mail.gmail.com>
On Fri, Jan 8, 2010 at 3:22 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Fri, Jan 8, 2010 at 15:16, Avery Pennarun <apenwarr@gmail.com> wrote:
>> This would resolve any other inconsistencies between the two as well,
>> notably that non-interactive rebase sometimes refuses to do the rebase
>> I requested because "Current branch master is up to date," while
>> interactive rebase is willing to do it. (Personally I prefer the
>> latter behaviour, since I don't like tools that think they're smarter
>> than me :))
>
> I taught rebase the -f|--force-rebase flag a little while back, you
> could use that :).
Thanks, I didn't know about that one. But my general point is still:
we seem to have two implementations when the functionality of one is
actually a superset of the other. As far as I can see, anyway. So
the obvious way to reduce the duplicated code is to simply eliminate
the less-featureful implementation.
Avery
^ permalink raw reply
* Re: ssh username environment variable
From: Junio C Hamano @ 2010-01-08 20:34 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Chris Packham, git
In-Reply-To: <20100108202958.GL32155@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Chris Packham <judge.packham@gmail.com> wrote:
>> Just wondering if there is an environment variable I can use to tell
>> git or ssh what user name to use for the ssh transport?
>
> No. But you can hack around it:
>
> cat >$HOME/bin/git-ssh
> #!/bin/sh
> ssh -l $GIT_SSH_USER "$@"
> ^D
>
> GIT_SSH=$HOME/bin/git-ssh GIT_SSH_USER=myname git clone ...
I thought the standard answer was "use $HOME/.ssh/config", to set User
by keying on the remote hostname to which you are going.
^ permalink raw reply
* Re: ssh username environment variable
From: Chris Packham @ 2010-01-08 20:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vskag9vz0.fsf@alter.siamese.dyndns.org>
On Fri, Jan 8, 2010 at 3:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
>> Chris Packham <judge.packham@gmail.com> wrote:
>>> Just wondering if there is an environment variable I can use to tell
>>> git or ssh what user name to use for the ssh transport?
>>
>> No. But you can hack around it:
>>
>> cat >$HOME/bin/git-ssh
>> #!/bin/sh
>> ssh -l $GIT_SSH_USER "$@"
>> ^D
>>
>> GIT_SSH=$HOME/bin/git-ssh GIT_SSH_USER=myname git clone ...
>
> I thought the standard answer was "use $HOME/.ssh/config", to set User
> by keying on the remote hostname to which you are going.
>
Yeah thats what I've done after reading a few more man pages.
^ permalink raw reply
* Re: [PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax
From: Sverre Rabbelier @ 2010-01-08 20:37 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Junio C Hamano, Nanako Shiraishi, Johannes Schindelin, git
In-Reply-To: <32541b131001081231x1b6ac8c1k30084e4abf8cc896@mail.gmail.com>
Heya,
On Fri, Jan 8, 2010 at 15:31, Avery Pennarun <apenwarr@gmail.com> wrote:
> Thanks, I didn't know about that one. But my general point is still:
> we seem to have two implementations when the functionality of one is
> actually a superset of the other. As far as I can see, anyway. So
> the obvious way to reduce the duplicated code is to simply eliminate
> the less-featureful implementation.
*cough* git sequencer *cough*
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 1/5] MSVC: Windows-native implementation for subset of Pthreads API
From: Johannes Sixt @ 2010-01-08 20:40 UTC (permalink / raw)
To: kusmabite; +Cc: Dmitry Potapov, msysgit, git, Andrzej K. Haczewski
In-Reply-To: <40aa078e1001080258n67e0711sf4733a99d512bf1@mail.gmail.com>
On Freitag, 8. Januar 2010, Erik Faye-Lund wrote:
> On Fri, Jan 8, 2010 at 4:32 AM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> > AFAIK, Win32 API assumes that reading LONG is always atomic, so
> > the critical section is not really necesary here, but you need
> > to declare 'waiters' as 'volatile':
>
> "Simple reads and writes to properly-aligned 32-bit variables are
> atomic operations."
> http://msdn.microsoft.com/en-us/library/ms684122(VS.85).aspx
>
> In other words: Yes, you are right.
Quite frankly, I do not want to stretch this statement to apply to the MinGW
compiler. The code in question is not performance critical anyway. I'd prefer
to leave it as is - it's undergone 2 months of testing already. Besides,
IMHO, it is much more readable the way it is written.
-- Hannes
^ permalink raw reply
* Idea: global git object cache
From: Avery Pennarun @ 2010-01-08 21:05 UTC (permalink / raw)
To: Git Mailing List
Hi all,
One thing I find curious about git is how objects mostly aren't shared
between multiple repositories on the local system. For example, if I
do:
git clone git://git.kernel.org/pub/scm/git/git.git git1
git clone git://git.kernel.org/pub/scm/git/git.git git2
Then I end up downloading the same objects from kernel.org *twice*.
If I use --reference on the second clone, then I can avoid
re-downloading all the objects, and it's much faster.
Unfortunately, I have to provide that option by hand, which is a
problem for git-submodule: it goes out to clone someone else's
repository automatically and doesn't know how to guess a value for
--reference. Another thing I commonly want to do with submodules is
to rm -rf the submodule's files, eg. because I change branches and git
doesn't clean it automatically. But then when I switch branches back
to the one with the submodule, git wants to go re-download the
submodule *again*. Redoing the checkout makes sense to me (just as
git deletes/recreates files when I normally switch branches) but
re-downloading seems silly.
So here's my suggestion to minimize downloads in a pretty easy way:
- whenever git creates a packfile in any repo (eg. during git gc or
git fetch), make an *extra* hardlink of it into
~/.gitcache/objects/pack.
- whenever git is considering which objects it does/doesn't currently
have, also consider the packs in ~/.gitcache/objects/pack (ie. using
the git/objects/alternates mechanism). If one of the packs qualifies,
hardlink it into the current repo. Maybe give it a .keep file to
indicate that it's counterproductive to repack this pack.
- after git deletes a packfile in any repo (eg. during git gc), check
the link count of that pack in ~/.gitcache/objects/pack; if it's now
down to just 1, there are no other users of the pack, so delete it
there too. You would also need to prune the cachedir occasionally to
deal with repositories that were deleted in other ways (eg. rm -rf).
- share the list of refs in a similar way (noticing that you probably
have different refs in multiple repos that are named
"refs/heads/master" of course) so that fetches will be efficient.
- extra improvement to submodule behaviour: hardlink packs from the
submodule into the supermodule's objects/pack directory (or use a
different directory like .git/submodules/pack to keep things
separate). Also, submodules should use the superproject's pack
directory as an alternate, in case (as often happens for me) the
supermodule already contains a bunch of objects from the submodule,
because the modules were split at some point.
I believe this would be quite easy to implement and would give an
immediate efficiency improvement. The ~/.gitcache feature could be
enabled/disabled by a config option. Is there any reason not to do
it?
Thanks,
Avery
P.S. I've been testing git's behaviour with lots of very large packs -
I'm currently using about 58 packs of about 1 GB each - as part of my
'bup' git-based backup tool (http://apenwarr.ca/log/?m=201001#04).
Repacking and fsck are obviously horrendously slow with that much
data, but bup avoids those operations as much as possible, and a
~/.gitcache wouldn't need to worry about them either (since each repo
is still responsible for repacking its own packs). Overall
performance for other git operations seems to be fine, though. And
searching the cache as a last restore can be optimized by always
searching packs in MRU order, in case git doesn't already do this.
^ permalink raw reply
* Re: Trouble with 'make prefix=/usr info'
From: Chris Johnsen @ 2010-01-08 21:14 UTC (permalink / raw)
To: Craig Moore; +Cc: Michael J Gruber, git
In-Reply-To: <d4133e471001060432v38a3f910qb27b9e77f4c1aa8b@mail.gmail.com>
On 2010 Jan 6, at 06:32, Craig Moore wrote:
> I've isolated the problem, and its coming from this command:
>
> ================================
> $ docbook2x-texi user-manual.xml --encoding=UTF-8 --to-stdout
>> user-manual.texi++
> Usage: jw [<options>] <sgml_file>
> where <options> are:
> -f|--frontend <frontend>: Specify the frontend (source format)
> (default is docbook)
> -b|--backend <backend>: Specify the backend (destination
> format)
> (default is html)
> -c|--cat <file>: Specify an extra SGML open catalog
> -n|--nostd: Do not use the standard SGML open
> catalogs
> -d|--dsl <file>|default|none: Specify an alternate style sheet
> (default is to use the default
> stylesheet)
> -l|--dcl <file>: Specify an alternate SGML declaration
> (usual ones like xml.dcl get detected
> automatically)
> -s|--sgmlbase <path>: Change base directory for SGML
> distribution
> (usually /usr/share/sgml)
> -p|--parser <program>: Specify the parser if several are
> installed
> (jade or openjade)
> -o|--output <directory>: Set output directory
> -u|--nochunks: Output only one big file
> (overrides the stylesheet settings)
> -i|--include <section>: Specify a SGML marked section to
> include
> (should be marked as "ignore" in
> the SGML text)
> -w|--warning <warning_type>|list: Control warnings or display the
> allowed warning types
> -e|--errors <error_type>|list: Control errors or display the allowed
> error types
> -h|--help: Print this help message and exit
> -V <variable[=value]>: Set a variable
> -v|--version: Print the version and exit
>
> $ docbook2x-texi --version
> DocBook-utils version 0.6.14 (jw version 1.1)
> ================================
>
> As you can see, I'm using DocBook-utils version 0.6.14 (jw version
> 1.1), and it doesn't list '--encoding=UTF-8 --to-stdout' in its
> options list. I'm guessing I've got the wrong version or type
> installed? Is there another which I should be using?
>
> Thanks for your help,
> Craig
>
I have previously used docbook2texi from docbook2X 0.8.8 by setting
DOCBOOK2X_TEXI for 'make info'.
<http://docbook2x.sourceforge.net/>
It needed a non-released patch to understand the combination of "--to-
stdout" and "--encoding=", though:
<http://docbook2x.cvs.sourceforge.net/viewvc/docbook2x/docbook2X/
perl/db2x_texixml.pl?r1=1.49&r2=1.50>
Alternatively, it is possible to work-around the failure of --stdout
with a wrapper script, but the patch is easy enough to apply.
--
Chris
^ permalink raw reply
* How to push changes from clone back to master
From: Simon C @ 2010-01-08 21:28 UTC (permalink / raw)
To: git
I created master branch in git:
mkdir git_master;
cd git_master
git init
git add .
git commit
create a clone
git clone . ../git_clone1
create newfile
git add newfile
git commit .
then try to propagate changes to master
git push
it gave me some warning, and subsequent git push says everything is up to
date.
but I do not see the new file under git_master
--
View this message in context: http://n2.nabble.com/How-to-push-changes-from-clone-back-to-master-tp4275010p4275010.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/5] MSVC: Windows-native implementation for subset of Pthreads API
From: Dmitry Potapov @ 2010-01-08 21:37 UTC (permalink / raw)
To: Johannes Sixt; +Cc: kusmabite, msysgit, git, Andrzej K. Haczewski
In-Reply-To: <201001082140.36717.j6t@kdbg.org>
On Fri, Jan 08, 2010 at 09:40:36PM +0100, Johannes Sixt wrote:
> On Freitag, 8. Januar 2010, Erik Faye-Lund wrote:
> > On Fri, Jan 8, 2010 at 4:32 AM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> > > AFAIK, Win32 API assumes that reading LONG is always atomic, so
> > > the critical section is not really necesary here, but you need
> > > to declare 'waiters' as 'volatile':
> >
> > "Simple reads and writes to properly-aligned 32-bit variables are
> > atomic operations."
> > http://msdn.microsoft.com/en-us/library/ms684122(VS.85).aspx
> >
> > In other words: Yes, you are right.
>
> Quite frankly, I do not want to stretch this statement to apply to the MinGW
> compiler.
I am sure that MinGW compiler (i.e. gcc) will work fine as long as the
variable is marked as 'volatile'.
> The code in question is not performance critical anyway. I'd prefer
> to leave it as is - it's undergone 2 months of testing already.
Well, it is a strong argument for not change anything, in general, but
the change is trivial -- instead of increment and decrementing some
varaible under a lock, it is increment/decrement using atomic operation.
There is no change to the logic, or anything that can have unexpected
side effects.
> Besides,
> IMHO, it is much more readable the way it is written.
I _completely_ disagree with that. Using atomic operations is not only
more efficient, but it is more readable. Having an additional mutex just
to increment and decrement does not increase readability in any way but
only raises additional questions -- why do you need it here? Is it used
for something else besides incrementing and decrementing the variable,
which can be done atomically?
Dmitry
^ permalink raw reply
* Re: [PATCH 9/9] rerere forget path: forget recorded resolution
From: Johannes Sixt @ 2010-01-08 21:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1262122958-9378-10-git-send-email-gitster@pobox.com>
Your implementation forgets to re-insert the forgotten resolutions into
MERGE_RR, therefore, the next 'git rerere' does not record the new
resolution.
In my implementation of 'rerere forget', I had the following tests.
The latter two of the three new tests fail with your implementation.
-- Hannes
diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
index a6bc028..a3f0c18 100755
--- a/t/t4200-rerere.sh
+++ b/t/t4200-rerere.sh
@@ -75,8 +75,9 @@ test_expect_success 'no postimage or thisimage yet' \
test_expect_success 'preimage has right number of lines' '
cnt=$(sed -ne "/^<<<<<<</,/^>>>>>>>/p" $rr/preimage | wc -l) &&
- test $cnt = 13
-
+ test $cnt = 13 &&
+ cnt=$(grep "To die! T" $rr/preimage | wc -l) &&
+ test $cnt = 1
'
git show first:a1 > a1
@@ -142,7 +143,23 @@ test_expect_success 'rerere kicked in' "! grep ^=======$ a1"
test_expect_success 'rerere prefers first change' 'test_cmp a1 expect'
-rm $rr/postimage
+test_expect_success 'rerere forget drops postimage' '
+ git rerere forget a1 &&
+ ! test -f $rr/postimage
+'
+
+test_expect_success 'conflict hash is the same as before' '
+ test $sha1 = "$(perl -pe "s/ .*//" .git/MERGE_RR)"
+'
+
+test_expect_success 'preimage was updated' '
+ cnt=$(sed -ne "/^<<<<<<</,/^>>>>>>>/p" $rr/preimage | wc -l) &&
+ test $cnt = 13 &&
+ cnt=$(grep "To die! T" $rr/preimage | wc -l) &&
+ test $cnt = 2
+'
+
+rm -f $rr/postimage
echo "$sha1 a1" | perl -pe 'y/\012/\000/' > .git/MERGE_RR
test_expect_success 'rerere clear' 'git rerere clear'
^ permalink raw reply related
* unchecked mallocs
From: Marinescu Paul dan @ 2010-01-08 21:59 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <D6F784B72498304C93A8A4691967698E8EE2C45016@REX2.intranet.epfl.ch>
While checking out the git code in xdiff/xpatience.c and xdiff/xmerge.c I
came across several (three) locations where the return values of xdl_malloc
(#defined as malloc) is not checked. Shouldn't this be done here?
In git 1.6.6 the calls are at
xmerge.c:567
merge.c:571
xpatience.c:191
Paul
^ permalink raw reply
* Re: git-cherry-pick problem - directory not touched by commit is marked "added by us"
From: Hakim Cassimally @ 2010-01-08 22:29 UTC (permalink / raw)
To: git; +Cc: Sam Vilain
In-Reply-To: <7vzl4qegdm.fsf@alter.siamese.dyndns.org>
(woops, sent just to Junio, resending to list)
Hi,
Thanks for the suggestions, I've tried both those commands, and they
break too :-(
2010/1/7 Junio C Hamano <gitster@pobox.com>:
> Junio C Hamano <gitster@pobox.com> writes:
>> What "cherry-pick" internally does is to run:
>>
>> git merge-recursive 301a^ -- HEAD 301a
>>
>> That is, "We are at HEAD; consolidate the change since 301a^ to 301a into
>> our state, and leave the result in the index and the work tree". Then it
>> commits the result. One thing to try is to see if this gives the same
>> kind of breakage.
$ git merge-recursive 301a^ -- HEAD 301a
# woo! no response! promising
$ git status
# On branch cgi_branch
<snip>
# new file: bin/upload_module.pl
#
# Unmerged paths:
# added by us: www/client/css/admin-clean.css
# added by us: www/client/css/admin.css
<snip dozens of spurious "added by us">
> There actually is another possibility; we used to run inside "cherry-pick"
>
> git merge-resolve 301a^ -- HEAD 301a
>
> instead. The request is the same but it uses a different algorithm, so if
> one fails and one succeeds, that might give us a better clue to figure out
> what is going on.
$ git merge-resolve 301a^ -- HEAD 301a
Trying simple merge.
Simple merge failed, trying Automatic merge.
error: www/client: is a directory - add individual files instead
fatal: Unable to process path www/client
error: www/css: is a directory - add individual files instead
fatal: Unable to process path www/css
error: www/images: is a directory - add individual files instead
fatal: Unable to process path www/images
error: www/js: is a directory - add individual files instead
fatal: Unable to process path www/js
fatal: merge program failed
At least the latter fails more informatively?
Thanks again for the help and suggestions ;-)
osfameron
^ permalink raw reply
* Re: [PATCH 2/3] ident.c: check explicit identity for name and email separately
From: Santi Béjar @ 2010-01-08 22:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Adam Megacz
In-Reply-To: <7vbph4eg63.fsf_-_@alter.siamese.dyndns.org>
On Fri, Jan 8, 2010 at 5:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
> bb1ae3f (commit: Show committer if automatic, 2008-05-04) added a logic to
> check both name and email were given explicitly by the end user, but it
> assumed that fmt_ident() is never called before git_default_user_config()
> is called, which was fragile. The former calls setup_ident() and fills
> the "default" name and email, so the check in the config parser would have
> mistakenly said both are given even if only user.name was provided.
>
> Make the logic more robust by keeping track of name and email separately.
>
It's a good improvement, thanks.
Acked-by: Santi Béjar <santi@agolina.net>
Santi
^ permalink raw reply
* [PATCH] string-list: rename the include guard to STRING_LIST_H
From: Thiago Farina @ 2010-01-08 22:45 UTC (permalink / raw)
To: git
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
string-list.h | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/string-list.h b/string-list.h
index 14bbc47..6569cf6 100644
--- a/string-list.h
+++ b/string-list.h
@@ -1,5 +1,5 @@
-#ifndef PATH_LIST_H
-#define PATH_LIST_H
+#ifndef STRING_LIST_H
+#define STRING_LIST_H
struct string_list_item {
char *string;
@@ -39,4 +39,4 @@ struct string_list_item *string_list_append(const char *string, struct string_li
void sort_string_list(struct string_list *list);
int unsorted_string_list_has_string(struct string_list *list, const char *string);
-#endif /* PATH_LIST_H */
+#endif /* STRING_LIST_H */
--
1.6.6.75.g37bae
^ permalink raw reply related
* [PATCH 1/2] Test update-index for a gitlink to a .git file
From: Brad King @ 2010-01-08 22:36 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Lars Hjemli
In-Reply-To: <1262990208-15554-1-git-send-email-brad.king@kitware.com>
Check that update-index recognizes a submodule that uses a .git file.
Currently it works when the .git file specifies an absolute path, but
not when it specifies a relative path.
Signed-off-by: Brad King <brad.king@kitware.com>
---
t/t2104-update-index-gitfile.sh | 38 ++++++++++++++++++++++++++++++++++++++
1 files changed, 38 insertions(+), 0 deletions(-)
create mode 100755 t/t2104-update-index-gitfile.sh
diff --git a/t/t2104-update-index-gitfile.sh b/t/t2104-update-index-gitfile.sh
new file mode 100755
index 0000000..ba71984
--- /dev/null
+++ b/t/t2104-update-index-gitfile.sh
@@ -0,0 +1,38 @@
+#!/bin/sh
+#
+# Copyright (c) 2010 Brad King
+#
+
+test_description='git update-index for gitlink to .git file.
+'
+
+. ./test-lib.sh
+
+test_expect_success 'submodule with absolute .git file' '
+ mkdir sub1 &&
+ (cd sub1 &&
+ git init &&
+ REAL="$(pwd)/.real" &&
+ mv .git "$REAL"
+ echo "gitdir: $REAL" >.git &&
+ test_commit first)
+'
+
+test_expect_success 'add gitlink to absolute .git file' '
+ git update-index --add -- sub1
+'
+
+test_expect_success 'submodule with relative .git file' '
+ mkdir sub2 &&
+ (cd sub2 &&
+ git init &&
+ mv .git .real &&
+ echo "gitdir: .real" >.git &&
+ test_commit first)
+'
+
+test_expect_failure 'add gitlink to relative .git file' '
+ git update-index --add -- sub2
+'
+
+test_done
--
1.6.5
^ permalink raw reply related
* [PATCH 0/2] Support relative .git file in a submodule
From: Brad King @ 2010-01-08 22:36 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Lars Hjemli
While experimenting with submodules I discovered that if a submodule
has a .git file "symlink" with a relative path to the real submodule
repository then it cannot be added to the superproject:
$ git init
$ mkdir sub
$ cd sub
$ git init
$ mv .git .real
$ echo 'gitdir: .real' > .git
$ echo a > a
$ git add a
$ git commit -m a
$ cd ..
$ git add sub
fatal: Not a git repository: .real
This patch series adds a test demonstrating the problem, and then
fixes it.
Brad King (2):
Test update-index for a gitlink to a .git file
Handle relative paths in submodule .git files
setup.c | 17 +++++++++++++++++
t/t2104-update-index-gitfile.sh | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+), 0 deletions(-)
create mode 100755 t/t2104-update-index-gitfile.sh
^ permalink raw reply
* [PATCH 2/2] Handle relative paths in submodule .git files
From: Brad King @ 2010-01-08 22:36 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Lars Hjemli
In-Reply-To: <1262990208-15554-1-git-send-email-brad.king@kitware.com>
Commit 842abf06f36b5b31050db6406265972e3e1cc189 taught
resolve_gitlink_ref() to call read_gitfile_gently() to resolve .git
files. However, read_gitfile_gently() needs to chdir over to the
directory containing the .git file to resolve relative paths correctly.
Signed-off-by: Brad King <brad.king@kitware.com>
---
setup.c | 17 +++++++++++++++++
t/t2104-update-index-gitfile.sh | 2 +-
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/setup.c b/setup.c
index 2cf0f19..a233e01 100644
--- a/setup.c
+++ b/setup.c
@@ -255,6 +255,8 @@ const char *read_gitfile_gently(const char *path)
struct stat st;
int fd;
size_t len;
+ char cwd[1024] = "";
+ const char *slash;
if (stat(path, &st))
return NULL;
@@ -276,9 +278,24 @@ const char *read_gitfile_gently(const char *path)
if (len < 9)
die("No path in gitfile: %s", path);
buf[len] = '\0';
+
+ slash = strrchr(path, '/');
+ if (slash) {
+ char *dir = xstrndup(path, slash - path);
+ if (!getcwd(cwd, sizeof(cwd)))
+ die_errno ("Could not get current working directory");
+ if (chdir(dir))
+ die_errno ("Could not switch to '%s'", dir);
+ free(dir);
+ }
+
if (!is_git_directory(buf + 8))
die("Not a git repository: %s", buf + 8);
path = make_absolute_path(buf + 8);
+
+ if (*cwd && chdir(cwd))
+ die_errno ("Could not change back to '%s'", cwd);
+
free(buf);
return path;
}
diff --git a/t/t2104-update-index-gitfile.sh b/t/t2104-update-index-gitfile.sh
index ba71984..641607d 100755
--- a/t/t2104-update-index-gitfile.sh
+++ b/t/t2104-update-index-gitfile.sh
@@ -31,7 +31,7 @@ test_expect_success 'submodule with relative .git file' '
test_commit first)
'
-test_expect_failure 'add gitlink to relative .git file' '
+test_expect_success 'add gitlink to relative .git file' '
git update-index --add -- sub2
'
--
1.6.5
^ permalink raw reply related
* [PATCH] ls-files: fix overeager pathspec optimization
From: Junio C Hamano @ 2010-01-08 23:01 UTC (permalink / raw)
To: Jeff King, Linus Torvalds; +Cc: Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <7vvdfcfjxo.fsf@alter.siamese.dyndns.org>
Given pathspecs that share a common prefix, ls-files optimized its call
into recursive directory reader by starting at the common prefix
directory.
If you have a directory "t" with an untracked file "t/junk" in it, but the
top-level .gitignore file told us to ignore "t/", this resulted in an
unexpected behaviour:
$ git ls-files -o --exclude-standard
$ cd t && git ls-files -o --exclude-standard
junk
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Junio C Hamano <gitster@pobox.com> writes:
>> I think a proper fix should be in dir.c::read_directory() where it calls
>> read_directory_recursive() without first checking if the directory itself
>> should be ignored. read_directory_recursive() itself has a logic to see
>> if the dirent it found is worth recursing into and a similar logic should
>> be in the toplevel caller.
So here it is.
dir.c | 37 ++++++++++++++++++++++++++++++++++
t/t3001-ls-files-others-exclude.sh | 39 ++++++++++++++++++++++++++++++++++++
2 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/dir.c b/dir.c
index f9ac454..9316eb6 100644
--- a/dir.c
+++ b/dir.c
@@ -787,6 +787,40 @@ static void free_simplify(struct path_simplify *simplify)
free(simplify);
}
+static int has_leading_ignored_dir(struct dir_struct *dir,
+ const char *path_, int len,
+ const struct path_simplify *simplify)
+{
+ int at, dtype = DT_DIR;
+ char path[PATH_MAX];
+
+ at = 0;
+ memcpy(path, path_, len);
+ while (1) {
+ char *cp;
+ path[at] = '\0';
+ /*
+ * NOTE! NOTE! NOTE!: we might want to actually lstat(2)
+ * path[] to make sure it is a directory.
+ */
+ if (excluded(dir, path, &dtype))
+ return 1;
+ if (at < len) {
+ path[at] = path_[at];
+ if (at < len && path[at] == '/')
+ at++;
+ }
+ if (len <= at)
+ break;
+ cp = memchr(path + at, '/', len - at);
+ if (!cp)
+ at = len;
+ else
+ at = cp - path;
+ }
+ return 0;
+}
+
int read_directory(struct dir_struct *dir, const char *path, int len, const char **pathspec)
{
struct path_simplify *simplify;
@@ -795,6 +829,9 @@ int read_directory(struct dir_struct *dir, const char *path, int len, const char
return dir->nr;
simplify = create_simplify(pathspec);
+ if (has_leading_ignored_dir(dir, path, len, simplify))
+ return dir->nr;
+
read_directory_recursive(dir, path, len, 0, simplify);
free_simplify(simplify);
qsort(dir->entries, dir->nr, sizeof(struct dir_entry *), cmp_name);
diff --git a/t/t3001-ls-files-others-exclude.sh b/t/t3001-ls-files-others-exclude.sh
index c65bca8..9e71260 100755
--- a/t/t3001-ls-files-others-exclude.sh
+++ b/t/t3001-ls-files-others-exclude.sh
@@ -153,4 +153,43 @@ test_expect_success 'negated exclude matches can override previous ones' '
grep "^a.1" output
'
+test_expect_success 'subdirectory ignore (setup)' '
+ mkdir -p top/l1/l2 &&
+ (
+ cd top &&
+ git init &&
+ echo /.gitignore >.gitignore &&
+ echo l1 >>.gitignore &&
+ echo l2 >l1/.gitignore &&
+ >l1/l2/l1
+ )
+'
+
+test_expect_success 'subdirectory ignore (toplevel)' '
+ (
+ cd top &&
+ git ls-files -o --exclude-standard
+ ) >actual &&
+ >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'subdirectory ignore (l1/l2)' '
+ (
+ cd top/l1/l2 &&
+ git ls-files -o --exclude-standard
+ ) >actual &&
+ >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'subdirectory ignore (l1)' '
+ (
+ cd top/l1 &&
+ git ls-files -o --exclude-standard
+ ) >actual &&
+ >expect &&
+ test_cmp expect actual
+'
+
test_done
--
1.6.6.209.g52296.dirty
^ permalink raw reply related
* Re: [PATCH 0/2] Support relative .git file in a submodule
From: Junio C Hamano @ 2010-01-08 23:09 UTC (permalink / raw)
To: Brad King; +Cc: git, Lars Hjemli
In-Reply-To: <1262990208-15554-1-git-send-email-brad.king@kitware.com>
Brad King <brad.king@kitware.com> writes:
> ... if a submodule
> has a .git file "symlink" with a relative path to the real submodule
> repository then ...
... then I've always thought that is simply a misconfiguration (t0002
seems to use full path for this exact reason). Is there a reason why
relative path should be used/usable here, other than "being able to is
better than not being able to"???
I don't like my process randomly chdir'ing around assuming they can chdir
back safely very much, and would prefer not to add such codepaths unless
absolutely necessary.
^ permalink raw reply
* Re: [PATCH 3/3] base85: Make the code more obvious instead of explaining the non-obvious
From: A Large Angry SCM @ 2010-01-08 23:15 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <1262958000-27181-3-git-send-email-agruen@suse.de>
Andreas Gruenbacher wrote:
> Here is another cleanup ...
>
I LOVE the subject line of this commit!
^ permalink raw reply
* [PATCH] sample pre-commit hook: don't trigger when recording a merge
From: Nanako Shiraishi @ 2010-01-08 23:16 UTC (permalink / raw)
To: git
When recording a merge, even if there are problematic whitespace errors,
let them pass, because the damage has already been done in the history. If
this hook triggers, it will invite a novice to fix such errors in a merge
commit but such a change is not related to the merge. Don't encourage it.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
templates/hooks--pre-commit.sample | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/templates/hooks--pre-commit.sample b/templates/hooks--pre-commit.sample
index 439eefd..66e56bb 100755
--- a/templates/hooks--pre-commit.sample
+++ b/templates/hooks--pre-commit.sample
@@ -7,6 +7,11 @@
#
# To enable this hook, rename this file to "pre-commit".
+if test -f "${GIT_DIR-.git}"/MERGE_HEAD
+then
+ exit 0
+fi
+
if git-rev-parse --verify HEAD >/dev/null 2>&1
then
against=HEAD
--
1.6.6
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: [PATCH 9/9] rerere forget path: forget recorded resolution
From: Junio C Hamano @ 2010-01-08 23:20 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <201001082255.51499.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> Your implementation forgets to re-insert the forgotten resolutions into
> MERGE_RR, therefore, the next 'git rerere' does not record the new
> resolution.
>
> In my implementation of 'rerere forget', I had the following tests.
Please filfre to roll a patch that adds the tests and code that inserts
necessary MERGE_RR entries, if the feature is pressing; unfortunately I
don't think I will have much git time during the coming weekend.
^ permalink raw reply
* Re: [PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax
From: A Large Angry SCM @ 2010-01-08 23:21 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Avery Pennarun, Junio C Hamano, Nanako Shiraishi,
Johannes Schindelin, git
In-Reply-To: <fabb9a1e1001081237n11fa61b5m63fa46fac2ad8d4a@mail.gmail.com>
Sverre Rabbelier wrote:
> Heya,
>
> On Fri, Jan 8, 2010 at 15:31, Avery Pennarun <apenwarr@gmail.com> wrote:
>> Thanks, I didn't know about that one. But my general point is still:
>> we seem to have two implementations when the functionality of one is
>> actually a superset of the other. As far as I can see, anyway. So
>> the obvious way to reduce the duplicated code is to simply eliminate
>> the less-featureful implementation.
>
> *cough* git sequencer *cough*
>
*cough* not in my ${PATH} *cough*
^ permalink raw reply
* Re: [PATCH 0/2] Support relative .git file in a submodule
From: Avery Pennarun @ 2010-01-08 23:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brad King, git, Lars Hjemli
In-Reply-To: <7vocl4urc6.fsf@alter.siamese.dyndns.org>
On Fri, Jan 8, 2010 at 6:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Brad King <brad.king@kitware.com> writes:
>
>> ... if a submodule
>> has a .git file "symlink" with a relative path to the real submodule
>> repository then ...
>
> ... then I've always thought that is simply a misconfiguration (t0002
> seems to use full path for this exact reason). Is there a reason why
> relative path should be used/usable here, other than "being able to is
> better than not being able to"???
If I have a bunch of git repos in ~/src, and I decide I'd rather
rename it all to ~/source, it seems like it would be nice for all my
links not to be broken. This sort of thing can also happen if you
have NFS-mounted home directories on a farm of machines, and some of
them automount in /u/username and others use /home/username, for
example. I think this is the same reason that common sysadmin advice
is to use relative symlinks instead of absolute links.
This problem seems especially true with submodules. If the
submodule's repo is something like supermodule/.git/submodule.git, a
relative path would almost always be a appropriate, no?
Have fun,
Avery
^ 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