Re: Re: [ANNOUNCE] git-pasky-0.3
On Wed, Apr 13, 2005 at 09:13:39PM +0200, Petr Baudis wrote: > Dear diary, on Wed, Apr 13, 2005 at 09:03:07PM CEST, I got a letter > where Russell King <[EMAIL PROTECTED]> told me that... > > On Wed, Apr 13, 2005 at 10:35:21AM +0100, Russell King wrote: > > > I tried this today, applied my patch for BE<->LE conversions and > > > glibc-2.2 compatibility (attached, still requires cleaning though), > > > and then tried git pull. Umm, whoops. > > > > Here's an updated patch which allows me to work with a BE-based > > cache. I've just used this to grab and checkout sparse.git. > > > > Note: it also fixes my glibc-2.2 build problem with the nsec > > stat64 structures (see read-cache.c). > > > > --- cache.h > > +++ cache.h Wed Apr 13 11:23:39 2005 > > @@ -14,6 +14,12 @@ > > #include > > #include > > > > +#include > > +#define cpu_to_beuint(x) (htonl(x)) > > +#define beuint_to_cpu(x) (ntohl(x)) > > +#define cpu_to_beushort(x) (htons(x)) > > +#define beushort_to_cpu(x) (ntohs(x)) > > + > > /* > > * Basic data structures for the directory cache > > * > > What do the wrapper macros gain us? Nothing much - I don't particularly care about them. I thought someone might object to using htonl/ntohl directly. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
Dear diary, on Wed, Apr 13, 2005 at 09:03:07PM CEST, I got a letter where Russell King <[EMAIL PROTECTED]> told me that... > On Wed, Apr 13, 2005 at 10:35:21AM +0100, Russell King wrote: > > I tried this today, applied my patch for BE<->LE conversions and > > glibc-2.2 compatibility (attached, still requires cleaning though), > > and then tried git pull. Umm, whoops. > > Here's an updated patch which allows me to work with a BE-based > cache. I've just used this to grab and checkout sparse.git. > > Note: it also fixes my glibc-2.2 build problem with the nsec > stat64 structures (see read-cache.c). > > --- cache.h > +++ cache.h Wed Apr 13 11:23:39 2005 > @@ -14,6 +14,12 @@ > #include > #include > > +#include > +#define cpu_to_beuint(x) (htonl(x)) > +#define beuint_to_cpu(x) (ntohl(x)) > +#define cpu_to_beushort(x) (htons(x)) > +#define beushort_to_cpu(x) (ntohs(x)) > + > /* > * Basic data structures for the directory cache > * What do the wrapper macros gain us? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.3
On Wed, 13 Apr 2005, Petr Baudis wrote: > Dear diary, on Wed, Apr 13, 2005 at 07:01:34PM CEST, I got a letter > where Daniel Barkalow <[EMAIL PROTECTED]> told me that... > > For future reference, git is unhappy if you actually do this, because your > > HEAD won't match the (empty) contents of the new directory. The easiest > > thing is to cp -r your original, replace the shared stuff with links, and > > go from there. > > How is it unhappy? That would likely be a bug, unless you do something > which really *needs* the tree populated and doesn't make sense otherwise > (show-diff aka git diff w/o arguments, for example). If you copy HEAD without copying the files, it will then try to apply the patches which would apply to your previous directory to the empty directory, which will just give a lot of errors about missing files. If you don't copy HEAD, it tries to compare against nothing. Upon further consideration, a "checkout-cache -a" at the end of your list makes things generally happy. The next problem is that rsync is replacing the .git/objects symlink with the remote system's directory, which makes this not actually helpful. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
git mailing list (Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.3)
On Wed, 13 Apr 2005, Petr Baudis wrote: > > Dear diary, on Wed, Apr 13, 2005 at 07:01:34PM CEST, I got a letter > where Daniel Barkalow <[EMAIL PROTECTED]> told me that... > > For future reference, git is unhappy if you actually do this, because your > > HEAD won't match the (empty) contents of the new directory. The easiest > > thing is to cp -r your original, replace the shared stuff with links, and > > go from there. > > How is it unhappy? I think it's just Daniel being unhappy because he didn't do the read-tree + checkout-cache + update-cache steps ;) Btw, I'm going to stop cc'ing linux-kernel on git issues (after this email, which also acts as an announcement for people who haven't noticed already), since anybody who is interested in git can just use the "[EMAIL PROTECTED]" mailing list: echo 'subscribe git' | mail [EMAIL PROTECTED] to get you subscribed (and you'll get a message back asking you to authorize it to avoid spam - if you don't get anything back, it failed). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.3
Dear diary, on Wed, Apr 13, 2005 at 07:01:34PM CEST, I got a letter where Daniel Barkalow <[EMAIL PROTECTED]> told me that... > For future reference, git is unhappy if you actually do this, because your > HEAD won't match the (empty) contents of the new directory. The easiest > thing is to cp -r your original, replace the shared stuff with links, and > go from there. How is it unhappy? That would likely be a bug, unless you do something which really *needs* the tree populated and doesn't make sense otherwise (show-diff aka git diff w/o arguments, for example). Given that what would you copy with cp -r and wipe shortly after (objects db) is likely to be significantly larger than the working tree itself, checkout-cache would be wiser anyway. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: [ANNOUNCE] git-pasky-0.3
On Wed, 13 Apr 2005, Petr Baudis wrote: > Dear diary, on Wed, Apr 13, 2005 at 11:25:04AM CEST, I got a letter > where David Woodhouse <[EMAIL PROTECTED]> told me that... > > On Wed, 2005-04-13 at 10:59 +0200, Petr Baudis wrote: > > > Theoretically, you are never supposed to share your index if you work > > > in fully git environment. > > > > Maybe -- if we are prepared to propagate the BK myth that network > > bandwidth and disk space are free. > > > > Meanwhile, in the real world, it'd be really useful to support sharing. > > It's fine to share the objects database. If you want to share the > directory cache, you are doing something wrong, though. What do you need > it for? > > > I'd even like to see support for using multiple branches checked out of > > the same .git/ repository. We already cope with having multiple branches > > _in_ the repository -- all we need to do is cope with multiple indices > > too, so we can have different versions checked out. > > I'm working on that right now. (Well, I wish I would, if other things > didn't keep distracting me.) > > The idea is to have a command which will do something like: > > mkdir .git > ln -s $origtree/heads $origtree/objects $origtree/tags .git > cp $origtree/HEAD .git > cd .. > read-tree $(tree-id) > > Voila. Now you have a new tree with almost no current neither future > overhead. For future reference, git is unhappy if you actually do this, because your HEAD won't match the (empty) contents of the new directory. The easiest thing is to cp -r your original, replace the shared stuff with links, and go from there. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
On Wed, 13 Apr 2005, David Woodhouse wrote: > > > In other words, that index file simply _cannot_ be shared. Don't even > > think about it. Only madness will ensue. > > If I use git in my home directory I cannot _help_ but share it. > Sometimes I'm using it from a BE box, sometimes from a LE box. Should I > really be forced to use separate checkouts for each type of machine? Now, that kind of "private sharing" should certainly be ok. In fact, the only locking there is (doing the ".git/index.lock" thing around any updates and erroring out if it already exists) was somewhat designed for that. So making it use BE data (preferred just because then you can use the existing htonl() etc helpers in user space) would work. As long as people don't think this means anything else... It really is a private file. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
On Wed, 13 Apr 2005, Ingo Molnar wrote: > > > > I've already noticed GNU interactive tools (googling for git), but > > it's Linus' choice of name. Alternative suggestions welcomed. What > > about 'gt'? ;-) > > 'gt' or 'gi' both sound fine - 'gi' being a bit faster to type ;-). > (Even 'get' seems to be unused in the command namespace.) Let's be realistic here. "git" as in "gnu interactive tools" was last actively developed in 1996, and had even its last maintenanace release over five years ago. Let it go, people. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
On Wed, 2005-04-13 at 07:38 -0700, Linus Torvalds wrote: > David, we already can. The objects are _designed_ to be shared. > > However, that is the ".git/objects" subdirectory. Not the per-view stuff. > For each _view_ you do need to have view-specific data, and the view index > very much is that. That's ".git/index". Yep, it takes very little to achieve that -- to allow multiple checked- out trees from a single object database. Petr's already outlined what it takes. > In other words, that index file simply _cannot_ be shared. Don't even > think about it. Only madness will ensue. If I use git in my home directory I cannot _help_ but share it. Sometimes I'm using it from a BE box, sometimes from a LE box. Should I really be forced to use separate checkouts for each type of machine? It's bad enough having to do that for ~/bin :) Seriously, it shouldn't have a significantly detrimental effect on the performance if we just use explicitly sized types and fixed byte-order. It's just not worth the pain of being gratuitously non-portable. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
On Wed, 13 Apr 2005, David Woodhouse wrote: > > I'd even like to see support for using multiple branches checked out of > the same .git/ repository. David, we already can. The objects are _designed_ to be shared. However, that is the ".git/objects" subdirectory. Not the per-view stuff. For each _view_ you do need to have view-specific data, and the view index very much is that. That's ".git/index". The index file isn't small - it's about 1.6MB for a kernel tree, because it needs to list every single file we know about, its "stat" information, and it's sha1 backing store. So multiply 17,000 by ~40, and add in the size of the name of each file, and avoid compression because this is read and written _all_ the time, and you end up with 1.6MB. But you _need_ one per checked-out tree. And it really _is_ private. It's not supposed to be shared. In fact, it _cannot_ be shared, because it doesn't have sufficient locking (it has some, but that's just to catch _errors_ when somebody tries to do two operations that update the index file at the same time in the same view). But even ignoring the locking issues, it just isn't appropriate, it's not how that file works. In other words, that index file simply _cannot_ be shared. Don't even think about it. Only madness will ensue. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
Le mercredi 13 avril 2005 Ã 10:25 +0100, David Woodhouse a Ãcrit : > On Wed, 2005-04-13 at 10:59 +0200, Petr Baudis wrote: > > Theoretically, you are never supposed to share your index if you work > > in fully git environment. > > Maybe -- if we are prepared to propagate the BK myth that network > bandwidth and disk space are free. On a related note, maybe kernel.org should host .torrent files (and serve them) for the kernel git repository. That would ease the pain. Xav - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
* Petr Baudis <[EMAIL PROTECTED]> wrote: > > Oh, and the other thing is: > > > > $ git pull > > > > GNU Interactive Tools 4.3.20 (armv4l-rmk-linux-gnu), 20:02:38 Mar 7 2001 > > GIT is free software; you can redistribute it and/or modify it under the > > terms of the GNU General Public License as published by the Free Software > > Foundation; either version 2, or (at your option) any later version. > > Copyright (C) 1993-1999 Free Software Foundation, Inc. > > Written by Tudor Hulubei and Andrei Pitis, Bucharest, Romania > > > > git: fatal error: `chdir' failed: permission denied. > > > > "git" already exists as a command from about 4 years ago. Can we have > > less TLAs for commands please? That namespace is rather over-used and > > collision-prone. > > I've already noticed GNU interactive tools (googling for git), but > it's Linus' choice of name. Alternative suggestions welcomed. What > about 'gt'? ;-) 'gt' or 'gi' both sound fine - 'gi' being a bit faster to type ;-). (Even 'get' seems to be unused in the command namespace.) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
On Wed, Apr 13, 2005 at 11:46:19AM +0200, Petr Baudis wrote: > I'll bet at the top of this you have a mktemp error. Indeed, thanks. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: [ANNOUNCE] git-pasky-0.3
On Wed, 2005-04-13 at 11:42 +0200, Petr Baudis wrote: > It's fine to share the objects database. If you want to share the > directory cache, you are doing something wrong, though. What do you > need it for? I want to _not_ care which machine I happen to be on when I use git repositories which live in my home directory. I want all operations to just work, regardless of whether the shell I'm looking at happens to be on a BE or a LE box. > <...> Would this do what you want? Sounds ideal. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
Dear diary, on Wed, Apr 13, 2005 at 11:38:52AM CEST, I got a letter where Russell King <[EMAIL PROTECTED]> told me that... > On Wed, Apr 13, 2005 at 10:35:21AM +0100, Russell King wrote: > > On Mon, Apr 11, 2005 at 03:57:58PM +0200, Petr Baudis wrote: > > > here goes git-pasky-0.3, my set of patches and scripts upon > > > Linus' git, aimed at human usability and to an extent a SCM-like usage. > > > > I tried this today, applied my patch for BE<->LE conversions and > > glibc-2.2 compatibility (attached, still requires cleaning though), > > and then tried git pull. Umm, whoops. > > Oh, and the other thing is: > > $ git pull > > GNU Interactive Tools 4.3.20 (armv4l-rmk-linux-gnu), 20:02:38 Mar 7 2001 > GIT is free software; you can redistribute it and/or modify it under the > terms of the GNU General Public License as published by the Free Software > Foundation; either version 2, or (at your option) any later version. > Copyright (C) 1993-1999 Free Software Foundation, Inc. > Written by Tudor Hulubei and Andrei Pitis, Bucharest, Romania > > git: fatal error: `chdir' failed: permission denied. > > "git" already exists as a command from about 4 years ago. Can we have > less TLAs for commands please? That namespace is rather over-used and > collision-prone. I've already noticed GNU interactive tools (googling for git), but it's Linus' choice of name. Alternative suggestions welcomed. What about 'gt'? ;-) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
Dear diary, on Wed, Apr 13, 2005 at 11:35:21AM CEST, I got a letter where Russell King <[EMAIL PROTECTED]> told me that... > On Mon, Apr 11, 2005 at 03:57:58PM +0200, Petr Baudis wrote: > > here goes git-pasky-0.3, my set of patches and scripts upon > > Linus' git, aimed at human usability and to an extent a SCM-like usage. > > I tried this today, applied my patch for BE<->LE conversions and > glibc-2.2 compatibility (attached, still requires cleaning though), > and then tried git pull. Umm, whoops. > > Here's just a small sample of what happened: > > diff: /9a30ec42a6c4860d3f11ad90c1052823a020de32/show-files.c: No such file or > directory > diff: /85bf824bd24f034896f5820a2628148a246f8fd1/show-files.c: No such file or > directory > mkdir: cannot create directory `/9a30ec42a6c4860d3f11ad90c1052823a020de32': > Permission denied > mkdir: cannot create directory `/85bf824bd24f034896f5820a2628148a246f8fd1': > Permission denied > ./gitdiff-do: /9a30ec42a6c4860d3f11ad90c1052823a020de32/update-cache.c: No > such > file or directory > ./gitdiff-do: /85bf824bd24f034896f5820a2628148a246f8fd1/update-cache.c: No > such > file or directory > diff: /9a30ec42a6c4860d3f11ad90c1052823a020de32/update-cache.c: No such file > or > directory > diff: /85bf824bd24f034896f5820a2628148a246f8fd1/update-cache.c: No such file > or > directory > patch: Only garbage was found in the patch input. I'll bet at the top of this you have a mktemp error. mktemp turns out to be a PITA to use - on some older systems (e.g. Mandrake 10 stock install) it has incompatible usage to the rest of the world. When I will get a convenient infrastructure for making a shell library, I will probably add a test for this to it. Try to upgrade your mktemp. That Mandrake 10 user said that urpmi should have a newer (correct) version. I will make a patch which will refer to ?time instead instead of ?tim.sec for seconds. That should fix your problem. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: [ANNOUNCE] git-pasky-0.3
Dear diary, on Wed, Apr 13, 2005 at 11:25:04AM CEST, I got a letter where David Woodhouse <[EMAIL PROTECTED]> told me that... > On Wed, 2005-04-13 at 10:59 +0200, Petr Baudis wrote: > > Theoretically, you are never supposed to share your index if you work > > in fully git environment. > > Maybe -- if we are prepared to propagate the BK myth that network > bandwidth and disk space are free. > > Meanwhile, in the real world, it'd be really useful to support sharing. It's fine to share the objects database. If you want to share the directory cache, you are doing something wrong, though. What do you need it for? > I'd even like to see support for using multiple branches checked out of > the same .git/ repository. We already cope with having multiple branches > _in_ the repository -- all we need to do is cope with multiple indices > too, so we can have different versions checked out. I'm working on that right now. (Well, I wish I would, if other things didn't keep distracting me.) The idea is to have a command which will do something like: mkdir .git ln -s $origtree/heads $origtree/objects $origtree/tags .git cp $origtree/HEAD .git cd .. read-tree $(tree-id) Voila. Now you have a new tree with almost no current neither future overhead. This will be used to do the out-tree merges. Command for user to do this will likely also make it a regular branch, doing ln -s $(realpath git/HEAD) .git/heads/branchname so that you can reference to it easily from your other branches. Would this do what you want? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
On Wed, 2005-04-13 at 10:59 +0200, Petr Baudis wrote: > Theoretically, you are never supposed to share your index if you work > in fully git environment. Maybe -- if we are prepared to propagate the BK myth that network bandwidth and disk space are free. Meanwhile, in the real world, it'd be really useful to support sharing. I'd even like to see support for using multiple branches checked out of the same .git/ repository. We already cope with having multiple branches _in_ the repository -- all we need to do is cope with multiple indices too, so we can have different versions checked out. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
Dear diary, on Wed, Apr 13, 2005 at 10:47:05AM CEST, I got a letter where Russell King <[EMAIL PROTECTED]> told me that... > On Tue, Apr 12, 2005 at 02:07:36PM +0100, David Woodhouse wrote: > > I'd suggest making it [index] big-endian to make sure the LE weenies don't > > forget to byteswap properly. > > That's not a bad argument actually - especially as networking uses BE. > (and git is about networking, right?) 8) Theoretically, you are never supposed to share your index if you work in fully git environment. However, I offer some "base tarballs" which have the unpacked source as well as the .git directory, and I think you want the index there. Of course you can always regenerate it by read-tree $(tree-id) but I really don't want to (hey, dwmw got away with that too! ;-). It forces an additional out-of-order step you need to do before making use of your git for the first time. The NFS argument obviously seems perfectly valid to me too. So, FWIW, I'm personally all for it, if someone gives me a patch. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
Dear diary, on Wed, Apr 13, 2005 at 10:47:05AM CEST, I got a letter where Russell King [EMAIL PROTECTED] told me that... On Tue, Apr 12, 2005 at 02:07:36PM +0100, David Woodhouse wrote: I'd suggest making it [index] big-endian to make sure the LE weenies don't forget to byteswap properly. That's not a bad argument actually - especially as networking uses BE. (and git is about networking, right?) 8) Theoretically, you are never supposed to share your index if you work in fully git environment. However, I offer some base tarballs which have the unpacked source as well as the .git directory, and I think you want the index there. Of course you can always regenerate it by read-tree $(tree-id) but I really don't want to (hey, dwmw got away with that too! ;-). It forces an additional out-of-order step you need to do before making use of your git for the first time. The NFS argument obviously seems perfectly valid to me too. So, FWIW, I'm personally all for it, if someone gives me a patch. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
On Wed, 2005-04-13 at 10:59 +0200, Petr Baudis wrote: Theoretically, you are never supposed to share your index if you work in fully git environment. Maybe -- if we are prepared to propagate the BK myth that network bandwidth and disk space are free. Meanwhile, in the real world, it'd be really useful to support sharing. I'd even like to see support for using multiple branches checked out of the same .git/ repository. We already cope with having multiple branches _in_ the repository -- all we need to do is cope with multiple indices too, so we can have different versions checked out. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: [ANNOUNCE] git-pasky-0.3
Dear diary, on Wed, Apr 13, 2005 at 11:25:04AM CEST, I got a letter where David Woodhouse [EMAIL PROTECTED] told me that... On Wed, 2005-04-13 at 10:59 +0200, Petr Baudis wrote: Theoretically, you are never supposed to share your index if you work in fully git environment. Maybe -- if we are prepared to propagate the BK myth that network bandwidth and disk space are free. Meanwhile, in the real world, it'd be really useful to support sharing. It's fine to share the objects database. If you want to share the directory cache, you are doing something wrong, though. What do you need it for? I'd even like to see support for using multiple branches checked out of the same .git/ repository. We already cope with having multiple branches _in_ the repository -- all we need to do is cope with multiple indices too, so we can have different versions checked out. I'm working on that right now. (Well, I wish I would, if other things didn't keep distracting me.) The idea is to have a command which will do something like: mkdir .git ln -s $origtree/heads $origtree/objects $origtree/tags .git cp $origtree/HEAD .git cd .. read-tree $(tree-id) Voila. Now you have a new tree with almost no current neither future overhead. This will be used to do the out-tree merges. Command for user to do this will likely also make it a regular branch, doing ln -s $(realpath git/HEAD) .git/heads/branchname so that you can reference to it easily from your other branches. Would this do what you want? -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
Dear diary, on Wed, Apr 13, 2005 at 11:35:21AM CEST, I got a letter where Russell King [EMAIL PROTECTED] told me that... On Mon, Apr 11, 2005 at 03:57:58PM +0200, Petr Baudis wrote: here goes git-pasky-0.3, my set of patches and scripts upon Linus' git, aimed at human usability and to an extent a SCM-like usage. I tried this today, applied my patch for BE-LE conversions and glibc-2.2 compatibility (attached, still requires cleaning though), and then tried git pull. Umm, whoops. Here's just a small sample of what happened: diff: /9a30ec42a6c4860d3f11ad90c1052823a020de32/show-files.c: No such file or directory diff: /85bf824bd24f034896f5820a2628148a246f8fd1/show-files.c: No such file or directory mkdir: cannot create directory `/9a30ec42a6c4860d3f11ad90c1052823a020de32': Permission denied mkdir: cannot create directory `/85bf824bd24f034896f5820a2628148a246f8fd1': Permission denied ./gitdiff-do: /9a30ec42a6c4860d3f11ad90c1052823a020de32/update-cache.c: No such file or directory ./gitdiff-do: /85bf824bd24f034896f5820a2628148a246f8fd1/update-cache.c: No such file or directory diff: /9a30ec42a6c4860d3f11ad90c1052823a020de32/update-cache.c: No such file or directory diff: /85bf824bd24f034896f5820a2628148a246f8fd1/update-cache.c: No such file or directory patch: Only garbage was found in the patch input. I'll bet at the top of this you have a mktemp error. mktemp turns out to be a PITA to use - on some older systems (e.g. Mandrake 10 stock install) it has incompatible usage to the rest of the world. When I will get a convenient infrastructure for making a shell library, I will probably add a test for this to it. Try to upgrade your mktemp. That Mandrake 10 user said that urpmi should have a newer (correct) version. I will make a patch which will refer to ?time instead instead of ?tim.sec for seconds. That should fix your problem. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
Dear diary, on Wed, Apr 13, 2005 at 11:38:52AM CEST, I got a letter where Russell King [EMAIL PROTECTED] told me that... On Wed, Apr 13, 2005 at 10:35:21AM +0100, Russell King wrote: On Mon, Apr 11, 2005 at 03:57:58PM +0200, Petr Baudis wrote: here goes git-pasky-0.3, my set of patches and scripts upon Linus' git, aimed at human usability and to an extent a SCM-like usage. I tried this today, applied my patch for BE-LE conversions and glibc-2.2 compatibility (attached, still requires cleaning though), and then tried git pull. Umm, whoops. Oh, and the other thing is: $ git pull GNU Interactive Tools 4.3.20 (armv4l-rmk-linux-gnu), 20:02:38 Mar 7 2001 GIT is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. Copyright (C) 1993-1999 Free Software Foundation, Inc. Written by Tudor Hulubei and Andrei Pitis, Bucharest, Romania git: fatal error: `chdir' failed: permission denied. git already exists as a command from about 4 years ago. Can we have less TLAs for commands please? That namespace is rather over-used and collision-prone. I've already noticed GNU interactive tools (googling for git), but it's Linus' choice of name. Alternative suggestions welcomed. What about 'gt'? ;-) -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: [ANNOUNCE] git-pasky-0.3
On Wed, 2005-04-13 at 11:42 +0200, Petr Baudis wrote: It's fine to share the objects database. If you want to share the directory cache, you are doing something wrong, though. What do you need it for? I want to _not_ care which machine I happen to be on when I use git repositories which live in my home directory. I want all operations to just work, regardless of whether the shell I'm looking at happens to be on a BE or a LE box. ... Would this do what you want? Sounds ideal. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
On Wed, Apr 13, 2005 at 11:46:19AM +0200, Petr Baudis wrote: I'll bet at the top of this you have a mktemp error. Indeed, thanks. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
* Petr Baudis [EMAIL PROTECTED] wrote: Oh, and the other thing is: $ git pull GNU Interactive Tools 4.3.20 (armv4l-rmk-linux-gnu), 20:02:38 Mar 7 2001 GIT is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. Copyright (C) 1993-1999 Free Software Foundation, Inc. Written by Tudor Hulubei and Andrei Pitis, Bucharest, Romania git: fatal error: `chdir' failed: permission denied. git already exists as a command from about 4 years ago. Can we have less TLAs for commands please? That namespace is rather over-used and collision-prone. I've already noticed GNU interactive tools (googling for git), but it's Linus' choice of name. Alternative suggestions welcomed. What about 'gt'? ;-) 'gt' or 'gi' both sound fine - 'gi' being a bit faster to type ;-). (Even 'get' seems to be unused in the command namespace.) Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
Le mercredi 13 avril 2005 10:25 +0100, David Woodhouse a crit : On Wed, 2005-04-13 at 10:59 +0200, Petr Baudis wrote: Theoretically, you are never supposed to share your index if you work in fully git environment. Maybe -- if we are prepared to propagate the BK myth that network bandwidth and disk space are free. On a related note, maybe kernel.org should host .torrent files (and serve them) for the kernel git repository. That would ease the pain. Xav - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
On Wed, 13 Apr 2005, David Woodhouse wrote: I'd even like to see support for using multiple branches checked out of the same .git/ repository. David, we already can. The objects are _designed_ to be shared. However, that is the .git/objects subdirectory. Not the per-view stuff. For each _view_ you do need to have view-specific data, and the view index very much is that. That's .git/index. The index file isn't small - it's about 1.6MB for a kernel tree, because it needs to list every single file we know about, its stat information, and it's sha1 backing store. So multiply 17,000 by ~40, and add in the size of the name of each file, and avoid compression because this is read and written _all_ the time, and you end up with 1.6MB. But you _need_ one per checked-out tree. And it really _is_ private. It's not supposed to be shared. In fact, it _cannot_ be shared, because it doesn't have sufficient locking (it has some, but that's just to catch _errors_ when somebody tries to do two operations that update the index file at the same time in the same view). But even ignoring the locking issues, it just isn't appropriate, it's not how that file works. In other words, that index file simply _cannot_ be shared. Don't even think about it. Only madness will ensue. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
On Wed, 2005-04-13 at 07:38 -0700, Linus Torvalds wrote: David, we already can. The objects are _designed_ to be shared. However, that is the .git/objects subdirectory. Not the per-view stuff. For each _view_ you do need to have view-specific data, and the view index very much is that. That's .git/index. Yep, it takes very little to achieve that -- to allow multiple checked- out trees from a single object database. Petr's already outlined what it takes. In other words, that index file simply _cannot_ be shared. Don't even think about it. Only madness will ensue. If I use git in my home directory I cannot _help_ but share it. Sometimes I'm using it from a BE box, sometimes from a LE box. Should I really be forced to use separate checkouts for each type of machine? It's bad enough having to do that for ~/bin :) Seriously, it shouldn't have a significantly detrimental effect on the performance if we just use explicitly sized types and fixed byte-order. It's just not worth the pain of being gratuitously non-portable. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
On Wed, 13 Apr 2005, Ingo Molnar wrote: I've already noticed GNU interactive tools (googling for git), but it's Linus' choice of name. Alternative suggestions welcomed. What about 'gt'? ;-) 'gt' or 'gi' both sound fine - 'gi' being a bit faster to type ;-). (Even 'get' seems to be unused in the command namespace.) Let's be realistic here. git as in gnu interactive tools was last actively developed in 1996, and had even its last maintenanace release over five years ago. Let it go, people. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
On Wed, 13 Apr 2005, David Woodhouse wrote: In other words, that index file simply _cannot_ be shared. Don't even think about it. Only madness will ensue. If I use git in my home directory I cannot _help_ but share it. Sometimes I'm using it from a BE box, sometimes from a LE box. Should I really be forced to use separate checkouts for each type of machine? Now, that kind of private sharing should certainly be ok. In fact, the only locking there is (doing the .git/index.lock thing around any updates and erroring out if it already exists) was somewhat designed for that. So making it use BE data (preferred just because then you can use the existing htonl() etc helpers in user space) would work. As long as people don't think this means anything else... It really is a private file. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: [ANNOUNCE] git-pasky-0.3
On Wed, 13 Apr 2005, Petr Baudis wrote: Dear diary, on Wed, Apr 13, 2005 at 11:25:04AM CEST, I got a letter where David Woodhouse [EMAIL PROTECTED] told me that... On Wed, 2005-04-13 at 10:59 +0200, Petr Baudis wrote: Theoretically, you are never supposed to share your index if you work in fully git environment. Maybe -- if we are prepared to propagate the BK myth that network bandwidth and disk space are free. Meanwhile, in the real world, it'd be really useful to support sharing. It's fine to share the objects database. If you want to share the directory cache, you are doing something wrong, though. What do you need it for? I'd even like to see support for using multiple branches checked out of the same .git/ repository. We already cope with having multiple branches _in_ the repository -- all we need to do is cope with multiple indices too, so we can have different versions checked out. I'm working on that right now. (Well, I wish I would, if other things didn't keep distracting me.) The idea is to have a command which will do something like: mkdir .git ln -s $origtree/heads $origtree/objects $origtree/tags .git cp $origtree/HEAD .git cd .. read-tree $(tree-id) Voila. Now you have a new tree with almost no current neither future overhead. For future reference, git is unhappy if you actually do this, because your HEAD won't match the (empty) contents of the new directory. The easiest thing is to cp -r your original, replace the shared stuff with links, and go from there. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.3
Dear diary, on Wed, Apr 13, 2005 at 07:01:34PM CEST, I got a letter where Daniel Barkalow [EMAIL PROTECTED] told me that... For future reference, git is unhappy if you actually do this, because your HEAD won't match the (empty) contents of the new directory. The easiest thing is to cp -r your original, replace the shared stuff with links, and go from there. How is it unhappy? That would likely be a bug, unless you do something which really *needs* the tree populated and doesn't make sense otherwise (show-diff aka git diff w/o arguments, for example). Given that what would you copy with cp -r and wipe shortly after (objects db) is likely to be significantly larger than the working tree itself, checkout-cache would be wiser anyway. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
git mailing list (Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.3)
On Wed, 13 Apr 2005, Petr Baudis wrote: Dear diary, on Wed, Apr 13, 2005 at 07:01:34PM CEST, I got a letter where Daniel Barkalow [EMAIL PROTECTED] told me that... For future reference, git is unhappy if you actually do this, because your HEAD won't match the (empty) contents of the new directory. The easiest thing is to cp -r your original, replace the shared stuff with links, and go from there. How is it unhappy? I think it's just Daniel being unhappy because he didn't do the read-tree + checkout-cache + update-cache steps ;) Btw, I'm going to stop cc'ing linux-kernel on git issues (after this email, which also acts as an announcement for people who haven't noticed already), since anybody who is interested in git can just use the [EMAIL PROTECTED] mailing list: echo 'subscribe git' | mail [EMAIL PROTECTED] to get you subscribed (and you'll get a message back asking you to authorize it to avoid spam - if you don't get anything back, it failed). Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.3
On Wed, 13 Apr 2005, Petr Baudis wrote: Dear diary, on Wed, Apr 13, 2005 at 07:01:34PM CEST, I got a letter where Daniel Barkalow [EMAIL PROTECTED] told me that... For future reference, git is unhappy if you actually do this, because your HEAD won't match the (empty) contents of the new directory. The easiest thing is to cp -r your original, replace the shared stuff with links, and go from there. How is it unhappy? That would likely be a bug, unless you do something which really *needs* the tree populated and doesn't make sense otherwise (show-diff aka git diff w/o arguments, for example). If you copy HEAD without copying the files, it will then try to apply the patches which would apply to your previous directory to the empty directory, which will just give a lot of errors about missing files. If you don't copy HEAD, it tries to compare against nothing. Upon further consideration, a checkout-cache -a at the end of your list makes things generally happy. The next problem is that rsync is replacing the .git/objects symlink with the remote system's directory, which makes this not actually helpful. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
Dear diary, on Wed, Apr 13, 2005 at 09:03:07PM CEST, I got a letter where Russell King [EMAIL PROTECTED] told me that... On Wed, Apr 13, 2005 at 10:35:21AM +0100, Russell King wrote: I tried this today, applied my patch for BE-LE conversions and glibc-2.2 compatibility (attached, still requires cleaning though), and then tried git pull. Umm, whoops. Here's an updated patch which allows me to work with a BE-based cache. I've just used this to grab and checkout sparse.git. Note: it also fixes my glibc-2.2 build problem with the nsec stat64 structures (see read-cache.c). --- cache.h +++ cache.h Wed Apr 13 11:23:39 2005 @@ -14,6 +14,12 @@ #include openssl/sha.h #include zlib.h +#include netinet/in.h +#define cpu_to_beuint(x) (htonl(x)) +#define beuint_to_cpu(x) (ntohl(x)) +#define cpu_to_beushort(x) (htons(x)) +#define beushort_to_cpu(x) (ntohs(x)) + /* * Basic data structures for the directory cache * What do the wrapper macros gain us? -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
On Wed, Apr 13, 2005 at 09:13:39PM +0200, Petr Baudis wrote: Dear diary, on Wed, Apr 13, 2005 at 09:03:07PM CEST, I got a letter where Russell King [EMAIL PROTECTED] told me that... On Wed, Apr 13, 2005 at 10:35:21AM +0100, Russell King wrote: I tried this today, applied my patch for BE-LE conversions and glibc-2.2 compatibility (attached, still requires cleaning though), and then tried git pull. Umm, whoops. Here's an updated patch which allows me to work with a BE-based cache. I've just used this to grab and checkout sparse.git. Note: it also fixes my glibc-2.2 build problem with the nsec stat64 structures (see read-cache.c). --- cache.h +++ cache.h Wed Apr 13 11:23:39 2005 @@ -14,6 +14,12 @@ #include openssl/sha.h #include zlib.h +#include netinet/in.h +#define cpu_to_beuint(x) (htonl(x)) +#define beuint_to_cpu(x) (ntohl(x)) +#define cpu_to_beushort(x) (htons(x)) +#define beushort_to_cpu(x) (ntohs(x)) + /* * Basic data structures for the directory cache * What do the wrapper macros gain us? Nothing much - I don't particularly care about them. I thought someone might object to using htonl/ntohl directly. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: [ANNOUNCE] git-pasky-0.3
Dear diary, on Tue, Apr 12, 2005 at 03:13:15PM CEST, I got a letter where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > On Tue, 2005-04-12 at 15:02 +0200, Petr Baudis wrote: > > Dear diary, on Tue, Apr 12, 2005 at 02:47:25PM CEST, I got a letter > > where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > > > On Mon, 2005-04-11 at 15:57 +0200, Petr Baudis wrote: > > > > Hello, > > > > > > > > here goes git-pasky-0.3, my set of patches and scripts upon > > > > Linus' git, aimed at human usability and to an extent a SCM-like usage. > > > > > > > > > > Its pretty dependant on where VERSION is located. This patch fixes > > > that. (PS, I left the output of 'git diff' as is to ask about the > > > following stuff after the proper diff ...) > > > > Thanks, applied. I don't understand your PS, though. :-) > > > > Heh, yeah I do that sometimes. Basically should 'git diff' output > anything (besides maybe not added files like cvs ... sorry, do not know > after what you fashion it) like it does now? Huh. Well, git diff without any arguments should just call show-diff. That is show your local uncommitted changes. It doesn't show the locally added/removed files yet for several reasons, but it's being worked on. :-) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
On Tue, 2005-04-12 at 15:02 +0200, Petr Baudis wrote: > Dear diary, on Tue, Apr 12, 2005 at 02:47:25PM CEST, I got a letter > where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > > On Mon, 2005-04-11 at 15:57 +0200, Petr Baudis wrote: > > > Hello, > > > > > > here goes git-pasky-0.3, my set of patches and scripts upon > > > Linus' git, aimed at human usability and to an extent a SCM-like usage. > > > > > > > Its pretty dependant on where VERSION is located. This patch fixes > > that. (PS, I left the output of 'git diff' as is to ask about the > > following stuff after the proper diff ...) > > Thanks, applied. I don't understand your PS, though. :-) > Heh, yeah I do that sometimes. Basically should 'git diff' output anything (besides maybe not added files like cvs ... sorry, do not know after what you fashion it) like it does now? -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: Re: [ANNOUNCE] git-pasky-0.3
Dear diary, on Tue, Apr 12, 2005 at 02:47:25PM CEST, I got a letter where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > On Mon, 2005-04-11 at 15:57 +0200, Petr Baudis wrote: > > Hello, > > > > here goes git-pasky-0.3, my set of patches and scripts upon > > Linus' git, aimed at human usability and to an extent a SCM-like usage. > > > > Its pretty dependant on where VERSION is located. This patch fixes > that. (PS, I left the output of 'git diff' as is to ask about the > following stuff after the proper diff ...) Thanks, applied. I don't understand your PS, though. :-) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
Dear diary, on Tue, Apr 12, 2005 at 02:47:25PM CEST, I got a letter where Martin Schlemmer [EMAIL PROTECTED] told me that... On Mon, 2005-04-11 at 15:57 +0200, Petr Baudis wrote: Hello, here goes git-pasky-0.3, my set of patches and scripts upon Linus' git, aimed at human usability and to an extent a SCM-like usage. Its pretty dependant on where VERSION is located. This patch fixes that. (PS, I left the output of 'git diff' as is to ask about the following stuff after the proper diff ...) Thanks, applied. I don't understand your PS, though. :-) -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.3
On Tue, 2005-04-12 at 15:02 +0200, Petr Baudis wrote: Dear diary, on Tue, Apr 12, 2005 at 02:47:25PM CEST, I got a letter where Martin Schlemmer [EMAIL PROTECTED] told me that... On Mon, 2005-04-11 at 15:57 +0200, Petr Baudis wrote: Hello, here goes git-pasky-0.3, my set of patches and scripts upon Linus' git, aimed at human usability and to an extent a SCM-like usage. Its pretty dependant on where VERSION is located. This patch fixes that. (PS, I left the output of 'git diff' as is to ask about the following stuff after the proper diff ...) Thanks, applied. I don't understand your PS, though. :-) Heh, yeah I do that sometimes. Basically should 'git diff' output anything (besides maybe not added files like cvs ... sorry, do not know after what you fashion it) like it does now? -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: Re: Re: [ANNOUNCE] git-pasky-0.3
Dear diary, on Tue, Apr 12, 2005 at 03:13:15PM CEST, I got a letter where Martin Schlemmer [EMAIL PROTECTED] told me that... On Tue, 2005-04-12 at 15:02 +0200, Petr Baudis wrote: Dear diary, on Tue, Apr 12, 2005 at 02:47:25PM CEST, I got a letter where Martin Schlemmer [EMAIL PROTECTED] told me that... On Mon, 2005-04-11 at 15:57 +0200, Petr Baudis wrote: Hello, here goes git-pasky-0.3, my set of patches and scripts upon Linus' git, aimed at human usability and to an extent a SCM-like usage. Its pretty dependant on where VERSION is located. This patch fixes that. (PS, I left the output of 'git diff' as is to ask about the following stuff after the proper diff ...) Thanks, applied. I don't understand your PS, though. :-) Heh, yeah I do that sometimes. Basically should 'git diff' output anything (besides maybe not added files like cvs ... sorry, do not know after what you fashion it) like it does now? Huh. Well, git diff without any arguments should just call show-diff. That is show your local uncommitted changes. It doesn't show the locally added/removed files yet for several reasons, but it's being worked on. :-) -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
