* git merge
From: Petr Baudis @ 2005-04-14 22:11 UTC (permalink / raw)
To: git; +Cc: torvalds
In-Reply-To: <20050414002902.GU25711@pasky.ji.cz>
Hi,
note that in my git tree there is a git merge implementation which
does out-of-tree merges now. It is still very trivial, and basically
just does something along the lines of (symbolically written)
checkout-cache $(diff-tree)
git diff $base $mergedbranch | git apply
.. fix rejects etc ..
git commit
It seems to work, but it is only very lightly tested - it is likely
there are various tiny mistakes and typos in various unusual code paths
and other weird corners of the scripts. Testing is encouraged, and
especially patches fixing bugs you come over.
It is designed in a way to make it possible to just replace the
checkout-cache and git diff | git apply steps with the merge-tree.pl
tool when it is finished.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* [ANNOUNCE] Archives of git at MARC
From: Hank Leininger @ 2005-04-14 22:12 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Courtesy of Randy Dunlap, MARC now has full(?) archives for the git
list, actually stretching a bit back to the pre-git-list discussions on
linux-kernel, available at:
http://marc.theaimsgroup.com/?l=git
[ Apologies if this mail crisscrosses with a similar announcement by
Randy. ]
Thanks,
Hank Leininger <hlein@progressive-comp.com>
E407 AEF4 761E D39C D401 D4F4 22F8 EF11 861A A6F1
-----BEGIN PGP SIGNATURE-----
iD8DBQFCXurBIvjvEYYapvERAn6PAJ4ztS51oqIiO060fImnDcQysyoQGgCeICQ8
6rJXDPbnUUC+sQ15kzCGuoY=
=iu3s
-----END PGP SIGNATURE-----
^ permalink raw reply
* another perspective on renames.
From: C. Scott Ananian @ 2005-04-14 22:22 UTC (permalink / raw)
To: git
Perhaps our thinking is being clouded by 'how other SCMs do things' ---
do we *really* need extra rename metadata? As Linus pointed out, as long
as a commit is done immediately after a rename (ie before the renamed file
is changed) the tree object contains all the information one needs: you
can notice that a given object's content-hash is named 'foo' in the first
version and 'bar' in the second version.
Ingo thought that this was insufficient because two *different* objects
(ie having different revision histories) might be mutated to a point where
they had a *same* contents (and then would be condensed into a single
blob). But isn't that a feature of the git-fs history generally (ie not a
renaming-specific issue)?
One solution would be to invent a new 'file-revision-history' annotation
on top of git-fs in order to keep these derivation paths seperate...
...but perhaps we might think of this as a 'feature' of our SCM instead?
The 'history' of a file may have join points where a single 'content' may
have been derived by two or more completely different paths. Explicit
guidance to the front-end tools is required to 'unmerge' these files after
this occurs (ie updating the directory cache for one, but not the others).
This makes sense for include/arch/{foo,bar}/baz.h, but maybe not so much
for (say) the empty file.
Anyway, maybe it's worth thinking a little about an SCM in which this is a
feature, instead of (or in addition to) automatically assuming this is a
bug we need to add infrastructure to work around.
--scott
PBFORTUNE Soviet cryptographic D5 SLBM MI5 CIA postcard WASHTUB [Hello to all my fans in domestic surveillance]
explosion Sigint Bush ODEARL FJHOPEFUL assassination Uzi Hussein Nader
( http://cscott.net/ )
^ permalink raw reply
* Re: Handling renames.
From: Daniel Barkalow @ 2005-04-14 22:23 UTC (permalink / raw)
To: David Woodhouse; +Cc: git, James Bottomley
In-Reply-To: <1113501260.27227.26.camel@hades.cambridge.redhat.com>
On Thu, 14 Apr 2005, David Woodhouse wrote:
> Opinions? Dissent? We'd probably need to escape the filenames in some
> way -- handwave over that for now.
I personally think renames are a minor thing that doesn't happen
much. What actually happens, in my opinion, is that some chunk of a file
is moved to a different, possibly new, file. If this is supported (as
something that the SCM notices), then a rename is just a special case
where the moved chunk is a whole file.
I think that it should be possible to identify and tag "big
enough" deletions and insertions, and compare them to find moves, where a
further change may be applied in the middle if two chunks are "very
similar" but not the same.
On the other hand, I think that the SCM will need to cache its
understanding of what a commit did in order to give reasonable
performance for operations like "annotate", and it may be advantegous to
distribute things from this cache, since the committer might want to tell
the system something that it didn't guess.
At some point, I'm going to argue for core support for "back pointers",
where a file can be created which is "about" some other file(s), and
someone looking for files "about" a particular file can find them without
searching the entire database. I think this will turn out to be important
for a variety of cases where some later participant wants to say something
about an existing file without changing the content of the file.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* (unknown),
From: Timo Hirvonen @ 2005-04-14 22:30 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply
* Re: [PATCH] Git pasky include commit-id in Makefile
From: Martin Schlemmer @ 2005-04-14 22:37 UTC (permalink / raw)
To: Darren Williams; +Cc: Git Mailing List, Petr Baudis
In-Reply-To: <20050414141022.GE10385@cse.unsw.EDU.AU>
[-- Attachment #1: Type: text/plain, Size: 3629 bytes --]
On Fri, 2005-04-15 at 00:10 +1000, Darren Williams wrote:
> Currently the commit-id script is not install with
> make install, this patches includes it in the SCRIPT
> target. This patch is against git-pasky-0.4
>
Hmm, this is still not fixed ...
> Signed-off-by Darren Williams <dsw@gelato.unsw.edu.au>
>
> COPYING: fe2a4177a760fd110e78788734f167bd633be8de
> Makefile: ca50293c4f211452d999b81f122e99babb9f2987
> --- Makefile
> +++ Makefile 2005-04-14 23:52:35.701915203 +1000
> @@ -19,7 +19,7 @@
> SCRIPT= parent-id tree-id git gitXnormid.sh gitadd.sh gitaddremote.sh \
> gitcommit.sh gitdiff-do gitdiff.sh gitlog.sh gitls.sh gitlsobj.sh \
> gitmerge.sh gitpull.sh gitrm.sh gittag.sh gittrack.sh gitexport.sh \
> - gitapply.sh gitcancel.sh gitlntree.sh
> + gitapply.sh gitcancel.sh gitlntree.sh commit-id
>
> GEN_SCRIPT= gitversion.sh
>
> README: ded1a3b20e9bbe1f40e487ba5f9361719a1b6b85
> VERSION: c27bd67cd632cc15dd520fbfbf807d482efa2dcf
> cache.h: 4d382549041d3281f8d44aa2e52f9f8ec47dd420
> cat-file.c: 45be1badaa8517d4e3a69e0bf1cac2e90191e475
> check-files.c: 927b0b9aca742183fc8e7ccd73d73d8d5427e98f
> checkout-cache.c: f06871cdbc1b18ea93bdf4e17126aeb4cca1373e
> commit-id: 65c81756c8f10d513d073ecbd741a3244663c4c9
> commit-tree.c: 12196c79f31d004dff0df1f50dda67d8204f5568
> diff-tree.c: 7dcc9eb7782fa176e27f1677b161ce78ac1d2070
> fsck-cache.c: 9c900fe458cecd2bdb4c4571a584115b5cf24f22
> git: 2c557dcf2032325acc265b577ee104e605fdaede
> gitXnormid.sh: a5d7a9f4a6e8d4860f35f69500965c2a493d80de
> gitadd.sh: 3ed93ea0fcb995673ba9ee1982e0e7abdbe35982
> gitaddremote.sh: bf1f28823da5b5270aa8fa05b321faa514a57a11
> gitapply.sh: d0e3c46e2ce1ee74e1a87ee6137955fa9b35c27b
> gitcancel.sh: ec58f7444a42cd3cbaae919fc68c70a3866420c0
> gitcommit.sh: 3629f67bbd3f171d091552814908b67af7537f4d
> gitdiff-do: d6174abceab34d22010c36a8453a6c3f3f184fe0
> gitdiff.sh: 5e47c4779d73c3f2f39f6be714c0145175933197
> gitexport.sh: dad00bf251b38ce522c593ea9631f842d8ccc934
> gitlntree.sh: 17c4966ea64aeced96ae4f1b00f3775c1904b0f1
> gitlog.sh: 177c6d12dd9fa4b4920b08451ffe4badde544a39
> gitls.sh: b6f15d82f16c1e9982c5031f3be22eb5430273af
> gitlsobj.sh: 128461d3de6a42cfaaa989fc6401bebdfa885b3f
> gitmerge.sh: 23e4a3ff342c6005928ceea598a2f52de6fb9817
> gitpull.sh: 0883898dda579e3fa44944b7b1d909257f6dc63e
> gitrm.sh: 5c18c38a890c9fd9ad2b866ee7b529539d2f3f8f
> gittag.sh: c8cb31385d5a9622e95a4e0b2d6a4198038a659c
> gittrack.sh: 03d6db1fb3a70605ef249c632c04e542457f0808
> init-db.c: aa00fbb1b95624f6c30090a17354c9c08a6ac596
> ls-tree.c: 3e2a6c7d183a42e41f1073dfec6794e8f8a5e75c
> parent-id: 1801c6fe426592832e7250f8b760fb9d2e65220f
> read-cache.c: 7a6ae8b9b489f6b67c82e065dedd5716a6bfc0ef
> read-tree.c: eb548148aa6d212f05c2c622ffbe62a06cd072f9
> rev-tree.c: 395b0b3bfadb0537ae0c62744b25ead4b487f3f6
> show-diff.c: a531ca4078525d1c8dcf84aae0bfa89fed6e5d96
> show-files.c: a9fa6767a418f870a34b39379f417bf37b17ee18
> tree-id: cb70e2c508a18107abe305633612ed702aa3ee4f
> update-cache.c: 62d0a6c41560d40863c44599355af10d9e089312
> write-tree.c: 1534477c91169ebddcf953e3f4d2872495477f6b
>
> ---------------------------------------------------
> Darren Williams <dsw AT gelato.unsw.edu.au>
> Gelato@UNSW <www.gelato.unsw.edu.au>
> --------------------------------------------------
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Re: Re: Re: Remove need to untrack before tracking new branch
From: Alex Riesen @ 2005-04-14 22:35 UTC (permalink / raw)
To: azarah; +Cc: Petr Baudis, git
In-Reply-To: <1113472557.23299.99.camel@nosferatu.lan>
On 4/14/05, Martin Schlemmer <azarah@nosferatu.za.org> wrote:
> + if (update_mode && changed & MODE_CHANGED)
> + chmod(ce->name, ce->st_mode);
it's "if ((update_mode && changed) & MODE_CHANGED)"
Did you really mean that?
-alex
^ permalink raw reply
* Re: Re: [PATCH] Git pasky include commit-id in Makefile
From: Petr Baudis @ 2005-04-14 22:35 UTC (permalink / raw)
To: Martin Schlemmer; +Cc: Darren Williams, Git Mailing List
In-Reply-To: <1113518245.23299.107.camel@nosferatu.lan>
Dear diary, on Fri, Apr 15, 2005 at 12:37:25AM CEST, I got a letter
where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> On Fri, 2005-04-15 at 00:10 +1000, Darren Williams wrote:
> > Currently the commit-id script is not install with
> > make install, this patches includes it in the SCRIPT
> > target. This patch is against git-pasky-0.4
> >
>
> Hmm, this is still not fixed ...
Come on people, give me a while. I just started walking through the
queued bugfixes. ;-)
--
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: Remove need to untrack before tracking new branch
From: Petr Baudis @ 2005-04-14 22:42 UTC (permalink / raw)
To: Martin Schlemmer; +Cc: git
In-Reply-To: <1113471609.23299.95.camel@nosferatu.lan>
Dear diary, on Thu, Apr 14, 2005 at 11:40:09AM CEST, I got a letter
where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> (PS, can you check the fact that your mail client keeps on adding a 'Re:
> ' ...)
Hmm. I guess my ancient reply_regexp
"^((\\[|\\()([^B]|B([^u]|u([^g]|g([^ ]|AnTiMaTcH))))[^]]+(\\]|\\)))?[
\t]*((re([\\[0-9\\]+])*|aw):[ \t]*)?" is broken... ;-)
> On Thu, 2005-04-14 at 11:11 +0200, Petr Baudis wrote:
> > I'm lost. Why do you do --update-modes? That makes no sense to me.
> > You introduce them to the cache out-of-order w.r.t. commits, that means
> > in the normal git usage they are already unrevertable.
> >
>
> Right, afterwards I thought I did add it to the wrong place.
So, could you please do something with it? :-)
> > What are you trying to do? Mode changes _are_ real changes. You _don't_
> > want to silence them. What you want is to even show them more explicitly
> > in show-diff.
> >
>
> No, you do not understand. If you actually change the mode, it will
> show. What now happens, is that say I track the 'linus' branch, then
> untrack, and then track 'pasky' again, the Patches will be applied, but
> not the mode changes which are stored in the cache ... Let me show you:
>
> -----
> $ ls -l $(./show-diff -s | cut -d: -f1)
..directroy listing with no 'x' bit..
> -----
>
> (Note no 'x' bit ...)
>
> And that is _after_ doing:
>
> $ git track linus; git track
>
> So basically the modes that are stored in the cache are not applied ...
> Although, yes, I prob should add the relevant code to checkout-cache.
This should be fixed now, BTW. git apply didn't correctly apply the
mode changes, but now it should. Several bugs prevented it to, in fact.
;-)
> > > show-diff.c: a531ca4078525d1c8dcf84aae0bfa89fed6e5d96
> > > --- a531ca4078525d1c8dcf84aae0bfa89fed6e5d96/show-diff.c
> > > +++ uncommitted/show-diff.c
> > > @@ -5,13 +5,18 @@
> > > */
> > > #include "cache.h"
> > >
> > > -static void show_differences(char *name,
> > > +static void show_differences(struct cache_entry *ce,
> > > void *old_contents, unsigned long long old_size)
> > > {
> > > static char cmd[1000];
> > > + static char sha1[41];
> > > + int n;
> > > FILE *f;
> > >
> > > - snprintf(cmd, sizeof(cmd), "diff -L %s -u -N - %s", name, name);
> > > + for (n = 0; n < 20; n++)
> > > + snprintf(&(sha1[n*2]), 3, "%02x", ce->sha1[n]);
> > > + snprintf(cmd, sizeof(cmd), "diff -L %s/%s -L uncommitted/%s -u -N - %s",
> > > + sha1, ce->name, ce->name, ce->name);
> >
> > The "directory" sha1 is the sha1 of the tree, not of the particular
> > file - that one is in the "attributes" list (parentheses after the
> > filename), together with mode.
> >
>
> Does it really matter? It is more just to get the patch prefix right,
> and I did it as it went nicely with the printed:
>
> ----
> show-diff.c: a531ca4078525d1c8dcf84aae0bfa89fed6e5d96
> ----
>
> for example ...
Yes, it matters, and I don't care how nicely it wents with what you
print before.
Either print there some nonsense which is clear not to be a tree ID, or
(much more preferably) print the real tree ID there. If some tool ever
uses it (e.g. to help resolve conflicts, perhaps even actually doing a
real merge based on the patch), you just confused it.
Also, do you think you could separate this patch from the other
(--update-modes) patch? (If we actually still need the --update-modes
patch after git apply was fixed.)
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* (unknown)
From: Timo Hirvonen @ 2005-04-14 22:43 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply
* Re: Handling renames.
From: David Woodhouse @ 2005-04-14 22:46 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, James Bottomley
In-Reply-To: <Pine.LNX.4.21.0504141758310.30848-100000@iabervon.org>
On Thu, 2005-04-14 at 18:23 -0400, Daniel Barkalow wrote:
> I personally think renames are a minor thing that doesn't happen
> much. What actually happens, in my opinion, is that some chunk of a
> file is moved to a different, possibly new, file. If this is supported
> (as something that the SCM notices), then a rename is just a special
> case where the moved chunk is a whole file.
Certainly we'd discussed the possibility that the 'rename' field may
contain more than one destination, or more than one source filename.
This could happen when a file is split into two, or when two files are
merged into one, for example.
--
dwmw2
^ permalink raw reply
* (unknown)
From: Timo Hirvonen @ 2005-04-14 22:47 UTC (permalink / raw)
subscribe git
^ permalink raw reply
* Re: Misc fixes for git-pasky
From: Petr Baudis @ 2005-04-14 22:49 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1113518277.8609.8.camel@dv>
Dear diary, on Fri, Apr 15, 2005 at 12:37:57AM CEST, I got a letter
where Pavel Roskin <proski@gnu.org> told me that...
> Hi, Petr!
>
> The attached patch against current git-pasky does following:
Hum. It does too much at once, that means I cannot apply it easily. :-(
> * README: spell checked
Good. :-)
> * cache.h: Include unistd.h. Needed for close() definition. While
> current zlib.h header includes unistd.h, it's not guaranteed to be so in
> other zlib versions.
Sounds good.
> * read-cache.c: Avoid C++ comments. C comments are more readable for C
> programmers. Besides, we don't want git to be so unportable that "gcc
> -pedantic" cannot compile it.
I don't really care about this too much, although I personally prefer
the old-style comments. // comments are C99 so -pedantic by itself
should have no right to complain about it.
> * show-diff.c: Fix handling of more than one option of the command line.
What exactly does it fix? The current code seems fine to my sleepy
brain.
> Add new option "-c" to omit checksums for modified files. Expand help.
How is the -c option useful?
Could you please send your patch with the correct inline settings on the
attachment (or just in the mail body) and signed off?
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* [patch pasky] refresh cache after changing tracked tree
From: Martin Schlemmer @ 2005-04-14 22:54 UTC (permalink / raw)
To: GIT Mailing Lists; +Cc: Petr Baudis
[-- Attachment #1.1: Type: text/plain, Size: 833 bytes --]
Hi,
I see the latest gitdiff-do does the right thing regarding modes, but we
still need to refresh the cache.
Signed-off-by: Martin Schlemmer <azarah@nosferatu.za.org>
gittrack.sh: 03d6db1fb3a70605ef249c632c04e542457f0808
--- 03d6db1fb3a70605ef249c632c04e542457f0808/gittrack.sh
+++ uncommitted/gittrack.sh
@@ -51,6 +51,7 @@
read-tree $(tree-id "$name")
gitdiff.sh local "$name" | gitapply.sh
+ update-cache --refresh
else
[ "$tracking" ] || \
@@ -61,6 +62,7 @@
if [ -s ".git/HEAD.local" ]; then
gitdiff.sh "$tracking" local | gitapply.sh
read-tree $(tree-id local)
+ update-cache --refresh
head=$(cat .git/HEAD)
branchhead=$(cat .git/heads/$tracking)
--
Martin Schlemmer
[-- Attachment #1.2: git-track-update_cache.patch --]
[-- Type: text/x-patch, Size: 532 bytes --]
gittrack.sh: 03d6db1fb3a70605ef249c632c04e542457f0808
--- 03d6db1fb3a70605ef249c632c04e542457f0808/gittrack.sh
+++ uncommitted/gittrack.sh
@@ -51,6 +51,7 @@
read-tree $(tree-id "$name")
gitdiff.sh local "$name" | gitapply.sh
+ update-cache --refresh
else
[ "$tracking" ] || \
@@ -61,6 +62,7 @@
if [ -s ".git/HEAD.local" ]; then
gitdiff.sh "$tracking" local | gitapply.sh
read-tree $(tree-id local)
+ update-cache --refresh
head=$(cat .git/HEAD)
branchhead=$(cat .git/heads/$tracking)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [patch pasky] update gitcancel.sh to handle modes as well
From: Martin Schlemmer @ 2005-04-14 22:57 UTC (permalink / raw)
To: GIT Mailing Lists; +Cc: Petr Baudis
[-- Attachment #1.1: Type: text/plain, Size: 1008 bytes --]
Hi,
gitcancel.sh do not handle mode changes:
----
$ chmod -x Makefile
$ git cancel
patch: **** Only garbage was found in the patch input.
----
Rather use checkout-cache to sync our tree, as should do the right thing
instead of diffing (cancel imply just blow away everything).
Signed-off-by: Martin Schlemmer <azarah@nosferatu.za.org>
gittrack.sh: 03d6db1fb3a70605ef249c632c04e542457f0808
--- 03d6db1fb3a70605ef249c632c04e542457f0808/gittrack.sh
+++ uncommitted/gittrack.sh
@@ -51,6 +51,7 @@
read-tree $(tree-id "$name")
gitdiff.sh local "$name" | gitapply.sh
+ update-cache --refresh
else
[ "$tracking" ] || \
@@ -61,6 +62,7 @@
if [ -s ".git/HEAD.local" ]; then
gitdiff.sh "$tracking" local | gitapply.sh
read-tree $(tree-id local)
+ update-cache --refresh
head=$(cat .git/HEAD)
branchhead=$(cat .git/heads/$tracking)
--
Martin Schlemmer
[-- Attachment #1.2: git-track-update_cache.patch --]
[-- Type: text/x-patch, Size: 532 bytes --]
gittrack.sh: 03d6db1fb3a70605ef249c632c04e542457f0808
--- 03d6db1fb3a70605ef249c632c04e542457f0808/gittrack.sh
+++ uncommitted/gittrack.sh
@@ -51,6 +51,7 @@
read-tree $(tree-id "$name")
gitdiff.sh local "$name" | gitapply.sh
+ update-cache --refresh
else
[ "$tracking" ] || \
@@ -61,6 +62,7 @@
if [ -s ".git/HEAD.local" ]; then
gitdiff.sh "$tracking" local | gitapply.sh
read-tree $(tree-id local)
+ update-cache --refresh
head=$(cat .git/HEAD)
branchhead=$(cat .git/heads/$tracking)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Re: [PATCH] Git pasky include commit-id in Makefile
From: Martin Schlemmer @ 2005-04-14 22:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: Darren Williams, Git Mailing List
In-Reply-To: <20050414223521.GL22699@pasky.ji.cz>
[-- Attachment #1: Type: text/plain, Size: 673 bytes --]
On Fri, 2005-04-15 at 00:35 +0200, Petr Baudis wrote:
> Dear diary, on Fri, Apr 15, 2005 at 12:37:25AM CEST, I got a letter
> where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> > On Fri, 2005-04-15 at 00:10 +1000, Darren Williams wrote:
> > > Currently the commit-id script is not install with
> > > make install, this patches includes it in the SCRIPT
> > > target. This patch is against git-pasky-0.4
> > >
> >
> > Hmm, this is still not fixed ...
>
> Come on people, give me a while. I just started walking through the
> queued bugfixes. ;-)
>
Sorry, thought you missed it as you had in later patches =)
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Remove need to untrack before tracking new branch
From: Martin Schlemmer @ 2005-04-14 23:01 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050414224257.GM22699@pasky.ji.cz>
[-- Attachment #1: Type: text/plain, Size: 4262 bytes --]
On Fri, 2005-04-15 at 00:42 +0200, Petr Baudis wrote:
> Dear diary, on Thu, Apr 14, 2005 at 11:40:09AM CEST, I got a letter
> where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> > (PS, can you check the fact that your mail client keeps on adding a 'Re:
> > ' ...)
>
> Hmm. I guess my ancient reply_regexp
> "^((\\[|\\()([^B]|B([^u]|u([^g]|g([^ ]|AnTiMaTcH))))[^]]+(\\]|\\)))?[
> \t]*((re([\\[0-9\\]+])*|aw):[ \t]*)?" is broken... ;-)
>
> > On Thu, 2005-04-14 at 11:11 +0200, Petr Baudis wrote:
> > > I'm lost. Why do you do --update-modes? That makes no sense to me.
> > > You introduce them to the cache out-of-order w.r.t. commits, that means
> > > in the normal git usage they are already unrevertable.
> > >
> >
> > Right, afterwards I thought I did add it to the wrong place.
>
> So, could you please do something with it? :-)
>
> > > What are you trying to do? Mode changes _are_ real changes. You _don't_
> > > want to silence them. What you want is to even show them more explicitly
> > > in show-diff.
> > >
> >
> > No, you do not understand. If you actually change the mode, it will
> > show. What now happens, is that say I track the 'linus' branch, then
> > untrack, and then track 'pasky' again, the Patches will be applied, but
> > not the mode changes which are stored in the cache ... Let me show you:
> >
> > -----
> > $ ls -l $(./show-diff -s | cut -d: -f1)
> ..directroy listing with no 'x' bit..
> > -----
> >
> > (Note no 'x' bit ...)
> >
> > And that is _after_ doing:
> >
> > $ git track linus; git track
> >
> > So basically the modes that are stored in the cache are not applied ...
> > Although, yes, I prob should add the relevant code to checkout-cache.
>
> This should be fixed now, BTW. git apply didn't correctly apply the
> mode changes, but now it should. Several bugs prevented it to, in fact.
> ;-)
>
Yep, I saw - thought you scrapped this, so mailed a new patch (or was
busy doing the touch ups to the email when this came in.
> > > > show-diff.c: a531ca4078525d1c8dcf84aae0bfa89fed6e5d96
> > > > --- a531ca4078525d1c8dcf84aae0bfa89fed6e5d96/show-diff.c
> > > > +++ uncommitted/show-diff.c
> > > > @@ -5,13 +5,18 @@
> > > > */
> > > > #include "cache.h"
> > > >
> > > > -static void show_differences(char *name,
> > > > +static void show_differences(struct cache_entry *ce,
> > > > void *old_contents, unsigned long long old_size)
> > > > {
> > > > static char cmd[1000];
> > > > + static char sha1[41];
> > > > + int n;
> > > > FILE *f;
> > > >
> > > > - snprintf(cmd, sizeof(cmd), "diff -L %s -u -N - %s", name, name);
> > > > + for (n = 0; n < 20; n++)
> > > > + snprintf(&(sha1[n*2]), 3, "%02x", ce->sha1[n]);
> > > > + snprintf(cmd, sizeof(cmd), "diff -L %s/%s -L uncommitted/%s -u -N - %s",
> > > > + sha1, ce->name, ce->name, ce->name);
> > >
> > > The "directory" sha1 is the sha1 of the tree, not of the particular
> > > file - that one is in the "attributes" list (parentheses after the
> > > filename), together with mode.
> > >
> >
> > Does it really matter? It is more just to get the patch prefix right,
> > and I did it as it went nicely with the printed:
> >
> > ----
> > show-diff.c: a531ca4078525d1c8dcf84aae0bfa89fed6e5d96
> > ----
> >
> > for example ...
>
> Yes, it matters, and I don't care how nicely it wents with what you
> print before.
>
hah ;p
> Either print there some nonsense which is clear not to be a tree ID, or
> (much more preferably) print the real tree ID there. If some tool ever
> uses it (e.g. to help resolve conflicts, perhaps even actually doing a
> real merge based on the patch), you just confused it.
>
Ok, understood. Do you think it will be scripted? If not I guess we
can just do labels like:
--- committed/
+++ uncommitted/
?
> Also, do you think you could separate this patch from the other
> (--update-modes) patch? (If we actually still need the --update-modes
> patch after git apply was fixed.)
>
Yeah, already split it out locally, just waiting on above response ...
Thanks,
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: update gitcancel.sh to handle modes as well
From: Petr Baudis @ 2005-04-14 22:57 UTC (permalink / raw)
To: Martin Schlemmer; +Cc: GIT Mailing Lists
In-Reply-To: <1113519445.23299.119.camel@nosferatu.lan>
Dear diary, on Fri, Apr 15, 2005 at 12:57:25AM CEST, I got a letter
where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> Hi,
>
> gitcancel.sh do not handle mode changes:
>
> ----
> $ chmod -x Makefile
> $ git cancel
> patch: **** Only garbage was found in the patch input.
> ----
>
> Rather use checkout-cache to sync our tree, as should do the right thing
> instead of diffing (cancel imply just blow away everything).
>
> Signed-off-by: Martin Schlemmer <azarah@nosferatu.za.org>
>
> gittrack.sh: 03d6db1fb3a70605ef249c632c04e542457f0808
> --- 03d6db1fb3a70605ef249c632c04e542457f0808/gittrack.sh
> +++ uncommitted/gittrack.sh
> @@ -51,6 +51,7 @@
>
> read-tree $(tree-id "$name")
> gitdiff.sh local "$name" | gitapply.sh
> + update-cache --refresh
>
> else
> [ "$tracking" ] || \
> @@ -61,6 +62,7 @@
> if [ -s ".git/HEAD.local" ]; then
> gitdiff.sh "$tracking" local | gitapply.sh
> read-tree $(tree-id local)
> + update-cache --refresh
>
> head=$(cat .git/HEAD)
> branchhead=$(cat .git/heads/$tracking)
The patch looks familiar, but not right. ;-)
--
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: Remove need to untrack before tracking new branch
From: Petr Baudis @ 2005-04-14 23:00 UTC (permalink / raw)
To: Martin Schlemmer; +Cc: git
In-Reply-To: <1113519687.23299.126.camel@nosferatu.lan>
Dear diary, on Fri, Apr 15, 2005 at 01:01:27AM CEST, I got a letter
where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> On Fri, 2005-04-15 at 00:42 +0200, Petr Baudis wrote:
> > Dear diary, on Thu, Apr 14, 2005 at 11:40:09AM CEST, I got a letter
> > where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> > > So basically the modes that are stored in the cache are not applied ...
> > > Although, yes, I prob should add the relevant code to checkout-cache.
> >
> > This should be fixed now, BTW. git apply didn't correctly apply the
> > mode changes, but now it should. Several bugs prevented it to, in fact.
> > ;-)
>
> Yep, I saw - thought you scrapped this, so mailed a new patch (or was
> busy doing the touch ups to the email when this came in.
Hmm, I must've missed the new patch. The latest I have still puts the
stuff to update-cache and combines it with the show-diff change.
> > > > > show-diff.c: a531ca4078525d1c8dcf84aae0bfa89fed6e5d96
> > > > > --- a531ca4078525d1c8dcf84aae0bfa89fed6e5d96/show-diff.c
> > > > > +++ uncommitted/show-diff.c
> > > > > @@ -5,13 +5,18 @@
..snip..
> > > > > - snprintf(cmd, sizeof(cmd), "diff -L %s -u -N - %s", name, name);
> > > > > + for (n = 0; n < 20; n++)
> > > > > + snprintf(&(sha1[n*2]), 3, "%02x", ce->sha1[n]);
> > > > > + snprintf(cmd, sizeof(cmd), "diff -L %s/%s -L uncommitted/%s -u -N - %s",
> > > > > + sha1, ce->name, ce->name, ce->name);
> > > >
> > > > The "directory" sha1 is the sha1 of the tree, not of the particular
> > > > file - that one is in the "attributes" list (parentheses after the
> > > > filename), together with mode.
> > > >
> > >
> > > Does it really matter? It is more just to get the patch prefix right,
> > > and I did it as it went nicely with the printed:
> > >
> > > ----
> > > show-diff.c: a531ca4078525d1c8dcf84aae0bfa89fed6e5d96
> > > ----
> > >
> > > for example ...
> >
> > Yes, it matters, and I don't care how nicely it wents with what you
> > print before.
> >
>
> hah ;p
>
> > Either print there some nonsense which is clear not to be a tree ID, or
> > (much more preferably) print the real tree ID there. If some tool ever
> > uses it (e.g. to help resolve conflicts, perhaps even actually doing a
> > real merge based on the patch), you just confused it.
> >
>
> Ok, understood. Do you think it will be scripted? If not I guess we
> can just do labels like:
>
> --- committed/
> +++ uncommitted/
>
> ?
Heh. Well, of course this could do. But is there any technical reason
why not just carry the sha1 id of the tree around and stuff it there?
--
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: [patch pasky] update gitcancel.sh to handle modes as well
From: Martin Schlemmer @ 2005-04-14 23:04 UTC (permalink / raw)
To: GIT Mailing Lists; +Cc: Petr Baudis
In-Reply-To: <1113519445.23299.119.camel@nosferatu.lan>
[-- Attachment #1.1: Type: text/plain, Size: 1784 bytes --]
On Fri, 2005-04-15 at 00:57 +0200, Martin Schlemmer wrote:
> Hi,
>
> gitcancel.sh do not handle mode changes:
>
> ----
> $ chmod -x Makefile
> $ git cancel
> patch: **** Only garbage was found in the patch input.
> ----
>
> Rather use checkout-cache to sync our tree, as should do the right thing
> instead of diffing (cancel imply just blow away everything).
>
> Signed-off-by: Martin Schlemmer <azarah@nosferatu.za.org>
>
> gittrack.sh: 03d6db1fb3a70605ef249c632c04e542457f0808
> --- 03d6db1fb3a70605ef249c632c04e542457f0808/gittrack.sh
> +++ uncommitted/gittrack.sh
> @@ -51,6 +51,7 @@
>
> read-tree $(tree-id "$name")
> gitdiff.sh local "$name" | gitapply.sh
> + update-cache --refresh
>
> else
> [ "$tracking" ] || \
> @@ -61,6 +62,7 @@
> if [ -s ".git/HEAD.local" ]; then
> gitdiff.sh "$tracking" local | gitapply.sh
> read-tree $(tree-id local)
> + update-cache --refresh
>
> head=$(cat .git/HEAD)
> branchhead=$(cat .git/heads/$tracking)
Yes, I am an idiot, and its past 1am already here.
Rather use checkout-cache to sync our tree, as should do the right thing
instead of diffing (cancel imply just blow away everything).
Signed-off-by: Martin Schlemmer <azarah@nosferatu.za.org>
gitcancel.sh: 839b3c58f20f6eb8412f499a891e007e2e67d114
--- 839b3c58f20f6eb8412f499a891e007e2e67d114/gitcancel.sh
+++ uncommitted/gitcancel.sh
@@ -10,9 +10,8 @@
#
# Takes no arguments. Takes the evil changes from the tree.
-# FIXME: Does not revert mode changes!
-show-diff | patch -p0 -R
rm -f .git/add-queue .git/rm-queue
+checkout-cache -q -f -a
update-cache --refresh
--
Martin Schlemmer
[-- Attachment #1.2: git-full-cancel.patch --]
[-- Type: text/x-patch, Size: 396 bytes --]
gitcancel.sh: 839b3c58f20f6eb8412f499a891e007e2e67d114
--- 839b3c58f20f6eb8412f499a891e007e2e67d114/gitcancel.sh
+++ uncommitted/gitcancel.sh
@@ -10,9 +10,8 @@
#
# Takes no arguments. Takes the evil changes from the tree.
-# FIXME: Does not revert mode changes!
-show-diff | patch -p0 -R
rm -f .git/add-queue .git/rm-queue
+checkout-cache -q -f -a
update-cache --refresh
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Re: [patch pasky] update gitcancel.sh to handle modes as well
From: Petr Baudis @ 2005-04-14 23:07 UTC (permalink / raw)
To: Martin Schlemmer; +Cc: GIT Mailing Lists
In-Reply-To: <1113519890.23299.129.camel@nosferatu.lan>
Dear diary, on Fri, Apr 15, 2005 at 01:04:50AM CEST, I got a letter
where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> Rather use checkout-cache to sync our tree, as should do the right thing
> instead of diffing (cancel imply just blow away everything).
>
> Signed-off-by: Martin Schlemmer <azarah@nosferatu.za.org>
>
> gitcancel.sh: 839b3c58f20f6eb8412f499a891e007e2e67d114
> --- 839b3c58f20f6eb8412f499a891e007e2e67d114/gitcancel.sh
> +++ uncommitted/gitcancel.sh
> @@ -10,9 +10,8 @@
> #
> # Takes no arguments. Takes the evil changes from the tree.
>
> -# FIXME: Does not revert mode changes!
>
> -show-diff | patch -p0 -R
> rm -f .git/add-queue .git/rm-queue
> +checkout-cache -q -f -a
>
> update-cache --refresh
Why -q?
Never make things silent unless you really know what are you doing and
why. The same goes for popular throwing of -f to rm's of files which
should always exist or 2>/dev/null for cats.
--
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: Remove need to untrack before tracking new branch
From: Martin Schlemmer @ 2005-04-14 23:09 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050414230047.GS22699@pasky.ji.cz>
[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]
On Fri, 2005-04-15 at 01:00 +0200, Petr Baudis wrote:
> Dear diary, on Fri, Apr 15, 2005 at 01:01:27AM CEST, I got a letter
> where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> > On Fri, 2005-04-15 at 00:42 +0200, Petr Baudis wrote:
> > > Dear diary, on Thu, Apr 14, 2005 at 11:40:09AM CEST, I got a letter
> > > where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> > > > > > - snprintf(cmd, sizeof(cmd), "diff -L %s -u -N - %s", name, name);
> > > > > > + for (n = 0; n < 20; n++)
> > > > > > + snprintf(&(sha1[n*2]), 3, "%02x", ce->sha1[n]);
> > > > > > + snprintf(cmd, sizeof(cmd), "diff -L %s/%s -L uncommitted/%s -u -N - %s",
> > > > > > + sha1, ce->name, ce->name, ce->name);
> > > > >
> > > > > The "directory" sha1 is the sha1 of the tree, not of the particular
> > > > > file - that one is in the "attributes" list (parentheses after the
> > > > > filename), together with mode.
> > > > >
> > > >
> > > > Does it really matter? It is more just to get the patch prefix right,
> > > > and I did it as it went nicely with the printed:
> > > >
> > > > ----
> > > > show-diff.c: a531ca4078525d1c8dcf84aae0bfa89fed6e5d96
> > > > ----
> > > >
> > > > for example ...
> > >
> > > Yes, it matters, and I don't care how nicely it wents with what you
> > > print before.
> > >
> >
> > hah ;p
> >
> > > Either print there some nonsense which is clear not to be a tree ID, or
> > > (much more preferably) print the real tree ID there. If some tool ever
> > > uses it (e.g. to help resolve conflicts, perhaps even actually doing a
> > > real merge based on the patch), you just confused it.
> > >
> >
> > Ok, understood. Do you think it will be scripted? If not I guess we
> > can just do labels like:
> >
> > --- committed/
> > +++ uncommitted/
> >
> > ?
>
> Heh. Well, of course this could do. But is there any technical reason
> why not just carry the sha1 id of the tree around and stuff it there?
>
Not at all. Just wanted to know if anybody saw the possible use before
adding possible cruft that could be done shorter - will do a patch
shortly.
Thanks,
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Re: [patch pasky] update gitcancel.sh to handle modes as well
From: Martin Schlemmer @ 2005-04-14 23:14 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing Lists
In-Reply-To: <20050414230712.GT22699@pasky.ji.cz>
[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]
On Fri, 2005-04-15 at 01:07 +0200, Petr Baudis wrote:
> Dear diary, on Fri, Apr 15, 2005 at 01:04:50AM CEST, I got a letter
> where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> > Rather use checkout-cache to sync our tree, as should do the right thing
> > instead of diffing (cancel imply just blow away everything).
> >
> > Signed-off-by: Martin Schlemmer <azarah@nosferatu.za.org>
> >
> > gitcancel.sh: 839b3c58f20f6eb8412f499a891e007e2e67d114
> > --- 839b3c58f20f6eb8412f499a891e007e2e67d114/gitcancel.sh
> > +++ uncommitted/gitcancel.sh
> > @@ -10,9 +10,8 @@
> > #
> > # Takes no arguments. Takes the evil changes from the tree.
> >
> > -# FIXME: Does not revert mode changes!
> >
> > -show-diff | patch -p0 -R
> > rm -f .git/add-queue .git/rm-queue
> > +checkout-cache -q -f -a
> >
> > update-cache --refresh
>
> Why -q?
>
> Never make things silent unless you really know what are you doing and
> why. The same goes for popular throwing of -f to rm's of files which
> should always exist or 2>/dev/null for cats.
>
Uhm, no particular reason (other than perhaps working usually on stuff
where too much info just confuses the user). If its fine in spirit, the
-q can go.
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Junio C Hamano @ 2005-04-14 23:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, git
In-Reply-To: <20050414193507.GA22699@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> What I would like your script to do is therefore just do the
PB> merge in a given already prepared (including built index)
PB> directory, with a passed base. The base should be determined
PB> by a separate tool (I already saw some patches); most future
PB> "science" will probably go to a clever selection of this
PB> base, anyway.
I think you are contradicting yourself for saying the above
after agreeing with me that the script should just work on trees
not commits. My understanding is that the tools is just to
merge two related trees relative to another ancestor tree,
nothing more. Especially, it should not care what is in the
working directory---that is SCM person's business.
I am just trying to follow my understanding of what Linus
wanted. One of the guiding principle is to do as much things as
in dircache without ever checking things out or touching working
files unnecessarily.
PB> This will give the tool maximal flexibility.
I suspect it would force me to have a working directory
populated with files, just to do a merge.
PB> I'm all for an -o, and I don't mind ,, - I just don't want it uselessly
PB> long. I hope "git~merge~$$" was a joke... :-)
Which part do you object to? PID part? or tilde? Would
git~merge do, perhaps? It probably would not matter to you
because as an SCM you would always give an explicit --output
parameter to the script anyway.
PB> By the way, what about indentation with tabs? If you have a
PB> strong opinion about this, I don't insist - but if you
PB> really don't mind/care either way, it'd be great to use tabs
PB> as in the rest of the git code.
I do not have a strong opinion, but it is more trouble for me
only because I am lazy and am used to the indentation my Emacs
gives me. I write code other than git, so changing Perl-mode
indentation setting globally for all .pl files is not an option
for me. I'll see what I can do when I have time.
PB> Is there a fundamental reason why the directory cache
PB> contains the ancestor instead of the destination branch?
Because you are thinking as an SCM person where there are
distinction between tree-A and tree-B, two heads being merged.
There is no "destination branch" nor "source branch" in what I
am doing. It is a merge of two equals derived from the same
ancestor.
PB> I think the script actually does not fundamentally depend on it. My main
PB> motivation is that the user can then trivially see what is he actually
PB> going to commit to his destination branch, which would be bought for
PB> free by that.
And again the user is *not* commiting to his "destination
branch". At the level I am working at, the merge result should
be commited with two -p parameters to commit-tree --- tree-A and
tree-B, both being equal parents from the POV of git object
storage.
PB> And this is another thing I dislike a lot. I'd like merge-tree.pl to
PB> leave my directory cache alone, thank you very much. You know, I see
PB> what goes to the directory cache as actually part of the policy part.
Remember I am not touching *your* dircache. It is a dircache in
the temporary merge area, specifically set up to help you review
the merge.
Can't the SCM driver do things along this line, perhaps?
- You have your working files and your dircache. They may not
match because you have uncommitted changes to your
environment. You want to merge with Linus head. You know
its SHA1 (call it COMMIT-Linus). Your SCM knows which commit
you started with (call it COMMIT-Current).
- First you merge the tree associated with COMMIT-Current. Use
it and COMMIT-Linus to find the common ancestor to use.
- Now use the tree SHA of COMMIT-Current, tree SHA1 of
COMMIT-Linus, and tree SHA1 of the common ancestor commit to
drive git-merge.perl (to be renamed ;-). You will get a
temporary directory. Have your user examine what is in
there, and fix the merge and have them tell you they are
happy.
- You go to that temporary directory, do write-tree and
commit-tree with -p parameter of COMMIT-Linus and
COMMIT-Current. This will result in a new commit. Call that
COMMIT-Merge.
- You, as an SCM, should know what your user have done in the
working directory relative to COMMIT-Current. Especially you
should know the set of paths involved in that change. Go in
to the temporary area, checkout-cache those files if you have
not done so. Apply the changes you have there. Optionally
have the user examine the changes and have him confirm. Lift
those files into the user's working directory.
- Do your bookkeeping like "echo COMMIT-Merge >.git/Head", to
make the user's working files based on COMMIT-Merge, and run
read-tree using the COMMIT-Merge in the user's working
directory. At this point, show-diff output should show what
the changes your user have had made if he had started working
based on COMMIT-Merge instead of starting from
COMMIT-Current.
I think the above would result in what SCM person would call
"merge upstream/sidestream changes into my working directory".
^ permalink raw reply
* Re: Reorganize common code
From: Petr Baudis @ 2005-04-14 23:13 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, torvalds
In-Reply-To: <Pine.LNX.4.21.0504131755550.30848-100000@iabervon.org>
Dear diary, on Thu, Apr 14, 2005 at 12:00:25AM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> This splits read-cache.c into util.c, cache.c, and objects.c, based on
> what the code is used for; similarly, cache.h becomes util.h, cache.h, and
> objects.h. For simplicity, cache.h includes the other two to give the
> previous overall behavior.
>
> Signed-Off-By: Daniel Barkalow <barkalow@iabervon.org>
FYI, given the scale of this change, I'm waiting for Linus to either ack
it, pick it himself or reject it.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ 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