* Re: [ANNOUCNE] GIT 1.1.0
From: Andreas Ericsson @ 2006-01-09 22:22 UTC (permalink / raw)
To: lamikr; +Cc: Junio C Hamano, git
In-Reply-To: <43C2CAED.8030304@cc.jyu.fi>
lamikr wrote:
>>- "git --version" from an interim snapshot gives a more
>> descriptive version name than "1.0-GIT" (Linus).
>>
>>
>
> I installed 1.1.0 today and it shows me
>
> $ git --version
> git version 1.0.GIT
>
You did not have git-describe installed prior to building 1.1.0. If you
re-install right on top the one you did today the version-file will be
generated correctly.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: undoing changes with git-checkout -f
From: lamikr @ 2006-01-09 22:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601091321390.5588@g5.osdl.org>
Linus Torvalds wrote:
>You should realize that git _does_not_know_ about your file. You never
>even told git about it. So git won't ever evenlook at it, much less delete
>it.
>
>So when you do a "git checkout -f", what that does is to rewrite all the
>files that git KNOWS about. Any files git doesn't know about will not ever
>be touched. Your "1.txt" file might as well be an object file, for all git
>knows. And git won't remove your object files or any other files that it
>doesn't know.
>
>(Now, in all fairness, even if you had done "git add", I don't think git
>will remove the file. If you committed the file and then checked out the
>previous version, _then_ it would remove the committed file).
>
>
Now that you say it, I got it, thanks. I expected earlier that git would
perform also the
remove of non-added files as other commands like "git-commit" are anyway
aware
if you have files in your working dir that have not yet added.
>If what you want to do is to clean the git directory of all files that git
>doesn't know about, you can do that with
>
> git-ls-files -z --others | xargs -0 rm --
>
>
Thanks for the tip. I have now added alias git-reset-ff='git-ls-files -z
--others | xargs -0 rm --'
And git-reset-fff (forte fortissimo) would probably blow the whole hd
away :-)
Mika
^ permalink raw reply
* git-bisect is magical
From: walt @ 2006-01-09 22:41 UTC (permalink / raw)
To: git
Arthur C. Clarke's Third Law states: Any sufficiently advanced
technology is indistinguishable from magic.
You guys have done it -- I can't distinguish git-bisect from
magic. It's wonderful, and thank you!
I used it for the first time this morning to find the commit
which caused some kernel breakage. I just sent off an email
to the developer whose commit did the breakage, and it only
took me about 45 minutes. (Now all I need to do is sit back
and wait for his reply saying 'You're an idiot!')
I have one minor suggestion for howto/isolate-bugs-with-bisect.
Linus states:
git bisect good ORIG_HEAD <- mark ORIG_HEAD as good (or
whatever other known-good
thing you booted last)
Well, in my case, I new the last good kernel was *two* updates ago,
so ORIG_HEAD wasn't the right thing to use. I had to guess what
to type instead of 'ORIG_HEAD'.
Which leads to one more question: I have my kernel configured to
add the -gxxxxxxxx localversion string to the kernel name. I took
a wild guess that the xxxxxxxx was the right thing to substitute
for 'ORIG_HEAD' and I got lucky. But what about someone who
doesn't know the magic 'xxxxxxxx' to use? If I didn't know enough
to keep a week's worth of daily kernel-builds with the 'xxxxxxxx'
to guide me, would I still be able to do what I did today?
(For example, if this had been a 'git' bug instead of a kernel bug,
I don't think I could have figured out how to use git-bisect to find
the bug -- could I?)
Thanks!
^ permalink raw reply
* Re: undoing changes with git-checkout -f
From: lamikr @ 2006-01-09 22:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzi5hy69.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>lamikr <lamikr@cc.jyu.fi> writes:
>
>
>
>>1) I clone git repo by using command
>>
>> git-clone rsync://source.mvista.com/git/linux-omap-2.6.git
>>linux-omap-2.6
>>
>>
>
>Please do not use rsync:// transport if possible (mvista might
>only pubilsh via rsync:// and not git://, so it may not be your fault).
>
>
Ok, I will send a message to maintainer. I was just pasting the address
from their instructions. (They were using cogito on top of git, but I
want to learn to use pure git commands first)
>Nothing. After the second step, git does not know anything
>about 1.txt; if it is a part of something you wanted to
>eventually commit, or it is some notes you took while perusing
>the source and is precious even when you switch branches (even
>though you would not commit it as part of the project) , so it
>does not touch it. After running "make", "checkout -f" does not
>do "make clean" for you to remove *.o files either, for exactly
>the same reason.
>
>"git status" would tell you the file is "untracked".
>
>If you did something like this:
>
> $ edit 1.txt
> $ git add 1.txt
> $ git reset --hard
>
>"git reset --hard" would remove it, while "git checkout -f"
>would leave the file behind.
>
>
Ok, so this describes the power difference between "checkout -f"
and "git-reset --hard" pretty well.
>BTW, please do not set Reply-To: (or Mail-Followup-To: for that
>matter) to the list. When I (or somebody else) want to reply
>to you, especially in private, your Reply-To: header forces me
>to manually rewrite the To: header MUA prepares for me.
>
>I know why you do it --- you are on the list and otherwise you
>would get duplicate messages, one from me directly and another
>from the list. I've seen other people do it, but IMNSHO it is a
>bad practice. Filter them on your end, and do not put extra
>burden to others, please. The only case mucking with the
>addressee headers may be acceptable is to remove yourself from
>CC: list when a list you are on is on the CC: list.
>
>
Yes, I am a victim of graphical email reader aka "thunderbird".
But I will now remember to do this for vger mailing lists.
A little off topic, but I just wish that http mail archive apps like the
one used in
http://marc.theaimsgroup.com/?l=linux-kernel
could also offer possibility to filter duplicates away.
Mika
^ permalink raw reply
* RE: git pull on Linux/ACPI release tree
From: Luben Tuikov @ 2006-01-09 22:51 UTC (permalink / raw)
To: Linus Torvalds, Brown, Len
Cc: Luck, Tony, Junio C Hamano, Martin Langhoff, David S. Miller,
linux-acpi, linux-kernel, akpm, git
In-Reply-To: <Pine.LNX.4.64.0601090850350.3169@g5.osdl.org>
--- Linus Torvalds <torvalds@osdl.org> wrote:
> But if there are workflow problems, let's try to fix them. The "apply
> patches directly to another branch" suggestion may not be sane (maybe it's
> too confusing to apply a patch and not actually see it in the working
> tree), but workflow suggestions in general are appreciated.
This is sensible, thank you.
A very general workflow I've seen people use is more/less as
I outlined in my previous email:
tree A (linus' or trunk)
Project B (Tree B)
Project C (Tree C, depending on stuff in Project B)
Now this could be how the "managers" see things, but development,
could've "cloned" from Tree B and Tree C further, as is often
customary to have a a) per user tree, or b) per bug tree.
So pull/merge/fetch/whatever follows Tree A->B->C.
It is sensible to have another tree say, called something
like "for_linus" or "upstream" or "product" which includes
what has accumulated in C from B and in B from A, (eq diff(C-A)).
I.e. a "push" tree. So that I can tell you, "hey,
pull/fetch/merge/whatever the current verb en vogue is, from
here to get latest xyz".
What I also wanted to mention is that Tree B undeniably
depends on the _latest_ state of Tree A, since Project B
uses API/behaviour of the code in Tree A, so one cannot just
say they are independent. Similarly for Tree C/Project C,
is dependent on B, and dependent on A.
Also sometimes a bugfix in C, prompts a bugfix in A,
so that the bugfix in A doesn't apply unless the bugfix in C.
(To get things more complicated.)
I think this is more/less the most easier to see, understand and
follow workflow approach, which is also the case for other SCMs.
What are the commands to follow to make everyone happy when
pulling from such a development process?
FWIW, "git diff A C | send to Linus" would get you the
"no merge messages/ancestors I want to see" idea, if I understand
this thread correctly.
> We've made switching branches about as efficient as it can be (but if the
> differences are huge, the cost of re-writing the working directory is
> never going to be low). But switching branches has the "confusion factor"
> (ie you forget which branch you're on, and apply a patch to your working
> branch instead of your development branch), so maybe there are other ways
> of doing the same thing that might be sensible..
Yes. Ever since I started used git, I never used branch
switching, but I do have git branches and I do use git branching.
I basically have a branch per directory, whereby the object db
is shared as is remotes/refs/etc, HEAD and index are not shared
of course.
This allows me to do a simple and fast "cd" to change/go to a
different branch, since they are in different directories.
So the time I wait to switch branches is the time the filesystem
takes to do a "cd".
This also allows me to build/test/patch/work on branches
simultaneously.
Thank you,
Luben
^ permalink raw reply
* Re: [ANNOUCNE] GIT 1.1.0
From: Junio C Hamano @ 2006-01-09 22:59 UTC (permalink / raw)
To: lamikr; +Cc: git
In-Reply-To: <43C2CAED.8030304@cc.jyu.fi>
lamikr <lamikr@cc.jyu.fi> writes:
>> - "git --version" from an interim snapshot gives a more
>> descriptive version name than "1.0-GIT" (Linus).
>>
>>
> I installed 1.1.0 today and it shows me
>
> $ git --version
> git version 1.0.GIT
Ah, sorry, and thanks for catching this. RPM building procedure
is somewhat tricky, and I failed to catch this bug. Fixed in my
tree --- this calls for an early 1.1.1 release I guess.
On the other hand, if you are building from the source, what
Andreas said applies, and in addition you need to fetch v1.1.0
tag before building; otherwise the versioning mechanism would not
notice you are building v1.1.0.
^ permalink raw reply
* [PATCH] GIT-VERSION-GEN: allow overriding from Makefile
From: Junio C Hamano @ 2006-01-09 23:01 UTC (permalink / raw)
To: git
The RPM building procedure relied on being able to build from a
freshly untarred tarball, so there is no way "git describe"
could figure out from which commit it is building (there was no
HEAD).
This still does not allow you to build RPM binary package from
an untagged interim version because RPM does not like '-' in
version number, but that probably is a blessing.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* For 1.1.1; the binary in 1.1.0 RPM was affected with this bug.
GIT-VERSION-GEN | 13 +++++++++----
Makefile | 2 +-
2 files changed, 10 insertions(+), 5 deletions(-)
1900d64cbecf46844dd7910d78676e0cace7139e
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 845b9dc..c878819 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -2,8 +2,15 @@
GVF=GIT-VERSION-FILE
-VN=$(git-describe --abbrev=4 HEAD 2>/dev/null) || VN=v1.0.GIT
-VN=$(expr "$VN" : v'\(.*\)')
+case "${VN+set}" in
+set)
+ ;;
+*)
+ VN=$(git-describe --abbrev=4 HEAD 2>/dev/null) || VN=v1.0.GIT
+ VN=$(expr "$VN" : v'\(.*\)')
+ ;;
+esac
+
if test -r $GVF
then
VC=$(sed -e 's/^GIT_VERSION = //' <$GVF)
@@ -14,5 +21,3 @@ test "$VN" = "$VC" || {
echo >&2 "GIT_VERSION = $VN"
echo "GIT_VERSION = $VN" >$GVF
}
-
-
diff --git a/Makefile b/Makefile
index c9c15b5..0bbb5b8 100644
--- a/Makefile
+++ b/Makefile
@@ -494,7 +494,7 @@ dist: git.spec git-tar-tree
gzip -f -9 $(GIT_TARNAME).tar
rpm: dist
- $(RPMBUILD) -ta $(GIT_TARNAME).tar.gz
+ VN=$(GIT_VERSION) $(RPMBUILD) -ta $(GIT_TARNAME).tar.gz
### Cleaning rules
--
1.1.0
^ permalink raw reply related
* RE: git pull on Linux/ACPI release tree
From: Linus Torvalds @ 2006-01-09 23:07 UTC (permalink / raw)
To: Luben Tuikov
Cc: Brown, Len, Luck, Tony, Junio C Hamano, Martin Langhoff,
David S. Miller, linux-acpi, linux-kernel, akpm, git
In-Reply-To: <20060109225143.60520.qmail@web31807.mail.mud.yahoo.com>
On Mon, 9 Jan 2006, Luben Tuikov wrote:
>
> Yes. Ever since I started used git, I never used branch
> switching, but I do have git branches and I do use git branching.
>
> I basically have a branch per directory, whereby the object db
> is shared as is remotes/refs/etc, HEAD and index are not shared
> of course.
>
> This allows me to do a simple and fast "cd" to change/go to a
> different branch, since they are in different directories.
> So the time I wait to switch branches is the time the filesystem
> takes to do a "cd".
>
> This also allows me to build/test/patch/work on branches
> simultaneously.
Yes. It has many advantages, and it's the approach I pushed pretty hard
originally, but the "many branches in the same tree" approach seems to
have become the more common one. Using many branches in the same tree is
definitely the better approach for _distribution_, but that doesn't
necessarily mean that it's the better one for development.
For example, you can have a git distribution tree with 20 different
branches on kernel.org, but do development in 20 different trees with just
one branch active - and when you do a "git push" to push out your branch
in your development tree, it just updates that one branch on the
distribution site.
So git certainly supports that kind of behaviour, but nobody I know
actually does it that way (not even me, but since I tend to just merge
other peoples code, I don't actually have multiple branches: I create
temporary branches for one-off things, but don't maintain them that way).
Linus
^ permalink raw reply
* [PATCH 0/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Michal Ostrowski @ 2006-01-09 23:34 UTC (permalink / raw)
To: git; +Cc: Michal Ostrowski
I've been trying to setup a git repository for access via ssh, on a
system where git is to be installed under ~user/bin, and ~user/bin is
not included in the PATH that sshd provides.
Consequently I need to execute something like:
git-clone -u /home/user/bin/git-upload-pack \
ssh://user@system/home/user/repo.git repo
When git-upload-pack executes on the remote system, it tries to execute
git-rev-list and fails, since /home/user/bin is not in the path.
The following patches handle this issue by appending GIT_EXEC_PATH to
PATH prior to exec calls (via git_setup_exec_path()). Also, the value
of ${bindir} at build time is encoded and used as a default value for
"GIT_EXEC_PATH", if the latter is not present.
--
Michal Ostrowski <mostrows@watson.ibm.com>
^ permalink raw reply
* [PATCH 1/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Michal Ostrowski @ 2006-01-09 23:35 UTC (permalink / raw)
To: git
In-Reply-To: <1136849678.11717.514.camel@brick.watson.ibm.com>
If git-upload-pack is invoked by ssh, it may have been invoked because
ssh was explicitly told which program to execute on the remote end
(i.e. --exec had been used with git-clone-pack). In this case, the
git suite may not be in the PATH, and so subsequent exec's by
git-upload-pack (i.e. git-rev-list, git-pack-objects) will fail.
These changes provide for ${bindir} to be stored at compile time in
environment.c. git_setup_exec_path() is implemented; this function
will append GIT_EXEC_PATH or the saved ${bindir} to PATH.
Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com>
---
Makefile | 7 +++++++
cache.h | 1 +
environment.c | 29 +++++++++++++++++++++++++++++
3 files changed, 37 insertions(+), 0 deletions(-)
b24fde016c2d7382016b80bc0b9a011db3413bb3
diff --git a/Makefile b/Makefile
index c9c15b5..ffd2a68 100644
--- a/Makefile
+++ b/Makefile
@@ -437,6 +437,13 @@ init-db.o: init-db.c
$(CC) -c $(ALL_CFLAGS) \
-DDEFAULT_GIT_TEMPLATE_DIR=$(call shellquote,"$(template_dir)") $*.c
+# Recompile environment.o if GIT_EXEC_PATH changes
+.environment.GIT_EXEC_PATH:
+ @(test -e $@ && grep -h -e '^$(bindir)$$' $@) || echo $(bindir) > $@
+environment.o: .environment.GIT_EXEC_PATH
+environment.o: CFLAGS+= -DGIT_EXEC_PATH=\"$(bindir)\"
+
+
$(LIB_OBJS): $(LIB_H)
$(patsubst git-%$X,%.o,$(PROGRAMS)): $(LIB_H)
$(DIFF_OBJS): diffcore.h
diff --git a/cache.h b/cache.h
index 29c9e81..d73071e 100644
--- a/cache.h
+++ b/cache.h
@@ -244,6 +244,7 @@ unsigned long approxidate(const char *);
extern int setup_ident(void);
extern const char *git_author_info(void);
extern const char *git_committer_info(void);
+extern void git_setup_exec_path(void);
struct checkout {
const char *base_dir;
diff --git a/environment.c b/environment.c
index 0596fc6..4dc0249 100644
--- a/environment.c
+++ b/environment.c
@@ -9,6 +9,10 @@
*/
#include "cache.h"
+#ifndef GIT_EXEC_PATH
+#define GIT_EXEC_PATH NULL
+#endif
+
char git_default_email[MAX_GITNAME];
char git_default_name[MAX_GITNAME];
int trust_executable_bit = 1;
@@ -16,6 +20,7 @@ int only_use_symrefs = 0;
int repository_format_version = 0;
char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
int shared_repository = 0;
+char *git_exec_path = GIT_EXEC_PATH;
static char *git_dir, *git_object_dir, *git_index_file, *git_refs_dir,
*git_graft_file;
@@ -76,4 +81,28 @@ char *get_graft_file(void)
return git_graft_file;
}
+void git_setup_exec_path(void)
+{
+ char *path, *old_path = getenv("PATH");
+ int path_len, len, old_len;
+ char *exec_path = getenv("GIT_EXEC_PATH");
+
+ if (!exec_path)
+ exec_path = git_exec_path;
+
+ len = strlen(exec_path);
+
+ if (!old_path)
+ old_path = "/usr/local/bin:/usr/bin:/bin";
+ old_len = strlen(old_path);
+ path_len = len + old_len + 1;
+
+ path = malloc(path_len + 1);
+
+ memcpy(path, old_path, old_len);
+ path[old_len] = ':';
+ memcpy(path + old_len + 1, exec_path, len);
+
+ setenv("PATH", path, 1);
+}
--
0.99.9m-g02ad
^ permalink raw reply related
* Re: git pull on Linux/ACPI release tree
From: Martin Langhoff @ 2006-01-09 23:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Luben Tuikov, Brown, Len, Luck, Tony, Junio C Hamano,
David S. Miller, linux-acpi, linux-kernel, akpm, git
In-Reply-To: <Pine.LNX.4.64.0601091502200.5588@g5.osdl.org>
On 1/10/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Using many branches in the same tree is
> definitely the better approach for _distribution_, but that doesn't
> necessarily mean that it's the better one for development.
(...)
> So git certainly supports that kind of behaviour, but nobody I know
> actually does it that way
Hrm! We do. http://locke.catalyst.net.nz/gitweb?p=moodle.git;a=heads
shows a lot of heads that share 99% of the code. The repo is ~90MB --
and we check each head out with cogito, develop and push. It is a
shared team repo, using git+ssh and sticky gid and umask 002.
Works pretty well I have to add. The only odd thing is that the
fastest way to actually start working on a new branch is to ssh on to
the server and cp moodle.git/refs/heads/{foo,bar} and then cg-clone
that bar branch away. Perhaps I should code up an 'cg-branch-add
--in-server' patch.
regards,
martin
^ permalink raw reply
* [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Michal Ostrowski @ 2006-01-09 23:36 UTC (permalink / raw)
To: git
In-Reply-To: <1136849678.11717.514.camel@brick.watson.ibm.com>
Calls to git_setup_exec_path() are inserted on paths that will execute
other git programs. git_setup_exec_path() will ensure that the git
installation directories are in the path.
Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com>
---
daemon.c | 2 ++
fetch-clone.c | 2 ++
run-command.c | 1 +
send-pack.c | 2 ++
upload-pack.c | 4 +++-
5 files changed, 10 insertions(+), 1 deletions(-)
bb14b4b61f53f755486695e5bdc45b5623a6f8c5
diff --git a/daemon.c b/daemon.c
index 3bd1426..d653f33 100644
--- a/daemon.c
+++ b/daemon.c
@@ -226,6 +226,8 @@ static int upload(char *dir)
snprintf(timeout_buf, sizeof timeout_buf, "--timeout=%u", timeout);
+ git_setup_exec_path();
+
/* git-upload-pack only ever reads stuff, so this is safe */
execlp("git-upload-pack", "git-upload-pack", "--strict", timeout_buf,
".", NULL);
return -1;
diff --git a/fetch-clone.c b/fetch-clone.c
index f46fe6e..afbbb79 100644
--- a/fetch-clone.c
+++ b/fetch-clone.c
@@ -98,6 +98,8 @@ int receive_unpack_pack(int fd[2], const
int status;
pid_t pid;
+ git_setup_exec_path();
+
pid = fork();
if (pid < 0)
die("%s: unable to fork off git-unpack-objects", me);
diff --git a/run-command.c b/run-command.c
index 8bf5922..993a3f9 100644
--- a/run-command.c
+++ b/run-command.c
@@ -9,6 +9,7 @@ int run_command_v_opt(int argc, char **a
if (pid < 0)
return -ERR_RUN_COMMAND_FORK;
if (!pid) {
+ git_setup_exec_path();
if (flags & RUN_COMMAND_NO_STDIO) {
int fd = open("/dev/null", O_RDWR);
dup2(fd, 0);
diff --git a/send-pack.c b/send-pack.c
index cd36193..a241f00 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -30,6 +30,7 @@ static void exec_pack_objects(void)
"--stdout",
NULL
};
+ git_setup_exec_path();
execvp("git-pack-objects", args);
die("git-pack-objects exec failed (%s)", strerror(errno));
}
@@ -58,6 +59,7 @@ static void exec_rev_list(struct ref *re
refs = refs->next;
}
args[i] = NULL;
+ git_setup_exec_path();
execvp("git-rev-list", args);
die("git-rev-list exec failed (%s)", strerror(errno));
}
diff --git a/upload-pack.c b/upload-pack.c
index 1834b6b..f8d4fbe 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -270,7 +270,9 @@ int main(int argc, char **argv)
break;
}
}
-
+
+ git_setup_exec_path();
+
if (i != argc-1)
usage(upload_pack_usage);
dir = argv[i];
--
0.99.9m-g02ad
^ permalink raw reply related
* Re: git-bisect is magical
From: Linus Torvalds @ 2006-01-09 23:38 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dpuoqf$3rp$1@sea.gmane.org>
On Mon, 9 Jan 2006, walt wrote:
>
> Arthur C. Clarke's Third Law states: Any sufficiently advanced
> technology is indistinguishable from magic.
>
> You guys have done it -- I can't distinguish git-bisect from
> magic. It's wonderful, and thank you!
Hey, I'm pretty damn happy with it myself, if I may say so ;)
It's the _one_ feature that we really never had with BK, and that git does
really really well.
> I have one minor suggestion for howto/isolate-bugs-with-bisect.
> Linus states:
> git bisect good ORIG_HEAD <- mark ORIG_HEAD as good (or
> whatever other known-good
> thing you booted last)
>
> Well, in my case, I new the last good kernel was *two* updates ago,
> so ORIG_HEAD wasn't the right thing to use. I had to guess what
> to type instead of 'ORIG_HEAD'.
Well, instead of guessing, you can always do the safe thing, and just try,
or just going far enough back to be really safe.
The "go far back" case is obviously wasteful, and if you go _too_ far
back, you'll just spend a long time bisecting, but on the other hand,
a binary search is pretty damned efficient, so even going back _way_ too
far usually just results in a couple more bisection attempts.
But if you're unsure, before marking somethng "good", you can just test it
out first, by doing something like
git checkout -b test <version-to-test-here>
and compiling and testing that one. If it's good, you can just do a simple
"git bisect good" to say that the current state was good..
Oh, and in general you don't ever have to name the good/bad ones: the
example in Documentation/howto states that you should say
git bisect bad master
git bisect good ORIG_HEAD
but the fact is, whenever you leave off the version specifier, it will
just assume that "current HEAD" is it. So quite often, a "git bisect" run
will start with just a simple
git bisect bad
to mark that the current head is bad (of course, that's 100% equivalent to
saying "git bisect bad master" if you are on the master branch right
then).
And if you don't remember what your last good kernel was, but you're sure
that the last full release was good, you can just do
git bisect good v2.6.15
and be done with it.
(Of course, right now there's 2075 commits in my git tree after 2.6.15, so
that's a fair amount of bisecting.. But let's say that you had known more
exactly, and been able to start off with just 300 commits - you only have
to do three "bisect" runs to whittle the 2075 commits down to that range
anyway - so it's not like you are totally screwed even if you don't know
where the good one was).
> Which leads to one more question: I have my kernel configured to
> add the -gxxxxxxxx localversion string to the kernel name.
Good man.
> I took
> a wild guess that the xxxxxxxx was the right thing to substitute
> for 'ORIG_HEAD' and I got lucky.
Yes. I guess we should document what the "-gxxxxx" thing means in the
kernel, and that it's simply the short-hand git name for the top commit
when the kernel was compiled. So you did exactly the right thing.
> But what about someone who
> doesn't know the magic 'xxxxxxxx' to use? If I didn't know enough
> to keep a week's worth of daily kernel-builds with the 'xxxxxxxx'
> to guide me, would I still be able to do what I did today?
Yes. See above. It certainly takes you more effort, but it's not _hugely_
more effort.
> (For example, if this had been a 'git' bug instead of a kernel bug,
> I don't think I could have figured out how to use git-bisect to find
> the bug -- could I?)
Well, if you know how git works internally, it's actually fairly easy to
do with any random project. You could, for example, just test whether
git-1.0.6 was good first. Or, again, just use a sledge-hammer, and go for
the original 1.0.
The alternative is to just ignore tagged versions altogether, and go by
date. For example, you could do something like
git log --since=1.week.ago
and just go to the end (right now, for me, that would be commit 8b32572,
aka "git-init-db(1): Describe --shared and .."). Again, just do
git checkout -b test 8b32572
and try that. If it was good, just mark it good and go from there. The
test cycle for git is going to be a lot faster than the test cycle for the
kernel, so you'll find any bug in no time.
Linus
^ permalink raw reply
* Re: git-bisect is magical
From: Andreas Ericsson @ 2006-01-09 23:39 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dpuoqf$3rp$1@sea.gmane.org>
walt wrote:
>
> I have one minor suggestion for howto/isolate-bugs-with-bisect.
> Linus states:
> git bisect good ORIG_HEAD <- mark ORIG_HEAD as good (or
> whatever other known-good
> thing you booted last)
>
> Well, in my case, I new the last good kernel was *two* updates ago,
> so ORIG_HEAD wasn't the right thing to use. I had to guess what
> to type instead of 'ORIG_HEAD'.
>
It would be neat if resets could optionally be stored as unannotated
tags as well as ORIG_HEAD, with a date and time in the tag-name.
git tag reset-$(date '+%F_%H.%M.%S')
works fine for me, although I expect the quibbling about the date-format
will never stop. I'll get going on it tomorrow unless I get some
seriously vehement requests not to, or someone beats me to it.
If someone *does* beat me to it, perhaps "git reset --clean-tags" should
be implemented as well?
> Which leads to one more question: I have my kernel configured to
> add the -gxxxxxxxx localversion string to the kernel name. I took
> a wild guess that the xxxxxxxx was the right thing to substitute
> for 'ORIG_HEAD' and I got lucky. But what about someone who
> doesn't know the magic 'xxxxxxxx' to use?
I expect you remember the date and approximate time you built it so the
--tag option should work fairly well there, I'd say. Otherwise, tagging
the build like you do is a very good idea.
>If I didn't know enough
> to keep a week's worth of daily kernel-builds with the 'xxxxxxxx'
> to guide me, would I still be able to do what I did today?
> (For example, if this had been a 'git' bug instead of a kernel bug,
> I don't think I could have figured out how to use git-bisect to find
> the bug -- could I?)
>
Most likely not as easily, although it would have been fairly easy to
mark the most recent tag as a known good build, or Linus' latest tree
from upstream.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [ANNOUCNE] GIT 1.1.0
From: lamikr @ 2006-01-09 23:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwth9f1nk.fsf@assigned-by-dhcp.cox.net>
>Ah, sorry, and thanks for catching this. RPM building procedure
>is somewhat tricky, and I failed to catch this bug. Fixed in my
>tree --- this calls for an early 1.1.1 release I guess.
>
>On the other hand, if you are building from the source, what
>Andreas said applies, and in addition you need to fetch v1.1.0
>tag before building; otherwise the versioning mechanism would not
>notice you are building v1.1.0.
>
>
I was not using git for fetching git sources,
I have build from the git 1.1.0.tar.bz2.
Did you mean that things should work after 1.1.1 is released?
I tried to fresh build and install of 1.1.0 on top of the previous
1.1.0 build but "git --version" is still displaying me "git version 1.0.GIT"
Mika
^ permalink raw reply
* Re: [ANNOUCNE] GIT 1.1.0
From: Andreas Ericsson @ 2006-01-10 0:22 UTC (permalink / raw)
To: lamikr; +Cc: Junio C Hamano, git
In-Reply-To: <43C2F7E2.4090909@cc.jyu.fi>
lamikr wrote:
>>Ah, sorry, and thanks for catching this. RPM building procedure
>>is somewhat tricky, and I failed to catch this bug. Fixed in my
>>tree --- this calls for an early 1.1.1 release I guess.
>>
>>On the other hand, if you are building from the source, what
>>Andreas said applies, and in addition you need to fetch v1.1.0
>>tag before building; otherwise the versioning mechanism would not
>>notice you are building v1.1.0.
>>
>>
>
> I was not using git for fetching git sources,
> I have build from the git 1.1.0.tar.bz2.
>
> Did you mean that things should work after 1.1.1 is released?
Not unless you build from the git-repo, no.
Snapshots will fail to set the "proper" version every time, because the
GIT-VERSION-FILE: is a forced target and even if git-describe is present
it will find neither tags nor HEAD.
I have no solution to this, apart from rewriting the Makefile on the fly
whenever a release tarball is created.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [ANNOUCNE] GIT 1.1.0
From: Junio C Hamano @ 2006-01-10 0:28 UTC (permalink / raw)
To: lamikr; +Cc: git
In-Reply-To: <43C2F7E2.4090909@cc.jyu.fi>
lamikr <lamikr@cc.jyu.fi> writes:
> Did you mean that things should work after 1.1.1 is released?
> I tried to fresh build and install of 1.1.0 on top of the previous
> 1.1.0 build but "git --version" is still displaying me "git version 1.0.GIT"
You need to build from a git repository for these automated
version numbers to work, and this will *not* change post 1.1.1.
But with the patch I sent out earlier, you should be able to:
$ VN=1.1.1 make
in a non-git repository (e.g. an untarred directory from a
tarball). What the patch fixes is to fix it for RPM binary
packages.
I expect that people building from the source do so from a git
repository not from a tarball, except when bootstrapping, so
hopefully this should not be too much of a problem.
^ permalink raw reply
* Re: [ANNOUCNE] GIT 1.1.0
From: Junio C Hamano @ 2006-01-10 1:21 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43C2FE4A.50203@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> I have no solution to this, apart from rewriting the Makefile on the
> fly whenever a release tarball is created.
Well, there is always an option to update the fallback version
number hardcoded in GIT-VERSION-GEN script, but that kind fo
defeats the whole idea of the current setup, so...
^ permalink raw reply
* Re: [ANNOUCNE] GIT 1.1.0
From: H. Peter Anvin @ 2006-01-10 2:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: lamikr, git
In-Reply-To: <7v7j99exkc.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> lamikr <lamikr@cc.jyu.fi> writes:
>
>>Did you mean that things should work after 1.1.1 is released?
>>I tried to fresh build and install of 1.1.0 on top of the previous
>>1.1.0 build but "git --version" is still displaying me "git version 1.0.GIT"
>
> You need to build from a git repository for these automated
> version numbers to work, and this will *not* change post 1.1.1.
>
Tarballs really should work as-is... the easy way to deal with that is
to have the tarball make script generate a version file which isn't part
of the git tree.
I'll send a patch under a separate cover.
-hpa
^ permalink raw reply
* [PATCH] For release tarballs, include the proper version
From: H. Peter Anvin @ 2006-01-10 2:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsn1f1lb.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 196 bytes --]
When producing a release tarball, include a "version" file, which
GIT-VERSION-GEN can then use to do the right thing when building from a
tarball.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
[-- Attachment #2: gitver --]
[-- Type: text/plain, Size: 1085 bytes --]
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 845b9dc..7763639 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -1,9 +1,15 @@
#!/bin/sh
GVF=GIT-VERSION-FILE
+DEF_VER=v1.1.GIT
-VN=$(git-describe --abbrev=4 HEAD 2>/dev/null) || VN=v1.0.GIT
-VN=$(expr "$VN" : v'\(.*\)')
+# First try git-describe, then see if there is a version file
+# (included in release tarballs), then default
+VN=$(git-describe --abbrev=4 HEAD 2>/dev/null) ||
+VN=$(cat version) ||
+VN="$DEF_VER"
+
+VN=$(expr "$VN" : v*'\(.*\)')
if test -r $GVF
then
VC=$(sed -e 's/^GIT_VERSION = //' <$GVF)
diff --git a/Makefile b/Makefile
index c9c15b5..fa0cd83 100644
--- a/Makefile
+++ b/Makefile
@@ -489,7 +489,9 @@ dist: git.spec git-tar-tree
./git-tar-tree HEAD $(GIT_TARNAME) > $(GIT_TARNAME).tar
@mkdir -p $(GIT_TARNAME)
@cp git.spec $(GIT_TARNAME)
- $(TAR) rf $(GIT_TARNAME).tar $(GIT_TARNAME)/git.spec
+ @echo $(GIT_VERSION) > $(GIT_TARNAME)/version
+ $(TAR) rf $(GIT_TARNAME).tar \
+ $(GIT_TARNAME)/git.spec $(GIT_TARNAME)/version
@rm -rf $(GIT_TARNAME)
gzip -f -9 $(GIT_TARNAME).tar
^ permalink raw reply related
* RE: git pull on Linux/ACPI release tree
From: Linus Torvalds @ 2006-01-10 2:50 UTC (permalink / raw)
To: Luben Tuikov
Cc: Brown, Len, Luck, Tony, Junio C Hamano, Martin Langhoff,
David S. Miller, linux-acpi, linux-kernel, akpm, git
In-Reply-To: <20060109225143.60520.qmail@web31807.mail.mud.yahoo.com>
On Mon, 9 Jan 2006, Luben Tuikov wrote:
>
> A very general workflow I've seen people use is more/less as
> I outlined in my previous email:
>
> tree A (linus' or trunk)
> Project B (Tree B)
> Project C (Tree C, depending on stuff in Project B)
>
> Now this could be how the "managers" see things, but development,
> could've "cloned" from Tree B and Tree C further, as is often
> customary to have a a) per user tree, or b) per bug tree.
>
> So pull/merge/fetch/whatever follows Tree A->B->C.
>
> It is sensible to have another tree say, called something
> like "for_linus" or "upstream" or "product" which includes
> what has accumulated in C from B and in B from A, (eq diff(C-A)).
> I.e. a "push" tree. So that I can tell you, "hey,
> pull/fetch/merge/whatever the current verb en vogue is, from
> here to get latest xyz".
>
> What I also wanted to mention is that Tree B undeniably
> depends on the _latest_ state of Tree A, since Project B
> uses API/behaviour of the code in Tree A, so one cannot just
> say they are independent. Similarly for Tree C/Project C,
> is dependent on B, and dependent on A.
Note that in the case where the _latest_ state of the tre you are tracking
really matters, then doing a "git pull" is absolutely and unquestionably
the right thing to do.
So if people thought that I don't want to have sub-maintainers pulling
from my tree _at_all_, then that was a mis-communication. I don't in any
way require a linear history, and criss-cross merges are supported
perfectly well by git, and even encouraged in those situations.
After all, if tree B starts using features that are new to tree A, then
the merge from A->B is required for functionality, and the synchronization
is a fundamental part of the history of development. In that cases, the
history complexity of the resulting tree is a result of real development
complexity.
Now, obviously, for various reasons we want to avoid having those kinds of
linkages as much as possible. We like to have develpment of different
subsystems as independent as possible, not because it makes for a "more
readable history", but because it makes it a lot easier to debug - if we
have three independent features/development trees, they can be debugged
independently too, while any linkages inevitably also mean that any bugs
end up being interlinked..
Linus
^ permalink raw reply
* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Junio C Hamano @ 2006-01-10 2:52 UTC (permalink / raw)
To: Michal Ostrowski; +Cc: git
In-Reply-To: <1136849810.11717.518.camel@brick.watson.ibm.com>
Michal Ostrowski <mostrows@watson.ibm.com> writes:
> Calls to git_setup_exec_path() are inserted on paths that will execute
> other git programs. git_setup_exec_path() will ensure that the git
> installation directories are in the path.
About fetch-clone.c (which is shared by fetch-pack and
clone-pack), it runs "git-index-pack" from finish_pack and
"git-unpack-objects" from unpack_pack, so spelling these exec
with execlp("git", "git", "index-pack", ...) might be cleaner,
since "git" is required to be in users' PATH even though git-*
may be moved out of the PATH in later versions of git. I
dunno...
In send-pack.c, I wonder why you didn't do a setup_exec_path()
at the beginning of main() instead of having two calls close to
exec*() call site.
The same comment applies for run-command.c; you do it once for
each child, but calling it once at the beginning of receive-pack
would be good enough. The same thing for daemon.c.
I suspect you are trying to limit the extent of damage, but I do
not think of a downside if we just call setup_exec_path() once
at the beginning of main(). $GIT_EXEC_PATH _could_ have a
private copy of broken "diff" to confuse diff-* family, but you
cannot say "git diff" in such a setup anyway because "git" does
the PATH prefixing already, so it would be a moot point.
Here is the list my "nm | grep ' exec[vlpe]*\($\|@@\)'" found
that use some variant of exec* family (except "git-diff-*"):
clone-pack
daemon
fetch-pack
merge-index
peek-remote
receive-pack
send-pack
shell
ssh-fetch/ssh-pull
ssh-upload/ssh-push
upload-pack
I do not care too much about ssh-* commit walkers (users can say
e.g. GIT_SSH_PUSH themselves).
Anyway, thanks for starting this. I need a bit more thought and
a bit of list discussion to convince myself this is a good
change.
^ permalink raw reply
* [PATCH] show-branch: take default arguments from configuration file.
From: Junio C Hamano @ 2006-01-10 2:53 UTC (permalink / raw)
To: git
This lets showbranch.default multivalued configuration item to
be used as the default set of parameters to git-show-branch when
none is given on the command line.
I keep many topic branches (e.g. zzz/pack, net/misc) and
branches used only as a reference under subdirectories
(e.g. hold/{html,man,todo} track the same from git.git, but
clutters the show-branch output when shown along with the main
development; ko/master tracks what I have pushed out already and
refetched from the kernel.org server), and often run:
$ git show-branch ko/master heads/*
to view only the ko/master head and branches I keep immediately
under $GIT_DIR/refs/heads. With this change, I can have this in
my $GIT_DIR/config file:
[showbranch]
default = ko/master
default = heads/*
and say
$ git show-branch
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This is "master" aka "toward 1.2" material, not meant for
1.1.1, but maybe we should allow trivial backports? I
haven't decided.
show-branch.c | 32 +++++++++++++++++++++++++++++++-
1 files changed, 31 insertions(+), 1 deletions(-)
680c6ea5291057fcba95f00455260ab1c1b242eb
diff --git a/show-branch.c b/show-branch.c
index 15b1968..f43c406 100644
--- a/show-branch.c
+++ b/show-branch.c
@@ -7,6 +7,10 @@
static const char show_branch_usage[] =
"git-show-branch [--all] [--heads] [--tags] [--topo-order] [--more=count | --list | --independent | --merge-base ] [<refs>...]";
+static int default_num = 0;
+static int default_alloc = 0;
+static char **default_arg = NULL;
+
#define UNINTERESTING 01
#define REV_SHIFT 2
@@ -508,6 +512,21 @@ static void append_one_rev(const char *a
die("bad sha1 reference %s", av);
}
+static int git_show_branch_config(const char *var, const char *value)
+{
+ if (!strcmp(var, "showbranch.default")) {
+ if (default_alloc <= default_num + 1) {
+ default_alloc = default_alloc * 3 / 2 + 20;
+ default_arg = xrealloc(default_arg, sizeof *default_arg * default_alloc);
+ }
+ default_arg[default_num++] = strdup(value);
+ default_arg[default_num] = NULL;
+ return 0;
+ }
+
+ return git_default_config(var, value);
+}
+
int main(int ac, char **av)
{
struct commit *rev[MAX_REVS], *commit;
@@ -527,11 +546,22 @@ int main(int ac, char **av)
int shown_merge_point = 0;
int topo_order = 0;
+ git_config(git_show_branch_config);
setup_git_directory();
+ /* If nothing is specified, try the default first */
+ if (ac == 1 && default_num) {
+ ac = default_num + 1;
+ av = default_arg - 1; /* ick; we would not address av[0] */
+ }
+
while (1 < ac && av[1][0] == '-') {
char *arg = av[1];
- if (!strcmp(arg, "--all"))
+ if (!strcmp(arg, "--")) {
+ ac--; av++;
+ break;
+ }
+ else if (!strcmp(arg, "--all"))
all_heads = all_tags = 1;
else if (!strcmp(arg, "--heads"))
all_heads = 1;
--
1.1.0
^ permalink raw reply related
* Re: [PATCH 1/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Junio C Hamano @ 2006-01-10 2:53 UTC (permalink / raw)
To: Michal Ostrowski; +Cc: git
In-Reply-To: <1136849754.11717.517.camel@brick.watson.ibm.com>
Michal Ostrowski <mostrows@watson.ibm.com> writes:
> If git-upload-pack is invoked by ssh, it may have been invoked because
> ssh was explicitly told which program to execute on the remote end
> (i.e. --exec had been used with git-clone-pack). In this case, the
> git suite may not be in the PATH, and so subsequent exec's by
> git-upload-pack (i.e. git-rev-list, git-pack-objects) will fail.
True.
> +.environment.GIT_EXEC_PATH:
> + @(test -e $@ && grep -h -e '^$(bindir)$$' $@) || echo $(bindir) > $@
Hmph.
* I did not know "test -e" was portable (it is in POSIX.1),
but since you are creating the file yourself anyway,
wouldn't "test -f" look more familiar?
* Perhaps grep -F (--fixed-strings), not as regexp?
* I do not get the point of using "grep -h" here (it's not in
POSIX.1). Perhaps just >/dev/null?
But I like the timestamp trick here that uses ||. Maybe I
should borrow it for GIT-VERSION-GEN. Maybe not.
> --- a/environment.c
> +++ b/environment.c
> @@ -9,6 +9,10 @@
> */
> #include "cache.h"
>
> +#ifndef GIT_EXEC_PATH
> +#define GIT_EXEC_PATH NULL
> +#endif
I wonder if not having GIT_EXEC_PATH defined should be an error here.
> +void git_setup_exec_path(void)
> +{
>...
> +}
Maybe move git.c::prepend_to_path() to a single library file and
use it here?
^ permalink raw reply
* [PATCH] GIT-VERSION-GEN: detect dirty tree and mark the version accordingly.
From: Junio C Hamano @ 2006-01-10 2:53 UTC (permalink / raw)
To: git
If we are building from a working tree with local modifications,
mark the version accordingly.
Deliberately uses '-' to prevent RPM from being built from such
a tree.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This is a useful precaution and should be safe, so planned to
go into 1.1.1.
GIT-VERSION-GEN | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
339b684aa42ac80964ef0d9049445dad7f83848c
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index c878819..cb393b5 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -11,6 +11,14 @@ set)
;;
esac
+dirty=$(sh -c 'git-diff-files --name-only HEAD' 2>/dev/null) || dirty=
+case "$dirty" in
+'')
+ ;;
+*)
+ VN="$VN-dirty" ;;
+esac
+
if test -r $GVF
then
VC=$(sed -e 's/^GIT_VERSION = //' <$GVF)
--
1.1.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox