* Re: using git directory cache code in darcs?
From: Junio C Hamano @ 2005-04-17 23:23 UTC (permalink / raw)
To: Nomad Arton; +Cc: git
In-Reply-To: <4262E50C.2070006@lazy.shacknet.nu>
>>>>> "NA" == Nomad Arton <lkml@lazy.shacknet.nu> writes:
NA> Linus Torvalds schrieb:
>> In fact, one of my hopes was that other SCM's could just use the git
>> plumbing. But then I'd really suggest that you use "git" itself, not any
>> "libgit". Ie you take _all_ the plumbing as real programs, and instead of
>> trying to link against individual routines, you'd _script_ it.
NA> please excuse; libgit and scripting to me arent a contradiction. many
NA> sripting languages are extended by C modules, while still happening to
NA> have all the scripting rapidity. its just a matter of how to
NA> communicate with the C code, isnt it?
You are arguing for scripting language binding like what Swig
creates. While that would also be a worthy addition, having
language binding is not the only way to do _script_.
What Linus is saying is that he wants you to talk with git
plumbing by invoking the executables he have, via system(3),
popen(3), etc.
The C-level first has to be libified before you can start
talking about host language bindings but that just started to
happen and is not ready yet. However, you can use and benefit
from GIT without waiting for that kind of integration, if you
use the "spawning the executables" approach. I agree with him.
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Linus Torvalds @ 2005-04-17 23:24 UTC (permalink / raw)
To: Russell King; +Cc: David Woodhouse, Git Mailing List, Peter Anvin
In-Reply-To: <20050417235136.B30656@flint.arm.linux.org.uk>
On Sun, 17 Apr 2005, Russell King wrote:
>
> I pulled it tonight into a pristine tree (which of course worked.)
Goodie.
> In doing so, I noticed that I'd messed up one of the commits - there's
> a missing new file. Grr. I'll put that down to being a newbie git.
Actually, you should put that down to horribly bad interface tools. With
BK, we had these nice tools that pointed out that there were files that
you might want to commit (ie "bk citool"), and made this very obvious.
Tools absolutely matter. And it will take time for us to build up that
kind of helper infrastructure. So being newbie might be part of it, but
it's the smaller part, I say. Rough interfaces is a big issue.
Linus
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: David Woodhouse @ 2005-04-17 23:21 UTC (permalink / raw)
To: randy_dunlap; +Cc: Linus Torvalds, git, hpa
In-Reply-To: <20050417152218.3501f2f1.rdunlap@xenotime.net>
On Sun, 2005-04-17 at 15:22 -0700, randy_dunlap wrote:
> David did the commits-mailing-list script and I'm working on a
> commits web-page like what was formerly seen at:
> http://www.kernel.org/pub/linux/kernel/v2.6/testing/cset/
> (with daily tarball)
>
> based on some older scripts from David, however I'm wondering if
> a variant of the gitlog.sh script wouldn't be a better starting
> point for it.
My commits-list script is in fact based on gitlog.sh. You'll probably
find useful things to crib from in both that and the original
bkexport.sh script.
The commits script also wants updating to print the date properly now
that we've changed how it's stored -- I'll try to find some time this
week to update it and set it running on master.kernel.org again, but it
may end up waiting till after LCA.
--
dwmw2
^ permalink raw reply
* [PATCH] "checkout-cache -m" writes unmerged contents for each stage.
From: Junio C Hamano @ 2005-04-17 23:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
This is the alternative strategy I mentioned in my previous
message. A new -m option to checkout-cache causes it to store
contents of unmerged paths in path~1~, path~2~, and path~3~.
To be applied on top of the previous patch I re-sent:
[PATCH] checkout-cache -a should not extract unmerged stages.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
checkout-cache.c | 93 ++++++++++++++++++++++++++++++++++++++++++++----------
1 files changed, 76 insertions(+), 17 deletions(-)
checkout-cache.c: 596471a2f98b80a622488cf04edf9e95ce8666b1
--- checkout-cache.c
+++ checkout-cache.c 2005-04-17 15:49:15.000000000 -0700
@@ -34,7 +34,7 @@
*/
#include "cache.h"
-static int force = 0, quiet = 0;
+static int force = 0, merge = 0, quiet = 0;
static void create_directories(const char *path)
{
@@ -65,6 +65,31 @@ static int create_file(const char *path,
return fd;
}
+/* Returns the pathname itself for a merged entry
+ * and pathname~N~ for an unmerged one.
+ * Do not free the value you get from this function.
+ */
+static char *ce_name_with_stage(struct cache_entry *ce)
+{
+ /* (CE_NAMEMASK+1) is the max length of a name.
+ * We are adding 3 bytes for ~N~ and we need a terminating NUL
+ * hence +5.
+ */
+ static char name[CE_NAMEMASK + 5];
+ int stage = ce_stage(ce);
+ if (! stage)
+ return ce->name;
+ else {
+ int pos = ce_namelen(ce);
+ strcpy(name, ce->name);
+ name[pos++] = '~';
+ name[pos++] = '0' + stage;
+ name[pos++] = '~';
+ name[pos] = 0;
+ return name;
+ }
+}
+
static int write_entry(struct cache_entry *ce)
{
int fd;
@@ -72,13 +97,20 @@ static int write_entry(struct cache_entr
unsigned long size;
long wrote;
char type[20];
+ char *name;
new = read_sha1_file(ce->sha1, type, &size);
if (!new || strcmp(type, "blob")) {
return error("checkout-cache: unable to read sha1 file of %s (%s)",
ce->name, sha1_to_hex(ce->sha1));
}
- fd = create_file(ce->name, ntohl(ce->ce_mode));
+ name = ce_name_with_stage(ce);
+ if (!quiet && name != ce->name)
+ fprintf(stderr,
+ "checkout-cache: storing stage %d of %s in %s\n",
+ ce_stage(ce), ce->name, name);
+
+ fd = create_file(name, ntohl(ce->ce_mode));
if (fd < 0) {
free(new);
return error("checkout-cache: unable to create %s (%s)",
@@ -117,19 +149,39 @@ static int checkout_entry(struct cache_e
return write_entry(ce);
}
+static int checkout_unmerged(int pos)
+{
+ int i, err;
+ struct cache_entry *ce = active_cache[pos];
+
+ for (err = 0, i = pos;
+ (i < active_nr &&
+ !strcmp(active_cache[i]->name, ce->name));
+ i++)
+ err |= checkout_entry(active_cache[i]);
+ return err;
+}
+
static int checkout_file(const char *name)
{
int pos = cache_name_pos(name, strlen(name));
if (pos < 0) {
- if (!quiet) {
- pos = -pos - 1;
- fprintf(stderr,
- "checkout-cache: %s is %s.\n",
- name,
- (pos < active_nr &&
- !strcmp(active_cache[pos]->name, name)) ?
- "unmerged" : "not in the cache");
+ pos = -pos - 1;
+ if (pos < active_nr &&
+ !strcmp(active_cache[pos]->name, name)) {
+ if (merge)
+ return checkout_unmerged(pos);
+ else if (! quiet) {
+ fprintf(stderr,
+ "checkout-cache: %s is unmerged.\n",
+ name);
+ return -1;
+ }
}
+ else if (! quiet)
+ fprintf(stderr,
+ "checkout-cache: %s is not in the cache.\n",
+ name);
return -1;
}
return checkout_entry(active_cache[pos]);
@@ -137,22 +189,25 @@ static int checkout_file(const char *nam
static int checkout_all(void)
{
- struct cache_entry *unmerge_skipping = NULL;
int i;
for (i = 0; i < active_nr ; i++) {
struct cache_entry *ce = active_cache[i];
if (ce_stage(ce)) {
- if (!unmerge_skipping ||
- strcmp(unmerge_skipping->name, ce->name))
+ if (!merge)
fprintf(stderr,
"checkout-cache: needs merge %s\n",
ce->name);
- unmerge_skipping = ce;
- continue;
+ while (i < active_nr &&
+ !strcmp(ce->name, active_cache[i]->name)) {
+ if (merge) {
+ checkout_entry(active_cache[i]);
+ }
+ i++;
+ }
+ i--;
}
- unmerge_skipping = NULL;
- if (checkout_entry(ce) < 0)
+ else if (checkout_entry(ce) < 0)
return -1;
}
return 0;
@@ -181,6 +236,10 @@ int main(int argc, char **argv)
force = 1;
continue;
}
+ if (!strcmp(arg, "-m")) {
+ merge = 1;
+ continue;
+ }
if (!strcmp(arg, "-q")) {
quiet = 1;
continue;
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Russell King @ 2005-04-17 22:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Woodhouse, Git Mailing List, Peter Anvin
In-Reply-To: <20050417231959.A30656@flint.arm.linux.org.uk>
On Sun, Apr 17, 2005 at 11:19:59PM +0100, Russell King wrote:
> On Sun, Apr 17, 2005 at 03:17:50PM -0700, Linus Torvalds wrote:
> > Can people usefully track my current kernel git repository, or do you have
> > to be crazy to do so? That's really the question. You be the judge. Me,
> > I'm just giddy from a merge that was clearly done using interfaces that
> > aren't actually really usable for anybody but me, and barely me at that ;)
>
> I guess I'll have the pleasure to find that out when I update my tree
> with your latest changes... which I think is a project for tomorrow.
I pulled it tonight into a pristine tree (which of course worked.)
In doing so, I noticed that I'd messed up one of the commits - there's
a missing new file. Grr. I'll put that down to being a newbie git.
--
Russell "newbie git" King
^ permalink raw reply
* Re: Add lsremote command.
From: Steven Cole @ 2005-04-17 22:42 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050417140309.GF1487@pasky.ji.cz>
On Sunday 17 April 2005 08:03 am, Petr Baudis wrote:
> Dear diary, on Sun, Apr 17, 2005 at 07:36:51AM CEST, I got a letter
> where Steven Cole <elenstev@mesatop.com> told me that...
> > This is a fairly trivial addition, but if users are adding remote repositories
> > with git addremote, then those users should be able to list out the remote
> > list without having to know the details of where the remotes file is kept.
>
> Could you please send your patches inline? (Either in the body or with
> correct content-disposition header.)
>
> You got the return values other way around and you are missing a
> copyright notice at the top; you should also mention that you take no
> parameters.
>
> Please use -s instead of -e, since it is more appropriate in this case.
> Also, you should report the "no remotes" message to stderr. And always
> exit when you found that .git/remotes exists, not only if cat succeeds.
>
> Kind regards,
>
Thanks for the fixes. Here's a better version.
Steven
This is a fairly trivial addition, but if users are adding remote repositories
with git addremote, then those users should be able to list out the remote
list without having to know the details of where the remotes file is kept.
Signed-off-by: Steven Cole <elenstev@mesatop.com>
diff -urN git-pasky.orig/git git-pasky/git
--- git-pasky.orig/git 2005-04-17 15:02:37.000000000 -0600
+++ git-pasky/git 2005-04-17 15:04:23.000000000 -0600
@@ -41,6 +41,7 @@
log
ls [TREE_ID]
lsobj [OBJTYPE]
+ lsremote
merge -b BASE_ID FROM_ID
pull [RNAME]
rm FILE...
@@ -105,6 +106,7 @@
"log") gitlog.sh "$@";;
"ls") gitls.sh "$@";;
"lsobj") gitlsobj.sh "$@";;
+"lsremote") gitlsremote.sh "$@";;
"merge") gitmerge.sh "$@";;
"pull") gitpull.sh "$@";;
"rm") gitrm.sh "$@";;
diff -urN git-pasky.orig/gitlsremote.sh git-pasky/gitlsremote.sh
--- git-pasky.orig/gitlsremote.sh 1969-12-31 17:00:00.000000000 -0700
+++ git-pasky/gitlsremote.sh 2005-04-17 16:20:48.000000000 -0600
@@ -0,0 +1,11 @@
+#!/bin/sh
+#
+# Lists remote GIT repositories
+# Copyright (c) Steven Cole 2005
+#
+# Takes no parameters
+#
+[ -s .git/remotes ] && cat .git/remotes
+[ -s .git/remotes ] && exit
+
+echo "List of remotes is empty. See git addremote." >&2
^ permalink raw reply
* Re: using git directory cache code in darcs?
From: Nomad Arton @ 2005-04-17 22:37 UTC (permalink / raw)
Cc: git
In-Reply-To: <Pine.LNX.4.58.0504170916080.7211@ppc970.osdl.org>
Linus Torvalds schrieb:
>
> In fact, one of my hopes was that other SCM's could just use the git
> plumbing. But then I'd really suggest that you use "git" itself, not any
> "libgit". Ie you take _all_ the plumbing as real programs, and instead of
> trying to link against individual routines, you'd _script_ it.
please excuse; libgit and scripting to me arent a contradiction. many
sripting languages are extended by C modules, while still happening to
have all the scripting rapidity. its just a matter of how to communicate
with the C code, isnt it?
yours,
peter
^ permalink raw reply
* Re: [PATCH] use gcrypt instead of libssl for hash
From: Junichi Uekawa @ 2005-04-17 22:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junichi Uekawa, git
In-Reply-To: <Pine.LNX.4.58.0504171039460.7211@ppc970.osdl.org>
Hi,
Thanks for your comments.
> > This is the first time for me to send you a patch; be gentle.
> > the following patch allows for use of gcrypt.
>
> Well, libgcrypt seems to be pretty rare out there - I certainly don't have
> it installed on my machine.
Hmm... okay. Might be the case if you don't use much of GNOME and other
apps.
> > libssl seems to have a restrictive licensing wrt GPL applications.
>
> The GPL makes explicit mention of the system libraries (which openssl
> definitely is by now), so it's ok by the GPL . And I don't see how you'd
> claim that the openssl license doesn't allow it. So it all looks ok by me.
>From a standpoint of Debian Developer; it feels not-so-clear;
since Debian will be distributing openssl and git.
openssl guys seem to recommend adding a quote, which might be sufficient.
"This program is released under the GPL with the additional exemption that compiling, linking, and/or using OpenSSL is allowed."
http://www.openssl.org/support/faq.html#LEGAL2
> But requiring libgcrypt seems silly. Especially as the libgcrypt
> interfaces are horribly ugly, much more so than the openssl ones - so even
> if you use libgcrypt, you don't actually want to use it directly, you want
> to have much nicer wrappers around it.
I'll consider wrappers approach.
regards,
junichi
--
Junichi Uekawa, Debian Developer
17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
http://www.netfort.gr.jp/~dancer/
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Linus Torvalds @ 2005-04-17 22:35 UTC (permalink / raw)
To: Herbert Xu; +Cc: mingo, pasky, simon, david.lang, git
In-Reply-To: <E1DNI0G-0000bo-00@gondolin.me.apana.org.au>
On Mon, 18 Apr 2005, Herbert Xu wrote:
>
> Sorry, it has already been shown that combining two difference hashes
> doesn't necessarily provide the security that you would hope.
Sorry, that's not true.
Quite the reverse. Again, you bring up totally theoretical arguments. In
_practice_ it has indeed been shown that using two hashes _does_ catch
hash colissions.
The trivial example is using md5 sums with a length. The "length" is a
rally bad "hash" of the file contents too. And the fact is, that simple
combination of hashes has proven to be more resistant to attack than the
hash itself. It clearly _does_ make a difference in practice.
So _please_, can we drop the obviously bogus "in theory" arguments. They
do not matter. What matters is practice.
And the fact is, in _theory_ we don't know if somebody may be trivially
able to break any particular hash. But in practice we do know that it's
less likely that you can break a combination of two totally unrelated
hashes than you break one particular one.
NOTE! I'm not actually arguing that we should do that. I'm actually
arguing totally the reverse: I'm arguing that there is a fine line between
being "very very careful" and being "crazy to the point of being
incompetent".
Linus
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Petr Baudis @ 2005-04-17 22:30 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: Jochen Roemling, torvalds, git
In-Reply-To: <20050417150921.58d6db68.rddunlap@osdl.org>
Dear diary, on Mon, Apr 18, 2005 at 12:09:21AM CEST, I got a letter
where "Randy.Dunlap" <rddunlap@osdl.org> told me that...
> On Sun, 17 Apr 2005 23:50:40 +0200 Jochen Roemling wrote:
>
> | Linus Torvalds wrote:
> |
> | >Ie we have two phases to the merge: first get the objects, with something
> | >like
> | >
> | > repo=kernel.org:/pub/kernel/people/torvalds/linux-2.6.git
> | > rsync --ignore-existing -acv $(repo)/ .git/
> | >
> | >
> | Could you place a tarball there for people like me who are no "real"
> | kernel hackers and don't have a kernel.org account? Or is there an
> | "anonymous" account that I'm just to ignorant to know of?
>
> You don't need a kernel.org account to rsync it... this works too:
>
> rsync -avz -e ssh --progress --ignore-existing rsync://rsync.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git/ .git/
Or
mkdir linux-2.6.git
cd linux-2.6.git
RSYNC_FLAGS="--progress --stats" git init rsync://rsync.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git/
which also does the initial checkout for you. ;-) (Requires latest
git-pasky, though.) Then you can bring the latest and greatest to your
tree by a mere git pull.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: randy_dunlap @ 2005-04-17 22:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: dwmw2, git, hpa
In-Reply-To: <Pine.LNX.4.58.0504171511210.7211@ppc970.osdl.org>
On Sun, 17 Apr 2005 15:17:50 -0700 (PDT) Linus Torvalds wrote:
|
|
| On Mon, 18 Apr 2005, David Woodhouse wrote:
| >
| > Do you want the commits list running for it yet? Do you want the
| > changesets which are already in it re-mailed without a 'TESTING' tag?
|
| I really don't know. I'm actually very happy where this thing is right
| now, and completing that first merge successfully was a big milestone to
| me personally. That said, actually _using_ this thing is not for the
| faint-of-heart, and while I think "git" already is showing itself to be
| useful, I'm very very biased.
|
| In other words, I really wonder what an outsider that doesn't have the
| same kind of mental bias thinks of the current git tree. Is it useful, or
| is it still just a toy for Linus to test out his crazy SCM-wannabe.
|
| Can people usefully track my current kernel git repository, or do you have
| to be crazy to do so? That's really the question. You be the judge. Me,
| I'm just giddy from a merge that was clearly done using interfaces that
| aren't actually really usable for anybody but me, and barely me at that ;)
TBD...
| Linus
|
| Btw, I also do want this to show up in the BK trees for people who use
| BitKeeper - the same way we always supported tar-ball + patch users
| before. So I'll have to try to come up with some sane way to do that too.
| Any ideas? The first series of 198 patches is obvious enough and can be
| just done that way direcly, but the merge..
David did the commits-mailing-list script and I'm working on a
commits web-page like what was formerly seen at:
http://www.kernel.org/pub/linux/kernel/v2.6/testing/cset/
(with daily tarball)
based on some older scripts from David, however I'm wondering if
a variant of the gitlog.sh script wouldn't be a better starting
point for it.
---
~Randy
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: H. Peter Anvin @ 2005-04-17 22:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Woodhouse, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504171511210.7211@ppc970.osdl.org>
I have set up /pub/scm/linux/kernel/git on kernel.org. Everyone who had
directories in /pub/linux/kernel/people now have directories in
/pub/scm/linux/kernel/git. For non-kernel trees it would probably be
better to have different trees, however; I also would like to request
that git itself is moved to /pub/software/scm/git; I have created that
directory and made it owned by Linus.
-hpa
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Russell King @ 2005-04-17 22:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Woodhouse, Git Mailing List, Peter Anvin
In-Reply-To: <Pine.LNX.4.58.0504171511210.7211@ppc970.osdl.org>
On Sun, Apr 17, 2005 at 03:17:50PM -0700, Linus Torvalds wrote:
> Can people usefully track my current kernel git repository, or do you have
> to be crazy to do so? That's really the question. You be the judge. Me,
> I'm just giddy from a merge that was clearly done using interfaces that
> aren't actually really usable for anybody but me, and barely me at that ;)
I guess I'll have the pleasure to find that out when I update my tree
with your latest changes... which I think is a project for tomorrow.
--
Russell King
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Linus Torvalds @ 2005-04-17 22:17 UTC (permalink / raw)
To: David Woodhouse; +Cc: Git Mailing List, Peter Anvin
In-Reply-To: <1113774736.3884.4.camel@localhost.localdomain>
On Mon, 18 Apr 2005, David Woodhouse wrote:
>
> Do you want the commits list running for it yet? Do you want the
> changesets which are already in it re-mailed without a 'TESTING' tag?
I really don't know. I'm actually very happy where this thing is right
now, and completing that first merge successfully was a big milestone to
me personally. That said, actually _using_ this thing is not for the
faint-of-heart, and while I think "git" already is showing itself to be
useful, I'm very very biased.
In other words, I really wonder what an outsider that doesn't have the
same kind of mental bias thinks of the current git tree. Is it useful, or
is it still just a toy for Linus to test out his crazy SCM-wannabe.
Can people usefully track my current kernel git repository, or do you have
to be crazy to do so? That's really the question. You be the judge. Me,
I'm just giddy from a merge that was clearly done using interfaces that
aren't actually really usable for anybody but me, and barely me at that ;)
Linus
Btw, I also do want this to show up in the BK trees for people who use
BitKeeper - the same way we always supported tar-ball + patch users
before. So I'll have to try to come up with some sane way to do that too.
Any ideas? The first series of 198 patches is obvious enough and can be
just done that way direcly, but the merge..
^ permalink raw reply
* Symlinks [was Re: Storing permissions]
From: Morten Welinder @ 2005-04-17 22:15 UTC (permalink / raw)
To: git
In-Reply-To: <42628D1B.3000207@dwheeler.com>
There's one more mode bit we might actually care about: the symlink bit.
(One would store the target as the blob, presumably, but chmod isn't going
to create symlinks out of regular files.)
Morten
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Herbert Xu @ 2005-04-17 22:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: mingo, pasky, simon, david.lang, git
In-Reply-To: <Pine.LNX.4.58.0504171014430.7211@ppc970.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
>
> If we want to have any kind of confidence that the hash is reall
> yunbreakable, we should make it not just longer than 160 bits, we should
> make sure that it's two or more hashes, and that they are based on totally
> different principles.
Sorry, it has already been shown that combining two difference hashes
doesn't necessarily provide the security that you would hope.
I think what hasn't been discussed here is the cost of actually doing
the comparisons. In other words, what is the minimum number of
comparisons we can get away and still deal with hash collisions
successfully?
Once we know what the cost is then we can decide whether it's worthwhile
considering the odds involved.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Randy.Dunlap @ 2005-04-17 22:09 UTC (permalink / raw)
To: Jochen Roemling; +Cc: torvalds, git
In-Reply-To: <4262DA30.2030500@roemling.net>
On Sun, 17 Apr 2005 23:50:40 +0200 Jochen Roemling wrote:
| Linus Torvalds wrote:
|
| >Ie we have two phases to the merge: first get the objects, with something
| >like
| >
| > repo=kernel.org:/pub/kernel/people/torvalds/linux-2.6.git
| > rsync --ignore-existing -acv $(repo)/ .git/
| >
| >
| Could you place a tarball there for people like me who are no "real"
| kernel hackers and don't have a kernel.org account? Or is there an
| "anonymous" account that I'm just to ignorant to know of?
You don't need a kernel.org account to rsync it... this works too:
rsync -avz -e ssh --progress --ignore-existing rsync://rsync.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git/ .git/
| I'm just somebody who is very interested in the new things happening
| here, but I guess there will be some month to go and a lot of things to
| learn until you see the first kernel patch that is signed off by me. :-)
|
| By the way: Does the git repository include all 60.000 changes of just
| the latest version of the 17.000 file in the kernel?
It's currently just 2.6.12-rc2 (17,000 files) plus changes...
Two people have announced full history gits if you are interested
in that... Check the git email archives for mail from Ingo Molnar:
Subject: full kernel history, in patchset format
and Thomas Gleixner <tglx@linutronix.de>:
Subject: BK -> git export done
---
~Randy
^ permalink raw reply
* First ever real kernel git merge!
From: Linus Torvalds @ 2005-04-17 22:10 UTC (permalink / raw)
To: Russell King; +Cc: Git Mailing List
In-Reply-To: <20050417215854.H13233@flint.arm.linux.org.uk>
It may not be pretty, but it seems to have worked fine!
Here's my history log (with intermediate checking removed - I was being
pretty anal ;):
rsync -avz --ignore-existing master.kernel.org:/home/rmk/linux-2.6-rmk.git/ .git/
rsync -avz --ignore-existing master.kernel.org:/home/rmk/linux-2.6-rmk.git/HEAD .git/MERGE-HEAD
merge-base $(cat .git/HEAD) $(cat .git/MERGE-HEAD)
for i in e7905b2f22eb5d5308c9122b9c06c2d02473dd4f $(cat .git/HEAD) $(cat .git/MERGE-HEAD); do cat-file commit $i | head -1; done
read-tree -m cf9fd295d3048cd84c65d5e1a5a6b606bf4fddc6 9c78e08d12ae8189f3bd5e03accc39e3f08e45c9 a43c4447b2edc9fb01a6369f10c1165de4494c88
write-tree
commit-tree 7792a93eddb3f9b8e3115daab8adb3030f258ce6 -p $(cat .git/HEAD) -p $(cat .git/MERGE-HEAD)
echo 5fa17ec1c56589476c7c6a2712b10c81b3d5f85a > .git/HEAD
fsck-cache --unreachable 5fa17ec1c56589476c7c6a2712b10c81b3d5f85a
which looks really messy, because I really wanted to do each step slowly
by hand, so those magic revision numbers are just cut-and-pasted from the
results that all the previous stages had printed out.
NOTE! As expected, this merge had absolutely zero file-level clashes,
which is why I could just do the "read-tree -m" followed by a write-tree.
But it's a real merge: I had some extra commits in my tree that were not
in Russell's tree, and obviously vice versa.
Also note! The end result is not actually written back to the corrent
working directory, so to see what the merge result actually is, there's
another final phase:
read-tree 7792a93eddb3f9b8e3115daab8adb3030f258ce6
update-cache --refresh
checkout-cache -f -a
which just updates the current working directory to the results. I'm _not_
caring about old dirty state for now - the theory was to get this thing
working first, and worry about making it nice to use later.
A second note: a real "merge" thing should notice that if the "merge-base"
output ends up being one of the inputs (it one side is a strict subset of
the other side), then the merge itself should never be done, and the
script should just update directly to which-ever is non-common HEAD.
But as far as I can tell, this really did work out correctly and 100%
according to plan. As a result, if you update to my current tree, the
top-of-tree commit should be:
cat-file commit $(cat .git/HEAD)
tree 7792a93eddb3f9b8e3115daab8adb3030f258ce6
parent 8173055926cdb8534fbaed517a792bd45aed8377
parent df4449813c900973841d0fa5a9e9bc7186956e1e
author Linus Torvalds <torvalds@ppc970.osdl.org> 1113774444 -0700
committer Linus Torvalds <torvalds@ppc970.osdl.org> 1113774444 -0700
Merge with master.kernel.org:/home/rmk/linux-2.6-rmk.git - ARM changes
First ever true git merge. Let's see if it actually works.
Yehaa! It did take basically zero time, btw. Except for my bunbling about,
and the first "rsync the objects from rmk's directory" part (which wasn't
horrible, it just wasn't instantaneous like the other phases).
Btw, to see the output, you really want to have a "git log" that sorts by
date. I had an old "gitlog.sh" that did the old recursive thing, and while
it shows the right thing, the ordering ended up making it be very
non-obvious that rmk's changes had been added recently, since they ended
up being at the very bottom.
Linus
^ permalink raw reply
* (Resend) [PATCH] checkout-cache -a should not extract unmerged stages
From: Junio C Hamano @ 2005-04-17 22:00 UTC (permalink / raw)
To: Linus Torvalds, Petr Baudis; +Cc: git
In-Reply-To: <7vy8bi0y2k.fsf@assigned-by-dhcp.cox.net>
Linus,
do you have any particular reason you did not want the patch
to skip unmerged ones when "checkout-cache -a" is done, and if
so could you let me know?
Here is what happens before the patch:
$ ls -al
total 16
drwxrwsr-x 3 junio src 4096 Apr 17 14:30 ./
drwxrwsr-x 8 junio src 4096 Apr 17 14:17 ../
drwxr-sr-x 3 junio src 4096 Apr 17 14:30 .git/
-rw-rw-r-- 1 junio src 29 Apr 17 14:30 SS
$ show-files --stage
100644 9e26851b98ab7dd3a3b9653a2efb9b4de0465310 0 SS
100644 e14bafaadce6c34768ba2ff8b3c6419e8839e7d2 1 TT
100644 99ef1b30fc6d6ea186d6eac62619e1afd65ad64e 2 TT
100644 033b9385f7a29882a6b4b34f67b20e2304d3489d 3 TT
$ ../++linus/checkout-cache -a
checkout-cache: SS already exists
checkout-cache: TT already exists
checkout-cache: TT already exists
$ ls -al
total 20
drwxrwsr-x 3 junio src 4096 Apr 17 14:31 ./
drwxrwsr-x 8 junio src 4096 Apr 17 14:17 ../
drwxr-sr-x 3 junio src 4096 Apr 17 14:30 .git/
-rw-rw-r-- 1 junio src 29 Apr 17 14:30 SS
-rw-rw-r-- 1 junio src 363 Apr 17 14:31 TT
See those two warning for TT? It has extracted stage 1 and
complaining about what it has done when it goes on to extract
stage 2 and 3.
At this point what is in TT is from the stage 1.
This behaviour is somewhat defensible, in that you are giving
the user a ready access to the "original" (from stage 1), and he
can continue cat-file blob other stages to decide what to do.
But I think that the way the user wants to resolve the unmerged
state is not our business and it is not particulary useful for
the plumbing layer to assume that he would always need stage 1
contents to arrive the merged result (e.g. sdiff between stage 2
and stage 3 would not require stage 1).
With the patch, you get this:
$ checkout-cache -a
checkout-cache: SS already exists
checkout-cache: needs merge TT
$ ls -al
total 16
drwxrwsr-x 3 junio src 4096 Apr 17 14:32 ./
drwxrwsr-x 8 junio src 4096 Apr 17 14:17 ../
drwxr-sr-x 3 junio src 4096 Apr 17 14:30 .git/
-rw-rw-r-- 1 junio src 29 Apr 17 14:30 SS
I think it is consistent with this behaviour you already have
merged:
$ ../++linus/checkout-cache SS TT
checkout-cache: SS already exists
checkout-cache: TT is unmerged.
$ ls -al
total 16
drwxrwsr-x 3 junio src 4096 Apr 17 14:32 ./
drwxrwsr-x 8 junio src 4096 Apr 17 14:17 ../
drwxr-sr-x 3 junio src 4096 Apr 17 14:30 .git/
-rw-rw-r-- 1 junio src 29 Apr 17 14:30 SS
Attached is a re-diff with an updated message.
I could also send you a patch that implements an alternative
strategy. With or without "-a", checkout of unmerged files can
result in something like this:
$ checkout-cache -a
checkout-cache: SS already exists
checkout-cache: storing stage 1 for TT in TT~1~
checkout-cache: storing stage 2 for TT in TT~2~
checkout-cache: storing stage 3 for TT in TT~3~
$ ls -al
total 28
drwxrwsr-x 3 junio src 4096 Apr 17 14:55 ./
drwxrwsr-x 8 junio src 4096 Apr 17 14:17 ../
drwxr-sr-x 3 junio src 4096 Apr 17 14:30 .git/
-rw-rw-r-- 1 junio src 29 Apr 17 14:30 SS
-rw-rw-r-- 1 junio src 363 Apr 17 14:55 TT~1
-rw-rw-r-- 1 junio src 363 Apr 17 14:55 TT~2
-rw-rw-r-- 1 junio src 363 Apr 17 14:55 TT~3
Maybe these two behaviours can be controlled with another
option (say, -m).
Petr, do you think this alternative behaviour would be useful
for Cogito when it starts using "read-tree -m"?
----------------------------------------------------------------
When checkout-cache -a is run, currently it attempts to extract
all existing unmerged stages to the same destination and
complains to what it itself has done for the first stage when it
tries to extract the later stages. This is nonsensical. Just
report the unmerged state and let the user sort the mess out
using "show-files --unmerged" and "cat-file blob".
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
checkout-cache.c | 11 +++++++++++
1 files changed, 11 insertions(+)
--- ++linus/checkout-cache.c 2005-04-17 13:57:04.000000000 -0700
+++ ++junio/checkout-cache.c 2005-04-17 14:35:11.000000000 -0700
@@ -137,10 +137,21 @@
static int checkout_all(void)
{
+ struct cache_entry *unmerge_skipping = NULL;
int i;
for (i = 0; i < active_nr ; i++) {
struct cache_entry *ce = active_cache[i];
+ if (ce_stage(ce)) {
+ if (!unmerge_skipping ||
+ strcmp(unmerge_skipping->name, ce->name))
+ fprintf(stderr,
+ "checkout-cache: needs merge %s\n",
+ ce->name);
+ unmerge_skipping = ce;
+ continue;
+ }
+ unmerge_skipping = NULL;
if (checkout_entry(ce) < 0)
return -1;
}
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: David Woodhouse @ 2005-04-17 21:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Peter Anvin
In-Reply-To: <Pine.LNX.4.58.0504161543590.7211@ppc970.osdl.org>
On Sat, 2005-04-16 at 16:01 -0700, Linus Torvalds wrote:
> So I re-created the dang thing (hey, it takes just a few minutes), and
> pushed it out, and there's now an archive on kernel.org in my public
> "personal" directory called "linux-2.6.git". I'll continue the tradition
> of naming git-archive directories as "*.git", since that really ends up
> being the ".git" directory for the checked-out thing.
Do you want the commits list running for it yet? Do you want the
changesets which are already in it re-mailed without a 'TESTING' tag?
--
dwmw2
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Jochen Roemling @ 2005-04-17 21:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504161543590.7211@ppc970.osdl.org>
Linus Torvalds wrote:
>Ie we have two phases to the merge: first get the objects, with something
>like
>
> repo=kernel.org:/pub/kernel/people/torvalds/linux-2.6.git
> rsync --ignore-existing -acv $(repo)/ .git/
>
>
Could you place a tarball there for people like me who are no "real"
kernel hackers and don't have a kernel.org account? Or is there an
"anonymous" account that I'm just to ignorant to know of?
I'm just somebody who is very interested in the new things happening
here, but I guess there will be some month to go and a lot of things to
learn until you see the first kernel patch that is signed off by me. :-)
By the way: Does the git repository include all 60.000 changes of just
the latest version of the 17.000 file in the kernel?
Best regards
Jochen Römling
^ permalink raw reply
* Re: [2.1/5] Add merge-base
From: Daniel Barkalow @ 2005-04-17 21:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050417212116.GK1461@pasky.ji.cz>
On Sun, 17 Apr 2005, Petr Baudis wrote:
> Dear diary, on Sun, Apr 17, 2005 at 06:51:59PM CEST, I got a letter
> where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > merge-base finds one of the best common ancestors of a pair of commits. In
> > particular, it finds one of the ones which is fewest commits away from the
> > further of the heads.
> >
> > Signed-Off-By: Daniel Barkalow <barkalow@iabervon.org>
>
> Note that during merge with Linus (probably the most complicated I've
> got so far, but still thankfully not too painful thanks to the rej
> tool) I've decided to revert your merge-base in favour of Linus'
> version. I did this mainly to make me merging Linus less awful; we
> should probably clean it up first and decide which solution to go for in
> the first place before possibly replacing it again, I think.
Sure. I'm working on the rearrangement now.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [2.1/5] Add merge-base
From: Petr Baudis @ 2005-04-17 21:21 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.21.0504171251150.30848-100000@iabervon.org>
Dear diary, on Sun, Apr 17, 2005 at 06:51:59PM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> merge-base finds one of the best common ancestors of a pair of commits. In
> particular, it finds one of the ones which is fewest commits away from the
> further of the heads.
>
> Signed-Off-By: Daniel Barkalow <barkalow@iabervon.org>
Note that during merge with Linus (probably the most complicated I've
got so far, but still thankfully not too painful thanks to the rej
tool) I've decided to revert your merge-base in favour of Linus'
version. I did this mainly to make me merging Linus less awful; we
should probably clean it up first and decide which solution to go for in
the first place before possibly replacing it again, I think.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [4/5] Add option for hardlinkable cache of extracted blobs
From: Russell King @ 2005-04-17 20:58 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Petr Baudis, Paul Jackson, git
In-Reply-To: <Pine.LNX.4.21.0504171600310.30848-100000@iabervon.org>
On Sun, Apr 17, 2005 at 04:03:46PM -0400, Daniel Barkalow wrote:
> Actually, the documentation I've got says:
>
> "F_OK requests checking whether merely testing for the existence of the
> file would be allowed (this depends on the permissions of the directories
> in the path to the file, as given in path-name.)"
>
> So it shouldn't complain about a filename which you're allowed to try to
> stat, even if there's nothing there. And it would depend on the privs of
> the wrong user in looking at the path.
Isn't it the case that with selinux, various objects may be hidden
depending on their accessibility? I wonder if this has an effect
here.
(or what about any other security model?)
--
Russell King
^ permalink raw reply
* Re: [4/5] Add option for hardlinkable cache of extracted blobs
From: Daniel Barkalow @ 2005-04-17 20:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: Paul Jackson, git
In-Reply-To: <20050417195935.GI1461@pasky.ji.cz>
On Sun, 17 Apr 2005, Petr Baudis wrote:
> Dear diary, on Sun, Apr 17, 2005 at 09:25:17PM CEST, I got a letter
> where Paul Jackson <pj@sgi.com> told me that...
> > Petr wrote:
> > > BTW, I'd just use access(F_OK) instead of stat() it I don't care about
> >
> > I recommend _only_ using it when you require exactly the above real vs.
> > effective id behaviour.
>
> Does this distinction have any effect when doing F_OK?
Actually, the documentation I've got says:
"F_OK requests checking whether merely testing for the existence of the
file would be allowed (this depends on the permissions of the directories
in the path to the file, as given in path-name.)"
So it shouldn't complain about a filename which you're allowed to try to
stat, even if there's nothing there. And it would depend on the privs of
the wrong user in looking at the path.
-Daniel
*This .sig left intentionally blank*
^ 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