Re: [PATCH 7/2] Support for NO_OPENSSL
This doesn't work at least in the form that Junio merged it (and from what I can tell, he merged your patch as-is): [EMAIL PROTECTED]:~/src/git make NO_OPENSSL=1 cc -g -O2 -Wall '-DNO_OPENSSL' '-DSHA1_HEADER=mozilla-sha1/sha1.h' -o git-rev-list rev-list.o libgit.a -lz -lssl /usr/lib/gcc-lib/i586-suse-linux/3.3.4/../../../../i586-suse-linux/bin/ld: cannot find -lssl it needs to disable the -lssl too.. 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] Under NO_OPENSSL -lssl should not be used
On Fri, 29 Jul 2005, Junio C Hamano wrote: Would this be OK? I think it is ugly but it gets the job done. Looks ok. I'd suggest having some option to turn of curl too - I have one machine that doesn't have curl installed, and I just turn the things that depend on it off by hand by editing the makefile right now.. 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: Fix interesting git-rev-list corner case
On Sat, 30 Jul 2005, Peter Osterlund wrote: I have problems pulling linux kernel changes from 33ac02aa4cef417871e128ab4a6565e751e5f3b2 to b0825488a642cadcf39709961dde61440cb0731c into my local tree. At first I thought your patch would fix it, but it doesn't: No, this is a merge conflict failure, and you simply have conflicts in the tree. git did everything right, it just couldn't do an automatic merge. ERROR: Merge conflict in arch/um/os-Linux/elf_aux.c. ERROR: Merge conflict in arch/x86_64/kernel/smpboot.c. ERROR: Merge conflict in drivers/i2c/busses/i2c-mpc.c. ERROR: Merge conflict in include/asm-i386/bitops.h. ERROR: Merge conflict in kernel/sys.c. We don't have any nice graphical tools to show these to you like BitKeeper had, although it shouldn't be fundamentally hard. What you need to do is basically edit all those five files, and look for the conflicts (they are just like normal CVS conflicts: orig-branch conflict-contents === pulled-branch conflict-contents and then you edit them to your liking until you have no more conflicts, and then you have to commit your manual resolve with git commit --all which will commit the merge _and_ your manual conflict resolution. This is something where a nice wrapper layer could do a lot better. I know there are graphical three-way merge programs available. But core git is no worse (and in fact a _lot_ better) than CVS in this regard, so I feel that the git merge, while obviously not perfect or even very smart, is sufficient for what git is (ie it's up to porcelain to do anything better). 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: Making it easier to find which change introduced a bug
On Sat, 30 Jul 2005, Alexander Nyberg wrote: Linus, do you think we could have something like patch-2.6.13-rc4-incremental-broken-out.tar.bz2 that could like Andrew's be placed into patches/ in a tree? Not really. The thing is, since the git patches really _aren't_ serial, and merging isn't based on patch-merging at all (unlike quilt, that literally merges patches as patches), you can't really linearize a git tree without getting some really strange behaviour. As it stands today it's easier for us who don't know git to just find out in which mainline kernel it works and which -mm it doesn't work in, get the broken-out and start push/pop. And I know I'm not the only one who has noticed this. What we can do is try to script the git bisection thing so that it's really trivial. It's actually very simple to use, and I think somebody had some example scripts around. Here's a simple starting point for somebody who wants to try.. It's not very well tested, but I've done _some_ testing on it to try to make sure it's at least reasonable. It adds four new git commands: - git bisect-start reset bisect state - git bisect-bad mark some version known-bad (if no arguments, then current HEAD) - git bisect-good mark some version known-good (if no arguments, then current HEAD) - git bisect do a bisection between the known bad and the known good heads, and check that version out. Then, the way you use it is: git bisect-start git bisect-bad # Current version is bad git bisect-good v2.6.13-rc2 # v2.6.13-rc2 was the last version tested that was good git bisect which will say something like Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect-good # this one is good git bisect which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say git-bisect-good or git-bisect-bad, and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in refs/bisect/bad. Oh, and then after you want to reset to the original head, do a git checkout master to get back to the master branch, instead of being in one of the bisection branches (git bisect-start will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of quilt push and quilt pop, now is it? Linus --- diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -62,7 +62,9 @@ SCRIPTS=git git-apply-patch-script git-m git-format-patch-script git-sh-setup-script git-push-script \ git-branch-script git-parse-remote git-verify-tag-script \ git-ls-remote-script git-clone-dumb-http git-rename-script \ - git-request-pull-script + git-request-pull-script git-bisect-bad-script git-bisect-good-script \ + git-bisect-script git-bisect-start-script + PROG= git-update-cache git-diff-files git-init-db git-write-tree \ git-read-tree git-commit-tree git-cat-file git-fsck-cache \ diff --git a/git-bisect-bad-script b/git-bisect-bad-script new file mode 100755 --- /dev/null +++ b/git-bisect-bad-script @@ -0,0 +1,4 @@ +#!/bin/sh +. git-sh-setup-script || dir Not a git archive +rev=$(git-rev-parse --revs-only --verify --default HEAD $@) || exit +echo $rev $GIT_DIR/refs/bisect/bad diff --git a/git-bisect-good-script b/git-bisect-good-script new file mode 100755 --- /dev/null +++ b/git-bisect-good-script @@ -0,0 +1,4 @@ +#!/bin/sh +. git-sh-setup-script || dir Not a git archive +rev=$(git-rev-parse --revs-only --verify --default HEAD $@) || exit +echo $rev $GIT_DIR/refs/bisect/good-$rev diff --git a/git-bisect-script b/git-bisect-script new file mode 100755 --- /dev/null +++ b/git-bisect-script @@ -0,0 +1,15 @@ +#!/bin/sh +. git-sh-setup-script || dir Not a git archive +bad=$(git-rev-parse --revs-only --verify refs/bisect/bad) || exit +good=($(git-rev-parse --revs-only --not $(cd $GIT_DIR ; ls refs/bisect/good-*))) || exit +rev=$(git-rev-list --bisect $bad [EMAIL PROTECTED]) || exit +nr=$(git-rev-list $rev [EMAIL PROTECTED] | wc -l) || exit +if [ $nr = 0 ]; then + echo $bad is first bad commit + git-diff-tree --pretty $bad + exit 0 +fi +echo Bisecting: $nr revisions left to test after this +echo $rev $GIT_DIR/refs/heads/new-bisect +git checkout new-bisect || exit +cd $GIT_DIR mv refs/heads/new-bisect refs/heads/bisect ln -sf refs/heads/bisect HEAD diff --git a/git-bisect-start-script b/git-bisect-start-script new file mode 100755 --- /dev/null +++
Re: Fix interesting git-rev-list corner case
On Sat, 30 Jul 2005, Peter Osterlund wrote: Can you send me your HEAD and MERGE_HEAD (don't do the merge). HEAD : 33ac02aa4cef417871e128ab4a6565e751e5f3b2 MERGE_HEAD: b0825488a642cadcf39709961dde61440cb0731c Bingo. Yup, it's git-merge-base, and it is confused by the same thing that confused git-rev-list. Thanks, I'll fix it. 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] add NO_CURL option to the Makefile
On Sat, 30 Jul 2005, Junio C Hamano wrote: I love it I can just slow down and let others submit obviously correct patches, which I can just slurp in. You're obviously doing well as a maintainer. Only stupid people try to do everything themselves. Personally, I spend a _lot_ of time communicating, because even if it's a lot more work to explain (in detail) what I want done, and it doesn't work out all the time, and I sometimes have to do it myself _anyway_, if it works even just occasionally, it not only gets people involved, it makes them do it themselves next time around without prodding, and then you just sit back, sip a foofy tropical drink, and take the credit. 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: send-pack question.
On Sat, 30 Jul 2005, Junio C Hamano wrote: * Right now, send-pack --all into an empty repository does not do anything, but send-pack --all master into an empty repository pushes all local heads. This is because we do not check send_all when deciding if we want to call try_match on local references. I am assuming this is an oversight; am I correct? If so, does the attached patch look OK? Yeah, that sounds like me just not having taken my 'meds. The patch looks fine. * It appears to me that you can say send-pack net, and depending on how the remote lists its refs, you can end up updating their refs/heads/net or refs/tags/net. Yeh. I was wanting to sort the refs to make everything be totally repeatable, but that was more of an urge than a real plan. More confusingly, you could say send-pack net net to update both. More realistically, you could get confused with a remote that has refs/heads/jgarzik/net and refs/heads/dsmiller/net in this way. I think it should detect, stop and warn about the ambiguity and require the user to be more explicit. Am I reading the current code correctly? Yes, warning on ambiguity sounds like a sound plan, and then you don't need to sort. You also probably to come up with a syntax for saying xyz is the local name, abc is the remote name. That's needed for both the pulling and the pushing side, but I didn't ever do it. I've always _hated_ the interface to path_match() which pretends to be just a boolean function but actually has a grave side effect, by the way. It's interesting but useful. But I agree, we've had one bug already due to the interesting part. If you do the ambiguity thing, you might mark them used some separate way, and maybe avoid that side effect (or rather - the side effect would still exist, but instead of removing the entry, it would just mark it as seen, ie make it less drastic). 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] Added hook in git-receive-pack
On Sun, 31 Jul 2005, Josef Weidendorfer wrote: Added hook in git-receive-pack After successful update of a ref, $GIT_DIR/hooks/update refname old-sha1 new-sha2 is called if present. This allows e.g sending of a mail with pushed commits on the remote repository. Documentation update with example hook included. This looks sane. However, I also get the strong feeling that git-update-server-info should be run as part of a hook and not be built into receive-pack.. Personally, I simply don't want to update any dumb server info stuff for my own local repositories - it's not like I'm actually serving those out 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: [PATCH] Added hook in git-receive-pack
On Sun, 31 Jul 2005, Junio C Hamano wrote: But you are. I can run this just fine: No I'm not. Try all the machines behind my firewall. kernel.org is just the place I put things to when I publish them. It doesn't have any of my working directories on it. 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] Added hook in git-receive-pack
On Sun, 31 Jul 2005, Junio C Hamano wrote: Linus Torvalds [EMAIL PROTECTED] writes: No I'm not. Try all the machines behind my firewall. Ah, that's true. Do you push into them? Yup, I do. I have this thing that I don't do backups, but I end up having redundancy instead, so I keep archives on my own machines and inside the private osdl network, for example. Also, I suspect that anybody who uses the CVS model with git - ie a central repository - is not likely to export that central repository any way: it's the crown jewels, after all. Open source may not have that mindset, but I'm thinking of how I was forced to use CVS at Transmeta, for example: the machine that had the CVS repo was certainly supposed to be very private indeed. In the central repo model you have another issue - you have potentially parallell pushes to different branches with no locking what-so-ever (and that's definitely _supposed_ to work), and I have this suspicion that the update for dumb servers code isn't really safe in that setting anyway. I haven't checked. 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: git diffs
On Mon, 1 Aug 2005, Matthias Urlichs wrote: Hi, Linus Torvalds wrote: git checkout -f master git-rev-parse master .git/refs/heads/merge-branch # # Switch to it, always leaving master untouched # git checkout -f merge-branch Isn't that equivalent to (but slower than) git checkout -f -b merge-branch master No. If you had a previous merge-branch (because something went wrong last time, and you just re-start the whole thing), you really want to _first_ force the branch to master, and then create the new merge-branch. Also, the last git checkout -f merge-branch will be pretty much zero time, because the stuff is already at the right point, so it will basically end up just re-doing the symlink. So I did it that strange way for a reason. 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
Fix sparse warnings
A few sparse warnings have crept in again since I checked last time:
undeclared variables with global scope.
Fix them by marking the private variables properly static.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
Btw, sparse also warns about the return 0 in receive-pack.c: unpack(),
since that function is supposed to return void. I think somebody else
already sent a patch for that one.
diff --git a/daemon.c b/daemon.c
--- a/daemon.c
+++ b/daemon.c
@@ -71,13 +71,13 @@ static int max_connections = 25;
/* These are updated by the signal handler */
static volatile unsigned int children_reaped = 0;
-pid_t dead_child[MAX_CHILDREN];
+static pid_t dead_child[MAX_CHILDREN];
/* These are updated by the main loop */
static unsigned int children_spawned = 0;
static unsigned int children_deleted = 0;
-struct child {
+static struct child {
pid_t pid;
socklen_t addrlen;
struct sockaddr_storage address;
diff --git a/rev-cache.c b/rev-cache.c
--- a/rev-cache.c
+++ b/rev-cache.c
@@ -5,7 +5,7 @@
struct rev_cache **rev_cache;
int nr_revs, alloc_revs;
-struct rev_list_elem *rle_free;
+static struct rev_list_elem *rle_free;
#define BATCH_SIZE 512
diff --git a/server-info.c b/server-info.c
--- a/server-info.c
+++ b/server-info.c
@@ -62,7 +62,7 @@ static int update_info_refs(int force)
}
/* packs */
-struct pack_info {
+static struct pack_info {
unsigned long latest;
struct packed_git *p;
int old_num;
-
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] list shortlog items in commit order
On Tue, 2 Aug 2005, Jeff Garzik wrote: shrug I don't really care either way. I suspect it's mostly the users, not the developers, who care. The core developers already know what went in, and have git to see it, they don't look at the shortlog output. So I suspect it's more important to see if there's user feedback one way or the other.. 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: Users of git-check-files?
On Wed, 3 Aug 2005, Junio C Hamano wrote: Linus Torvalds [EMAIL PROTECTED] writes: Yeah, probably not. git-rev-list does so much more than git-rev-tree ever did. Does rev-list do --edges ;-)? No, but does anybody use it? It _may_ be interesting as a git-merge-base thing, but then we should probably add it to git-merge-base (which actually _does_ do edges these days, but it just only shows the most recent one..) BTW, I have two known bugs/problems that I haven't resolved, which is bothering me quite a bit. Yes, it is my fault (lack of time and concentration). One is the EINTR from the daemon.c, I actually think the new code is totally broken. If you want to listen to several sockets, you should just run several daemons. Yeah, yeah, it won't give you global child control etc, but I doubt we care. But I don't think it's a huge issue, since most serious users are likely to use the --inetd flag and use inetd as the real daemon anyway (ie the built-in daemon code is most useful for normal users just setting up their own quick thing). and another is receive-pack failing with unpack should have generated but I cannot find it when pushing. The latter is something I am aware of, I know it needs to be diagnosed, but I have not looked into yet. I've lost that state. Can you explain a bit mroe.. 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: Users of git-check-files?
On Wed, 3 Aug 2005, Junio C Hamano wrote: Linus Torvalds [EMAIL PROTECTED] writes: Are you sure you have a good git version on master? I've never seen anything like that, and I push all the time.. I have been esuspecting that it happens only because I rewind and rebase pu, which you never do. The thing is, even though I rewind pu all the time, it happens only occasionally. Oh, that would do it. You need to prune back the remote tree you send to, so that it is a real subset of what you are sending from (at least as far as the branch you send is concerned - other branches may be ahead of you, of course). Unlike git-fetch-pack, the send-pack interface does not do any common commit discovery, so if you have state on the other end that isn't on your local end, that's setting yourself up for problems: you are basically misusing the interfaces. I started out to make the -f flag to send-file work around it, but I never finished that, partly because it really ends up being the same thing as git-fetch-pack in reverse, which was against the whole point of git-send-pack. Send-pack is meant to be an update remote tree thing, with the assumption that the remote tree is a subset - and exactly that assumption is what makes send-pack much cheaper than fetch-pack. (Actually, to me it's not the cheaper that matters, but exactly the fact that send-pack is so safe - if somebody has changed something at the other end that I don't have in mine, I _want_ errors, because that would be a serious problem). 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: Users of git-check-files?
On Wed, 3 Aug 2005, Johannes Schindelin wrote: On Wed, 3 Aug 2005, Linus Torvalds wrote: Are you sure you have a good git version on master? I've never seen anything like that, and I push all the time.. Call him Zaphod: he has two heads (master and pu). You don't. Oh, but I most definitely do. I update several heads at a time when I create a new tag etc. What I don't do is to rewrite my history, though.. 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: Users of git-check-files?
On Wed, 3 Aug 2005, Josef Weidendorfer wrote: Yes it is. To reproduce: Create a repository with 2 branches. Make 2 clones of the 2 branches via SSH. Make a commit on one clone and push. Make another commit on the other clone and push = ERROR This works perfectly fine, you just have to make sure that you update the right head. If you try to update a head that is ahead of you, that is driver error. Admittedly one that could have nicer error messages ;) This is why git-send-pack takes the name of the branch to update.. The real problem with git-send-pack is that the local and remote names have to be the same, which is a bug, really. It _should_ be perfectly fine to do something like git-send-pack ..dest.. localname:remotename which would push the local localname branch to the remote remotename branch. 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: Users of git-check-files?
On Wed, 3 Aug 2005, Josef Weidendorfer wrote: But my example shows that the error happens even with 2 branches totally unrelated to each other: if branch1 got a new commit, you can not push to branch2 from another clone. Sure you can. git-send-pack remote branch2 and you've just done so. The shorthand of no branches listed expands to _all_ branches, and if you try to send all branches, then you're trying to update branch1 with something you don't have. That's your usage error. 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: Very limited pathspec wildcards..
On Wed, 3 Aug 2005, Junio C Hamano wrote: Wouldn't something like this work equally well? Nope, for several reasons: - it's _horribly_ inefficient (ie it traverses directories that it doesn't need to) - it shows all the changeset comments, regardless of whether they are releant or not. It just removes the diffs. Try it out. Junio, name-based filters _have_ to be done early. This is why diffcore-pathspec isn't used any more - it's _much_ too inefficient to do it 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] (preview) Renaming push.
On Wed, 3 Aug 2005, Junio C Hamano wrote: While I have not updated the send-pack src:dst syntax, I added a horrible hack that some people may love to see. This removes the need to use git-rev-parse from many commands. Yes, I think this makes sense. We had three different sha1 parsers: get_sha1(), get_sha1_hex(), and get_extended_sha1(). None of the users of get_sha1() really have any reason to want the limited form, so I think your patch does the right thing. Now, for extra bonus points, maybe you should make git-rev-list also understand the rev..rev format (which you can't do with just the get_sha1() interface, since it expands into more). Of course, most people don't tend to use git-rev-list directly, so maybe that's not a biggie, and so git-rev-parse is fine. 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
Tree tags again..
Junio, maybe there should be some test-case for this: error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit error: remote ref 'refs/tags/v2.6.11' is not a strict subset of local ref 'refs/tags/v2.6.11'. error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit error: remote ref 'refs/tags/v2.6.11-tree' is not a strict subset of local ref 'refs/tags/v2.6.11-tree'. Hmm? 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: Display of merges in gitk
On Fri, 29 Jul 2005, Paul Mackerras wrote: I have reworked the way gitk displays merges. Ok, goodie. It works fine in my environment, with most merges showing up as not interesting. But a merge like 3e0777b8fa96f7073ed5d13d3bc1d573b766bef9 shows an example of where there was actually both real content merges, and some real clashes. However, most of the content merges were trivial, and they often hide the real clashes. For example, if you click on that merge, a _lot_ of it looks like it might be clashes, even though most of it was auto-merged. This is not really a problem, but I get the feeling that it could be improved somehow - maybe a button that hides the parts that don't have clashes? In the usual case of two parents, lines from the first parent are in red and lines from the second parent are in blue. Lines in the result that don't correspond to either parent are in bold black. To get the alternate output, maybe something like: - run merge on the original/parent1/parent2 (the same way the git-merge-one-file-script does) - anything that merged fine is in black (regardless of which parent it came from), and then mark the merge rejects are in red/blue depending on parent? I don't know how doable that would be. 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
gitk hyperlinks (was Re: Display of merges in gitk)
[ Also Kay Sievers, because the clickability thing sounds like a potentially good thing for webgit too.. ] For 2.6.13 we've been reverting some stuff lately, to make sure we get a stable release. That's fine, and when I revert something I try to mention the commit ID of the thing I revert in the message. Apparently others do too, as indicated by a patch I just got from Petr Vandovec. So we've got for example: 889371f61fd5bb914d0331268f12432590cf7e85: Author: Linus Torvalds [EMAIL PROTECTED] 2005-07-30 13:41:56 Committer: Linus Torvalds [EMAIL PROTECTED] 2005-07-30 13:41:56 Revert yenta free_irq on suspend ACPI is wrong. Devices should not release their IRQ's on suspend and re-aquire them on resume. ACPI should just re-init the IRQ controller instead of breaking most drivers very subtly. Breakage reported by Hugh Dickins [EMAIL PROTECTED] Undo: d8c4b4195c7d664baf296818bf756775149232d3 Signed-off-by: Linus Torvalds [EMAIL PROTECTED] and 403fe5ae57c831968c3dbbaba291ae825a1c5aaa: Author: Petr Vandrovec [EMAIL PROTECTED] 2005-08-05 06:50:07 Committer: Linus Torvalds [EMAIL PROTECTED] 2005-08-05 06:57:44 [PATCH] rtc: msleep() cannot be used from interrupt Since the beginning of July my Opteron box was randomly crashing and being rebooted by hardware watchdog. Today it finally did it in front of me, and this patch will hopefully fix it. The problem is that at the end of June (the 28th, to be exact: commit 47f176fdaf8924bc83fddcf9658f2fd3ef60d573, [PATCH] Using msleep() instead of HZ) rtc_get_rtc_time ... and when I use gitk, it would be just too damn cool for words if I could easily follow the SHA1's mentioned in the commit message. I can just cut-and-paste the SHA1, and I've verified that it works fine. However, as you'v enoticed, I'm of the whiny kind, and I thought it could be easier. So I'm whining again. whineMommy, mommy, can you make my life easier/whine So I noticed that I really would like two things: - clickable SHA1's in commit messages would be really really cool if something like that is even possible with tcl/tk. Now, if you can highlight them when showing the message, that would be extra cool, but even without any highlighing, the thing actually _almost_ works fine already: you can double-click the SHA1, and it will select it. You then have to move the mouse to the goto window, and paste in the SHA1 there. And this is where it would be good if this sequence could be simplified a bit. Even if it's something as simple as accepting the SHA1 paste into the same window (not having to go to the goto window: just double-click on the SHA1, and then right-click to paste it back). - I'd like to have a back button. Not just for the above kind of thing, but in general too: when searching for something, it would just be very nice if gitk just kept a list of the n last commits that have been selected, and there was a web-browser-like button that went back/forward in history. But especially when looking at a revert, I just want to first go to the thing we revert, see what's going on there (get the historical perspective - commit log for why the original was done etc), and then I'd want to go back (and possibly forth and back again ;). And while the revert mentioned the thing it reverted (so I could cut-and-paste), the thing it reverted obviously does _not_ mention the thing that reverted it, so now I have to manually just scroll back. This same thing happens for a failed search (I search for xyz, and it actually finds it, and I realize that that was the wrong search, but now I'm two months back..) whineMommy, mommy, plase/whine 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: Terminology
On Fri, 5 Aug 2005, Johannes Schindelin wrote: Tutorial says cache aka index. Though technically, a cache is the index file _plus_ the related objects in the object database. git-update-cache.txt even makes the difference between the index and the directory cache. I think we should globally rename it to index. The directory cache and later cache naming came from when I started doing the work - before git was even git at all, and had no backing store what-so-ever, I started out writing cache.h and read-cache.c, and it was really first a trial at doing a totally SCM-neutral directory cache front-end. You don't even see that in the git revision history, because that was before git was self-hosting - the project was partly started to also work as possibly just a fast front-end to something that wasn't as fast (ie think something like a front-end to make monotone work better). So the directory cache and cache naming comes from that historical background: it was really started as a front-end cache, and in fact the .git directory was called .dircache initially. You can see some of that in the very earliest git releases: by then I had already done the backing store, and the thing was already called git, but the dircache naming still remains in places. For example, here's my backup target in the initial checkin: backup: clean cd .. ; tar czvf dircache.tar.gz dir-cache which shows that not only did I call the resulting tar file dircache, the directory I was developing stuff in was called dir-cache as well ;) The index obviously ended up doing a lot more, and especially with the different stages it became much more than just a directory cache thing: it's integral to how git does the fast part of a merge. So we should call it index and edit out the old cache and director cache naming entirely. - the directory which corresponds to the top of the hierarchy described in the index file; I've seen words like working tree, working directory, work tree used. The tutorial initially says working tree, but then working directory. Usually, a directory does not include its subdirectories, though. git-apply-patch-script.txt, git-apply.txt, git-hash-object.txt, git-read-tree.txt use work tree. git-checkout-cache.txt, git-commit-tree.txt, git-diff-cache.txt, git-ls-tree.txt, git-update-cache.txt contain working directory. git-diff-files.txt talks about a working tree. I think we should use working tree throughout, since working directory is unix-speak for pwd and has a totally different meaning. - When the stat information a cache entry records matches what is in the work tree, the entry is called clean or up-to-date. The opposite is dirty or not up-to-date. - An index file can be in merged or unmerged state. The former is when it does not have anything but stage 0 entries, the latter otherwise. I think the unmerged case should be mentioned in the cache entry thing, since it's really a per-entry state, exactly like dirty/clean. Then, explaining a unmerged index as being an index file with some entries being unmerged makes more sense. As it is, the above explains an index file as being unmerged by talking about stage 0 entries, which in turn haven't been explained at all. - A tree object can be recorded as a part of a commit object. The tree object is said to be associated with the commit object. In diffcore.txt, changeset is used in place of commit. We really should use commit throughout. ex-BK users sometimes lip into changeset (which in turn is probably because BK had these per-file commits too - deltas), but there's no point in the distinction in git. A commit is a commit. - The following objects are collectively called tree-ish: a tree object, a commit object, a tag object that resolves to either a commit or a tree object, and can be given to commands that expect to work on a tree object. We could call this category an ent. LOL. You are a total geek. - The files under $GIT_DIR/refs record object names, and are called refs. What is under refs/heads/ are called heads, refs/tags/ tags. Typically, they are either object names of commit objects or tag objects that resolve to commit objects, but a tag can point at any object. The tutorial never calls them refs, but instead references. It might be worth saying explicitly that a reference is nothing but the same thing as a object name aka sha1. And make it very clear that it can point to any object type, although commits tend to be the most common thng you want to reference. That then leads naturally into a very specific _subcase_ of refs, namely a head: - A head is always an object name of a commit, and marks the latest commit in one line of development. A line of development is often called a branch. We sometimes use the word branch head to stress the fact that we are talking
Re: My Itchlist
On Fri, 5 Aug 2005, Junio C Hamano wrote: - Teach fetch-pack reference renaming. Well, the fetch side at least needs it less. Right now the renaming means that you can only really fetch _one_ head at a time, but that's at least a fairly common and important case, and you can do the rest from there. And doing only one means that git-fetch-pack can just return the result SHA1 of the head it was asked to fetch. In fact, even that could just be extended to returning multiple heads: just return each SHA1 in order. No renaming necessary, since it's then up to the user what to do with the results. In fact, many users don't even want to write the result to a ref _at_all_: they just use the raw name - no refs - to merge. So arguably it is _wrong_ to make git-fetch-pack write refs, because that just leads to the problem with temporary refs etc. Local variables are good. These are not 1.0 showstopper items but what I personally would love to see. - teach mailsplit/mailinfo basic MIME (attachments and quoted-printable) Some people send patches in MIME quoted-printable. I could drop them on the floor and ask the sender to resend, but I've been being a nice guy, which currently involves manual intervention. This really is a nasty problem. People add their own commentary etc, and the fact is, the maintainer _needs_ to edit it. Otherwise you'll have people saying Hi there, I really like this thing, but I have this problem which this patch fixes etc, which is all very nice, but dammit, that's simply not changelog material. Also, I definitely myself end up editing patches occasionally: fixing things up. Again, this is simply a major pain if the patch comes in as an attachment. So there are tons of reasons to just try to teach people that attachments are painful. Much better to teach people not to use them than having people use them and the tools working with them. - teach git-apply reverse and possibly fuzz. I think this might help Porcelain; currently they have to interpret git extended diff headers themselves. Reverse would definitely be useful. fuzz is really pretty dangerous. I think that once a a patch doesn't apply, you really want to have helper tools like a graphical wiggle etc, and that really means that it's not git-apply, it's something totally different. And quite frankly, if you have a tool that can handle unified diffs already, then extending it for the git rename stuff should be pretty easy. It's not like we haven't wanted renaming patches for at least a _decade_ already, it's just that nobody ever did them. So I'm hoping that git can act as a impetus for people to just finally have a standard way of saying rename. EVERYBODY wants it. Anybody who ever sees a rename as a patch will always go damn, it would be nice to have renames. And dammit, we have them, so let's try to push out the concept. And if that means that we should use rename patches and let non-git users have some pain until they say ok, ok, it's a good idea, I'll do it. Uncle, uncle!, then maybe the world will be a better place. It's not like they can't see how git-apply does it already ;) 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: gitk hyperlinks (was Re: Display of merges in gitk)
On Sat, 6 Aug 2005, Paul Mackerras wrote: Linus Torvalds writes: - clickable SHA1's in commit messages would be really really cool if something like that is even possible with tcl/tk. Done, and it was even pretty easy. It took only about a dozen lines. Looks good also. I assume the mouse can't change when it hovers? Good idea. Also done. :) It's on master.kernel.org now in my gitk.git directory. Hopefully Junio will pull it into git soon. The current version also squishes the graph horizontally if it gets too wide (i.e. more than half the width of the top-left pane). Yeah, that looks weird when the lines start turning soft ans squiggly. 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
Make git-sh-setup-script do what it was supposed to do
Duh. A missing meant that half the tests that git-sh-setup-script were
_meant_ to do were actually totally ignored.
In particular, the git sanity checking ended up only testing that the
GIT_OBJECT_DIRECTORY was sane, not that GIT_DIR itself was..
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
diff --git a/git-sh-setup-script b/git-sh-setup-script
--- a/git-sh-setup-script
+++ b/git-sh-setup-script
@@ -12,6 +12,6 @@ die() {
}
[ -d $GIT_DIR ]
-[ -d $GIT_DIR/refs ]
+[ -d $GIT_DIR/refs ]
[ -d $GIT_OBJECT_DIRECTORY ]
[ -d $GIT_OBJECT_DIRECTORY/00 ]
-
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
gitk SHA link hovers
This makes the cursor change when you hover over a SHA1 link with the new
hypertext gitk commit ID linking feature.
All credit goes to Jeff Epler [EMAIL PROTECTED] and bugs are mine.
I don't actually know any tcl/tk, I'm just acting as a random monkey that
looks at what others do and mix it up.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -1802,10 +1802,13 @@ proc selectline {l isnew} {
set linkid [string range $comment $s $e]
if {![info exists idline($linkid)]} continue
incr e
- $ctext tag conf link$i -foreground blue -underline 1
+ $ctext tag add link $commentstart + $s c $commentstart + $e c
$ctext tag add link$i $commentstart + $s c $commentstart + $e c
$ctext tag bind link$i 1 [list selectline $idline($linkid) 1]
}
+$ctext tag conf link -foreground blue -underline 1
+$ctext tag bind link Enter { %W configure -cursor hand2 }
+$ctext tag bind link Leave { %W configure -cursor {} }
$ctext tag delete Comments
$ctext tag remove found 1.0 end
-
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 - how to drop a commit
On Sun, 7 Aug 2005, Sam Ravnborg wrote: I accidently commited too many files to my tree today, and now I want to drop the commit so I have logically separate commits. What is the right way to do this - in cogito hopefully. Not cogito, and this needs to be scripted, but if what you _want_ to do is undo the commit (in order to re-do it as several commits), here are the raw git commands necessary (you could make this git-fix-script, and then git fix basically does the git equivalent of what bk fix -C did) # Set up # . git-sh-setup-script || die Not a git archive # Figure out the parent. # parent=$(git-rev-parse --verify HEAD^) || exit # # Update the index to be at that point in time and make HEAD # point to it, but don't update the working tree contents (ie # the changes remain in the working tree, to be re-committed). # git-read-tree -f -m $parent echo $parent .git/HEAD NOTE! The commit still _exists_, but the HEAD reference to it is now lost. If you want to save that as a broken branch, you can precede this with git branch broken-branch which means that the broken point got saved off as broken-branch. And if you didn't do that (or if you _did_ do that, and later end up deciding to throw that branch away with a rm .git/refs/heads/broken-branch or similar) then you can get rid of the stale and unreachable objects with a simple git prune. Be careful! git prune _will_ throw away all the objects that it can't find references to. You might want to run git-fsck-cache --full --unreachable first to get an idea of what it's going to throw away. 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: qgit-0.81
On Sat, 6 Aug 2005, Marco Costalba wrote: Some little new stuff too, complete changelog below: - added move back/forward in selection history - added hyperlinks SHA1's in commit messages Ok, this is nicer than gitk, with the parents showing up in the commit message and thus easy to go to. You might add children too: it's not something git itself knows about intrisically, but since you've already built the graph, at least you see what children are part of that graph.. Oh, and do people really care _that_ much when the change happened? That's a lot of screen real estate wasted on the date stamp of last change. At least I can drag it to the right and hide it that way.. A couple of quick comments: - Any chance of having a git archive of qgit? I realize that sourceforge doesn't have git archives, but (a) maybe you can ask and (b) maybe there are alternate places you could put it. It's just sad having to download tar-balls. - The qgit graph is not as pretty as the gitk one. Any chance of making the bullets a bit smaller, and having an option to not do the jump-over-bumps? - the file annotation window is nice, but it _really_ shouldn't do line wrapping. If you make the window narrower, you'll see it wrap and look horrible.. Are all text windows always wrapped in QT? - You edit the commit comments heavily, and have no options to unedit. For example, I need the emails in the sign-offs if I ever cut-and-paste to an email client when I sent a hey, this commit broke so-and-so.. - the format a patch to be sent as email thing says at least two revisions needed when you only have one. Why? One of my more common cases is that I send one commit as a patch, and now I do git-diff-tree -p --pretty [commit-id] ~/diff and then just send that. A single commit _does_ describe a valid patch, after all. No biggie, 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
Extend git reset to take a reset point
This was triggered by a query by Sam Ravnborg, and extends git reset to reset the index and the .git/HEAD pointer to an arbitrarily named point. For example git reset HEAD^ will just reset the current HEAD to its own parent - leaving the working directory untouched, but effectively un-doing the top-most commit. You might want to do this if you realize after you committed that you made a mistake that you want to fix up: reset your HEAD back to its previous state, fix up the working directory and re-do the commit. If you want to totally un-do the commit (and reset your working directory to that point too), you'd first use git reset HEAD^ to reset to the parent, and then do a git checkout -f to reset the working directory state to that point in time too. Signed-off-by: Linus Torvalds [EMAIL PROTECTED] --- This is potentially a dangerous command, so maybe we should make it ask for confirmation first? On the other hand, it definitely is convenient: I often end up doing this by hand, and clearly other people have hit the oops, I want to undo and then re-do those last five commits, I was just a bit too drunk The old git reset only reset the index to the current HEAD, which is really only useful if you've tried to do a merge that failed and that you're giving up on. This one is more useful, but also potentially more dangerous - doing a git reset v0.99.3 git checkout -f will basically revert a tree to some old state, and if you didn't save the old point, you may not be able to get back to it (git-fsck-cache will help you, but..) Not hugely tested, btw. That strange extra git-rev-parse is _meant_ to make sure that if you reset to a tag, it will always extract the commit ID from that tag and not reset the HEAD to a tag object. diff --git a/git-reset-script b/git-reset-script --- a/git-reset-script +++ b/git-reset-script @@ -1,5 +1,7 @@ #!/bin/sh . git-sh-setup-script || die Not a git archive -git-read-tree --reset HEAD +rev=$(git-rev-parse --revs-only --verify --default HEAD $@) || exit +rev=$(git-rev-parse --revs-only --verify $rev^0) || exit +git-read-tree --reset $rev echo $rev $GIT_DIR/HEAD git-update-cache --refresh rm -f $GIT_DIR/MERGE_HEAD - 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: use of temporary refs in resolve
On Sun, 7 Aug 2005, Junio C Hamano wrote: Also ORIG_HEAD is probably redundant. After a successful automerge, the same information can be had by HEAD^1 Absolutely not. You forgot about one of the most common merge cases: fast-forward. In fact, ORIG_HEAD is _the_ most common head I use explicitly. Almost all operations take HEAD as default, but doing a gitk ORIG_HEAD.. is extremely useful after a pull. 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: Cannot install git RPM
On Tue, 9 Aug 2005, Clemens Koller wrote: Over here - using a non-standard ELDK/LFS mixture, git depends at least on: ... diffstat (ftp://invisible-island.net/diffstat/diffstat-1.39.tgz) Hmm.. This should not be true. Any diffstats should be converted to use git-apply --stat instead. I don't find any diffstat users, so maybe you just remember it from the old days, and didn't realize that it's not needed any more. [ That said, anybody who wants to install git might as well install diffstat, it's a useful program in general, and works on more than just unified diffs ] 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: gitweb - feature request
On Tue, 9 Aug 2005, Johannes Schindelin wrote: You have Firefox, don't you? Next time you surf to gitweb, right click on the funny yellow symbol in the lower right corner of your Firefox. It should say something like Subscribe to Do it. Left-click. And you need to be inside the project you want to rss (it would be nice if you could be at the projects page and it would give you a list of things to subscribe to, but that may not be possible). 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: Newbie question: equiv of: cvs co -p filename ?
On Tue, 9 Aug 2005, John Ellson wrote: I hacked this: #!/bin/bash ID=`git-ls-files -s | grep $1 | cut -d ' ' -f 2` No. git-ls-files shows the latest _index_ state, not the latest committed state. Use git-ls-tree HEAD pathname to get the latest committed state for the pathname, and then pick out the SHA1 from there, use git-cat-file blob sha1 to cat the result. Of course, this will work with any revision, not just HEAD. So you could do something like git-ls-tree $(git-rev-parse --default HEAD $@) | while read mode type sha name do case $type in blob) git-cat-file blob $sha ;; tree) git-ls-tree $sha ;; *) exit 1 done (totally untested) 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
Speed up git-merge-base a lot
In commit 4f7eb2e5a351e0d1f19fd4eab7e92834cc4528c2 I fixed git-merge-base
getting confused by datestamps that caused it to traverse things in a
non-obvious order.
However, my fix was a very brute-force one, and it had some really
horrible implications for more complex trees with lots of parallell
development. It might end up traversing all the way to the root commit.
Now, normally that isn't that horrible: it's used mainly for merging, and
the bad cases really tend to happen fairly rarely, so if it takes a few
seconds, we're not in too bad shape.
However, gitk will also do the git-merge-base for every merge it shows,
because it basically re-does the trivial merge in order to show the
interesting parts. And there we'd really like the result to be
instantaneous.
This patch does that by walking the tree more completely, and using the
same heuristic as git-rev-list to decide ok, the rest is uninteresting.
In one - hopefully fairly extreme - case, it made a git-merge-base go from
just under five seconds(!) to a tenth of a second on my machine.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
diff --git a/merge-base.c b/merge-base.c
--- a/merge-base.c
+++ b/merge-base.c
@@ -2,6 +2,22 @@
#include cache.h
#include commit.h
+#define PARENT1 1
+#define PARENT2 2
+#define UNINTERESTING 4
+
+static int interesting(struct commit_list *list)
+{
+ while (list) {
+ struct commit *commit = list-item;
+ list = list-next;
+ if (commit-object.flags UNINTERESTING)
+ continue;
+ return 1;
+ }
+ return 0;
+}
+
static struct commit *common_ancestor(struct commit *rev1, struct commit *rev2)
{
struct commit_list *list = NULL;
@@ -18,19 +34,18 @@ static struct commit *common_ancestor(st
insert_by_date(rev1, list);
insert_by_date(rev2, list);
- while (list) {
+ while (interesting(list)) {
struct commit *commit = list-item;
struct commit_list *tmp = list, *parents;
- int flags = commit-object.flags 3;
+ int flags = commit-object.flags 7;
list = list-next;
free(tmp);
- switch (flags) {
- case 3:
+ if (flags == 3) {
insert_by_date(commit, result);
- continue;
- case 0:
- die(git-merge-base: commit without either parent?);
+
+ /* Mark children of a found merge uninteresting */
+ flags |= UNINTERESTING;
}
parents = commit-parents;
while (parents) {
-
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] Debian packaging for 0.99.4
On Wed, 10 Aug 2005, Sebastian Kuzminsky wrote: People still use GNU Interactive Tools. Not just crazy, stupid people, and I bet not just Debian people. Why do you say that? Do you have anybody who actually does, or are you just claiming so? Some distributions seems to disagree with you. rpm.pbone.net already implies that SuSE not only has never packaged GNU interactive tools at all, they're already packaging git-core. Redhat seems to have dropped it after RH-7.1 according to the same admittedly very nonscientific source (while rpmfind.net didn't find any RH packages at all). So.. 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] Debian packaging for 0.99.4
On Thu, 11 Aug 2005, Sebastian Kuzminsky wrote: What I have is bug reports against the cogito package, from people who want to install both. The reports came very soon after I released the package, so I dont think it's a totally freak occurance. The point is, people have the thing _installed_, because apparently it comes as default with a full debian install. That doesn't mean they actually use them - they're complaining because they get a this clashes with that error. At least that's the only comment I've ever gotten: people that say that they had the old git installed. None of the ones that contacted me said that they had actually ever _used_ it. Hands up people. Does anybody _use_ GNU interactive tools? None of this I have a package crap. 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: [OT?] git tools at SourceForge ?
On Fri, 12 Aug 2005, Daniel Barkalow wrote: The git architecture makes the central server less important, and it's easy to run your own. On the other hand: - the git architecture is admirably suited to an _untrusted_ central server, ie exactly the SourceForge kind of setup. I realize that the people at SourceForge probably think they are trustworthy, but in the big picture, even SF probably would prefer people to see them as a _distribution_ point, not the final authority. IOW, with git (unlike, for example CVS), you can have a useful distribution point that is _not_ one that the developers have to control or even necessarily want to control. Which is exactly the kind of setup that would match what SF does. So with git, developers don't have to trust SF, and if SF is down or something bad happens (disk crash, bad backups, whatever), you didn't lose anything - the real development wasn't being done at SF anyway, it was a way to _connect_ the people who do real development. - Every developer wants to have their own history and complete source control, but very few developers actually have good distribution resources. kernel.org works for a few projects, and might be fine to expand a bit past what it does now, but kernel.org doesn't eevn try to do (nor _want_ to do, I bet) the kinds of things that SF does. Yes, developers can just merge with each other directly, and git allows that, but it's actually not very convenient - not because of git itself, but because of just doing the maintenance. For example, I don't allow incoming traffic to my machines, and I feel _much_ better that way. No MIS, no maintenance, and much fewer security issues. This is _exactly_ where something like SF really ends up being helpful. It's a _hosting_ service, and git is eminently suitable to being hosted, exactly because of its distributed approach. It needs very few hosting services: you could make do with a very very limited shell access, and in fact I tried to design the git push protocol so that you could give people ssh shell access, where the shell was not a real shell at all, but something that literally just implemented four or five commands (git-receive-pack and some admin commands to do things like creation/removal of whole archives etc). Also, kernel.org is providing space to a set of people with a large overlap with git users, since git hasn't been particularly publicized and kernel.org is hosting git. kernel.org certainly works well enough for the few projects that use it, but I don't think it's going to expand all that much. And it's possible that git usage won't expand all that much either. But quite frankly, I think git is a lot better than CVS (or even SVN) by now, and I wouldn't be surprised if it started getting some use outside of the git-only and kernel projects once people start getting more used to it. And so I'd be thrilled to have some site like SF support it. bkbits.net used to do that for BK projects, and there were a _lot_ of projects that used it. 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: [OT?] git tools at SourceForge ?
On Sat, 13 Aug 2005, Martin Langhoff wrote: Yes, developers can just merge with each other directly I take it that you mean an exchange of patches that does not depend on having public repos. What are the mechanisms available on that front, other than patchbombs? Just have a shared trusted machine. A lot of core developers end up having machines that they may not control, and that they may not be able to use as major distribution points, but that they _can_ share with others. For example, master.kernel.org ends up being that for the kernel: you don't have to have an account on master, but most of the core developers do, so they can use it as a short-cut that is independent of the actual public site. Similarly, some people are perfectly willing to give other trusted developers a ssh login on their machine - and that's a perfectly fine way to sync repositories directly if you have even a slow DSL link. You'd never want to _distribute_ the result over DSL, though. The point being that you can certainly sync up to others without going through a public site. [ We _could_ also just send pack-files as email attachments. There's nothing fundamentally wrong with doing the object discovery that git-send-pack does on its own manually over email. In other words: you could easily do something like Hey, I've got your commit as of yesterday, ID sha1, can you send me your current top-of-tree SHA1 name and the pack-file between the two? and have direct git-to-git synchronization even over email. NOTE NOTE NOTE! BK did this, with a bk send and bk receive. I hated it, which is why I'd never do scripts like that. But I think it's a valid thing to do when you're cursing the fact that the central repository is down, and has been down for five hours, and you don't know how long it will take to get back up, and you don't have _any_ other choices ] This is _exactly_ where something like SF really ends up being helpful. It's a _hosting_ service, and git is eminently suitable to being Not sure whether SF is offering rsync, but they do support hosting of arbitrarty data -- and a project using GIT can use that to host several developer trees. The problem with the arbitrary data approach (and rsync) is that the git repositories can get out of sync. We haven't seen it very often on kernel.org, but we _do_ see it. I think I've got something like three bug reports from people saying your tree is corrupted because it so happened that the mirroring was on-going at the same time I did a push, and the mirroring caught an updated HEAD without actually having caught all of the objects that HEAD referenced. Now, all the git tools do write things in the right order, and mirror scripts etc _tend_ to mirror in alphabetical order (and objects come before refs ;), so you really have to hit the right window where a git tool updates the git repository at the same time as a mirroring sweep is going on, but it definitely _does_ happen. It just happens seldom enough that most people haven't noticed. But if you've seen the gitweb page go blank for one of the projects, you now know why it can happen.. And this is inevitable when you have a non-git-aware server. You really need to update the objects in the right order, and to get the right order you do have to be git-aware. It'd be nice if SF offered gitweb and similar niceties. As my usage of GIT increases, I may add support for it on Eduforge.org I think we'll find that it's a learning process, to just find out what drives site managers mad (we certainly found the problem with lots of small files on kernel.org out ;). Having a few sites that do it and tell the others what gotchas there are involved with it (and what scripts they use for maintaining stuff like auto-packing etc) is all a learning experience. 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: Cloning speed comparison
On Sat, 13 Aug 2005, Petr Baudis wrote: Anyway, clone-pack is a clear winner for networks (but someone should re-check that, especially compared to rsync, wrt. server-side file caching); really cool fast, but not very practical for anonymous access. git-daemon is for the anonymous access case, either started from inetd (or any other external listen to port, exec service thing), or with the built-in listening stuff. It uses exactly the same protocol and logic as the regular ssh clone-pack thing, except it doesn't authenticate the remote end: it only checks that the local end is accepting anonymous pulls by checking whether there is a git-daemon-export-ok file in the git directory. In my tests, the git daemon was noticeably faster than ssh, if only because the authentication actually tends to be a big part of the overhead in small pulls. [ Hey. There's a deer outside my window eating our roses again. Cute ] 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: Cloning speed comparison
On Fri, 12 Aug 2005, H. Peter Anvin wrote: Running it over ssh would be a good way to do authentication... Well, if you have ssh as an option, you don't need git-daemon any more, since the protocol that git-daemon does runs quite well over ssh on its own... The only point of git-daemon really is when you don't have ssh access (ie you may want to give people a limited interface, but not full ssh). Ie as-is, it's only for anonymous reads of a git archive, but it obviously _could_ do more. 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: Fwd: Re: git checkout -f branch doesn't remove extra files
On Sat, 13 Aug 2005, Dave Jones wrote: Git actually has a _lot_ of nifty tools. I didn't realize that people didn't know about such basic stuff as git-tar-tree and git-ls-files. Maybe its because things are moving so fast :) Or maybe I just wasn't paying attention on that day. (I even read the git changes via RSS, so I should have no excuse). Well, git-tar-tree has been there since late April - it's actually one of those really early commands. I'm pretty sure the RSS feed came later ;) I use it all the time in doing releases, it's a lot faster than creating a tar tree by reading the filesystem (even if you don't have to check things out). A hidden pearl. This is my crappy release-script: [EMAIL PROTECTED] ~]$ cat bin/release-script #!/bin/sh stable=$1 last=$2 new=$3 echo # git-tag-script v$new echo git-tar-tree v$new linux-$new | gzip -9 ../linux-$new.tar.gz echo git-diff-tree -p v$stable v$new | gzip -9 ../patch-$new.gz echo git-rev-list --pretty v$new ^v$last ../ChangeLog-$new echo git-rev-list --pretty=short v$new ^v$last | git-shortlog ../ShortLog echo git-diff-tree -p v$last v$new | git-apply --stat ../diffstat-$new and when I want to do a new kernel release I literally first tag it, and then do release-script 2.6.12 2.6.13-rc6 2.6.13-rc7 and check that things look sane, and then just cut-and-paste the commands. Yeah, it's stupid. 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: Add an empty directory?
On Sat, 13 Aug 2005, Carl Baldwin wrote: The bottom line is that I don't really see many situations where it is absolutely necessary but it is a convenience. Not supporting it may seem like an artificial limit that really didn't need to be there. Well, there is an argument for not supporting it, namely that the way patches work, traditionally a directory that became empty is deleted (because patches have no way of saying remove directory or create directory). So a system where the existence of a directory flows from the existence of the files within the directory will automatically always do the right thing with patches floating around. Which is a big deal for me, since most of the kernel development still ends up being done with patches. Yes, we merge things with git, but a lot of the development is about passing patches around for review and commentary. And the thing is, you can always create the directory in your workspace. Git won't care, and won't know about it, but there's really no downside to it. 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][PATCH] Rewriting revs in place in push target repository
On Sat, 13 Aug 2005, Petr Baudis wrote:
* Does this break atomicity?
I think it does not in real setups, since thanks to O_RDWR the
file should be overwritten only when the write() happens.
Can a 41-byte write() be non-atomic in any real conditions?
That's not the problem.
The problem is that your change means that there is no locking, and you
now can have two writers that both update the same file, and they _both_
think that they succeed. They'll both read the old contents, decide that
it still is the one from before the push, and then they'll both do the
write.
And yes, in most (all?) sane filesystems, the end result is that one of
them wins, and the end result is a nice 41-byte file. But the problem is
that the other write just totally got lost, and the person doing the push
_thought_ he had updated the thing, but never did.
To make things worse, with NFS and client-side caching, different clients
that look at the tree at around that time can literally see _different_
heads winning the race. One of the writers wrote first, and that client
(and other NFS clients doing a read at that time) will see it succeed. But
then the other pusher writes, and now people will see _that_ one succeed.
Confusion reigns.
In contrast, with the create lock-file and rename thing, if there is a
race, somebody will win, and the loser will hopefully know they lost.
* Does this break with full disk/quota?
I'm not sure - we are substituting 41 bytes by another 41
bytes; will the system ever be evil enough to truncate the
file, then decide the user is over his quota and not write
the new contents?
Probably not.
But how about you just try to copy the permission/group of the original
file before you do the rename? I assume that if you're depending on
permissions, it's either a shared group or by having the thing writable by
others, so doing a
if (!fstat(oldfd, st)) {
fchown(fd, (uid_t) -1, st.st_gid);
fchmod(fd, st.st_mode ALLPERMS);
}
.. do rename here ..
which should get you where you want, no?
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: sending changesets from the middle of a git tree
On Sat, 13 Aug 2005, Steve French wrote: 1) There is no way to send a particular changeset from the middle of a set from one tree to another, without exporting it as a patch or rebuilding a new git tree. Correct. If I export those two changesets as patches, and send them on. presumably I lose the changset comments etc. Well, you can export them with git send-email and you won't be losing any comments. Alternatively, use git cherry, which helps re-order the commits in your tree. They'll be _new_ commits, but they'll have the contents moved over. Junio, maybe you want to talk about how you move patches from your pu branch to the real branches. and then when the upstream tree is merged back, it might look a little odd in the changeset history. Well, you'll end up having the same change twice. It happens. Or if you just redo your tree as a separate branch, you can reorder things so that you don't have them twice at all. 2) There is no way to update the comment field of a changeset after it goes in (e.g. to add a bugzilla bug number for a bug that was opened just after the fix went in). That's correct. Same things apply: you can move a patch over, and create a new one with a modified comment, but basically the _old_ commit will be immutable. The good news is that it means that nobody else can change what you said or did either. 3) There is no way to do a test commit of an individual changeset against a specified tree (to make sure it would still merge cleanly, automatically). Oh, sure, that's certainly very possible, and the git cherry stuff even helps you do it. Or use git-apply --check to just see if a patch applies and do your own scripts. 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: sending changesets from the middle of a git tree
On Sat, 13 Aug 2005, Linus Torvalds wrote: That's correct. Same things apply: you can move a patch over, and create a new one with a modified comment, but basically the _old_ commit will be immutable. Let me clarify. You can entirely _drop_ old branches, so commits may be immutable, but nothing forces you to keep them. Of course, when you drop a commit, you'll always end up dropping all the commits that depended on it, and if you actually got somebody else to pull that commit you can't drop it from _their_ repository, but undoing things is not impossible. For example, let's say that you've made a mess of things: you've committed three commits old-a-b-c, and you notice that a was broken, but you want to save b and c. What you can do is # Create a branch broken that is the current code # for reference git branch broken # Reset the main branch to three parents back: this # effectively undoes the three top commits git reset HEAD^^^ git checkout -f # Check the result visually to make sure you know what's # going on gitk --all # Re-apply the two top ones from broken # # First parent of broken (aka b): git-diff-tree -p broken^ | git-apply --index git commit --reedit=broken^ # Then top of broken (aka c): git-diff-tree -p broken | git-apply --index git commit --reedit=broken and you've now re-applied (and possibly edited the comments) the two commits b/c, and commit a is basically gone (it still exists in the broken branch, of course). Finally, check out the end result again: # Look at the new commit history gitk --all to see that everything looks sensible. And then, you can just remove the broken branch if you decide you really don't want it: # remove 'broken' branch rm .git/refs/heads/broken # Prune old objects if you're really really sure git prune And yeah, I'm sure there are other ways of doing this. And as usual, the above is totally untested, and I just wrote it down in this email, so if I've done something wrong, you'll have to figure it out on your own ;) 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: symlinked directories in refs are now unreachable
On Mon, 15 Aug 2005, Matt Draisey wrote: The behaviour of the symlinked in ref directories has changed from earlier versions of git. Hmm.. There used to be a mix of lstat() (in receive-pack) and stat() (in fsck-cache.c, and it got standardized in one function which used lstat. The reason for the lstat is really to try to avoid having especially the remote protocols follow symlinks, but I guess it's not a very good reason, so I don't think it would be wrong to just standardize refs.c to use stat() instead. You might sent a patch to Junio.. HOWEVER: symlinks for references really are pretty dangerous. We do things like echo new-id .git/HEAD and links (symlinks _or_ hardlinks) thus really aren't safe. You're much better off copying those small files. 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: Switching heads and head vs branch after CVS import
On Mon, 15 Aug 2005, Wolfgang Denk wrote: I asked this question before without receiving any reply: Assume I know exactly where the merge back happenend - is there any way to tell git about it, so I don't see all these dangling heads any more? You'd have to teach cvsimport about it. Basically, in cvsimport, you have ... my @par = (); @par = (-p,$parent) if $parent; which sets the parent. Right now the parent is _always_ just the previous head of the branch we're committing to (I'm no good with perl, but I think Martin was wrong - there's no code to handle the case of a merge: once we branch off, git cvsimport will not currently ever create a merge-commit). But if you have some heuristic for figuring out that it's a merge, and know the other branch is, you could add more parents by just adding another (-p, $merge_parent) to the parameters to git-commit-tree. The problem is literally how to figure out that it's a merge. You can probably make a guess from the commit message together with possibly looking at the diff. The good news is that if you guess wrong, and you claim a merge where none exists, it doesn't really do any real damage. It might make th history look strange, and it might make subsequent git merges harder if the branch is actually still live and you want to continue development within git. But even that is debatable (if the eventual git merge isn't trivial, you're likely to have to merge by hand anyway - and it's going to be as hard as a CVS merge would have been, because quite frankly, you've got the same information CVS had..). 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: gitweb - option to disable rename detection
On Tue, 16 Aug 2005, Yasushi SHOJI wrote: Instead of disabling it entirely, how about just having some limit on it? ah, that's a good idea. here is a quick and dirty patch. This makes it somewhat more expensive - I was thinking about disabling it in git-diff-tree, since the rename logic already knows how many new/deleted files there are. 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] Add SubmittingPatches
On Tue, 16 Aug 2005, Johannes Schindelin wrote:
BTW, I don't know how many people still use pine, but for those poor souls
it may be good to mention that the quell-flowed-text is needed for recent
versions.
And 4.58 needs at least this
Linus
---
diff-tree 8326dd8350be64ac7fc805f6563a1d61ad10d32c (from
e886a61f76edf5410573e92e38ce22974f9c40f1)
Author: Linus Torvalds [EMAIL PROTECTED]
Date: Mon Aug 15 17:23:51 2005 -0700
Fix pine whitespace-corruption bug
There's no excuse for unconditionally removing whitespace from
the pico buffers on close.
diff --git a/pico/pico.c b/pico/pico.c
--- a/pico/pico.c
+++ b/pico/pico.c
@@ -219,7 +219,9 @@ PICO *pm;
switch(pico_all_done){ /* prepare for/handle final events */
case COMP_EXIT : /* already confirmed */
packheader();
+#if 0
stripwhitespace();
+#endif
c |= COMP_EXIT;
break;
-
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] Alternate object pool mechanism updates.
On Sun, 14 Aug 2005, Junio C Hamano wrote: Linus Torvalds [EMAIL PROTECTED] writes: I think this is great - especially for places like kernel.org, where a lot of repos end up being related to each other, yet independent. Yes. There is one shortcoming in the current git-clone -s in the proposed updates branch. If the parent repository has alternates on its own, that information should be copied to the cloned one as well (e.g. Jeff has alternates pointing at you, and I clone from Jeff with -s flag --- I should list not just Jeff but also you to borrow from in my alternates file). Btw, looking at the code, it strikes me that using : to separate the alternate object directories in the file is rather strange. Maybe allow a different format for the file? Or at least allow '\n' as an alternate separator (but it would be nice to allow comments too). Finally, I have to say that that info directory is confusing. Namely, there's two of them - the git info and the object info directories are totally different directories - maybe logical, but to me it smells like info is here a code-name for misc files that don't make sense anywhere else. Anyway, I don't think alternates is necessarily sensible as a object information. Sure, it's about alternate objects, but the thing is, object directories can be shared across many projects, but alternates to me makes more sense as a per-project thing. What this all is leading up to is that I think we'd be better off with a totally new git config file, in .git/config, and we'd have all the startup configuration there. Including things like alternate object directories, perhaps standard preferences for that particular repo, and things like the grafts thing. Wouldn't that be nice? 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
[RFC PATCH] Add support for figuring out where in the git archive we are
This does only git-diff-cache and git-diff-files, but the concept
should work for any command that uses the working tree.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
This is really partly a serious patch, but also just a query whether
people would want git to work in subdirectories, not just the top-level
directory.
So you can be in linux/drivers, and if you do a
git-diff-files -p char
then it will automatically be turned into the full pathname, and do the
right thing (ie do a diff of drivers/char only).
I didn't want to do it originally, but that was largely a complexity
issue, and an issue of there being many more things up in the air at that
time. Now, things have calmed down a bit, the interfaces are fairly
stable, and it turns out to be not that difficult to just walk up the
chain of directories until we hit the one that has the .git directory in
it.
I only converted git-diff-files and git-diff-cache to do this, because
so far it's a technology demo. And the git-diff-script file (and the
git-sh-setup-script in particular) does _not_ accept this automatically
figure out where we are thing, so it's really only the native git diff
commands that do it.
But if people think it's a good idea, I can pretty trivially convert the
rest. It's done in a way that makes it very easy to convert programs to
take advantage of the auto-git-directory-finding thing.
If you use the GIT_DIR environment variable approach, it assumes that all
filenames you give it are absolute and acts the way it always did before.
Comments? Like? Dislike?
Linus
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -97,7 +97,7 @@ LIB_H=cache.h object.h blob.h tree.h com
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 \
refs.o csum-file.o pack-check.o pkt-line.o connect.o ident.o \
-sha1_name.o
+sha1_name.o setup.o
LIB_H += rev-cache.h
LIB_OBJS += rev-cache.o
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -140,6 +140,8 @@ extern char *get_graft_file(void);
#define ALTERNATE_DB_ENVIRONMENT GIT_ALTERNATE_OBJECT_DIRECTORIES
+extern char **setup_git_directory(char **pathspec);
+
#define alloc_nr(x) (((x)+16)*3/2)
/* Initialize and use the cache information */
diff --git a/diff-cache.c b/diff-cache.c
--- a/diff-cache.c
+++ b/diff-cache.c
@@ -179,15 +179,12 @@ int main(int argc, const char **argv)
int allow_options = 1;
int i;
- read_cache();
for (i = 1; i argc; i++) {
const char *arg = argv[i];
if (!allow_options || *arg != '-') {
- if (tree_name) {
- pathspec = argv + i;
+ if (tree_name)
break;
- }
tree_name = arg;
continue;
}
@@ -265,12 +262,16 @@ int main(int argc, const char **argv)
usage(diff_cache_usage);
}
+ pathspec = setup_git_directory(argv + i);
+
if (find_copies_harder detect_rename != DIFF_DETECT_COPY)
usage(diff_cache_usage);
if (!tree_name || get_sha1(tree_name, sha1))
usage(diff_cache_usage);
+ read_cache();
+
/* The rest is for paths restriction. */
diff_setup(diff_setup_opt);
diff --git a/diff-files.c b/diff-files.c
--- a/diff-files.c
+++ b/diff-files.c
@@ -45,8 +45,7 @@ int main(int argc, const char **argv)
{
static const unsigned char null_sha1[20] = { 0, };
const char **pathspec;
- int entries = read_cache();
- int i;
+ int entries, i;
while (1 argc argv[1][0] == '-') {
if (!strcmp(argv[1], -p) || !strcmp(argv[1], -u))
@@ -95,8 +94,9 @@ int main(int argc, const char **argv)
argv++; argc--;
}
- /* Do we have a pathspec? */
- pathspec = (argc 1) ? argv + 1 : NULL;
+ /* Find the directory, and set up the pathspec */
+ pathspec = setup_git_directory(argv + 1);
+ entries = read_cache();
if (find_copies_harder detect_rename != DIFF_DETECT_COPY)
usage(diff_files_usage);
diff --git a/setup.c b/setup.c
new file mode 100644
--- /dev/null
+++ b/setup.c
@@ -0,0 +1,66 @@
+#include cache.h
+
+char **setup_git_directory(char **pathspec)
+{
+ static char *spec[2], **p;
+ static char cwd[PATH_MAX+1];
+ int len, offset;
+
+ /*
+* If GIT_DIR is set explicitly, we're not going
+* to do any discovery
+*/
+ if (gitenv(GIT_DIR_ENVIRONMENT))
+ return *pathspec ? pathspec : NULL;
+
+ if (!getcwd(cwd, sizeof(cwd)) || cwd[0] != '/')
+ die(Unable to read current working directory);
+
+ offset = len = strlen(cwd
Re: [RFC PATCH] Add support for figuring out where in the git archive we are
On Tue, 16 Aug 2005, Junio C Hamano wrote: Comments: Wouldn't that mean git-*-scripts would not benefit from this because git-sh-setup would set GIT_DIR for you even if you don't? As it stands now, yes. But the point being that if people like this, then I'll just change the git-sh-setup-script accordingly. For example, once git-diff-tree also does the same thing, then git-diff-script would have no reason left to even call the current git-sh-setup-script at all, since the git-diff-* commands would basically do the setup _and_ report the errors that git-sh-setup-script does now. If you can do cd drivers git-diff-files ../net that would be very useful. I don't do that right now, but it's actually very easy to do in the setup_git_directory() function. It falls out very simply there - both the ./ and the ../ prefix would make tons of sense to handle there. Do you want to take the current patch (which buys you very little because not a lot of stuff has been set up to deal with it, but is the basis for all future work anyway) or do you want me to polish it up a bit and re-submit the whole thing? I'd do at least the git-diff-tree part and the ./ and ../ handling, and convert at least the git diff thing to the new world order and away from git-sh-setup-script? 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 PATCH] Add support for figuring out where in the git archive we are
On Tue, 16 Aug 2005, Junio C Hamano wrote:
The developement history would look nicer if you did the latter,
but I am easy and can go either way.
Here is.
I'd do at least the git-diff-tree part and the ./ and ../ handling,
and convert at least the git diff thing to the new world order and away
from git-sh-setup-script?
Sounds like fun.
Mostly done. It actually works from inside subdirectories, but . at the
top-level is still not done. Small detail. Will fix later. But it would
help if you would apply this, since I'm going to be off for dinner..
The ../ handling was pretty straightforward.
Linus
Make git diff work inside relative subdirectories
We always show the diff as an absolute path, but pathnames to diff are
taken relative to the current working directory (and if no pathnames are
given, the default ends up being all of the current working directory).
Note that ../xyz also works, so you can do
cd linux/drivers/char
git diff ../block
and it will generate a diff of the linux/drivers/block changes.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -97,7 +97,7 @@ LIB_H=cache.h object.h blob.h tree.h com
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 \
refs.o csum-file.o pack-check.o pkt-line.o connect.o ident.o \
-sha1_name.o
+sha1_name.o setup.o
LIB_H += rev-cache.h
LIB_OBJS += rev-cache.o
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -140,6 +140,9 @@ extern char *get_graft_file(void);
#define ALTERNATE_DB_ENVIRONMENT GIT_ALTERNATE_OBJECT_DIRECTORIES
+extern const char **get_pathspec(const char *prefix, char **pathspec);
+extern const char *setup_git_directory(void);
+
#define alloc_nr(x) (((x)+16)*3/2)
/* Initialize and use the cache information */
diff --git a/diff-cache.c b/diff-cache.c
--- a/diff-cache.c
+++ b/diff-cache.c
@@ -168,10 +168,11 @@ static const char diff_cache_usage[] =
[common diff options] tree-ish [path...]
COMMON_DIFF_OPTIONS_HELP;
-int main(int argc, const char **argv)
+int main(int argc, char **argv)
{
const char *tree_name = NULL;
unsigned char sha1[20];
+ const char *prefix = setup_git_directory();
const char **pathspec = NULL;
void *tree;
unsigned long size;
@@ -179,15 +180,12 @@ int main(int argc, const char **argv)
int allow_options = 1;
int i;
- read_cache();
for (i = 1; i argc; i++) {
const char *arg = argv[i];
if (!allow_options || *arg != '-') {
- if (tree_name) {
- pathspec = argv + i;
+ if (tree_name)
break;
- }
tree_name = arg;
continue;
}
@@ -265,12 +263,16 @@ int main(int argc, const char **argv)
usage(diff_cache_usage);
}
+ pathspec = get_pathspec(prefix, argv + i);
+
if (find_copies_harder detect_rename != DIFF_DETECT_COPY)
usage(diff_cache_usage);
if (!tree_name || get_sha1(tree_name, sha1))
usage(diff_cache_usage);
+ read_cache();
+
/* The rest is for paths restriction. */
diff_setup(diff_setup_opt);
diff --git a/diff-files.c b/diff-files.c
--- a/diff-files.c
+++ b/diff-files.c
@@ -41,12 +41,12 @@ static void show_modified(int oldmode, i
diff_change(oldmode, mode, old_sha1, sha1, path, NULL);
}
-int main(int argc, const char **argv)
+int main(int argc, char **argv)
{
static const unsigned char null_sha1[20] = { 0, };
const char **pathspec;
- int entries = read_cache();
- int i;
+ const char *prefix = setup_git_directory();
+ int entries, i;
while (1 argc argv[1][0] == '-') {
if (!strcmp(argv[1], -p) || !strcmp(argv[1], -u))
@@ -95,8 +95,9 @@ int main(int argc, const char **argv)
argv++; argc--;
}
- /* Do we have a pathspec? */
- pathspec = (argc 1) ? argv + 1 : NULL;
+ /* Find the directory, and set up the pathspec */
+ pathspec = get_pathspec(prefix, argv + 1);
+ entries = read_cache();
if (find_copies_harder detect_rename != DIFF_DETECT_COPY)
usage(diff_files_usage);
diff --git a/diff-tree.c b/diff-tree.c
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -395,16 +395,25 @@ static int diff_tree_stdin(char *line)
return diff_tree_commit(commit, line);
}
+static int count_paths(const char **paths)
+{
+ int i = 0;
+ while (*paths++)
+ i++;
+ return i;
+}
+
static const char diff_tree_usage[] =
git-diff-tree [--stdin] [-m] [-s] [-v] [--pretty] [-t]
[common diff options] tree-ish
Re: [RFC PATCH] Add support for figuring out where in the git archive we are
On Tue, 16 Aug 2005, Junio C Hamano wrote:
Merged, pushed out, and tested. Ouch. Fails on t test.
It's because the new git-diff-files expects there to be a valid readable
.git/HEAD, and is unhappy since the test hasn't updated HEAD.
This trivial patch fixes it.
Linus
Fix test failure due to overly strict .git directory tests
We may not actually have a valid HEAD at all times, so relax the validity
tests for a .git subdirectory accordingly.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
-
diff --git a/setup.c b/setup.c
--- a/setup.c
+++ b/setup.c
@@ -81,10 +81,9 @@ const char *setup_git_directory(void)
offset = len = strlen(cwd);
for (;;) {
/*
-* We always want to see a .git/HEAD and a .git/refs/
-* subdirectory
+* We always want to see a .git/refs/ subdirectory
*/
- if (!access(.git/HEAD, R_OK) !access(.git/refs/, X_OK)) {
+ if (!access(.git/refs/, X_OK)) {
/*
* Then we need either a GIT_OBJECT_DIRECTORY define
* or a .git/objects/ directory
-
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: gitk with hyperspace support
On Wed, 17 Aug 2005, Paul Mackerras wrote: I would like to get some feedback about what people think of the visual effect of this new approach, and in particular whether having the lines jump into hyperspace loses information that people find useful. Me likee. Maybe some knob to tune how eagerly this happens? The new version is at: http://ozlabs.org/~paulus/gitk/gitk.hs .hs made firefox think it was haskell. Confusing ;) 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: Improve handling of . and .. in git-diff-*
On Tue, 16 Aug 2005, Linus Torvalds wrote: This fixes up usage of .. (without an ending slash) and . (with or without the ending slash) in the git diff family. Btw, if it wasn't clear, with this patch you can now do git diff . and it will show the diffs for everything under the current working directory. Similarly, you can do git diff ./drivers or something like cd arch/i386 git diff . ../x86-64 and it will do the obvious thing (the obvious thing in the latter case is to show the diffs for everything under _both_ arch/i386 and arch/x86-64, but not anything outside of that - the path pattern gets rewritten to arch/i386 and arch/x86-64). Linus PS. A number of the other work tree ops can be similarly extended to DTRT in git project subdirectories, but I wanted to finish off the git diff family first, and get that one all done. I think I'm done now, and I might tackle the other things (git-update-cache, git-checkout-cache, git-commit-script, etc) tomorrow. - 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] Teach applymbox to keep the Subject: line.
On Tue, 16 Aug 2005, Junio C Hamano wrote: This is a companion patch to the previous format-patch fix. With -k, format-patch can be told not to remove the [PATCH] in the original commit, nor to add the [PATCH] on its own. I think this might be the point in time to just make the [PATCH] prefix go away. It made much more sense with BK than it does with git: since git keeps track of author and committer separately, you can always see when the committer wasn't the author of the change, which is what the [PATCH] thing was all about. In other words, at least for the kernel, [PATCH] was a marker that said the author didn't commit this directly. Git already has that information explicitly in the git data. (Also, with proper Signed-off-by: lines it's also always clear that there were other people involved, and that the author of the patch is different from the person who applied it). So I would personally not mind if we just made the [PATCH] prefix go away entirely, or perhaps had a separate flag to git-applymbox that told it to prepend a specific prefix to the Subject: line (which might not be [PATCH] at all) defaulting to no prefix. Linus PS. Another historical reason for marking patches explicitly was that people were worried that introducing BK would somehow make the old patch-based submissions be second-class citizens. It was easy to make statistics and show that at least half the real changes (as opposed to merges) were still patch-based. So again, the PATCH marker had some historical relevance, but I don't think it matters any more. - 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 1/2] Export relative path handling prefix_path() function
Not all programs necessarily have a pathspec array of pathnames, some of
them (like git-update-cache) want to do things one file at a time. So
export the single-path interface too.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
cache.h |1 +
setup.c |2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
c06157a36e49182c34e1e92aa7b329bde5dca3f9
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -142,6 +142,7 @@ extern char *get_graft_file(void);
extern const char **get_pathspec(const char *prefix, char **pathspec);
extern const char *setup_git_directory(void);
+extern char *prefix_path(const char *prefix, int len, char *path);
#define alloc_nr(x) (((x)+16)*3/2)
diff --git a/setup.c b/setup.c
--- a/setup.c
+++ b/setup.c
@@ -1,6 +1,6 @@
#include cache.h
-static char *prefix_path(const char *prefix, int len, char *path)
+char *prefix_path(const char *prefix, int len, char *path)
{
char *orig = path;
for (;;) {
-
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 2/2] Make git-update-cache take relative pathnames
This also makes ./filename acceptable as a side effect, since the
pathname normalization handles that too.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
update-cache.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
ece92eeda777c3141f5692132ccc2ba7e4e801a2
diff --git a/update-cache.c b/update-cache.c
--- a/update-cache.c
+++ b/update-cache.c
@@ -321,6 +321,7 @@ int main(int argc, char **argv)
{
int i, newfd, entries, has_errors = 0;
int allow_options = 1;
+ const char *prefix = setup_git_directory();
newfd = hold_index_file_for_update(cache_file, get_index_file());
if (newfd 0)
@@ -381,6 +382,7 @@ int main(int argc, char **argv)
}
die(unknown option %s, path);
}
+ path = prefix_path(prefix, prefix ? strlen(prefix) : 0, path);
if (!verify_path(path)) {
fprintf(stderr, Ignoring path %s\n, argv[i]);
continue;
-
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] Teach parse_commit_buffer about grafting.
On Thu, 18 Aug 2005, Paul Mackerras wrote: I added support for grafts to gitk just yesterday, and it should be on kernel.org by now. I also committed the changes to send lines into hyperspace. Paul, I hate to tell you about yet another flag to git-rev-list, but did you realize that in addition to all the other magic flags, there's a flag called --parents? Right now you use git-rev-list --header --topo-order, which gives you both the commit ID's and the header. Add a --parents there, and you'll notice that the first line of each NUL-terminated record changes from just the commit ID to the commit ID + parent list. That way gitk wouldn't need to actually know about grafts, because it would just pick it up from the git-rev-list output which gets it from the regular commit parsing code. Umm. git-rev-list really does everything. Rule of thumb: if you _ever_ need to look at any other internal git information, you're probably doing something wrong, or you've missed yet another flag ;) 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] Teach applymbox to keep the Subject: line.
On Thu, 18 Aug 2005, Sam Ravnborg wrote: I almost always handedit my mails and I find myself forgetting to add Signed-off-by from time to time. Is there a simple way to implment a trigger that can check that _I_ signed off the patch before applying it? Well, Junio has been talking about adding commit hooks. I don't think that's been done. The idea being that you could verify that the thing you're committing follows certain rules (no bad whitespace added in the diff, sign-offs in the messages, whatever). That said, git-applypatch (which is what git-applymbox ends up calling) does not use the general git commit script. So it would have to have its own hook. The script is pretty easy to read, though: just look at git-applypatch, and notice that the last stages are: ... git-apply --index $PATCHFILE || exit 1 tree=$(git-write-tree) || exit 1 echo Wrote tree $tree commit=$(git-commit-tree $tree -p $(cat .git/HEAD) $final) || exit 1 echo Committed: $commit echo $commit .git/HEAD and that just before this thing you could easily add some sanity checking by hand. The commit message at that point is in the $final file, and the patch is obviously in $PATCHFILE, so you can verify either of those to your hearts content. The only question is what the hook/trigger should look like. just put something like [ -x .git/hooks/applypatch-hook ] .git/hooks/applypatch-hook $tree $PATCHFILE || exit at the line before that git-apply perhaps? Then, you could install your own applypatch hook which looks at the message or the patch? 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: git-whatchanged -p anomoly?
On Thu, 18 Aug 2005, Luck, Tony wrote: The spurious changes reported by git-whatchanged -p are: Documentation/acpi-hotkey.txt |3 Documentation/kernel-parameters.txt|5 drivers/acpi/osl.c |6 fs/jfs/inode.c |4 Ehh. These are all from: Author: Alex Williamson [EMAIL PROTECTED] [IA64, X86_64] fix swiotlb sizing in commit b63d6e09b432e6873d072a767c87218f8e73e66c. And you've signed off on it. Do a git-diff-tree -p --pretty b63d6e09b432e6873d072a767c87218f8e73e66c | less -S to see it in all its glory. Now, I suspect you didn't mean to commit that thing: it really looks like you've mixed up your patches somehow, because the commit message seems to match only a very small portion of the patch. Did you perhaps have a failed merge or something that was in your index when you applied that patch? If you have a dirty index when you do git-applymbox, it the commit done as part of the applymbox might commit other state too. (git-applymbox _does_ verify that the files that it patches are up-to-date in the index, but it does _not_ verify that the index matches the current HEAD. I guess I could add a sanity check for that...) Is this a bug, or am I just confused about how git-whatchanged works? It's definitely not a bug in git-whatchanged, and I don't think you're confused about how git-whatchanged is supposed to work. But I think you've committed a bad patch. 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] Teach parse_commit_buffer about grafting.
On Fri, 19 Aug 2005, Paul Mackerras wrote: Umm. git-rev-list really does everything. Rule of thumb: if you _ever_ need to look at any other internal git information, you're probably doing something wrong, or you've missed yet another flag ;) I still look in [gitdir]/refs/tags/* and [gitdir]/refs/heads/*, what flag have I missed? :) Junio wants me to look at everything under [gitdir]/refs, in fact. Or are the refs not considered internal git information? Ahh, ok, fair enough. git-rev-list won't give you that. And yes, the general rule is that anything under .git/refs/ is potentially a reference. If it's under heads/ or tags/ it's a branch/tag, and then the prefix heads/ or tags/ shouldn't be part of the name - you already show the difference with colors. Anything else is unusual, but bisection puts refs in the .git/refs/bisect directory for example, and if gitk were to show those, it should probably show them in yet another color, and _with_ the bisect/ prefix.. 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: Questions on 'cvs migration guide''
On Fri, 19 Aug 2005, Martin Langhoff wrote: In the section 'Emulating CVS behaviour', where the team setup is described with a team 'merger'. What is not clear is how to deal with project-wide branches. Should they be created in the master repo, and everyone clone a new repo from it? Just make them another branch in the master repo. Whether people will clone a whole new repo for it, or have just one repo and switch between local branches in their own local (single) repo is their personal choice. Some people may well prefer to have all different branches checked out in different places (ie have one repository per branch) others may prefer to work with one repository and just switch. And yet another question: the teammember who is pulling must 'switch' the merging repo to the right branch, pull from the corresponding remote repos of each teammember, and push to the public view of the repo. Is that right? .. yes. Or alternatively, just keep the repo at that branch (and if such a person works on multiple branches, he/she can thus just keep multiple repos). 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: Questions on 'cvs migration guide''
On Fri, 19 Aug 2005, Martin Langhoff wrote: I'm keen on keeping my 'merge publish' step in a single repo that has all the 'team' branches. The person running this repo will probably actually code in separate repos, and merge in there too. I would suggest against a person owning a merge and publish. Instead, just have a public repo that everybody involved to can push to - _they_ will need to merge before they push (since a push won't accept a unrelated parent), but that way anybody can export their changes at any time, exactly like with a central CVS repository. Right now I'm switching 'heads' (I'm getting used to cogito's use of 'branch' for 'remote head') using this quick'n'dirty bit of shell: No, just do git checkout headname but I want to prevent the action if the checkout is 'dirty'. Is there any way to check whether cg-diff thinks anything has changed? If you use git checkout to switch branches, it will do that testing for you. You can still _force_ a head switch with git checkout -f. Oh, and if a file was dirty that is the same in both heads, the dirtyness follows you into the new head. If that isn't what you want, then you need to add some logic like if [ $(git-diff-files) != ]; then echo Current branch not clean 2 exit 1 fi git checkout $@ or something. 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: Publishing your work questions?
On Sat, 20 Aug 2005, Linus Torvalds wrote:
But yes, you _should_ be able to do it with that ultra-simplistic login
shell. Probably just a 5-liner main() function or something.
This is entirely untested, and a lot more than five lines of code. Edit
until it works.
Linus
#include unistd.h
#include string.h
#include stdlib.h
static char *parse_argument(char *orig)
{
int i;
int len = strlen(orig);
/* We only accept properly quoted arguments */
if (len 2 || orig[0] != '\'' || orig[len-1] != '\'')
exit(2);
orig[len-1] = 0;
orig++;
len -= 2;
/*
* Go look for quoted single-ticks. They are always
* quoted as '\'', we don't accept anything else
*/
for (i = 0; len ; i++, len--) {
char c = orig[i];
if (c != '\'')
continue;
if (len 4 || memcmp(orig+i, '\\'', 4))
exit(2);
len -= 3;
memmove(orig+1, orig+4, len+1);
}
return orig;
}
int main(int argc, char **argv)
{
int i;
char *cmd, *arg;
if (argc 2)
exit(1);
i = 2;
cmd = argv[1];
if (!strcmp(cmd, -c))
cmd = argv[i++];
/* We're not going to allow anything else */
if (argc != i)
exit(1);
/*
* Right now we only accept upload commands, but
* we could have some maintenance commands too, to
* create new archives or delete old ones..
*/
if (strncmp(cmd, git-upload-pack , 16))
exit(1);
arg = parse_argument(cmd+16);
execlp(git-upload-pack, git-upload-pack, arg, NULL);
exit(3);
}
-
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-ls-files: generalized pathspecs
This generalizes the git glob string to be a lot more like the
git-diff-* pathspecs (but there are still differences: the diff family
doesn't do any globbing, and because the diff family always generates the
full native pathname, it doesn't have the issue with ..).
It does three things:
- it allows multiple matching strings, ie you can do things like
git-ls-files arch/i386/ include/asm-i386/ | xargs grep pattern
- the matching criteria is a combination of exact path component
match (the same as the git-diff-* family), and fnmatch(). However,
you should be careful with the confusion between the git-ls-files
internal globbing and the standard shell globbing, ie
git-ls-files fs/*.c
does globbing in the shell, and does something totally different from
git-ls-files 'fs/*.c'
which does the globbing inside git-ls-files.
The latter has _one_ pathspec with a wildcard, and will match any .c
file anywhere under the fs/ directory, while the former has been
expanded by the shell into having _lots_ of pathspec entries, all of
which are just in the top-level fs/ subdirectory. They will happily
be matched exactly, but we will thus miss all the subdirectories under
fs/.
As a result, the first one will (on the current kernel) match 55 files,
while the second one will match 664 files!
- it uses the generic path prefixing, so that .. and friends at the
beginning of the path spec work automatically
NOTE! When generating relative pathname output (the default), a
pathspec that causes the base to be outside the current working
directory will be rejected with an error message like:
fatal: git-ls-files: cannot generate relative filenames containing '..'
because we do not actually generate .. in the output. However, the
.. format works fine for the --full-name case:
cd arch/i386/kernel
git-ls-files --full-name ../mm/
results in
arch/i386/mm/Makefile
arch/i386/mm/boot_ioremap.c
arch/i386/mm/discontig.c
arch/i386/mm/extable.c
arch/i386/mm/fault.c
arch/i386/mm/highmem.c
arch/i386/mm/hugetlbpage.c
arch/i386/mm/init.c
arch/i386/mm/ioremap.c
arch/i386/mm/mmap.c
arch/i386/mm/pageattr.c
arch/i386/mm/pgtable.c
Perhaps more commonly, the generic path prefixing means that . and
./ automatically get simplified and work properly.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
diff --git a/ls-files.c b/ls-files.c
--- a/ls-files.c
+++ b/ls-files.c
@@ -21,7 +21,7 @@ static int line_terminator = '\n';
static int prefix_len = 0, prefix_offset = 0;
static const char *prefix = NULL;
-static const char *glob = NULL;
+static const char **pathspec = NULL;
static const char *tag_cached = ;
static const char *tag_unmerged = ;
@@ -302,6 +302,33 @@ static int cmp_name(const void *p1, cons
e2-name, e2-len);
}
+/*
+ * Match a pathspec against a filename. The first len characters
+ * are the common prefix
+ */
+static int match(const char **spec, const char *filename, int len)
+{
+ const char *m;
+
+ while ((m = *spec++) != NULL) {
+ int matchlen = strlen(m + len);
+
+ if (!matchlen)
+ return 1;
+ if (!strncmp(m + len, filename + len, matchlen)) {
+ if (m[len + matchlen - 1] == '/')
+ return 1;
+ switch (filename[len + matchlen]) {
+ case '/': case '\0':
+ return 1;
+ }
+ }
+ if (!fnmatch(m + len, filename + len, 0))
+ return 1;
+ }
+ return 0;
+}
+
static void show_dir_entry(const char *tag, struct nond_on_fs *ent)
{
int len = prefix_len;
@@ -310,7 +337,7 @@ static void show_dir_entry(const char *t
if (len = ent-len)
die(git-ls-files: internal error - directory entry not
superset of prefix);
- if (glob fnmatch(glob, ent-name + len, 0))
+ if (pathspec !match(pathspec, ent-name, len))
return;
printf(%s%s%c, tag, ent-name + offset, line_terminator);
@@ -373,7 +400,7 @@ static void show_ce_entry(const char *ta
if (len = ce_namelen(ce))
die(git-ls-files: internal error - cache entry not superset of
prefix);
- if (glob fnmatch(glob, ce-name + len, 0))
+ if (pathspec !match(pathspec, ce-name, len))
return;
if (!show_stage)
@@ -455,36 +482,44 @@ static void prune_cache(void)
active_nr = last;
}
-/*
- * If the glob starts with a subdirectory, append it to
- * the prefix instead, for more efficient operation.
- *
- * But we do not update the prefix_offset, which tells
- * how much of the name to ignore at printout.
- */
-static void
Re: git-rev-parse question.
On Tue, 23 Aug 2005, Junio C Hamano wrote: I have been looking at what git-rev-parse does and could not figure out a way to convince it to give me only arguments with a '-' prefix. Gaah. Understandable. It got broken during some cleanup. Try this trivial patch, it should work better. NOTE! The behaviour of -- for git-rev-parse is somewhat unclear. Right now it prints it out with --flags, which is probably wrong. Linus --- Subject: Fix git-rev-parse --default and --flags handling This makes the argument to --default and any --flags arguments should up correctly. Signed-off-by: Linus Torvalds [EMAIL PROTECTED] --- diff --git a/rev-parse.c b/rev-parse.c --- a/rev-parse.c +++ b/rev-parse.c @@ -107,7 +107,7 @@ static void show_arg(char *arg) if (do_rev_argument is_rev_argument(arg)) show_rev_arg(arg); else - show_norev(arg); + show(arg); } static void show_default(void) @@ -122,7 +122,7 @@ static void show_default(void) show_rev(NORMAL, sha1, s); return; } - show_arg(s); + show(s); } } - 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: Current status toward 0.99.5 and beyond
On Tue, 23 Aug 2005, Junio C Hamano wrote:
So far, the following commands should be usable with relative directory
paths:
update-cache
ls-files
diff-files
diff-cache
diff-tree
Also, git-rev-parse.
Finally, this trivial patch makes git-rev-list also able to handle not
being in the top-level directory, which makes it possible to do git log
and git-whatchanged at any point in the directory structure.
Linus
---
Subject: Make git-rev-list work within subdirectories
This trivial patch makes git-rev-list able to handle not being in the
top-level directory. This magically also makes git-whatchanged do the
right thing.
Trivial scripting fix to make sure that git log also works.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
diff --git a/git-log-script b/git-log-script
--- a/git-log-script
+++ b/git-log-script
@@ -1,5 +1,4 @@
#!/bin/sh
-. git-sh-setup-script || die Not a git archive
-revs=$(git-rev-parse --revs-only --default HEAD $@)
+revs=$(git-rev-parse --revs-only --default HEAD $@) || exit
[ $revs ] || die No HEAD ref
git-rev-list --pretty $(git-rev-parse --default HEAD $@) | LESS=-S
${PAGER:-less}
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -481,6 +481,7 @@ static void handle_one_commit(struct com
int main(int argc, char **argv)
{
struct commit_list *list = NULL;
+ const char *prefix = setup_git_directory();
int i, limited = 0;
for (i = 1 ; i argc; i++) {
-
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: git-rev-parse question.
On Tue, 23 Aug 2005, Linus Torvalds wrote:
Try this trivial patch, it should work better.
Actually, don't do the show_default() part of this. We should _not_ show
the default string if we haev --no-revs and the string doesn't match a
rev.
Also, this fixes -- handlign with --flags. Thinking about it for a
few seconds made it obvious that we shouldn't show it.
Linus
---
Subject: Fix git-rev-parse --default and --flags handling
This makes the argument to --default and any --flags arguments should up
correctly, and makes -- together with --flags act sanely.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
diff --git a/rev-parse.c b/rev-parse.c
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -107,7 +107,7 @@ static void show_arg(char *arg)
if (do_rev_argument is_rev_argument(arg))
show_rev_arg(arg);
else
- show_norev(arg);
+ show(arg);
}
static void show_default(void)
@@ -122,7 +122,7 @@ static void show_default(void)
show_rev(NORMAL, sha1, s);
return;
}
- show_arg(s);
+ show_norev(s);
}
}
@@ -149,7 +149,7 @@ int main(int argc, char **argv)
if (*arg == '-') {
if (!strcmp(arg, --)) {
show_default();
- if (revs_only)
+ if (revs_only || flags_only)
break;
as_is = 1;
}
-
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
Fix silly pathspec bug in git-ls-files
The verify_pathspec() function doesn't test for ending NUL character in the pathspec, causing some really funky and unexpected behaviour. It just happened to work in the cases I had tested. Signed-off-by: Linus Torvalds [EMAIL PROTECTED] --- diff --git a/ls-files.c b/ls-files.c --- a/ls-files.c +++ b/ls-files.c @@ -496,7 +496,7 @@ static void verify_pathspec(void) char c = n[i]; if (prev prev[i] != c) break; - if (c == '*' || c == '?') + if (!c || c == '*' || c == '?') break; if (c == '/') len = i+1; - 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: Automatic merge failed, fix up by hand
On Tue, 23 Aug 2005, Len Brown wrote: I'm having trouble using git for merging kernel trees. git seems to manufacture conflicts in files that I never touched, and on some files it completely throws up its arms, see Not handling case below. Cool. You've found a case where git-merge-base finds what appears to be two equally good merge candidates, but they really aren't. The merge candidates are 30e332f3307e9f7718490a706e5ce99f0d3a7b26 and 3edea4833a1efcd43e1dff082bc8001fdfe74b34. To see this graphically, do: echo 30e332f3307e9f7718490a706e5ce99f0d3a7b26 .git/refs/tags/selected-merge-base echo 3edea4833a1efcd43e1dff082bc8001fdfe74b34 .git/refs/tags/other-merge-base echo 81065e2f415af6c028eac13f481fb9e60a0b487b .git/refs/tags/linus-head echo 702c7e7626deeabb057b6f529167b65ec2eefbdb .git/refs/tags/lenb-head gitk --all and notice how the not-selected one is: Author: Antonino A. Daplas [EMAIL PROTECTED] 2005-08-15 06:29:11 Committer: Linus Torvalds [EMAIL PROTECTED] 2005-08-15 09:59:39 Tags: not-selected while the selected on is: Author: Luming Yu [EMAIL PROTECTED] 2005-08-11 21:31:00 Committer: Len Brown [EMAIL PROTECTED] 2005-08-15 12:46:58 Tags: selected and the reason we chose that one is that it's three hours later than the other one, and we don't know any better. Not clear how I got into this state -- probably something to do with adding commits on branches and them git-pull-branch'ing them into the master; combined with updating the master from-linus. No, it's git. Well, it's git, together with your propensity to merge old work, which causes this kind of confusion where there are two equally good points to choose from as the merge base, and git chose the wrong one because it _looked_ newer and there was a recent merge to an old version of my tree. Cross-merges cause this, but I'm sure there's a good algorithm for selecting _which_ of the two interesting commits to pick. Give me a moment to think about this. 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
Fix git-rev-parse breakage
The --flags cleanup caused problems: we used to depend on the fact that
revs_only magically suppressed flags, adn that assumption was broken by
the recent fixes.
It wasn't a good assumption in the first place, so instead of
re-introducing it, let's just get rid of it.
This makes --revs-only imply --no-flags.
[ Side note: we might want to get rid of these confusing two-way flags,
where some flags say only print xxx, and others say don't print yyy.
We'd be better off with just three flags that say print zzz, where zzz
is one of flags, revs, norevs ]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
diff --git a/rev-parse.c b/rev-parse.c
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -160,6 +160,7 @@ int main(int argc, char **argv)
}
if (!strcmp(arg, --revs-only)) {
revs_only = 1;
+ no_flags = 1;
continue;
}
if (!strcmp(arg, --no-revs)) {
-
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: baffled again
On Tue, 23 Aug 2005, Tony Luck wrote: So GIT decides that the test branch has had a patch, and the release branch hasn't ... and so it merges by keeping the version in test. Plausible? Very. Sounds like what happened. 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: Query about status of http-pull
On Wed, 24 Aug 2005, Junio C Hamano wrote: Added at the end of git-repack-script (Linus can disable it by giving an '-n' flag when packing his private repositories). No, I just haven't updated my git on master.kernel.org in a while. So nothing to disable. I ran git-update-server-info manually, so it should work now. 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: baffled again
On Wed, 24 Aug 2005, Linus Torvalds wrote: Basically, he had two branches, A and B, and both contained the same patch (but _not_ the same commit). One undid it, the other did not. There's no real way to say which one is correct, and both cases clearly merge perfectly, so both outcomes patch applied and patch reverted are really equally valid. In fact, the case that git selected (patch applied), is not only the one that is very fundamentally the one git will always select in this kind of situation - in some respects is actually the nicer choice of the two. While it may cause problems (ie the revert was the right thing to do), it's at least the state that is less likely to be lost. Having a revert disappear is likely better than having a real change disappear. The reaction to the reverted code showing up again is likely damn, won't that bug ever go away, I fixed it once already - but at least people will see that it's fair: it was applied twice, so let's revert it twice. In contrast, the reaction to a patch going away is likely just very confusing: you have two people applying it, but only one reverting it will revert both, while the first person who applied it may never have realized it got reverted. 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] undo and redo
On Wed, 24 Aug 2005, Carl Baldwin wrote: Oops. I forgot to actually exit from the script if git-diff-files is non-empty. Also, looking at it now, I don't think keeping undo information in a stack is the right thing. But keeping more than just one would be good. Oh well, my first shot is never perfect. ;-) I would actually argue that git checkout -b newbranch undo-point is the perfect undo. It leaves the old state in the old branch, and creates a new branch (and checks it out) with the state you want to revert to. The advantage is exactly that there is no stack of undo's: you can have multiple independent undo's pending, and you can continue development at any of them. And merge the results together. Of course, right now we don't have a delete branch command, but it's really as simple as rm .git/refs/heads/branchname (and eventually you may want to do a git prune to get rid of stale objects, but that's a separate issue). 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: Fix git-rev-parse breakage
On Wed, 24 Aug 2005, Junio C Hamano wrote: that is not a right thing so get rid of that assumption (which I agree is a good change, and the last sentense says opposite... Well, the patch makes it an _explicit_ assumption, instead of a very subtly hidden one from the code-flow. It was the non-obvious hidden assumption that caused the bug. Here is my thinking, requesting for a sanity check. * git-whatchanged wants to use it to tell rev-list arguments from rev-tree arguments. You _do_ want to pick --max-count=10 or --merge-order in this case, and --revs-only implying --no-flags would make this impossible. Fair enough. However, there are two kinds of flags: the revision flags, and the -p kind of flags. And the problem was that git-whatchanged -p didn't work any more, because we passed -p along to git-rev-list. Gaah. 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: Storing state in $GIT_DIR
On Fri, 26 Aug 2005, Martin Langhoff wrote: OTOH, storing the metadata in a branch will allow us to run the import in alternating repositories. But as Junio points out, unless I can guarantee that the metadata and the tree are in sync, I cannot trivially resume the import cycle from a new repo. But you can. Remember: the metadata is the pointers to the original git conversion, and objects are immutable. In other words, if you just have a last commit pointer in your meta-data, then git is _by_definition_ in sync. There's never anything to get out of sync, because objects aren't going to change. So you can think of your meta-data as a strange kind of head ref. Or rather, a _collection_ of these strange refs. And it doesn't matter if somebody ends up committing on top of an arch import. The metadata by definition doesn't know about it, so the import head doesn't move anywhere (if you do git and arch work in parallell, you can then merge the two heads with git, of course). 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, PATCH] A new merge algorithm (EXPERIMENTAL)
On Fri, 26 Aug 2005, Fredrik Kuivinen wrote: In real numbers it is as follows: In Linus' kernel tree there are 5996 commits. 400 of those have more than one parent. Of those 400 merge commits 4 have more than one shared head. Ok, that's already interesting in itself. I was wanting to re-run all the merges with the new git-merge-base -a to see which merges might have had different merge bases, and you've actually done that. Interesting to see the numbers. * Is it worth it? That is, is the added complexity in the merge logic worth the advantages of correctly handling some strange (but real life) merge cases? I am of two minds on this. I hate the notion of a more complex merge. But at the same time, it clearly is a very interesting case when we do have multiple possible shared parents, and I think that at the very least we should warn the user. And using a more complex merge algorithm when it happens seems to be a very valid thing to do. Also, it's possible that other developers see more of the criss-crossing merges than I do - iow, they're probably more likely to happen in the throw-away trees than in some of the main trees. Neither of the two cases we've seen and had issues were merges I did, for example. Which means that your 1% of all merges number is probably low. Of course, it's quite likely that in most cases, the pick either one approach will give the exact same result as the more complex merge. Using python, which people have less exposure to, sounds like an additional thorny issue.. 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: Comments in read-tree about #nALT
On Sat, 27 Aug 2005, Daniel Barkalow wrote: What I missed was that the effect of causes_df_conflict is to give no merge for the entry, rather than giving an error overall. So I do need an equivalent. Daniel, I'm not 100% sure what you're trying to do, but one thing that might work out is to just having multiple stage 3 entries with the same pathname. We current use 4 stages: - stage 0 is resolved - stage 1 is original - stage 2 is one branch - stage 3 is another branch But if we allowed duplicate entries per stage, I think we could easily just fold stage 2/3 into one stage, and just have n entries in stage 2. That would immediately mean that a three-way merge could be n way. The only rule would be that when you add a entry to stage 2, you must always add it after any previous entry that is already in stage 2. That should be easy. In fact, this extension might even allow us to solve the multiple merge base problem: we could allow multiple entries in stage 1 too, ie one entry per merge base (and just collapse identical entries - there's no ordering involved in stage 1 entries). So you could merge n trees with m bases, and all without really changing the current logic much at all. Maybe I'm missing something (like what you're trying to do in the first place), but this _seems_ doable. Of course, git-merge-one-file gets more interesting as a result. 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 6/9] New option --ignore-whitespace for git-apply.
On Sun, 28 Aug 2005, Robert Fitzsimons wrote: Allow the user to force a patch to be applied even though there might be whitespace differences. Added a test case for the new option. If you ignore whitespace, then you should probably accept patches that are whitespace corrupted in another way: lines missing the ' ' at the beginning. Especially lines that are empty. That's actually the most common form of whitespace corruption there is. 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] Spell __attribute__ correctly in cache.h.
On Sun, 28 Aug 2005, Jason Riedy wrote: I'm fine with requiring a limited C99 compiler. A pedantic compiler will reject members with a length of zero. 6.7.5.2 para1 requires a value greater than zero for a constant array size. So the code now (with [0] decls) is neither C89 nor C99. But using array[] means that sizeof() no longer works, and then you have to use offsetof(), which is a big pain. I think all relevant compilers end up accepting [0] (probably giving a warning, especially in some pedantic mode), since it's been how gcc users have been doing things for years (gcc was late to the [] syntax). 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] Spell __attribute__ correctly in cache.h.
On Sun, 28 Aug 2005, Antti-Juhani Kaijanaho wrote: This is not true under C99. If an array[] is the last member of a struct (which is what we are, AFAIK, talking about), then sizeof that struct is defined and gives the size of that struct as if the array's size were zero (but the struct cannot be used in an automatic context). Ahh, thanks. Mea culpa, I thought it was illegal in general. In that case, the only reason not to use [] is that older gcc's don't like it, but even that version cut-off may be old enough to not matter. Anybody know? gcc-2.95 is still considered production at least for the kernel. I don't have it available to test whether it understands [] though. 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: question git branches
On Mon, 29 Aug 2005, Ben Greear wrote: I think I'm missing something fundamental though... I wanted to change to the ben_dev_rfcnt branch to build a kernel without my additional patch. git branch ben_dev_rfcnt seems to change it fine, but all of the changes for repository 'foo' are also still here. git branch just creates the branch, it doesn't actually do anything else. Use git checkout branchname to switch to it. You can do both with bit checkout -b branchname which both creates the branch and switches to it. (Both git branch and git checkout -b branchname that reate a new branch take an optional argument which says what point you want the branch to start at. It defaults to current state, but you can create a branch at any point in the history by just explicitly stating the commit name that you want to start off with as the head of the branch) Use gitk --all to visualize where the different branches are in the history, and a plain git branch with no arguments to list the branches and mark your currently active branch. 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: cogito/git usage question
On Mon, 29 Aug 2005, Bryan O'Donoghue wrote: cg-tag-ls lists every version from 2.6.11 to the current 2.6.13 inclusive. cg-tag-ls also lists kernel version 2.6.13-rc6. What I'm wondering is how exactly I set copy of the tree to that version, so that I can apply the -mm patchset ? You need to start a new branch at the right point in time, and check it out. Let's call it bryan-mm, and then it looks something like this: git checkout -b bryan-mm v2.6.13-rc6 (mental footnote: pronounce it as git checkout new branch 'bryan-mm' at v2.6.13-rc3). [ You can also do the exact same thing by git branch bryan-mm v2.6.13-rc6 git checkout bryan-mm and it's entirely a matter of taste whether you usually want to create the branches first, and switch to them later, or create-and-switch in one go ] So then you can apply any -mm patches to that tree. If you want to merge the result (ie you want to have _both_ the -mm patches _and_ the changes from the final 2.6.13 release), you might want to create yet another branch so that you can easily switch between the different states, and then do a resolve: git checkout -b bryan-mm-merged git resolve HEAD v2.6.13 Merge 2.6.13-rc7-mm1 and final 2.6.13 which will hopefully have no conflicts, and commit the end result. If it did have conflicts, you'll have to fix it up by hand (all the normal markers from CVS: one side = other side ), and then commit it by hand with git commit --all. [ Notice how in this second git checkout -b we only gave the new branch name, not where to start. That's because we just wanted to start from the same point where we already were in in the original bryan-mm branch ] Finally, use gitk --all to get a better mental visualization for what the hell you just did. I keep repeating that command, because just doing the commands may not give you the same understanding of what actually happened, but gitk --all is really good for visualizing what's up (less so when the branches aren't close to each other, but still..) And then you can switch between the different branches with just a simple git checkout branch and off you go. 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: please pull ppc64-2.6.git
On Mon, 29 Aug 2005, Paul Mackerras wrote: Please do a pull from: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/paulus/ppc64-2.6.git Gaah. This is not a valid git repository. Guys, if you do partially populated repositories, _please_ make sure that you still make it a valid git repository. These days you can trivially do so by doing a echo /pub/scm/linux/kernel/git/torvalds/linux-2.6/objects objects/info/alternates or similar. That also makes gitweb able to show diffs etc, something it can't do for a broken partial repository. Not pulled, 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: please pull ppc64-2.6.git
On Mon, 29 Aug 2005, Russell King wrote: Is the expected filesystem layout documented somewhere online (_external_ to the source code) ? Nope, I don't think so. Alternatively, when changes occur to the repostory format, please can they be marked with some obvious subject so that folk know when things are going to break? The only actual filesystem _breakage_ has been the introduction of pack-files (and the old, old _old_ thing where I changed the actual object compression/hashing order). The objects/info/alternates thing is an extension, which allows you to have a partial object store, and point to the rest of it, and still have all the tools understand it and be able to parse the totality of it. So it doesn't break or change old formats, it only allows a new one. (Partial repos have always worked with the rsync protocol, and with the client-side pulling. But that was more of an accident than anything else, and they fundamentally were broken for any real work - gitweb can't show anything really sane, server-side serving - whether anonymous or ssh - doesn't work, etc etc). 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: cogito/git usage question
On Mon, 29 Aug 2005, Bryan O'Donoghue wrote: If I'm understanding, I update to a given git repository, branch locally based on tags and then I can checkout a branch locally, to make that the active branch. Exactly. This is the difference between a tag and a branch: a tag is an immobile point in time, while branches are heads of active development (there's a bit more detail to this: you _can_ change a tag, so it's not like it's totally fixed in stone, but the point is that it's not a dynamic entity - it's some fairly static thing that you've protected). So you can't start new development off a tag directly: you need to create a new branch that just starts off at the point that the tag points to. So if you really think of a branch as that head of active development and tags as static points in time this all makes tons of sense. Btw, you don't need to branch based on tags: you can branch based of _any_ kind of local reference. A tag is just a common one. But you can branch based on your current state too, ie a command line like git branch -b fixup HEAD^ means that you will create a fixup branch that starts not at a tag, but at the parent of HEAD. In particular, let's say that you just committed something, and realized that you need to work on something else without the new thing disturbing you (you have a patch that applies in the same area, or whatever), something like the above works fine. Or just use gitk to visually find a place, and when you decide to start a new branch somewhere, select that commit in gitk, and use the cut-and-paste facility to just paste the SHA1 directly into git branch -b working any-random-point-sha1 so it's not like the tags are important per se, they're just short-hand symbolc way-markers. 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: please pull ppc64-2.6.git
On Tue, 30 Aug 2005, Paul Mackerras wrote: What can one put in the alternates file? Just an absolute path, or does a relative path or a URL work too? Only an absolute path. URL's fundamentally do not work, and relative paths end up being parsed as relative to where-ever the user happens to be (and some commands will chdir() into the .git directory, while others will not). For a raw git directory like the ones on master.kernel.org, with a relative pathname (relative to the main git directory itself) the _pulling_ should actually happen to work, since that will be happening in the xxx.git directory using GIT_DIR=.. But anything who uses GIT_DIR=something else from another directory wouldn't be able to use it. That probably includes gitweb, btw. So only do the absolute ones. Maybe we should define some well-specified meaning for relative ones, but it definitely isn't there now. or similar. That also makes gitweb able to show diffs etc, something it can't do for a broken partial repository. Gitweb still doesn't work; I think someone needs to update the git on *.kernel.org. Hmm, yes. kernel.org is at 0.99.4, and the objects/info/alternates thing was done after that. It's in 0.99.5, though, so next time kernel.org updates its git version, it will automagically start working. (And I use my own git installation, so it works fine for me, and I just pulled the thing without problems). 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 1/9] Fix git patch header processing in git-apply.
On Mon, 29 Aug 2005, Robert Fitzsimons wrote: I should have mentioned before, these changes are being used in a SourcePuller dump file to git import script I've been working on. Hmm. Anything that depends on --ignore-applied is fundamentally broken as an import tool. There's no way something like that can be valid, since it inhently means that somebody is trying to apply a patch that simple isn't applicable. So it seems like you're trying to work around some other serious problems in the import, and as a result the import is clearly not trustworthy. Don't do this. 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: Comments in read-tree about #nALT
On Mon, 29 Aug 2005, Junio C Hamano wrote: But if we allowed duplicate entries per stage, I think we could easily just fold stage 2/3 into one stage, and just have n entries in stage 2. That would immediately mean that a three-way merge could be n way. I suspect you are solving a different problem here --- an Octopus. Well, that too, but I did mention doing the same thing for stage 1, which is the multiple merge bases case. It all boils down to the same thing: we want to read in multiple trees, and then do merges one file at a time based on the result (and the fact that we can have multiple entries for files in the different stages essentially just complicates git-merge-one-file). But I agree that the current way of doing things in stage 2 and stage 3 is special casing two head merges from an Octopus, and there might not be a fundamental reason for doing so. Folding the current stage 2 and 3 into a single merge target stage, Daniel pointed out that there is a real reason for stage 2 - it's used as a special case for matches current index. Apart from that, it's the same as stage 3. Stage 3 is the one we can duplicate freely. There's can be only one branch that is special in that it matches the current index, so expanding stage 3 from one to many is clearly something where all the different trees are on equal footing. Same goes for stage 1 - all merge bases are conceptually equally valid, and thus there is no reason to consider any ordering between them, and you can merge any number of trees into stage 1. So stage 0 and stage 2 are special in that they inherently have one special tree that they correspond to. 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 1/9] Fix git patch header processing in git-apply.
On Mon, 29 Aug 2005, Junio C Hamano wrote: The code is simple enough and I see some beauty in it, but I honor your veto, at least for now. Well, I didn't actually veto it when I saw the feature the first time, because I think it's a valid thing to do when applying patches by hand. It was only when I realized that Robert was trying to use it to import from somewhere else that it became broken. An import should use the most anal patches possible. Actually, an import should preferably never use patches at all, since that never really works for binary data. This is why the CVS importer actually checks out full files and imports them that way. The patch-based ones will fundamentally always have problems. 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] Documentation for git-daemon.
On Mon, 29 Aug 2005, A Large Angry SCM wrote: Signed-off-by: [EMAIL PROTECTED] Btw, I enjoy your email address and name, but especially with something that is supposed to hopefully have some legal value down the line if somebody starts making SCO noises, it really would be nice to have a real person to associate things with.. It would be embarrassing later if there is no way to even look you up somehow. If you don't want your realname/affiliation to be public/official, maybe you could at least let people know in private? 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
Fix bisection terminating condition
When testing bisection and using gitk to visualize the result, it was
obvious that the termination condition was broken.
We know what the bad entry is only when the bisection ends up telling us
to test the known-bad entry again.
Also, add a safety net: if somebody marks as good something that includes
the known-bad point, we now notice and complain, instead of writing an
empty revision to the new bisection branch.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
diff --git a/git-bisect-script b/git-bisect-script
--- a/git-bisect-script
+++ b/git-bisect-script
@@ -105,12 +105,16 @@ bisect_next() {
good=$(git-rev-parse --sq --revs-only --not \
$(cd $GIT_DIR ls refs/bisect/good-*))
rev=$(eval git-rev-list --bisect $good $bad) || exit
- nr=$(eval git-rev-list $rev $good | wc -l) || exit
- if [ $nr -le 1 ]; then
+ if [ -z $rev ]; then
+ echo $bad was both good and bad
+ exit 1
+ fi
+ if [ $rev = $bad ]; then
echo $rev is first bad commit
git-diff-tree --pretty $rev
exit 0
fi
+ nr=$(eval git-rev-list $rev $good | wc -l) || exit
echo Bisecting: $nr revisions left to test after this
echo $rev $GIT_DIR/refs/heads/new-bisect
git checkout new-bisect || exit
-
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
Ugly git pull .. merge messages
Junio, I think this happened when you rewrote the pull/push stuff to do shorthands.. Lately, git pull generates a lot of extra crud in the single-line commit message, which is annoying because a lot of tools will thus actually not show enough of the line to be valid. For example, it used to get rid of the .git at the end, and it didn't bother to say HEAD. So Merge HEAD from master.kernel.org:/home/rmk/linux-2.6-arm.git used to be just Merge master.kernel.org:/home/rmk/linux-2.6-arm which is actually much nicer. It tends to fit in the gitk description window. In this example: Merge refs/heads/release from master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6 I had manually removed the .git (since git-fetch-pack will happily add it back), so it doesn't have the .git at the end of the message, but instead it has a ref-name that is the internal git path rather than the path that I actually specified. Now, we didn't use to be shorter, but at least it used to be more readable, with Merge 'release' branch of master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6 (Ok, it's slightly shorter, but not much - but my point is that it's actually more readable). Could we get the nicer messages back, please? 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: empty patch-2.6.13-git? patches on ftp.kernel.org
On Fri, 2 Sep 2005, David Woodhouse wrote: rm -rf tmp-empty-tree mkdir -p tmp-empty-tree/.git cd tmp-empty-tree Ahh. Please change that to rm -rf tmp-empty-tree mkdir tmp-empty-tree cd tmp-empty-tree git-init-db because otherwise you'll almost certainly hit something else later on.. 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: Moved files and merges
On Mon, 5 Sep 2005, H. Peter Anvin wrote: It would also hade the somewhat interesting possibility that one could remove and recreate a file and have it exist as a different entity. That probably needs to be a user option. It's a totally broken model. Really. You think it solves issues, but it just creates more bugs and problems than it solves. Trust me. The whole point of git is that content is the only thing that matters, and that there isn't any other meta-data. If you break that fundamental assumption, everything git does so well will break. I think we've already shown that the content matters approach works. I claim that the git rename tracking works better than any other SCM out there, _exactly_ because it doesn't make the mistake of trying to track anything but content. The moved + modified files is not anything special. The current automatic merger may not handle it, but that's not because it _can't_ handle it, it's because it tries to be simple and efficient. And because it's so _incredibly_ fast for all the normal cases, you can now spend some effort on figuring out renames dynamically for the few cases where it fails. Does it do so now? No. Would adding UUID's help? Hell no. It would be just an unmitigated disaster. Exactly the same way git-diff-tree can figure out renames, a merge algorithm can figure them out. Right now, we have two stages in merges: we try the trivial merge first (pure git-read-tree), and when that fails, we try the automatic 3-way merge. The fact that we don't have a third (and fourth, and fifth) merge algorithm for when those two trivial merges happen to not work is _not_ an indication that the contents only approach doesn't work - it's just an indication of the fact that 99.9% of all merges are trivial, and they should be optimized for. So the next step is _not_ to do UUID's, it's to notice that merge errors happened, and try to figure out why. Right now we just give up and say sort it out by hand. That's actually a perfectly valid approach even in the presense of moved files - it's a bit painful, but once you _do_ sort it out and commit the merge, especially if you can push the merge back (so that both sides then agree on the final rename), future merges will be trivial again - ie you won't have to go through it over and over again. Of course, if you don't push it back, but keep the two trees separate and keep on modifying files that have different names in the other repository, you'll keep on getting into the situation that the trivial merge doesn't work. So we _do_ want to get an automated phase 3 (and maybe 4..) merge that can figure out renames, but the point here is that it's something we _can_ figure out. For example, one way of doing it is to just do the exact merge we do now, and then look at the files that didn't merge. Do a cross-diff between such files and new/deleted files (if not _exactly_ the way we do for git diff -M, then at least it's exactly the same concept), and try to do a three-way merge where the base/first/second pairs don't have the same name. For example, let's say that you have the common commit A, and file x, and two paths (B and C) where B has renamed the file x to y, and C has modified file x. You end up with the schenario that our trivial merge fails to handle, and right now we give up, and don't help the user very much at all. But the _solution_ is not to change read-tree to know about renames, nor is it to make git keep any new data. The solution is to just make phase 3 say: - Automatic merge failed, trying rename merge - go through all files that exist in C but not in B (or vice versa), and pair them up with all files that exist in B but not in C (or vice versa) and see if _they_ can be handled as a three-way merge. And exactly the same way that we do the rename detection, we may want to find the optimal pairing by looking at the distance between the files. Notice? This will automatically handle the renamed in one branch, modified in another case. In fact, if the renamer modified it too, that's not a problem at all - the three-way merge will work exactly the same way it does now with the case of a non-moved modified in both files. Problem solved. Without complicating the trivial (and very common) cases, and without introducing any new metadata that is fundamentally impossible to maintain (and it _is_ fundamentally impossible to maintain, because it has nothing to do with the contents of the files, so patches etc will by definition break it). 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
