* Re: Handling large files with GIT
From: Linus Torvalds @ 2006-02-13 5:05 UTC (permalink / raw)
To: Ben Clifford; +Cc: Martin Langhoff, Florian Weimer, git
In-Reply-To: <Pine.LNX.4.64.0602122049010.3691@g5.osdl.org>
On Sun, 12 Feb 2006, Linus Torvalds wrote:
>
> This is a large part of why git performs well on the kernel. Most merges
> don't actually touch all - or even a very big percentage - of the over
> thousand subdirectories in the kernel. Git can quickly see and ignore the
> whole subdirectory when that happens - the SHA1 is exactly the same, so
> git knows that every file under that subdirectory (and every recursive
> directory) is the same.
Final note: this means, for example, that git is relatively bad at
tracking a "hashed" nested file directory (like the one git itself uses),
because new files will end up randomly appearing in every directory, and
no directory is ever "stable".
In contrast, if the directory structure is - for example - something where
you index files by date, and subdirectories with older dates are thus much
more naturally likely to be quiescent, the "this tree is the same"
optimizations work very well.
Basically, a lot of the git speed optimizations depend on "on average,
things stay the same". We may have 18,000+ files in the kernel, but most
patches will change maybe five of them. There's a lot of fairly static
content and the changes have a certain level of "locality". It's normally
a hundred-line patch to one file, not a hundred files that had one-liners.
And when 20 files are changed, most of them tend to be in the same
subdirectory, etc etc.
Taking advantage of those kinds of things is what makes git good at
handling software projects. But it wouldn't necessarily be how you lay out
a mail directory, for example. An automated file store might want to
spread out the changes on purpose.
Linus
^ permalink raw reply
* Re: Fake linear history in a deterministic manner.
From: Junio C Hamano @ 2006-02-13 5:24 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90602121746v5adb448ej73cc2be6dd3745ce@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> I thought briefly about delaying the decision until I see the merge,
> and pick the leftmost, or rightmost, if there is some bias in
> git-merge or cg-merge on putting whatever origin has on a particular
> side. It'd mean running backwards through history and that the very
> last merge can flip the decision entirely. Hmmm... any strategy I can
> come up with means that each new merge throws the dice again entirely.
>
> Ideas?
When somebody pushes a ref to your existing commit ancestry
graph, you can easily identify which commits are the new ones
you see for the first time.
A
o---o
/
o---o---o---o---o B
Suppose you started from two branch repo A and B. Your sqlite
database knows about all of these commits, and say you earlier
have decided to treat A as a side branch, B as trunk.
Then somebody pushed a new B, making the ancestry graph like
this:
A
o---o-------*---*---* B-new
/ /
o---o---o---o---o B-old
When the update-hook runs, as you read in receive-pack.c,
your refs have not been updated yet, so you can identify the
commits marked with * with:
git rev-list B-new $(git rev-parse --not --all)
I think you have to do this enumeration of new commits anyway,
if you are keeping tabs on all commits in your database. And
you check the chain * commits form, and work backwards. The
topologically oldest ones determine what branch others belong
to.
With CVS you cannot express a merge very well, so you now face a
choice. Which parent to drop from the leftmost * commit in the
above picture?
It has commits known to your sqlite database as its parents, and
one of them, B (old), is on trunk; the other one is a side
branch, so in this case the decision is clear. You leave the
link from B-old and cut link from A. But this heuristics would
not work very well if both are branches. Which one to prefer?
One approach would be to see the world with eyes of the person
who did such a merge. Both git and cogito place the current
branch as the first parent, so you can tell which one the person
who did the merge had before that merge that way. Also in
practice, in a normal branch, you would build sequence of small
commits and occasionally merge from elsewhere, so the side with
more difference tends to be a side branch from the point of view
of the person who performs the merge.
However, this would not help much. There is no inherent
distinction between trunk and branch in the distributed
development. Although I treat my "next" branch as a side branch
and "master" branch as the trunk, "next" sometimes needs to
merge from "master", and by looking at only that merge, you
cannot tell which one is the trunk. My merging "master" into
"next" does not make my "next" the trunk.
Since the ordering is completely arbitrary, I think you can give
preference to the ones you have found out about earlier. That
is, suppose you already had this, and for some reason track B is
the trunk and track A is a branch (say commits on B have 1.XX,
the ones on A have 1.XX.1.YY where XX depends on which commits
on B the branch was forked from). At this point, if you see a
push to C:
A
o---o
/
o---o---o---o---o B
\
*---* C
you give 1.XX.2.YY to commits on C.
This may or may not match reality, and C may collect a lot of
commits while B might stay dormant -- and you may regret that
you picked B as the trunk. But the thing is, there is no
inherent trunk or branch in the distributed world, so the cvs
clients of your server needs to live with it. To you, you saw B
first and people who track the project through your server also
saw B first. Then you can have total ordering to side
branches. When you see a merge, you arbitrarily but
consistently pick which side to pick. The one that has smaller
number at the third place (which I am using as "the branch
number").
Just thinking out aloud again...
^ permalink raw reply
* Re: Handling large files with GIT
From: Jeff Garzik @ 2006-02-13 5:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ben Clifford, Martin Langhoff, Florian Weimer, git
In-Reply-To: <Pine.LNX.4.64.0602122049010.3691@g5.osdl.org>
Linus Torvalds wrote:
> I've never used maildir layout, but if it is a couple of large _flat_
> subdirectories,
That's what it is :/ One directory per mail folder, with each email an
individual file in that dir.
On the side I run a mini-ISP that offers (among other things)
SMTP/IMAP/POP via exim/dovecot. I use maildir for my customers, and am
desperately searching for a better solution. David Woodhouse and I talk
off and on about using git for distributed mail storage.
OTOH, I wonder if a P2P-ish, sha1-indexed network service wouldn't be
better for both a git fallback and email storage.
Jeff
^ permalink raw reply
* Re: Fake linear history in a deterministic manner.
From: Martin Langhoff @ 2006-02-13 5:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6bz3k7e.fsf@assigned-by-dhcp.cox.net>
On 2/13/06, Junio C Hamano <junkio@cox.net> wrote:
Yep, I had roughly this exact scenario in my mind, thanks for the
graphs -- help make sense of what's happening.
> When somebody pushes a ref to your existing commit ancestry
> graph, you can easily identify which commits are the new ones
> you see for the first time.
>
> A
> o---o
> /
> o---o---o---o---o B
>
> Suppose you started from two branch repo A and B. Your sqlite
> database knows about all of these commits, and say you earlier
> have decided to treat A as a side branch, B as trunk.
Well, from the point of view of B being a head we know about, either A
is another head, and we don't care about it, or A is someone's repo
and we haven't seen it and thus cannot care about it either.
A bit of background... git-cvsserver at the moment has the following
semantics: what cvs considers a top-level "module" we use to identify
the head. So
cvs -d :ext:me@server:/var/frob.git checkout master
will get you frob.git#master. I thought long and hard about this, and
it is horribly hard to mimic CVS's idea of branches. So clients see a
strictly linear history. Any user in this scenario wanting to do
branching and merging is kindly invited to use real tools. There';s
only so much magic Perl can do ;-)
> Then somebody pushed a new B, making the ancestry graph like
> this:
>
> A
> o---o-------*---*---* B-new
> / /
> o---o---o---o---o B-old
>
> When the update-hook runs, as you read in receive-pack.c,
> your refs have not been updated yet, so you can identify the
> commits marked with * with:
>
> git rev-list B-new $(git rev-parse --not --all)
That's a nifty trick, though I'm not sure I'll be able to use it.
Right now I'm doing something stupid-er just using `git-log
--parents`, skipping commits that don't move the ball forward on the
linear head I know about, and then processing those "other tracks"
when I see a merge commit. I'll probably find the merge base and see
what commits were brought in from the other side.
The problem is that the situation running from post update hook is
very different from the scenario of running the very same script on a
repo where you see all the history.
In any case, I'm undecided whether to use --topo-order or
--merge-order. Does it really matter?
(...)
> With CVS you cannot express a merge very well, so you now face a
> choice. Which parent to drop from the leftmost * commit in the
> above picture?
Well, we've already lied about having B to clients that won't know
what to do if we tell them about parallel histories, so our pick is B.
(...)
> One approach would be to see the world with eyes of the person
> who did such a merge. Both git and cogito place the current
> branch as the first parent,
Yes, I thought about that, but that order is ambiguous in the two most
interesting cases:
- project maintainer pulls from mature feature branches from other
developers - her side is first, show the "pulled" stuff as merges
(flattened with a merge summary in the commit msg). Still, you can
argue the feature development is more interesting.
- team-shared-git-repo user does cg-update and merges updates from
origin - her side is first, we don't know which side is the
interesting one. At all. Hmmm.
> But the thing is, there is no
> inherent trunk or branch in the distributed world, so the cvs
> clients of your server needs to live with it.
That's the mantra so far, and we'll talk to cvs clients about
perfectly linearized history. Anything else won't be useful as far as
I can tell -- or in any case,until this is going well for basic usage.
If someone's crazy enough to try I won't get in the way.
cheers.
martin
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Shawn Pearce @ 2006-02-13 6:03 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <43F00DB6.4040306@vilain.net>
Sam Vilain <sam@vilain.net> wrote:
> ok. Well, perhaps a nice solution might be just to aggregate the
> comments as each new commit is made. ie, the previous comment is
> prepended to the new comment unless you use the editor or a special
> -M (or whatever) option that replaces the running comment.
Yea, that's not a bad idea. If you are creating a new commit you
probably would want to edit the running description for the patch;
or at least be reminded of what it is.
> I tried importing a patchset into pg, and made some changes to it to see
> the patch revisioning going on. However, I can't see this happening.
> Can you perhaps include this information in your tutorial?
Revisioning doesn't happen for the series, just the individual
patches. But I've thought about series revisoning and keeping a
secondary GIT index/commit chain external to the main repository
for exactly this purpose.
Each change to a patch (pg-ci) is a new commit object in GIT with
the prior commit object as its parent; if you use pg-ci a few times
with the same patch on the stack then look at the log with git-log
or gitk you'll see the commits are chained together.
When you pop patches and reorder them in the series the resulting
merges are stored as commits with two parents: one for the HEAD
at the time of the merge and one for the commit which was the last
commit in the patch being pushed (HEAD^1 and HEAD^2 respectively).
For example:
pg-new A
echo a >>somefile
pg-ci -m"This is a"
pg-new B
echo b >>somefile
pg-ci -m"This is b"
pg-pop -a
pg-push B # base used to be HEAD+A, now its HEAD
pg-push A # base used to be HEAD, now its HEAD+B
The challenge then becomes walking through the merge history.
If you look at pg's own history you'll see an interesting knot
in gitk at a7e73545e511c5c2daea1f6c7bf06cf3179e7f0da (Refreshed
patch Create-Rebase-Tool). This was produced because I reorded
the patches in the stack and thus had to merge them. It was an
automatic merge, but it still generated merge commit objects.
Good suggestion about including some details about it in the
tutorial.
> As far as other, more general critiques of the software goes: What
> about merging? stgit has a very nice way of merging; I specify how to
> merge using a config file, and when I rebase my patches with "stg pull",
> it fires up my custom editor. All I really want is a way to specify how
> to handle merges, with the ancestor/left/right files on hand. I want to
> use something as simple as this script:
>
> echo "falling back to ediff-merge"
> emacs --eval "(ediff-merge-files-with-ancestor \"${branch1}\"
> \"${branch2}\" \"${ancestor}\" nil \"${output}\")"
pg doesn't currently invoke any user code when an automatic merge
fails during pg-push or pg-rebase. It does attempt to produce
a 3 way merge and leaves the resulting portions for you in the
filesystem. If you look at MERGING.txt you'll see that up to 5
files can come out of a merge (here I'm using the tracked file X.c):
X.c
X.c-head
X.c-last
X.c-pbase
X.c-rej
These just get left in the filesystem for you to use as you want;
in your case it sounds like you'd want to invoke:
emacs --eval "(ediff-merge-files-with-ancestor
\"X.c-head\"
\"X.c-last\"
\"X.c-pbase\"
nil
\"X.c\"
)"
X.c already contains the result of performing:
diff X.c-pbase X.c-last | patch X.c
so it already has any hunks which were part of your patch and
which applied cleanly to X.c-head (which is the file coming in as
the new base). Thus you are left only with the rejecting hunks,
which are in X.c-rej.
Personally I've always preferred being given the rejects from
patch to work out a merge problem then to be given the mess that
RCS merge leaves you with. (I've _never_ been able to decipher
what I want from an RCS merge conflict.)
What is the desired behavior when multiple files have conflicts?
Stop and let the user work on one file before moving to the next?
Open all merge editors in parallel? Neither seems right to me in
all situations, which is why I just left the `mess' in the filesystem
for the user to resolve at their own pace.
> That's all the features I'm really after.
I like what you are suggesting and will try to incorporate these
improvements this week.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Don't send copies to the From: address
From: Ryan Anderson @ 2006-02-13 7:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Biesinger, git, Greg Kroah-Hartman
In-Reply-To: <7vk6c2sg66.fsf@assigned-by-dhcp.cox.net>
On Fri, Feb 10, 2006 at 07:55:13PM -0800, Junio C Hamano wrote:
> Christian Biesinger <cbiesinger@web.de> writes:
>
> > Sending copies to the from address is pointless.
>
> Ryan, care to defend this part of the code? This behaviour
> might have been inherited from Greg's original version.
>
> I cannot speak for Ryan or Greg, but I think the script
> deliberately does this to support this workflow:
>
> (1) The original author sends in a patch to a subsystem
> maintainer;
>
> (2) The subsystem maintainer applies the patch to her tree,
> perhaps with her own sign-off and sign-offs by other people
> collected from the list. She examines it and says this
> patch is good;
>
> (3) The commit is formatted and sent to higher level of the
> foodchain. The message is CC'ed to interested parties in
> order to notify that the patch progressed in the
> foodchain.
>
> Me, personally I do not like CC: to people on the signed-off-by
> list, but dropping a note to From: person makes perfect sense to
> me, if it is to notify the progress of the patch.
That's the thinking I've been using everytime I think about how that
code works.
> What you are after _might_ be not CC'ing it if it was your own
> patch. Maybe something like this would help, but even if that
> is the case I suspect many people want to CC herself so it needs
> to be an optional feature.
This is probably along the right lines, but there are a few other things
we need as well.
I'm thinking of "don't add my email to cc:", as well ass "don't add cc:s
from From and Signed-off-by" as an option.
So, please feel free to commit this one, and I'll send a patch in a
minute or two for the other half.
>
> -- >8 --
> [PATCH] Do not CC me
>
> ---
> git diff
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 3f1b3ca..a02e2f8 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -343,7 +343,7 @@ foreach my $t (@files) {
> }
> close F;
>
> - $cc = join(", ", unique_email_list(@cc));
> + $cc = join(", ", unique_email_list(grep { $_ ne $from } @cc));
>
> send_message();
>
>
>
>
>
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* [PATCH 2/2] send-email: Add --cc
From: Ryan Anderson @ 2006-02-13 8:22 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Ryan Anderson
In-Reply-To: <11398189241095-git-send-email-ryan@michonline.com>
Since Junio used this in an example, and I've personally tried to use it, I
suppose the option should actually exist.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
Documentation/git-send-email.txt | 3 +++
git-send-email.perl | 8 ++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
6d18725b9d46259162cfe54c9e0e369558394816
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index c2f52f5..8c58685 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -24,6 +24,9 @@ OPTIONS
-------
The options available are:
+--cc::
+ Specify a starting "Cc:" value for each email.
+
--chain-reply-to, --no-chain-reply-to::
If this is set, each email will be sent as a reply to the previous
email sent. If disabled with "--no-chain-reply-to", all emails after
diff --git a/git-send-email.perl b/git-send-email.perl
index abffca5..13b85dd 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -31,7 +31,7 @@ sub cleanup_compose_files();
my $compose_filename = ".msg.$$";
# Variables we fill in automatically, or via prompting:
-my (@to,@cc,$initial_reply_to,$initial_subject,@files,$from,$compose);
+my (@to,@cc,@initial_cc,$initial_reply_to,$initial_subject,@files,$from,$compose);
# Behavior modification variables
my ($chain_reply_to, $smtp_server, $quiet, $suppress_from, $no_signed_off_cc) = (1, "localhost", 0, 0, 0);
@@ -48,6 +48,7 @@ my $rc = GetOptions("from=s" => \$from,
"in-reply-to=s" => \$initial_reply_to,
"subject=s" => \$initial_subject,
"to=s" => \@to,
+ "cc=s" => \@initial_cc,
"chain-reply-to!" => \$chain_reply_to,
"smtp-server=s" => \$smtp_server,
"compose" => \$compose,
@@ -199,6 +200,9 @@ Options:
--to Specify the primary "To:" line of the email.
+ --cc Specify an initial "Cc:" list for the entire series
+ of emails.
+
--compose Use \$EDITOR to edit an introductory message for the
patch series.
@@ -298,7 +302,7 @@ $subject = $initial_subject;
foreach my $t (@files) {
open(F,"<",$t) or die "can't open file $t";
- @cc = ();
+ @cc = @initial_cc;
my $found_mbox = 0;
my $header_done = 0;
$message = "";
--
1.2.0.g6d18
^ permalink raw reply related
* [PATCH 0/2] More git-send-email updates
From: Ryan Anderson @ 2006-02-13 8:22 UTC (permalink / raw)
To: Junio C Hamano, git
To follow up on some conversations related to git-send-email this week, here are two updates:
The first adds a command line option to suppress adding the "From" address to
the list of addresses to Cc, when it appears in a From: header line. (Note
that git-send-email never looked for From: lines inside the body of a message
to use as a source for Cc: addresses, which, given the patch formats Linus has
previously talked about, is probably a bug.)
The second patch adds the mythical "--cc" option. I say "mythical" because it
has never existed, but both Junio and I have mentioned it (or used it)
recently, so we both *assumed* that it existed. I think that's justification
for adding it.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* [PATCH 1/2] send-email: Add some options for controlling how addresses are automatically
From: Ryan Anderson @ 2006-02-13 8:22 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Ryan Anderson
In-Reply-To: <11398189232404-git-send-email-ryan@michonline.com>
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
Documentation/git-send-email.txt | 7 +++++++
git-send-email.perl | 15 ++++++++++++---
2 files changed, 19 insertions(+), 3 deletions(-)
dc4ad3ef1b29ce35dc0ace4d284cfab5e594bfb7
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 00537d8..c2f52f5 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -48,6 +48,9 @@ The options available are:
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
+--no-signed-off-by-cc::
+ Do not add emails foudn in Signed-off-by: lines to the cc list.
+
--quiet::
Make git-send-email less verbose. One line per email should be
all that is output.
@@ -61,6 +64,10 @@ The options available are:
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
+--suppress-from::
+ Do not add the From: address to the cc: list, if it shows up in a From:
+ line.
+
--to::
Specify the primary recipient of the emails generated.
Generally, this will be the upstream maintainer of the
diff --git a/git-send-email.perl b/git-send-email.perl
index 3f1b3ca..abffca5 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -34,7 +34,7 @@ my $compose_filename = ".msg.$$";
my (@to,@cc,$initial_reply_to,$initial_subject,@files,$from,$compose);
# Behavior modification variables
-my ($chain_reply_to, $smtp_server, $quiet) = (1, "localhost", 0);
+my ($chain_reply_to, $smtp_server, $quiet, $suppress_from, $no_signed_off_cc) = (1, "localhost", 0, 0, 0);
# Example reply to:
#$initial_reply_to = ''; #<20050203173208.GA23964@foobar.com>';
@@ -52,6 +52,8 @@ my $rc = GetOptions("from=s" => \$from,
"smtp-server=s" => \$smtp_server,
"compose" => \$compose,
"quiet" => \$quiet,
+ "suppress-from" => \$suppress_from,
+ "no-signed-off-cc" => \$no_signed_off_cc,
);
# Now, let's fill any that aren't set in with defaults:
@@ -212,13 +214,19 @@ Options:
email sent, rather than to the first email sent.
Defaults to on.
+ --no-signed-off-cc Suppress the automatic addition of email addresses
+ that appear in a Signed-off-by: line, to the cc: list.
+ Note: Using this option is not recommended.
+
--smtp-server If set, specifies the outgoing SMTP server to use.
Defaults to localhost.
+ --suppress-from Supress sending emails to yourself if your address
+ appears in a From: line.
+
--quiet Make git-send-email less verbose. One line per email should be
all that is output.
-
Error: Please specify a file or a directory on the command line.
EOT
exit(1);
@@ -304,6 +312,7 @@ foreach my $t (@files) {
$subject = $1;
} elsif (/^(Cc|From):\s+(.*)$/) {
+ next if ($2 eq $from && $suppress_from);
printf("(mbox) Adding cc: %s from line '%s'\n",
$2, $_) unless $quiet;
push @cc, $2;
@@ -332,7 +341,7 @@ foreach my $t (@files) {
}
} else {
$message .= $_;
- if (/^Signed-off-by: (.*)$/i) {
+ if (/^Signed-off-by: (.*)$/i && !$no_signed_off_cc) {
my $c = $1;
chomp $c;
push @cc, $c;
--
1.2.0.g6d18
^ permalink raw reply related
* git-bisect problem
From: Andrew Morton @ 2006-02-13 8:25 UTC (permalink / raw)
To: git
I've been trying to locate an ipw2200 regression in Jeff's tree
(git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git#ALL)
and it ended up leading me to
826eeb53a6f264842200d3311d69107d2eb25f5e is first bad commit
diff-tree 826eeb53a6f264842200d3311d69107d2eb25f5e (from 33052057e3e2db7f37fc78aa3f25c98f7e989fae)
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Thu Feb 2 22:03:08 2006 -0800
Linux v2.6.16-rc2
which wasn't very useful.
I don't _think_ I screwed anything up.
git-bisect start
# good: [2664b25051f7ab96b22b199aa2f5ef6a949a4296] Linux v2.6.16-rc1
git-bisect good 2664b25051f7ab96b22b199aa2f5ef6a949a4296
# bad: [826eeb53a6f264842200d3311d69107d2eb25f5e] Linux v2.6.16-rc2
git-bisect bad 826eeb53a6f264842200d3311d69107d2eb25f5e
# good: [10379a25fee8ddc8698d2f6c54ccedd4664c2941] Merge master.kernel.org:/pub/scm/linux/kernel/git/davej/agpgart
git-bisect good 10379a25fee8ddc8698d2f6c54ccedd4664c2941
# good: [9a2dba4b4912b493070cbc170629fdbf440b01d7] slab: rename ac_data to cpu_cache_get
git-bisect good 9a2dba4b4912b493070cbc170629fdbf440b01d7
# good: [9ad11ab48b1ad618bf47076e9e579f267f5306c2] compat: fix compat_sys_openat and friends
git-bisect good 9ad11ab48b1ad618bf47076e9e579f267f5306c2
# good: [1494a92f4c2b1d5abdaa1f823dd19f797bb137de] [ALSA] hda-codec - Fix typos in alc882 model table
git-bisect good 1494a92f4c2b1d5abdaa1f823dd19f797bb137de
# good: [9fdb62af92c741addbea15545f214a6e89460865] [ACPI] merge 3549 4320 4485 4588 4980 5483 5651 acpica asus fops pnpacpi branches into release
git-bisect good 9fdb62af92c741addbea15545f214a6e89460865
# good: [cf41f8ac386e8d62122e7e394b4c6b3e3ab30ede] Merge branch 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
git-bisect good cf41f8ac386e8d62122e7e394b4c6b3e3ab30ede
# good: [00b464debf0038b1628996065f0be564ccfbfd86] SUNRPC: Remove obsolete rpcauth #defines
git-bisect good 00b464debf0038b1628996065f0be564ccfbfd86
# good: [35849c75d7750a254119c1a4b88c90156919df2a] md: Add sysfs access to raid6 stripe cache size
git-bisect good 35849c75d7750a254119c1a4b88c90156919df2a
# good: [33052057e3e2db7f37fc78aa3f25c98f7e989fae] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
git-bisect good 33052057e3e2db7f37fc78aa3f25c98f7e989fae
^ permalink raw reply
* Re: git-bisect problem
From: Junio C Hamano @ 2006-02-13 9:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <20060213002502.5c23122c.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> writes:
> I've been trying to locate an ipw2200 regression in Jeff's tree
> (git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git#ALL)
> and it ended up leading me to
>
> 826eeb53a6f264842200d3311d69107d2eb25f5e is first bad commit
> diff-tree 826eeb53a6f264842200d3311d69107d2eb25f5e (from 33052057e3e2db7f37fc78aa3f25c98f7e989fae)
> Author: Linus Torvalds <torvalds@g5.osdl.org>
> Date: Thu Feb 2 22:03:08 2006 -0800
>
> Linux v2.6.16-rc2
>
> which wasn't very useful.
>
> I don't _think_ I screwed anything up.
>
> git-bisect start
> # good: [2664b25051f7ab96b22b199aa2f5ef6a949a4296] Linux v2.6.16-rc1
> git-bisect good 2664b25051f7ab96b22b199aa2f5ef6a949a4296
> # bad: [826eeb53a6f264842200d3311d69107d2eb25f5e] Linux v2.6.16-rc2
> git-bisect bad 826eeb53a6f264842200d3311d69107d2eb25f5e
> # good: [10379a25fee8ddc8698d2f6c54ccedd4664c2941] Merge master.kernel.org:/pub/scm/linux/kernel/git/davej/agpgart
> git-bisect good 10379a25fee8ddc8698d2f6c54ccedd4664c2941
> # good: [9a2dba4b4912b493070cbc170629fdbf440b01d7] slab: rename ac_data to cpu_cache_get
> git-bisect good 9a2dba4b4912b493070cbc170629fdbf440b01d7
> # good: [9ad11ab48b1ad618bf47076e9e579f267f5306c2] compat: fix compat_sys_openat and friends
> git-bisect good 9ad11ab48b1ad618bf47076e9e579f267f5306c2
> # good: [1494a92f4c2b1d5abdaa1f823dd19f797bb137de] [ALSA] hda-codec - Fix typos in alc882 model table
> git-bisect good 1494a92f4c2b1d5abdaa1f823dd19f797bb137de
> # good: [9fdb62af92c741addbea15545f214a6e89460865] [ACPI] merge 3549 4320 4485 4588 4980 5483 5651 acpica asus fops pnpacpi branches into release
> git-bisect good 9fdb62af92c741addbea15545f214a6e89460865
> # good: [cf41f8ac386e8d62122e7e394b4c6b3e3ab30ede] Merge branch 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
> git-bisect good cf41f8ac386e8d62122e7e394b4c6b3e3ab30ede
At this point, looking at "git bisect visualize" shows that
bisect point is at "SUNRPC: Remove obsolete rpcauth #defines",
and commits older than that are NFSv3, 4 SUNRPCs, 2 NLMs, and
stops at "[PATCH] kernel-doc: clean up the script (whitespace)".
> # good: [00b464debf0038b1628996065f0be564ccfbfd86] SUNRPC: Remove obsolete rpcauth #defines
> git-bisect good 00b464debf0038b1628996065f0be564ccfbfd86
And this is marked to be good -- it leaves:
SUNPRC good
SUNRPC NFSv3 00b464
...o---o---o---o---------o--------o
/ bad
o---o---o---o---o---o v2.6.16-rc2
good
cf41f8 md md md md dm
> # good: [35849c75d7750a254119c1a4b88c90156919df2a] md: Add sysfs access to raid6 stripe cache size
> git-bisect good 35849c75d7750a254119c1a4b88c90156919df2a
Then you mark the rightmost md to be good.
good
00b464
o---------o--------o
/ bad
o---o v2.6.16-rc2
good
md dm
So at this point, assuming the bug is something that is
bisectable, there are still three suspects:
(1) dm (device-mapper log bitset: fix big endian)
(2) the merge was screwed up
(3) Linus did more than setting EXTRAVERSION in v2.6.16-rc2
> # good: [33052057e3e2db7f37fc78aa3f25c98f7e989fae] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
> git-bisect good 33052057e3e2db7f37fc78aa3f25c98f7e989fae
And your test showed the merge one was good.
good
330520
o---------o--------o
/ bad
o---o v2.6.16-rc2
good
md dm
As humans, we can tell that it is not very plausible that the
EXTRAVERSION change caused whatever breakage you are chasing,
but sorry, from your log, I think bisect is doing the right
thing.
The last stretch of the md/dm track does not seem to have much
to do with ipw2200 (isn't that a wireless thing?), and the other
track does not look card specific even though NFS and SUNRPC
sounds networking related. If I have to guess:
(0) the bug is not really reproducible;
(1) an earlier part of bisection misrecorded bad as good;
(2) older commits on these two tracks have subtle interaction,
and the problem does not surface without such interaction
(but that is not plausible because your test on the final
"merge" should have shown the problem if that is the case);
^ permalink raw reply
* Re: stg refresh/conflict resolution helptext/reality inconsistency
From: Catalin Marinas @ 2006-02-13 9:20 UTC (permalink / raw)
To: Ben Clifford; +Cc: git
In-Reply-To: <Pine.OSX.4.64.0602131305420.19080@piva.hawaga.org.uk>
On 13/02/06, Ben Clifford <benc@hawaga.org.uk> wrote:
> The following happens to me. The help text about using "refresh" doesn't
> seem to match up what I actually did. Am I doing something wrong?
Indeed, the 'refresh' help doesn't say anything about this. Dealing
with conflicts can be found in the tutorial.
> $ stg push
> Pushing patch "strcmp-ordering"...Error: three-way merge tool failed for
> file "imap/src/osdep/unix/maildir.c"
> The merge failed during "push". Use "refresh" after fixing the conflicts
> stg push: git-merge-index failed (possible conflicts)
>
> [edit file to get rid of the <<< === >>> stuff]
>
> $ stg refresh
> stg refresh: Unsolved conflicts. Please resolve them first
'stg status -c' would show the conflict files.
> $ rm .git/conflicts
'stg resolved --all' does the same thing. I'd recommend that you use
it instead since it also clears the index if the merge conflict wasn't
handled by gitmergeonefile.py.
If you don't like doing this, you can set 'autoresolved: yes' in your
configuration file (/etc/stgitrc, ~/.stgitrc or .git/stgitrc) which
would mark all the conficts as resolved before refreshing. I
personally prefer to mark each individual conflict as resolved.
Setting 'keeporig: no' would also prevent StGIT from generating the
original versions of the file being merged.
--
Catalin
^ permalink raw reply
* Re: Two crazy proposals for changing git's diff commands
From: Catalin Marinas @ 2006-02-13 9:23 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrnduphvr.2i8.mdw@metalzone.distorted.org.uk>
Mark Wooding <mdw@distorted.org.uk> wrote:
> (I really look forward to a StGIT which can withstand git-prune.)
Almost sure in the next release, probably sometime in March.
--
Catalin
^ permalink raw reply
* Re: git-bisect problem
From: Andrew Morton @ 2006-02-13 9:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virrj1v44.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
>
> As humans, we can tell that it is not very plausible that the
> EXTRAVERSION change caused whatever breakage you are chasing,
> but sorry, from your log, I think bisect is doing the right
> thing.
I don't think humans are well-suited to using git.
My current theory is that I was bisecting Linus's tree all along.
What is the correct way in which to switch to git-netdev-all in preparation
for performing the bisection?
^ permalink raw reply
* Re: git-bisect problem
From: Ryan Anderson @ 2006-02-13 9:39 UTC (permalink / raw)
To: Andrew Morton; +Cc: Junio C Hamano, git
In-Reply-To: <20060213013205.4ba47836.akpm@osdl.org>
On Mon, Feb 13, 2006 at 01:32:05AM -0800, Andrew Morton wrote:
> Junio C Hamano <junkio@cox.net> wrote:
> >
> > As humans, we can tell that it is not very plausible that the
> > EXTRAVERSION change caused whatever breakage you are chasing,
> > but sorry, from your log, I think bisect is doing the right
> > thing.
>
> I don't think humans are well-suited to using git.
>
> My current theory is that I was bisecting Linus's tree all along.
>
> What is the correct way in which to switch to git-netdev-all in preparation
> for performing the bisection?
First, use "git branch" to show you what branches exist, the * will mark
the current one.
Then "git checkout $branch" to switch to one that exists, or "git
checkout -b $newbranch $sourcebranch" to create a new branch starting
from $sourcebranch (which can also be a random commit/tag/etc).
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: git-bisect problem
From: Andrew Morton @ 2006-02-13 9:51 UTC (permalink / raw)
To: Ryan Anderson; +Cc: junkio, git
In-Reply-To: <20060213093938.GC11053@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> wrote:
>
> On Mon, Feb 13, 2006 at 01:32:05AM -0800, Andrew Morton wrote:
> > Junio C Hamano <junkio@cox.net> wrote:
> > >
> > > As humans, we can tell that it is not very plausible that the
> > > EXTRAVERSION change caused whatever breakage you are chasing,
> > > but sorry, from your log, I think bisect is doing the right
> > > thing.
> >
> > I don't think humans are well-suited to using git.
> >
> > My current theory is that I was bisecting Linus's tree all along.
> >
> > What is the correct way in which to switch to git-netdev-all in preparation
> > for performing the bisection?
>
> First, use "git branch" to show you what branches exist, the * will mark
> the current one.
>
> Then "git checkout $branch" to switch to one that exists, or "git
> checkout -b $newbranch $sourcebranch" to create a new branch starting
> from $sourcebranch (which can also be a random commit/tag/etc).
>
Yeah, am (ret)trying that.
Assuming I find the bad commit, how do I extract it as a patch?
I tried
git-format-patch -o ~/a 386093ef9a6c88576d8b418bf1c8616d5e410a20 git-netdev-all
and that chewed 10 minutes CPU time and produced no output, so I killed it.
^ permalink raw reply
* Re: git-bisect problem
From: Fernando J. Pereda @ 2006-02-13 9:58 UTC (permalink / raw)
To: git
In-Reply-To: <20060213015146.26e6c09d.akpm@osdl.org>
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]
On Mon, Feb 13, 2006 at 01:51:46AM -0800, Andrew Morton wrote:
| Assuming I find the bad commit, how do I extract it as a patch?
|
| I tried
|
| git-format-patch -o ~/a 386093ef9a6c88576d8b418bf1c8616d5e410a20 git-netdev-all
|
| and that chewed 10 minutes CPU time and produced no output, so I killed it.
This gives you the whole info about the commit, including a patch:
git cat-file commit 386093ef9a6c88576d8b418bf1c8616d5e410a20
Cheers,
Ferdy
--
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-bisect problem
From: Junio C Hamano @ 2006-02-13 10:08 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <20060213013205.4ba47836.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> writes:
>> As humans, we can tell that it is not very plausible that the
>> EXTRAVERSION change caused whatever breakage you are chasing,
>> but sorry, from your log, I think bisect is doing the right
>> thing.
>
> I don't think humans are well-suited to using git.
I did not mean that ;-). Git is not as smart as humans.
> My current theory is that I was bisecting Linus's tree all along.
Sorry, I did not realize that was _not_ what you were doing.
Your log started by saying 2.6.16-rc1 is good but 2.6.16-rc2 was
not, so I just assumed your bug was between those two.
If your suspect was merged between these two versions, then it
does not matter which branch you were _on_ when you started to
bisect.
You mark points that are good and bad, and wander around in the
commit DAG, trying to narrow down the distance between known
good points and bad points while bisecting, and during that, you
are not really on _any_ branch.
^ permalink raw reply
* Re: git-bisect problem
From: Ryan Anderson @ 2006-02-13 10:14 UTC (permalink / raw)
To: Andrew Morton; +Cc: junkio, git
In-Reply-To: <20060213015146.26e6c09d.akpm@osdl.org>
On Mon, Feb 13, 2006 at 01:51:46AM -0800, Andrew Morton wrote:
>
> Assuming I find the bad commit, how do I extract it as a patch?
>
> I tried
>
> git-format-patch -o ~/a 386093ef9a6c88576d8b418bf1c8616d5e410a20 git-netdev-all
>
> and that chewed 10 minutes CPU time and produced no output, so I killed it.
Well, assuming it's not a merge, you'll want something like this:
git format-patch -o ~/a 386093ef9a6c88576d8b418bf1c8616d5e410a20^1..386093ef9a6c88576d8b418bf1c8616d5e410a20
For essentially the same output, you can do a few other variations:
git whatchanged -p 386093ef9a6c88576d8b418bf1c8616d5e410a20^1..386093ef9a6c88576d8b418bf1c8616d5e410a20
git diff 386093ef9a6c88576d8b418bf1c8616d5e410a20^1..386093ef9a6c88576d8b418bf1c8616d5e410a20
If it's a merge that bisect terminates on, things get a bit trickier, as
you want to figure out what went wrong in the merge to cause it, so
you'll want to use either the syntax for specifying which merge parent
to look at (which I forget at the moment) or, run:
git rev-list --parents --max-count=1 386093ef9a6c88576d8b418bf1c8616d5e410a20
and look at columns 2+ individually.
In fact, if you want, you can re-do the merge, by creating some branches
based off of each parent, then pulling one into the other, and seeing
what went wrong.
Hope that helps (if not, I apologize - I should've gone to bed a while
ago and it may have snuck through)
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: git-bisect problem
From: Andrew Morton @ 2006-02-13 10:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqxb1sho.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
>
> Andrew Morton <akpm@osdl.org> writes:
>
> >> As humans, we can tell that it is not very plausible that the
> >> EXTRAVERSION change caused whatever breakage you are chasing,
> >> but sorry, from your log, I think bisect is doing the right
> >> thing.
> >
> > I don't think humans are well-suited to using git.
>
> I did not mean that ;-). Git is not as smart as humans.
>
> > My current theory is that I was bisecting Linus's tree all along.
>
> Sorry, I did not realize that was _not_ what you were doing.
> Your log started by saying 2.6.16-rc1 is good but 2.6.16-rc2 was
> not, so I just assumed your bug was between those two.
>
> If your suspect was merged between these two versions, then it
> does not matter which branch you were _on_ when you started to
> bisect.
>
> You mark points that are good and bad, and wander around in the
> commit DAG, trying to narrow down the distance between known
> good points and bad points while bisecting, and during that, you
> are not really on _any_ branch.
So how am I supposed to find this bug in Jeff's tree?
I do git-checkout -f git-netdev-all, then do the bisection and I come up
with junk.
<does it all again>
It points at this:
commit a03b1950521466e007288a25c9fc7ac7f05a97e5
Merge: 0b310f36d7d96e27f6941ec0f9b95e15142f1e78 c6f0d75a2defe8c7d8bf9f78de891cedc46b4b3e
Author: Jeff Garzik <jgarzik@pobox.com>
Date: Tue Jan 31 11:52:21 2006 -0500
Merge branch 'upstream-fixes'
git-bisect start
# good: [d834a41c966c6a20368fadb59248740935e6fbae] ipw2200: do not sleep in ipw_request_direct_scan
git-bisect good d834a41c966c6a20368fadb59248740935e6fbae
# bad: [b0afb58735e5dae05cb06ce6d0ca3073f390e9dc] Merge branch 'upstream'
git-bisect bad b0afb58735e5dae05cb06ce6d0ca3073f390e9dc
# good: [0c19585b0d2f6817dd9af607650d3f6cae2fd8bc] uml: typo fixup
git-bisect good 0c19585b0d2f6817dd9af607650d3f6cae2fd8bc
# good: [71baa1a599c04ab56ebf5fdb8d03abd0d601462f] [MIPS] Get rid of unnecessary prototypes. Fixes and optimizations for HZ > 100.
git-bisect good 71baa1a599c04ab56ebf5fdb8d03abd0d601462f
# good: [d04e4e115bd9df2b748cb30abd610f3c0eb1e303] eeh_driver NULL noise removal
git-bisect good d04e4e115bd9df2b748cb30abd610f3c0eb1e303
# good: [9908104935325bd6beba67d637b6f5396d47075c] [IPV6]: Address autoconfiguration does not work after device down/up cycle
git-bisect good 9908104935325bd6beba67d637b6f5396d47075c
# good: [0b310f36d7d96e27f6941ec0f9b95e15142f1e78] Merge branch 'upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
git-bisect good 0b310f36d7d96e27f6941ec0f9b95e15142f1e78
# bad: [70c07e02625ec46d0ffbfce1acef42d660803528] Merge branch 'viro'
git-bisect bad 70c07e02625ec46d0ffbfce1acef42d660803528
# good: [2746b8623abce815aaae7afc946b1b39f8436f5a] Merge branch 'net.b0' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/bird
git-bisect good 2746b8623abce815aaae7afc946b1b39f8436f5a
# bad: [6bd0e10e53cc4824cd8cdaab8c370e53ab2e23c2] Merge branch 'sundance'
git-bisect bad 6bd0e10e53cc4824cd8cdaab8c370e53ab2e23c2
# bad: [3c9b3a8575b4f2551e3b5b74ffa1c3559c6338eb] Merge branch 'master'
git-bisect bad 3c9b3a8575b4f2551e3b5b74ffa1c3559c6338eb
# bad: [c0d3c0c0ce94d3db893577ae98e64414d92e49d8] [netdrvr] schedule eepro100 for removal
git-bisect bad c0d3c0c0ce94d3db893577ae98e64414d92e49d8
# bad: [a03b1950521466e007288a25c9fc7ac7f05a97e5] Merge branch 'upstream-fixes'
git-bisect bad a03b1950521466e007288a25c9fc7ac7f05a97e5
^ permalink raw reply
* Re: git-bisect problem
From: Luben Tuikov @ 2006-02-13 10:22 UTC (permalink / raw)
To: Fernando J. Pereda, git, Andrew Morton
In-Reply-To: <20060213095859.GA17115@ferdyx.org>
--- "Fernando J. Pereda" <ferdy@ferdyx.org> wrote:
> On Mon, Feb 13, 2006 at 01:51:46AM -0800, Andrew Morton wrote:
> | Assuming I find the bad commit, how do I extract it as a patch?
> |
> | I tried
> |
> | git-format-patch -o ~/a 386093ef9a6c88576d8b418bf1c8616d5e410a20 git-netdev-all
> |
> | and that chewed 10 minutes CPU time and produced no output, so I killed it.
>
> This gives you the whole info about the commit, including a patch:
>
> git cat-file commit 386093ef9a6c88576d8b418bf1c8616d5e410a20
I personally like
git-diff-file
^ permalink raw reply
* Re: git-bisect problem
From: Luben Tuikov @ 2006-02-13 10:23 UTC (permalink / raw)
To: Fernando J. Pereda, git
In-Reply-To: <20060213095859.GA17115@ferdyx.org>
--- "Fernando J. Pereda" <ferdy@ferdyx.org> wrote:
> On Mon, Feb 13, 2006 at 01:51:46AM -0800, Andrew Morton wrote:
> | Assuming I find the bad commit, how do I extract it as a patch?
> |
> | I tried
> |
> | git-format-patch -o ~/a 386093ef9a6c88576d8b418bf1c8616d5e410a20 git-netdev-all
> |
> | and that chewed 10 minutes CPU time and produced no output, so I killed it.
>
> This gives you the whole info about the commit, including a patch:
>
> git cat-file commit 386093ef9a6c88576d8b418bf1c8616d5e410a20
I meant to say:
git-diff-tree --pretty -p <commit_id>
Luben
^ permalink raw reply
* Re: git-bisect problem
From: Andrew Morton @ 2006-02-13 10:25 UTC (permalink / raw)
To: Ryan Anderson; +Cc: junkio, git
In-Reply-To: <20060213101443.GD11053@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> wrote:
>
> On Mon, Feb 13, 2006 at 01:51:46AM -0800, Andrew Morton wrote:
> >
> > Assuming I find the bad commit, how do I extract it as a patch?
> >
> > I tried
> >
> > git-format-patch -o ~/a 386093ef9a6c88576d8b418bf1c8616d5e410a20 git-netdev-all
> >
> > and that chewed 10 minutes CPU time and produced no output, so I killed it.
>
> Well, assuming it's not a merge, you'll want something like this:
>
> git format-patch -o ~/a 386093ef9a6c88576d8b418bf1c8616d5e410a20^1..386093ef9a6c88576d8b418bf1c8616d5e410a20
That worked.
> For essentially the same output, you can do a few other variations:
>
> git whatchanged -p 386093ef9a6c88576d8b418bf1c8616d5e410a20^1..386093ef9a6c88576d8b418bf1c8616d5e410a20
> git diff 386093ef9a6c88576d8b418bf1c8616d5e410a20^1..386093ef9a6c88576d8b418bf1c8616d5e410a20
>
> If it's a merge that bisect terminates on, things get a bit trickier, as
> you want to figure out what went wrong in the merge to cause it, so
> you'll want to use either the syntax for specifying which merge parent
> to look at (which I forget at the moment) or, run:
> git rev-list --parents --max-count=1 386093ef9a6c88576d8b418bf1c8616d5e410a20
> and look at columns 2+ individually.
It did terminate on a merge. Thats over four hours gone and, frankly, I'm
sick of it. I just want the darned diffs so I can do something useful.
> In fact, if you want, you can re-do the merge, by creating some branches
> based off of each parent, then pulling one into the other, and seeing
> what went wrong.
>
> Hope that helps (if not, I apologize - I should've gone to bed a while
> ago and it may have snuck through)
It does.
I'm still not having much success geting a string of patches out of it.
git format-patch -o ~/a d834a41c966c6a20368fadb59248740935e6fbae..826eeb53a6f264842200d3311d69107d2eb25f5e
Has chewed 5 minutes CPU so far and hasn't produced anything.
How do I get the IPW patches out of Jeff's tree, in order?
I guess since I found a command which actually works, I can type that
20-odd times.
^ permalink raw reply
* Re: git-bisect problem
From: Luben Tuikov @ 2006-02-13 10:40 UTC (permalink / raw)
To: Ryan Anderson, Andrew Morton; +Cc: junkio, git
In-Reply-To: <20060213101443.GD11053@mythryan2.michonline.com>
Andrew,
Here is the output:
$ git-diff-tree --pretty -p 386093ef9a6c88576d8b418bf1c8616d5e410a20
diff-tree 386093ef9a6c88576d8b418bf1c8616d5e410a20 (from ce5f8d70ba6e3d7ffcaff86b2cf91a42c27f77af)
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date: Wed Feb 1 03:04:57 2006 -0800
[PATCH] ipw2200: fix ->eeprom[EEPROM_VERSION] check
priv->eeprom is a pointer.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Acked-by: Yi Zhu <yi.zhu@intel.com>
Cc: James Ketrenos <jketreno@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
diff --git a/drivers/net/wireless/ipw2200.c b/drivers/net/wireless/ipw2200.c
index 916b24c..14beab4 100644
--- a/drivers/net/wireless/ipw2200.c
+++ b/drivers/net/wireless/ipw2200.c
@@ -2456,7 +2456,7 @@ static void ipw_eeprom_init_sram(struct
copy. Otherwise let the firmware know to perform the operation
on it's own
*/
- if ((priv->eeprom + EEPROM_VERSION) != 0) {
+ if (priv->eeprom[EEPROM_VERSION] != 0) {
IPW_DEBUG_INFO("Writing EEPROM data into SRAM\n");
/* write the eeprom data to sram */
Luben
^ permalink raw reply related
* Re: git-bisect problem
From: Andrew Morton @ 2006-02-13 10:44 UTC (permalink / raw)
To: ltuikov; +Cc: ryan, junkio, git
In-Reply-To: <20060213104036.67433.qmail@web31811.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> wrote:
>
> Andrew,
>
> Here is the output:
>
> $ git-diff-tree --pretty -p 386093ef9a6c88576d8b418bf1c8616d5e410a20
Yes, that is decent. But for many patches, I'd end up having to call the
files "386093ef9a6c88576d8b418bf1c8616d5e410a20.patch". git-format-patch
chooses nice filenames. Slowly.
Anyway, repeated applications of the one-diff git-format-patch (based on a
grep of the git-log output) got me the 69 patches which I want, so I can
find this bug now, thanks.
^ permalink raw reply
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