* Re: [PATCH 1/2] Introduces xmkstemp()
From: Johannes Sixt @ 2007-08-31 8:49 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: git
In-Reply-To: <46D7D48D.6000503@trolltech.com>
Marius Storm-Olsen schrieb:
> Just wanted to let the original author know, so he would be aware of it,
> and we wouldn't have to go the extra round-trips with patches to fix
> patches. (And for MinGW awareness when adding code to git-compat-util.h)
You can't expect a lot of MinGW awareness from non-MinGW users when they
make changes to git-compat-util.h since upstream does not have _any_
references to MinGW there, yet.
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/2] Introduces xmkstemp()
From: Marius Storm-Olsen @ 2007-08-31 8:42 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Luiz Fernando N. Capitulino, Junio C Hamano, git
In-Reply-To: <46D7D284.30004@telecom.at>
[-- Attachment #1: Type: text/plain, Size: 673 bytes --]
Johannes Sixt said the following on 31.08.2007 10:34:
> Marius Storm-Olsen schrieb:
>> This functions needs to be further down in the file for MinGW
>> builds, since mkstemp() is forward declared later in the file.
>> So, something like this:
>
> Please consider using the lates MinGW port. It's already fixed
> there.
Right. (That's the whole 4msysgit.git mingw.git discussion on the
msysgit mailinglist these days)
Just wanted to let the original author know, so he would be aware of
it, and we wouldn't have to go the extra round-trips with patches to
fix patches. (And for MinGW awareness when adding code to
git-compat-util.h)
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH] fix parallel make problem
From: Junio C Hamano @ 2007-08-31 8:36 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git
In-Reply-To: <20070831081517.GB17637@mellanox.co.il>
"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
>> Quoting Junio C Hamano <gitster@pobox.com>:
>> Subject: Re: [PATCH] fix parallel make problem
>>
>> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
>>
>> >> +.PRECIOUS: $(patsubst test-%$X,test-%.o,$(TEST_PROGRAMS))
>> >> +
>> >> test-%$X: test-%.o $(GITLIBS)
>> >> $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
>> >
>> > Add a comment here?
>>
>> I did not see a particular need for that. What would you say
>> there?
>
> That it's a work-around for make bug.
I would agree it is a make bug to barf like what we saw. Even
though we allowed it to treat test-%.o files as intermediate
products and allowed them to be removed, it is not a good excuse
for make to forget rebuilding them.
But I also happen to think not marking test-%.o as precious was
a bug on our side. We would want to keep the build by-product
to avoid recompilation, don't we? And this additional line is
primarily about fixing that bug, which works the bug around as a
side effect.
> So how did this end up in your mail?
Because it is not a format-patch output.
I often run "git diff --stat -p HEAD" from inside MUA in order
to get the patch from my work tree, write a proposed commit
message, and then reset the change away without committing after
sending that message (yes I do not need "git stash" --- gmane
and vger are my stashes, Mwhhhaaaa).
^ permalink raw reply
* Re: [PATCH 1/2] Introduces xmkstemp()
From: Johannes Sixt @ 2007-08-31 8:34 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Luiz Fernando N. Capitulino, Junio C Hamano, git
In-Reply-To: <46D7D0F7.1050302@trolltech.com>
Marius Storm-Olsen schrieb:
> This functions needs to be further down in the file for
> MinGW builds, since mkstemp() is forward declared later
> in the file. So, something like this:
Please consider using the lates MinGW port. It's already fixed there.
-- Hannes
^ permalink raw reply
* [PATCH 01/14] gitweb: get remotes too when getting heads list
From: Giuseppe Bilotta @ 2007-08-31 8:32 UTC (permalink / raw)
To: git; +Cc: Giuseppe Bilotta
In-Reply-To: <favitdff@sea.gmane.org>
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b2bae1b..65953db 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2063,7 +2063,7 @@ sub git_get_heads_list {
open my $fd, '-|', git_cmd(), 'for-each-ref',
($limit ? '--count='.($limit+1) : ()), '--sort=-committerdate',
'--format=%(objectname) %(refname) %(subject)%00%(committer)',
- 'refs/heads'
+ 'refs/heads', 'refs/remotes'
or return;
while (my $line = <$fd>) {
my %ref_item;
@@ -2073,8 +2073,9 @@ sub git_get_heads_list {
my ($hash, $name, $title) = split(' ', $refinfo, 3);
my ($committer, $epoch, $tz) =
($committerinfo =~ /^(.*) ([0-9]+) (.*)$/);
- $name =~ s!^refs/heads/!!;
+ $name =~ s!^refs/(head|remote)s/!!;
+ $ref_item{'class'} = $1;
$ref_item{'name'} = $name;
$ref_item{'id'} = $hash;
$ref_item{'title'} = $title || '(no commit message)';
--
1.5.2.5
^ permalink raw reply related
* Re: [PATCH 1/2] Introduces xmkstemp()
From: Marius Storm-Olsen @ 2007-08-31 8:27 UTC (permalink / raw)
To: Luiz Fernando N. Capitulino; +Cc: Junio C Hamano, git
In-Reply-To: <20070814164453.400b9c55@localhost>
[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]
Luiz Fernando N. Capitulino said the following on 14.08.2007 21:44:
> This is a wrapper for mkstemp() that performs error checking and
> calls die() when an error occur.
>
> Signed-off-by: Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>
> ---
> git-compat-util.h | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 362e040..ca0a597 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -303,6 +303,16 @@ static inline FILE *xfdopen(int fd, const char *mode)
> return stream;
> }
>
> +static inline int xmkstemp(char *template)
> +{
> + int fd;
> +
> + fd = mkstemp(template);
> + if (fd < 0)
> + die("Unable to create temporary file: %s", strerror(errno));
> + return fd;
> +}
> +
> static inline size_t xsize_t(off_t len)
> {
> return (size_t)len;
This functions needs to be further down in the file for
MinGW builds, since mkstemp() is forward declared later
in the file. So, something like this:
diff --git a/git-compat-util.h b/git-compat-util.h
index 9e075b7..f9ba8b0 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -477,4 +477,14 @@ extern __attribute__((noreturn)) int git_exit(int code);
#endif /* __MINGW32__ */
+static inline int xmkstemp(char *template)
+{
+ int fd;
+
+ fd = mkstemp(template);
+ if (fd < 0)
+ die("Unable to create temporary file: %s", strerror(errno));
+ return fd;
+}
+
#endif
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply related
* Re: [PATCH] autodetect core.symlinks in git-init
From: Marius Storm-Olsen @ 2007-08-31 8:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git mailing list, Stephen Cuppett, Nanako Shiraishi
In-Reply-To: <7vodgo2moe.fsf_-_@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 579 bytes --]
Junio C Hamano said the following on 31.08.2007 09:22:
> We already autodetect if filemode is reliable on the filesystem
> to deal with VFAT and friends. Do the same for symbolic link
> support.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> + if (!close(xmkstemp(path)) &&
Just tried this with 4msysgit (so, MinGW on Windows), and with a patch
for adding xmkstemp() to git-compat-util.h, this patch works perfectly
on Windows. It's obviously the right thing to do.
Acked-by: Marius Storm-Olsen <mstormo_git@storm-olsen.com>
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH] fix parallel make problem
From: Michael S. Tsirkin @ 2007-08-31 8:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, git
In-Reply-To: <7vabs82kcq.fsf@gitster.siamese.dyndns.org>
> Quoting Junio C Hamano <gitster@pobox.com>:
> Subject: Re: [PATCH] fix parallel make problem
>
> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
>
> >> +.PRECIOUS: $(patsubst test-%$X,test-%.o,$(TEST_PROGRAMS))
> >> +
> >> test-%$X: test-%.o $(GITLIBS)
> >> $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
> >
> > Add a comment here?
>
> I did not see a particular need for that. What would you say
> there?
That it's a work-around for make bug.
> >> Warning: 1 path touched but unmodified. Consider running git-status.
> >
> > BTW, shouldn't the warning go to standard error?
>
> No, usually you are under PAGER, so we need to send this to
> stdout. We do this only when we are generating textual diff
> which will be consumed by patch or git-apply. They both know
> how to ignore such a non patch material.
So how did this end up in your mail?
--
MST
^ permalink raw reply
* Re: [PATCH] fix parallel make problem
From: Junio C Hamano @ 2007-08-31 8:12 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git
In-Reply-To: <20070831080651.GA17637@mellanox.co.il>
"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
>> +.PRECIOUS: $(patsubst test-%$X,test-%.o,$(TEST_PROGRAMS))
>> +
>> test-%$X: test-%.o $(GITLIBS)
>> $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
>
> Add a comment here?
I did not see a particular need for that. What would you say
there?
>> Warning: 1 path touched but unmodified. Consider running git-status.
>
> BTW, shouldn't the warning go to standard error?
No, usually you are under PAGER, so we need to send this to
stdout. We do this only when we are generating textual diff
which will be consumed by patch or git-apply. They both know
how to ignore such a non patch material.
^ permalink raw reply
* Re: [PATCH] fix parallel make problem
From: Michael S. Tsirkin @ 2007-08-31 8:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, git
In-Reply-To: <7vmyw85uml.fsf@gitster.siamese.dyndns.org>
> Quoting Junio C Hamano <gitster@pobox.com>:
> Subject: Re: [PATCH] fix parallel make problem
>
> How about this as a replacement? I notice that after a
> successful build all the test-*.o files are removed by make, and
> somehow make seems to believe it is Ok not to recreate them.
Yea. this works for me.
> ---
> Makefile | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 4eb4637..51af531 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -969,6 +969,8 @@ test-date$X: date.o ctype.o
>
> test-delta$X: diff-delta.o patch-delta.o
>
> +.PRECIOUS: $(patsubst test-%$X,test-%.o,$(TEST_PROGRAMS))
> +
> test-%$X: test-%.o $(GITLIBS)
> $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
Add a comment here?
> Warning: 1 path touched but unmodified. Consider running git-status.
BTW, shouldn't the warning go to standard error?
--
MST
^ permalink raw reply
* Re: [PATCH] autodetect core.symlinks in git-init
From: Nanako Shiraishi @ 2007-08-31 8:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git mailing list, Stephen Cuppett
In-Reply-To: <7vodgo2moe.fsf_-_@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> We already autodetect if filemode is reliable on the filesystem
> to deal with VFAT and friends. Do the same for symbolic link
> support.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> * The earlier one left the test symlink behind after testing is
> complete. Embarrassing...
>
> builtin-init-db.c | 15 +++++++++++++++
> 1 files changed, 15 insertions(+), 0 deletions(-)
Thank you for a quick patch. I was about to report that leftover test
file as a bug. Do you ever sleep? I am always amazed how quickly any
potential issue raised on the mailing list is resolved.
With this patch my "git init" in a pendrive correctly says "[core]
symlinks = false".
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
----------------------------------------------------------------------
Get a free email account with anti spam protection.
http://www.bluebottle.com/tag/2
^ permalink raw reply
* Re: gitk from subdirectory
From: Junio C Hamano @ 2007-08-31 7:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Mackerras, git
In-Reply-To: <alpine.LFD.0.999.0708310038080.25853@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 30 Aug 2007, Junio C Hamano wrote:
>
>> "git log" family of commands, even when run from a subdirectory,
>> do not limit the revision range with the current directory as
>> the path limiter, but with double-dash without any paths after
>> it, i.e. "git log --" do so. It was a mistake to have a
>> difference between "git log --" and "git log" introduced in
>> commit ae563542bf10fa8c33abd2a354e4b28aca4264d7 (First cut at
>> libifying revlist generation).
>>
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> Looks obviously correct.
>
> Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Thanks.
^ permalink raw reply
* Re: gitk from subdirectory
From: Linus Torvalds @ 2007-08-31 7:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git
In-Reply-To: <7vejhk45q5.fsf@gitster.siamese.dyndns.org>
On Thu, 30 Aug 2007, Junio C Hamano wrote:
> "git log" family of commands, even when run from a subdirectory,
> do not limit the revision range with the current directory as
> the path limiter, but with double-dash without any paths after
> it, i.e. "git log --" do so. It was a mistake to have a
> difference between "git log --" and "git log" introduced in
> commit ae563542bf10fa8c33abd2a354e4b28aca4264d7 (First cut at
> libifying revlist generation).
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Looks obviously correct.
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus
^ permalink raw reply
* [PATCH] autodetect core.symlinks in git-init
From: Junio C Hamano @ 2007-08-31 7:22 UTC (permalink / raw)
To: Git mailing list; +Cc: Stephen Cuppett, Nanako Shiraishi
In-Reply-To: <7vveaw2na9.fsf@gitster.siamese.dyndns.org>
We already autodetect if filemode is reliable on the filesystem
to deal with VFAT and friends. Do the same for symbolic link
support.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* The earlier one left the test symlink behind after testing is
complete. Embarrassing...
builtin-init-db.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index af15cb2..763fa55 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -264,6 +264,21 @@ static int create_default_files(const char *git_dir, const char *template_path)
if (work_tree != git_work_tree_cfg)
git_config_set("core.worktree", work_tree);
}
+
+ /* Check if symlink is supported in the work tree */
+ if (!reinit) {
+ path[len] = 0;
+ strcpy(path + len, "tXXXXXX");
+ if (!close(xmkstemp(path)) &&
+ !unlink(path) &&
+ !symlink("testing", path) &&
+ !lstat(path, &st1) &&
+ S_ISLNK(st1.st_mode))
+ unlink(path); /* good */
+ else
+ git_config_set("core.symlinks", "false");
+ }
+
return reinit;
}
^ permalink raw reply related
* Re: [RFC] Change handling of RelNotes
From: Junio C Hamano @ 2007-08-31 7:09 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Stephen Cuppett, Git mailing list
In-Reply-To: <200708310645.l7V6jKJk009287@mi0.bluebottle.com>
Nanako Shiraishi <nanako3@bluebottle.com> writes:
> I sometimes have a checkout on a filesystem that does not support
> symbolic links, but I set core.symlink configuration variable to false
> in such a case. Would it make sense to update "git init" to autodetect
> lack of symbolic link support in the filesystem?
Hmph. Something along this line, perhaps?
builtin-init-db.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index af15cb2..c411008 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -264,6 +264,22 @@ static int create_default_files(const char *git_dir, const char *template_path)
if (work_tree != git_work_tree_cfg)
git_config_set("core.worktree", work_tree);
}
+
+ /* Check if symlink is supported in the work tree */
+ if (!reinit) {
+ path[len] = 0;
+ strcpy(path + len, "tXXXXXX");
+
+ if (!close(xmkstemp(path)) &&
+ !unlink(path) &&
+ !symlink("testing", path) &&
+ !lstat(path, &st1) &&
+ S_ISLNK(st1.st_mode))
+ ; /* good */
+ else
+ git_config_set("core.symlinks", "false");
+ }
+
return reinit;
}
^ permalink raw reply related
* Re: [RFC] Change handling of RelNotes
From: Nanako Shiraishi @ 2007-08-31 6:44 UTC (permalink / raw)
To: Stephen Cuppett; +Cc: Git mailing list
In-Reply-To: <316a20a40708301835hc4236d4tdb289b6f705ab86@mail.gmail.com>
Quoting "Stephen Cuppett" <cuppett@gmail.com>:
> I propose we eliminate this symlink.
Maybe it is just me, but you do not sound like you are proposing to do
anything yourself. You are simply demanding Junio to change the way he
works. Instead of being able to edit RelNotes at the toplevel, relying
on the symbolic link to let him edit the right file, you are forcing him
to edit the appropriate file in Documentation/ directory.
Shouldn't you have at least said "I request" instead?
I sometimes have a checkout on a filesystem that does not support
symbolic links, but I set core.symlink configuration variable to false
in such a case. Would it make sense to update "git init" to autodetect
lack of symbolic link support in the filesystem?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
----------------------------------------------------------------------
Free pop3 email with a spam filter.
http://www.bluebottle.com/tag/5
^ permalink raw reply
* Re: [PATCH] git-filter-branch: document --original option
From: David Kastrup @ 2007-08-31 6:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Giuseppe Bilotta, git, Johannes Schindelin
In-Reply-To: <7v3ay07h0h.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> I agree we do not give the "portable to version 7" prize
>> anymore. But you made me realize another thing.
>>
>> I think it should make sure orig_namespace has one and only one
>> trailing slash, because otherwise "--original refs/heads//"
>> would lead you to the same disaster.
>
> Perhaps,
>
> orig_namespace=$(expr "$OPTARG/" : '\(.*[^/]\)/*$')/
>
See separate proposal which I find still prettier (and which does not
fork).
But I really don't think we should bend over backwards: multiple end
slashes have explicit manual origin. People deserve what they get
then.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] git-filter-branch: document --original option
From: David Kastrup @ 2007-08-31 6:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Giuseppe Bilotta, git, Johannes Schindelin
In-Reply-To: <7vodgo7jbn.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>> ...
>>> --original)
>>> + case "$OPTARG" in */) ;; *) OPTARG="$OPTARG/" ;; esac
>>> orig_namespace="$OPTARG"
>>> ;;
>>> *)
>>
>> orig_namespace="${OPTARG%/}/"
>>
>> Sure, it does not win the "portable to Version 7" price, but our
>> scripts don't do that, anyway.
>
> I agree we do not give the "portable to version 7" prize
> anymore. But you made me realize another thing.
>
> I think it should make sure orig_namespace has one and only one
> trailing slash, because otherwise "--original refs/heads//"
> would lead you to the same disaster.
I am not sure we should bend over backwards to people courting
disaster. Completion does not add double slashes, and that's the most
common cause for spurious slashes. And I don't know an equally
straightforward way to remove multiple slashes at the end.
do orig_namespace="$OPTARG";OPTARG="${OPTARG%/}/"
while test "X${orig_namespace}" != "X${OPTARG}"
is not really all too pretty.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [RFC] Change handling of RelNotes
From: Marius Storm-Olsen @ 2007-08-31 6:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Cuppett, git
In-Reply-To: <7vejhk5tr0.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]
Junio C Hamano said the following on 31.08.2007 04:21:
> "Stephen Cuppett" <cuppett@gmail.com> writes:
>> I went to clone git onto a memory stick today. The default fs on
>> the sticks doesn't support symlinks. After looking a little bit,
>> the only symlink I can see in the source tree is RelNotes. It
>> appears when going to a new release the file gets created in
>> /Documentation and the symlink updated.
>
> Well, I hope you do not compile nor checkout git onto a memory
> stick but use it as just a sneakernet medium.
>
> If that is the case why should it matter if the contents tracked
> has symlinks?
Well, you have the same thing on Windows, of course. Where the first
time you try to clone git.git, it reports the RelNotes symlink.
So, at first you think, "Hmm, that just seems broken"; till you
discover core.symlinks=false, and set that globally, and every thing
works.
So, as a Windows user you always have that option set to false; but
you have to discover it first. I can see it being a problem on Linux,
mounting a memorystick, and then trying to clone git.git to it. Your
inclination to discover core.symlinks=false is not as high, I guess.
And since it's certainly nothing you'd want in your global config, it
might take some time before you realize that the correct way of
cloning it for a memorystick is in fact:
git clone -n git://repo.or.cz/git.git
(and if you'd want it checked out too)
cd git
git config core.symlinks false
git checkout
Maybe we should consider having Git detect the underlying FS's
capabilities when cloning, and set core.symlinks to the correct value?
(You'll have to manually adjust it if you just 'cp' it to another FS,
that's as expected.)
^shrug^
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [RFC] Change handling of RelNotes
From: Junio C Hamano @ 2007-08-31 6:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: Stephen Cuppett, git
In-Reply-To: <20070831013935.GM1219@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> On Fri, Aug 31, 2007 at 03:35:36AM CEST, Stephen Cuppett wrote:
>> With this one abnormality the git repo on a normal flash drive doesn't
>> work... at least in my case.
>
> Wouldn't it be better to minimalize the restriction imposed to you by
> git in case you are working on a filesystem that doesn't support
> symlinks? Let's say that in that case Git will keep the symlink only in
> the index... (And perhaps warn.)
Didn't we already add support for Cygwin/MinGW in the form of
core.symlinks configuration item?
I just did this:
$ git clone -l -s -n git.git victim-005
$ cd victim-005
$ git config core.symlinks false
$ git checkout
^ permalink raw reply
* Re: gitk from subdirectory
From: Junio C Hamano @ 2007-08-31 5:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Linus Torvalds, git
In-Reply-To: <7vejhk45q5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "git log" family of commands, even when run from a subdirectory,
> do not limit the revision range with the current directory as
> the path limiter, but with double-dash without any paths after
> it, i.e. "git log --" do so. It was a mistake to have a
> difference between "git log --" and "git log" introduced in
> commit ae563542bf10fa8c33abd2a354e4b28aca4264d7 (First cut at
> libifying revlist generation).
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In case it was not obvious, this patch is meant to make the
previous patch from me to change gitk unneeded.
^ permalink raw reply
* Re: gitk from subdirectory
From: Junio C Hamano @ 2007-08-31 5:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Mackerras, git
In-Reply-To: <alpine.LFD.0.999.0708302200160.25853@woody.linux-foundation.org>
"git log" family of commands, even when run from a subdirectory,
do not limit the revision range with the current directory as
the path limiter, but with double-dash without any paths after
it, i.e. "git log --" do so. It was a mistake to have a
difference between "git log --" and "git log" introduced in
commit ae563542bf10fa8c33abd2a354e4b28aca4264d7 (First cut at
libifying revlist generation).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
revision.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/revision.c b/revision.c
index 51fff0e..c193c3e 100644
--- a/revision.c
+++ b/revision.c
@@ -896,7 +896,8 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
continue;
argv[i] = NULL;
argc = i;
- revs->prune_data = get_pathspec(revs->prefix, argv + i + 1);
+ if (argv[i + 1])
+ revs->prune_data = get_pathspec(revs->prefix, argv + i + 1);
seen_dashdash = 1;
break;
}
^ permalink raw reply related
* Re: gitk from subdirectory
From: Junio C Hamano @ 2007-08-31 5:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Mackerras, git
In-Reply-To: <7vsl6046gn.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> I realize that the "--" behaviour of git log was intentional, but seeing
>> what it results in I think the intention was good, but stupid.
>
> I haven't finished analysis yet, but I was reaching the same
> conclusion.
>
> v1.2.0 used to limit "git rev-list" to the current working
> directory, v1.3.0 and newer does not. But they do when "--" is
> given. This makes it impossible to do:
>
> cd Documentation
> echo >master
> git rev-list master
> ... get "ambiguous -- which do you mean? rev, or
> ... limited to path?" error message
> git rev-list master --
> ... I do mean unlimited and dig from 'master'
FWIW bisect points at your commit ae563542bf10fa8c33abd2a354e4b28aca4264d7
(First cut at libifying revlist generation) ;-).
^ permalink raw reply
* Re: gitk from subdirectory
From: Junio C Hamano @ 2007-08-31 5:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Mackerras, git
In-Reply-To: <alpine.LFD.0.999.0708302200160.25853@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 30 Aug 2007, Junio C Hamano wrote:
>>
>> I am wondering if this was intended behaviour change. I think
>> it makes sense to want an easy way to say "what changed stuff in
>> the directory I am in?" because presumably you are there because
>> you are interested in stuff in there. But if you hard code "--"
>> it is not easy to disable that and get the global log.
>
> Hmm. My reaction to this would be that it was a mistake to have a
> difference between
>
> git log --
>
> and
>
> git log
>
> and that we should instead fix this at the argument parsing level.
>
> And then anybody who depended on the old "--" behaviour can just add a "."
> at the end.
>
> That way there are no special cases.
>
> I realize that the "--" behaviour of git log was intentional, but seeing
> what it results in I think the intention was good, but stupid.
I haven't finished analysis yet, but I was reaching the same
conclusion.
v1.2.0 used to limit "git rev-list" to the current working
directory, v1.3.0 and newer does not. But they do when "--" is
given. This makes it impossible to do:
cd Documentation
echo >master
git rev-list master
... get "ambiguous -- which do you mean? rev, or
... limited to path?" error message
git rev-list master --
... I do mean unlimited and dig from 'master'
^ permalink raw reply
* Re: gitk from subdirectory
From: Linus Torvalds @ 2007-08-31 5:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git
In-Reply-To: <7vabs85ntg.fsf@gitster.siamese.dyndns.org>
On Thu, 30 Aug 2007, Junio C Hamano wrote:
>
> I am wondering if this was intended behaviour change. I think
> it makes sense to want an easy way to say "what changed stuff in
> the directory I am in?" because presumably you are there because
> you are interested in stuff in there. But if you hard code "--"
> it is not easy to disable that and get the global log.
Hmm. My reaction to this would be that it was a mistake to have a
difference between
git log --
and
git log
and that we should instead fix this at the argument parsing level.
And then anybody who depended on the old "--" behaviour can just add a "."
at the end.
That way there are no special cases.
I realize that the "--" behaviour of git log was intentional, but seeing
what it results in I think the intention was good, but stupid.
Linus
^ 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