[PATCH 3/6] git-gnu-progs-Makefile: git Makefile update
Update the git Makefile to put the results of config.sh into the scripts.
config.sh searches for gnu utilities cp, stat, date and xargs.
Signed-off-by: Bryan Larsen [EMAIL PROTECTED]
---
Makefile | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -51,9 +51,18 @@ PROG= git-update-cache git-diff-files
all: $(PROG)
-install: $(PROG) $(SCRIPTS)
+config: config.sh
+ ./config.sh
+
+install: $(PROG) $(SCRIPTS) config
$(INSTALL) -m755 -d $(dest)$(bin)
$(INSTALL) $(PROG) $(SCRIPTS) $(dest)$(bin)
+ . ./config ; \
+ cd $(dest)$(bin) ; \
+ for file in $(SCRIPTS); do \
+ sed -e s/DATE\=date/DATE=$${DATE}/ -e s/CP\=cp/CP=$${CP}/
-e s/XARGS\=xargs/XARGS=$${XARGS}/ -e s/STAT\=stat/STAT=$${STAT}/ $$file
$$file.new; \
+ cat $$file.new $$file; rm $$file.new; \
+ done
LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o \
tag.o date.o index.o diff-delta.o patch-delta.o entry.o path.o \
@@ -190,7 +199,7 @@ test: all
$(MAKE) -C t/ all
clean:
- rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE)
+ rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE) config
$(MAKE) -C Documentation/ clean
backup: clean
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] darwinports-Portfile: Portfile for cogito
A Portfile for darwinports.
Signed-off-by: Bryan Larsen [EMAIL PROTECTED]
---
Makefile|2 ++
Portfile.in | 25 +
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -240,6 +240,8 @@ dist: cogito.spec
@rm $(tarname)/cogito.spec
@rmdir $(tarname)
gzip -9 $(tarname).tar
+ sed -e 's/@@VERSION@@/$(shell cat $(VERSION) | cut -d- -f2)/g'
Portfile.in Portfile
+ echo checksums md5 `md5sum $(tarname).tar.gz | cut -d ' ' -f 1`
Portfile
clean:
rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(GEN_SCRIPT) $(LIB_FILE)
config
diff --git a/Portfile.in b/Portfile.in
new file mode 100644
--- /dev/null
+++ b/Portfile.in
@@ -0,0 +1,25 @@
+# $Id: $
+PortSystem1.0
+name cogito
+version @@VERSION@@
+categoriesdevel
+maintainers [EMAIL PROTECTED]
+description Git core + cogito tools to provide a full distributed SCM.
+long_description The git core, developed by Linus Torvalds provides \
+ an extremely fast and flexible filesystem-based \
+ database designed to store directory trees with \
+ regard to their history. The cogito tools, \
+ developed by Petr Baudis, provide full distributed \
+ SCM (software change management) functionality.
+homepage http://kernel.org/pub/software/scm/cogito/
+master_sites http://kernel.org/pub/software/scm/cogito/
+configure{}
+depends_lib bin:gcp:coreutils
+depends_lib bin:gnuxargs:findutils
+build.typegnu
+destroot.type gnu
+destroot.destdir prefix=${prefix} DESTDIR=${destroot}
+test.run yes
+test.cmd make
+test.target test
+test.dir ${worksrcpath}
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trial git RPM's..
Linus Torvalds [EMAIL PROTECTED] writes: Ok, I tagged a v0.99 thing, and pushed it out. I've also made trial RPM's of it: src, ppc64 and x86. They're build on whatever random machines I had, and on the ppc64 I chose to do it on my FC4 machine that has newer libraries than my YDL one. The x86 thing is FC3, I do believe. I haven't really verified the RPM's in any other way than a trial installation on one machine, and gitk seemed to work. Whoop. The idea being that this is a good way to check whether the rpm target works, _and_ cogito can have something to build against. A couple of pieces. The dist target has assumes git-tar-tree is in the path. Making it so you have to have git installed to build the rpm. The man pages are not built. The build dependencies do not call out the tools necessary to build the man pages. And it does not pass my torture test of building rpm's on debian, but that is not a huge problem. Are you still up for a patch that records who and when made a tag? I sent one but it seems to have been lost. Eric - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rev-list: add --full-objects flag.
On Mon, 11 Jul 2005, Eric W. Biederman wrote: I guess I was expecting to pull from one tree into another unrelated tree. Getting a tree with two heads and then be able to merge them together. You can do it, but you have to do it by hand. It's a valid operation, but it's not an operation I want people to do by mistake, so it's not something the trivial helper scripts help with. The way to do it by hand is to just use something stupid that doesn't understand what it's doing anyway, and just copy the files over. cp -a or rsync works fine. Then just do git resolve by hand. It's not very hard at all, but it's definitely something that should be a special case. A couple of questions. 1) Does git-clone-script when packed copy the entire repository or just take a couple of slices of the tree where you have references? It only gets the objects needed for the references, nothing more. So if you only get one branch, it will leave the objects that are specific to other branches alone. 2) Is there a way for a pack to create deltas against objects that are not in the tree? For a dumb repository making incremental changes this is ideal. A pack can only have deltas against objects in that pack. It caan't even have deltas to other objects in the same tree, it literally is only _within_ a pack. This is so that each pack is totally independent: you can always unpack (and verify) the objects in a pack _without_ having anything else (of course, the end result is often not a full project, and you won't have any references, but at least the _objects_ are valid). I don't want to have deltas to outside the pack, because while it's obviously very nice from a size packing standpoint, it's totally horrid from an infrastructure standpoint. It would make it possible to have circular dependencies (ie deltas against each other) that could only be resolved by having a third pack (or the unpacked object). It would also means that you may have to have two packs mapped at the same time to unpack them, which was very much against what I was aiming for: I think that in the long run, for truly huge projects, you'd want to have a history of packs, each maybe a gigabyte in size, and you may be in the situation that you simply cannot have two packs mapped at the same time because you don't have enough virtual memory for it. So then inter-pack deltas would mean that you'd have to have partial pack mapping etc horrid special case logic. Right now, because a pack is always self-sufficient, you know that in order to unpack an object, if you find it in the index file, you will be able to unpack it by just mapping that pack and going off.. So the rule is: don't pack too often. The unpacked objects are actually working really really well as long as you don't have tens of thousands of them. Having a few hundred (or even a few thousand) unpacked objects is not a problem at all. Then you do a git repack when it starts getting uncomfortable, and you you continue. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Design for http-pull on repo with packs
The big problem, however, comes when Jeff (or anyone else) decides to repack. Then, if you fetch both his repo and Linus', you might end up with several really big pack files, that mostly overlap. That could easily mean storing most objects many times, if you don't do some smart selective un/repacking when fetching. So although it is possible to pack and re-pack at any time, perhaps we need some guidelines? Maybe Linus should just do a re-pack as each 2.6.x release is made (or perhaps just every 2.6.even release if that is too often). It has already been noted offlist that repositories hosted on kernel.org can just copy pack files from Linus (or even better hardlink them). -Tony - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Support for packs in HTTP
On Mon, 11 Jul 2005, Daniel Barkalow wrote: On Sun, 10 Jul 2005, Linus Torvalds wrote: You really _mustn't_ try to create the pack directly to the $GIT_DIR/objects/pack subdirectory - that would make git itself start possibly using that pack before the index is all done, and that would be just wrong and nasty. So you really should _always_ generate the pack somewhere else, and then move it (pack file first, index file second). It's currently fine ignoring index files without corresponding pack files (sha1_file.c, line 470). That doesn't help. Redgardless of which order you write them (and you _will_ write the pack-file first), you'll find that at some point you have both files, but one or the other isn't fully written, ie they are unusable. And yes, you can handle that by always checking the SHA1 of the files when you open them, but the fact is, you shouldn't need to, just to use it. Checking the SHA1 of the pack-file in particular is very expensive (since it's potentially a huge file, and you don't even want to read all of it). So you could have rules like: pack-file must get populated first, and index file must be SHA1-checked by all users. Or, you could just have a saner rule: create the pack-files somewhere else, and move them atomically to the right place. Problem solved. So that's what I decided the rule is: never ever have a partial file, and thus you can by definition use them immediately when you see both files. But that requires that you write them under another name than the final one. And since you want that _anyway_ for other uses, you don't hide that inside git-pack-objects, but you make it an exported interface. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rev-list: add --full-objects flag.
On Mon, 11 Jul 2005, Eric W. Biederman wrote: I'm having the worst time putting together a mental model of how git works, and the documentation is spotty enough that it hasn't been helpful. So I am wading through the code. It seems every time I turn a corner there is another rough spot. Btw, I know I'm bad at writing docs, but what I _do_ enjoy doing is answering reasonably specific technical questions, and maybe somebody else can write docs by taking advantage of me that way. I tried to write the tutorial in a way that it also tries to explain how git works (not just a do this, but a you update the index file and then write the result out as a tree object), but it obviously covers a fairly limited part of what git actually can do, and at the same time it doesn't go into a lot of detail. And part of that is not just my inability to write documentation, it's also that I just have the wrong view of the project, ie I probably just take a lot of things for granted and consider them obvious, even though they aren't, and then I probably occasionally explain things that aren't worth explaining, because either they _are_ obvious, or people just don't care and they are irrelevant. I'd love to see somebody write up more of a this is how you use git kind of tutorial, _and_ on the other hand more of a low-level explanation of the notion of an object store where objects refer to each other by their SHA1 names, and how that is represented in the filesystem and/or in packs. Something with a few pictures would be great (ie screenshots of gitk, but also something that tries to just visually show hot tags point to commits that point to parents and trees, and trees pointing to other trees and then blobs). All things that I'm a complete idiot at, but that would help users visualize what the heck git is actually _doing_, so that they don't just parrot some magic command line that they don't understand, but can actually reason about what they are doing. I think a lot of people do understand this, but yes, the docs are kind of lacking. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Dereference tag repeatedly until we get a non-tag.
This seems reasonable to me. I have thought this would be useful on
several occasions and haven't yet conceived of a counterexample where
it would break something.
On 7/11/05, Junio C Hamano [EMAIL PROTECTED] wrote:
When we allow a tag object in place of a commit object, we only
dereferenced the given tag once, which causes a tag that points
at a tag that points at a commit to be rejected. Instead,
dereference tag repeatedly until we get a non-tag.
This patch makes change to two functions:
- commit.c::lookup_commit_reference() is used by merge-base,
rev-tree and rev-parse to convert user supplied SHA1 to that of
a commit.
- rev-list uses its own get_commit_reference() to do the same.
Dereferencing tags this way helps both of these uses.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
*** Whether having a tag pointing at another tag is a separate
*** issue, but I do not see a reason to forbid it. Maybe it
*** is used to represent a chain of trust.
commit.c |5 +++--
rev-list.c |4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
0dc9377363ee73c5e3f3711d6f82e49886ce8c6a
diff --git a/commit.c b/commit.c
--- a/commit.c
+++ b/commit.c
@@ -52,8 +52,9 @@ struct commit *lookup_commit_reference(c
if (!obj)
return NULL;
- if (obj-type == tag_type)
- obj = ((struct tag *)obj)-tagged;
+ while (obj-type == tag_type)
+ obj = parse_object(((struct tag *)obj)-tagged-sha1);
+
return check_commit(obj, sha1);
}
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -367,12 +367,12 @@ static struct commit *get_commit_referen
/*
* Tag object? Look what it points to..
*/
- if (object-type == tag_type) {
+ while (object-type == tag_type) {
struct tag *tag = (struct tag *) object;
object-flags |= flags;
if (tag_objects !(object-flags UNINTERESTING))
add_pending_object(object, tag-tag);
- object = tag-tagged;
+ object = parse_object(tag-tagged-sha1);
}
/*
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: arch 2.0 first source available (git related)
Dear diary, on Sat, Jul 09, 2005 at 04:20:13PM CEST, I got a letter where Thomas Lord [EMAIL PROTECTED] told me that... The prereq graph is, indeed, an improvement. ..snip.. But object retrieval can be potentially as much as linear to the depth of the prereq graph, right? I don't think any of the benefits you listed are worth the complication, and you can still do the reachability analysis pretty easily. (And I think it takes the same number of roundtrips when downloading from remote server?) Other advantageous (imo) changes from `git' not mentioned in the original message: * blobs do not have header lines Git blobs all begin with a line of text declaring the type and size of the blob. That doesn't increase database verifiability significantly and I found no use for the headers. Having the headers makes it needlessly complicated to translate a file to or from a blob. `revc' does not have blob headers. In git, this is crucial at least for distinguishing commits and tags. I personally consider the verifiability boost useful. * `revc' uses portable file formats In working dirs, `git' stores binary files which are endian, word-size, and compiler-environment specific. `revc' stores some binary files too (for performance and simplicity reasons) but uses only portable formats. I think they are only word-size specific, and that should be no big matter to resolve, shall anyone want to. * `revc' is shaping up into much cleaner and more portable code (at least compared to the last version of `git' I saw -- which was extremely *lucid* code but not terribly clean and not even attempting to be portable.) All right, the portability could be better. ;-) Kind regards, -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ Espy be careful, some twit might quote you out of context.. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] git-gnu-progs-Makefile: git Makefile update
Linus Torvalds wrote: On Mon, 11 Jul 2005, Junio C Hamano wrote: I am not yet convinced one variable per GNU program is the right way to do (I do agree it is a problem and I appreciate your trying to solving it; an obvious alternative cop-out would be to fix this in the user's environment, but there might be a saner solution) Yes. As you say, if we do this (and I think it's so ugly that I'm not convinced we want to), it should be done in git-sh-setup-script _once_ instead of editing every single script. Agreed: I was much happier with my cogito implementation where I just put it in cg-Xlib. Is git-sh-setup-script appropriate? At first glance it had a specific purpose and was not included in a large number of files. Most everything includes git-sh-setup-script anyway by now. However, what are the features that break the default apple tools anyway? Maybe we should avoid using them? OSX clearly comes with cp and xargs regardless, what are the flags that don't work with their cruddy versions? xargs -r, cp -l, cp -u, cp -a. Git uses the first 2, cogito uses all 4. Last night, I couldn't think of alternatives to these, but I obviously didn't try very hard. xargs -r can probably happen via a temporary file and cp -u can probably be simulated using rsync. [ Rant mode on: ..and who the hell is the idiot at Apple who includes the old crappy BSD stuff? They already use gcc, so it's totally pointless to have a NIH thing, when the GNU utilities are just _better_. Maybe somebody can ask Apple to get with the program and not live in the dark ages any more. ] It wasn't long ago that the BSD's and Solaris had the same problems. If only Apple is in the dark ages, shame on them. Bryan - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trial git RPM's..
* Eric W. Biederman ([EMAIL PROTECTED]) wrote: Linus Torvalds [EMAIL PROTECTED] writes: Ok, I tagged a v0.99 thing, and pushed it out. I've also made trial RPM's of it: src, ppc64 and x86. They're build on whatever random machines I had, and on the ppc64 I chose to do it on my FC4 machine that has newer libraries than my YDL one. The x86 thing is FC3, I do believe. I haven't really verified the RPM's in any other way than a trial installation on one machine, and gitk seemed to work. Whoop. The idea being that this is a good way to check whether the rpm target works, _and_ cogito can have something to build against. A couple of pieces. The dist target has assumes git-tar-tree is in the path. Making it so you have to have git installed to build the rpm. Known, and was a reasonable assumption in my environment. It's simple bootstrapping issue. The man pages are not built. The build dependencies do not call out the tools necessary to build the man pages. That was rather intentional, because the asciidoc package is not common. thanks, -chris - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git clone rsync:... ?
[EMAIL PROTECTED] /git git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6 defaulting to local storage area ssh: rsync: Name or service not known fatal: unexpected EOF I've read several messages that this is changing, but it still isn't clear where we should be starting. Moreover, I'd like to be able to keep one repo that is just pulling from the net and then clone it for different working directories. Why? Sometimes, in my ignorance, I break my working repo. It's handy to have one that I know is OK without pulling from the net each time. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
Junio C Hamano [EMAIL PROTECTED] writes:
- git-commit-tree says check_valid(commit) and barfs.
My current preference is to keep .git/refs/heads tag free. At
least, I do not think we should ever write non commits to
.git/*_HEAD.
What do you think? An alternative would be to allow tags
(recursively) pointing at a commit as a commit parent, but I do
not think we would want to go that route.
Or, just dereferencing tags for commit parents in commit-tree
would be fine as well.
Dereference tags given as commit-tree -p parameters.
Marc Singer noticed that when he has a tag instead of a commit
in his .git/HEAD (this happens after git checkout -f tag), git
commit barfs. This patch makes commit-tree dereference tags
like everybody else does.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
cd /opt/packrat/playpen/public/in-place/git/git.junio/
jit-diff
# - master: [PATCH] git-cvsimport-script: add import only option
# + (working tree)
diff --git a/commit-tree.c b/commit-tree.c
--- a/commit-tree.c
+++ b/commit-tree.c
@@ -8,6 +8,7 @@
#include pwd.h
#include time.h
#include ctype.h
+#include commit.h
#define BLOCKING (1ul 14)
@@ -133,10 +134,14 @@ int main(int argc, char **argv)
check_valid(tree_sha1, tree);
for (i = 2; i argc; i += 2) {
char *a, *b;
+ struct commit *commit;
a = argv[i]; b = argv[i+1];
if (!b || strcmp(a, -p) || get_sha1(b, parent_sha1[parents]))
usage(commit_tree_usage);
- check_valid(parent_sha1[parents], commit);
+ commit = lookup_commit_reference(parent_sha1[parents]);
+ if (!commit)
+ usage(commit_tree_usage);
+ memcpy(parent_sha1[parents], commit-object.sha1, 20);
if (new_parent(parents))
parents++;
}
Compilation finished at Mon Jul 11 16:12:36
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: arch 2.0 first source available (git related)
Dear diary, on Mon, Jul 11, 2005 at 11:36:56PM CEST, I got a letter where Thomas Lord [EMAIL PROTECTED] told me that... On Mon, 2005-07-11 at 21:39 +0200, Petr Baudis wrote: Dear diary, on Sat, Jul 09, 2005 at 04:20:13PM CEST, I got a letter where Thomas Lord [EMAIL PROTECTED] told me that... The prereq graph is, indeed, an improvement. ..snip.. But object retrieval can be potentially as much as linear to the depth of the prereq graph, right? Potentially but not, by far, in the common case. Moreover, that depth is an arbitrary parameter which user's can freely vary -- that's part of the point. But if the depth will be less than that, won't the user end up with some (plenty) of the objects duplicated? -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ Espy be careful, some twit might quote you out of context.. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Design for http-pull on repo with packs
Dan Holmsand [EMAIL PROTECTED] writes: I did a little experiment. I cloned Linus' current tree, and git repacked everything (that's 63M + 3.3M worth of pack files). Then I got something like 25 or so of Jeff's branches. That's 6.9M of object files, and 1.4M packed. Total size: 70M for the entire .git/objects/pack directory. Repacking all of that to a single pack file gives, somewhat surprisingly, a pack size of 62M (+ 1.3M index). In other words, the cost of getting all those branches, and all of the new stuff from Linus, turns out to be *negative* (probably due to some strange deltification coincidence). We do _not_ want to optimize for initial slurps into empty repositories. Quite the opposite. We want to optimize for allowing quick updates of reasonably up-to-date developer repos. If initial slurps are _also_ efficient then that is an added bonus; that is something the baseline big pack (60M Linus pack) would give us already. So repacking everything into a single pack nightly is _not_ what we want to do, even though that would give the maximum compression ;-). I know you understand this, but just stating the second of the above paragraphs would give casual readers a wrong impression. I think that this shows that (at least in this case), having many branches isn't particularly wasteful (1.4M in this case with one incremental pack). And that fewer packs beats many packs quite handily. You are correct. For somebody like Jeff, having the Linus baseline pack with one pack of all of his head (incremental that excludes what is already in the Linus baseline pack) would help pullers. The big problem, however, comes when Jeff (or anyone else) decides to repack. Then, if you fetch both his repo and Linus', you might end up with several really big pack files, that mostly overlap. That could easily mean storing most objects many times, if you don't do some smart selective un/repacking when fetching. Indeed. Overlapping packs is a possibility, but my gut feeling is that it would not be too bad, if things are arranged so that packs are expanded-and-then-repacked _very_ rarely if ever. Instead, at least for your public repository, if you only repack incrementally I think you would be OK. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, 11 Jul 2005, Marc Singer wrote: I picked 2.6.12 # git checkout -f v2.6.12 applied the patch and was greeted with an error about being unable to commit telling me that I LONG_HEX_NUMBER is not a valid commit object. Isn't 2.6.12 later than 2.6.12-rcX? Yes. However, that's not how git checkout ends up working, which is probably (almost certainly) a misfeature of git checkout. In particular, when you use a tag to checkout something, it will checkout the _state_ at that point (ie v2.6.12), but it won't have reset your HEAD to point to it. And your earlier adventures made your HEAD be something that isn't a commit (although I quite frankly don't know quite how you succeeded at that: git checkout should refuse to write a HEAD unless you check out a specific branch, and all branch pointers are proper commit points). Anyway, here's how you fix it right now, and I'll have to figure out how to make a nice interface: # # Reset the master branch to v2.6.12 # git-rev-list --max-count=1 v2.6.12 .git/refs/heads/master # # Switch to the master branch # git checkout -f master which should get you to be at a known point (which is v2.6.12). Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] git-gnu-progs-Makefile: git Makefile update
The only user of cp -l in the Linus GIT is git-clone-script local optimization. I could revert it to the version that I originally sent to the list, which uses cpio -pld, if your cpio groks that flag. Those options are in the man page, at least. Bryan - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] git-gnu-progs-Makefile: git Makefile update
Bryan Larsen [EMAIL PROTECTED] writes:
Last night, I couldn't think of alternatives to these, but I obviously
didn't try very hard. xargs -r can probably happen via a temporary
file and cp -u can probably be simulated using rsync.
The only user of xargs -r in the Linus GIT is git-prune-script
which tries not to run rm -f with an empty argument list, like
this:
git-fsck-cache --cache --unreachable $@ |
sed -ne '/unreachable /{
s/unreachable [^ ][^ ]* //
s|\(..\)|\1/|p
}' | {
cd $GIT_OBJECT_DIRECTORY || exit
xargs -r $dryrun rm -f
}
Not tested on a BSD, and it is probably as ugly as it can get,
but we could:
{
echo 'unreachable nosuch/file';
git-fsck-cache --cache --unreachable $@
} |
sed -ne '/unreachable /{
s/unreachable [^ ][^ ]* //
s|\(..\)|\1/|p
}' | {
cd $GIT_OBJECT_DIRECTORY || exit
xargs $dryrun rm -f
}
The only user of cp -l in the Linus GIT is git-clone-script
local optimization. I could revert it to the version that I
originally sent to the list, which uses cpio -pld, if your cpio
groks that flag.
I do not speak for Pasky, but to me cp -u sounds just like an
optimization, so maybe defining CP_U='cp -u' and detect missing
support at config time and falling back on the simple cp would
be an option?
GNU cp -a states that is the same as -dpR (never follow
symlinks, preserve link, mode, ownership, and timestamps), so
that can be rewritten as a shell function in cg-Xlib that is
called say cg_copy_tree, whose implementation runs two tar
processes piped together when cp -a is not available. Using a
tarpipe unconditionally is also fine.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Support for packs in HTTP
On Mon, 11 Jul 2005, Linus Torvalds wrote:
On Mon, 11 Jul 2005, Daniel Barkalow wrote:
On Sun, 10 Jul 2005, Linus Torvalds wrote:
You really _mustn't_ try to create the pack directly to the
$GIT_DIR/objects/pack subdirectory - that would make git itself start
possibly using that pack before the index is all done, and that would be
just wrong and nasty.
So you really should _always_ generate the pack somewhere else, and then
move it (pack file first, index file second).
It's currently fine ignoring index files without corresponding
pack files (sha1_file.c, line 470).
That doesn't help.
Well, it means that the order you move them doesn't matter, because it
will ignore the pair if either hasn't been moved.
Redgardless of which order you write them (and you _will_ write the
pack-file first), you'll find that at some point you have both files, but
one or the other isn't fully written, ie they are unusable.
(Off topic: note that git-http-pull writes the _index_ first, because it
fetches it to determine if it should fetch the pack)
And yes, you can handle that by always checking the SHA1 of the files when
you open them, but the fact is, you shouldn't need to, just to use it.
Checking the SHA1 of the pack-file in particular is very expensive (since
it's potentially a huge file, and you don't even want to read all of it).
IIRC, we check the size of the pack file and there are hashes around the
ends of the two files which have to match; but this is a die() check, not
an ignore check, so we just crash with a clear error message rather than
doing crazy stuff (like reading from beyond the end of the mmap).
So that's what I decided the rule is: never ever have a partial file, and
thus you can by definition use them immediately when you see both files.
But that requires that you write them under another name than the final
one. And since you want that _anyway_ for other uses, you don't hide that
inside git-pack-objects, but you make it an exported interface.
We should never write anything under the final name, anyway, for just this
reason; we already use open/write/close/rename for objects, refs, and
cache (maybe not working directory files, though). I think we're actually
agreeing on this.
My position is that the temporary location should be something like
{final-name}.part, such that it doesn't match *.idx or *.pack beforehand
(so it doesn't look like a complete file that you might want to send to
someone) and it doesn't have to worry about EXDEV on the rename. Also, I
would ideally like to be able to resume an interrupted download, which
means that it would have to find the partial file in a predictable
location, given what it's supposed to contain.
-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trial git RPM's..
Linus Torvalds [EMAIL PROTECTED] wrote: On Mon, 11 Jul 2005, Eric W. Biederman wrote: A couple of pieces. The dist target has assumes git-tar-tree is in the path. Making it so you have to have git installed to build the rpm. Yes. Maybe we could relax that requirement by using ./git-tar-tree or something? That still requires that you have _built_ git to do the rpm, but at least you won't have had to install it. I don't see a problem here. Sure, you need git to build git, so place it in Build-requires: Need to install the binary to build the next from source, that's all. Just like gcc ;-) [...] The man pages are not built. The build dependencies do not call out the tools necessary to build the man pages. Most people don't have asciidoc, and I'm not sure we want to require it. Maybe we could have a separate make man-rpm target for that? Would have to be a requirement for building anyway. There is a (not really nice) SRPM at http://www.pvv.ntnu.no/~terjeros/rpms/asciidoc/. Will see to clean it up. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: arch 2.0 first source available (git related)
On Tue, 2005-07-12 at 01:31 +0200, Petr Baudis wrote: But if the depth will be less than that, won't the user end up with some (plenty) of the objects duplicated? Some, yes, many, no. It's pretty easy to tune how many, afaict. -t - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cogito clone, invalid cross-dev links
Dear diary, on Mon, Jul 11, 2005 at 10:44:45PM CEST, I got a letter where Marc Singer [EMAIL PROTECTED] told me that... It complained when I cloned across devices. `/git/cogito/.git/refs/tags/cogito-0.8' - `.git/refs/tags/cogito-0.8' cp: cannot create link `.git/refs/tags/cogito-0.8': Invalid cross-device link `/git/cogito/.git/refs/tags/cogito-0.9' - `.git/refs/tags/cogito-0.9' cp: cannot create link `.git/refs/tags/cogito-0.9': Invalid cross-device link and so on. Is this a problem? Small problem, yes - fixed now. Thanks. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ Espy be careful, some twit might quote you out of context.. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] remove Obsoletes from cogito.spec.in
This is leftover from early naming, and is no longer relevant.
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
diff --git a/cogito.spec.in b/cogito.spec.in
--- a/cogito.spec.in
+++ b/cogito.spec.in
@@ -7,7 +7,6 @@ License:GPL
Group: Development/Tools
URL: http://kernel.org/pub/software/scm/cogito/
Source:
http://kernel.org/pub/software/scm/cogito/%{name}-%{version}.tar.gz
-Obsoletes: git
BuildRequires: zlib-devel, openssl-devel, curl-devel
BuildRoot: %{_tmppath}/%{name}-%{version}-root
Prereq:sh-utils, diffutils, rsync, rcs, mktemp = 1.5
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trial git RPM's..
Linus Torvalds [EMAIL PROTECTED] writes: On Mon, 11 Jul 2005, Eric W. Biederman wrote: A couple of pieces. The dist target has assumes git-tar-tree is in the path. Making it so you have to have git installed to build the rpm. Yes. Maybe we could relax that requirement by using ./git-tar-tree or something? That still requires that you have _built_ git to do the rpm, but at least you won't have had to install it. Does that fit the rpm build process? Or does an rpm build make something like that really inconvenient? I don't know, patches welcome. That would be sane. The reason I worry about having it installed is that if git-tar-tree changes without building first you will run the old version instead of the new one. The man pages are not built. The build dependencies do not call out the tools necessary to build the man pages. Most people don't have asciidoc, and I'm not sure we want to require it. Maybe we could have a separate make man-rpm target for that? Or just have a make man target and only require the rpm to use it. You certainly want to require making the man pages when building the rpm. Which means only those people who build rpms or build man pages need asciidoc. And it does not pass my torture test of building rpm's on debian, but that is not a huge problem. Ok, why is debian problematic? Mostly because debian is not rpm based. If you are real careful you can build rpm's on debian. It is almost as bad as complaining that git does not build on windows with Microsoft's compiler. I was getting a really generic error. I need to look into it deeper to see if is something that is avoidable. Is there some missing dependency or something? I really haven't ever done an rpm, and the git rpm target was all done by Chris Wright, so I don't have any clue at all. Again, patches welcome. Will do. Eric - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trial git RPM's..
Linus Torvalds [EMAIL PROTECTED] writes: On Mon, 11 Jul 2005, Eric W. Biederman wrote: Are you still up for a patch that records who and when made a tag? I sent one but it seems to have been lost. I'd really actually prefer for the code to be shared with the commit code, so that the user info (name, email, date) would not just be exactly the same, but would share the same code so that we don't end up having them ever get out of sync. Sounds fair. That would imply moving parts of git-tag-script into mktag.c. Actually I was looking at doing a git-ident thing that will just compute who git thinks you are. And then git-commit-tree can just popen it to share code. That looks like how the logic has been accomplished in other places. Moving parts of git-tag-script into mktag is hard because you have to generate a flat file to pass to gpg. And I don't think I am ready to hard code the call to gpg into mktag, as some other signing method may come along. Although that may be the saner choice. Anyway the git-ident thing is easy and informative for debugging so I will finish coding that up as soon as I get home. Eric - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Cogito 0.12.1
Hello,
here is Cogito 0.12.1, another desperate attempt to keep pace with
'@' or Linus, the named Human Master Coder. (Linus, the Human Master
Coder, mumbles arcane do { formulae } while (0)! Some kind of force
seems to attack your mind. Everything suddenly looks so different...
You are confused.) Visit the greater spellbook vault at
http://www.kernel.org/pub/software/scm/cogito
or re-attune yourself to the git plane (in case you are already
connected to the mana flow of Cogito) for updated powerful
counter-magick.
Most of it is upstream stuff. Otherwise, almost everything are
bugfixes and updates to deal better with the mighty pack stuff.
Important bugfixes is fixed parent-id (cg-admin-uncommit, subsequently)
and massive pull fixes w.r.t. pulling from packed repositories and
cross-filesystem local pull.
Oh, don't get used too much to the new cg-info script's semantics,
I want to move the functionality to cg-status; I just forgot to do it
before tagging the release and only remembered it now.
May the sun always shine on you,
--
Petr the High Elven Codethrower Baudis
Stuff: http://pasky.or.cz/
You play too little rogue-like RPG games, apparently.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, 11 Jul 2005, Junio C Hamano wrote: - we allow git-checkout-script with a tag; I think we store the tag object without dereferencing in .git/HEAD; No, git-checkout-script _shouldn't_ have done that. It will do the read-tree on the tag (which will do the right thing), but it won't change the HEAD itself. But I think Marc has/had an older git-checkout-script. The original one didn't do branches at all, and indeed just blindly wrote its result into .git/HEAD. My current preference is to keep .git/refs/heads tag free. At least, I do not think we should ever write non commits to .git/*_HEAD. And we don't. Not any more. However, right now we don't update .git/HEAD at _all_ unless we checked out a specific branch. Part of that is that we don't really know what we should change. Should we reset the current branch to that tag? Should we switch to the master branch, and switch _that_ to that tag? Should we create a totally new branch for just this thing? Creating a new branch ends up being the only _safe_ option, but what should we choose as the branch name? Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rev-list: add --full-objects flag.
On Mon, 11 Jul 2005, Eric W. Biederman wrote: Ok. Only the dumb methods are allowed. Well, no, you can actually do git-clone-pack by hand in that git archive, and it will use the smart packing to get the other end, even if it is totally unrelated to the current project. But you have to do it by hand in the sense that none of the nice helper scripts will help you to do this. Merging two unrelated projects really is a very special operation. I've done it once (gitk into git), and I don't think we'll see it done very many times again. So if you only get one branch, it will leave the objects that are specific to other branches alone. Hmm. As I recall reading the code it grabs everything that is in .git/refs/*. Only by default. If you specify a branch (or five) git-clone-pack will grab only that branch. However, I don't think git clone (the script) even exposes that, so right now you'd not even see it - git clone only exposes the get all the branches by default behaviour. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trial git RPM's..
On Mon, 11 Jul 2005, Eric W. Biederman wrote: Actually I was looking at doing a git-ident thing that will just compute who git thinks you are. And then git-commit-tree can just popen it to share code. That looks like how the logic has been accomplished in other places. I hate popen() if there's a reasonable functional interface in a library. popen() is damn inefficient for doing something like this that is all C anyway. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, 11 Jul 2005, Linus Torvalds wrote: No, git-checkout-script _shouldn't_ have done that. It will do the read-tree on the tag (which will do the right thing), but it won't change the HEAD itself. In preparation of actually updating the HEAD, I just made git checkout verify that it only checks out a commit, not a tree tag or something like that. Too late for Marc, but next time around a git checkout v2.6.11 will result in [EMAIL PROTECTED] linux]$ git checkout v2.6.11 error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit Needed a single revision That's not exactly _obvious_ either, but hey, it's at least a half-way readable and understandable error, and it's obviously correct to somebody who knows how git works. That still leaves the question about what to do when you do git checkout v2.6.12 which _is_ a valid operation. Right now it will check out that tag, in the sense that it will make the working tree correspond to v2.6.12, but it won't actually touch HEAD at all. The question is, what _should_ it do to head? Should it just reset HEAD to point to .git/refs/master, and then write the commit ID to it? That may actually sometimes be exactly what you want, and at least it will result in a consistent state (ie the next commit will have the right parent). On the other hand, it will blow away whatever the old master branch contained, and thus likely leave an unreachable commit. On the other hand, creating a new branch might be a but surprising to people: But I just wanted to check it out. But as far as I can see, it's the only safe thing to do, and it has the advantage that you can then go back to the old state with a simple git checkout master. But what about the branch name? Should we just ask the user? Together with a flag, like git checkout -b new-branch v2.6.12 for somebody who wants to specify the branch name? Or should we pick a random name and add a helper function to rename a branch later? Opinions? Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Demo support for packs via HTTP
On Mon, 11 Jul 2005, Darrin Thompson wrote: On Sun, 2005-07-10 at 15:56 -0400, Daniel Barkalow wrote: + curl_easy_setopt(curl, CURLOPT_FILE, indexfile); + curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, fwrite); + curl_easy_setopt(curl, CURLOPT_URL, url); I was hoping to send in a patch which would turn on user auth and turn off ssl peer verification. Your (preliminary obviously) patch puts curl handling in two places. Is there a place were I can safely start working on adding the needed setopts? If I understand the curl documentation, you should be able to set options on the curl object when it has just been created, if those options aren't going to change between requests. Note that I make requests from multiple places, but I use the same curl object for all of them. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, Jul 11, 2005 at 06:43:23PM -0700, Linus Torvalds wrote: On Mon, 11 Jul 2005, Linus Torvalds wrote: No, git-checkout-script _shouldn't_ have done that. It will do the read-tree on the tag (which will do the right thing), but it won't change the HEAD itself. In preparation of actually updating the HEAD, I just made git checkout verify that it only checks out a commit, not a tree tag or something like that. Too late for Marc, but next time around a git checkout v2.6.11 :-) will result in [EMAIL PROTECTED] linux]$ git checkout v2.6.11 error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit Needed a single revision On the other hand, creating a new branch might be a but surprising to people: But I just wanted to check it out. But as far as I can see, it's the only safe thing to do, and it has the advantage that you can then go back to the old state with a simple git checkout master. But what about the branch name? Should we just ask the user? Together with a flag, like git checkout -b new-branch v2.6.12 for somebody who wants to specify the branch name? Or should we pick a random name and add a helper function to rename a branch later? Opinions? From my POV, what I want is a branch with the tag v2.6.12 as the basis of the branch. I'm guessing that -b means make me a branch and call it this. # git checkout -b BRANCH_NAME [TAG] If the TAG is omitted, the branch is made from the current HEAD or some other reasonable point defined by the current working directory. Are uncommitted changes present in the working directory maintained? Discarded? I wont't care since I'll never be doing that. At least, not on purpose. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
Linus Torvalds [EMAIL PROTECTED] writes: But what about the branch name? Should we just ask the user? Together with a flag, like git checkout -b new-branch v2.6.12 for somebody who wants to specify the branch name? Or should we pick a random name and add a helper function to rename a branch later? Opinions? How about treating master a temporary thing --- whatever I happen to be working on right now? - git branch branch-name ;# copies master to branch-name; if branch-name exists in refs/heads, warn and refuse. Override with --force flag. - git checkout branch-name ;# copies branch-name to master; but if master does not match any of the other refs/heads/, warn and refuse. Override with --force flag. Yes I realize that you have to be careful when to push to your public repository if you take this route, but this is only relevant to people like Jeff with multiple heads, and I think he publicly stated that his refs/heads/master aka .git/HEAD does not mean much and what matters are his branch heads. People who do not use multiple branches but just checks out various tags, the above would be reasonably convenient. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trial git RPM's..
Linus Torvalds [EMAIL PROTECTED] writes: On Mon, 11 Jul 2005, Eric W. Biederman wrote: Actually I was looking at doing a git-ident thing that will just compute who git thinks you are. And then git-commit-tree can just popen it to share code. That looks like how the logic has been accomplished in other places. I hate popen() if there's a reasonable functional interface in a library. popen() is damn inefficient for doing something like this that is all C anyway. Ok two new files then. The new library function, and then the utility that calls it. Eric - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, 11 Jul 2005, Marc Singer wrote: From my POV, what I want is a branch with the tag v2.6.12 as the basis of the branch. I'm guessing that -b means make me a branch and call it this. Yup. That would be the interface. # git checkout -b BRANCH_NAME [TAG] If the TAG is omitted, the branch is made from the current HEAD or some other reasonable point defined by the current working directory. That would be the most natural thing that would fall out of this kind of interface. Are uncommitted changes present in the working directory maintained? Discarded? I wont't care since I'll never be doing that. At least, not on purpose. They'd be maintained. If they clash with the target being checked out (ie the checked-out tag would have changes to those files) it would error out with a I can't do that, Dave. Unless you give the -f flag, in which case they're all thrown out, and git checkout will force the new state and throw away any old state entirely. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, 11 Jul 2005, Junio C Hamano wrote: Opinions? How about treating master a temporary thing --- whatever I happen to be working on right now? I'd not mind with this in theory, but it has the fundamental problem that we can end up losing sight of commits we have, and then have no way to reach them. Which is ok per se - sometimes you simply don't care about them, and I occasionally drop some commits on purpose when I've done something I decide to undo and then do a git prune to get rid of the objects. But I don't want this to happen _easily_. Your examples aren't actually very interesting: - git branch branch-name ;# copies master to branch-name; if branch-name exists in refs/heads, warn and refuse. Override with --force flag. - git checkout branch-name ;# copies branch-name to master; but if master does not match any of the other refs/heads/, warn and refuse. Override with --force flag. because those two examples end up avoiding the _real_ issue, which is the git checkout v2.6.12 case, which is exactly the case that would need a --force flag, since master is what you're working on before. And --force would drop that information. So I want something that naturally works with this (very reasonable) way of working, and does _not_ force people to drop information. In your world, you'd have to first save the old master with git branch work-branch and then you could do git checkout v2.6.12 to start on master anew. That's fair, but it's conceptually very wrong: it rquires you to name the _old_ thing, which to me just sounds very confusing indeed. You don't care about the old thing, it's the _new_ thing you care about. So at least to me it makes much more sense to say ok, I'll start something new, and call it xyzzy, than ok, I'll start something new, and I'll save the old under 'old'. The old thing might not even be anything you worked on (it might be something you just cloned from somebody else), so you giving it a name isn't very logical. In contrast, you're clearly doing something active with the new thing, so naming _that_ makes sense. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rev-list: add --full-objects flag.
On Mon, 11 Jul 2005, Eric W. Biederman wrote: The question: Does git-upload-pack which gets it's list of objects with git-rev-list --objects needed1 needed2 needed3 ^has1 ^has2 ^has3 get any history beyond the top of tree of each branch. As I read the code it does not. It does. It gets all the history necessary for each branch. git-rev-list will walk the whole history until it hits commits that as been marked as uninteresting (or the parents of commits that have been marked as uninteresting), and those are the ones that the receiver already has, of course. So after you get a pack, you have all the history for all the branches you got. A branch you _didn't_ get, you don't get any history for, of course, but that doesn't matter. You'll get that history if you ever pull the branch later. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rev-list: add --full-objects flag.
Linus Torvalds [EMAIL PROTECTED] writes: On Mon, 11 Jul 2005, Eric W. Biederman wrote: The question: Does git-upload-pack which gets it's list of objects with git-rev-list --objects needed1 needed2 needed3 ^has1 ^has2 ^has3 get any history beyond the top of tree of each branch. As I read the code it does not. It does. It gets all the history necessary for each branch. git-rev-list will walk the whole history until it hits commits that as been marked as uninteresting (or the parents of commits that have been marked as uninteresting), and those are the ones that the receiver already has, of course. Ok. So the intention is sane then. Looking closer it appears that commit_list_insert is recursive and that is what I missed. So after you get a pack, you have all the history for all the branches you got. A branch you _didn't_ get, you don't get any history for, of course, but that doesn't matter. You'll get that history if you ever pull the branch later. Right. Things work well if you have all of the history. Eric - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
Linus Torvalds [EMAIL PROTECTED] writes: So at least to me it makes much more sense to say ok, I'll start something new, and call it xyzzy, than ok, I'll start something new, and I'll save the old under 'old'. The old thing might not even be anything you worked on (it might be something you just cloned from somebody else), so you giving it a name isn't very logical. In contrast, you're clearly doing something active with the new thing, so naming _that_ makes sense. What I had mind was ``If you do not care about the current master, just say checkout --force''. When I start working on something I often do not know what the thing I am going to work on ends up to be. So I would start from v2.6.12 tag, do random hacking, and when I got into a reasonable shape, I would say ``Ok, this is worth saving. Let's name it foobar branch and continue.'' And I would probably switch to some other subproject when an urgent bugfix comes in, and I would not want to lose my master _then_. So (the branch one has been revised): checkout [--force] commit-ish In addition to reading the tree and updating the work tree, stores commit-ish^0 in .git/refs/heads/master. However, if the current master is not something that matches a refs/*/*, then the user will be losing the trail between master before checkout and what is recorded in refs/, so the user needs to allow me explicitly to do it. branch branch-name Save the current master to branch-name. If the user makes a mistake and tries to store the master head into a wrong branch, that would lose development trail of the branch being overwritten, so if the named branch exists and master is not a descendent of it, the user needs to explicitly tell me that it is OK to do so. I do not quite follow your objections. I do not think I am forcing anybody to name an old thing. Do you mean that I've been working on A and now I want to switch to B; so I'll save the current state in A and switch to B is too redundant, and I should just let the user say I've been working on something I do not care to remember, now I want to switch to B, so just take me to B and you should remember where I was and save it to A automatically? That sort of makes sense to me. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, 11 Jul 2005, Junio C Hamano wrote: I do not quite follow your objections. I do not think I am forcing anybody to name an old thing. Sure you are. You're forcing them to make a choice, where both choices are bad. Either: - name an old thing (that you may not even have worked on - master from a newly cloned repo) - throw the old master state away (--force) Either choice is bad. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, 11 Jul 2005, Linus Torvalds wrote: Of course, if you want to create a new branch my-branch and _not_ check it out, you could have done so with just git-rev-parse v2.6.12^0 .git/refs/heads/my-branch which I think I will codify as git branch. And now we have that git branch. It's a trivial one-liner, except with the setup and error checking it's actually more like six lines. Linus --- commit 37f1a519f2ea0ce912ccd7c623aea992147c3900 Author: Linus Torvalds [EMAIL PROTECTED] Date: Mon Jul 11 21:30:23 2005 -0700 Add git branch script You can use it as git branch branchname [start-point] and it creates a new branch of name branchname. If a starting point is specified, that will be where the branch is created, otherwise it will be created at the current HEAD. The sequence git branch xyz abc git checkout xyz can also be written as git checkout -b xyz abc as per the previous commit. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] tagger id
This patch adds a command git-id for use on
the command line to see what git will set your id too,
and for use in scripts (git-tag-script) so they can get your git id.
The common code for computing the git-id is moved to ident.c
Fix parse_date to not mind being passed a constant date
to parse.
The code to compute the identifier has been restructured
to at least make a reasonable stab at error handling. The
original version had so many unchecked return values it was
just scary to think about.
Eric
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -47,7 +47,7 @@ PROG= git-update-cache git-diff-files
git-diff-stages git-rev-parse git-patch-id git-pack-objects \
git-unpack-objects git-verify-pack git-receive-pack git-send-pack \
git-prune-packed git-fetch-pack git-upload-pack git-clone-pack \
- git-show-index
+ git-show-index git-id
all: $(PROG)
@@ -57,7 +57,7 @@ install: $(PROG) $(SCRIPTS)
LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o \
tag.o date.o index.o diff-delta.o patch-delta.o entry.o path.o \
-epoch.o refs.o csum-file.o pack-check.o pkt-line.o connect.o
+epoch.o refs.o csum-file.o pack-check.o pkt-line.o connect.o ident.o
LIB_FILE=libgit.a
LIB_H=cache.h object.h blob.h tree.h commit.h tag.h delta.h epoch.h
csum-file.h \
pack.h pkt-line.h refs.h
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -208,9 +208,14 @@ extern void *read_object_with_reference(
unsigned char *sha1_ret);
const char *show_date(unsigned long time, int timezone);
-void parse_date(char *date, char *buf, int bufsize);
+void parse_date(const char *date, char *buf, int bufsize);
void datestamp(char *buf, int bufsize);
+int git_ident(char *buf, size_t bufsize,
+ const char *env_name, const char *env_email, const char *env_date);
+int git_committer_ident(char *buf, size_t bufsize);
+int git_author_ident(char *buf, size_t bufsize);
+
static inline void *xmalloc(size_t size)
{
void *ret = malloc(size);
diff --git a/commit-tree.c b/commit-tree.c
--- a/commit-tree.c
+++ b/commit-tree.c
@@ -5,9 +5,10 @@
*/
#include cache.h
-#include pwd.h
#include time.h
#include ctype.h
+#include string.h
+#include errno.h
#define BLOCKING (1ul 14)
@@ -45,39 +46,6 @@ static void add_buffer(char **bufp, unsi
memcpy(buf + size, one_line, len);
}
-static void remove_special(char *p)
-{
- char c;
- char *dst = p, *src = p;
-
- for (;;) {
- c = *src;
- src++;
- switch(c) {
- case '\n': case '': case '':
- continue;
- }
- *dst++ = c;
- if (!c)
- break;
- }
-
- /*
-* Go back, and remove crud from the end: some people
-* have commas etc in their gecos field
-*/
- dst--;
- while (--dst = p) {
- unsigned char c = *dst;
- switch (c) {
- case ',': case ';': case '.':
- *dst = 0;
- continue;
- }
- break;
- }
-}
-
static void check_valid(unsigned char *sha1, const char *expect)
{
void *buf;
@@ -114,16 +82,13 @@ static int new_parent(int idx)
int main(int argc, char **argv)
{
- int i, len;
+ int i;
int parents = 0;
unsigned char tree_sha1[20];
unsigned char commit_sha1[20];
- char *gecos, *realgecos, *commitgecos;
- char *email, *commitemail, realemail[1000];
- char date[50], realdate[50];
- char *audate, *cmdate;
+ char committer[1000];
+ char author[1000];
char comment[1000];
- struct passwd *pw;
char *buffer;
unsigned int size;
@@ -142,35 +107,12 @@ int main(int argc, char **argv)
}
if (!parents)
fprintf(stderr, Committing initial tree %s\n, argv[1]);
- pw = getpwuid(getuid());
- if (!pw)
- die(You don't exist. Go away!);
- realgecos = pw-pw_gecos;
- len = strlen(pw-pw_name);
- memcpy(realemail, pw-pw_name, len);
- realemail[len] = '@';
- gethostname(realemail+len+1, sizeof(realemail)-len-1);
- if (!strchr(realemail+len+1, '.')) {
- strcat(realemail, .);
- getdomainname(realemail+strlen(realemail),
sizeof(realemail)-strlen(realemail)-1);
+ if (git_author_ident(author, sizeof(author)) 0) {
+ die(Bad author! %s, strerror(errno));
+ }
+ if (git_committer_ident(committer, sizeof(committer)) 0) {
+ die(Bad Committer! %s, strerror(errno));
}
-
- datestamp(realdate, sizeof(realdate));
- strcpy(date, realdate);
-
- commitgecos = gitenv(GIT_COMMITTER_NAME) ? : realgecos;
- commitemail = gitenv(GIT_COMMITTER_EMAIL)
Re: Bootstrapping into git, commit gripes at me
On Mon, Jul 11, 2005 at 09:34:33PM -0700, Linus Torvalds wrote: On Mon, 11 Jul 2005, Linus Torvalds wrote: Of course, if you want to create a new branch my-branch and _not_ check it out, you could have done so with just git-rev-parse v2.6.12^0 .git/refs/heads/my-branch which I think I will codify as git branch. And now we have that git branch. It's a trivial one-liner, except with the setup and error checking it's actually more like six lines. Does it make sense to think about this branch as an flow of commits? Or is it just a starting point for a line of development? If I make a branch, check it out, commit changes to it, and then clobber the working directory, can I later resume that branch of development without creating a new branch? Do I need to set a tag to mark the last commit on that branch? - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, 11 Jul 2005, Marc Singer wrote: Does it make sense to think about this branch as an flow of commits? Or is it just a starting point for a line of development? It's really a flow of commits. Nothing will ever really remember what the starting point was at some later date if you have done commits, and the branch will always follow the _head_ of development on that branch. So if you need to remember the starting point as a _static_ entity, you need to create a tag pointing to that place. You can do that at any point, very much including after you've already done development (but before you forget what to tag ;) If I make a branch, check it out, commit changes to it, and then clobber the working directory, can I later resume that branch of development without creating a new branch? Absolutely. You can create a branch, commit to it, switch to another branch, commit to that one, switch back to the branch you created, and just go on. A branch will always follow the development. Do I need to set a tag to mark the last commit on that branch? No, but as mentioned, _if_ you care about remembering where you _started_ the branch, you may want to tag that. Of course, most of the time you really really don't care. It will be largely obvious from the global commit history, which you can trivially visualize with gitk --all. You'll see where your branch split off the main branch, and the only case where that is ambiguous is if you started your branch at the tip of another branch, and no other development has gone on in that other branch - then you don't see a fork. Of course, the other reason you usually don't care where you started is that you simply don't care. When you use CVS, you usually need to know where the branch was started (and each point it was merged at) just so that you can sanely merge it by doing diffs etc. With git, since we have all the proper history, that's not necessary at all. So I _suspect_ that most of the time when you create a branch, you don't need to tag where you started. Others will see what is your development simply by virtue of it being in your tree and not in other peoples tree, whether you created a branch for that or not ;) Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
How to get a directory filled with v2.6.11?
I switched to using the git version in source control. Checkout/branching works great. :-) But, this version of git doesn't let me do # git checkout -f v2.6.11 error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit Needed a single revision which I suspect is protection added to prevent my special sort of shenanigans. If I cannot perform the checkout anymore, is there another way to fill a directory with the contents of that particular tree? What am I doing? I've got some updates against 2.6.11 orphaned in another develpment directory. I could just upack a tar.bz2 file for 2.6.11, but git is more clever. I want to perform a diff against the tagged v2.6.11 and my development tree. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
