* RE: git pull on Linux/ACPI release tree
From: Linus Torvalds @ 2006-01-08 19:41 UTC (permalink / raw)
To: Brown, Len; +Cc: David S. Miller, linux-acpi, linux-kernel, akpm, git
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B3005A13505@hdsmsx401.amr.corp.intel.com>
On Sun, 8 Jan 2006, Brown, Len wrote:
>
> Perhaps the tools should try to support what "a lot of people"
> expect, rather than making "a lot of people" do extra work
> because of the tools?
>
> Call me old fashioned, but I believe that tools are supposed to
> make work easier, not harder.
They DO.
Len, you're doing EXTRA WORK that is pointless.
Just stop doing the automated merges. Problems solved. It really is that
easy. Don't do what David suggests - he does it because he's apparently
_so_ comfortable with things that he prefers to do extra work just to keep
his trees extra clean (I actually would disagree - but git makes that
fairly easy to do, so if you prefer to have as linear a history as
possible, you can do it with git pretty easily).
Now, I'm only complaining about _automated_ merges. If you have a reason
to worry about my tree having clashes with your tree, do a real merge. For
example, in your latest pull, you had a
"pull linus into release branch"
merge, where you merged my v2.6.15 tree. That makes perfect sense.
What I object to is that there were _also_ two automated merges within ten
hours or each other, with absolutely _zero_ development in your tree in
between. Why did you do that in your development tree? By _definition_ you
had done zero development. You just tracked the development in _my_ tree.
In case you wonder, the two commits I'm talking about are:
add5b5ee992e40c9cd8697ea94c223628be162a7
25da0974601fc8096461f3d3f7ca3aab8e79adfb
and neither of them have any reason to be in a development tree. You
didn't develop them.
They are real merges, because you had a trivial patch in your tree
(changing the acpi-devel mailing list address) that I didn't have, so when
you pulled, your end result was thus always different from something I had
(so you did a real "merge", even though it was totally trivial), but the
point is that there is a difference between "the ACPI development tree"
and "the tree that has random ACPI patches and then tracks Linus' tree as
closely as possible".
See?
That's the most egregious example. There's two unnecessary pulls on
December 28 and 29th too (commits 0a5296dc and c1a959d8).
You can do
gitk 0aec63e..f9a204e1
to see exactly what I see when I pulled from you. 11 commits, 5 of which
are just trivial merges that are no development, just tracking _my_ tree.
Of those, one makes sense (tracking a release).
(NOTE NOTE NOTE! It does make sense to track my tree in case you do big
changes and you worry about clashes. Then you would want to synchronize
those big changes with my changes, so that you can resolve any clashes
early. So I'm not saying that tracking trees is always bad: I'm saying
that doing so _unnecessarily_ is bad, because it adds no value, and it
just makes the history harder to read).
Now, most people don't read the history. It gets messy enough quickly
enough that it's hard to read anyway over time. My tree has tons of _real_
merges anyway, since it's by definition the one that is used for most
synchronization, so my tree is always pretty hard to follow.
But my guess is that this probably makes it harder for _you_ to see what
you've done too. If you didn't merge with me, then "git log" would show
just your own changes at the top, and that's likely what you care most
about anyway, no?
Also, if you didn't pull from me, and you decided that you needed to re-do
your tree (let's say that you notice that one of your commits was bad
_before_ you ask me to pull from your tree), then you'd also have an
easier time re-creating your own development without that buggy change,
exactly because _your_ tree wouldn't have my changed mixed up in it.
So your merges likely make git harder to use for you, not easier.
Linus
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Junio C Hamano @ 2006-01-08 19:33 UTC (permalink / raw)
To: Martin Langhoff
Cc: Brown, Len, David S. Miller, torvalds-3NddpPZAyC0,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, akpm-3NddpPZAyC0,
git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <46a038f90601081119r39014fbi995cc8b6e95774da-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Martin Langhoff <martin.langhoff-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> On 1/9/06, Brown, Len <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>> Perhaps the tools should try to support what "a lot of people"
>> expect, rather than making "a lot of people" do extra work
>> because of the tools?
>
> I think it does. All the tricky stuff that David and Junio have been
> discussing is actually done very transparently by
>
> git-rebase <upstream>
>
> Now, git-rebase uses git-format-patch <options> | git-am <options> so
> it sometimes has problems merging.
Careful. I do not think rebase works across merges at all.
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Martin Langhoff @ 2006-01-08 19:19 UTC (permalink / raw)
To: Brown, Len
Cc: David S. Miller, torvalds-3NddpPZAyC0,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, akpm-3NddpPZAyC0,
git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B3005A13505-N2PTB0HCzHKkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
On 1/9/06, Brown, Len <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> Perhaps the tools should try to support what "a lot of people"
> expect, rather than making "a lot of people" do extra work
> because of the tools?
I think it does. All the tricky stuff that David and Junio have been
discussing is actually done very transparently by
git-rebase <upstream>
Now, git-rebase uses git-format-patch <options> | git-am <options> so
it sometimes has problems merging. In that case, you can choose to
either resolve the problem (see the doco for how to signal to git-am
that you've resolved a conflict) or to cancel the rebase. If you
choose to cancel the rebase, do
cp .git/refs/heads/{<headname>,<headnamebadrebase>}
cat .git/HEAD_ORIG > .git/refs/heads/<headname>
git-reset --hard
rm -fr .dotest
and you'll be back to where you started. Perhaps this could be rolled
into something like git-rebase --cancel to make it easier, but that's
about it. The toolchain definitely supports it.
cheers,
martin
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: git pull on Linux/ACPI release tree
From: Linus Torvalds @ 2006-01-08 19:10 UTC (permalink / raw)
To: Brown, Len
Cc: linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, akpm-3NddpPZAyC0,
git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B3005A13489-N2PTB0HCzHKkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
On Sun, 8 Jan 2006, Brown, Len wrote:
>
> Is it possible for it git, like bk, to simply ignore merge commits in its summary output?
That's not the point. It does: "git log --no-merges" does exactly that.
But fire up "gitk" to watch the history, and see the difference.
> Note that "Auto-update from upstream" is just the place-holder comment
> embedded in the wrapper script in git/Documentation/howto/using-topic-branches.txt
That has absolutely nothing to do with anything. It's not the comment
(which admittedly gives absolutely no information - but why should it,
since the _commit_ itself has no information in it?)
It's like you have empty commits that don't do anything at all, except
that they are worse, because they have two parents.
> I think that Tony's howto above captures two key requirements
> from all kernel maintainers -- which the exception of you --
No. Your commits make it harder for _everybody_ to track the history.
A merge by definition "couples" the history of two branches. That's what a
merge very fundamentally is. It ties two things together. But two things
that don't have any connection to each other _shouldn't_ be tied together.
Just as an example: because of the extra merges, you've made all your
commits dependent on what happened in my tree, with no real reason. So
let's say that somebody reports that something broke in ACPI. Now you
can't just go to the top of the ACPI history and work backwards - you'll
have tied up the two histories so that they are intertwined.
And yes, you can always work around it, but there's just no point. And
none of the other developers seem to need to do it. They do their
development, and then they say "please pull". At that point the two
histories are tied together, but now they are tied together for a
_reason_. It was an intentional synchronization point.
An "automated pull" by definition has no reason. If it works automated,
then the merge has zero semantic meaning.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: git pull on Linux/ACPI release tree
From: Brown, Len @ 2006-01-08 18:28 UTC (permalink / raw)
To: David S. Miller
Cc: torvalds-3NddpPZAyC0, linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, akpm-3NddpPZAyC0,
git-u79uwXL29TY76Z2rM5mHXA
>I know a lot of people react to this kind of usage with "what's the
>point of the source control system if you're just messing with patches
>in and out of the tree all the time" But as a subsystem maintainer,
>you deal with a lot of changes and it's important to get a pristine
>clean history when you push things to Linus.
>
>In fact, I do this so much that Linus's tree HEAD often equals my
>origin when he pulls.
>
>Merges really suck and I also hate it when the tree gets cluttered
>up with them, and Linus is right, ACPI is the worst offender here.
>
>Yes, we can grep the merges out of the shortlog or whatever, but that
>merging crap is still physically in the tree.
>
>Just don't do it. Merge into a private branch for testing if you
>don't want to rebuild trees like I do, but push the clean tree to
>Linus.
Perhaps the tools should try to support what "a lot of people"
expect, rather than making "a lot of people" do extra work
because of the tools?
Call me old fashioned, but I believe that tools are supposed to
make work easier, not harder.
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: git-format-patch Date header
From: Andreas Ericsson @ 2006-01-08 15:44 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060108173736.199df297.tihirvon@gmail.com>
Timo Hirvonen wrote:
> On Sun, 08 Jan 2006 16:21:13 +0100
> Andreas Ericsson <ae@op5.se> wrote:
>
>
>>Timo Hirvonen wrote:
>>
>>>git-format-patch uses "date '+%s %z'" format for the Date header.
>>>Sylpheed does not understand this format. How common this convention
>>>is? Should we change git-format-patch to use more standard date format?
>>>
>>>OTOH, I like the %s format because it is so simple and easy to parse :)
>>>
>>
>>Actually, that's what's printed in the commit message, so any change
>>would have to be put there and that would break backwards compatibility
>>for new tools that might want to use it.
>
>
> So fixing Sylpheed (and maybe other email clients too) is the right
> solution...
>
Nopes. In this case fixing my home-hacked git-send-patch script is the
right thing to do. git-format-patch has always printed that format,
though, so the error lies with me and the patch I sent. I shall have to
re-visit it after reading rfc 822 a bit more closely.
>
>>On an unrelated note, please don't start a new thread by replying to an
>>old message. It's very confusing to follow and people may not see your
>>message. This time it was doubly so because the next mail in my inbox is
>>a patch for git-format-patch, to which I thought you replied.
>
>
> Sorry. I replied to your message because it was the message having Date
> header in the "%s %z" format.
>
I just noticed. Thanks, and sorry.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Apologies for ill-formed mail
From: Andreas Ericsson @ 2006-01-08 15:41 UTC (permalink / raw)
To: git
Hi all.
Sorry for the poorly formatted mail I recently sent to the list. I used
my git-send-patch script, which uses git-format-patch and I forgot that
I had installed the patched git-format-patch version on my system just
prior to sending those patches.
Once again, my apologies.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-format-patch Date header
From: Timo Hirvonen @ 2006-01-08 15:37 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43C12DE9.8010906@op5.se>
On Sun, 08 Jan 2006 16:21:13 +0100
Andreas Ericsson <ae@op5.se> wrote:
> Timo Hirvonen wrote:
> > git-format-patch uses "date '+%s %z'" format for the Date header.
> > Sylpheed does not understand this format. How common this convention
> > is? Should we change git-format-patch to use more standard date format?
> >
> > OTOH, I like the %s format because it is so simple and easy to parse :)
> >
>
> Actually, that's what's printed in the commit message, so any change
> would have to be put there and that would break backwards compatibility
> for new tools that might want to use it.
So fixing Sylpheed (and maybe other email clients too) is the right
solution...
> On an unrelated note, please don't start a new thread by replying to an
> old message. It's very confusing to follow and people may not see your
> message. This time it was doubly so because the next mail in my inbox is
> a patch for git-format-patch, to which I thought you replied.
Sorry. I replied to your message because it was the message having Date
header in the "%s %z" format.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: git-format-patch Date header
From: Andreas Ericsson @ 2006-01-08 15:21 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060108164038.89e4439f.tihirvon@gmail.com>
Timo Hirvonen wrote:
> git-format-patch uses "date '+%s %z'" format for the Date header.
> Sylpheed does not understand this format. How common this convention
> is? Should we change git-format-patch to use more standard date format?
>
> OTOH, I like the %s format because it is so simple and easy to parse :)
>
Actually, that's what's printed in the commit message, so any change
would have to be put there and that would break backwards compatibility
for new tools that might want to use it.
On an unrelated note, please don't start a new thread by replying to an
old message. It's very confusing to follow and people may not see your
message. This time it was doubly so because the next mail in my inbox is
a patch for git-format-patch, to which I thought you replied.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* git-format-patch Date header
From: Timo Hirvonen @ 2006-01-08 14:40 UTC (permalink / raw)
To: git
In-Reply-To: <20060108141457.8C4E85BE8F@nox.op5.se>
git-format-patch uses "date '+%s %z'" format for the Date header.
Sylpheed does not understand this format. How common this convention
is? Should we change git-format-patch to use more standard date format?
OTOH, I like the %s format because it is so simple and easy to parse :)
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* [PATCH] .gitignore git-describe
From: Andreas Ericsson @ 2006-01-08 14:15 UTC (permalink / raw)
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
265df952d4c61f60eae42261aeea90e9b6d8e414
diff --git a/.gitignore b/.gitignore
index 1a9090b..4335061 100644
--- a/.gitignore
+++ b/.gitignore
@@ -23,6 +23,7 @@ git-count-objects
git-cvsexportcommit
git-cvsimport
git-daemon
+git-describe
git-diff
git-diff-files
git-diff-index
--
1.0.7-gb38d1
^ permalink raw reply related
* [PATCH] format-patch: Use --mbox by default.
From: Andreas Ericsson @ 2006-01-08 14:01 UTC (permalink / raw)
This patch enables a slightly modified and more correct --mbox
output by default. The --date, --author and --mbox options
are obsoleted and removed.
Previously, author-info and date was by default only printed if the
commit was made by someone else, irrespective of the obsoleted options.
Since it does no harm having ones own info there too it shouldn't really
matter much, and should lessen the confusion regarding how to use
git-format-patch with git-am.
The patches generated also had bad mail headers for sendmail (of
postfix 2.2.2 at least) to use directly (From: line must be on top,
Subject: last of header), which isn't really an issue but annoying
just the same. I haven't actually tried this new format, but at least
'file' now recognize it as "news or mail text", rather than "ASCII
English text".
Note that this reverts commit aa66c7ec77d474b737da607d6cb2d07f56628def,
"format-patch/commit: Quote single quote in the author name properly"
which is no longer needed since the whosepatchScript now prints
the headers directly rather than passing them to eval.
These changes allow us to remove two conditional statements
and the invokation of a sub-shell in the process_one function,
so it should be a bit faster too.
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
Documentation/git-format-patch.txt | 18 ++-----------
git-format-patch.sh | 49 +++++++-----------------------------
2 files changed, 12 insertions(+), 55 deletions(-)
b38d1ffeb27ba32de849f33a9c416fda4cd8eecb
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 47705de..73e1358 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -9,7 +9,7 @@ git-format-patch - Prepare patches for e
SYNOPSIS
--------
[verse]
-'git-format-patch' [-n | -k] [-o <dir> | --stdout] [-s] [-c] [--mbox]
+'git-format-patch' [-n | -k] [-o <dir> | --stdout] [-s] [-c]
[--diff-options] <his> [<mine>]
DESCRIPTION
@@ -27,9 +27,8 @@ When -n is specified, instead of "[PATCH
line is formatted as "[PATCH N/M] Subject", unless you have only
one patch.
-When --mbox is specified, the output is formatted to resemble
-UNIX mailbox format, and can be concatenated together for
-processing with applymbox.
+The output is formatted to resemble UNIX mailbox format, and can
+be concatenated together for processing with gitlink::git-am[1].
OPTIONS
@@ -45,11 +44,6 @@ OPTIONS
Do not strip/add '[PATCH]' from the first line of the
commit log message.
--a|--author, -d|--date::
- Output From: and Date: headers for commits made by
- yourself as well. Usually these are output only for
- commits made by people other than yourself.
-
-s|--signoff::
Add `Signed-off-by:` line to the commit message, using
the committer identity of yourself.
@@ -61,12 +55,6 @@ OPTIONS
has a SP character immediately followed by a TAB
character.
--m|--mbox::
- Format the output files for closer to mbox format by
- adding a phony Unix "From " line, so they can be
- concatenated together and fed to `git-applymbox`.
- Implies --author and --date.
-
--stdout::
This flag generates the mbox formatted output to the
standard output, instead of saving them into a file per
diff --git a/git-format-patch.sh b/git-format-patch.sh
index 818059f..047246e 100755
--- a/git-format-patch.sh
+++ b/git-format-patch.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2005 Junio C Hamano
#
-USAGE='[-n | -k] [-o <dir> | --stdout] [--signoff] [--check] [--mbox] [--diff-options] <upstream> [<our-head>]'
+USAGE='[-n | -k] [-o <dir> | --stdout] [--signoff] [--check] [--diff-options] <upstream> [<our-head>]'
LONG_USAGE='Prepare each commit with its patch since our-head forked from upstream,
one file per patch, for e-mail submission. Each output file is
numbered sequentially from 1, and uses the first line of the commit
@@ -15,9 +15,8 @@ the current working directory.
When -n is specified, instead of "[PATCH] Subject", the first line is formatted
as "[PATCH N/M] Subject", unless you have only one patch.
-When --mbox is specified, the output is formatted to resemble
-UNIX mailbox format, and can be concatenated together for processing
-with applymbox.'
+The output is formatted to resemble UNIX mailbox format, and can be
+concatenated together for processing with "git am".'
. git-sh-setup
# Force diff to run in C locale.
@@ -32,14 +31,8 @@ outdir=./
while case "$#" in 0) break;; esac
do
case "$1" in
- -a|--a|--au|--aut|--auth|--autho|--author)
- author=t ;;
-c|--c|--ch|--che|--chec|--check)
check=t ;;
- -d|--d|--da|--dat|--date)
- date=t ;;
- -m|--m|--mb|--mbo|--mbox)
- date=t author=t mbox=t ;;
-k|--k|--ke|--kee|--keep|--keep-|--keep-s|--keep-su|--keep-sub|\
--keep-subj|--keep-subje|--keep-subjec|--keep-subject)
keep_subject=t ;;
@@ -48,7 +41,7 @@ do
-s|--s|--si|--sig|--sign|--signo|--signof|--signoff)
signoff=t ;;
--st|--std|--stdo|--stdou|--stdout)
- stdout=t mbox=t date=t author=t ;;
+ stdout=t ;;
-o=*|--o=*|--ou=*|--out=*|--outp=*|--outpu=*|--output=*|--output-=*|\
--output-d=*|--output-di=*|--output-dir=*|--output-dire=*|\
--output-direc=*|--output-direct=*|--output-directo=*|\
@@ -173,12 +166,12 @@ titleScript='
whosepatchScript='
/^author /{
- s/'\''/'\''\\'\'\''/g
- s/author \(.*>\) \(.*\)$/au='\''\1'\'' ad='\''\2'\''/p
+ s/^author \([^>]*>\)[\t ]*\(.*\)$/From: \1\nDate: \2/p
q
}'
process_one () {
+ sed -ne "$whosepatchScript" $commsg
mailScript='
/./d
/^$/n'
@@ -191,26 +184,7 @@ process_one () {
;;
esac
mailScript="$mailScript"'
- s|^|Subject: |'
- case "$mbox" in
- t)
- echo 'From nobody Mon Sep 17 00:00:00 2001' ;# UNIX "From" line
- ;;
- esac
-
- eval "$(sed -ne "$whosepatchScript" $commsg)"
- test "$author,$au" = ",$me" || {
- mailScript="$mailScript"'
- a\
-From: '"$au"
- }
- test "$date,$au" = ",$me" || {
- mailScript="$mailScript"'
- a\
-Date: '"$ad"
- }
-
- mailScript="$mailScript"'
+ s|^|Subject: |
a\
: body
@@ -218,7 +192,7 @@ Date: '"$ad"
n
b body'
- (cat $commsg ; echo; echo) |
+ (cat $commsg; echo; echo) |
sed -ne "$mailScript" |
git-stripspace
@@ -239,12 +213,7 @@ Date: '"$ad"
git-diff-tree -p $diff_opts "$commit"
echo "-- "
echo "@@GIT_VERSION@@"
-
- case "$mbox" in
- t)
- echo
- ;;
- esac
+ echo
}
total=`wc -l <$series | tr -dc "[0-9]"`
--
1.0.7-gb38d1
^ permalink raw reply related
* [ANNOUNCE] qgit-1.1rc1
From: Marco Costalba @ 2006-01-08 12:20 UTC (permalink / raw)
To: git
Hi everybody,
this should be qgit-1.0.1 but due to some new and quite intrusive
changes I chose for 1.1rc1 although the final 1.1 is still far away.
Important bugs, found after 1.0 was out, are the broken link navigation
in commit description window and the broken filter by SHA sub string
in main view.
Among new features added, to note is support for file content copy
with annotation line headers automatically removed and support for
toggling between to list all files or just interesting ones in merge
revisions, the pruning algorithm is the same of gitk with only
implementation differences, so the results should be the same.
There is also a 20% speed up in start-up times (tested on my box with
different clock settings) due to a new double buffering data loader.
What I consider the coolest feature, although not visible ;-) , is the
introduction of an extended exception system to resolve in a general,
and IMHO clean way, stability problems due to races.
See exception_manager.txt in base directory if interested.
Page with all the download links is, as usual,
http://digilander.libero.it/mcostalba/
You will found installation instructions and detailed change logs in
README and ChangeLog file respectively.
Marco
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
^ permalink raw reply
* Re: [PATCH 7/7] Add an optional limit to git-rebase
From: Yann Dirson @ 2006-01-08 10:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT list
In-Reply-To: <7vu0cf5uc5.fsf@assigned-by-dhcp.cox.net>
On Sat, Jan 07, 2006 at 06:25:46PM -0800, Junio C Hamano wrote:
> Patches 5, 6, and 7 in the series sound useful, but could they
> come with documentation updates please?
Right, that sounds reasonable :)
However, since my initial motivation was patch 7, and you correctly
pointed out that 5 and 6 are not needed for 7, I'm not sure what to do
about those 5 and 6. I'll have to let your comments about patch 6
settle in my mind first :)
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [PATCH 7/7] Add an optional limit to git-rebase
From: Yann Dirson @ 2006-01-08 10:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6db12z7.fsf@assigned-by-dhcp.cox.net>
On Sun, Jan 08, 2006 at 01:30:20AM -0800, Junio C Hamano wrote:
> Yann Dirson <ydirson@altern.org> writes:
>
> > This patch adds a limit to restrict the list of patches to rebase.
> >
> > This is useful when a set of patches were done against a given head,
> > but needs to be ported to a different head, as opposed to being ported
> > to a descendant of the original head. In such a case we only want to
> > port our own patches, not those that make the two branches different
> > upstream.
>
> This usage makes sense, independent from your git-format-patch
> "limit" patch. The patched argument to git-format-patch does
> not match your git-format-patch changes AFAICT ;-).
D'oh, I knew I should always written a testsuite when changing the
implementation of a feature at such a late time in night.
> > -git-format-patch -k --stdout --full-index "$other" ORIG_HEAD |
> > +git-format-patch -k --stdout --full-index "$other" ORIG_HEAD $limit |
>
> If all you want to do is to move the cut-off point more recent
> than the merge base is, how about (without your git-format-patch
> changes) doing something stupid like this instead?
>
> git-format-patch -k --stdout --full-index ${limit:-"$other"} ORIG_HEAD
Right, that would even be closer to the version that had indeed been
tested - it does have the advantage of passing t3401, though :)
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [PATCH 4/7] Add a test for rebase when a change was picked upstream
From: Yann Dirson @ 2006-01-08 10:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j9b7922.fsf@assigned-by-dhcp.cox.net>
On Sat, Jan 07, 2006 at 06:22:29PM -0800, Junio C Hamano wrote:
> Yann Dirson <ydirson@altern.org> writes:
>
> > +export GIT_AUTHOR_EMAIL=bogus_email_address
>
> This is probably not needed for this test, although it would not
> hurt.
Inheritance from t3400 :)
> > +test_expect_success \
> > + 'rebase topic branch against new master and check git-am did not get halted' \
> > + 'sh -x git-rebase master &&
> > + test ! -d .dotest
> > +'
>
> Some people build git with SHELL_PATH=/bin/bash because their
> /bin/sh is not POSIX enough (e.g. Solaris). Perhaps emulate
> what t5501 does?
Oh, that "sh -x" is only a forgotten debugging item, I'll drop it.
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [PATCH 1/7] Add a minimal test for git-cherry
From: Yann Dirson @ 2006-01-08 9:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy81r5ugx.fsf@assigned-by-dhcp.cox.net>
On Sat, Jan 07, 2006 at 06:22:54PM -0800, Junio C Hamano wrote:
> Yann Dirson <ydirson@altern.org> writes:
>
> > This test checks that git-cherry finds the expected number of patches
> > in two simple cases.
> >
> > Signed-off-by: Yann Dirson <ydirson@altern.org>
> >
> > +test_expect_success \
> > + 'cherry-pick one of the 2 patches, and check cherry recognized one and only one as new' \
> > + 'git-cherry-pick my-topic-branch^0 &&
> > + echo $(git-cherry master my-topic-branch) &&
> > + expr "$(echo $(git-cherry master my-topic-branch) )" : "+ [^ ]* - .*"
> > +'
>
> I wonder if "+ followed by -" order is stable here. If you make
> commits in the my-topic-branch fast enough, they would get the
> same timestamp and I suspect the order from rev-list would be
> left to chance.
We could maybe insert a sleep between the two commits ? Not that I
find it too appealing, however...
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [PATCH 7/7] Add an optional limit to git-rebase
From: Junio C Hamano @ 2006-01-08 9:30 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20060108004120.GO1113@nowhere.earth>
Yann Dirson <ydirson@altern.org> writes:
> This patch adds a limit to restrict the list of patches to rebase.
>
> This is useful when a set of patches were done against a given head,
> but needs to be ported to a different head, as opposed to being ported
> to a descendant of the original head. In such a case we only want to
> port our own patches, not those that make the two branches different
> upstream.
This usage makes sense, independent from your git-format-patch
"limit" patch. The patched argument to git-format-patch does
not match your git-format-patch changes AFAICT ;-).
> -git-format-patch -k --stdout --full-index "$other" ORIG_HEAD |
> +git-format-patch -k --stdout --full-index "$other" ORIG_HEAD $limit |
If all you want to do is to move the cut-off point more recent
than the merge base is, how about (without your git-format-patch
changes) doing something stupid like this instead?
git-format-patch -k --stdout --full-index ${limit:-"$other"} ORIG_HEAD
^ permalink raw reply
* Re: [PATCH 6/7] Add an optional limit to git-formatpatch
From: Junio C Hamano @ 2006-01-08 9:30 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20060108004059.GN1113@nowhere.earth>
Yann Dirson <ydirson@altern.org> writes:
> We may not want to format all patches since the merge base.
I am unsure about this one for a few reasons.
- If you have:
topic~3--topic~2--topic~1--topic
/
MB--*--*--*--upstream
and you do "not want to format all patches since the merge
base", instead of "format-patch --limit=topic~2 master topic",
you could just say "format-patch topic~2 topic", so this
feature seems unnecessary. Maybe I am not reading you right.
- Even if the idea of having limit makes sense, only one limit
can be specified, but you can have multiple (upstream,mine)
pairs. Your --limit applies the single limit to all of them.
I am not sure if that makes sense either.
I'd expect the limit value to be per (upstream,mine) pair,
making "# Now we have what we want in $@" for-loop to iterate
over (upstream,mine,limit) 3-tuples.
Internally an (upsteam,mine) pair is canonicalized to be a
single string "upstream..mine", so extending the canonical
syntax somehow, say, "upstream..mine..limit" where empty
"limit" means "use the merge base", might make sense. I
dunno.
- One thing that comes to mind is to deal with this structure:
topic~5--topic~4--topic~3--topic~2--topic~1--topic
/ /
Z--*--*--*--*--*--MB--*--*--*--upstream
and you do want to include commits older than topic~3 because
they have not been picked up by the upstream. In such a
scenario, specifying commit Z as the "limit" may make sense.
It is not "limit", but is what ASCII drawing in git-cherry
calls "fork-point". Is that what you are doing (the commit
log suggests otherwise and you want to get less than what
merge base gives you)?
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Junio C Hamano @ 2006-01-08 8:44 UTC (permalink / raw)
To: David S. Miller; +Cc: git
In-Reply-To: <20060108.001651.02992220.davem@davemloft.net>
"David S. Miller" <davem@davemloft.net> writes:
> I know a lot of people react to this kind of usage with "what's the
> point of the source control system if you're just messing with patches
> in and out of the tree all the time" But as a subsystem maintainer,
> you deal with a lot of changes and it's important to get a pristine
> clean history when you push things to Linus.
I suppose another possibility of rebasing the topic branches
every now and then amounts to almost the same thing; I think
your way is safer just in case something goes wrong. Maybe
Catalin can give us a short tutorial on StGIT here?
> #!/bin/sh
> (cd $1; git format-patch --mbox origin) || exit 1
> for i in $1/*.txt
> do
> sed 's/\[PATCH\] //' <$i >tmp.patch
> git-applymbox -k tmp.patch || exit 1
> done
With "git format-patch --mbox -k origin", you would not need the
sed command.
Or doing it inside a single repository:
#!/bin/sh
git branch -f anchor ;# mark the current head
git reset --hard linus ;# rewind to linus head
# extract them, and apply them -- I suspect origin and linus
# are the same
git format-patch --stdout -k origin anchor | git am -k -3
To check the results, since the patch you fed to "am" as a whole
should be fairly close to the difference between the linus head
and your resulting HEAD, parhaps:
git diff $(git merge-base origin anchor) anchor |
git apply --stat --summary >status.1
git diff linus HEAD | git apply --stat --summary >status.2
diff -u status.1 status.2
If you do not like the result, you can "git reset --hard anchor"
to come back to where you started.
* format-patch --stdout implies --mbox.
* -3 to "am" is optional and as a matter of taste. If you want
to resolve conflicts by hand to be sure, running "am" without
it may be preferable. Otherwise when a patch does not cleanly
apply it would construct an appropriate merge base tree on the
fly and runs a 3-way merge.
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: David S. Miller @ 2006-01-08 8:16 UTC (permalink / raw)
To: len.brown; +Cc: torvalds, linux-acpi, linux-kernel, akpm, git
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B3005A13489@hdsmsx401.amr.corp.intel.com>
From: "Brown, Len" <len.brown@intel.com>
Date: Sun, 8 Jan 2006 02:47:30 -0500
> I'm probably a naïve git user -- but I expect I have a lot of company.
> If there is a better way of using the tool to get the job done,
> I'm certainly a willing customer with open ears.
What I do is simply build a new fresh tree if I feel the urge
to sync with the top of Linus's tree. I use the script below
which I call "git suck". It just sucks the patches out of
one tree and sticks them into another tree. You go:
bash$ cd new-2.6
bash$ git suck ../foo-2.6
It preserves everything except the dates, and it's so incredibly
cheap and fast with GIT.
I know a lot of people react to this kind of usage with "what's the
point of the source control system if you're just messing with patches
in and out of the tree all the time" But as a subsystem maintainer,
you deal with a lot of changes and it's important to get a pristine
clean history when you push things to Linus.
In fact, I do this so much that Linus's tree HEAD often equals my
origin when he pulls.
Merges really suck and I also hate it when the tree gets cluttered
up with them, and Linus is right, ACPI is the worst offender here.
Yes, we can grep the merges out of the shortlog or whatever, but that
merging crap is still physically in the tree.
Just don't do it. Merge into a private branch for testing if you
don't want to rebuild trees like I do, but push the clean tree to
Linus.
#!/bin/sh
#
# Usage: git suck path-to-tree
#
# Pull all patches relative to 'origin' from the tree specified
# and apply them to the current directory tree, keeping all changelog
# and authorship information identical. It will update the dates
# of the changes of course.
(cd $1; git format-patch --mbox origin) || exit 1
for i in $1/*.txt
do
sed 's/\[PATCH\] //' <$i >tmp.patch
git-applymbox -k tmp.patch || exit 1
done
^ permalink raw reply
* RE: git pull on Linux/ACPI release tree
From: Brown, Len @ 2006-01-08 7:47 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, akpm-3NddpPZAyC0,
git-u79uwXL29TY76Z2rM5mHXA
Hi Linus,
adding git-u79uwXL29TaiAVqoAR/hOK1cXZ9k6wlg@public.gmane.org
>> please pull this batch of trivial patches from:
>>
>>
>git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release
>
>Len,
>
>I _really_ wish you wouldn't have those automatic merges.
>
>Why do you do them? They add nothing but ugly and unnecessary
>history, and in this pull, I think almost exactly half of the
>commits were just these empty merges.
Is it possible for it git, like bk, to simply ignore merge commits in its summary output?
Note that "Auto-update from upstream" is just the place-holder comment
embedded in the wrapper script in git/Documentation/howto/using-topic-branches.txt
All instances of it here are from me manually updating --
the only "auto" happening here is the automatic insertion of that comment:-)
I think that Tony's howto above captures two key requirements
from all kernel maintainers -- which the exception of you --
who hang out in the middle of the process rather than
at the top of the tree.
1. It is important that we be able (and encouraged, not discouraged)
to track the top of tree as closely as we have time to handle.
Divergence and conflicts are best handled as soon as they are noticed
and can be a huge pain if left to fester and discovered
only when it is time to push patches upstream.
Plus, tracking the top of tree means we force more folks to
track the top of tree, and so it gets more testing. This is goodness.
Earlier in your release cycle when changes are appearing faster,
my need/desire to sync is greater than later in the cycle when changes
are smaller and infrequent. On average, I think that one sync/day
from upstream is an entirely reasonable frequency.
2. It is also important that we be able to cherry pick individual patches
in our trees so that they don't block each other from going upstream.
Tony's using-topic-branches.txt above is the best way I know of doing that.
I think it is a big improvement over the bk model since I can have a simple
branch for each patch or group of patches rather than an entire repository
dedicatd to each. But for this to work, I need to be able to update
any and all of the topic branches from upstream, and to merge them with
each other -- just like I could with BK. Otherwise they become "dated"
in the time they were first integrated, and it is not convenient to do
simple apples/apples comparisons that are needed to debug and test.
I'm probably a naïve git user -- but I expect I have a lot of company.
If there is a better way of using the tool to get the job done,
I'm certainly a willing customer with open ears.
thanks,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Does git belong in root's $PATH?
From: H. Peter Anvin @ 2006-01-08 3:00 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dpppg4$qkd$1@sea.gmane.org>
walt wrote:
> H. Peter Anvin wrote:
>
>>/usr used to be what is now called /home. What you're describing above
>>is the current usage.
>
> History lessons are valuable for us youngsters ;o) Can you give us a
> brief description of what motivated such a change? (Just as important,
> of course, is whether the original motives have changed or disappeared.)
>
This is the history as far as I understand it. Keep in mind I was only
8 years old in 1980, and I think I first learned about how Unix worked
in 1985 or 1986, so not all of this is first-hand.
/usr was initially used for home directories (user directories.) Both
fore reasons as have been previously discussed (remember, most easy
multi-user systems were a lot friendlier than one would expect today),
and because the root disk often filled up, it became common for users to
put binaries in /usr/bin, and often the sysadmin, too.
As the need for system security tightened, by the 80's this was a pretty
unusable configuration. Since home directories were specified in
/etc/passwd, those could, and often were, located elsewhere -- much
easier than trying to change the now-established conventions of /usr/bin
et al. A lot of systems in the 80's were massively multiuser anyway
(workstations were coming in but were rare), and so you'd frequently see
paths like /u2/h/hpa for example (my actual home directory location on
our college server.)
The convention of using /home for home directories seems to have evolved
out of necessity when networking came in use on a large scale (NFS,
automounter, etc), probably in the late 80's-early 90's. By the time
Linux emerged in 1991 it was pretty well-established on smaller systems;
larger systems still tended to use local conventions inherited from
previous generation systems.
-hpa
^ permalink raw reply
* Re: [PATCH 7/7] Add an optional limit to git-rebase
From: Junio C Hamano @ 2006-01-08 2:25 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list
In-Reply-To: <20060108004120.GO1113@nowhere.earth>
Patches 5, 6, and 7 in the series sound useful, but could they
come with documentation updates please?
^ permalink raw reply
* Re: How do I apply a single "change"
From: Linus Torvalds @ 2006-01-08 2:24 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: ltuikov, Junio C Hamano, git
In-Reply-To: <43C06892.2030709@op5.se>
On Sun, 8 Jan 2006, Andreas Ericsson wrote:
>
> You can't. cherry-pick doesn't work on remote repos, so you need to pull that
> branch to a local one first.
"fetch", not "pull".
It's easy enough to get confused anyway, so we should be careful.
Linus
^ 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