* [RFC] qgit with tabs
From: Marco Costalba @ 2006-05-13 10:44 UTC (permalink / raw)
To: git
Hi all,
I have pushed some patches that add tabs to qgit UI.
I don't expect a new release any time soon, but I am interested to
hear comments, especially on the usability front, so to be able to
steer new development in advance.
With new UI I found myself more and more using keyboard bindings
instead of mouse:
- r, p, f to switch to revisions list, patch and file views respectively
- t to toggle tree view
- s to toggle split view (very useful IMHO)
NOTE:
Due to some repacking on a dumb host probably you need to re-clone:
git clone http://digilander.libero.it/mcostalba/scm/qgit.git
cd qgit
autoreconf -i
./configure
make
make install-strip
Marco
^ permalink raw reply
* Re: Tracking branch history
From: Shawn Pearce @ 2006-05-13 7:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060513071753.GA21998@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> Junio C Hamano <junkio@cox.net> wrote:
> > Shawn Pearce <spearce@spearce.org> writes:
> >
> > > git-udpate-ref. So just have it append the ref's history to a file:
> > >
> > > .git/log/refs/heads/$branch
> > >
> > > where the history records are stored as:
> > >
> > > 40 byte commit-ish SHA1
> > > <SP>
> > > <committer>
> > > <LF>
> > >
> > > e.g.:
> > >
> > > cbb6d91d95e523c2b6a6b52577c4be28d18ace83 Shawn O. Pearce <spearce@spearce.org> 1137039378 -0500
> > > ae8c74e96a1e02bbfb7f1a9669b77d6f8ee6c3cf Shawn O. Pearce <spearce@spearce.org> 1136921470 -0500
> > >
> >
> > Because the question we often would want to ask is "two days ago
> > my tip worked but today it does not", recording the timestamp
> > makes sense, but I do not know what the point is for the name
> > and e-mail. If it is in your local repository (i.e. the program
> > that updates the tip ref is not receive-pack which is invoked by
> > your pushing into a remote repo), it will always be you. And in
> > the receive-pack case, the information is not available to begin
> > with (you may have a UNIX UID but that is about it).
Forget my last patch. This one automatically creates the log file
by looking for a config value of 'core.logRefUpdates=true'.
--> -
Log ref updates to logs/refs/<ref>
If config parameter core.logRefUpdates is true then append a line
to .git/logs/refs/<ref> whenever git-update-ref <ref> is executed.
Each log line contains the following information:
40 byte tree-ish SHA1
<SP>
date/time
<LF>
where date/time is the current date, time and timezone in the
standard GIT date format. If the caller is unable to append to
the log file then git-update-ref will fail without updating <ref>.
---
Documentation/config.txt | 7 ++++++
Documentation/git-update-ref.txt | 17 +++++++++++++++
cache.h | 1 +
config.c | 5 ++++
environment.c | 1 +
update-ref.c | 43 +++++++++++++++++++++++++++++++++++---
6 files changed, 71 insertions(+), 3 deletions(-)
cac86f2df9a52d94cb03038e267934c67f04122b
diff --git a/Documentation/config.txt b/Documentation/config.txt
index d1a4bec..f06695c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -70,6 +70,13 @@ core.preferSymlinkRefs::
This is sometimes needed to work with old scripts that
expect HEAD to be a symbolic link.
+core.logRefUpdates::
+ If true, `git-update-ref` will append a line to
+ "$GIT_DIR/logs/<ref>" listing the new SHA1 and the date/time
+ of the update. This information can be used to determine
+ what commit was the tip of a branch "2 days ago". This value
+ is false by default (no logging).
+
core.repositoryFormatVersion::
Internal variable identifying the repository format and layout
version.
diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
index 475237f..8c46263 100644
--- a/Documentation/git-update-ref.txt
+++ b/Documentation/git-update-ref.txt
@@ -49,6 +49,23 @@ for reading but not for writing (so we'l
ref symlink to some other tree, if you have copied a whole
archive by creating a symlink tree).
+Logging Updates
+---------------
+If config parameter "core.logRefUpdates" is true then
+`git-update-ref` will append a line to the log file
+"$GIT_DIR/logs/<ref>" (dereferencing all symbolic refs before
+creating the log name) describing the change in ref value. Log lines
+are formatted as:
+
+ . sha1 SP date LF
++
+Where "sha1" is the 40 character hexadecimal value of <newvalue>
+and "date" is the current date/time and timezone in the standard
+GIT date format.
+
+An update will fail (without changing <ref>) if the current user is
+unable to create a new log file or append to the existing log file.
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>.
diff --git a/cache.h b/cache.h
index b1300cd..887ce20 100644
--- a/cache.h
+++ b/cache.h
@@ -171,6 +171,7 @@ extern void rollback_index_file(struct c
extern int trust_executable_bit;
extern int assume_unchanged;
extern int prefer_symlink_refs;
+extern int log_ref_updates;
extern int warn_ambiguous_refs;
extern int diff_rename_limit_default;
extern int shared_repository;
diff --git a/config.c b/config.c
index 0f518c9..f8a814e 100644
--- a/config.c
+++ b/config.c
@@ -232,6 +232,11 @@ int git_default_config(const char *var,
return 0;
}
+ if (!strcmp(var, "core.logrefupdates")) {
+ log_ref_updates = git_config_bool(var, value);
+ return 0;
+ }
+
if (!strcmp(var, "core.warnambiguousrefs")) {
warn_ambiguous_refs = git_config_bool(var, value);
return 0;
diff --git a/environment.c b/environment.c
index 444c99e..437266e 100644
--- a/environment.c
+++ b/environment.c
@@ -14,6 +14,7 @@ char git_default_name[MAX_GITNAME];
int trust_executable_bit = 1;
int assume_unchanged = 0;
int prefer_symlink_refs = 0;
+int log_ref_updates = 0;
int warn_ambiguous_refs = 1;
int repository_format_version = 0;
char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
diff --git a/update-ref.c b/update-ref.c
index fd48742..c231760 100644
--- a/update-ref.c
+++ b/update-ref.c
@@ -22,7 +22,7 @@ int main(int argc, char **argv)
const char *refname, *value, *oldval, *path;
char *lockpath;
unsigned char sha1[20], oldsha1[20], currsha1[20];
- int fd, written;
+ int fd, written, pfxlen;
setup_git_directory();
git_config(git_default_config);
@@ -38,7 +38,9 @@ int main(int argc, char **argv)
if (oldval && get_sha1(oldval, oldsha1))
die("%s: not a valid old SHA1", oldval);
- path = resolve_ref(git_path("%s", refname), currsha1, !!oldval);
+ path = git_path("%s", refname);
+ pfxlen = strlen(path) - strlen(refname);
+ path = resolve_ref(path, currsha1, !!oldval);
if (!path)
die("No such ref: %s", refname);
@@ -50,7 +52,7 @@ int main(int argc, char **argv)
exit(0);
}
path = strdup(path);
- lockpath = mkpath("%s.lock", path);
+ lockpath = strdup(mkpath("%s.lock", path));
if (safe_create_leading_directories(lockpath) < 0)
die("Unable to create all of %s", lockpath);
@@ -75,6 +77,41 @@ int main(int argc, char **argv)
}
/*
+ * Write to the log if logging of ref updates is enabled
+ */
+ if (log_ref_updates) {
+ char *logpath;
+ char now[50];
+ char logrec[100];
+ unsigned len;
+ int logfd;
+
+ datestamp(now, sizeof(now));
+ len = snprintf(logrec, sizeof(logrec), "%s %s\n", sha1_to_hex(sha1), now);
+ if (len >= sizeof(logrec)) {
+ unlink(lockpath);
+ die("Internal error formatting log record.");
+ }
+
+ logpath = git_path("logs/%s", path + pfxlen);
+ if (safe_create_leading_directories(logpath) < 0) {
+ unlink(lockpath);
+ die("Unable to create all of %s", logpath);
+ }
+ logfd = open(logpath, O_CREAT | O_APPEND | O_WRONLY, 0666);
+ if (logfd < 0) {
+ unlink(lockpath);
+ die("Unable to append to log %s", logpath);
+ }
+ written = write(logfd, logrec, len);
+ if (written != len) {
+ unlink(lockpath);
+ die("Unable to append to %s", logpath);
+ }
+ close(logfd);
+ }
+
+ /*
* Finally, replace the old ref with the new one
*/
if (rename(lockpath, path) < 0) {
--
1.3.2.g7278
^ permalink raw reply related
* Re: Tracking branch history
From: Shawn Pearce @ 2006-05-13 7:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vody2v7yr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > git-udpate-ref. So just have it append the ref's history to a file:
> >
> > .git/log/refs/heads/$branch
> >
> > where the history records are stored as:
> >
> > 40 byte commit-ish SHA1
> > <SP>
> > <committer>
> > <LF>
> >
> > e.g.:
> >
> > cbb6d91d95e523c2b6a6b52577c4be28d18ace83 Shawn O. Pearce <spearce@spearce.org> 1137039378 -0500
> > ae8c74e96a1e02bbfb7f1a9669b77d6f8ee6c3cf Shawn O. Pearce <spearce@spearce.org> 1136921470 -0500
> >
>
> Because the question we often would want to ask is "two days ago
> my tip worked but today it does not", recording the timestamp
> makes sense, but I do not know what the point is for the name
> and e-mail. If it is in your local repository (i.e. the program
> that updates the tip ref is not receive-pack which is invoked by
> your pushing into a remote repo), it will always be you. And in
> the receive-pack case, the information is not available to begin
> with (you may have a UNIX UID but that is about it).
Agreed. Prototype patch below.
While writing this I discovered at least two chunks of GIT which
don't use git-update-ref: fetch.c and upload-pack.c. fetch.c uses
the APIs in refs.c but upload-pack.c doesn't. I spent a couple of
hours trying to convert update-ref.c to use the APIs in refs.c so
I could just put the logging change there, but that turned out to
be more difficult than expected for a simple prototype so it all
went out the window.
-- >-
Log ref updates to logs/refs/<refname>
If .git/logs/refs/<refname> exists then append a line to it whenever
git-update-ref <refname> is executed. Each log line contains the
following information:
40 byte tree-ish SHA1
<SP>
date/time
<LF>
where date/time is the current date, time and timezone in the
standard GIT date format. If the caller is unable to append to
the log file and the log file exists then git-update-ref will fail
without updating <refname>.
---
Documentation/git-update-ref.txt | 15 ++++++++++++++
update-ref.c | 41 +++++++++++++++++++++++++++++++++++---
2 files changed, 53 insertions(+), 3 deletions(-)
8f1ccd3b0eda9d54eca37af178113c91174e81ca
diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
index 475237f..d314786 100644
--- a/Documentation/git-update-ref.txt
+++ b/Documentation/git-update-ref.txt
@@ -49,6 +49,21 @@ for reading but not for writing (so we'l
ref symlink to some other tree, if you have copied a whole
archive by creating a symlink tree).
+Logging Updates
+---------------
+If "$GIT_DIR/logs/<ref>" (possibly dereferencing symbolic refs)
+exists then `git-update-ref` will append a line to the log file
+describing the change in ref value. Log lines are formatted as:
+
+ . sha1 SP date LF
++
+Where "sha1" is the 40 character hexadecimal value of <newvalue>
+and "date" is the current date/time and timezone in the standard
+GIT date format.
+
+An update will fail (without changing <ref>) if the log file
+exists but the current user is unable to append to the file.
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>.
diff --git a/update-ref.c b/update-ref.c
index fd48742..bffe5f9 100644
--- a/update-ref.c
+++ b/update-ref.c
@@ -20,9 +20,9 @@ int main(int argc, char **argv)
{
char *hex;
const char *refname, *value, *oldval, *path;
- char *lockpath;
+ char *lockpath, *logpath;
unsigned char sha1[20], oldsha1[20], currsha1[20];
- int fd, written;
+ int fd, logfd, written, pfxlen;
setup_git_directory();
git_config(git_default_config);
@@ -38,7 +38,9 @@ int main(int argc, char **argv)
if (oldval && get_sha1(oldval, oldsha1))
die("%s: not a valid old SHA1", oldval);
- path = resolve_ref(git_path("%s", refname), currsha1, !!oldval);
+ path = git_path("%s", refname);
+ pfxlen = strlen(path) - strlen(refname);
+ path = resolve_ref(path, currsha1, !!oldval);
if (!path)
die("No such ref: %s", refname);
@@ -50,6 +52,17 @@ int main(int argc, char **argv)
exit(0);
}
path = strdup(path);
+
+ /*
+ * If logging is required make sure we can append to the log.
+ */
+ logpath = strdup(git_path("logs/%s", path + pfxlen));
+ logfd = open(logpath, O_APPEND | O_WRONLY, 0);
+ if (logfd < 0 && errno != ENOENT)
+ die("Unable to append to log %s", logpath);
+ if (logfd >= 0)
+ setup_ident();
+
lockpath = mkpath("%s.lock", path);
if (safe_create_leading_directories(lockpath) < 0)
die("Unable to create all of %s", lockpath);
@@ -75,6 +88,28 @@ int main(int argc, char **argv)
}
/*
+ * Write to the log, if it was opened.
+ */
+ if (logfd >= 0) {
+ char now[50];
+ char logrec[100];
+ unsigned len;
+
+ datestamp(now, sizeof(now));
+ len = snprintf(logrec, sizeof(logrec), "%s %s\n", sha1_to_hex(sha1), now);
+ if (len >= sizeof(logrec)) {
+ unlink(lockpath);
+ die("Internal error formatting log record.");
+ }
+ written = write(logfd, logrec, len);
+ if (written != len) {
+ unlink(lockpath);
+ die("Unable to append to %s", logpath);
+ }
+ close(logfd);
+ }
+
+ /*
* Finally, replace the old ref with the new one
*/
if (rename(lockpath, path) < 0) {
--
1.3.2.g7278
^ permalink raw reply related
* Re: [PATCH] Fix git-pack-objects for 64-bit platforms
From: Junio C Hamano @ 2006-05-13 5:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dennis Stosberg, git
In-Reply-To: <Pine.LNX.4.64.0605111218380.3866@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Since I _do_ have a 64-bit big-endian architecture, I decided to install
> some of the 64-bit development libraries that I didn't already have, and I
> added "-m64" to the compiler flags.
>
> All the tests seem to pass with the simple fix (and without it, we do
> indeed fail at least t5700-clone-reference.sh).
>
> Of course, there might well be something else that doesn't get coverage,
> but passing all tests is at least a good sign. And since x86-64 has been
> getting pretty extensive coverage, I don't think we have a lot of 64-bit
> bugs per se, this one just happened to hide.
>
> Linus
Thanks, both. This is what I am thinking of applying (but I am
sort of burned-out right now after a two-day meeting with my
sponsors, so the real work will be tomorrow).
It takes the uint32_t version but matches another place to use
that type instead of "int" (which would not matter in next 10
years perhaps).
-- >8 --
diff --git a/pack-objects.c b/pack-objects.c
index c0acc46..a81d609 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -156,7 +156,7 @@ static void prepare_pack_revindex(struct
rix->revindex = xmalloc(sizeof(unsigned long) * (num_ent + 1));
for (i = 0; i < num_ent; i++) {
- long hl = *((long *)(index + 24 * i));
+ uint32_t hl = *((uint32_t *)(index + 24 * i));
rix->revindex[i] = ntohl(hl);
}
/* This knows the pack format -- the 20-byte trailer
diff --git a/sha1_file.c b/sha1_file.c
index f2d33af..642c45a 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1126,7 +1126,7 @@ int find_pack_entry_one(const unsigned c
int mi = (lo + hi) / 2;
int cmp = memcmp(index + 24 * mi + 4, sha1, 20);
if (!cmp) {
- e->offset = ntohl(*((int*)(index + 24 * mi)));
+ e->offset = ntohl(*((uint32_t *)(index + 24 * mi)));
memcpy(e->sha1, sha1, 20);
e->p = p;
return 1;
^ permalink raw reply related
* Re: Tracking branch history
From: Junio C Hamano @ 2006-05-13 4:56 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060513034051.GA21586@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> git-udpate-ref. So just have it append the ref's history to a file:
>
> .git/log/refs/heads/$branch
>
> where the history records are stored as:
>
> 40 byte commit-ish SHA1
> <SP>
> <committer>
> <LF>
>
> e.g.:
>
> cbb6d91d95e523c2b6a6b52577c4be28d18ace83 Shawn O. Pearce <spearce@spearce.org> 1137039378 -0500
> ae8c74e96a1e02bbfb7f1a9669b77d6f8ee6c3cf Shawn O. Pearce <spearce@spearce.org> 1136921470 -0500
>
Because the question we often would want to ask is "two days ago
my tip worked but today it does not", recording the timestamp
makes sense, but I do not know what the point is for the name
and e-mail. If it is in your local repository (i.e. the program
that updates the tip ref is not receive-pack which is invoked by
your pushing into a remote repo), it will always be you. And in
the receive-pack case, the information is not available to begin
with (you may have a UNIX UID but that is about it).
^ permalink raw reply
* Re: Tracking branch history
From: Linus Torvalds @ 2006-05-13 4:38 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Daniel Barkalow, git
In-Reply-To: <20060513034051.GA21586@spearce.org>
On Fri, 12 May 2006, Shawn Pearce wrote:
>
> Why not intergrate this into git-update-ref. Almost every tool which
> deals with a GIT repository (aside from my pure-Java Eclipse plugin
> which is still a major work-in-process) performs ref changes through
> git-udpate-ref. So just have it append the ref's history to a file:
>
> .git/log/refs/heads/$branch
>
> where the history records are stored as:
>
> 40 byte commit-ish SHA1
> <SP>
> <committer>
> <LF>
Sure. Except it's not really "committer", in the ordinary sense (there's
no "commit" for a fast-forward). But yes, re-using that format (with date
and all) makes sense.
> Of course a major issue here is locking the log file during the ref
> update, but it looks like it might just be safe to append the entry
> to the log file right after the re_verify and before the rename.
I'd suggest just opening it with O_APPEND, and doing the update with a
single write() system call. Let the OS do the locking for you.
Linus
^ permalink raw reply
* Re: Tracking branch history
From: Daniel Barkalow @ 2006-05-13 4:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605121656350.3866@g5.osdl.org>
On Fri, 12 May 2006, Linus Torvalds wrote:
> Btw, the real problem with this is how to use it.
>
> The only really valid use I see is to use it for date-based things, ie if
> given a date, look up the most recent commit ID that is older than the
> date in question. No other op seems to really make sense, but that one
> does.
>
> Now, the one other operation that is semantically sensible is to use the
> list of commits to figure out a "path" through the commit space. However,
> that path won't actually even be well-defined (a fast-forward pull/merge
> can and often /will/ update the history in a way where it's impossible to
> select one particular path to the previous commit listed in the commit
> log).
I think that jumping around with reset is necessary to make this actually
complicated; a fast-forward only happens if the new value descends from
the old value, and a merge obviously descends from the old value. Sure,
the non-linear history added by a merge will still be non-linear, but
from the local user's point of view, it was all added in bulk by the
merge.
I think the program creating the history should note the tricky cases,
where the new value doesn't descend from the old value, which should be
easy to identify. I'm not sure what should actually be done to report a
reset in a changelog, either. The section of the log just before the reset
is clearly a false start of some sort, and you probably want to do
something special to list the commits which don't actually lead to the
current state, but you probably want to report them, in case the reason
you'd looking through this is that there was some benefit to a version
that you ended up discarding, and you want to revisit that attempt.
I think in the always-forward case, there's a useful optimization to be
had by having the rev-list-equivalent actually binning commits by the
earliest points that descend from them, so you don't trace the local
branch back to where other branches forked off over and over. But it seems
to me otherwise pretty simple.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Tracking branch history
From: Shawn Pearce @ 2006-05-13 3:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.64.0605121640210.3866@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
>
> On Fri, 12 May 2006, Daniel Barkalow wrote:
> >
> > One feature that might make git more intuitive to people is if we were to
> > additionally track the history of what commit was the head of each branch
> > over time. This is only vaguely related to the history of the content, but
> > it's well-defined and sometimes significant.
> >
> > E.g., if you know that two weeks ago, what you had worked, but it doesn't
> > work now, you can use git-bisect to figure out what happened, but first
> > you have to figure out what commit it was that you were using two weeks
> > ago. Two weeks ago, we had that information, but we didn't keep it.
>
> Note that this is possible, but it must be done literally as a separate
> history from the commit history.
>
> IOW, a good (?) way to do it is to literally have a commit hook that
> basically just does
>
> echo $new >> .git/$branch-commit-history
>
> possibly together with a datestamp thing (ie it could be something like
> "echo $new "$USER" $(date)" rather than just the commit SHA1).
Why not intergrate this into git-update-ref. Almost every tool which
deals with a GIT repository (aside from my pure-Java Eclipse plugin
which is still a major work-in-process) performs ref changes through
git-udpate-ref. So just have it append the ref's history to a file:
.git/log/refs/heads/$branch
where the history records are stored as:
40 byte commit-ish SHA1
<SP>
<committer>
<LF>
e.g.:
cbb6d91d95e523c2b6a6b52577c4be28d18ace83 Shawn O. Pearce <spearce@spearce.org> 1137039378 -0500
ae8c74e96a1e02bbfb7f1a9669b77d6f8ee6c3cf Shawn O. Pearce <spearce@spearce.org> 1136921470 -0500
Of course a major issue here is locking the log file during the ref
update, but it looks like it might just be safe to append the entry
to the log file right after the re_verify and before the rename.
I wouldn't have git-update-ref create the log file. I'd would only
have it append if the log already exists.
Hmm, this actually looks like it would be really easy. Maybe I'll
hack up an RFC patch this evening after dinner.
--
Shawn.
^ permalink raw reply
* Re: Tracking branch history
From: Linus Torvalds @ 2006-05-13 0:03 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605121640210.3866@g5.osdl.org>
On Fri, 12 May 2006, Linus Torvalds wrote:
>
> IOW, a good (?) way to do it is to literally have a commit hook that
> basically just does
>
> echo $new >> .git/$branch-commit-history
>
> possibly together with a datestamp thing (ie it could be something like
> "echo $new "$USER" $(date)" rather than just the commit SHA1).
Btw, the real problem with this is how to use it.
The only really valid use I see is to use it for date-based things, ie if
given a date, look up the most recent commit ID that is older than the
date in question. No other op seems to really make sense, but that one
does.
Now, the one other operation that is semantically sensible is to use the
list of commits to figure out a "path" through the commit space. However,
that path won't actually even be well-defined (a fast-forward pull/merge
can and often /will/ update the history in a way where it's impossible to
select one particular path to the previous commit listed in the commit
log).
The other thing that makes the "path" thing hard is that it's just
fundamentally a pretty hard thing to calculate, even when it would result
in one unambiguous path. I _believe_ that it comes close to what "git
bisect" does, and that the bisect algorithm could probably be used to
always create _a_ path between each commit (is just pick successive
half-way-points - the commit list _should_ always have a direct dominance
relationship, but the bisection algorithm should do something half-way
sane even if you "jump about" by "git reset" or something).
It might be interesting to see if it's somethign that can be done
reasonably efficiently.
Linus
^ permalink raw reply
* Re: Tracking branch history
From: Linus Torvalds @ 2006-05-12 23:45 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605121838490.6713@iabervon.org>
On Fri, 12 May 2006, Daniel Barkalow wrote:
>
> One feature that might make git more intuitive to people is if we were to
> additionally track the history of what commit was the head of each branch
> over time. This is only vaguely related to the history of the content, but
> it's well-defined and sometimes significant.
>
> E.g., if you know that two weeks ago, what you had worked, but it doesn't
> work now, you can use git-bisect to figure out what happened, but first
> you have to figure out what commit it was that you were using two weeks
> ago. Two weeks ago, we had that information, but we didn't keep it.
Note that this is possible, but it must be done literally as a separate
history from the commit history.
IOW, a good (?) way to do it is to literally have a commit hook that
basically just does
echo $new >> .git/$branch-commit-history
possibly together with a datestamp thing (ie it could be something like
"echo $new "$USER" $(date)" rather than just the commit SHA1).
Make sure that not just "git commit", but anything else that changes the
branch (notably, "git fetch" and a fast-forward merge as a result of an
explicit merge or a "git pull") would also do this same thing.
But realize that this is really purely a per-repository logging thing, and
not really bound to the actual git history any way.
Linus
^ permalink raw reply
* Tracking branch history
From: Daniel Barkalow @ 2006-05-12 23:18 UTC (permalink / raw)
To: git
One feature that might make git more intuitive to people is if we were to
additionally track the history of what commit was the head of each branch
over time. This is only vaguely related to the history of the content, but
it's well-defined and sometimes significant.
E.g., if you know that two weeks ago, what you had worked, but it doesn't
work now, you can use git-bisect to figure out what happened, but first
you have to figure out what commit it was that you were using two weeks
ago. Two weeks ago, we had that information, but we didn't keep it.
It would probably also be useful for showing changelogs in a
locally-useful order. If you merge in a tree that's been in separate
development for a long time, the commits in that tree will be interleaved
in commit date with the commits you did locally. You tend to want to
attribute all of the changes that happened in the merge to the time of the
merge, but that commit object isn't going to tell you anything useful,
because it may have been done by the other tree (and you fast-forwarded to
the merge). In fact, you may want to attribute the changes to the
fast-forward, which can't recorded in the content history, because nothing
happened to the content. On the other hand, if we were to also record the
branch history, we could give output which shows changes in the order they
reached the local tree (then ordered by the commit tree), just by having
it do:
<time now>
git log <head-as-of-before>..<head-of-of-now>
<time before>
git log <head-as-of-before-that>..<head-as-of-before>
<time before-that>
and so forth.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* git-mailinfo '-u' argument should be default.
From: David Woodhouse @ 2006-05-12 16:46 UTC (permalink / raw)
To: git
If you apply a patch with 'git-am', it takes the raw content of the
From: header, in whatever character set that happens to be, and puts
that content, untagged, into the commit object.
That is almost _never_ the right thing to do, surely? Raw data in
untagged character sets is marginally better than line noise.
We should default to the '-u' behaviour, which converts to the character
set which the git repo is stored in. It's not just for converting to
UTF-8, although it looks like it was in the past. Now, however, it
converts to the character set defined in the configuration. So even if
it's a Luddite who for some reason is sticking with an obsolete
character set, it gets that right.
The only option which makes sense _other_ than that would be to just
stick the RFC2047-encoded original From: header into the commit, surely?
--
dwmw2
^ permalink raw reply
* Re: git-bisect failed me again
From: Linus Torvalds @ 2006-05-12 16:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: junkio, git
In-Reply-To: <Pine.LNX.4.64.0605120823170.3866@g5.osdl.org>
On Fri, 12 May 2006, Linus Torvalds wrote:
>
> But git isn't linear. Never has been. The fact that commits get (roughtly)
> sorted by date (modified by their ancestry relationships either subtly or
> grossly depending on whether --topo-sort is off or on) does not make
> anything linear.
Note that totally independently of sort order (whether "topo-order" or the
normal cheaper "order by date, but at least one chain of parenthood always
first"), you _will_ get the situation that a commit that was shown "last"
in a linear list is actually merged long before.
The simplest case is this:
merge
| \
A \
| \
B \
| X
C |
| Y
D |
| Z
.. ..
where the "main branch" is the A-B-C-D.. line of history, and the merge
brings in another "X-Y-Z" line of history.
Now, the A-B-C branch may have gotten a lot more recent love and
attention, and when you linearize it, since the normal ordering tends to
show it in a date-like order, you may get a list of commits like
merge
A
B
C
D
..
X
Y
Z
..
which makes you think that "A" is much more recent than "X". That may be
actually be _true_, but:
- 'X' actually _showed_up_ in the mainline much later than A. So, if you
track another persons tree like this, X as a commit may be 2 weeks old,
but it might not have been in the tree you tracked yesterday, because
it hadn't been _merged_ until today.
So in a very real sense, from your standpoint, 'X' may be the 'recent'
one, because you hadn't seen it before, but you _had_ seen 'A'
yesterday.
- Equally importantly, 'A' very much is _not_ a descendant of 'X' (ie,
'X' is _not_ reachable from 'A'). So even though 'A' is in a time-sense
much more recent than 'X', you can't say "it's the most recent commit,
so if there's a bug in any of the series, the bug must have been
visible at point 'A'".
This is why it's wrong to look at _any_ linearized list of commits and
imply any ordering what-so-ever. There simply is no list ordering that
guarantees anything at all, because even with "topo-sort", the only thing
we guarantee is that commits that are directly related to each other will
always sort the child before its parents. So even there, you can't
actually say that one commit "dominates" another commit unless you end up
looking at the parenthood chain (and merges are really important).
[ Strictly speaking, there is exactly _one_ thing you can say from just
seeing a list of commits: _if_ that list includes all types of commits
(ie notably merges and empty changes) _and_ if that list was generated
with just one "top" commit, then the first commit on the list will
dominate all other commits. But that's literally the only real ordering
you can ever know from just a list.
So looking at the first commit in a list is actually valid, but only if
you included all the merges and only if the list was generated by a git
command, and not sorted by any other criteria ]
Linus
^ permalink raw reply
* Re: git-bisect failed me again
From: Linus Torvalds @ 2006-05-12 15:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: junkio, git
In-Reply-To: <20060512081207.6cd701f9.akpm@osdl.org>
On Fri, 12 May 2006, Andrew Morton wrote:
>
> Linus Torvalds <torvalds@osdl.org> wrote:
> >
> > Anyway, my first guess would be that you might have marked something good
> > or bad that wasn't. How sure are you about that initial "git bisect bad"
> > you did?
>
> Am pretty confident.
And I'm pretty damn sure it ain't.
Andrew, git is _not_ linear. You can't just list the commits, take the
last and the first, and say "the last must be bad, the first must be
good". Which seems to be what you did.
>
>
> bix:/usr/src/25> grep '^commit ' patches/git-acpi.patch
> commit 9011bff4bdc0fef1f9a782d7415c306ee61826c9 <- This was my `bad'
> commit 5d882e684aafea30c508d86d235327d94e1d38ae
> commit 14394600cdfe0c952ce662a32a68c5c5524d32ac
> commit da95181baf3cf6a2bd81c0c8af1d4c6790703e4f
> commit b128440ed11d108c375772b7fe9ad46d2ac07084 <- This was the bug
That "b128440e.." commit wasn't even among the collection of commits that
you tested with "git bisect" in the first place.
You've apparently created a "list of commits" that doesn't include any
merges, and then you decided that the "most recent of those commits was
obviously bad".
WHICH IS NOT TRUE.
You never actually even TESTED that 9011bff commit, did you? In fact, I'm
100% sure you didn't. You just said "it's bad", without any confidence
what-so-ever except that it happened to be first on your list.
Right?
The fact is, it seems that the way you generated the list of commits was
basically:
- pick every commit that is not a merge and doesn't exist in linus tree.
(ie you basically did the equivalent of "git-rev-list --no-merges
linus..acpi", although it's possible that you used "git whatchanged" or
something else that will not show merges because they don't generate
diffs)
And then you believed that you had a linear series of commits, and that
the most recent commit must thus be the buggy one.
But git isn't linear. Never has been. The fact that commits get (roughtly)
sorted by date (modified by their ancestry relationships either subtly or
grossly depending on whether --topo-sort is off or on) does not make
anything linear.
The commit you mark as "this was the bug" is on a totally different
development branch from the one you marked "bad". That development branch
was merged with the branch that your "bad" commit came from with commit
7378614.. (which is not on your list at all):
"Pull bugzilla-5737 into test branch"
but there are actually a few other merges there too (and ACPI-only commits
that aren't reachable from your "top" bad commit).
> and git-bisect claimed that 9011bff4bdc0fef1f9a782d7415c306ee61826c9
> introduced the bug.
Hell no. Git bisect did no such thing at all. YOU DID.
Go back and look at what your sequence of instructions was (from your
original email):
->> Trying to find a recently-merged box-killer in Len's tree:
->>
->> bix:/usr/src/git26> cat .git/branches/git-acpi
->> git+ssh://master.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git#test
->>
->> git-checkout git-acpi
->> git-bisect reset
->> git-bisect start
->> git-bisect good ff2fc3e9e3edb918b6c6b288485c6cb267bc865e
->> git-bisect bad 9011bff4bdc0fef1f9a782d7415c306ee61826c9
->>
->> And it led me to
and notice how YOU claimed that "9011bff4.." was bad at the very
beginning of the "git bisect" run. Not "git bisect". YOU. You started off
by claiming that 9011bff4 was bad, apparently without having ever even
tested it.
The way "git bisect" works is that if you give it garbage information, it
_will_ give you a garbage result. That's pretty much guaranteed. But if
you actually give it tested and correct information, it will very
efficiently zero in on what the problem really was.
And the whole _point_ about "git bisect" is that the git history isn't
linear. If it was linear, you wouldn't need a tool to bisect it at all:
you'd just pick the middle entry from the history list, and use it. It
would be so trivial to bisect by hand, that using a tool is just
unnecessary.
So really, take a look at "git bisect visualize". In this case, you should
have noticed that you had a list of 50+ commits, but when you did
git bisect good ff2fc3e
git bisect bad 9011bff
git bisect visualize
you had cut your list of commits down to just six (none of which was the
bug).
This is why I integrated "gitk" immediately when it became available. It's
really important to see the non-linear history, because if you don't
visualize it (either mentally or with a tool like "gitk"), you'll never
understand what is going on.
Linus
^ permalink raw reply
* Re: git-bisect failed me again
From: Andrew Morton @ 2006-05-12 15:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: junkio, git
In-Reply-To: <Pine.LNX.4.64.0605120738190.3866@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
>
> (In fact, the _most_ visually obvious way to do it is to do this:
>
> git bisect reset
> git bisect start
> git bisect good ff2fc3e9e3edb918b6c6b288485c6cb267bc865e
> git bisect bad 9011bff4bdc0fef1f9a782d7415c306ee61826c9
> git bisect visualize &
> git bisect good c52851b60cc0aaaf974ff0e49989fb698220447d
> .. go into the "file" menu, and select "re-read references" ..
> git-bisect good 7e1f19e50371e1d148226b64c8edc77fec47fa5b
> .. do "re-read references" again ..
>
> and you'll see exactly what "git bisect" is doing).
>
> You claimed that the previous commit (7e1f19..) was good, and that
> 9011bff.. itself was bad). So if that was true, then it really _was_ that
> 9011bff.. commit that caused it.
>
> > What did I do wrong this time?
>
> You did nothing wrong, unless your _testing_ was wrong, and one of your
> "git bisect good" entries should have been bad, or the other way around
> (you booted into the wrong kernel, so you thought something was ok when it
> wasn't).
>
> Why are you so sure that git bisect gave the wrong answer? This is ACPI,
> after all. For all we know, subtle cache-effects could break it.
>
> "git bisect" sadly won't help with bugs that show up due to some other
> subtle interaction..
>
> Anyway, my first guess would be that you might have marked something good
> or bad that wasn't. How sure are you about that initial "git bisect bad"
> you did?
Am pretty confident.
bix:/usr/src/25> grep '^commit ' patches/git-acpi.patch
commit 9011bff4bdc0fef1f9a782d7415c306ee61826c9 <- This was my `bad'
commit 5d882e684aafea30c508d86d235327d94e1d38ae
commit 14394600cdfe0c952ce662a32a68c5c5524d32ac
commit da95181baf3cf6a2bd81c0c8af1d4c6790703e4f
commit b128440ed11d108c375772b7fe9ad46d2ac07084 <- This was the bug
commit 61ce94e1f8b16b1694475adba9bf2e07fac02020
commit a48142ea89e02ed0aba0a481ead1e9302e1a4160
commit d5c11d3ba31d6ead24f27de648dc2dcfde5092e3
commit f6a08bf2cb06ee3d5be749cf20685b677619bc8e
commit 2cb7f1704275905b7548eee299c554bcdc5cf357
commit 2ce2b16467f0d43d0f8933eb4821b2369b31888c
commit 8ec0cbd9386a40a3afffad78334f4403b256dc4b
commit ba8acc597cff47fcbbd7b9f0d73a59e784852d8b
commit 7e9e8344848d80c9b6e1b9eaf32dd498b48ca5bb
commit d2606159ffdf8e435f6a7714f8e8910672b944d5
commit 8fb1d47b74e2bad912f74783048b433a1e313799
commit f7c0fce6da5cb68b8b0e203df4ff8ef9b3265105
commit 61e295946a248e43cf244cb24097e284d1d00e35
commit a32283362a7a8e7cff608fe25299a59925daea4d
commit 4cd5611ca16348b3805ddcf89b97fe670e76faaa
commit 529758bad4b0f9a8eec56fcc5cad342e9680ea36
commit 91afb9e683426ff238aab159e60f6d6e792e7488
commit 9f102deee398ea4dfcee3b2108dc00bc59ea877b
commit e85eb9a47f19a26b636b58106e309f8db6b2415d
commit 4597ac50598b85a09417df531849b80ce2e8e44b
commit 74951d613e758f9709d6f2173107be68f18f77f4
commit e6f1f3c54974a30c65ea0b699809d12f0aa04272
commit c12ea918ee175ceb3a258cd81f1c43e897d0c0bc
commit eefa27a93a0490902f33837ac86dbcf344b3aa29
commit ff2fc3e9e3edb918b6c6b288485c6cb267bc865e
commit df42baa0d8e54df18dd9366dd7c93d6be7d5d063
commit 200739c179c63d21804e9e8e2ced265243831579
commit 5e15b92d07fb11490c886c5dd7567f523ea43e2d
commit 9224a867c497053842dc595e594ca6d32112221f
commit 459c7266d7a5c1730169258217e25fdd1b7ca854
commit 1a36561607abf1405b56a41aac2fd163429cd1f8
commit e4513a57ef719d3d6d1cee0ca4d9f4016aa452bb
commit 578b333bfe8eb1360207a08a53c321822a8f40f3
commit 9d9f749b316ac21cb59ad3e595cbce469b409e1a
commit cd090eedd85256829f762677d0752a846c1b88b9
commit 81507ea9cfa64e9851b53e0fefebfa776eda9ecb
commit 1c6e7d0aeecac38e66b1bb63e3eff07b2a1c2f2c
commit b5f2490b6e3317059e87ba40d4f659d1c30afc1f
commit 1acfb7f2b0d460ee86bdb25ad0679070ec8a5f0d
commit 7e1f19e50371e1d148226b64c8edc77fec47fa5b
commit 1300124f69cafc54331bc06e968a8dd67863f989
commit ec7381d6bfd3e7b8d2880dd5e9d03b131b0603f6
commit 8313524a0d466f451a62709aaedf988d8257b21c
commit ea936b78f46cbe089a4ac363e1682dee7d427096
commit 52fc0b026e99b5d5d585095148d997d5634bbc25
commit 46358614ed5b031797522f1020e989c959a8d8a6
commit 6665bda76461308868bd1e52caf627f4cb29ed32
commit fdc136ccd3332938e989439c025c363f8479f3e6
commit a1f9e65e2085e0a87f28a4d5a8ae43b32c087f24
commit 1fee94034917aa711fcbd4ebf4c36f7ebd9fa7d6
commit 0eacee585a89ce5827b572a73a024931506bef48
commit 9cfda2c94df61c9f859b474abe774c65a4464d0a
commit d52bb94d56676acd9bdac8e097257a87b4b1b2e1
commit c52851b60cc0aaaf974ff0e49989fb698220447d
commit 09b4d1ee881c8593bfad2a42f838d85070365c3e
commit 3b2d99429e3386b6e2ac949fc72486509c8bbe36
commit ffd642e748c867a7339b57225b8bf8b9a0dcd9c5 <- This was my `good'
commit f9ea7fd8be9827791f407ca1191ff70ec25eb2d9
commit b60e49b2383db0334bef1f0d9cdad9bec2336050
commit 1ca218d3bd6acca0922a349cb76e3244d27ebfba
and git-bisect claimed that 9011bff4bdc0fef1f9a782d7415c306ee61826c9
introduced the bug.
^ permalink raw reply
* Re: git-bisect failed me again
From: Linus Torvalds @ 2006-05-12 14:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: Junio C Hamano, git
In-Reply-To: <20060512000249.71933599.akpm@osdl.org>
On Fri, 12 May 2006, Andrew Morton wrote:
>
> Trying to find a recently-merged box-killer in Len's tree:
>
> bix:/usr/src/git26> cat .git/branches/git-acpi
> git+ssh://master.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git#test
>
> git-checkout git-acpi
Just for others: if you already have a Linux repo, this is the perfect
time to do
git clone --reference <old-linux-repo>
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6
to get that linux-acpi-2.6 repository.
And for Junio: good job on that "--reference" flag. I used to do a local
clone and then force an update, this was much better.
> git-bisect reset
> git-bisect start
> git-bisect good ff2fc3e9e3edb918b6c6b288485c6cb267bc865e
> git-bisect bad 9011bff4bdc0fef1f9a782d7415c306ee61826c9
>
> And it led me to
>
> bix:/usr/src/git26> git-bisect good
> 9011bff4bdc0fef1f9a782d7415c306ee61826c9 is first bad commit
>
> which isn't a buggy patch.
Well, to see what's up, do "git bisect visualize". That tends to not only
help bisect things (for when you want to pick a different bisection
point), it's also a wonderfully visual tool to what the f*%& happens when
something goes wrong.
Anyway, when I replay your log:
> bix:/usr/src/git26> cat .git/BISECT_LOG
> git-bisect start
> # good: [ff2fc3e9e3edb918b6c6b288485c6cb267bc865e] ACPI: EC acpi-ecdt-uid-hack
> git-bisect good ff2fc3e9e3edb918b6c6b288485c6cb267bc865e
> # bad: [9011bff4bdc0fef1f9a782d7415c306ee61826c9] ACPI: delete newly added debugging macros in processor_perflib.c
> git-bisect bad 9011bff4bdc0fef1f9a782d7415c306ee61826c9
> # good: [c52851b60cc0aaaf974ff0e49989fb698220447d] P-state software coordination for speedstep-centrino
> git-bisect good c52851b60cc0aaaf974ff0e49989fb698220447d
> # good: [7e1f19e50371e1d148226b64c8edc77fec47fa5b] ACPI: UP build fix for bugzilla-5737
> git-bisect good 7e1f19e50371e1d148226b64c8edc77fec47fa5b
I definitely get the same "9011bff4bdc0fef1f9a782d7415c306ee61826c9 is
first bad commit" result, and going along visually at every point makes it
very very obvious that git-bisect is right.
(In fact, the _most_ visually obvious way to do it is to do this:
git bisect reset
git bisect start
git bisect good ff2fc3e9e3edb918b6c6b288485c6cb267bc865e
git bisect bad 9011bff4bdc0fef1f9a782d7415c306ee61826c9
git bisect visualize &
git bisect good c52851b60cc0aaaf974ff0e49989fb698220447d
.. go into the "file" menu, and select "re-read references" ..
git-bisect good 7e1f19e50371e1d148226b64c8edc77fec47fa5b
.. do "re-read references" again ..
and you'll see exactly what "git bisect" is doing).
You claimed that the previous commit (7e1f19..) was good, and that
9011bff.. itself was bad). So if that was true, then it really _was_ that
9011bff.. commit that caused it.
> What did I do wrong this time?
You did nothing wrong, unless your _testing_ was wrong, and one of your
"git bisect good" entries should have been bad, or the other way around
(you booted into the wrong kernel, so you thought something was ok when it
wasn't).
Why are you so sure that git bisect gave the wrong answer? This is ACPI,
after all. For all we know, subtle cache-effects could break it.
"git bisect" sadly won't help with bugs that show up due to some other
subtle interaction..
Anyway, my first guess would be that you might have marked something good
or bad that wasn't. How sure are you about that initial "git bisect bad"
you did?
Linus
^ permalink raw reply
* git-bisect failed me again
From: Andrew Morton @ 2006-05-12 7:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Trying to find a recently-merged box-killer in Len's tree:
bix:/usr/src/git26> cat .git/branches/git-acpi
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git#test
git-checkout git-acpi
git-bisect reset
git-bisect start
git-bisect good ff2fc3e9e3edb918b6c6b288485c6cb267bc865e
git-bisect bad 9011bff4bdc0fef1f9a782d7415c306ee61826c9
And it led me to
bix:/usr/src/git26> git-bisect good
9011bff4bdc0fef1f9a782d7415c306ee61826c9 is first bad commit
diff-tree 9011bff4bdc0fef1f9a782d7415c306ee61826c9 (from 7e1f19e50371e1d148226b64c8edc77fec47fa5b)
Author: Len Brown <len.brown@intel.com>
Date: Thu May 11 00:28:12 2006 -0400
ACPI: delete newly added debugging macros in processor_perflib.c
which isn't a buggy patch.
bix:/usr/src/git26> cat .git/BISECT_LOG
git-bisect start
# good: [ff2fc3e9e3edb918b6c6b288485c6cb267bc865e] ACPI: EC acpi-ecdt-uid-hack
git-bisect good ff2fc3e9e3edb918b6c6b288485c6cb267bc865e
# bad: [9011bff4bdc0fef1f9a782d7415c306ee61826c9] ACPI: delete newly added debugging macros in processor_perflib.c
git-bisect bad 9011bff4bdc0fef1f9a782d7415c306ee61826c9
# good: [c52851b60cc0aaaf974ff0e49989fb698220447d] P-state software coordination for speedstep-centrino
git-bisect good c52851b60cc0aaaf974ff0e49989fb698220447d
# good: [7e1f19e50371e1d148226b64c8edc77fec47fa5b] ACPI: UP build fix for bugzilla-5737
git-bisect good 7e1f19e50371e1d148226b64c8edc77fec47fa5b
A had a second go - fed it the very first and last commit IDs in that tree.
Same result.
bix:/usr/src/git26> git-bisect good
9011bff4bdc0fef1f9a782d7415c306ee61826c9 is first bad commit
diff-tree 9011bff4bdc0fef1f9a782d7415c306ee61826c9 (from 7e1f19e50371e1d148226b64c8edc77fec47fa5b)
Author: Len Brown <len.brown@intel.com>
Date: Thu May 11 00:28:12 2006 -0400
ACPI: delete newly added debugging macros in processor_perflib.c
Signed-off-by: Len Brown <len.brown@intel.com>
:040000 040000 f7a3b4cfdb128fb6a777b2e30a83c63edd70f46a 2ca1c42aaae65df9052d60d274aaec3116e30c2d M drivers
bix:/usr/src/git26> cat .git/BISECT_LOG
git-bisect start
# good: [74951d613e758f9709d6f2173107be68f18f77f4] ACPI: Remove debugging macros from drivers/acpi/thermal.c
git-bisect good 74951d613e758f9709d6f2173107be68f18f77f4
# bad: [9011bff4bdc0fef1f9a782d7415c306ee61826c9] ACPI: delete newly added debugging macros in processor_perflib.c
git-bisect bad 9011bff4bdc0fef1f9a782d7415c306ee61826c9
# good: [c52851b60cc0aaaf974ff0e49989fb698220447d] P-state software coordination for speedstep-centrino
git-bisect good c52851b60cc0aaaf974ff0e49989fb698220447d
# good: [7e1f19e50371e1d148226b64c8edc77fec47fa5b] ACPI: UP build fix for bugzilla-5737
git-bisect good 7e1f19e50371e1d148226b64c8edc77fec47fa5b
What did I do wrong this time?
Thanks.
^ permalink raw reply
* Re: [PATCH 5/6] gitopt: convert setup_revisions(), and diff_opt_parse()
From: Eric Wong @ 2006-05-11 20:19 UTC (permalink / raw)
To: git
In-Reply-To: <11471512123005-git-send-email-normalperson@yhbt.net>
In other news, this patch is broken. Bundled args won't work if some
in the bundle are handled setup_revisions() and some are handled by
diff_opt_parse().
I'll work on fixing this, as well (may take a while working mostly one-handed).
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Fix git-pack-objects for 64-bit platforms
From: Linus Torvalds @ 2006-05-11 19:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dennis Stosberg, git
In-Reply-To: <7v7j4swg0r.fsf@assigned-by-dhcp.cox.net>
On Thu, 11 May 2006, Junio C Hamano wrote:
>
> Since I saw a patch that touches only one place, I thought I'd
> better point this out...
>
> There are a few more places that knows about this
> ((char*)base_pointer + (entry_count * 24)) magic in our code.
Since I _do_ have a 64-bit big-endian architecture, I decided to install
some of the 64-bit development libraries that I didn't already have, and I
added "-m64" to the compiler flags.
All the tests seem to pass with the simple fix (and without it, we do
indeed fail at least t5700-clone-reference.sh).
Of course, there might well be something else that doesn't get coverage,
but passing all tests is at least a good sign. And since x86-64 has been
getting pretty extensive coverage, I don't think we have a lot of 64-bit
bugs per se, this one just happened to hide.
Linus
---
diff --git a/pack-objects.c b/pack-objects.c
index 523a1c7..1b9e7a1 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -156,7 +156,7 @@ static void prepare_pack_revindex(struct
rix->revindex = xmalloc(sizeof(unsigned long) * (num_ent + 1));
for (i = 0; i < num_ent; i++) {
- long hl = *((long *)(index + 24 * i));
+ uint32_t hl = *((uint32_t *)(index + 24 * i));
rix->revindex[i] = ntohl(hl);
}
/* This knows the pack format -- the 20-byte trailer
^ permalink raw reply related
* Re: [PATCH] Fix git-pack-objects for 64-bit platforms
From: Linus Torvalds @ 2006-05-11 19:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dennis Stosberg, git
In-Reply-To: <7v7j4swg0r.fsf@assigned-by-dhcp.cox.net>
On Thu, 11 May 2006, Junio C Hamano wrote:
>
> Is uint32_t guaranteed to be exactly 32-bit, or merely enough to
> hold 32-bit?
I think it's guaranteed to be 32-bit, but regardless, the current git
headers already assume that "unsigned int" is 32-bit.
Which is a pretty safe assumption for at least the next ten years or so,
possibly much longer. So I don't think we need to worry _too_ much about
this. I think it's more important to try to get git working on Windows,
than on 16-bit DOS or on a PDP-9, or one of the odd cray machines.
Linus
^ permalink raw reply
* Re: [PATCH] Fix git-pack-objects for 64-bit platforms
From: Junio C Hamano @ 2006-05-11 18:52 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0605111054290.3866@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 11 May 2006, Dennis Stosberg wrote:
>>
>> I am not sure whether an int cast or an int32_t cast is more
>> appropriate here. An int is not guaranteed to be four bytes wide,
>> but I don't know of any modern platform where that's not the case.
>> On the other hand int32_t is not necessarily available before C99.
>>
>> Any opinions? I wonder why no one has hit this on x86_64...
>
> I think the "ntohl()" hides it. It loads a 64-bit value, but since x86-64
> is little-endian, the low 32 bits are correct. The htonl() will then strip
> the high bits and make it all be big-endian.
That sounds sensible.
Since I saw a patch that touches only one place, I thought I'd
better point this out...
There are a few more places that knows about this
((char*)base_pointer + (entry_count * 24)) magic in our code.
$ git grep -n -e '24 *\*' -e '\* *24' master -- '*.c'
master:pack-objects.c:159: long hl = *((long *)(index + 24 * i));
This is yours.
master:sha1_file.c:447: if (idx_size != 4*256 + nr * 24 + 20 + 20)
master:sha1_file.c:1148: memcpy(sha1, (index + 24 * n + 4), 20);
master:sha1_file.c:1162: int cmp = memcmp(index + 24 * mi + 4, sha1, 20);
These three should be OK, I think.
master:sha1_file.c:1164: e->offset = ntohl(*((int*)(index + 24 * mi)));
This you might want to look at; I suspect it is what
Linus suggests.
Also we _might_ have uglier magic that assumes the base_pointer to
be a pointer to a 4-byte integer and uses offset of multiple of
6 instead of 24, although I do not think it is likely.
I have to leave the keyboard in a few minutes so I cannot verify
nor fix them myself for the next 8 hours or so. Sorry.
> And while I actually run a 64-bit big-endian machine myself (G5 ppc64), my
> user space is all 32-bit by default, so it never showed up on linux-ppc64
> either.
>
> Anyway, the correct type to use is "uint32_t" in this case. That's what
> htonl() takes.
Is uint32_t guaranteed to be exactly 32-bit, or merely enough to
hold 32-bit?
^ permalink raw reply
* Re: [PATCH] Fix git-pack-objects for 64-bit platforms
From: Linus Torvalds @ 2006-05-11 17:58 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: git
In-Reply-To: <20060511173632.G60c08b4@leonov.stosberg.net>
On Thu, 11 May 2006, Dennis Stosberg wrote:
>
> I am not sure whether an int cast or an int32_t cast is more
> appropriate here. An int is not guaranteed to be four bytes wide,
> but I don't know of any modern platform where that's not the case.
> On the other hand int32_t is not necessarily available before C99.
>
> Any opinions? I wonder why no one has hit this on x86_64...
I think the "ntohl()" hides it. It loads a 64-bit value, but since x86-64
is little-endian, the low 32 bits are correct. The htonl() will then strip
the high bits and make it all be big-endian.
And while I actually run a 64-bit big-endian machine myself (G5 ppc64), my
user space is all 32-bit by default, so it never showed up on linux-ppc64
either.
Anyway, the correct type to use is "uint32_t" in this case. That's what
htonl() takes.
Linus
^ permalink raw reply
* [PATCH] Fix git-pack-objects for 64-bit platforms
From: Dennis Stosberg @ 2006-05-11 17:36 UTC (permalink / raw)
To: git
The offset of an object in the pack is recorded as a 4-byte integer
in the index file. When reading the offset from the mmap'ed index
in prepare_pack_revindex(), the address is dereferenced as a long*.
This works fine as long as the long type is four bytes wide. On
NetBSD/sparc64, however, a long is 8 bytes wide and so dereferencing
the offset produces garbage.
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
---
I am not sure whether an int cast or an int32_t cast is more
appropriate here. An int is not guaranteed to be four bytes wide,
but I don't know of any modern platform where that's not the case.
On the other hand int32_t is not necessarily available before C99.
Any opinions? I wonder why no one has hit this on x86_64...
pack-objects.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
026b1b2cdd5332f59e15cd8611a49ead3094d08c
diff --git a/pack-objects.c b/pack-objects.c
index 523a1c7..29bda43 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -156,7 +156,7 @@ static void prepare_pack_revindex(struct
rix->revindex = xmalloc(sizeof(unsigned long) * (num_ent + 1));
for (i = 0; i < num_ent; i++) {
- long hl = *((long *)(index + 24 * i));
+ long hl = *((int *)(index + 24 * i));
rix->revindex[i] = ntohl(hl);
}
/* This knows the pack format -- the 20-byte trailer
--
1.3.2.gbe65
^ permalink raw reply related
* [PATCH] Fix compilation on newer NetBSD systems
From: Dennis Stosberg @ 2006-05-11 17:35 UTC (permalink / raw)
To: git
NetBSD >=2.0 has iconv() in libc. A libiconv is not required and
does not exist.
See: http://netbsd.gw.com/cgi-bin/man-cgi?iconv+3+NetBSD-2.0
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
---
Makefile | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
2a73fcf43bfd1f73ec5e1e50396d54b83abae5e1
diff --git a/Makefile b/Makefile
index 37fbe78..26fa4e6 100644
--- a/Makefile
+++ b/Makefile
@@ -285,7 +285,9 @@ ifeq ($(uname_S),OpenBSD)
ALL_LDFLAGS += -L/usr/local/lib
endif
ifeq ($(uname_S),NetBSD)
- NEEDS_LIBICONV = YesPlease
+ ifeq ($(shell test `uname -r | sed -e 's/^\([0-9]\).*/\1/'` -lt 2 && echo y),y)
+ NEEDS_LIBICONV = YesPlease
+ endif
ALL_CFLAGS += -I/usr/pkg/include
ALL_LDFLAGS += -L/usr/pkg/lib -Wl,-rpath,/usr/pkg/lib
endif
--
1.3.2.gbe65
^ permalink raw reply related
* Re: Implementing branch attributes in git config
From: Junio C Hamano @ 2006-05-11 17:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Johannes Schindelin, sean
In-Reply-To: <Pine.LNX.4.64.0605091215340.3718@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 9 May 2006, Junio C Hamano wrote:
>>
>> If we are shooting for "let's not do this again", I do not think
>> (4) without some quoting convention is good enough. Today, we
>> are talking about branch names so we could give them artificial
>> limits, which could be weaker than what we already have on the
>> branch names, but we would later regret that, when we start
>> wanting to have other names in the configuration (e.g. people's
>> names).
>
> Here's my suggestion as a patch.
>
> NOTE! This patch could be applied right now, and to all the branches (to
> make 1.x, 1.2.x and 1.3.x all support the _syntax_). Even if nothing
> actually uses it.
Linus,
I've adjusted this patch, your follow-up patch, and Sean's
"extended section part is case sensitive" patch, along with the
test tweak to "maint" branch. I also prepared them to be
mergeable to the "master" branch. Tentatively it is in "next"
for testing.
I'm ready to push out "maint" (not tagged as 1.3.3 yet) and
"next", but have not done so.
I understand the plan is to have 1.3.3 out from this "maint",
and also merge this in "master" about the same time, but I am
expecting I will be offline for the rest of the week most of the
time, so it would happen over the weekend at the earliest.
Does that sound good to you?
I do not think we would need v1.1.7 nor v1.2.7 for this. People
who have stayed at v1.1.6 or v1.2.6 would need to update if they
are going to use newer git in their repo anyway, and I do not
think of a reason not to update to 1.3.3 but update to 1.1.7 or
1.2.7 in order to stay at the feature level of 1.1.X or 1.2.X
series. We haven't made incompatible changes as far as I
remember.
Here is what the (adjusted) test case in "next" looks like.
Corresponding one in "maint" lack --list so does not have the
last hunk. The "maint" and "next" branches I have locally both
passes the test.
-- >8 --
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 7090ea9..8260d57 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -229,7 +229,7 @@ test_expect_failure 'invalid key' 'git-r
test_expect_success 'correct key' 'git-repo-config 123456.a123 987'
test_expect_success 'hierarchical section' \
- 'git-repo-config 1.2.3.alpha beta'
+ 'git-repo-config Version.1.2.3eX.Alpha beta'
cat > expect << EOF
[beta] ; silly comment # another comment
@@ -241,8 +241,8 @@ # empty line
NoNewLine = wow2 for me
[123456]
a123 = 987
-[1.2.3]
- alpha = beta
+[Version "1.2.3eX"]
+ Alpha = beta
EOF
test_expect_success 'hierarchical section value' 'cmp .git/config expect'
@@ -251,7 +251,7 @@ cat > expect << EOF
beta.noindent=sillyValue
nextsection.nonewline=wow2 for me
123456.a123=987
-1.2.3.alpha=beta
+version.1.2.3eX.alpha=beta
EOF
test_expect_success 'working --list' \
^ 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