* Re: Re: Re: write-tree is pasky-0.4
From: Linus Torvalds @ 2005-04-16 3:13 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.21.0504152221070.30848-100000@iabervon.org>
On Fri, 15 Apr 2005, Daniel Barkalow wrote:
>
> So you want to merge someone else's tree into your committed state, and
> then merge the result with your working directory to get the working
> directory you continue with, provided that the second merge is trivial?
No, you don't even "merge" the working directory.
The low-level tools should entirely ignore the working directory. To a
low-level merge, the working directory doesn't even exist. It just gets
three commits (or trees) and merges two of them with the third as a
parent, and does all of it in it's own temporary "merge working
directory".
So on a technical level, the "plumbing" part really really doesn't care at
all.
However, from a _usability_ part, you expect after a merge that your
working directory has been updated to be the merged tree. And that's where
the "if I have a working tree that is dirty, I want that part to fail"
comes in. In other words, the final phase (after the "tree-merge" has
actually successfully already finished) is to go back to the working
directory, and check out the merged results.
But that checkout would be a variation on "checkout-cache -a" which first
checks that none of the files it is going to overwrite are dirty.
Don't worry about this part. It's really totally separate from the true
merge itself. The "real work" has already been done by the time we notice
that "oops, we can't actually show him the newly merged tree, because he
has got dirty data where we want to show it".
> > I care. Even if the best common parent is 3 months ago, I care. I'd much
> > rather get a big explicit conflict than a "clean merge" that ends up being
> > debatable because people played games with per-file merging or something
> > questionable like that.
>
> Are you thinking that the best common ancestor is the one that ties up
> absolutely all of the chains of commits, or the closest one that the sides
> have in common?
The closest common one.
> For the latter, there are sometimes multiple ancestors which fit this
> criterion
Yes. Let's just pick one at random (or more likely, the latest one by
date - let's not actually be _random_ random) at first.
There are other heuristics we can try, ie if it turns out that it's common
to have a couple of alternatives (but no more than some small number, say
five or so), we can literally just -try- to do a tree-only merge, and see
how many lines out common output you get from "diff-tree".
Because that "how mnay files do we need to merge" is the number you want
to minimize, and doing a couple of extra "diff-tree" + "join" operations
should be so fast that nobody will notice that we actually tried five
different merges to see which one looked the best.
But hey, especially if the merge fails with real clashes (ie there are
changes in common and running "merge" leaves conflicts), and there were
other alternate parents to choose, there's nothing wrong with just
printing them out and saying "you might try to specify one of these
manually".
I really don't think we should worry too much about this until we've
actually used the system for a while and seen what it does. So just start
with "nearest common parent with most recent date". Which I think you
already implemented, no?
Linus
^ permalink raw reply
* Re: Re: Add "clone" support to lntree
From: Linus Torvalds @ 2005-04-16 3:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: Daniel Barkalow, git
In-Reply-To: <20050416025844.GY7417@pasky.ji.cz>
On Sat, 16 Apr 2005, Petr Baudis wrote:
>
> I'm wondering, whether each tree should be fixed to a certain branch.
I'm wondering why you talk about "branches" at all.
No such thing should exist. There are no branches. There are just
repositories. You can track somebody elses repository, but you should
track it by location, not by any "branch name".
And you track it by just merging it.
Yeah, we don't have really usable merges yet, but..
Linus
^ permalink raw reply
* Re: Re: Add "clone" support to lntree
From: Daniel Barkalow @ 2005-04-16 3:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050416025844.GY7417@pasky.ji.cz>
On Sat, 16 Apr 2005, Petr Baudis wrote:
> Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter
> where Petr Baudis <pasky@ucw.cz> told me that...
> > git branch --- creates a branch from a given commit
> > (when passed empty commit, creates a branch
> > from the current commit and sets the working
> > tree to that branch)
> > Note that there is a bug in current git update - it will allow you to
> > bring several of your trees to follow the same branch, or even a remote
> > branch. This is not even supposed to work, and will be fixed when I get
> > some sleep. You will be able to do git pull even on local branches, and
> > the proper solution for this will be just tracking the branch you want
> > to follow.
>
> I must admit that I'm not entirely decided yet, so I'd love to hear your
> opinion.
>
> I'm wondering, whether each tree should be fixed to a certain branch.
> That is, you decide a name when you do git fork, and then the tree
> always follows that branch. (It always has to follow [be bound to]
> *some* branch, and each branch can be followed by only a single tree at
> a time.)
I don't think I'm following the use of branches. Currently, what I do is
have a git-pasky and a git-linus, and fork off a working directory from
one of these for each thing I want to work on. I do some work, commit as I
make progress, and then do a diff against the remote head to get a patch
to send off. If I want to do a series of patches which depend on each
other, I fork my next directory off of my previous one rather than off of
a remote base. I haven't done much rebasing, so I haven't worked out how I
would do that most effectively.
I think I can make this space efficient by hardlinking unmodified blobs to
a directory of cached expanded blobs.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Re: Re: write-tree is pasky-0.4
From: Daniel Barkalow @ 2005-04-16 3:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0504152000570.7211@ppc970.osdl.org>
On Fri, 15 Apr 2005, Linus Torvalds wrote:
> On Fri, 15 Apr 2005, Daniel Barkalow wrote:
> >
> > So you want to merge someone else's tree into your committed state, and
> > then merge the result with your working directory to get the working
> > directory you continue with, provided that the second merge is trivial?
>
> No, you don't even "merge" the working directory.
>
> The low-level tools should entirely ignore the working directory. To a
> low-level merge, the working directory doesn't even exist. It just gets
> three commits (or trees) and merges two of them with the third as a
> parent, and does all of it in it's own temporary "merge working
> directory".
It seems like users won't expect there to be a new working directory for
the merge in which they are supposed to resolve te conflicts, but where
they don't see their uncommited changes. In any case, the low-level tools
have to care about *some* working directory, even if it isn't the parent
of .git, and the parent of .git seems like where other similar things
happen. If we're being conservative about merging, we're likely to report
a lot of conflicts, at least until we work out better techniques than a
simple 3-way merge.
> > For the latter, there are sometimes multiple ancestors which fit this
> > criterion
>
> Yes. Let's just pick one at random (or more likely, the latest one by
> date - let's not actually be _random_ random) at first.
Okay; I've currently got the one where the number of generations it is
away from the further head is the smallest, and of equal ones, an
arbitrary choice. If people are generally similar in the amount they
diverge before commiting, this should be the most similar ancestor.
> There are other heuristics we can try, ie if it turns out that it's common
> to have a couple of alternatives (but no more than some small number, say
> five or so), we can literally just -try- to do a tree-only merge, and see
> how many lines out common output you get from "diff-tree".
>
> Because that "how mnay files do we need to merge" is the number you want
> to minimize, and doing a couple of extra "diff-tree" + "join" operations
> should be so fast that nobody will notice that we actually tried five
> different merges to see which one looked the best.
>
> But hey, especially if the merge fails with real clashes (ie there are
> changes in common and running "merge" leaves conflicts), and there were
> other alternate parents to choose, there's nothing wrong with just
> printing them out and saying "you might try to specify one of these
> manually".
I think we should be able to get good results out of doing the 5 merges
and reporting a conflict only if there's a conflict in all of them; it
shouldn't be possible for two to succeed but give different results (if it
did, clearly our current algorithm is unsafe, since it would give some
undesired output if it happened to use the wrong ancestor).
I'm thinking of not actually calling "merge(1)" for this at all; it just
calls diff3, and diff3 is only 1745 lines including option parsing. We can
probably arrange to look around for better ancestors in case of conflicts
we'd otherwise have to report, and get this all tidy and more efficient
than having diff3 re-read files. And if we only go to other ancestors in
case of conflicts, we're going to be a lot faster total than getting a
reaction from the user, almost no matter what we do.
> I really don't think we should worry too much about this until we've
> actually used the system for a while and seen what it does. So just start
> with "nearest common parent with most recent date". Which I think you
> already implemented, no?
I've got something like that (see above); did you want it in some form
other than the patch I sent you?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 3/2] merge-trees script for Linus git
From: Junio C Hamano @ 2005-04-16 4:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504151755590.7211@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> Just a heads-up - I'd really want to do the same thing to "merge-tree.c"
LT> too, but since you said that you were working on extending that to do
LT> recursion etc, I decided to hold off. So if you're working on it, maybe
LT> you can add the "-z" flag there too?
Sent as a separate patch already.
LT> I'm actually holding off merging the perl version exactly because you
LT> seemed to be working on the C version. I don't mind perl per se, but if
LT> there's a real solution coming down the line..
I'd take the hint, but I would say the current Perl version
would be far more usable than the C version I would come up with
by the end of this weekend because:
- the Perl version creates a new temporary directory and leaves
a ready-to-use dircache there---the only thing needed from
that point for you is to fix it up any conflicts and do
update-cache on that dircache. In that sense it is already
usable (Linus-usable, but probably not Pasky-usable due to
differences in phylosophy).
- the enhancement I am planning on the C version does not do
the real work itself, as you have originally written (the
workings and the output from it are outlined in [*R1*]).
Somebody has to write the executor part that does read-tree
the base, update-cache --cacheinfo --add for the selects,
runs 3-way merge on conflicting files and runs update-cache
for the merges, update-cache --remove for the deletes, before
it matches the usability of the Perl version. I do not
expect to have enough time this weekend to finish this.
I know of one case in Perl version I need to see if it does the
right thing but other than that it would be far better than the
C version I'm toying with.
Just to let you know, here is the plan I have for my part.
1. I am currently writing some test cases. The plan is first
to make sure the Perl version works OK with the test cases
to flush initial problems out.
2. After that I'll see if a dumb but recursive C version I
already have spits out the right instructions. This step is
to make sure that the test cases are sane, and by making
that sure, we will be able to say that we have something
usable in extremely short run (i.e. the Perl version) after
this step.
3. After that is done, I'll add the fourth argument to
merge-tree.c to specify the base so that it can cut down 90%
of trivial selects. Only after this happens the executioner
script would be useful performance wise.
[References]
*R1* <7vr7hbhky9.fsf@assigned-by-dhcp.cox.net>
^ permalink raw reply
* [PATCH] Cache of hardlinked blobs
From: Daniel Barkalow @ 2005-04-16 4:43 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git, Linus Torvalds
I wrote a quick and dirty patch to check out blobs into .git/blobs, and
hardlink them into the working directory; if you symlink .git/blobs
together for a number of trees, this should save a lot of space if you
have a lot of working directories. It also seems to speed up and save
space in "git fork" (or whatever it ends up being called) if the symlink
is added to the list of symlinks. It seems effective from trying it with a
git tree. Ingo: do you want to try it with a kernel tree? I think you said
you wanted good performance for that sort of thing.
Patch follows:
Make a cache of expanded blobs, and hardlink against them instead of
creating more files. This is useful if the cache is shared between
different working directories and your editor breaks hard links
appropriately.
Signed-Off-By: Daniel Barkalow <barkalow@iabervon.org>
Index: checkout-cache.c
===================================================================
--- e4d994ccc556a50f89297c6dbcf22e484a344cf8/checkout-cache.c (mode:100664 sha1:431b7032576f40d93a08be801e26f76c168ed57b)
+++ 2ee21d9b73c81d51f6c0e8ff35a92a4f11105fc4/checkout-cache.c (mode:100664 sha1:9624b3c783c482c9f6da8bf8b2cf45b316107776)
@@ -34,6 +34,8 @@
*/
#include "cache.h"
+#define HARDLINK_CACHE ".git/blobs"
+
static int force = 0, quiet = 0;
static void create_directories(const char *path)
@@ -64,6 +66,80 @@
return fd;
}
+#ifdef HARDLINK_CACHE
+
+/*
+ * NOTE! This returns a statically allocated buffer, so you have to be
+ * careful about using it. Do a "strdup()" if you need to save the
+ * filename.
+ */
+char *sha1_blob_cache_file_name(const unsigned char *sha1)
+{
+ int i;
+ static char *name, *base;
+
+ if (!base) {
+ char *sha1_file_directory = HARDLINK_CACHE;
+ int len = strlen(sha1_file_directory);
+ base = malloc(len + 60);
+ memcpy(base, sha1_file_directory, len);
+ memset(base+len, 0, 60);
+ base[len] = '/';
+ base[len+3] = '/';
+ name = base + len + 1;
+ }
+ for (i = 0; i < 20; i++) {
+ static char hex[] = "0123456789abcdef";
+ unsigned int val = sha1[i];
+ char *pos = name + i*2 + (i > 0);
+ *pos++ = hex[val >> 4];
+ *pos = hex[val & 0xf];
+ }
+ return base;
+}
+
+static int write_entry(struct cache_entry *ce)
+{
+ int fd;
+ void *new;
+ unsigned long size;
+ long wrote;
+ char type[20];
+ char *cache_name;
+ struct stat st;
+
+ cache_name = sha1_blob_cache_file_name(ce->sha1);
+
+ if (stat(cache_name, &st)) {
+ new = read_sha1_file(ce->sha1, type, &size);
+ if (!new || strcmp(type, "blob")) {
+ return error("checkout-cache: unable to read sha1 file of %s (%s)",
+ ce->name, sha1_to_hex(ce->sha1));
+ }
+ fd = create_file(cache_name, ntohl(ce->ce_mode));
+ if (fd < 0) {
+ free(new);
+ return error("checkout-cache: unable to create %s (%s)",
+ ce->name, strerror(errno));
+ }
+ wrote = write(fd, new, size);
+ close(fd);
+ free(new);
+ if (wrote != size)
+ return error("checkout-cache: unable to write %s",
+ ce->name);
+ }
+ if (link(cache_name, ce->name)) {
+ if (errno == ENOENT) {
+ create_directories(ce->name);
+ link(cache_name, ce->name);
+ }
+ }
+ return 0;
+}
+
+#else
+
static int write_entry(struct cache_entry *ce)
{
int fd;
@@ -91,6 +167,8 @@
return 0;
}
+#endif
+
static int checkout_entry(struct cache_entry *ce)
{
struct stat st;
^ permalink raw reply
* Re: [PATCH 3/2] merge-trees script for Linus git
From: Linus Torvalds @ 2005-04-16 5:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7jj3fjky.fsf@assigned-by-dhcp.cox.net>
On Fri, 15 Apr 2005, Junio C Hamano wrote:
>
> I'd take the hint, but I would say the current Perl version
> would be far more usable than the C version I would come up with
> by the end of this weekend because:
Actually, it turns out that I have a cunning plan.
I'm full of cunning plans, in fact. It turns out that I can do merges even
more simply, if I just allow the notion of "state" into an index entry,
and allow multiple index entries with the same name as long as they differ
in "state".
And that means that I can do all the merging in the regular index tree,
using very simple rules.
Let's see how that works out. I'm writing the code now.
Linus
^ permalink raw reply
* would madvise be a win or a lose on memory pressure?
From: Mike Taht @ 2005-04-16 5:05 UTC (permalink / raw)
To: git
Doesn't seem to make sense to use MADV_RANDOM on the cache file, but
maybe MADV_SEQUENTIAL on the rest...
--- /home/m/src/git-pasky-0.4/update-cache.c 2005-04-15
12:24:26.000000000 -0700
+++ update-cache.c 2005-04-15 21:53:34.000000000 -0700
@@ -30,7 +30,7 @@
close(fd);
if (!out || (int)(long)in == -1)
return -1;
-
+ madvise(in,size,MADV_SEQUENTIAL);
memset(&stream, 0, sizeof(stream));
deflateInit(&stream, Z_BEST_COMPRESSION);
--- /home/m/src/git-pasky-0.4/read-cache.c 2005-04-15
12:24:26.000000000 -0700
+++ read-cache.c 2005-04-15 22:01:12.000000000 -0700
@@ -143,6 +143,7 @@
close(fd);
if (-1 == (int)(long)map)
return NULL;
+ madvise(map,st.st_size,MADV_SEQUENTIAL);
*size = st.st_size;
return map;
}
@@ -254,6 +255,7 @@
close(fd);
if (map == MAP_FAILED)
return -1;
+ madvise(map,size,MADV_SEQUENTIAL);
cmp = memcmp(buf, map, size);
munmap(map, size);
if (cmp)
--
Mike Taht
^ permalink raw reply
* Re: [PATCH 3/2] merge-trees script for Linus git
From: Linus Torvalds @ 2005-04-16 6:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504152152580.7211@ppc970.osdl.org>
On Fri, 15 Apr 2005, Linus Torvalds wrote:
>
> Actually, it turns out that I have a cunning plan.
Damn, my cunning plan is some good stuff.
Or maybe it is _so_ cunning that I just confuse even myself. But it looks
like it is actually working, and that it allows pretty much instantaenous
merges.
The plan goes like this:
- each "index" entry has two bits worth of "stage" state. stage 0 is the
normal one, and is the only one you'd see in any kind of normal use.
- however, when you do "read-tree" with multiple trees, the "stage"
starts out at 0, but increments for each tree you read. And in
particular, the old "-m" flag (which used to be "merge with old state")
has a new meaning: it now means "start at stage 1" instead.
- this means that you can do
read-tree -m <tree1> <tree2> <tree3>
and you will end up with an index with all of the <tree1> entries in
"stage1", all of the <tree2> entries in "stage2" and all of the <tree3>
entries in "stage3".
- furthermore, "read-tree" has this special-case logic that says: if you
see a file that matches in all respects in all three states, it
"collapses" back to "stage0".
- write-tree refuses to write a nonsensical tree, so write-tree will
complain about unmerged entries if it sees a single entry that is not
stage 0".
Ok, this all sounds like a collection of totally nonsensical rules, but
it's actually exactly what you want in order to do a fast merge. The
differnt stages represent the "result tree" (stage 0, aka "merged"), the
original tree (stage 1, aka "orig"), and the two trees you are trying to
merge (stage 2 and 3 respectively).
In fact, the way "read-tree" works, it's entirely agnostic about how you
assign the stages, and you could really assign them any which way, and the
above is just a suggested way to do it (except since "write-tree" refuses
to write anything but stage0 entries, it makes sense to always consider
stage 0 to be the "full merge" state).
So what happens? Try it out. Select the original tree, and two trees to
merge, and look how it works:
- if a file exists in identical format in all three trees, it will
automatically collapse to "merged" state by the new read-tree.
- a file that has _any_ difference what-so-ever in the three trees will
stay as separate entries in the index. It's up to "script policy" to
determine how to remove the non-0 stages, and insert a merged version.
But since the index is always sorted, they're easy to find: they'll be
clustered together.
- the index file saves and restores with all this information, so you can
merge things incrementally, but as long as it has entries in stages
1/2/3 (ie "unmerged entries") you can't write the result.
So now the merge algorithm ends up being really simple:
- you walk the index in order, and ignore all entries of stage 0, since
they've already been done.
- if you find a "stage1", but no matching "stage2" or "stage3", you know
it's been removed from both trees (it only existed in the original
tree), and you remove that entry.
- if you find a matching "stage2" and "stage3" tree, you remove one of
them, and turn the other into a "stage0" entry. Remove any matching
"stage1" entry if it exists too.
.. all the normal trivial rules ..
NOTE NOTE NOTE! I could make "read-tree" do some of these nontrivial
merges, but I ended up deciding that only the "matches in all three
states" thing collapses by default. Why? Because even though there are
other trivial cases ("matches in both merge trees but not in the original
one"), those cases might actually be interesting for the merge logic to
know about, so I thought I'd leave all that information around. I expect
it to be fairly rare anyway, so writing out a few extra index entries to
disk so that others can decide to annotate the merge a bit more sounded
like a fair deal.
I should make "ls-files" have a "-l" format, which shows the index and the
mode for each file too. Right now it's very hard to see what the contents
of the index is. But all my tests seem to say that not only does this
work, it's pretty efficient too. And it's dead _simple_, thanks to having
all the merge information in just one place, the same index we always use
anyway.
Btw, it also means that you don't even have to have a separate
subdirectory for this. All the information literally is in the index file,
which is a temporary thing anyway. We don't need to worry about what is in
the working directory, since we'll never show it, and we'll never need to
use it.
Damn, I'm good.
(On the other hand, it is Friday evening at 11PM, and I'm sitting in front
of the computer. I'm a sad case. I will now go take a beer, and relax. I
think this is another of my "Really Good Ideas" (tm), and is worth the
beer. This "feels" right).
Linus
^ permalink raw reply
* Re: write-tree is pasky-0.4
From: Paul Jackson @ 2005-04-16 6:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: barkalow, pasky, junkio, git
In-Reply-To: <Pine.LNX.4.58.0504152000570.7211@ppc970.osdl.org>
One trick I've used to separate good automatic merges from ones that
need human interaction is to run both the 'patch' and 'merge' commands,
which use different approaches to determining the result.
If they agree, take it. To apply the changes between file1 and file2
to filez:
diff -au file1 file2 | patch -f filez
merge -q filez file1 file2
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* Re: [PATCH 3/2] merge-trees script for Linus git
From: Junio C Hamano @ 2005-04-16 8:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504152152580.7211@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> Damn, my cunning plan is some good stuff.
I really like this a lot. It is *so* *simple*, clear, flexible
and an example of elegance. This is one of the things I would
happily say "Sheeeeeeeeeeeeeesh! Why didn't *I* think of *THAT*
first!!!" to.
LT> NOTE NOTE NOTE! I could make "read-tree" do some of these nontrivial
LT> merges, but I ended up deciding that only the "matches in all three
LT> states" thing collapses by default.
* Understood and agreed.
LT> Damn, I'm good.
* Agreed ;-). Wholeheartedly.
So what's next? Certainly I'd immediately drop (and I would
imagine you would as well) both C or Perl version of
merge-tree(s).
The userland merge policies need ways to extract the stage
information and manipulate them. Am I correct to say that you
mean by "ls-files -l" the extracting part?
LT> I should make "ls-files" have a "-l" format, which shows the
LT> index and the mode for each file too.
You probably meant "ls-tree". You used the word "mode" but it
already shows the mode so I take it to mean "stage". Perhaps
something like this?
$ ls-tree -l -r 49c200191ba2e3cd61978672a59c90e392f54b8b
100644 blob fe2a4177a760fd110e78788734f167bd633be8de COPYING
100644 blob b39b4ea37586693dd707d1d0750a9b580350ec50:1 man/frotz.6
100644 blob b39b4ea37586693dd707d1d0750a9b580350ec50:2 man/frotz.6
100664 blob eeed997e557fb079f38961354473113ca0d0b115:3 man/frotz.6
...
The above example shows that COPYING has merged successfully,
and O and A have the same contents and B has something different
at man/frotz.6.
Assuming that you would be working on that, I'd like to take the
dircache manipulation part. Let's think about the minimally
necessary set of operations:
* The merge policy decides to take one of the existing stage.
In this case we need a way to register a known mode/sha1 at a
path. We already have this as "update-cache --cacheinfo".
We just need to make sure that when "update-cache" puts
things at stage 0 it clears other stages as well.
* The merge policy comes up with a desired blob somewhere on
the filesystem (perhaps by running an external merge
program). It wants to register it as the result of the
merge.
We could do this today by first storing the "desired blob"
in a temporary file somewhere in the path the dircache
controls, "update-cache --add" the temporary file, ls-tree to
find its mode/sha1, "update-cache --remove" the temporary
file and finally "update-cache --cacheinfo" the mode/sha1.
This is workable but clumsy. How about:
$ update-cache --graft [--add] desired-blob path
to say "I want to register mode/sha1 from desired-blob, which
may not be of verify_path() satisfying name, at path in the
dircache"?
* The merge policy decides to delete the path.
We could do this today by first stashing away the file at the
path if it exists, "update-cache --remove" it, and restore
if necessary. This is again workable but clumsy. How about:
$ update-cache --force-remove path
to mean "I want to remove the path from dircache even though
it may exist in my working tree"?
So it all boils down to update-cache. The new things to be
introduced are:
* An explicit update-cache always removes stage 1/2/3 entries
associated with the named path.
* update-cache --graft
* update-cache --force-remove
Am I on the right track?
You might want to go even lower level by letting them say
something like:
* update-cache --register-stage mode sha1 stage path
Registers the mode/sha1 at stage for path. Does not look at
the working tree. stage is [0-3]
* update-cache --delete-stage stage-list path
Removes the entry at named stages for path. Does not look at
the working tree. stage-list is either [0-3](,[0-3])+ or
bitmask (i.e. (1 << stage-number) ORed together). The former
would probably be easier to work with by scripts
* write-blob path
Hashes and registers the file at path (regardless of what
verify_path() says) and writes the resulting blob's mode/sha1
to the standard output.
If you take this lower-level approach, an explicit update-cache
would not clear stage1/2/3.
My preference is the former, not so low-level, interface.
Guidance?
^ permalink raw reply
* [PATCH] Byteorder fix for read-tree, new -m semantics version.
From: Junio C Hamano @ 2005-04-16 9:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vis2ncf8j.fsf@assigned-by-dhcp.cox.net>
The ce_namelen field has been renamed to ce_flags and split into
the top 2-bit unused, next 2-bit stage number and the lowest
12-bit name-length, stored in the network byte order. A new
macro create_ce_flags() is defined to synthesize this value from
length and stage, but it forgets to turn the value into the
network byte order. Here is a fix.
The patch is against 9c03bd47892d11d0bb28c442184786db3c189978.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
cache.h | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- cache.h
+++ cache.h 2005-04-16 02:22:05.000000000 -0700
@@ -66,7 +66,7 @@
#define CE_NAMEMASK (0x0fff)
#define CE_STAGEMASK (0x3000)
-#define create_ce_flags(len, stage) ((len) | ((stage) << 12))
+#define create_ce_flags(len, stage) htons((len) | ((stage) << 12))
const char *sha1_file_directory;
struct cache_entry **active_cache;
^ permalink raw reply
* git-pasky file mode handling
From: Russell King @ 2005-04-16 9:45 UTC (permalink / raw)
To: git
Hi,
It seems that there's something weird going on with the file mode
handling. Firstly, some files in the git-pasky repository have mode
0664 while others have 0644.
Having pulled from git-pasky a number of times, with Petr's being the
"tracked" repository, I now find that when I do an update-cache --refresh,
it complains that the files need updating, despite show-diff showing no
differences. Investigating, this appears to be because the file modes
are wrong for a number of the files. All my files do not have group
write.
I notice in the changelog what appears to be a dependence on the umask.
If this is so, please note that git appears to track the file modes,
and any dependence upon the umask is likely to screw with this tracking.
--
Russell King
^ permalink raw reply
* [PATCH 1/2] Add --stage to show-files for new stage dircache.
From: Junio C Hamano @ 2005-04-16 10:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vis2ncf8j.fsf@assigned-by-dhcp.cox.net>
>>>>> "JNH" == Junio C Hamano <junkio@cox.net> writes:
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> I should make "ls-files" have a "-l" format, which shows the
LT> index and the mode for each file too.
JNH> You probably meant "ls-tree". You used the word "mode" but it
JNH> already shows the mode so I take it to mean "stage".
I was *wrong*. Of course you meant "show-files".
Instead of sending you an apology, I am sending you the one I
wrote myself. Please find it in the next message ;-).
Here is its sample output. It shows file-mode, SHA1, stage and
pathname. I am attaching this one because this is a
verification that your read-tree -m passed the test.
$ ../show-files --stage
100664 578cc900ed980b72acfbdd1eea63e688a893c458 2 AA
100664 f355077379fce072c210628691da232b59b6f25c 3 AA
100664 d698ebc45d0edfe6e5b95aebb5983cb5c760960b 2 AN
100664 0fa6a8e41814531679e1c76e968a9066fceb689d 1 DD
100664 aff448a9467a4d83b164ef969cfe92ff18eb96be 1 DM
100664 4bfe111723f11cb4a4deec7c837e12601030285f 3 DM
100664 9b0f86e5cded99b9de3bd9d234747ec2d1a4cddd 1 DN
100664 9b0f86e5cded99b9de3bd9d234747ec2d1a4cddd 3 DN
100664 a6772f2a2c15bac796d8c7bb55885891956534cf 1 MD
100664 dc2088ce13f659f2bd554b2c1b343f4966143b9b 2 MD
100664 e4310204563a9059828644464779874c3a406fee 1 MM
100664 fe5ddcd7618d26384cf98c6fcd15780c7125e6d6 2 MM
100664 53a9d14868dbe346a9f0cf01fcda742545b55987 3 MM
100664 f48f37ea0205a7e5591777b4d3ae0d153d3ef131 1 MN
100664 d7600381b69b92f61bad50c5f8408e831b622ef0 2 MN
100664 f48f37ea0205a7e5591777b4d3ae0d153d3ef131 3 MN
100664 67fb1517ea8d59949a8e4f5f07f0422b212f64dc 3 NA
100664 0e5842253af8881b2c9f579029d7b50a8e03d7f6 1 ND
100664 0e5842253af8881b2c9f579029d7b50a8e03d7f6 2 ND
100664 0d45c04c9d05fa9c21edf95fc2c1a43519a8c440 1 NM
100664 0d45c04c9d05fa9c21edf95fc2c1a43519a8c440 2 NM
100664 849bfa41d15951f5e97cb93e22cbcc2924ce4517 3 NM
100664 83d94b8fd056921f22ad2ca0122dd7f64974be7c 0 NN
This is taken from the dircache after I ran
$ read-tree -m O A B
using the merge testcase I prepared earlier. Very trivial,
single ancestor O, with two branches A & B merge case. This
covers all possible patterns, except file vs directory
conflicts. The filenames are all two letters, first letter
being what the first branch does to that file while the second
one encodes what the second branch does to it. The actions are:
- A means "Added in this branch --- did not exist in the ancestor."
- N means "No change in this branch."
- D means "Deleted in this branch."
- M means "Modified in this branch."
So, for example, the first branch modified file MN while the
second one did not touch it. Of course it existed in the
ancestor. You can see that read-tree did the right thing
because SHA1 for stage 1 and stage 3 match, and stage 2 is
different.
100664 f48f37ea0205a7e5591777b4d3ae0d153d3ef131 1 MN
100664 d7600381b69b92f61bad50c5f8408e831b622ef0 2 MN
100664 f48f37ea0205a7e5591777b4d3ae0d153d3ef131 3 MN
I verified all of the above result and it shows your algorithm
is doing exactly what is expected.
For those of you who are interested, this is the recipe to
reproduce this merge testcase. NOTE! NOTE! NOTE! Do not run
this in your working tree, because it trashes .git in its
working directory.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
--- /dev/null
+++ generate-merge-test.sh
@@ -0,0 +1,163 @@
+#!/bin/sh
+
+: Skip execution up to <<\End_of_Commentary
+
+This directory is to hold a test case for merges.
+
+There is one ancestor (called O for Original) and two branches A
+and B derived from it. We want to do 3-way merge between A and
+B, using O as the common ancestor.
+
+ merge A O B
+ diff3 A O B
+
+Decisions are made by comparing contents of O, A and B pathname
+by pathname. The result is determined by the following guiding
+principle:
+
+ - If only A does something to it and B does not touch it, take
+ whatever A does.
+
+ - If only B does something to it and A does not touch it, take
+ whatever B does.
+
+ - If both A and B does something but in the same way, take
+ whatever they do.
+
+ - If A and B does something but different things, we need a
+ 3-way merge:
+
+ - We cannot do anything about the following cases:
+
+ * O does not have it. A and B both must be adding to the
+ same path independently.
+
+ * A deletes it. B must be modifying.
+
+ - Otherwise, A and B are modifying. Run 3-way merge.
+
+
+First, the case matrix.
+
+ - Vertical axis is for A's actions.
+ - Horizontal axis is for B's actions.
+
+.----------------------------------------------------------------.
+| A B | No Action | Delete | Modify | Add |
+|------------+------------+------------+------------+------------|
+| No Action | | | | |
+| | select O | delete | select B | select B |
+| | | | | |
+|------------+------------+------------+------------+------------|
+| Delete | | | ********** | can |
+| | delete | delete | merge | not |
+| | | | | happen |
+|------------+------------+------------+------------+------------|
+| Modify | | ********** | ?????????? | can |
+| | select A | merge | select A=B | not |
+| | | | merge | happen |
+|------------+------------+------------+------------+------------|
+| Add | | can | can | ?????????? |
+| | select A | not | not | select A=B |
+| | | happen | happen | merge |
+.----------------------------------------------------------------.
+
+End_of_Commentary
+
+rm -fr [NDMA][NDMA] S .git Trivial
+init-db
+
+# Original tree.
+mkdir S
+for a in N D M
+do
+ for b in N D M
+ do
+ p=$a$b
+ echo This is $p from the original tree. >$p
+ echo This is S/$p from the original tree. >S/$p
+ update-cache --add $p || exit
+ update-cache --add S/$p || exit
+ done
+done
+cat >Trivial <<\EOF
+This is a trivial merge sample text.
+Branch A is expected to upcase this word.
+There are some filler words to foil diff contexts here,
+like this one,
+and this one,
+and this one is yet another one of them.
+At the very end, here comes another line, that is
+the word, expected to be upcased by Branch B.
+This concludes the trivial merge sample file.
+EOF
+update-cache --add Trivial || exit
+tree_O=$(write-tree)
+commit_O=$(echo 'Original tree for the merge test.' | commit-tree $tree_O)
+
+# Branch A and B makes the changes according to the above matrix.
+# Branch A
+to_remove=$(echo D? S/D?)
+rm -f $to_remove
+update-cache --remove $to_remove || exit
+
+for p in M? S/M?
+do
+ echo This is modified $p in the branch A. >$p
+ update-cache $p || exit
+done
+
+for p in AN AA
+do
+ echo This is added $p in the branch A. >$p
+ update-cache --add $p || exit
+done
+mv Trivial ,,Trivial
+sed -e '/Branch A/s/word/WORD/g' <,,Trivial >Trivial
+rm -f ,,Trivial
+update-cache Trivial || exit
+
+tree_A=$(write-tree)
+commit_A=$(echo 'Branch A for the merge test.' |
+ commit-tree $tree_A -p $commit_O)
+
+
+# Branch B
+# Start from O
+rm -rf [NDMA][NDMA] S Trivial
+mkdir S
+../read-tree $tree_O
+checkout-cache -a
+
+to_remove=$(echo ?D S/?D)
+rm -f $to_remove
+update-cache --remove $to_remove || exit
+
+for p in ?M S/?M
+do
+ echo This is modified $p in the branch B. >$p
+ update-cache $p || exit
+done
+
+for p in NA AA
+do
+ echo This is added $p in the branch B. >$p
+ update-cache --add $p || exit
+done
+mv Trivial ,,Trivial
+sed -e '/Branch B/s/word/WORD/g' <,,Trivial >Trivial
+rm -f ,,Trivial
+update-cache Trivial || exit
+
+tree_B=$(write-tree)
+commit_B=$(echo 'Branch B for the merge test.' |
+ commit-tree $tree_B -p $commit_O)
+
+for commit in $commit_O $commit_A $commit_B
+do
+ echo ================
+ echo commit $commit
+ cat-file commit $commit
+done
+echo ================
+
^ permalink raw reply
* [PATCH 2/2] Add --stage to show-files for new stage dircache.
From: Junio C Hamano @ 2005-04-16 10:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vfyxrau23.fsf_-_@assigned-by-dhcp.cox.net>
This adds --stage option to show-files command. It shows
file-mode, SHA1, stage and pathname. Record separator follows
the usual convention of -z option as before.
The patch is on top of the byte order fix for create_ce_flags in my
previous message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
cache.h | 12 +++++++-----
show-files.c | 22 ++++++++++++++++++----
2 files changed, 25 insertions(+), 9 deletions(-)
--- cache.h 2005-04-16 03:02:36.000000000 -0700
+++ cache.h=show-files-stage-flags 2005-04-16 02:48:47.000000000 -0700
@@ -65,8 +65,14 @@
#define CE_NAMEMASK (0x0fff)
#define CE_STAGEMASK (0x3000)
+#define CE_STAGESHIFT 12
-#define create_ce_flags(len, stage) htons((len) | ((stage) << 12))
+#define create_ce_flags(len, stage) htons((len) | ((stage) << CE_STAGESHIFT))
+#define ce_namelen(ce) (CE_NAMEMASK & ntohs((ce)->ce_flags))
+#define ce_size(ce) cache_entry_size(ce_namelen(ce))
+#define ce_stage(ce) ((CE_STAGEMASK & ntohs((ce)->ce_flags)) >> CE_STAGESHIFT)
+
+#define cache_entry_size(len) ((offsetof(struct cache_entry,name) + (len) + 8) & ~7)
const char *sha1_file_directory;
struct cache_entry **active_cache;
@@ -75,10 +81,6 @@
#define DB_ENVIRONMENT "SHA1_FILE_DIRECTORY"
#define DEFAULT_DB_ENVIRONMENT ".git/objects"
-#define cache_entry_size(len) ((offsetof(struct cache_entry,name) + (len) + 8) & ~7)
-#define ce_namelen(ce) (CE_NAMEMASK & ntohs((ce)->ce_flags))
-#define ce_size(ce) cache_entry_size(ce_namelen(ce))
-
#define alloc_nr(x) (((x)+16)*3/2)
/* Initialize and use the cache information */
--- show-files.c
+++ show-files.c 2005-04-16 02:58:32.000000000 -0700
@@ -14,6 +14,7 @@
static int show_cached = 0;
static int show_others = 0;
static int show_ignored = 0;
+static int show_stage = 0;
static int line_terminator = '\n';
static const char **dir;
@@ -108,10 +109,19 @@
for (i = 0; i < nr_dir; i++)
printf("%s%c", dir[i], line_terminator);
}
- if (show_cached) {
+ if (show_cached | show_stage) {
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
- printf("%s%c", ce->name, line_terminator);
+ if (!show_stage)
+ printf("%s%c", ce->name, line_terminator);
+ else
+ printf(/* "%06o %s %d %10d %s%c", */
+ "%06o %s %d %s%c",
+ ntohl(ce->ce_mode),
+ sha1_to_hex(ce->sha1),
+ ce_stage(ce),
+ /* ntohl(ce->ce_size), */
+ ce->name, line_terminator);
}
}
if (show_deleted) {
@@ -156,12 +166,16 @@
show_ignored = 1;
continue;
}
+ if (!strcmp(arg, "--stage")) {
+ show_stage = 1;
+ continue;
+ }
- usage("show-files (--[cached|deleted|others|ignored])*");
+ usage("show-files [-z] (--[cached|deleted|others|ignored|stage])*");
}
/* With no flags, we default to showing the cached files */
- if (!(show_cached | show_deleted | show_others | show_ignored))
+ if (!(show_stage | show_deleted | show_others | show_ignored))
show_cached = 1;
read_cache();
^ permalink raw reply
* Re: Re: Re: Add "clone" support to lntree
From: Petr Baudis @ 2005-04-16 11:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.58.0504152014330.7211@ppc970.osdl.org>
Dear diary, on Sat, Apr 16, 2005 at 05:16:12AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> On Sat, 16 Apr 2005, Petr Baudis wrote:
> >
> > I'm wondering, whether each tree should be fixed to a certain branch.
>
> I'm wondering why you talk about "branches" at all.
>
> No such thing should exist. There are no branches. There are just
> repositories. You can track somebody elses repository, but you should
> track it by location, not by any "branch name".
>
> And you track it by just merging it.
>
> Yeah, we don't have really usable merges yet, but..
First, this "level" of branches concerns multiple working directories
tied to a single repository. It seems like a sensible thing to do; and
you agreed with it too (IIRC). And when you do that, git-pasky just
saves some work for you. For git-pasky, branch is really just a symbolic
name for a commit ID, which gets updated every time you commit in some
repository. Nothing more.
So the whole point of this is to have a symbolic name for some other
working directory. When you want to merge, you don't need to go over to
the other directory, do commit-id, cut'n'paste, and feed that to git
merge. You just do
git merge myotherbranch
Now, about remote repositories. When you pull a remote repository, that
does not mean it has to be immediately merged somewhere. It is very
useful to have another branch you do *not* want to merge, but you want
to do diffs to it, or even check it out / export it later to some
separate directory. Again, the "branch" is just a symbolic name for the
head commit ID of what you pulled, and the pointer gets updated every
time you pull again - that's the whole point of it.
The last concept are "tracking" working directories. If you pull the
tracked branch to this directory, it also automerges it. This is useful
when you have a single canonical branch for this directory, which it
should always mirror. That would be the case e.g. for the gazillions of
Linux users who would like to just have the latest bleeding kernel of
your, and they expect to use git just like a "different CVS". Basically,
they will just do
git pull
instead of
cvs update
:-).
--
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: Merge with git-pasky II.
From: David Lang @ 2005-04-16 12:19 UTC (permalink / raw)
To: simon; +Cc: Linus Torvalds, David Woodhouse, Junio C Hamano, Petr Baudis, git
In-Reply-To: <20050416014442.GW4488@himi.org>
On Fri, Apr 15, 2005 at 08:32:46AM -0700, Linus Torvalds wrote:
> In other words, I'm right. I'm always right, but sometimes I'm more
right
> than other times. And dammit, when I say "files don't matter", I'm
really
> really Right(tm).
>
You're right, of course (All Hail Linus!), if you can make it work
efficiently enough.
Just to put something else on the table, here's how I'd go about
tracking renames and the like, in another world where Linus /does/
make the odd mistake - it's basically a unique id for files in the
repository, added when the file is first recognised and updated when
update-cache adds a new version to the cache. Renames copy the id
across to the new name, and add it into the cache.
This gives you an O(n) way to tell what file was what across
renames, and it might even be useful in Linus' world, or if someone
wanted to build a traditional SCM on top of a git-a-like.
Attached is a patch, and a rename-file.c to use it.
Simon
given that you have multiple machines creating files, how do you deal with
the idea of the same 'unique id' being assigned to different files by
different machines?
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply
* SHA1 hash safety
From: David Lang @ 2005-04-16 12:24 UTC (permalink / raw)
To: git
this issue was raised a few days ago in the context of someone tampering
with the files and it was decided that the extra checks were good enough
to prevent this (at least for now), but what about accidental collisions?
if I am understanding things right the objects get saved in the filesystem
in filenames that are the SHA1 hash. of two legitimate files have the same
hash I don't see any way for both of them to exist.
yes the risk of any two files having the same has is low, but in the
earlier thread someone chimed in and said that they had two files on their
system that had the same hash..
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply
* Re: space compression (again)
From: David Lang @ 2005-04-16 12:29 UTC (permalink / raw)
To: Ray Heasman; +Cc: git
In-Reply-To: <1113593583.29624.46.camel@maze.mythral.org>
we alrady have the concept of objects that contain objects and therefor
don'e need to be re-checked (directories), the chunks inside a file could
be the same type of thing.
currently we say that if the hash on the directory is the same we don't
need to re-check each of the files in that directory, this would be that
if the hash on the file hasn't changed we don't need to re-check the
chunks inside that file.
David Lang
On Fri, 15 Apr 2005, Ray Heasman wrote:
> Date: Fri, 15 Apr 2005 12:33:03 -0700
> From: Ray Heasman <lists@mythral.org>
> To: git@vger.kernel.org
> Subject: Re: space compression (again)
>
> For for this email not threading properly, I have been lurking on the
> mail list archives and just had to reply to this message.
>
> I was planning to ask exactly this question, and Scott beat me to to. I
> even wanted to call them "chunks" too. :-)
>
> It's probably worthwhile for anyone discussing this subject to read this
> link: http://www.cs.bell-labs.com/sys/doc/venti/venti.pdf . I know it's
> been posted before, but it really is worth reading. :-)
>
> On Fri, 15 Apr 2005, Linus Torvalds wrote:
>> On Fri, 15 Apr 2005, C. Scott Ananian wrote:
>>>
>>> Why are blobs per-file? [After all, Linus insists that files are an
>>> illusion.] Why not just have 'chunks', and assemble *these*
>>> into blobs (read, 'files')? A good chunk size would fit evenly into some
>>> number of disk blocks (no wasted space!).
>>
>> I actually considered that. I ended up not doing it, because it's not
>> obvious how to "block" things up (and even more so because while I like
>> the notion, it flies in the face of the other issues I had: performance
>> and simplicity).
>
> I don't think it's as bad as you think.
>
> Let's conceptually have two types of files - Pobs (Proxy Objects, or
> Pointer Objects), and chunks. Both are stored and referenced by their
> content hash, as usual. Pobs just contain a list of hashes referencing
> the chunks in a file. When a file is initially stored, we chunk it so
> each chunk fits comfortably in a block, but otherwise we aren't too
> critical about sizes. When a file is changed (say, a single line edit),
> we update the chunk that contains that line, hash it and store it with
> its new name, and update the Pob, which we rehash and restore. If a
> chunk grows to be very large (say > 2 disk blocks), we can rechunk it
> and update the Pob to include the new chunks.
>
>> The problem with chunking is:
>> - it complicates a lot of the routines. Things like "is this file
>> unchanged" suddenly become "is this file still the same set of chunks",
>> which is just a _lot_ more code and a lot more likely to have bugs.
>
> You're half right; it will be more complex, but I don't think it's as
> bad as you think. Pobs are stored by hash just like anything else. If
> some chunks are different, the pob is different, which means it has a
> different hash. It's exactly the same as dealing with changed file now.
> Sure, when you have to fetch the data, you have to read the pob and get
> a list of chunks to concatenate and return, but your example given
> doesn't change.
>
>> - you have to find a blocking factor. I thought of just going it fixed
>> chunks, and that just doesn't help at all.
>
> Just use the block size of the filesystem. Some filesystems do tail
> packing, so space isn't an issue, though speed can be. We don't actually
> care how big a chunk is, except to make it easy on the filesystem.
> Individual chunks can be any size.
>
>> - we already have wasted space due to the low-level filesystem (as
>> opposed to "git") usually being block-based, which means that space
>> utilization for small objects tends to suck. So you really want to
>> prefer objects that are several kB (compressed), and a small block just
>> wastes tons of space.
>
> If a chunk is smaller than a disk block, this is true. However, if we
> size it right this is no worse than any other file. Small files (less
> than a block) can't be made any larger, so they waste space anyway.
> Large files end up wasting space in one block unless they are a perfect
> multiple of the block size.
>
> When we increase the size of a chunk, it will waste space, but we would
> have created an entire new file, so we win there too.
>
> Admittedly, Pobs will be wasting space too.
>
> On the other hand, I use ReiserFS, so I don't care. ;-)
>
>> - there _is_ a natural blocking factor already. That's what a file
>> boundary really is within the project, and finding any other is really
>> quite hard.
>
> Nah. I think I've made a good case it isn't.
>
>> So I'm personally 100% sure that it's not worth it. But I'm not opposed to
>> the _concept_: it makes total sense in the "filesystem" view, and is 100%
>> equivalent to having an inode with pointers to blocks. I just don't think
>> the concept plays out well in reality.
>
> Well, the reason I think this would be worth it is that you really win
> when you have multiple parallel copies of a source tree, and changes are
> cheaper too. If you store all the chunks for all your git repositories
> in one place, and otherwise treat your trees of Pobs as the real
> repository, your copied trees only cost you space for the Pobs.
> Obviously this also applies for file updates within past revisions of a
> tree, but I don't know how much it would save. It fits beautifully into
> the current abstraction, and saves space without having to resort to
> rolling hashes or xdeltas.
>
> The _real_ reason why I am excited about git is that I have a vision of
> using this as the filesystem (in a FUSE wrapper or something) for my
> home directory. MP3s and AVIs aside, it will make actual work much
> easier for me. I have a dream; a dream where I save files using the same
> name, safe in the knowledge that I can get to any version I want. I will
> live in a world of autosaves, deletes without confirmation, and /etcs
> immune from the vagaries of my package management systems, not to
> mention users not asking me leading questions about backups. *sigh*
> *sniff* Excuse me, I think I have to go now.
>
> -Ray
>
>
> -
> 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
>
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply
* Re: SHA1 hash safety
From: Ingo Molnar @ 2005-04-16 12:31 UTC (permalink / raw)
To: David Lang; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0504160519330.21837@qynat.qvtvafvgr.pbz>
* David Lang <david.lang@digitalinsight.com> wrote:
> this issue was raised a few days ago in the context of someone
> tampering with the files and it was decided that the extra checks were
> good enough to prevent this (at least for now), but what about
> accidental collisions?
>
> if I am understanding things right the objects get saved in the
> filesystem in filenames that are the SHA1 hash. of two legitimate
> files have the same hash I don't see any way for both of them to
> exist.
>
> yes the risk of any two files having the same has is low, but in the
> earlier thread someone chimed in and said that they had two files on
> their system that had the same hash..
you can add -DCOLLISION_CHECK to Makefile:CFLAGS to turn on collision
checking (disabled currently). If there indeed exist two files that have
different content but the same hash, could someone send those two files?
Ingo
^ permalink raw reply
* Re: SHA1 hash safety
From: David Lang @ 2005-04-16 12:48 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20050416123155.GA19908@elte.hu>
On Sat, 16 Apr 2005, Ingo Molnar wrote:
> * David Lang <david.lang@digitalinsight.com> wrote:
>
>> this issue was raised a few days ago in the context of someone
>> tampering with the files and it was decided that the extra checks were
>> good enough to prevent this (at least for now), but what about
>> accidental collisions?
>>
>> if I am understanding things right the objects get saved in the
>> filesystem in filenames that are the SHA1 hash. of two legitimate
>> files have the same hash I don't see any way for both of them to
>> exist.
>>
>> yes the risk of any two files having the same has is low, but in the
>> earlier thread someone chimed in and said that they had two files on
>> their system that had the same hash..
>
> you can add -DCOLLISION_CHECK to Makefile:CFLAGS to turn on collision
> checking (disabled currently). If there indeed exist two files that have
> different content but the same hash, could someone send those two files?
remember that the flap over SHA1 being 'broken' a couple weeks ago was not
from researchers finding multiple files with the same hash, but finding
that it was more likly then expected that files would have the same hash.
there was qa discussion on LKML within the last year about useing MD5
hashes for identifying unique filesystem blocks (with the idea of being
able to merge identical blocks) and in that discussion it was pointed out
that collisions are a known real-life issue.
so if collision detection is turned on in git, does that make it error out
if it runs into a second file with the same hash, or does it do something
else?
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply
* full kernel history, in patchset format
From: Ingo Molnar @ 2005-04-16 13:15 UTC (permalink / raw)
To: git
i've converted the Linux kernel CVS tree into 'flat patchset' format,
which gave a series of 28237 separate patches. (Each patch represents a
changeset, in the order they were applied. I've used the cvsps utility.)
the history data starts at 2.4.0 and ends at 2.6.12-rc2. I've included a
script that will apply all the patches in order and will create a
pristine 2.6.12-rc2 tree.
it needed many hours to finish, on a very fast server with tons of RAM,
and it also needed a fair amount of manual work to extract it and to
make it usable, so i guessed others might want to use the end result as
well, to try and generate large GIT repositories from them (or to run
analysis over the patches, etc.).
the patches contain all the existing metadata, dates, log messages and
revision history. (What i think is missing is the BK tree merge
information, but i'm not sure we want/need to convert them to GIT.)
it's a 136 MB tarball, which can be downloaded from:
http://kernel.org/pub/linux/kernel/people/mingo/Linux-2.6-patchset/
the ./generate-2.6.12-rc2 script generates the 2.6.12-rc2 tree into
linux/, from scratch. (No pre-existing kernel is needed, as 2.patch
generates the full 2.4.0 kernel tree.) The patching takes a couple of
minutes to finish, on a fast box.
below i've attached a sample patch from the series.
note: i kept the patches the cvsps utility generated as-is, to have a
verifiable base to work on. There were a very small amount of deltas
missed (about a dozen), probably resulting from CVS related errors,
these are included in the diff-CVS-to-real patch. Also, the patch format
cannot create the Documentation/logo.gif file, so the script does this
too - just to be able to generate a complete 2.6.12-rc2 tree that is
byte-for-byte identical to the real thing.
Ingo
---------------------
PatchSet 1234
Date: 2002/04/11 18:29:07
Author: viro
Branch: HEAD
Tag: (none)
Log:
[PATCH] crapectomy in include/linux/nfsd/syscall.h
Removes an atavism in declaration of sys_nfsservctl() - sorry, I should've
remove that junk when cond_syscall() thing was done.
BKrev: 3cb5c7e3phTYgiz1YLsjQ_McTo9pOQ
Members:
ChangeSet:1.1234->1.1235
include/linux/nfsd/syscall.h:1.3->1.4
Index: linux/include/linux/nfsd/syscall.h
===================================================================
RCS file: /home/mingo/linux-CVS/linux/include/linux/nfsd/syscall.h,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- linux/include/linux/nfsd/syscall.h 15 Mar 2002 23:06:06 -0000 1.3
+++ linux/include/linux/nfsd/syscall.h 11 Apr 2002 17:29:07 -0000 1.4
@@ -132,11 +132,7 @@
/*
* Kernel syscall implementation.
*/
-#if defined(CONFIG_NFSD) || defined(CONFIG_NFSD_MODULE)
extern asmlinkage long sys_nfsservctl(int, struct nfsctl_arg *, void *);
-#else
-#define sys_nfsservctl sys_ni_syscall
-#endif
extern int exp_addclient(struct nfsctl_client *ncp);
extern int exp_delclient(struct nfsctl_client *ncp);
extern int exp_export(struct nfsctl_export *nxp);
^ permalink raw reply
* using git directory cache code in darcs?
From: David Roundy @ 2005-04-16 13:22 UTC (permalink / raw)
To: git; +Cc: darcs-devel
Hello Linus and various git developers (ccing darcs developers),
I've been thinking about the possibility of using the git "current
directory cache" code in darcs. Darcs already has an abstraction layer
over its pristine directory cache, so this shouldn't be too hard--provided
the git code is understandable. The default in darcs is currently to use
an actual directory ("_darcs/current/") as the cache, and we synchronize
the file modification times in the cache with those of identical files in
the working directory to speed up compares. We (the darcs developers) have
talked for some time about introducing a single-file directory cache, but
noone ever got around to it, partly because there wasn't a particularly
compelling need.
It seems that the git directory cache is precisely what we want. Also, if
we switch to (optionally) using the git directory cache, I imagine it'll
make interfacing with git a lot easier. And, of course, it would
significantly speed up a number of darcs commands, which are limited by the
slowness of the readdir-related code. We haven't tracked this down why
this is, but a recursive directory compare in which we readdir only one of
the directories (since we don't care about new files in the other one)
takes half the time of a compare in which we readdir both directories.
So my questions are:
1) Would this actually be a good idea? It seems good to me, but there may
be other considerations that I haven't thought of.
2) Will a license be chosen soon for git? Or has one been chosen, and I
missed it? I can't really include git code in darcs without a license. I'd
prefer GPLv2 or later (since that's how darcs is licensed), but as long as
it's at least compabible with GPLv2, I'll be all right.
3) Is it likely that git will switch to not using global variables for
active_cache, active_nr and active_alloc? I'd be more comfortable passing
these things around, since it would make the haskell interface easier and
safer. e.g. I'd like
struct git_cache {
struct cache_entry **cache;
unsigned int nr, alloc;
};
git_cache *read_cache(char *path_to_index);
or alternatively
int read_cache(char *path_to_index, git_cache *);
Would anyone on the git side be interested in making such changes? If not,
would they be likely to be accepted if a darcs person submitted patches?
4) Would there be interest in creating a libgit? I've been imagining taking
git source files and including them directly in darcs' code, but in the
long run it would be easier if there were a standard git API we could use.
I guess that's about all.
--
David Roundy
http://www.darcs.net
^ permalink raw reply
* Re: SHA1 hash safety
From: Brian O'Mahoney @ 2005-04-16 13:29 UTC (permalink / raw)
To: David Lang; +Cc: Ingo Molnar, git
In-Reply-To: <Pine.LNX.4.62.0504160542190.21837@qynat.qvtvafvgr.pbz>
Three points:
(1) I _have_ seen real-life collisions with MD5, in the context of
Document management systems containing ~10^6 ms-WORD documents.
(2) The HMAC (ethernet-harware-address) of any interface _should_
help to make a unique Id.
(3) While I havn't looked at the details of the plumbing, this is
the time to make sure we can, easily, drop in SHA-160, SHA-256
(or whatever comes from NIST) when needed.
David Lang wrote:
> On Sat, 16 Apr 2005, Ingo Molnar wrote:
>
>> * David Lang <david.lang@digitalinsight.com> wrote:
>>
>>> this issue was raised a few days ago in the context of someone
>>> tampering with the files and it was decided that the extra checks were
>>> good enough to prevent this (at least for now), but what about
>>> accidental collisions?
>>>
>>> if I am understanding things right the objects get saved in the
>>> filesystem in filenames that are the SHA1 hash. of two legitimate
>>> files have the same hash I don't see any way for both of them to
>>> exist.
>>>
>>> yes the risk of any two files having the same has is low, but in the
>>> earlier thread someone chimed in and said that they had two files on
>>> their system that had the same hash..
>>
>>
>> you can add -DCOLLISION_CHECK to Makefile:CFLAGS to turn on collision
>> checking (disabled currently). If there indeed exist two files that have
>> different content but the same hash, could someone send those two files?
>
>
> remember that the flap over SHA1 being 'broken' a couple weeks ago was
> not from researchers finding multiple files with the same hash, but
> finding that it was more likly then expected that files would have the
> same hash.
>
> there was qa discussion on LKML within the last year about useing MD5
> hashes for identifying unique filesystem blocks (with the idea of being
> able to merge identical blocks) and in that discussion it was pointed
> out that collisions are a known real-life issue.
>
> so if collision detection is turned on in git, does that make it error
> out if it runs into a second file with the same hash, or does it do
> something else?
>
> David Lang
>
--
Brian
^ permalink raw reply
* Re: using git directory cache code in darcs?
From: Ingo Molnar @ 2005-04-16 13:31 UTC (permalink / raw)
To: git, darcs-devel
In-Reply-To: <20050416132231.GJ2551@abridgegame.org>
* David Roundy <droundy@abridgegame.org> wrote:
> 2) Will a license be chosen soon for git? Or has one been chosen, and
> I missed it? I can't really include git code in darcs without a
> license. I'd prefer GPLv2 or later (since that's how darcs is
> licensed), but as long as it's at least compabible with GPLv2, I'll be
> all right.
there's a license in the latest code, it's GPLv2. Here's the COPYING
file:
---------------
Note that the only valid version of the GPL as far as this project
is concerned is _this_ particular version of the license (ie v2, not
v2.2 or v3.x or whatever), unless explicitly otherwise stated.
HOWEVER, in order to allow a migration to GPLv3 if that seems like
a good idea, I also ask that people involved with the project make
their preferences known. In particular, if you trust me to make that
decision, you might note so in your copyright message, ie something
like
This file is licensed under the GPL v2, or a later version
at the discretion of Linus.
might avoid issues. But we can also just decide to synchronize and
contact all copyright holders on record if/when the occasion arises.
Linus Torvalds
----------------------------------------
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
\f
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
\f
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
\f
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
\f
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
\f
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program 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 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) year name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, the commands you use may
be called something other than `show w' and `show c'; they could even be
mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the program, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
<signature of Ty Coon>, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.
^ 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