* Re: Does git belong in root's $PATH?
From: Sam Ravnborg @ 2006-01-07 23:01 UTC (permalink / raw)
To: Linus Torvalds, linux-kernel, kbuild-devel; +Cc: walt, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601071023250.3169@g5.osdl.org>
On Sat, Jan 07, 2006 at 10:31:52AM -0800, Linus Torvalds wrote:
>
>
> On Sat, 7 Jan 2006, walt wrote:
> >
> > When updated my kernel this morning, the same way I've been doing
> > it for many months, I noticed that the -gxxxxxxx localversion
> > string was missing from the new kernel's name.
> >
> > I finally figured out that this happened because /usr/local/bin
> > is not in my root's $PATH, and the setlocalversion script depends
> > on git. (The only thing I do as root is 'make install').
>
> Ok, sounds like a build buglet to me. If you've done a "make" as a regular
> user, and just do a "make install" as root, I'd argue that the "make
> install" should do as little as humanly possible, and literally just
> install the kernel. If it starts changing the version, that sounds a bit
> fishy.
>
> Sam, anything we can do?
Today kbuild uses same method to build KERNELRELEASE no matter what
target is used, and I recently committed a change that used git tools as
replacement for direct manipulation with .git/*
What I did not realise was that we now require git during make install
time - which is obviously plain wrong.
I will try to look into a cleaner solution tomorrow where KERNELRELEASE
is fetched somewhere else during make install time.
>
> That said:
>
> > I suppose I'm asking a philosophical question here: do you
> > guys install git where root can find it (as a system tool)?
>
> I don't, but I don't use "make install" anyway, I just do "make
> modules_install". I install the kernel by hand, I always have.
>
> Of course, that's partly because I've always felt that "make install" does
> too much (I think "make modules_install" is better - it really only
> installs the already-built modules).
The big difference here is that "make modules_install" is part of
kbuild, whereas "make install" almost just call installkernel which is
distribution specific - and the distributions does all sort of stuff in
installkernel :-(
>
> Maybe it would be best to remove the "vmlinux" dependency from "make
> install" (so that "make install" will do exactly that: just install). I
> think all the documentation already tells you to do a "make" and then a
> "make install".
I had a short chat with David Miller about something similar.
What I really liked to do was to tell user if vmlinux needed an update.
But the implmentation of kbuild does make this almost impossible - I
have at least not seen how to do it.
When I during early 2.6.12 removed the dependency on vmlinux from
the install target people were complaining that there scripts broke and
the solution that was implmented was a new target:
"make kernel_install" and "make install" got back the vmlinux
dependency.
Only difference between the two are that "make kernel_install" does NOT
have vmlinux as prerequisite. This was btw only done for i386 and
the only other architecture that have kernel_install is parisc with a
vmlinux dependency.
So no, I'm very unlikely to remove the vmlinux dependency from the
"make install" target - it results in too many suprises.
>
> The other make targets really _are_ different: "make fdimage" depends on
> vmlinux, but that's because it literally just builds the image. "make
> install" is special.
>
> Sam, what say you? I forget what the kbuild mailing list is, but maybe
> you can forward this suggestion there..
These days it is named linux-kernel@vger.kernel.org ;-)
kbuild-devel@lists.sourceforge.net is seldom used though I still monitor
it. Talked with mec about discontinue it but he liked to keep it
araound. He is btw still moderator on that list filtering away all spam.
Sam
^ permalink raw reply
* [PATCH] tar-tree: finish honoring extractor's umask in git-tar-tree.
From: Junio C Hamano @ 2006-01-07 23:21 UTC (permalink / raw)
To: git
Earlier commit 38ec15a973a1f075f0d94d130b0ef279562921cd forgot
to apply the same principle of not forcing go-w to the base
directory when specified.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This will be in fixes branch to be slurped into both maint
and master. Please do not extract the kernel tarball as root
user, especially if you do not know how tar command works for
root user by default (hint: --no-same-permissions).
tar-tree.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
3ac0ebbba4d2d47ca2f4a674afead830f76ca256
diff --git a/tar-tree.c b/tar-tree.c
index 96bd143..f749d4b 100644
--- a/tar-tree.c
+++ b/tar-tree.c
@@ -433,7 +433,7 @@ int main(int argc, char **argv)
archive_time = time(NULL);
if (basedir)
write_header((unsigned char *)"0", TYPEFLAG_DIR, NULL, NULL,
- basedir, 040755, NULL, 0);
+ basedir, 040777, NULL, 0);
traverse_tree(buffer, size, NULL);
free(buffer);
write_trailer();
--
1.0.7-g0263
^ permalink raw reply related
* Re: [PATCH 2/3] ls-files --others --directory: give trailing slash
From: Linus Torvalds @ 2006-01-07 23:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Darrin Thompson
In-Reply-To: <7vy81racv7.fsf@assigned-by-dhcp.cox.net>
On Sat, 7 Jan 2006, Junio C Hamano wrote:
>
> * Likes, dislikes? This suits better for *my* purpose of
> calling this from git-status, but it might be undesirable for
> your Porcelain.
Likes.
However, I'd re-write it as just
memcpy(fullname + baselen + len, "/", 2);
len++;
if (show_other_directories &&
!dir_exists(fullname, baselen + len))
break;
read_directory(fullname, fullname, baselen + len);
because let's face it, every user wants the "+1", so just do it once
up-front instead of adding one in three different places.
Linus
^ permalink raw reply
* Re: [PATCH] git-mv.perl: use stderr for error output and cleanup
From: Andreas Ericsson @ 2006-01-08 0:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Randal L. Schwartz, Alex Riesen, git
In-Reply-To: <7v7j9bg369.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> BTW, I never understood the usefulness of Statement Modifiers.
> Even reading the examples in perlsyn.pod:
>
> print "Basset hounds got long ears" if length $ear >= 10;
> go_outside() and play() unless $is_raining;
>
> seeing "do these things" upfront and then realize "ah, but that
> is done only when this holds true", interrupts the flow of
> understanding while reading a program by somebody else [*1*].
Here's what "Programming Perl" by O'Reilly (third edition, somewhere
around page 604) has to say about it:
---%<---%<---%<---
*) Do things the most readable way. For instance:
open(FOO, $foo) or die "Can't open $foo: $!";
is better than
die "Can't open $foo: $!" unless open(FOO, $foo);
because the second way hides the main point of the statement in a modifier.
---%<---%<---%<---
Considering the book was co-authored by Larry Wall, I'd say that's as
good as an apology.
> It is worse if the Statement Modifier is a loop control.
>
> (flamebait) Compound Statements take BLOCK and people who want
> to do a one-liner could not do so without braces. I've always
> thought Statement Modifies as a lame workaround for that
> problem.
>
Most things can be done without braces, so long as one doesn't spell out
the 'if'.
$opt_h and usage();
-d $directory or mkdir($directory);
is perfectly valid perl. This way of writing it is familiar enough for
shell-scripters. Hardcore C-programmers will look twice when they see a
line that so obviously looks completely wrong and will almost certainly,
with some revulsion, understand it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* How do I apply a single "change"
From: Luben Tuikov @ 2006-01-08 0:31 UTC (permalink / raw)
To: git
Forgive me for the _incredibly stupid questions_,
but how do I apply a single "change", identified
by its SHA? Either from one branch to the other or
remote?
I.e. I want to "integrate" only that change?
Alternatively, how do I apply the absolute output of
"git-format-patch". I tried but whatever I tried with
complained that it couldn't find any email addressess.
(roll eyes here)
Thanks for the help,
Luben
^ permalink raw reply
* [PATCH 1/7] Add a minimal test for git-cherry
From: Yann Dirson @ 2006-01-08 0:38 UTC (permalink / raw)
To: GIT list
This test checks that git-cherry finds the expected number of patches
in two simple cases.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
t/t3500-cherry.sh | 47 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 47 insertions(+), 0 deletions(-)
create mode 100755 t/t3500-cherry.sh
e9d999acb2653af449e3122872cbd4e8f8260c71
diff --git a/t/t3500-cherry.sh b/t/t3500-cherry.sh
new file mode 100755
index 0000000..f2f9109
--- /dev/null
+++ b/t/t3500-cherry.sh
@@ -0,0 +1,47 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Yann Dirson, based on t3400 by Amos Waterland
+#
+
+test_description='git-cherry should detect patches integrated upstream
+
+This test cherry-picks one local change of two into master branch, and
+checks that git-cherry only returns the second patch in the local branch
+'
+. ./test-lib.sh
+
+export GIT_AUTHOR_EMAIL=bogus_email_address
+
+test_expect_success \
+ 'prepare repository with topic branch, and check cherry finds the 2 patches from there' \
+ 'echo First > A &&
+ git-update-index --add A &&
+ git-commit -m "Add A." &&
+
+ git-checkout -b my-topic-branch &&
+
+ echo Second > B &&
+ git-update-index --add B &&
+ git-commit -m "Add B." &&
+
+ echo AnotherSecond > C &&
+ git-update-index --add C &&
+ git-commit -m "Add C." &&
+
+ git-checkout -f master &&
+
+ echo Third >> A &&
+ git-update-index A &&
+ git-commit -m "Modify A." &&
+
+ expr "$(echo $(git-cherry master my-topic-branch) )" : "+ [^ ]* + .*"
+'
+
+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) )" : "+ [^ ]* - .*"
+'
+
+test_done
--
1.0.6-g8ecb
--
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 related
* [PATCH 2/7] Fix typo in debug stanza of t2001
From: Yann Dirson @ 2006-01-08 0:38 UTC (permalink / raw)
To: GIT list
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
t/t2001-checkout-cache-clash.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
392df5563e13d8156f99cdabb29aaa579629cbd5
diff --git a/t/t2001-checkout-cache-clash.sh b/t/t2001-checkout-cache-clash.sh
index b1c5263..0dcab8f 100755
--- a/t/t2001-checkout-cache-clash.sh
+++ b/t/t2001-checkout-cache-clash.sh
@@ -74,7 +74,7 @@ test_debug 'show_files $tree3'
test_expect_success \
'read previously written tree and checkout.' \
'git-read-tree $tree2 && git-checkout-index -f -a'
-test_debug show_files $tree2
+test_debug 'show_files $tree2'
test_expect_success \
'checking out conflicting path with -f' \
--
1.0.6-g8ecb
--
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 related
* [PATCH 3/7] Fix git-formatpatch usage string wrt output modes
From: Yann Dirson @ 2006-01-08 0:39 UTC (permalink / raw)
To: GIT list
--stdout was not mentionned, and the description for the case where -o
was not given was thus incomplete.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
git-format-patch.sh | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
8a6d4a039ff4ffd75d5eeddbd6801787a8479b05
diff --git a/git-format-patch.sh b/git-format-patch.sh
index daa3cae..0948f1f 100755
--- a/git-format-patch.sh
+++ b/git-format-patch.sh
@@ -9,8 +9,10 @@ one file per patch, for e-mail submissio
numbered sequentially from 1, and uses the first line of the commit
message (massaged for pathname safety) as the filename.
-When -o is specified, output files are created in that directory; otherwise in
-the current working directory.
+There are three output modes. By default, output files are created in
+the current working directory; when -o is specified, they are created
+in that directory instead; when --stdout is specified, they are spit
+on standard output, and can be piped to git-am.
When -n is specified, instead of "[PATCH] Subject", the first line is formatted
as "[PATCH N/M] Subject", unless you have only one patch.
--
1.0.6-g8ecb
--
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 related
* [PATCH 4/7] Add a test for rebase when a change was picked upstream
From: Yann Dirson @ 2006-01-08 0:39 UTC (permalink / raw)
To: GIT list
This test exercises the standard feature that makes rebase useful.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
t/t3401-rebase-partial.sh | 57 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 57 insertions(+), 0 deletions(-)
create mode 100755 t/t3401-rebase-partial.sh
90bb1e981d99331bdc39acb2ab97ed0c88b06630
diff --git a/t/t3401-rebase-partial.sh b/t/t3401-rebase-partial.sh
new file mode 100755
index 0000000..7c2d7f9
--- /dev/null
+++ b/t/t3401-rebase-partial.sh
@@ -0,0 +1,57 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Yann Dirson, based on t3400 by Amos Waterland
+#
+
+test_description='git rebase should detect patches integrated upstream
+
+This test cherry-picks one local change of two into master branch, and
+checks that git rebase succeeds with only the second patch in the
+local branch.
+'
+. ./test-lib.sh
+
+export GIT_AUTHOR_EMAIL=bogus_email_address
+
+test_expect_success \
+ 'prepare repository with topic branch' \
+ 'echo First > A &&
+ git-update-index --add A &&
+ git-commit -m "Add A." &&
+
+ git-checkout -b my-topic-branch &&
+
+ echo Second > B &&
+ git-update-index --add B &&
+ git-commit -m "Add B." &&
+
+ echo AnotherSecond > C &&
+ git-update-index --add C &&
+ git-commit -m "Add C." &&
+
+ git-checkout -f master &&
+
+ echo Third >> A &&
+ git-update-index A &&
+ git-commit -m "Modify A."
+'
+
+test_expect_success \
+ 'pick top patch from topic branch into master' \
+ 'git-cherry-pick my-topic-branch^0 &&
+ git-checkout -f my-topic-branch
+'
+
+test_debug \
+ 'git-cherry master &&
+ git-format-patch -k --stdout --full-index master >/dev/null &&
+ gitk --all & sleep 1
+'
+
+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
+'
+
+test_done
--
1.0.6-g8ecb
--
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 related
* Re: Does git belong in root's $PATH?
From: Andreas Ericsson @ 2006-01-08 0:37 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: walt, git
In-Reply-To: <43C02725.2020702@zytor.com>
H. Peter Anvin wrote:
> Andreas Ericsson wrote:
>
>>
>> Not including /usr/local/{bin,sbin} in root's path is considered wise,
>> since, historically, that's where users would install their own
>> versions of programs that the system doesn't provide. This use has
>> largely been obsoleted by $HOME/bin as the default for user-specific
>> programs, mainly because of disks getting larger and cheaper.
>>
>
> Hmmm... I think that was /usr/bin (hence the eventual migration of the
> meaning of /usr from what was originally the equivalent of /home.)
>
I've been told that it's '/usr' simply because that's where user
interface tools that have nothing to do with boot-strapping resides. A
point emphasized by the fact that /bin, /sbin and /lib must not reside
on network-mounted media, while /usr may.
It seems so logical I never bothered to look in to find out for myself
though, so I may well be wrong, or at least younger. ;)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH 5/7] Add an optional limit to git-cherry
From: Yann Dirson @ 2006-01-08 0:40 UTC (permalink / raw)
To: GIT list
This allows to use another commit than the merge base as a limit for
scanning patches.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
git-cherry.sh | 20 +++++++++++++-------
t/t3500-cherry.sh | 5 +++++
2 files changed, 18 insertions(+), 7 deletions(-)
b1e23bf60c069a1f6bd4b8d04afd1fb80005e4ee
diff --git a/git-cherry.sh b/git-cherry.sh
index 5e9bd0c..1a62320 100755
--- a/git-cherry.sh
+++ b/git-cherry.sh
@@ -3,17 +3,17 @@
# Copyright (c) 2005 Junio C Hamano.
#
-USAGE='[-v] <upstream> [<head>]'
+USAGE='[-v] <upstream> [<head>] [<limit>]'
LONG_USAGE=' __*__*__*__*__> <upstream>
/
fork-point
\__+__+__+__+__+__+__+__> <head>
-Each commit between the fork-point and <head> is examined, and
-compared against the change each commit between the fork-point and
-<upstream> introduces. If the change seems to be in the upstream,
-it is shown on the standard output with prefix "+". Otherwise
-it is shown with prefix "-".'
+Each commit between the fork-point (or <limit> if given) and <head> is
+examined, and compared against the change each commit between the
+fork-point and <upstream> introduces. If the change seems to be in
+the upstream, it is shown on the standard output with prefix "+".
+Otherwise it is shown with prefix "-".'
. git-sh-setup
case "$1" in -v) verbose=t; shift ;; esac
@@ -28,9 +28,15 @@ esac
case "$#" in
1) upstream=`git-rev-parse --verify "$1"` &&
ours=`git-rev-parse --verify HEAD` || exit
+ limit="$upstream"
;;
2) upstream=`git-rev-parse --verify "$1"` &&
ours=`git-rev-parse --verify "$2"` || exit
+ limit="$upstream"
+ ;;
+3) upstream=`git-rev-parse --verify "$1"` &&
+ ours=`git-rev-parse --verify "$2"` &&
+ limit=`git-rev-parse --verify "$3"` || exit
;;
*) usage ;;
esac
@@ -38,7 +44,7 @@ esac
# Note that these list commits in reverse order;
# not that the order in inup matters...
inup=`git-rev-list ^$ours $upstream` &&
-ours=`git-rev-list $ours ^$upstream` || exit
+ours=`git-rev-list $ours ^$limit` || exit
tmp=.cherry-tmp$$
patch=$tmp-patch
diff --git a/t/t3500-cherry.sh b/t/t3500-cherry.sh
index f2f9109..7b81377 100755
--- a/t/t3500-cherry.sh
+++ b/t/t3500-cherry.sh
@@ -38,6 +38,11 @@ test_expect_success \
'
test_expect_success \
+ 'check that cherry with limit returns only the top patch'\
+ 'expr "$(echo $(git-cherry master my-topic-branch my-topic-branch^1) )" : "+ [^ ]*"
+'
+
+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) &&
--
1.0.6-g8ecb
--
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 related
* Re: How do I apply a single "change"
From: Junio C Hamano @ 2006-01-08 0:38 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20060108003114.4679.qmail@web31812.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> ... how do I apply a single "change", identified
> by its SHA? Either from one branch to the other or
> remote?
>
> I.e. I want to "integrate" only that change?
$ git-cherry-pick $object_name
> Alternatively, how do I apply the absolute output of
> "git-format-patch". I tried but whatever I tried with
> complained that it couldn't find any email addressess.
> (roll eyes here)
It is unclear what you mean by absolute output, but here is what
I regularly do:
$ git-format-patch -k -m --stdout from to | git am -3 -k
^ permalink raw reply
* [PATCH 6/7] Add an optional limit to git-formatpatch
From: Yann Dirson @ 2006-01-08 0:40 UTC (permalink / raw)
To: GIT list
We may not want to format all patches since the merge base.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
git-format-patch.sh | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
a0f52fc065de2bdca4f8e598d4a8a743d183d4d9
diff --git a/git-format-patch.sh b/git-format-patch.sh
index 0948f1f..6a0d331 100755
--- a/git-format-patch.sh
+++ b/git-format-patch.sh
@@ -30,6 +30,7 @@ diff_opts=
LF='
'
+limit=
outdir=./
while case "$#" in 0) break;; esac
do
@@ -45,6 +46,11 @@ do
-k|--k|--ke|--kee|--keep|--keep-|--keep-s|--keep-su|--keep-sub|\
--keep-subj|--keep-subje|--keep-subjec|--keep-subject)
keep_subject=t ;;
+ -l=|--l=|--li=|--lim=|--limi=|--limit=)
+ limit=`expr "$1" : '-[^=]*=\(.*\)'` ;;
+ -l|--l|--li|--lim|--limi|--limit)
+ case "$#" in 1) usage ;; esac; shift
+ limit="$1" ;;
-n|--n|--nu|--num|--numb|--numbe|--number|--numbere|--numbered)
numbered=t ;;
-s|--s|--si|--sig|--sign|--signo|--signof|--signoff)
@@ -136,7 +142,7 @@ do
die "Not a valid rev $rev1 ($revpair)"
git-rev-parse --verify "$rev2^0" >/dev/null 2>&1 ||
die "Not a valid rev $rev2 ($revpair)"
- git-cherry -v "$rev1" "$rev2" |
+ git-cherry -v "$rev1" "$rev2" $limit |
while read sign rev comment
do
case "$sign" in
--
1.0.6-g8ecb
--
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 related
* [PATCH 7/7] Add an optional limit to git-rebase
From: Yann Dirson @ 2006-01-08 0:41 UTC (permalink / raw)
To: GIT list
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.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
git-rebase.sh | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
bf833136c7c4cc17e7e45b959b56cda11528c33a
diff --git a/git-rebase.sh b/git-rebase.sh
index 16d4359..06c7e1a 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -3,10 +3,10 @@
# Copyright (c) 2005 Junio C Hamano.
#
-USAGE='<upstream> [<head>]'
+USAGE='<upstream> [<head>] [<limit>]'
. git-sh-setup
-case $# in 1|2) ;; *) usage ;; esac
+case $# in 1|2|3) ;; *) usage ;; esac
# Make sure we do not have .dotest
if mkdir .dotest
@@ -36,6 +36,14 @@ other=$(git-rev-parse --verify "$1^0") |
# Make sure the branch to rebase is valid.
head=$(git-rev-parse --verify "${2-HEAD}^0") || exit
+# Set limit
+case "$#" in
+3)
+ limit=$(git-rev-parse --verify "$3^0") || usage ;;
+*)
+ limit= ;;
+esac
+
# If the branch to rebase is given, first switch to it.
case "$#" in
2)
@@ -62,5 +70,5 @@ then
exit 0
fi
-git-format-patch -k --stdout --full-index "$other" ORIG_HEAD |
+git-format-patch -k --stdout --full-index "$other" ORIG_HEAD $limit |
git am --binary -3 -k
--
1.0.6-g8ecb
--
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 related
* Re: Does git belong in root's $PATH?
From: H. Peter Anvin @ 2006-01-08 0:39 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: walt, git
In-Reply-To: <43C05ED5.1090603@op5.se>
Andreas Ericsson wrote:
>
> I've been told that it's '/usr' simply because that's where user
> interface tools that have nothing to do with boot-strapping resides. A
> point emphasized by the fact that /bin, /sbin and /lib must not reside
> on network-mounted media, while /usr may.
>
> It seems so logical I never bothered to look in to find out for myself
> though, so I may well be wrong, or at least younger. ;)
>
/usr used to be what is now called /home. What you're describing above
is the current usage.
-hpa
^ permalink raw reply
* Re: How do I apply a single "change"
From: Luben Tuikov @ 2006-01-08 0:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j9b8sgf.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > ... how do I apply a single "change", identified
> > by its SHA? Either from one branch to the other or
> > remote?
> >
> > I.e. I want to "integrate" only that change?
>
> $ git-cherry-pick $object_name
Ok, so git searches the db (other branches, etc) and
does the job. This worked for me.
How will I do this same thing but if the "change" is
on a remote repository?
> > Alternatively, how do I apply the absolute output of
> > "git-format-patch". I tried but whatever I tried with
> > complained that it couldn't find any email addressess.
> > (roll eyes here)
>
> It is unclear what you mean by absolute output, but here is what
> I regularly do:
>
> $ git-format-patch -k -m --stdout from to | git am -3 -k
I did
$ git-format-patch commit^ commit
and the usual 0001-blah-blah file got created. Then
I tried to apply it, but whatever I tried it complained.
Will "git-am -3 -k" work without complaining there is
no "email field" or something? (I cannot try it as
git-cherry-pick worked for me already.)
Thanks,
Lunen
^ permalink raw reply
* Re: How do I apply a single "change"
From: Andreas Ericsson @ 2006-01-08 1:19 UTC (permalink / raw)
To: ltuikov; +Cc: Junio C Hamano, git
In-Reply-To: <20060108005152.46315.qmail@web31813.mail.mud.yahoo.com>
Luben Tuikov wrote:
> --- Junio C Hamano <junkio@cox.net> wrote:
>>
>>$ git-cherry-pick $object_name
>
>
> Ok, so git searches the db (other branches, etc) and
> does the job. This worked for me.
>
> How will I do this same thing but if the "change" is
> on a remote repository?
>
You can't. cherry-pick doesn't work on remote repos, so you need to pull
that branch to a local one first.
>
>>>Alternatively, how do I apply the absolute output of
>>>"git-format-patch". I tried but whatever I tried with
>>>complained that it couldn't find any email addressess.
>>>(roll eyes here)
>>
>>It is unclear what you mean by absolute output, but here is what
>>I regularly do:
>>
>>$ git-format-patch -k -m --stdout from to | git am -3 -k
>
>
> I did
> $ git-format-patch commit^ commit
>
> and the usual 0001-blah-blah file got created. Then
> I tried to apply it, but whatever I tried it complained.
> Will "git-am -3 -k" work without complaining there is
> no "email field" or something? (I cannot try it as
> git-cherry-pick worked for me already.)
>
You need to specify the '--mbox' (or '-m') for git-format-patch,
otherwise it can't find author-info in the generated patch and it won't
know who committed what.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Does git belong in root's $PATH?
From: walt @ 2006-01-08 1:22 UTC (permalink / raw)
To: git
In-Reply-To: <43C05F4C.8050908@zytor.com>
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.)
Thanks!
^ permalink raw reply
* Re: [PATCH] Stgit - gitmergeonefile.py: handle removal vs. changes
From: Chuck Lever @ 2006-01-08 1:50 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Blaisorblade, git
In-Reply-To: <43BFA499.3020202@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 549 bytes --]
Catalin Marinas wrote:
>>Also, another note: I just found Bruce Eckel mentioning pychecker, which is a
>>static code checker for Python (to perform the checks a compiler would
>>normally do). I've not the time to investigate more myself, but I hope it can
>>be useful to you.
>>
>>
>
> Thanks. I'll give it a try.
i already ran pychecker against everything but gitmergeonefile.py... it
found a few things that you have already integrated (like that weird
behavior around using empty lists as the default value for function
arguments). fyi...
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 466 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Open Source NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763-4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668-1089
x-mozilla-html:FALSE
url:http://troy.citi.umich.edu/u/cel/
version:2.1
end:vcard
^ permalink raw reply
* Re: [PATCH 4/7] Add a test for rebase when a change was picked upstream
From: Junio C Hamano @ 2006-01-08 2:22 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20060108003948.GL1113@nowhere.earth>
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.
> +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?
^ permalink raw reply
* Re: [PATCH 1/7] Add a minimal test for git-cherry
From: Junio C Hamano @ 2006-01-08 2:22 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20060108003815.GI1113@nowhere.earth>
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.
^ 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
* 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: 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: 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
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