* [PATCH] Don't write directly to a make target ($@).
From: Jim Meyering @ 2006-05-25 13:32 UTC (permalink / raw)
To: git
Otherwise, if make is suspended, or killed with prejudice, or if the
system crashes, you could be left with an up-to-date, yet corrupt,
generated file.
---
Makefile | 34 ++++++++++++++++++++--------------
1 files changed, 20 insertions(+), 14 deletions(-)
59fd5cb51824364100cacd92f1ca4674853a13a8
diff --git a/Makefile b/Makefile
index dbf19c6..3af3187 100644
--- a/Makefile
+++ b/Makefile
@@ -496,37 +496,43 @@ builtin-help.o: common-cmds.h
rm -f $@ && ln git$X $@
common-cmds.h: Documentation/git-*.txt
- ./generate-cmdlist.sh > $@
+ ./generate-cmdlist.sh > t$@
+ mv t$@ $@
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
- rm -f $@
+ rm -f $@ t$@
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
-e 's/@@NO_PYTHON@@/$(NO_PYTHON)/g' \
- $@.sh >$@
- chmod +x $@
+ $@.sh >t$@
+ chmod +x t$@
+ mv t$@ $@
$(patsubst %.perl,%,$(SCRIPT_PERL)) : % : %.perl
- rm -f $@
+ rm -f $@ t$@
sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
- $@.perl >$@
- chmod +x $@
+ $@.perl >t$@
+ chmod +x t$@
+ mv t$@ $@
$(patsubst %.py,%,$(SCRIPT_PYTHON)) : % : %.py
- rm -f $@
+ rm -f $@ t$@
sed -e '1s|#!.*python|#!$(PYTHON_PATH_SQ)|' \
-e 's|@@GIT_PYTHON_PATH@@|$(GIT_PYTHON_DIR_SQ)|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
- $@.py >$@
- chmod +x $@
+ $@.py >t$@
+ chmod +x t$@
+ mv t$@ $@
git-cherry-pick: git-revert
- cp $< $@
+ cp $< t$@
+ mv t$@ $@
git-status: git-commit
- cp $< $@
+ cp $< t$@
+ mv t$@ $@
# These can record GIT_VERSION
git$X git.spec \
@@ -653,7 +659,8 @@ install-doc:
### Maintainer's dist rules
git.spec: git.spec.in
- sed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > $@
+ sed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > t$@
+ mv t$@ $@
GIT_TARNAME=git-$(GIT_VERSION)
dist: git.spec git-tar-tree
@@ -724,4 +731,3 @@ check-docs::
*) echo "no link: $$v";; \
esac ; \
done | sort
-
--
1.3.2
^ permalink raw reply related
* Re: parsecvs fails
From: Lars Johannsen @ 2006-05-25 14:04 UTC (permalink / raw)
To: git; +Cc: Aneesh Kumar
In-Reply-To: <cc723f590605250432r7dd0b75xe5ff17b11da06e3c@mail.gmail.com>
On (25/05/06 17:02), Aneesh Kumar wrote:
> The tagging used by the repository given below is quiet complex.
> But it can be used as a test case for all the cvs to git converter.
> Even ViewVC and ViewCVS doesn't work with this repository.
>
> Any help in converting it to git ?
>
> rsync -av rsync://ci-linux.cvs.sourceforge.net/cvsroot/ci-linux/ci/
> ci-linux/ci/
>
> -aneesh
Well it seems like most of your ,v files contains tags refering to version 1
and yet the first version in the files is 1.1
So to fix for parsecvs ( and maybe for viewcvs) i think you need to fix
all symbols at 'top of file' for all ,v files. Change from v1 to v1.1
with something like sed ',/@#/s/:1*$/:1.1/;,/@#/s/:1;*$/:1.1;/'
--
Lars
^ permalink raw reply
* bogus "fatal: Not a git repository"
From: Linus Torvalds @ 2006-05-25 15:22 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano, Johannes Schindelin
I was just testing that "git ls-remote" change by Junio, and when you're
not in a git repository, it gives this totally bogus warning. The _target_
obviously has to be a git repository, but there's no reason why you'd have
to be in a local git repo when doing an ls-remote.
The reason is commit 73136b2e8a8ee024320c5ac6a0f14f912432bf03 by Dscho: it
adds calls to git-repo-config in git-parse-remote.sh to get the remote
shorthands etc.
Now, either we should just hide and ignore the error from git-repo-config
(probably bad, because some errors _are_ valid - like git-repo-config
failing due to bad syntax in the config file), or we should just make
git-repo-config quietly handle the case of not being in a git repository.
This does the latter: just quietly accepting (and doing nothing - trying
to set a value will result in the lock-file failing) our lot in life
sounds better than dying with a bogus error message.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/repo-config.c b/repo-config.c
index 127afd7..08fc4cc 100644
--- a/repo-config.c
+++ b/repo-config.c
@@ -108,7 +108,8 @@ static int get_value(const char* key_, c
int main(int argc, const char **argv)
{
- setup_git_directory();
+ int nongit = 0;
+ setup_git_directory_gently(&nongit);
while (1 < argc) {
if (!strcmp(argv[1], "--int"))
^ permalink raw reply related
* Re: file name case-sensitivity issues
From: Alex Riesen @ 2006-05-25 15:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j4c4af3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Wed, May 24, 2006 00:57:04 +0200:
> I'd call that a PEBCAK.
It is not solvable there though.
> If you _know_ you are working on a case challenged filesystem, I
> think the best thing you can do is not to work on a project that
> has files in different cases on such a filesystem.
That is seldom an acceptable suggestion. Besides, how about when you
don't _know_, like when cloning onto an usb-stick mounted with
auto-detection? Will the files with case-different names just
overwrite each other?
^ permalink raw reply
* Re: [PATCH] Don't write directly to a make target ($@).
From: Junio C Hamano @ 2006-05-25 16:28 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <87hd3e5ixw.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> writes:
> Otherwise, if make is suspended, or killed with prejudice, or if the
> system crashes, you could be left with an up-to-date, yet corrupt,
> generated file.
Thanks. Maybe you would want a "make clean" target for them too
if you do this. I often use $@+ instead of t$@ so that I can
say "rm -f *+" there.
> @@ -496,37 +496,43 @@ builtin-help.o: common-cmds.h
> rm -f $@ && ln git$X $@
>
> common-cmds.h: Documentation/git-*.txt
> - ./generate-cmdlist.sh > $@
> + ./generate-cmdlist.sh > t$@
> + mv t$@ $@
>
IOW, like this:
common-cmds.h: Documentation/git-*.txt
rm -f $@+ $@
./generate-cmdlist.sh > $@+
mv $@+ $@
clean::
rm -f *+
^ permalink raw reply
* Re: [PATCH] Don't write directly to a make target ($@).
From: Timo Hirvonen @ 2006-05-25 16:41 UTC (permalink / raw)
To: git; +Cc: jim, git
In-Reply-To: <7vejyixe5g.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Jim Meyering <jim@meyering.net> writes:
>
> > Otherwise, if make is suspended, or killed with prejudice, or if the
> > system crashes, you could be left with an up-to-date, yet corrupt,
> > generated file.
>
> Thanks. Maybe you would want a "make clean" target for them too
> if you do this. I often use $@+ instead of t$@ so that I can
> say "rm -f *+" there.
>
> > @@ -496,37 +496,43 @@ builtin-help.o: common-cmds.h
> > rm -f $@ && ln git$X $@
> >
> > common-cmds.h: Documentation/git-*.txt
> > - ./generate-cmdlist.sh > $@
> > + ./generate-cmdlist.sh > t$@
> > + mv t$@ $@
> >
>
> IOW, like this:
>
> common-cmds.h: Documentation/git-*.txt
> rm -f $@+ $@
> ./generate-cmdlist.sh > $@+
> mv $@+ $@
>
> clean::
> rm -f *+
Or just use one tmp file, i.e. ".tmp" instead of t$@.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH] Don't write directly to a make target ($@).
From: Jim Meyering @ 2006-05-25 16:42 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060525194125.9380842a.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> wrote:
> Or just use one tmp file, i.e. ".tmp" instead of t$@.
Argh, no.
That'd fail big time with parallel builds.
^ permalink raw reply
* Re: [PATCH] Don't write directly to a make target ($@).
From: Jim Meyering @ 2006-05-25 16:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejyixe5g.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Jim Meyering <jim@meyering.net> writes:
>
>> Otherwise, if make is suspended, or killed with prejudice, or if the
>> system crashes, you could be left with an up-to-date, yet corrupt,
>> generated file.
>
> Thanks. Maybe you would want a "make clean" target for them too
> if you do this. I often use $@+ instead of t$@ so that I can
> say "rm -f *+" there.
I chose a prefix rather than a suffix, so that if git is built on a file
system with unreasonable file name length limitations, the prefix will
distinguish the temporary from the target; in that situation, a suffixed
temporary name could map to the target name.
However, assuming reasonable file name length limits, using a suffix is
generally better, since it works even when the target is an absolute
name. Adding a prefix obviously won't work with an absolute name.
I'm happy to ignore 14-byte(and 8.3)-limited file systems and
go with a suffix, if you still prefer that. New patch coming up.
^ permalink raw reply
* git-cvsserver wart?
From: Cameron McBride @ 2006-05-25 16:42 UTC (permalink / raw)
To: git
I'm a new git user, so if I'm doing something boneheaed - sharp kicks
are welcome.
For reasons I won't go into, the ability to use cvs clients is darn
near crucial. Although most development is local (where I install /
use git), pulling down the latest updates and pushing up minor changes
via CVS is helpful at remote locations where I don't want to maintain
clients. Git with git-cvsserver makes this very nice. Thanks to
all!
Now, the problem I ran into:
code/ntropy> cvs up
Can't use an undefined value as an ARRAY reference at
/usr/local/bin/git-cvsserver line 761.
closing dbh with active statement handles
cvs [update aborted]: end of file from server (consult above messages if any)
code/ntropy> cvs -v
Concurrent Versions System (CVS) 1.11.1p1 (client/server)
Doing a 'cvs up -dP' (or either of the two individually) seems to work fine.
so, it's an old client, a newer client doesn't have this problem. a
bare 'cvs up' works fine on:
Concurrent Versions System (CVS) 1.11.17 (client/server)
Just to be clear, it appears everything gets updated with the
workaround - but there might be something else amiss, so I thought it
was worth mentioning.
Cameron
p.s. I'm assuming the following statement is harmless (it's always present):
closing dbh with active statement handles
^ permalink raw reply
* Re: [PATCH] Don't write directly to a make target ($@).
From: Jim Meyering @ 2006-05-25 16:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejyixe5g.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Jim Meyering <jim@meyering.net> writes:
>
>> Otherwise, if make is suspended, or killed with prejudice, or if the
>> system crashes, you could be left with an up-to-date, yet corrupt,
>> generated file.
>
> Thanks. Maybe you would want a "make clean" target for them too
> if you do this. I often use $@+ instead of t$@ so that I can
> say "rm -f *+" there.
>
>> @@ -496,37 +496,43 @@ builtin-help.o: common-cmds.h
>> rm -f $@ && ln git$X $@
>>
>> common-cmds.h: Documentation/git-*.txt
>> - ./generate-cmdlist.sh > $@
>> + ./generate-cmdlist.sh > t$@
>> + mv t$@ $@
>>
>
> IOW, like this:
>
> common-cmds.h: Documentation/git-*.txt
> rm -f $@+ $@
> ./generate-cmdlist.sh > $@+
> mv $@+ $@
>
> clean::
> rm -f *+
I've included a revised patch below.
I left off the `clean' addition, because I believe "make clean" should
not remove wildcard patterns like "*+", on the off-chance that someone
uses names like that for files they care about. Besides, in practice,
those temporary files are left behind so rarely that they're not a bother,
and they're removed again as part of the next build.
---------
Subject: [PATCH] Don't write directly to a make target ($@). Update atomically.
Otherwise, if make is killed with prejudice, or if the system crashes,
you could be left with an up-to-date, yet corrupt generated file.
---
Makefile | 34 ++++++++++++++++++++--------------
1 files changed, 20 insertions(+), 14 deletions(-)
620173525c5075f2056af107a85881d0d50d3a89
diff --git a/Makefile b/Makefile
index dbf19c6..04536f6 100644
--- a/Makefile
+++ b/Makefile
@@ -496,37 +496,43 @@ builtin-help.o: common-cmds.h
rm -f $@ && ln git$X $@
common-cmds.h: Documentation/git-*.txt
- ./generate-cmdlist.sh > $@
+ ./generate-cmdlist.sh > $@+
+ mv $@+ $@
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
- rm -f $@
+ rm -f $@ $@+
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
-e 's/@@NO_PYTHON@@/$(NO_PYTHON)/g' \
- $@.sh >$@
- chmod +x $@
+ $@.sh >$@+
+ chmod +x $@+
+ mv $@+ $@
$(patsubst %.perl,%,$(SCRIPT_PERL)) : % : %.perl
- rm -f $@
+ rm -f $@ $@+
sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
- $@.perl >$@
- chmod +x $@
+ $@.perl >$@+
+ chmod +x $@+
+ mv $@+ $@
$(patsubst %.py,%,$(SCRIPT_PYTHON)) : % : %.py
- rm -f $@
+ rm -f $@ $@+
sed -e '1s|#!.*python|#!$(PYTHON_PATH_SQ)|' \
-e 's|@@GIT_PYTHON_PATH@@|$(GIT_PYTHON_DIR_SQ)|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
- $@.py >$@
- chmod +x $@
+ $@.py >$@+
+ chmod +x $@+
+ mv $@+ $@
git-cherry-pick: git-revert
- cp $< $@
+ cp $< $@+
+ mv $@+ $@
git-status: git-commit
- cp $< $@
+ cp $< $@+
+ mv $@+ $@
# These can record GIT_VERSION
git$X git.spec \
@@ -653,7 +659,8 @@ install-doc:
### Maintainer's dist rules
git.spec: git.spec.in
- sed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > $@
+ sed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > $@+
+ mv $@+ $@
GIT_TARNAME=git-$(GIT_VERSION)
dist: git.spec git-tar-tree
@@ -724,4 +731,3 @@ check-docs::
*) echo "no link: $$v";; \
esac ; \
done | sort
-
--
1.3.2
^ permalink raw reply related
* Re: [RFC][PATCH] Allow transfer of any valid sha1
From: Eric W. Biederman @ 2006-05-25 17:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtcay5k8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
>> I clearly would not advertise it. My problem is that I have
>> evidence that someone pulled a given sha1 at some point from
>> some branch on a given repository. But I don't have that branch.
>
> If that was over rsync (as you mention later), then I would
> consider that is an unfortunate unfixable issue. rsync mirrors
> are fundamentally unsafe for git -- Linus and I do not keep
> saying rsync should be deprecated without good reasons.
>
> There still might be bugs that breaks this guarantee outside
> rsync, but if that is the case we should fix it.
Sounds reasonable. So far I don't believe anything I have
proposed would result in a reference getting written
if we don't transfer all of the dependencies.
I do need to examine the algorithm by which we compute what
to transmit and make certain I have not broke that.
I believe I am still only using the existing references
for finding a common point in the history.
> I do not want to rehash the thread around Sep 29th 2005 here.
> The entry point of that thread is this message:
>
> http://marc.theaimsgroup.com/?l=git&m=112795140820665
>
> and the punch line are these two messages:
>
> http://marc.theaimsgroup.com/?l=git&m=112801874021223
> http://marc.theaimsgroup.com/?l=git&m=112802808030710
>
> I did not realize what I was breaking initially. I am not
> ashamed of having been wrong, but it was embarrassing ;-).
>
>> If I want
>> a copy of your pu branch at some point in the past, but you have
>> rebased it since that sha1 was published then there will clearly not
>> be a path from any current head to that branch. But if I still have a
>> copy of the sha1 I should actually be able to recover the old copy of
>> the pu branch from your tree.
>
> Not necessarily. I occasionally prune after rewinding. When my
> "pu" branch head does not point at the lost commit, the
> repository may or may not have that object you happen to know I
> used to have anymore.
Agreed. Of course the simple object existence test works in that
instance. Not that it does in general. The could be a git-prune
versus upload-pack race for instance.
>>> Now, proving that a given SHA1 is the name of an object that
>>> exists in the repository is cheap (has_sha1_file()), but proving
>>> that the object is reachable from some of our refs can become
>>> quite expensive. That gives this issue a security implication
>>> as well -- you can easily DoS the git-daemon that way, for
>>> example.
>>
>> Exactly, which is why I aimed for the cheap test.
>
> But the thing is the cheap test is broken, eh, rather,
> propagates brokenness downstream (which is perhaps worse).
As I understand it brokenness is writing a ref when you don't
have the complete tree it points to. I have no desire
to do that.
My basic argument is that starting a pull with a commit that is not a
reference is no worse than staring a pull from a broken repository. The
same checks that protects us should work in either case.
So as long as what I have done does not compromise the computation
of a common ancestor I think we should be fine.
I can see the argument that in a non-broken repository that finding
a path from an existing ref is proof that everything will work.
However if the code can be made to work without requiring that
proof it should be an even stronger guarantee of correctness,
and the expensive step of walking down from an existing ref would
be unnecessary.
Eric
^ permalink raw reply
* Re: [RFC][PATCH] Allow transfer of any valid sha1
From: Linus Torvalds @ 2006-05-25 17:28 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Junio C Hamano, git
In-Reply-To: <m1lksqdook.fsf@ebiederm.dsl.xmission.com>
On Thu, 25 May 2006, Eric W. Biederman wrote:
>
> My basic argument is that starting a pull with a commit that is not a
> reference is no worse than staring a pull from a broken repository. The
> same checks that protects us should work in either case.
I think Junio reacted to the subject line, which was somewhat badly
phrased. You're not looking to transfer random objects, you're looking to
_start_ a branch at any arbitrary known point.
However, Junio's point is probably that the "any valid SHA1" might
actually point to a broken tree, even if it exists on the server.
Of course, in that case hopefully git-rev-list exits with an error, and
the server doesn't generate any pack at all rather than generating a
broken one.
However, there's a (questionable) security issue: what if the server
doesn't _want_ to expose certain branches? Arguably, if you know the top
SHA1, you likely know all that it contains, but it may be a valid argument
to say that if the SHA1 isn't an exported branch, you shouldn't
necessarily be able to follow it.
Linus
^ permalink raw reply
* Re: [RFC][PATCH] Allow transfer of any valid sha1
From: Eric W. Biederman @ 2006-05-25 17:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605251024320.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 25 May 2006, Eric W. Biederman wrote:
>>
>> My basic argument is that starting a pull with a commit that is not a
>> reference is no worse than staring a pull from a broken repository. The
>> same checks that protects us should work in either case.
>
> I think Junio reacted to the subject line, which was somewhat badly
> phrased. You're not looking to transfer random objects, you're looking to
> _start_ a branch at any arbitrary known point.
Probably, but if I understood enough to get the subject line right the
first time I probably would have understood enough to just send
a patch :)
> However, Junio's point is probably that the "any valid SHA1" might
> actually point to a broken tree, even if it exists on the server.
>
> Of course, in that case hopefully git-rev-list exits with an error, and
> the server doesn't generate any pack at all rather than generating a
> broken one.
>
> However, there's a (questionable) security issue: what if the server
> doesn't _want_ to expose certain branches? Arguably, if you know the top
> SHA1, you likely know all that it contains, but it may be a valid argument
> to say that if the SHA1 isn't an exported branch, you shouldn't
> necessarily be able to follow it.
Agreed and I mentioned this one earlier.
However the only way the above scenario can even happen in a useful
manner is with a shared object store for several repositories. Otherwise
you couldn't access the data you don't want to share.
I can't think of a valid argument against not sharing an entire
repository except David Woodhouse's bandwidth concern.
Of course what was wanted there was a test a limit to how far
back in the history you could look for a common commit, which
is something different.
In general it is much easier to guarantee that either a repository is
shared or it is not. Making a guarantee that objects that
"git-fsck-objects --unreachable --full" identifies will never be
downloaded is difficult, and probably not worth encouraging
people to do.
That said it is easy to keep the current behavior as an option,
so the security policy issue shouldn't limit the technical discussion.
Eric
^ permalink raw reply
* Re: file name case-sensitivity issues
From: Junio C Hamano @ 2006-05-25 18:17 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20060525154735.GA6119@steel.home>
fork0@t-online.de (Alex Riesen) writes:
> ... Besides, how about when you
> don't _know_, like when cloning onto an usb-stick mounted with
> auto-detection? Will the files with case-different names just
> overwrite each other?
You _do_ realize that example is bogus, don't you? At least I
hope you did after you sent it.
You are cloning a project that has mixed cases (say foo and FOO)
onto a case challenged filesystem but unfortunately you did not
know the filesystem was case challenged in advance. So after
the cloning, your checkout results in only one file either foo
or FOO but not both, because you cannot have two files whose
names are different only in case on such a filesystem.
Tough.
There are some other problems on case challenged filesystems
that we _could_ solve but we probably don't right now. You
could concentrate on fixing those, instead of talking about
unfixable.
There are probably 2 kinds of case-challenged-ness. On non
case-challenged filesystems, if I say "rm -f foo Foo; echo >foo;
echo >Foo", "ls" says "foo Foo". On case-challenged systems,
one of the following would happen:
* "ls" says "foo". If I swap the order of the "echo", it says
"Foo". The filesystem does record the case but does not
allow two names with only case difference.
* "ls" says ef oh oh in a case different from either "foo" nor
"Foo". Or it says "foo" but if I swap the order of the
"echo", it still says "foo". The filesystem does not record
the case, and does not allow two names with only case
difference. readdir() may do some heuristics such as
lowercasing the name, but the point is the returned string is
unrealiable.
I have git installed on a Cygwin on NTFS at work, and I think it
is in the former category. git seems to work as expected,
modulo that you obviously cannot have two files "foo" and "Foo"
in your git-managed project. Probably a patch to delete "Foo"
and create "foo" (to make your project friendlier to Windows)
and a merge to do the same would work well, though I haven't
tried.
What breaks on filesystems in the latter category? I suspect
not many.
update-index records the names given by the user (I am assuming
that at least the shell is case sensitive), uses that name to
stat() and open() to update and/or refresh the cache entry, so
that codepath should be OK. Anything that goes from index to
find names and then goes to the filesystem with those names
(diff family, checkout-index and read-tree -u) should be fine.
ls-files -o/-i would have a hard time, since they need to work
with strings read from readdir(), as you found out. That means
"git add" and "git clean" may not work.
I do not think of anything else that is affected by readdir()
breakage offhand; the core is doing pretty fine as it is (I do
not consider ls-files -o/-i a core -- that is more Porcelainish
part of the whole package).
I honestly think that on Windows people would not even want to
use the core Porcelainish nor even Cogito. The would want a
native Window-ish UI that drives the core. I do not think such
a program would internally call "git add" nor read from
"ls-files -o/-i". It would instead do its own Folder hierarchy
traversal, and use "update-index --add --remove" to implement
its own "git add/rm" UI, and read from "ls-files" (not -o nor
-i) so that it can show tracked and untracked files differently
in its Explorer view.
So in that sense, I think ls-files -o/-i issue is quite low
priority. It does not matter on sane filesystems, and in the
place where it matters the most, the desired solution does not
involve ls-files -o/-i working well there.
Having said that, I think you _could_ have a repository
configuration that says "this repository sits on a case
challenged filesystem", and update ls-files to munge what it
gets from readdir() by comparing them against what you have in
the index. If your readdir() gives "foo" when you have "FOO" in
the index on such a filesystem, you do not say that "foo" is an
untracked file -- you just say you found "FOO" as you expected.
^ permalink raw reply
* Re: [RFC][PATCH] Allow transfer of any valid sha1
From: Junio C Hamano @ 2006-05-25 18:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric W. Biederman, git
In-Reply-To: <Pine.LNX.4.64.0605251024320.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 25 May 2006, Eric W. Biederman wrote:
>>
>> My basic argument is that starting a pull with a commit that is not a
>> reference is no worse than staring a pull from a broken repository. The
>> same checks that protects us should work in either case.
>
> I think Junio reacted to the subject line, which was somewhat badly
> phrased. You're not looking to transfer random objects, you're looking to
> _start_ a branch at any arbitrary known point.
I realize that now. From Eric's original message:
To be accurate of his source Andrew records the sha1 of the commit
and the git tree he pulled from. Which looks like:
GIT b307e8548921c686d2eb948ca418ab2941876daa \
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
So I figured I would transform the above line into the obvious
git-pull command:
git-pull \
git+ssh://master.kernel.org/pub/scm/.../torvalds/linux-2.6.git \
b307e8548921c686d2eb948ca418ab2941876daa
With the limitation of the current tool, we could do:
git-fetch master.kernel.org:/pub/scm/.../torvalds/linux-2.6.git \
refs/heads/master:refs/remotes/linus/master
git merge 'whatever merge message' HEAD b307e854
assuming that b307e854 is reachable from your tip. So it might
be just a matter of giving a convenient shorthand to do the
above two commands, instead of mucking with upload-pack.
^ permalink raw reply
* Re: [RFC][PATCH] Allow transfer of any valid sha1
From: Linus Torvalds @ 2006-05-25 18:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric W. Biederman, git
In-Reply-To: <7v3beyuffg.fsf@assigned-by-dhcp.cox.net>
On Thu, 25 May 2006, Junio C Hamano wrote:
>
> With the limitation of the current tool, we could do:
>
> git-fetch master.kernel.org:/pub/scm/.../torvalds/linux-2.6.git \
> refs/heads/master:refs/remotes/linus/master
> git merge 'whatever merge message' HEAD b307e854
>
> assuming that b307e854 is reachable from your tip. So it might
> be just a matter of giving a convenient shorthand to do the
> above two commands, instead of mucking with upload-pack.
It's not upload-pack that needs mucking with. It's simply "fetch-pack"
that currently will refuse to say "want b307e854..", because the only
thing it can do is say "want <headref>".
So the patch would literally be to have a way to tell fetch-pack directly
what you want, and not have the "only select from remote branches" logic.
Linus
^ permalink raw reply
* git-format-patch possible regressions
From: Marco Costalba @ 2006-05-25 19:23 UTC (permalink / raw)
To: git
A couple of possible regressions:
1) Unreconized --signoff option
$ git --version
git version 1.3.3.ged90
$ git-format-patch -s HEAD^..HEAD
0001-cat-file-document-p-option.txt
$ git-format-patch --signoff HEAD^..HEAD
fatal: unrecognized argument: --signoff
2) Unhandled ranges list
$ git --version
git version 1.3.3.ged90
$ git-format-patch -s HEAD^..HEAD HEAD^^..HEAD^
0001-cat-file-document-p-option.txt
$ git --version
git version 1.3.3.gf205
git checkout -b test 51ce34b9923d9b119ac53414584f80e05520abea
$ git-format-patch HEAD^..HEAD HEAD^^..HEAD^
0001-Builtin-git-show-branch.txt
0002-Builtin-git-apply.txt
Both regressions brake qgit. The first one is easy to fix (--signoff --> -s)
The second one is not so easy.
It is use to format a patch series starting from a mouse selected
multiple revisions. Note that the revisions could be not consecutive.
Note also that looping git-format-patch for each revision does not
updates patch number that always stay at 0001.
Feeding all the selected revisions in one go in the form
git-format-patch sel1^..sel1 sel2^..sel2 ........ seln^..seln is
the only way I have found to:
1) create a patch series of (randomly) selected revisions
2) increment patch numbers for each patch
Marco
^ permalink raw reply
* Re: git-format-patch possible regressions
From: Linus Torvalds @ 2006-05-25 19:43 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550605251223g2cf8cfb9vfa18d016b369188d@mail.gmail.com>
On Thu, 25 May 2006, Marco Costalba wrote:
>
> 2) Unhandled ranges list
>
> $ git-format-patch -s HEAD^..HEAD HEAD^^..HEAD^
You _really_ shouldn't use this "mix two ranges" format.
It may have "worked" before, but it
- worked differently from all other git ranges
- it was really an implementation detail (handling each argument
separately)
The "x..y" format is defined to mean the same thing "y ^x", and that means
that "HEAD^..HEAD HEAD^^..HEAD^" really does mean the same thing as
"^HEAD^ ^HEAD^^ HEAD HEAD^", which in turn means the same thing as "^HEAD^
HEAD" from a reachability standpoint (since HEAD^ is by definition
reachable from HEAD, adding it won't change the revision list, and the
same goes for ^HEAD^^ vs ^HEAD^).
So thus "HEAD^..HEAD HEAD^^..HEAD^" really _is_ the same thing as
"HEAD^..HEAD", and any tool that thought otherwise was just being
very confused.
Now, we could choose to try to make "a..b" mean something else (ie make
the "^a" part only meaningful for that particular "sub-query"), and yes,
in many ways that would be a more intuitive thing, but it's not how git
revision descriptions work currently, and if we make that change we should
do it across the board.
(It's not an easy change to make, but it should be possible by having
multiple separate NECESSARY/UNNECESSARY bits, and make the revision
walking logic a whole lot more complicated than it already is).
So I'd argue that you should really do something like
( git-rev-list a..b ; git-rev-list c..d ) |
git-format-patch --stdin
in qgit if you want the ranges to be truly independent.
(And no, I don't think git-format-patch takes a "--stdin" argument, but it
might not be unreasonable to add it as a generic revision walking
argument for scripting like this).
Linus
^ permalink raw reply
* Re: git-format-patch possible regressions
From: Junio C Hamano @ 2006-05-25 19:56 UTC (permalink / raw)
To: Marco Costalba; +Cc: git, Linus Torvalds
In-Reply-To: <e5bfff550605251223g2cf8cfb9vfa18d016b369188d@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> A couple of possible regressions:
>
> 1) Unreconized --signoff option
>
> $ git --version
> git version 1.3.3.ged90
> $ git-format-patch -s HEAD^..HEAD
> 0001-cat-file-document-p-option.txt
> $ git-format-patch --signoff HEAD^..HEAD
> fatal: unrecognized argument: --signoff
>...
> Both regressions brake qgit. The first one is easy to fix (--signoff --> -s)
I do not think -s does what you want. It means "do not generate
diff" to the diff family, but format-patch overrides it and
forces generating patch+stat output, so you do not see what it
is doing.
Also I do not think we would want to have --sign to format-patch
anyway; it encourages a wrong workflow. Please see this and
other messages in the thread:
http://article.gmane.org/gmane.comp.version-control.git/20389
On a slightly related topic, I sent a message to Pasky about
this -s stuff. It means something slightly different in
diff-files (instead of asking for no output, it behaves as a
no-op there), and we can remove that compatibility wart once
Cogito stops using "diff-files -s" when it wants to do
"diff-files" in cg-merge (and I suspect that diff-files is
unnecessary).
> 2) Unhandled ranges list
>
> The second one is not so easy.
This is a real regression; I was hoping Porcelain writers were
paying attention of what are coming, but obviously the
description in "What's in git.git" messages and discussion on
the list were not detailed enough. My apologies.
Having said that, I think what Linus says about equilvalence
between "a..b" and "^a b" makes whole lot of sense. However, I
could argue both ways. Linus's interpretation of "a..b c..d" is
"^a ^c b d", but format-patch's interpretation has always been
"do '^a b' and then '^c d'".
The former is more generic; you could say "not in A nor B but in
C pretty easily -- list of ranges cannot express something like
that. On the other hand, at least in the context of usual
format-patch, the convenience of being able to work on more than
one ranges in sequence may far outweigh the restriction of not
being able to say something like that.
As an easy alternative, we could give --start-number=<n> to
format-patch so that you can do the iteration yourself instead
of having format-patch to iterate over the list.
^ permalink raw reply
* Re: [PATCH 0/2] tagsize < 8kb restriction
From: Junio C Hamano @ 2006-05-25 20:03 UTC (permalink / raw)
To: Björn Engelmann; +Cc: git
In-Reply-To: <44759ABF.1010209@gmx.de>
Björn Engelmann <BjEngelmann@gmx.de> writes:
> I am well aware that all functionality neccessary already exists. I just
> want to prevent people learning git in future to have the same
> frustrating experience as I did.
I think I understood your points, but for normal "people
learning git", hash-object, write-tree, commit-tree and mktag
are _not_ the commands they need to know about. These low level
commands are for Porcelain writers. The users do not create
blobs or trees or commits -- they "git add", "git rm", "git
commit", and "git pull" and as part of these actions, blobs,
trees and commits are created. The users do not even create
tags with mktag -- they use "git tag" for that.
^ permalink raw reply
* Re: git-format-patch possible regressions
From: Marco Costalba @ 2006-05-25 20:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605251233300.5623@g5.osdl.org>
On 5/25/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> The "x..y" format is defined to mean the same thing "y ^x", and that means
> that "HEAD^..HEAD HEAD^^..HEAD^" really does mean the same thing as
> "^HEAD^ ^HEAD^^ HEAD HEAD^", which in turn means the same thing as "^HEAD^
> HEAD" from a reachability standpoint (since HEAD^ is by definition
> reachable from HEAD, adding it won't change the revision list, and the
> same goes for ^HEAD^^ vs ^HEAD^).
>
> So thus "HEAD^..HEAD HEAD^^..HEAD^" really _is_ the same thing as
> "HEAD^..HEAD", and any tool that thought otherwise was just being
> very confused.
>
Perhaps I have chose the wrong example but it was _only_
instrumental in better explaing the regression.
The general problem is how to format patches files named with
consecutive numbers starting from a set of possible unrelated
revisions.
> Now, we could choose to try to make "a..b" mean something else (ie make
> the "^a" part only meaningful for that particular "sub-query"), and yes,
> in many ways that would be a more intuitive thing, but it's not how git
> revision descriptions work currently, and if we make that change we should
> do it across the board.
>
> (It's not an easy change to make, but it should be possible by having
> multiple separate NECESSARY/UNNECESSARY bits, and make the revision
> walking logic a whole lot more complicated than it already is).
>
> So I'd argue that you should really do something like
>
> ( git-rev-list a..b ; git-rev-list c..d ) |
> git-format-patch --stdin
>
> in qgit if you want the ranges to be truly independent.
>
> (And no, I don't think git-format-patch takes a "--stdin" argument, but it
> might not be unreasonable to add it as a generic revision walking
> argument for scripting like this).
>
To fix qgit problem could be enough to add/modify the option -nx to
make git-format-patch do not default with 0001 number but with x and
then simply call git-format-patch in a loop:
for(int i = 0; i <selectedRevisions.count(); i++)
git-format patch -n<i+1> selectedRevisions[i] ^selectedRevisions[i];
But of course it is clear your suggestion could be a solution for
much broader cases.
Marco
^ permalink raw reply
* Re: git-format-patch possible regressions
From: Marco Costalba @ 2006-05-25 20:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vhd3dubd9.fsf@assigned-by-dhcp.cox.net>
> > Both regressions brake qgit. The first one is easy to fix (--signoff --> -s)
>
> I do not think -s does what you want. It means "do not generate
> diff" to the diff family, but format-patch overrides it and
> forces generating patch+stat output, so you do not see what it
> is doing.
>
Sorry, I was fooled by git-format-patch.txt documentation.
> > 2) Unhandled ranges list
> >
> > The second one is not so easy.
>
> This is a real regression; I was hoping Porcelain writers were
> paying attention of what are coming, but obviously the
> description in "What's in git.git" messages and discussion on
> the list were not detailed enough. My apologies.
>
Sorry also for this, normally I read "What's in git.git" but perhaps I
missed this.
>
> As an easy alternative, we could give --start-number=<n> to
> format-patch so that you can do the iteration yourself instead
> of having format-patch to iterate over the list.
>
>
You beat me for few minutes ;-)
Marco
^ permalink raw reply
* Re: [RFC][PATCH] Allow transfer of any valid sha1
From: Eric W. Biederman @ 2006-05-25 20:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Eric W. Biederman, git
In-Reply-To: <Pine.LNX.4.64.0605251134410.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 25 May 2006, Junio C Hamano wrote:
>>
>> With the limitation of the current tool, we could do:
>>
>> git-fetch master.kernel.org:/pub/scm/.../torvalds/linux-2.6.git \
>> refs/heads/master:refs/remotes/linus/master
>> git merge 'whatever merge message' HEAD b307e854
>>
>> assuming that b307e854 is reachable from your tip. So it might
>> be just a matter of giving a convenient shorthand to do the
>> above two commands, instead of mucking with upload-pack.
>
> It's not upload-pack that needs mucking with. It's simply "fetch-pack"
> that currently will refuse to say "want b307e854..", because the only
> thing it can do is say "want <headref>".
>
> So the patch would literally be to have a way to tell fetch-pack directly
> what you want, and not have the "only select from remote branches" logic.
So fixing fetch-pack is easy and pretty non-controversial.
The patch below handles that.
The problem is that I then run into the limitations in upload-pack.
(The movement of filter_refs may actually be overkill)
Eric
diff --git a/fetch-pack.c b/fetch-pack.c
index a3bcad0..c767d84 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -260,6 +260,27 @@ static void mark_recent_complete_commits
}
}
+static struct ref **get_sha1_heads(struct ref **refs, int nr_heads, char **head)
+{
+ int i;
+ for (i = 0; i < nr_heads; i++) {
+ struct ref *ref;
+ unsigned char sha1[20];
+ char *s = head[i];
+ int len = strlen(s);
+
+ if (len != 40 || get_sha1_hex(s, sha1))
+ continue;
+
+ ref = xcalloc(1, sizeof(*ref) + len + 1);
+ memcpy(ref->old_sha1, sha1, 20);
+ memcpy(ref->name, s, len + 1);
+ *refs = ref;
+ refs = &ref->next;
+ }
+ return refs;
+}
+
static void filter_refs(struct ref **refs, int nr_match, char **match)
{
struct ref *prev, *current, *next;
@@ -311,6 +332,8 @@ static int everything_local(struct ref *
if (cutoff)
mark_recent_complete_commits(cutoff);
+ filter_refs(refs, nr_match, match);
+
/*
* Mark all complete remote refs as common refs.
* Don't mark them common yet; the server has to be told so first.
@@ -329,8 +352,6 @@ static int everything_local(struct ref *
}
}
- filter_refs(refs, nr_match, match);
-
for (retval = 1, ref = *refs; ref ; ref = ref->next) {
const unsigned char *remote = ref->old_sha1;
unsigned char local[20];
@@ -373,6 +394,7 @@ static int fetch_pack(int fd[2], int nr_
packet_flush(fd[1]);
die("no matching remote head");
}
+ get_sha1_heads(&ref, nr_match, match);
if (everything_local(&ref, nr_match, match)) {
packet_flush(fd[1]);
goto all_done;
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 187f088..2372df8 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -105,6 +105,7 @@ canon_refs_list_for_fetch () {
'') remote=HEAD ;;
refs/heads/* | refs/tags/* | refs/remotes/*) ;;
heads/* | tags/* | remotes/* ) remote="refs/$remote" ;;
+ [0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]) ;;
*) remote="refs/heads/$remote" ;;
esac
case "$local" in
^ permalink raw reply related
* Re: [PATCH] Documentation/Makefile: remove extra /
From: Junio C Hamano @ 2006-05-25 20:45 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060525123746.GA14325@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> As both DESTDIR and the prefix are supposed to be absolute pathnames
> they can simply be concatenated without an extra / (like in the main Makefile).
> The extra slash may even break installation on Windows.
>
> Signed-off-by: Martin Waitz <tali@admingilde.org>
> ---
> Documentation/Makefile | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/Makefile b/Documentation/Makefile
> index 2a08f59..2b0efe7 100644
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -52,9 +52,9 @@ man1: $(DOC_MAN1)
> man7: $(DOC_MAN7)
>
> install: man
> - $(INSTALL) -d -m755 $(DESTDIR)/$(man1) $(DESTDIR)/$(man7)
> - $(INSTALL) $(DOC_MAN1) $(DESTDIR)/$(man1)
> - $(INSTALL) $(DOC_MAN7) $(DESTDIR)/$(man7)
> + $(INSTALL) -d -m755 $(DESTDIR)$(man1) $(DESTDIR)$(man7)
> + $(INSTALL) $(DOC_MAN1) $(DESTDIR)$(man1)
> + $(INSTALL) $(DOC_MAN7) $(DESTDIR)$(man7)
This unfortunately breaks a workaround I did in the main
Makefile for dist-doc target, but I agree it is a good change.
^ permalink raw reply
* Re: [RFC][PATCH] Allow transfer of any valid sha1
From: Eric W. Biederman @ 2006-05-25 20:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v3beyuffg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> On Thu, 25 May 2006, Eric W. Biederman wrote:
>>>
>>> My basic argument is that starting a pull with a commit that is not a
>>> reference is no worse than staring a pull from a broken repository. The
>>> same checks that protects us should work in either case.
>>
>> I think Junio reacted to the subject line, which was somewhat badly
>> phrased. You're not looking to transfer random objects, you're looking to
>> _start_ a branch at any arbitrary known point.
>
> I realize that now. From Eric's original message:
>
> To be accurate of his source Andrew records the sha1 of the commit
> and the git tree he pulled from. Which looks like:
>
> GIT b307e8548921c686d2eb948ca418ab2941876daa \
> git+ssh://master.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> So I figured I would transform the above line into the obvious
> git-pull command:
>
> git-pull \
> git+ssh://master.kernel.org/pub/scm/.../torvalds/linux-2.6.git \
> b307e8548921c686d2eb948ca418ab2941876daa
>
> With the limitation of the current tool, we could do:
>
> git-fetch master.kernel.org:/pub/scm/.../torvalds/linux-2.6.git \
> refs/heads/master:refs/remotes/linus/master
> git merge 'whatever merge message' HEAD b307e854
>
> assuming that b307e854 is reachable from your tip. So it might
> be just a matter of giving a convenient shorthand to do the
> above two commands, instead of mucking with upload-pack.
If we conclude the fetch by sha1 path is not practical certainly.
There are a couple of problems with the just use the tool as
is approach.
- I don't know which branch I need to fetch.
Although it looks like Andrew has kept that information when it was not the
default branch so I can probably use that.
- Fetching a branch that I just want a subset of is wasteful.
- It feels really weird when everything else allows me to use sha1s
for git-fetch to deny them.
Then there is the big hole in my plan to get better changelog information
that it appears that after Andrew pulls a branch he resolves some
merge conflicts. If that is right I need to figure out how to address
that before I can improve git-quiltimport.sh.
To get a slightly better feel of the problem below is the complete list of git
trees that Andrew pulled in for 2.6.17-rc4-mm3.
Eric
GIT d684de2c4a498ec4edf4e6c3420b008c62be394c git+ssh://master.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git#test
GIT 34ec52e3356245e9a13dfcbc8460635e675f13cf git+ssh://master.kernel.org/pub/scm/linux/kernel/git/davej/agpgart.git
GIT 08e66777d094d93091a914a8746a9b93599e14a9 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/perex/alsa-current.git
GIT 0ef744735f0d82d90809935586a0d1043f7f09b5 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/viro/audit-current.git#master.b13
GIT cca5d8ad1f58f188500b9fb12ba6d98643a4cf49 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git#for-linus
GIT b3b6a155c2b85d436b192d74e459f837eab0944e git+ssh://master.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git#cfq
GIT 8ba86486650c59f969c589c7d6c3dd4da734c75a git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6.git
GIT 2a1db55336a9e99f5dd7ee64e42fa4cbb509ea6a git+ssh://master.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
GIT 639b4408a9e8e014878c7538859f33f852c23882 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git#devel
GIT d2f222e6310b073ae3d91b8d3d676621fae1314e git+ssh://master.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6.git
GIT 3ac6c7b44560fdf2ea8865536bd52d4ff038107e git://git.infradead.org/hdrcleanup-2.6.git
GIT 12415e45ab0429a88412f4af365515adbe0bdd68 git://git.infradead.org/hdrinstall-2.6.git
GIT 155f23d603727fcb2af6c69ff77b74d1d4eb5bde git+ssh://master.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git#test
GIT ba9cfd16a13a932f0603a7f65b3881738a698ae1 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git#for-mm
GIT 51d797474f87b375819d084f7583a2864c5656c4 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/intelfb-2.6#i915fb
GIT c32217fdc98292dbafd5f51d3f43337081b01c29 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-klibc.git
GIT 9fe74aaa1dc55100d20d9b7be2ccbf84ad26ce84 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git#ALL
GIT 864fdc881dd9e0077f9ed11191055e3eabf3b2a5 git://www.linux-mips.org/pub/scm/upstream.git#for-akpm
GIT 0d25971d7c969debf76f9fab6d6b37cb62408f55 git://git.infradead.org/mtd-2.6.git
GIT b748b7167cbeb11e729c6f9c3472165903dd115e git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git#ALL
GIT c4bdea3ce8b1d9b9d8dc44223542b3ebbe3a3020 git://git.linux-nfs.org/pub/linux/nfs-2.6.git
GIT f8b4c6027275d9b2d5004726a6d1bb818a13ddef git://oss.oracle.com/home/sourcebo/git/ocfs2.git/#ALL
GIT 35b86edf75270176310cb9507745d8c02b9e6592 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git/
GIT 3c06da5ae5358e9d325d541a053e1059e9654bcc git+ssh://master.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
GIT aa783a8f31c79f493bd49ba926b171b79b9839fb git://git.infradead.org/users/dwmw2/rbtree-2.6.git
GIT ee69d3f20b23250eae98a4cb20236196694f0b81 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jejb/aic94xx-sas-2.6.git
GIT 9f434d4f84a235f6b61aec6e691d6b07bc46fc24 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6.git
GIT 0df298d180556450cbe5edf12c1e890f6ac6ea97 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-target-2.6.git
GIT f1d282724317895f73c4c182041ab4385126c026 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git#stex
GIT 19932e4d7d2002bc956d1636e1c3a1d4455049fa git+ssh://master.kernel.org/pub/scm/linux/kernel/git/viro/bird.git#frv.b14
GIT 6ea79eadeba9b0d0ab08dcf7ee16df13e1fdadae git+ssh://master.kernel.org/pub/scm/linux/kernel/git/viro/bird.git#m32r.b14
GIT c3d6ecc77e8e5d4ac82c3bf27ed02b8c0d83d41d git+ssh://master.kernel.org/pub/scm/linux/kernel/git/viro/bird.git#m68k.b14
GIT e7dd49b206624021c23a27512d2a31503f5207f2 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/viro/bird.git#upf.b14
GIT ea0d175136582dff6e3591368b1da472ef3870b8 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/viro/bird.git#volatile.b14
GIT b29527edccbbc53a908bc34a910df3601061c950 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog-mm.git
GIT b307e8548921c686d2eb948ca418ab2941876daa git+ssh://master.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
^ 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