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-s
Re: Fix interesting git-rev-list corner case
On Sat, 30 Jul 2005, Peter Osterlund wrote: > > OK, but note that I didn't do any editing of any local files myself. > Both commit ids are from your public linux kernel git tree. What I did > was equivalent to: > > 1. rsync from > rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ > 2. waited a day or so. > 3. git-pull-script from the same kernel.org repository. > > Is it expected that you end up with merge conflicts in this case? Nope. Something went wrong. > I think it should be possible to just fast forward to the new HEAD in > this situation. Indeed. Can you send me your HEAD and MERGE_HEAD (don't do the merge). Sounds like maybe "git-merge-base" is confused, and thinks HEAD is not reachable from FETCH_HEAD. It could have a similar bug git-rev-list 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: 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: Fix interesting git-rev-list corner case
On Sat, 30 Jul 2005, Linus Torvalds wrote:
>
> Yup, it's git-merge-base, and it is confused by the same thing that
> confused git-rev-list.
>
> Thanks, I'll fix it.
Hmm.. Here's a tentative fix. I'm not really happy with it, and maybe
somebody else can come up with a better one. I think this one ends up
being quite a bit more expensive than the old one (it will look up _all_
common parents that have a child that isn't common, and then select the
newest one of the bunch), but I haven't really thought it through very
much.
I bet there is a smarter way to do this, but this _should_ fix the problem
Peter sees. Peter?
Linus
---
diff --git a/merge-base.c b/merge-base.c
--- a/merge-base.c
+++ b/merge-base.c
@@ -2,54 +2,50 @@
#include "cache.h"
#include "commit.h"
-static struct commit *process_list(struct commit_list **list_p, int this_mark,
- int other_mark)
-{
- struct commit *item = (*list_p)->item;
-
- if (item->object.flags & other_mark) {
- return item;
- } else {
- pop_most_recent_commit(list_p, this_mark);
- }
- return NULL;
-}
-
static struct commit *common_ancestor(struct commit *rev1, struct commit *rev2)
{
- struct commit_list *rev1list = NULL;
- struct commit_list *rev2list = NULL;
+ struct commit_list *list = NULL;
+ struct commit_list *result = NULL;
- commit_list_insert(rev1, &rev1list);
- rev1->object.flags |= 0x1;
- commit_list_insert(rev2, &rev2list);
- rev2->object.flags |= 0x2;
+ if (rev1 == rev2)
+ return rev1;
parse_commit(rev1);
parse_commit(rev2);
- while (rev1list || rev2list) {
- struct commit *ret;
- if (!rev1list) {
- // process 2
- ret = process_list(&rev2list, 0x2, 0x1);
- } else if (!rev2list) {
- // process 1
- ret = process_list(&rev1list, 0x1, 0x2);
- } else if (rev1list->item->date < rev2list->item->date) {
- // process 2
- ret = process_list(&rev2list, 0x2, 0x1);
- } else {
- // process 1
- ret = process_list(&rev1list, 0x1, 0x2);
+ rev1->object.flags |= 1;
+ rev2->object.flags |= 2;
+ insert_by_date(rev1, &list);
+ insert_by_date(rev2, &list);
+
+ while (list) {
+ struct commit *commit = list->item;
+ struct commit_list *tmp = list, *parents;
+ int flags = commit->object.flags & 3;
+
+ list = list->next;
+ free(tmp);
+ switch (flags) {
+ case 3:
+ insert_by_date(commit, &result);
+ continue;
+ case 0:
+ die("git-merge-base: commit without either parent?");
}
- if (ret) {
- free_commit_list(rev1list);
- free_commit_list(rev2list);
- return ret;
+ parents = commit->parents;
+ while (parents) {
+ struct commit *p = parents->item;
+ parents = parents->next;
+ if ((p->object.flags & flags) == flags)
+ continue;
+ parse_commit(p);
+ p->object.flags |= flags;
+ insert_by_date(p, &list);
}
}
- return NULL;
+ if (!result)
+ return NULL;
+ return result->item;
}
int main(int argc, char **argv)
@@ -64,6 +60,8 @@ int main(int argc, char **argv)
}
rev1 = lookup_commit_reference(rev1key);
rev2 = lookup_commit_reference(rev2key);
+ if (!rev1 || !rev2)
+ return 1;
ret = common_ancestor(rev1, rev2);
if (!ret)
return 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: [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: Fix interesting git-rev-list corner case
On Sat, 31 Jul 2005, Peter Osterlund wrote: > > > I bet there is a smarter way to do this, but this _should_ fix the problem > > Peter sees. Peter? > > Yes, it does fix the problem. Thanks. Ok, Junio, can you apply the git-merge-base patch? It's not perfect, but it's clearly better than what's there right now. Add a "Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>" and edit the description a bit, perhaps. 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: [PATCH] Added hook in git-receive-pack
On Sun, 31 Jul 2005, Junio C Hamano wrote: > > You are absolutely right. It should grab some sort of lock > while it does its thing (would fcntl(F_GETLK) be acceptable to > networked filesystem folks?). There is no lock that works reliably except for the "create a directory and rename it onto another directory" Please do it in the hook layer. > I have one question regarding the hooks. We seem to prefer > avoiding system and roll our own. Is there a particular reason, > other than bypassing the need to quote parameters for shell? Hmm.. I suspect it's partly just because there is existing code that does the fork()/exec() thing because it needs to do IO, and system() doesn't close the right pipes after fork etc. "system()" really is very inflexible. It basically never works if you have any shared file descriptors. 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 Sun, 31 Jul 2005, Andrew Morton wrote: > > So I finally decided to take a look at my git problems. Discovered I > couldn't fix them with zero git knowledge :( Heh. We're here to please. I'll cc the git list too, because there really _are_ a lot of people out there that know it fairly well, and may even have better suggestions than I do. > What I want to do is to pull zillions of people's git trees into one repo > and then run some magic command to give me unified diffs from everyone's > trees which will apply to your latest. Absolutely. Here's how to do it: - start off by fetching every single tree you want to have into its own local branch. I think you basically do this already. If you're using cogito, I think a simple "cg-pull" will do it for you. If you are using raw git, the easiest thing to do is to really just do result=$(git-fetch-pack "$repo" "$head") || exit which will fetch the named "head" from the named "repo", and stuff the result in the "result" variable. You can then stuff that result anywhere, so for example, if you pull _my_ repostiry, you could then name the result "linus-tree" by just doing echo $result > .git/refs/heads/linus-tree and it really is that easy. So just do this for all the repos you want to pull, so that you have heads in the same tree, names however you wish (it the head naming _you_ have in your tree do not necessarily have anything at all to do with the head naming in the heads in the trees the data came from. In fact, that's very important, because there can be multiple HEAD or "master" source branches, of course, and you need to make _your_ heads be unique). - second phase is to select some kind of order for these things, and just start merging. Start off with a known base, and for each tree you merge it against the previous merge, and then just generate the diff against the previous merge. Now, one downside is that the current "git resolve" will _always_ resolve into HEAD, which is admittedly a bit of a bummer: you can't resolve into a totally temporary tree, which is what your usage might want. This might be something git could do better for you, but the upside is that "git resolve" will always leave the previous tree in ORIG_HEAD, and since you really need to generate a temporary branch for all your merges anyway, you might as well just do exactly that, and switch to it before you start the merge process. Anyway, this example script will jusy always create a temporary branch called "merge-branch" that starts at whatever point you use as your base. Not a biggie. You can choose whatever as your starting point, I'm just assuming that it's the "master" branch, and that you'd keep (for example) my last release in there as the base. But if you want to keep the result of your quilt stuff, that should be doable too, for example. I'm _assuming_ that you'd do the git merge diffs first, and then do the quilt stuff on top of the result, but there's nothing really that forces that order. So it should literally be as simple as something like this: # # Start off from "master", create a new branch "merge-branch" # off that state. # 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 # # # For each tree you want to merge, just do so.. # # This also decides the order of the patches # for i in linus-tree davem-net-tree davem-sparc-tree ... do git resolve HEAD $i "Merging $i" if [ "$?" -ne 0 ]; then echo "Automatic resolve failed, skipping $i" >&2 # # Revert back to previous state, we're not going # to do any manual fixups here. # git checkout -f else # # Yay! The resolve worked, let's just diff what # it did and continue onward from here # git diff ORIG_HEAD.. > merge-diff-$i fi done # # Finally, just switch back to "master", throw away all the work # we did (the objects will stay around, but you can do a # # git prune # # once a week to get rid of the temporary objects. Don't do it # here, it's too expensive and there's no real point). # git checkout -f master rm .git/refs/heads/merge-branch and you're hopefully done. It really _should_ be that easy. The above will leave you with a series of diffs called merge-diff-linus-tree
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: Users of git-check-files?
On Wed, 3 Aug 2005, Johannes Schindelin wrote: > > there's git-check-files in the repository, but AFAIK nobody uses it, not > even "git status", which would be the primary candidate. If really no > users of git-check-files exist, maybe we should remove it? Yes. It was used by the old "git-applymbox" (aka "dotest") until I got around writing "git-apply". It has no point any more, all the tools check the file status on their own, and yes, the thing should probably be removed. 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] list shortlog items in commit order
On Tue, 2 Aug 2005, Jeff Garzik wrote: > > 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 Tue, 2 Aug 2005, Junio C Hamano wrote: > > How about git-rev-tree? Does anybody care? Yeah, probably not. git-rev-list does so much more than git-rev-tree ever did. 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: > > > I've lost that state. Can you explain a bit mroe.. > > Sorry, you have not lost anything. It is my bad that this is > the first time I brought it up. I've been seeing that from time > to time when I push to either my "send to master" repository > from my working repository, or from the "send to master" > repository to master.kernel.org, but I haven't figured it out if > there is any pattern. Are you sure you have a good git version on master? I've never seen anything like that, and I push all the time.. 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
Very limited pathspec wildcards..
I ended up looking at wildcards in pathspecs, but wasn't quite ready
enough to pay the price of real wildcards. This limited form is the end
result.
It allows a final '*' in the path matching to indicate that we don't care
about the "match exact files/subdirectories only" rule.
So while
git-whatchanged git
will only show the file called "git" (or any changes under a subdirectory
called "git"),
git-whatchanged git*
will show anything that starts with "git".
Note that this _only_ works at the very end. You can't say
git-whatchanged git-*-script
even though maybe it would be good if we allowed full wildcards some day.
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---
Btw, I'm not sure this is a wonderful idea. I found it useful for doing
git-whatchanged -p drivers/scsi/aic7xxx/aic79xx*
since I was interested in seeign if only that particular driver had had
changes. But it's hacky and pretty limited, so I throw this patch out more
as a "maybe others think it is a good idea" thing.
So Junio, if you feel this is ugly, just drop it, I certainly won't mind.
As it is you can't even escape the '*', so if you actually only want to
match a filename that literally ends in an asterisk, this makes that
impossible, and will match that file _and_ anything that shares the same
prefix..
diff --git a/diff-tree.c b/diff-tree.c
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -163,6 +163,12 @@ static int interesting(void *tree, unsig
for (i=0; i < nr_paths; i++) {
const char *match = paths[i];
int matchlen = pathlens[i];
+ int wildcard = 0;
+
+ if (matchlen && match[matchlen-1] == '*') {
+ matchlen--;
+ wildcard = 1;
+ }
if (baselen >= matchlen) {
/* If it doesn't match, move along... */
@@ -183,7 +189,7 @@ static int interesting(void *tree, unsig
if (pathlen > matchlen)
continue;
- if (matchlen > pathlen) {
+ if (!wildcard && matchlen > pathlen) {
if (match[pathlen] != '/')
continue;
if (!S_ISDIR(mode))
diff --git a/read-cache.c b/read-cache.c
--- a/read-cache.c
+++ b/read-cache.c
@@ -183,10 +183,17 @@ int ce_path_match(const struct cache_ent
name = ce->name;
while ((match = *pathspec++) != NULL) {
int matchlen = strlen(match);
+ int wildcard = 0;
+ if (matchlen && match[matchlen-1]) {
+ matchlen--;
+ wildcard = 1;
+ }
if (matchlen > len)
continue;
if (memcmp(name, match, matchlen))
continue;
+ if (wildcard)
+ return 1;
if (matchlen && name[matchlen-1] == '/')
return 1;
if (name[matchlen] == '/' || !name[matchlen])
-
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: > > I think in addition to the existing ref_newer() check, which > makes sure you are advancing the remote head, not just replacing > with something unrelated, making sure that we have objects > referenced by ref->old_sha1 we obtained from the remote on our > end for all branches involved would be the only thing needed. Yes. 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: > > I try to write a "git annotate" based on the output of git-whatchanged. You can't. It's fundamentally not doable, because you lose the merge information. So you need to use a combination of git-rev-list _and_ git-whatchanged. Use the "--parents" flag to git-rev-list to get the parents output for doing your own graph, if you want to. I have been thinking of adding a "follow this file" mode to git-rev-list, which just ignores all children of merges that used the file directly from one of the other children. Exactly because then you could have a git-rev-list that prunes based on filename, and would potentially be a lot more efficient (not follow the "uninteresting" side of a merge). I haven't gotten around to it, partly because I wonder if it would be better as a separate program - even if that would mean that you'd lose all the cool features of git-rev-list (the ability to limit it to certain versions, and the ability to sort the output in relevant orders). Partly because I'm just too friggin lazy. > P.S.: My only unsolved problem is that git-whatchanged sometimes shows > the diffs in the wrong order (clock-skew problem?) Nope, this is a direct result of two branches modifying the same file in parallel. There is no "right" or "wrong" order. 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: > > This allows git-send-pack to push local refs to a destination > repository under different names. Looks good, except I was almost hoping for one modification: > Here is the name mapping rules for refs. > > * If there is no ref mapping on the command line: > > - if '--all' is specified, it is equivalent to specifying > ":" for all the existing local refs on the >command line > - otherwise, it is equivalent to specifying ":" for >all the refs that exist on both sides. > > * is just a shorthand for ":" > > * ":" > > push ref that matches to ref that matches . In this format, "src" makes sense as a generic sha1_name, and _not_ necessarily limited to a ref-name. IOW, there's really no reason to not allow git-send-pack .. dest .. :dst-ref where "" may be something else than a ref (but a ref obviously ends up being one such thing). For example, let's say that I've got stuff at the HEAD of my tree that I'm not quite ready to push out yet, but I _do_ want to push out the parent of the current head. I'd love to be able to just do git-send-pack parent $(git-rev-parse HEAD^):master and there's no real reason why that syntax shouldn't just work: it's entirely logical to say "I want to push out the parent of my HEAD as 'master' on the other end", and that's _exactly_ what the above says. So: > - It is an error if does not match exactly one of local > refs. I think "src" should just be seen as any random SHA1 name, and we should use "get_sha()" to convert it to a SHA1. In contrast, "dst" is obviously a real ref name, and as such: > - It is an error if matches more than one remote refs. makes sense. That makes your next rule a bit iffy, though: > - If does not match any remote refs, either > > - it has to start with "refs/"; is used as the > destination literally in this case. > > - == and the ref that matched the must not > exist in the set of remote refs; the ref matched > locally is used as the name of the destination. since "src" from a local standpoint isn't really a ref-name at all. But hey, your current patch looks fine already. It doesn't _quite_ do what I had in mind, but it gets very very close. 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: > > > git-send-pack parent $(git-rev-parse HEAD^):master > > When I do something like your example, I create a temporary > lightweight tag and push it. Snapshots in JIT are just a bunch > of lightweight tags so.. I like the scripting, and combining pipelines of commands kind of thing. I agree that you can just make a temporary tag, but it's a bit like in any scripting stuff - you could use a temp-file, but it's just cleaner if you can keep temporary values in local variables (or in a local cmd pipeline like the above). Whenever you script somethign that creates a new tag or ref, you suddenly have cleanup and uniqueness issues 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: [PATCH] (preview) Renaming push.
On Wed, 3 Aug 2005, Junio C Hamano wrote: > > While I have not updated the send-pack : 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.
Mommy, mommy, can you make my life easier
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 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..)
Mommy, mommy, plase
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 comm
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, Kay Sievers wrote: > > Damn cool? No problem. :) > > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=403fe5ae57c831968c3dbbaba291ae825a1c5aaa Goodie. Although when I looked at it first, it wasn't obvious - the link is same font, same color as the rest. Maybe make them stand out a _bit_ more? But yes, works well. Thanks, 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 { %W configure -cursor hand2 }
+$ctext tag bind link { %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: use of temporary refs in resolve
On Sun, 7 Aug 2005, Junio C Hamano wrote: > > How about LAST_MERGE? I don't think it matters. I kind of saw it as the "other side" of ORIG_HEAD, but since we now clean it up and since I've never used it, I think it falls under the status of "well-intentioned but useless". 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 "parent information" in commit window
This adds a useful "Parent:" line to the git commit information window.
It looks something like this (from the infamous octopus merge):
Author: Junio C Hamano <[EMAIL PROTECTED]> 2005-05-05 16:16:54
Committer: Junio C Hamano <[EMAIL PROTECTED]> 2005-05-05 16:16:54
Parent: fc54a9c30ccad3fde5890d2c0ca2e2acc0848fbc (Update
git-apply-patch-script ...)
Parent: 9e30dd7c0ecc9f10372f31539d0122db97418353 (Make
git-prune-script executa ...)
Parent: c4b83e618f1df7d8ecc9392fa40e5bebccbe6b5a (Do not write out new
index if ...)
Parent: 660265909fc178581ef327076716dfd3550e6e7b (diff-cache shows
differences ...)
Parent: b28858bf65d4fd6d8bb070865518ec43817fe7f3 (Update diff engine
for symlin ...)
Octopus merge of the following five patches.
Update git-apply-patch-script for symbolic links.
Make git-prune-script executable again.
Do not write out new index if nothing has changed.
diff-cache shows differences for unmerged paths without --cache.
Update diff engine for symlinks stored in the cache.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
where all the parent commit ID's are clickable, because the new lines are
added as part of the "comment" string, and thus the regular clickability
thing will match them automatically.
I think this is good. And my random-tcl-monkey-skills are clearly getting
better (although it's perfectly possible that somebody who actually knows
what he is doing would have done things differently).
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---
[ Btw, the patch was generated against a tree that had Paul's hovering
patches merged. Junio, I don't think you've merged that yet, so this may
apply better to Paul's tree than to standard git. But I _think_ it will
apply cleanly to either one ]
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -1799,9 +1799,21 @@ proc selectline {l isnew} {
}
$ctext insert end "\n"
}
-$ctext insert end "\n"
+
set commentstart [$ctext index "end - 1c"]
-set comment [lindex $info 5]
+set comment {}
+foreach p $parents($id) {
+ set l "..."
+ if {[info exists commitinfo($p)]} {
+ set l [lindex $commitinfo($p) 0]
+ if {[string length $l] > 32} {
+ set l "[string range $l 0 28] ..."
+ }
+ }
+ append comment "Parent: $p ($l)\n"
+}
+append comment "\n"
+append comment [lindex $info 5]
$ctext insert end $comment
$ctext insert end "\n"
-
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 revert" (Re: pci_update_resource() getting called on sparc64)
Comments? Linus On Mon, 8 Aug 2005, Linus Torvalds wrote: > > > On Mon, 8 Aug 2005, Greg KH wrote: > > > > Hm, how do you revert a git patch? > > Something like this? > > #!/bin/sh > . git-sh-setup-script || die "Not a git archive" > rev=$(git-rev-parse --verify --revs-only "$@") || exit > git-diff-tree -R -p $rev | git-apply --index && > echo "Revert $rev" | git commit > > Just name it "git-revert-script" and it might do what you want to do. > > It may not have the nicest error messages: if you try to revert a merge > (which won't have a diff), git-apply will say something like > > fatal: No changes > > which isn't exactly being helpful. And the revert message could be made > more interesting (like putting the first line of the description of what > we reverted into the message instead of just the revision number). > > 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 revert" (Re: pci_update_resource() getting called on sparc64)
On Mon, 8 Aug 2005, Junio C Hamano wrote: > > Totally untested. I acquired your habit of coding in my e-mail > client ;-). Looks good. Although I also have this advanced testing habit of just reading the email and if it looks sane it tested out ok ;) But it strikes me that we could use the "-M" flag to git-diff-tree, which makes it a lot more likely that we can revert renames, even if the file has been slightly changed afterwards. 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 revert" (Re: pci_update_resource() getting called on sparc64)
On Mon, 8 Aug 2005, Junio C Hamano wrote: > > * git commit does not take commit message from stdin. I think >we should do something like this: Yes. Alteratively (or additionally), we should add a command line option to set the commit message. CVS uses "-m", but you already took that. I forget what BK used, but I think it was "-Y" (with lowercase "-y" being "take message from file". Or maybe the other way around). Or if you want to be more CVS-like, use "-F", and accept "-" for stdin? But I like "test -t 0" regardless. Very few editors are ok with non-tty stdin, although I could imagine some disturbed individual having "ed" as their editor and expecting to be able to pipe commands into it 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: git-commit-script, was Re: "git revert" (Re: pci_update_resource() getting called on sparc64)
On Mon, 8 Aug 2005, Junio C Hamano wrote: > > Sure, what's the alternative spelling for the current -m, > though? Would -c be OK for commit? How about using long names? git commit --reuse-message looks a lot more intuitively understandable to me than something like "-c" Most of us don't use 300bps terminals any more, so typing a few extra characters is probably ok. Now, to make things be backwards-compatible, it should be easy enough to notice "Oh, the argument to '-m' is just a single SHA1, let's see if it's a commit, and turn '-m' into '--reuse-message' automatically" If anybody cares. Does cogito already use "-m"? 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: Make git-rev-tree obsolete
On Tue, 9 Aug 2005, Johannes Schindelin wrote:
>
> Junio remarked that Jeff's git-changes-script still uses git-rev-tree, and
> therefore it should not be removed. This patch changes git-changes-script
> over to git-rev-list:
It really should be totally rewritten, to take advantage of git-rev-list
being able to terminate early. As it is, your conversion may work, and it
may give the right results, but it will suck performance-wise for all the
same reasons that git-rev-tree sucked: it will walk all the way down to
the root of the tree(s).
> --- git-changes-script.orig Tue Aug 9 02:21:36 2005
> +++ git-changes-scriptTue Aug 9 02:20:53 2005
> @@ -85,14 +85,14 @@
> base=$(cat .git/HEAD) || exit 1
> fi
>
> -git-rev-tree $base | sort -rn > ${tmpfile}.base
> +git-rev-list $base > ${tmpfile}.base
> if [ -n "$remote" ]; then
> [ -d $remote/.git ] || exit 1
> if [ -z "$tobase" ]; then
> tobase=$(cat $remote/.git/HEAD) || exit 1
> fi
> pushd $remote > /dev/null
> - git-rev-tree $tobase | sort -rn > ${tmpfile}.remote
> + git-rev-list $tobase > ${tmpfile}.remote
> diff -u ${tmpfile}.base ${tmpfile}.remote | grep
> "^${diffsearch}[^${diffsearch}]" | cut -c 1- > ${tmpfile}.diff
> rm -f ${tmpfile}.base ${tmpfile}.remote
> mv ${tmpfile}.diff ${tmpfile}.base
It really should do something like
#
# Make sure we see objects in the remote directory
#
export GIT_ALTERNATE_OBJECT_DIRECTORIES=$remote/.git/objects
#
# Get the local SHA1
#
local_ref=$(git-rev-parse --verify $base^0) || exit
#
# Get the remote SHA1
#
remote_ref=$(GIT_DIR="$remote/.git" git-rev-parse --verify $tobase^0)
|| exit
#
# Ok, let it rip..
#
git log $remote_ref..$local_ref
to do a proper search of objects that are in $local but not in $remote,
without having to traverse all the way down to the root for both.
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
"Child" information in commit window - and cleanups
This adds "Child: " lines to the commit window, which tells what children
a commit has.
It also cleans things up: it marks the text widget as no-wrap, which means
that it doesn't need to truncate the commit description arbitrarily by
hand. Also, the description itself is now done by a common helper routine
that handles both the parent and the children.
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---
[ NOTE! The list of children is "calculated" information, since git itself
doesn't actually keep any child pointers, and that means that it only
lists any children that gitk has seen. There may be other children of a
commit in other branches in the same repository, and gitk will not show
such children that it doesn't know about.
But this is useful for walking up and down the links - you get the same
information as if you had clicked on a link ]
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -387,7 +387,7 @@ proc makewindow {} {
set ctext .ctop.cdet.left.ctext
text $ctext -bg white -state disabled -font $textfont \
-width $geometry(ctextw) -height $geometry(ctexth) \
- -yscrollcommand ".ctop.cdet.left.sb set"
+ -yscrollcommand ".ctop.cdet.left.sb set" -wrap none
scrollbar .ctop.cdet.left.sb -command "$ctext yview"
pack .ctop.cdet.left.sb -side right -fill y
pack $ctext -side left -fill both -expand 1
@@ -1704,10 +1704,19 @@ proc selcanvline {w x y} {
selectline $l 1
}
+proc commit_descriptor {p} {
+global commitinfo
+set l "..."
+if {[info exists commitinfo($p)]} {
+ set l [lindex $commitinfo($p) 0]
+}
+return "$p ($l)"
+}
+
proc selectline {l isnew} {
global canv canv2 canv3 ctext commitinfo selectedline
global lineid linehtag linentag linedtag
-global canvy0 linespc parents nparents
+global canvy0 linespc parents nparents children nchildren
global cflist currentid sha1entry
global commentend idtags idline
@@ -1790,15 +1799,15 @@ proc selectline {l isnew} {
set commentstart [$ctext index "end - 1c"]
set comment {}
-foreach p $parents($id) {
- set l "..."
- if {[info exists commitinfo($p)]} {
- set l [lindex $commitinfo($p) 0]
- if {[string length $l] > 32} {
- set l "[string range $l 0 28] ..."
- }
+if {[info exists parents($id)]} {
+ foreach p $parents($id) {
+ append comment "Parent: [commit_descriptor $p]\n"
+ }
+}
+if {[info exists children($id)]} {
+ foreach c $children($id) {
+ append comment "Child: [commit_descriptor $c]\n"
}
- append comment "Parent: $p ($l)\n"
}
append comment "\n"
append comment [lindex $info 5]
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "Child" information in commit window - and cleanups
On Mon, 8 Aug 2005, Linus Torvalds wrote: > > It also cleans things up: it marks the text widget as no-wrap, which means > that it doesn't need to truncate the commit description arbitrarily by > hand. Btw, in case anybody wondered: there is no x-axis scroll-bar. I don't think one is needed, and if you _really_ want to scroll, you can do so by dragging with the middle-mouse-button. I have to say, with tcl/tk, "google" + "random typing" can make you appear to know what the hell you're doing. 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 "diffstat"s 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: gitweb - feature request
On Wed, 10 Aug 2005, Kay Sievers wrote: > > Firefox may need a plugin to be able to read it, I don't really know... Firefox definitely needs a separate plugin, at least for me. 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 ?
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 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 Thu, 11 Aug 2005, Martin Langhoff wrote: > > Well, I doubt this problem lies with Debian. Oh, it definitely does. >GNU Interactive Tools is > packaged for most (all?) distributions, and has been there for ages. .. but no other distribution seems to install it. The _only_ people who have ever even noticed are debian people. That should clue somebody in. The top man-page I found for GNU interactive tools says: A Set of Interactive Programs Edition 2.5, for GIT version 4.3.16 January 1997 just let it die in peace. 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 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, Sam Ravnborg wrote: > > The easy fix is to kill the small git script that is not > mandatory anyway (as far as my quick grep told me). It's not "mandatory", but the tutorial etc use it as an example. In other words, if you remove the git script, you are going to have a _bad_ package. I'd suggest that people who don't like the naming just don't install "git" at all. Live with 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] 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: [PATCH] fetch-pack: start multi-head pulling.
On Fri, 12 Aug 2005, Junio C Hamano wrote:
>
> Linus, I need a bit of guidance from you about this one; an
> ancient commit 4f7770c87ce3c302e1639a7737a6d2531fe4b160 removed
> the multi-head support fetch-pack once had, labelling it as "a
> misguided attempt", and I would like to know if I am making the
> same misguided attempt again. This update actually makes
> clone-pack almost redundant.
I like your version.
My misguided attempt was not the ability to pull multiple heads, but what
to _do_ with them. I originally envisioned something more "git-push-pack"
like, where it would pull multiple heads into real references, and _that_
was the misguided part. I then ended up just printing it out to stdout,
and that made it "one ref only".
Your version where you just print out multiple heads with names is, I
think, the right thing to do.
The shell script looks a bit unreadable to me, personally.
> head=$(git-fetch-pack "$merge_repo" "$merge_head")
> + if h=`expr "$head" : '\([^ ][^ ]*\) '`
> + then
> + head=$h
> + fi
Back-ticks, and the ":" operator to "expr". You really _are_ old-fashioned
when it comes to shell ;)
Wouldn't it be simpler/cleaner to just do
head=($(git-fetch-pack "$merge_repo" "$merge_head"))
which gets you "$head" being the same as ${head[0]}, namely the SHA1 you
want (and if you ever implement multi-head pulling, you'll have it all in
${head[..]}..)
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] fetch-pack: start multi-head pulling.
On Fri, 12 Aug 2005, Johannes Schindelin wrote: > > I seem to remember Junio does not like bash arrays... Well, fair enough, although they aren't really "bash" arrays, they appeared in other shells before "bash". At least ksh and zsh have them, although the zsh implementation seems to be pretty broken (indices start at 1, and $var acts like $var[*] etc). Afaik, ksh is actually the origin of the thing. 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] Use "-script" postfix for scripts
On Fri, 12 Aug 2005, Junio C Hamano wrote: > > I have never liked the original -script name convention. It > only meant that they are implemented as scripts (as opposed to > those on the $(PROG) Makefile variable), but the end users who > end up typing their names from the command line, and to a lesser > degree the people who use them in their scripts, should not care > how they are implemented to begin with. Well, end users _don't_ care, since they are supposed to use just a simple "git xxx". The advantage with "git-xxx-script" is for git developers: at least yours truly does "grep xyz *.c" all the time, and the "grep abc *-script" is entirely analogous to that. That's where the "-script" ending comes from: it really helps pick out the stuff you can grep from (as opposed to the stuff that got compiled and isn't greppable). Sure, I could have called it ".sh" instead to make it look even more like a shell script thing, but I actually think "-script" describes any scripting language - shell, perl, you name 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 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 , 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 Sat, 13 Aug 2005, Petr Baudis wrote: > > Oh. Sounds nice, are there plans to run this on kernel.org too? (So far, > 90% of my GIT network activity happens with kernel.org; the rest is with > my notebook, and I want to keep that ssh.) Maybe. I don't know what the status of that is, but the plan was to at least give it a try. > BTW, is the pack protocol flexible enough to be extended to support > pushing? The _protocol_ could handle it, but you obviously need some kind of secure authentication, and quite frankly, one of the selling points on git-daemon right now is that it's all read-only and very simple and there should be no security issues because it will never write anything at all. So right now git-daemon only accepts requests from fetch-pack. > > [ Hey. There's a deer outside my window eating our roses again. Cute ] > > Oh, it must be nice in Oregon. I can't imagine anything like that to > happen in Czechia unless you live at a solitude or in some lonely tiny > village. Deer are really just oversized rats with horns (*). They're cute, though, and it's kind of funny looking up from the screen and noticing one munching on the roses just ten feet away. Linus (*) Did I mention that biology wasn't one of the things I did at Uni? - 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: > > My git snapshot creator that builds the hourly tarballs at > http://www.codemonkey.org.uk/projects/git-snapshots/ > currently does an rsync, and then a checkout, and finally > it cleans up by removing all the checked out files. > It currently does this by hand, but on learning about > this 'new' command, I thought, cool, now I can do.. > > git-ls-files | xargs rm -rf > > however, this then leaves a bunch of empty subdirs, as > git-ls-files doesn't list the subdirs by themselves in > the output. Am I missing some other option ? Nope, you're not missing anything, except that you shouldn't do that. "git-ls-files" is very nice for things like git-ls-files | xargs grep but your example is not one of them. Not without options, and not _with_ strange options. Your example is an example of just not doing it the right way. If you really want a temporary tree, what you do is something like git-checkout-cache --prefix=tmp-dir/ -f -a and when you're done, you just do rm -rf tmp-dir and you're done. NOTE NOTE NOTE! In the above, the order of the parameters is really really important! "-a" takes effect when it is seen, so it needs to be last. Also, the "--prefix" thing really _really_ needs the slash at the end, because it's literally used to prefix the pathname. HOWEVER, if all you want to do is just a tar-file, then there's a better solution. It's called snap=git-snapshot-$(date +"%Y%m%d") git-tar-tree HEAD $snap | gzip -9 > $snap.tar.gz which is even easier, and a hell of a lot more efficient. 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". 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 Fri, 12 Aug 2005, Linus Torvalds 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". Btw, I just checked that git-tar-tree is documented and has a man-page. It does. However, that man-page attributes authorship to me, which is wrong. git-tar-tree was written by Rene Scharfe <[EMAIL PROTECTED]>. Don't know how many other man-pages say I wrote something just because people copied another man-page around. Worth fixing, 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: 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: [PATCH] Use "-script" postfix for scripts
On Sat, 13 Aug 2005, Junio C Hamano wrote: > Ryan Anderson <[EMAIL PROTECTED]> writes: > > See, for example, the history on git-rename-script for why this is good. > > Why do you think it is a good example? What happens when next > time somebody rewrites it in C? We'll call the C version "rename.c", and the program gets to be called "git-rename", and "git rename" continues to work perfectly fine, so users won't be affected in the least. And "grep ... *.c" and "grep ... *-script" also still work right. That sounds like a good outcome to me. 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/cogito workshop/bof at linuxconf au?
On Sat, 13 Aug 2005, Martin Langhoff wrote: > > Anyone coming to Linuxconf.au 2006? It'll will be in Dunedin NZ and > I'd be really keen on joining a git/cogito workshop or bof. I was planning to be there. I like lca, but passed it over this year because of it being in Canberra (I'm sure it's a nice city to live in, but it's not a very exciting one, and I've been there several times before ;) > I would gladly try and organize a workshop, but I am far from fluent > with git, so I won't go at it alone. Any takers? Call for papers ends > 5th September, not too far ahead. We have to register our interest > _now_. I'm no good with papers, though. One of the reasons I decided to leave the university lifestyle was that I hate writing papers. That's anti-conductive to being at a uni ;) 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: git/cogito workshop/bof at linuxconf au?
On Sun, 14 Aug 2005, Martin Langhoff wrote: > > And how are things lining up for the upcoming one (January 2006, Dunedin, > NZ)? Dunno yet. I have a policy of trying to travel with the whole family, which means I'll have to decide whether I'm willing to put that much money into it, or whether some poor unsuspecting company can help sponsor me ;) We'll see. > There's a lot of interest, but the barriers of entry are somewhat > high, with the codebase moving fast, and some of the concepts > requiring re-learning of what to expect from an SCM. Perhaps no so > much among kernel hackers, but the general populace is largely still > laden with cvs/svn and their mindset. Yeah. We do not have a nice paper explaining the concepts and usage. The tutorial isn't really in-depth enough (it doesn't even mention a lot of the helper scripts or even some of the core stuff). The old README started out explaining some of the concepts, but it's _way_ of out date in all usage respects. Pasky has the Overview thing, which gets pointed to by kernel.org, and which could be expanded upon a lot. I'll happily help anybody who wants to try to write some nice documentation (answer questions etc), but I'm just not very good at doing it myself. 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, Junio C Hamano wrote: > > Petr Baudis <[EMAIL PROTECTED]> writes: > > Rewrite refs in place in receive-pack & friends > > > > When updating a ref, it would write a new file with the new ref and > > then rename it, overwriting the original file. The problem is that > > this destroys permissions and ownership of the original file, which is > > troublesome especially in multiuser environment, like the one I live in. > > Hmph. If a repo is _really_ used multiuser then you should not > have to care about ownership. I think Pasky's usage is that different heads are owned by different groups and/or users, and he wants to use the filesystem permissions to determine who gets to update which branch. Which is reasonable in a way. On the other hand, I don't think filesystem permissions are really very useful. I think it's more appropriate to use triggers to say something like "only allow people in the 'xyz' group to write to this head". Obviously, triggers aren't about _security_ - somebody who has write permissions to the tree can always screw up others. But triggers are fine for things like branch ownership, where you trust your users, but you just want to avoid mistakes. So a trigger might be something like #!/bin/sh . git-sh-setup-script branch="$1" old="$2" new="$3" if [ -e $GIT_DIR/permissions/$branch ]; then id=$(id -un) grep -q "^$id$" $GIT_DIR/permissions/$branch || die "You're not allowed to write to $branch" fi true and that would allow you to list all users that are allowed to write to the branch in $GIT_DIR/permissions/. Totally untested, of course. But the concept should work. 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: (cogito) Branch offf from older commit?
On Sun, 14 Aug 2005, Wolfgang Denk wrote: > > Is there (in cogito) a way to start a branch off from an older > commit? You should be able to just use the git commands, and cogito should be perfectly happy. IOW, if you do git checkout -b newbranch you'll switch to a "newbranch" that was created at the starting point, and as far as I can tell, this is all very cogito-friendly indeed. So now you can work in that "newbranch" - commit things, do anything you want, and all with cogito (ie it's only this one raw git command you need to set things up, after that you're back in cogito-land). You can switch back with "git checkout master" (again, I don't think cogito does the local git branches yet, but once you've switched back you're golden), and if you're in the "master" branch, you can merge with your new-branch with git resolve master newbranch "Merge my work on xyz" or similar. And always remember "gitk --all", since that's a very useful thing to visualize where you are. > -> cg-seek 024447b186cca55c2d803ab96b4c8f8674363b86 No, cg-seek doesn't start a new branch, so the result is "locked". You can't commit on top of the seek-point, because the branch you are in already _has_ a child of that point. (Actually, these days cg-seek does use a fixed local git branch for the seek target, so that's not _technically_ true any more. I suspect Pasky is working on exposing the general local branch interfaces) 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] Alternate object pool mechanism updates.
On Sun, 14 Aug 2005, Junio C Hamano wrote: > > Ok, so the one in the proposed updates branch says > info/alternates. > > With this, your recent cg-clone -l can be made to still use > individual .git/object/??/ hierarchy to keep objects newly > created in each repository while sharing the inherited objects > from the parent repository, which would probably alleviate the > multi-user environment worries you express in the comments for > the option. The git-clone-script in the proposed updates branch > has such a change. 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. However, exactly for places like kernel.org it would _also_ be nice if there was some way to prune objects that have been merged back into the parent. In other words, imagine that people start using my kernel tree as their source of "alternate" objects, which works wonderfully well, but then as I pull from them, nothing ever removes the objects that are now duplicate. We've got a "git prune-packed", it would be good to have a "git prune-alternate" or something equivalent. 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, Martin Langhoff wrote: > > After having done a cvs import of Moodle using git-cvsimport-script > all the cvs branches show up as heads. How do I switch heads within a > checkout? cogito doesn't seem to be able to, and I'm unsure on how to > do it with git. Just do git checkout branch-name to switch between them. One thing that "git cvsimport" does not know to do is to show when a branch was merged back into the HEAD. That would be a very interesting thing to see, but I don't think there's any way to get that information out of CVS (so you'd have to basically make an educated guess by looking at the changes). So in a cvsimport, you'll never see a merge back to the head, even if one technically took place. > And I am confused about the difference between heads and branches. Confusion of naming. branches and heads are the same thing in git. However, largely due to historical reasons, I encouraged "one tree pre branch", and then you had "external branches" which were totally separate repositories. Now, we're stuck with both the "internal branches" (heads) and "external branches" (other repositories) _both_ being confusingly called "branch", and then to make it more confusing, sometimes you'll see people say "head" to make clear that it's a branch internal to one repo. > In any case, should the cvsimport turn cvs branches into git branches > instead of heads? Is there are way to turn a head into a proper > branch? They are "proper branches", and sorry about the confusion. A head is a 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: Switching heads and head vs branch after CVS import
On Mon, 15 Aug 2005, Martin Langhoff wrote:
>
> > So in a cvsimport, you'll never see a merge back to the head, even if one
> > technically took place.
>
> There may be some surprises in here! gitk --all shows at least one
> branch opening and merging back into origin, and it has figured it out
> correctly
Oh, wow. The new cvsimport is obviously being a hell of a lot smarter than
my original one was. Goodie.
> Except for the keyword expansion. surely there's a way to tell cvsps
> to not do it. Why would we ever want it?
Ahh. I don't think we should blame cvsps, I think cvsimport should use the
"-ko" flag to disable keyword expansion or whatever the magic flag is.
Sven, Matthias, opinions? I've never used CVS keyword expansion, and
always felt it was pointless, but hey..
> > branches and heads are the same thing in git.
>
> right. There are two separate directories in .git for them, so I was
> misled by that. Should I assume git is safe from name clashes or is it
> up to porcelain to deal with such minutiae?
Well, you actually are _expected_ to get clashes.
What happens normally (at least for core git) is that the ".git/branches"
directory contains external sources for the branches (for example, a "git
clone" will fill in the "origin" source, while I often have a
".git/branches/parent" in my tree because). That is just a pointer to
where the external branch exists.
Then, when you do something like
git fetch parent
it will look up the source of "parent" by looking in the
".git/branches/parent" file, and update the ".git/refs/heads/parent"
branch appropriately from that external branch.
So in this example the parent "head" ("local branch") points to the actual
_commit_ we have, while the ".git/branches/parent thing points to what
_external_ branch it came from.
But yes, you _can_ mess this up if you want to. If you have the same
"external branch" name that you use for an "internal branch", you deserve
all the confusion you get ;)
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: > > It seems to me that git-diff-tree needs huge memory if you try to diff > on big change with rename detection enabled. > > This isn't problem for sane project but if you create a repo with only > major releases imports, git-diff-tree run by git_commit() eats system > memory and die ;P Instead of disabling it entirely, how about just having some limit on it? The basic rename detection works very well for "normal" changes as you point out, but it very fundamentally is O(n^2) in number of files created and deleted, so we could instead just limit it and say "if we have tons of new/deleted files, disable it in the interest of CPU/memory usage". 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 Tue, 16 Aug 2005, Martin Langhoff wrote: > > If I find the time, I'll add some sort of pattern-match parameters to > be tried against the commitmsg to extract likely head/branch names > where we are merging from. My problem right now is that the only cvs > repo with interesting branches and merges I have is huge, and takes an > hour to import. That puts a damper on things, unfortunately. I was seriously considering just breaking the "remote cvs" support entirely (you can always just use cvsup or something to download it to make it local), and just taking the RCS parsing code from GNU rcs/cvs and making a C language CVS importer. That would speed things up by an order of magnitude or more, as far as I can tell. 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
Re: [PATCH] Alternate object pool mechanism updates.
On Tue, 16 Aug 2005, Junio C Hamano wrote: > Linus Torvalds <[EMAIL PROTECTED]> writes: > > > We've got a "git prune-packed", it would be good to have a "git > > prune-alternate" or something equivalent. > > If you have GIT_ALTERNATE_DIRECTORIES environment variable, git > prune-packed will remove objects from your repository if it is > found in somebody else's pack. I am not sure if this is the > behaviour we would want. Well, it may be good enough if the "master" repository is regularly packed.. 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))
+
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_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
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
Improve handling of "." and ".." in git-diff-*
This fixes up usage of ".." (without an ending slash) and "." (with or
without the ending slash) in the git diff family.
It also fixes pathspec matching for the case of an empty pathspec, since a
"." in the top-level directory (or enough ".." under subdirectories) will
result in an empty pathspec. We used to not match it against anything, but
it should in fact match everything.
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
This is in addition to the previous fix for the t testcase and applies
independently of that.
NOTE! This does _not_ handle ".." or "." in the _middle_ of a pathspec. If
you have people who do
git diff net/../char/
this will not help them - it will _not_ simplify this to
git diff char/
and only ".." and "." components at the head of the pathspec will be
honoured.
Finally, if you try to give a pathspec that goes "outside" of the .git
directory (eg, a ".." pattern at the top of the git archive), the code
will politely tell you to f*ck off and die (this is not a new feature, the
previous code drop did that too, but because we now handle it even for the
top-level case without any extra prefix, it's worth noting).
---
diff --git a/diffcore-pathspec.c b/diffcore-pathspec.c
--- a/diffcore-pathspec.c
+++ b/diffcore-pathspec.c
@@ -29,6 +29,8 @@ static int matches_pathspec(const char *
name[len] == 0 ||
name[len] == '/')
return 1;
+ if (!len)
+ return 1;
}
return 0;
}
diff --git a/read-cache.c b/read-cache.c
--- a/read-cache.c
+++ b/read-cache.c
@@ -191,6 +191,8 @@ int ce_path_match(const struct cache_ent
return 1;
if (name[matchlen] == '/' || !name[matchlen])
return 1;
+ if (!matchlen)
+ return 1;
}
return 0;
}
diff --git a/setup.c b/setup.c
--- a/setup.c
+++ b/setup.c
@@ -1,23 +1,60 @@
#include "cache.h"
+static char *prefix_path(const char *prefix, int len, char *path)
+{
+ char *orig = path;
+ for (;;) {
+ char c;
+ if (*path != '.')
+ break;
+ c = path[1];
+ /* "." */
+ if (!c) {
+ path++;
+ break;
+ }
+ /* "./" */
+ if (c == '/') {
+ path += 2;
+ continue;
+ }
+ if (c != '.')
+ break;
+ c = path[2];
+ if (!c)
+ path += 2;
+ else if (c == '/')
+ path += 3;
+ else
+ break;
+ /* ".." and "../" */
+ /* Remove last component of the prefix */
+ do {
+ if (!len)
+ die("'%s' is outside repository", orig);
+ len--;
+ } while (len && prefix[len-1] != '/');
+ continue;
+ }
+ if (len) {
+ int speclen = strlen(path);
+ char *n = xmalloc(speclen + len + 1);
+
+ memcpy(n, prefix, len);
+ memcpy(n + len, path, speclen+1);
+ path = n;
+ }
+ return path;
+}
+
const char **get_pathspec(const char *prefix, char **pathspec)
{
char *entry = *pathspec;
char **p;
int prefixlen;
- if (!prefix) {
- char **p;
- if (!entry)
- return NULL;
- p = pathspec;
- do {
- if (*entry != '.')
- continue;
- /* fixup ? */
- } while ((entry = *++p) != NULL);
- return (const char **) pathspec;
- }
+ if (!prefix && !entry)
+ return NULL;
if (!entry) {
static const char *spec[2];
@@ -27,38 +64,10 @@ const char **get_pathspec(const char *pr
}
/* Otherwise we have to re-write the entries.. */
- prefixlen = strlen(prefix);
p = pathspec;
+ prefixlen = prefix ? strlen(prefix) : 0;
do {
- int speclen, len = prefixlen;
- char *n;
-
- for (;;) {
- if (!strcmp(entry, ".")) {
- entry++;
- break;
- }
- if (!strncmp(entry, "./", 2)) {
-
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
