* 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
* cat-file (was Re: git-bisect problem)
From: Joshua N Pritikin @ 2006-02-13 12:21 UTC (permalink / raw)
To: git
In-Reply-To: <20060213095859.GA17115@ferdyx.org>
[-- Attachment #1: Type: text/plain, Size: 340 bytes --]
On Mon, Feb 13, 2006 at 10:58:59AM +0100, Fernando J. Pereda wrote:
> This gives you the whole info about the commit, including a patch:
>
> git cat-file commit 386093ef9a6c88576d8b418bf1c8616d5e410a20
Eh? Then why not call the command "cat-object" or simply "cat"?
--
Make April 15 just another day, visit http://fairtax.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Catalin Marinas @ 2006-02-13 14:40 UTC (permalink / raw)
To: git
In-Reply-To: <20060210195914.GA1350@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> I just posted the first public version of pg, a GIT porcelain for
> managing patches. Think StGIT, but better in some ways:
Couldn't help replying to such a topic :-) (only that the ":" ending
of the above phrase might make people think that some features you
listed are not available in StGIT).
Without much testing, I think pg is a good tool but it is different
from StGIT in many ways. It mainly resembles the topic branches way of
working with the advantage of having them stacked on each-other. Each
patch seems to be equivalent to a topic branch where you can commit
changes. Rebasing a patch is equivalent to a merge in a branch with
the merge commit having a general description like "Refreshed patch
..." and two parents - the new base and the old top.
While I don't say the above is a bad thing, it is pretty different
from StGIT. With StGIT, the history of the tree only shows one commit
per patch with the patch description chosen by the user. If you edit
the description or modify the patch, the old patch or description is
dropped from the main branch (visible via HEAD) and you only get the
latest one. This clean history has many advantages when sending
patches upstream either via e-mail or by asking for a pull.
> - Simplified command line user interface.
>
> pg tries to simplify GIT by 'hiding' the index and behaving like
> more traditional SCMs which only look at `HEAD` (last commit)
> and the working directory (files).
This is the case with StGIT as well. It doesn't usually require the
use of GIT commands directly.
> - Preserves change history of patches.
>
> The complete change history associated with each patch is
> maintained directly within GIT. By storing the evolution of a
> patch as a sequence of GIT commits standard GIT history tools
> such as gitk can be used.
There have been discussions to adding this to StGIT as well (and there
is a patch already from Chuck). It is a good thing to have but I'm
opposed to the idea of having the history accessible from the top of
the patch. Since the patch can be refreshed indefinitely, it would
make the main history (visible from HEAD) really ugly and also cause
problems with people pulling from a tree. I prefer to have a separate
command (like 'stg id patch/log') that gives access to the history.
> - Its prune proof.
>
> The metadata structure is stored entirely within the refs
> directory and the object database, which means you can safely use
> git-prune without damaging your work, even for unapplied
> patches.
That's missing indeed in StGIT but it will be available in the next
release. I didn't push this yet because I wasn't sure what to do with
the refresh history of a patch.
> - Automatic detection (and cancellation) of returning patches.
>
> pg automatically detects when a patch is received from
> the upstream GIT repository during a pg-rebase and deletes
> (cancels) the local version of the patch from the patch series.
> The automatic cancelling makes it easy to use pg to track and
> develop changes on top of a GIT project.
StGIT has been doing this from the beginning. You would need to run a
'stg clean' after a rebase (or push). I prefer to run this command
manually so that 'stg series -e' would show the empty patches and let
me decided what to do with them.
> - Fast
>
> pg operations generally perform faster than StGIT operations,
> at least on my large (~7000 file) repositories.
Might be possible but I haven't done any tests. There are some
optimisations in StGIT that make it pretty fast: (1) if the base of
the patch has not changed, it can fast-forward the pushed patches
which is O(1) and (2) StGIT first tries to use git-apply when pushing
a patch and use a three-way merge only if this fails (the operation
usually succeeds for most of the patches). There are some speed
problems with three-way merging if there are many file
removals/additions because the external merge tool is called for each
of them but the same problem exists for any other tool.
--
Catalin
^ permalink raw reply
* Re: [PATCH 0/2] More git-send-email updates
From: Nicolas Vilz 'niv' @ 2006-02-13 15:58 UTC (permalink / raw)
To: git
In-Reply-To: <11398189232404-git-send-email-ryan@michonline.com>
Ryan Anderson wrote:
> 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.
>
it is a very nice idea to use git-send-email together with
git-format-patch --stdout, but i think, maybe i do something wrong... I
tried that cli-syntax Junio mentioned in "Whats in git.git"
git format-patch --stdout <branch_01>..<branch_02>|git send-email --to
<email_address>
and got a "Error: Please specify a file or a directory on the command
line.".
Besides, git asks me for a From-Header (which is fixed with this patch,
I suppose)
I use git 1.2.0 directly from your git-repository.
so actually git-send-email does not work with this syntax above.
If I first produce the patches, save them into another directory and
afterwards give git-send-email that directory for lunch, it works...
is there any other work-around for this everyday-task but a shellscript
which temporarily creates a patch-dir which contains the patches and
removes it after git-send-email is done with it?
Sincerly
Nicolas
^ 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