* Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?
From: Matt McCutchen @ 2006-03-30 21:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603300919280.27203@g5.osdl.org>
On Thu, 2006-03-30 at 09:32 -0800, Linus Torvalds wrote:
> The beauty of git should be (and maybe that's not entirely true simply
> because of practical concerns) that there really need not be any notion of
> "more official".
I understand this, and it is one of several reasons why I prefer git to
other version control systems. However, I thought there would be a
single official kernel repository even if git didn't require it. Junio
explained to me that both yours and the stable one are official for
different purposes. I think I will use the stable one because it is
current enough for my needs.
> - the more fundamental one is that when you start mixing branches, you
> have to be very careful if you expect the upstream projects to pull the
> changes _back_. [...]
True. It might help several branches coordinate development if a commit
could be marked as "equivalent" to another commit so that, if both were
involved in a merge, one could be thrown out.
--
Matt McCutchen
hashproduct@verizon.net
http://hashproduct.metaesthetics.net/
^ permalink raw reply
* Re: Gitk strangeness..
From: Alex Riesen @ 2006-03-30 20:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <17449.48630.370867.10251@cargo.ozlabs.ibm.com>
Paul Mackerras, Wed, Mar 29, 2006 00:51:34 +0200:
> Junio C Hamano writes:
>
> > How about this alternative patch, then? It turned out to be
> > quite convoluted as I feared.
>
> That's brilliant. Thank you! With the patch to gitk below, the
> graph display on Linus' example looks much saner.
>
Well... Could you take a look at these screenshots, please?
http://home.arcor.de/fork0/bug/gitk1.jpg (this one is BIG, 400k, 2456x949)
http://home.arcor.de/fork0/bug/gitk2.jpg
http://home.arcor.de/fork0/bug/gitk3.jpg
The compressed repository is being uploaded there:
http://home.arcor.de/fork0/bug/ggg.tar.bz2 (~6Mb)
The old gitk produced a denser graph, which wasn't perfect too, but
had a higher count of visible commit titles (and this is two-monitor
setup, too).
^ permalink raw reply
* Re: Possible --boundary bug
From: Marco Costalba @ 2006-03-30 20:55 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <e5bfff550603301034r58b38500ie5897ed06fce6e9a@mail.gmail.com>
Sorry, the good description is below, please ignore the wrong previous one.
On 3/30/06, Marco Costalba <mcostalba@gmail.com> wrote:
> Trying to convert qgit to use the new and cool --boundary option I
> found this one:
>
> From git tree
>
> $ git-rev-list --boundary --topo-order --parents 5aa44d5..ab57c8d |
> grep eb38cc689e8
> -e646de0d14bac20ef6e156c1742b9e62fb0b9020
> eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4
> 4b953cdc04fec8783e2c654a671005492fda9b01
> 5ca5396c9ecba947c8faac7673195d309a6ba2ea
> eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4
>
> and also
>
> $ git-rev-list --boundary --topo-order --parents 5aa44d5..ab57c8d |
> grep c64965750
> 8c0db2f5193153ea8a51bb45b0512c5a3889023b
> 21a02335f821c89a989cf0b533d2ae0adb6da16e
> c649657501bada28794a30102d9c13cc28ca0e5e
>
It seems the lines:
-c649657501bada28794a30102d9c13cc28ca0e5e .......
and
-eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4 ......
are missing though the two revs are boundary revs.
Marco
P.S: Sorry for lengthy output but --abbrev option:
git-rev-list --boundary --topo-order --abbrev=8 --parents 5aa44d5..ab57c8d
does seems to work only for prettyprinted parent names, I guess this
from patches log messages because is not documented.
^ permalink raw reply
* Re: [PATCH] gitk: Use git wrapper to run git-ls-remote.
From: Christopher Faylor @ 2006-03-30 20:13 UTC (permalink / raw)
To: Junio C Hamano, Mark Wooding, git
In-Reply-To: <7v8xqr3iwt.fsf@assigned-by-dhcp.cox.net>
On Thu, Mar 30, 2006 at 10:08:02AM -0800, Junio C Hamano wrote:
>Mark Wooding <mdw@distorted.org.uk> writes:
>
>> From: Mark Wooding <mdw@distorted.org.uk>
>>
>> For some reason, the Cygwin Tcl's `exec' command has trouble running
>> scripts...
>
>Yup, I've seen this and have a "personal edition" workaround
>exactly like yours. I haven't bothered to put it in even "pu",
>because I am reluctant to add an workaround to a problem I do
>not understand (and I haven't bothered to try understanding the
>problem which happens only on Windows ;-).
>
>Does anybody know what is going on?
Currently, Cygwin's tcl is a pure windows version which uses
CreateProcess to run stuff. It doesn't know about scripts and possibly
doesn't even know about cygwin paths.
cgf
^ permalink raw reply
* Possible --boundary bug
From: Marco Costalba @ 2006-03-30 18:34 UTC (permalink / raw)
To: junkio; +Cc: git
Trying to convert qgit to use the new and cool --boundary option I
found this one:
>From git tree
$ git-rev-list --boundary --topo-order --parents 5aa44d5..ab57c8d |
grep eb38cc689e8
-e646de0d14bac20ef6e156c1742b9e62fb0b9020
eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4
4b953cdc04fec8783e2c654a671005492fda9b01
5ca5396c9ecba947c8faac7673195d309a6ba2ea
eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4
and also
$ git-rev-list --boundary --topo-order --parents 5aa44d5..ab57c8d |
grep c64965750
8c0db2f5193153ea8a51bb45b0512c5a3889023b
21a02335f821c89a989cf0b533d2ae0adb6da16e
c649657501bada28794a30102d9c13cc28ca0e5e
But perhaps correct output should be:
$ git-rev-list --boundary --topo-order --parents 5aa44d5..ab57c8d |
grep eb38cc689e8
-e646de0d14bac20ef6e156c1742b9e62fb0b9020
eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4
-4b953cdc04fec8783e2c654a671005492fda9b01
5ca5396c9ecba947c8faac7673195d309a6ba2ea
eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4
and
$ git-rev-list --boundary --topo-order --parents 5aa44d5..ab57c8d |
grep c64965750
-8c0db2f5193153ea8a51bb45b0512c5a3889023b
21a02335f821c89a989cf0b533d2ae0adb6da16e
c649657501bada28794a30102d9c13cc28ca0e5e
It seems the '-' flag is mistakenly missing because of boundary revs:
c649657501bada28794a30102d9c13cc28ca0e5e and
eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4
Marco
^ permalink raw reply
* Re: [PATCH] gitk: Use git wrapper to run git-ls-remote.
From: Mark Wooding @ 2006-03-30 18:26 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xqr3iwt.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Does anybody know what is going on?
I'll try staring at the Tcl source code some time. I'm rather too busy
tonight, though.
There's also some very strange geometry management oddness going on in
gitk. I'll try to sort that out too.
-- [mdw]
^ permalink raw reply
* Re: [PATCH] gitk: Use git wrapper to run git-ls-remote.
From: Junio C Hamano @ 2006-03-30 18:08 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <20060330123151.25779.73775.stgit@metalzone.distorted.org.uk>
Mark Wooding <mdw@distorted.org.uk> writes:
> From: Mark Wooding <mdw@distorted.org.uk>
>
> For some reason, the Cygwin Tcl's `exec' command has trouble running
> scripts...
Yup, I've seen this and have a "personal edition" workaround
exactly like yours. I haven't bothered to put it in even "pu",
because I am reluctant to add an workaround to a problem I do
not understand (and I haven't bothered to try understanding the
problem which happens only on Windows ;-).
Does anybody know what is going on?
^ permalink raw reply
* Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?
From: Linus Torvalds @ 2006-03-30 17:32 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <1143687710.2524.1.camel@mattlaptop.metaesthetics.net>
On Wed, 29 Mar 2006, Matt McCutchen wrote:
>
> Perhaps this is just politics, but which kernel repository is more
> official, and why? Linus's or the one I have been using,
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
> ?
The beauty of git should be (and maybe that's not entirely true simply
because of practical concerns) that there really need not be any notion of
"more official".
You can fetch multiple different git trees from different sources into the
same git tree, and then keep them _all_ around equally as different
branches. You can move fixes between the different branches with "git
cherry-pick", and you can merge different branches with "git merge"
Now, the reason I say "_should_ be" rather than "is" is two-fold:
- right now, a lot of the infrastructure is simply set up more towards
the "one single source repository" model. When you do a "git clone", it
kind of makes the origin special. That's how all the documentation is
written, and that's also the only remote branch that git creates
_automatically_ for you.
This really isn't a technical issue: the git code code doesn't care
about any special "original" repository. But the fact that you have to
create the ".git/remotes/linus" file by hand, and that all the examples
in the docs end up talking about a single "origin" branch means that
people _think_ of git as a "single origin" thing.
- the more fundamental one is that when you start mixing branches, you
have to be very careful if you expect the upstream projects to pull the
changes _back_. In particular, that's where you have to think twice (or
three times) about doing a "git merge" (or a "git pull", which
implicitly merges for you if it's not a pure fast-forward).
In particular, the fact that _you_ want to merge two trees that came
from different sources does _not_ imply that either of the two sources
might want to merge with each other. So if you merge the two together,
you may find it impossible to have either of them then pull from you:
they way want your changes, but they might not like the merge you did,
because they have different policies about that work than you did.
So while the first point is purely a "mental model" issue and about lack
of helper scripts, the second point is fundamental.
For example, in your case it was almost certainly the right thing to do to
cherry-pick your changes from the 2.6.15.6 branch onto the development
branch, because I simply don't want to merge the 2.6.15.6 stuff into the
standard tree: part of the _rules_ for the stable branch is that the
things it fixes should have been fixed in the development tree already, so
merging the stable tree should always be unnecessary (and often clash,
although _hopefully_ in many cases the fixes in the stable tree are 1:1
identical and will merge beautifully).
Anyway: from a technical standpoint, no tree should be "special" or "more
official" for git usage. But when merging data back to any of those trees
that aren't special, the source/history of the data is important to keep
in mind. Branch "a" may not be any more special than branch "b", but when
you push changes back to the source of branch "a", the history of those
changes (relative to what the source was) is meaningful.
Linus
^ permalink raw reply
* [PATCH] git-clone: exit early if repo isn't specified
From: Yasushi SHOJI @ 2006-03-30 17:01 UTC (permalink / raw)
To: git
Subject: [PATCH] git-clone: exit early if repo isn't specified
git-clone without a repo isn't useful at all. print message and get
out asap.
This patch also move the variable 'local' to where other variables are
initialized.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
---
git-clone.sh | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
a222289a855194280aade24baa005de9e55667d0
diff --git a/git-clone.sh b/git-clone.sh
index a731d15..7b05fd9 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -98,6 +98,7 @@ close FH;
'
quiet=
+local=no
use_local=no
local_shared=no
no_checkout=
@@ -155,6 +156,13 @@ do
shift
done
+repo="$1"
+if test -z "$repo"
+then
+ echo >&2 'you must specify a repository to clone.'
+ exit 1
+fi
+
# --bare implies --no-checkout
if test yes = "$bare"
then
@@ -178,8 +186,6 @@ fi
# Turn the source into an absolute path if
# it is local
-repo="$1"
-local=no
if base=$(get_repo_base "$repo"); then
repo="$base"
local=yes
--
1.3.0.rc1.gb8abc
^ permalink raw reply related
* [PATCH] Make git-clone to take long double-dashed origin option (--origin)
From: Yasushi SHOJI @ 2006-03-30 17:00 UTC (permalink / raw)
To: git
Subject: [PATCH] Make git-clone to take long double-dashed origin option (--origin)
git-clone currently take option '-o' to specify origin. this patch
makes git-clone to take double-dashed option '--origin' and other
abbreviations in addtion to the current single-dashed option.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
---
git-clone.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
6585a854a571f3978652c06cc746b3d9e501359d
diff --git a/git-clone.sh b/git-clone.sh
index 6887321..a731d15 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -9,7 +9,7 @@ # See git-sh-setup why.
unset CDPATH
usage() {
- echo >&2 "Usage: $0 [--use-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]"
+ echo >&2 "Usage: $0 [--use-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]"
exit 1
}
@@ -127,7 +127,7 @@ while
shift; reference="$1" ;;
*,--reference=*)
reference=`expr "$1" : '--reference=\(.*\)'` ;;
- *,-o)
+ *,-o|*,--or|*,--ori|*,--orig|*,--origi|*,--origin)
case "$2" in
*/*)
echo >&2 "'$2' is not suitable for an origin name"
@@ -138,7 +138,7 @@ while
exit 1
}
test -z "$origin_override" || {
- echo >&2 "Do not give more than one -o options."
+ echo >&2 "Do not give more than one --origin options."
exit 1
}
origin_override=yes
@@ -160,7 +160,7 @@ if test yes = "$bare"
then
if test yes = "$origin_override"
then
- echo >&2 '--bare and -o $origin options are incompatible.'
+ echo >&2 '--bare and --origin $origin options are incompatible.'
exit 1
fi
if test t = "$use_separate_remote"
--
1.3.0.rc1.gb8abc
^ permalink raw reply related
* head_points_at checked in as 47874d6
From: Yasushi SHOJI @ 2006-03-30 15:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi Junio,
Would you kindly explain what you are intended to do with the
following code checked in as 47874d6d9a7f49ade6388df049597f03365961ca ?
# The name under $remote_top the remote HEAD seems to point at
head_points_at=$(
(
echo "master"
cd "$GIT_DIR/$remote_top" &&
find . -type f -print | sed -e 's/^\.\///'
) | (
done=f
while read name
do
test t = $done && continue
branch_tip=`cat "$GIT_DIR/$remote_top/$name"`
if test "$head_sha1" = "$branch_tip"
then
echo "$name"
done=t
fi
done
)
)
What I don't understand are:
- why do we have to do 'echo "master"' for the top of the loop? is
this an optimization?
- why do we keep looping after done=t?
I just noticed this when I tried to clone a repo _without_ master
branch.
Thanks for your time. And sorry for my ignorants.
--
yashi
^ permalink raw reply
* Re: [PATCH] Ability to automaticaly push tags to remote repositories.
From: Krzysiek Pawlik @ 2006-03-30 14:18 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <442BD562.3030207@people.pl>
[-- Attachment #1.1: Type: text/plain, Size: 182 bytes --]
Krzysiek Pawlik wrote:
> Comments, suggestions?
Broken when there are no tags. Attached patch fixes it.
--
Krzysiek Pawlik (Nelchael)
RLU #322999 GPG Key ID: 0xBC555551
[-- Attachment #1.2: fix-no-tags.patch --]
[-- Type: text/plain, Size: 1025 bytes --]
Fix auto-push of tags when there are no tags.
---
commit eff67bafe333c28c238feb614f098b987216ffb0
tree 8758ae4a2eace9c4fdf64ec89c1f983871097a74
parent 6e581cf43ccf7236ea47ac4ba9b51df9cda3c671
author Krzysiek Pawlik <kpawlik@silvermedia.pl> Thu, 30 Mar 2006 16:10:26 +0200
committer Krzysiek Pawlik <kpawlik@silvermedia.pl> Thu, 30 Mar 2006 16:10:26 +0200
cg-push | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cg-push b/cg-push
index 865cbd5..40016c1 100755
--- a/cg-push
+++ b/cg-push
@@ -60,7 +60,7 @@ if [ "${auto_push_tags}" = "yes" ]; then
if [ ! -d "$_git/cogito-tags-pushed" ]; then
mkdir "$_git/cogito-tags-pushed" || die "can't create cache for pushed tags"
fi
- for i in `cg-tag-ls | awk '{print $1}'`; do
+ for i in `cg-tag-ls 2> /dev/null | awk '{print $1}'`; do
if [ ! -f "$_git/cogito-tags-pushed/${i}" ]; then
echo "Adding ${i} to list of tags to push"
tags[${#tags[@]}]="refs/tags/${i}"
\f
!-------------------------------------------------------------flip-
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply related
* [PATCH] Ability to automaticaly push tags to remote repositories.
From: Krzysiek Pawlik @ 2006-03-30 12:56 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 688 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- From `cg-push --long-help`:
- -t TAG::
Tells cg-push to also push the given tag. Note that in the
future, cg-push should push tags automatically. Also note
that even if you pass `cg-push` the '-t' arguments, your
HEAD is still pushed as well in addition to the tags.
One of possible ways of doing it is in attached patch. Comments,
suggestions?
- --
Krzysiek Pawlik (Nelchael)
RLU #322999 GPG Key ID: 0xBC555551
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEK9Vigo/w9rxVVVERAvXkAJ42ESjs3REY0ECqIYlbz+9WX/3+ZQCfSQs/
B4X6U2io0Wq0/0oiolpUW1g=
=3ZR7
-----END PGP SIGNATURE-----
[-- Attachment #2: cg-push-tags.patch --]
[-- Type: text/plain, Size: 1475 bytes --]
Ability to automaticaly push tags to remote repositories.
---
commit 6e581cf43ccf7236ea47ac4ba9b51df9cda3c671
tree b440cb8e4629c5c77e38fb6179992b52edf8c861
parent 891c6d85f38a326e91d62906e1696a38d28fb105
author Krzysiek Pawlik <kpawlik@silvermedia.pl> Thu, 30 Mar 2006 14:48:36 +0200
committer Krzysiek Pawlik <kpawlik@silvermedia.pl> Thu, 30 Mar 2006 14:48:36 +0200
cg-push | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/cg-push b/cg-push
index 4332b28..865cbd5 100755
--- a/cg-push
+++ b/cg-push
@@ -43,17 +43,32 @@ send_pack_update()
locbranch="$_git_head"
tags=()
+auto_push_tags=yes
while optparse; do
if optparse -r=; then
locbranch="$OPTARG"
[ "$(cg-object-id -c "$locbranch")" ] || exit 1
elif optparse -t=; then
tags[${#tags[@]}]="refs/tags/$OPTARG"
+ auto_push_tags=no
else
optfail
fi
done
+if [ "${auto_push_tags}" = "yes" ]; then
+ if [ ! -d "$_git/cogito-tags-pushed" ]; then
+ mkdir "$_git/cogito-tags-pushed" || die "can't create cache for pushed tags"
+ fi
+ for i in `cg-tag-ls | awk '{print $1}'`; do
+ if [ ! -f "$_git/cogito-tags-pushed/${i}" ]; then
+ echo "Adding ${i} to list of tags to push"
+ tags[${#tags[@]}]="refs/tags/${i}"
+ touch "$_git/cogito-tags-pushed/${i}"
+ fi
+ done
+fi
+
[ ${#ARGS[@]} -gt 1 ] && die "too many arguments, I can push only one branch at once"
name="${ARGS[0]}"
\f
!-------------------------------------------------------------flip-
^ permalink raw reply related
* [PATCH] gitk: Use git wrapper to run git-ls-remote.
From: Mark Wooding @ 2006-03-30 12:31 UTC (permalink / raw)
To: git
From: Mark Wooding <mdw@distorted.org.uk>
For some reason, the Cygwin Tcl's `exec' command has trouble running
scripts. Fix this by using the C `git' wrapper. Other GIT programs run
by gitk are written in C already, so we don't need to incur a
performance hit of going via the wrapper (which I'll bet isn't pretty
under Cygwin).
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
gitk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index f4c6624..ac85d1c 100755
--- a/gitk
+++ b/gitk
@@ -359,7 +359,7 @@ proc readrefs {} {
foreach v {tagids idtags headids idheads otherrefids idotherrefs} {
catch {unset $v}
}
- set refd [open [list | git-ls-remote [gitdir]] r]
+ set refd [open [list | git ls-remote [gitdir]] r]
while {0 <= [set n [gets $refd line]]} {
if {![regexp {^([0-9a-f]{40}) refs/([^^]*)$} $line \
match id path]} {
^ permalink raw reply related
* [PATCH] cvsimport: use git-update-ref when updating
From: Johannes Schindelin @ 2006-03-30 12:06 UTC (permalink / raw)
To: git, junkio
This simplifies code, and also fixes a subtle bug: when importing in a
shared repository, where another user last imported from CVS, cvsimport
used to complain that it could not open <branch> for update.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-cvsimport.perl | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 3728294..957af13 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -15,6 +15,7 @@ # You can change that with the '-o' opti
use strict;
use warnings;
+use Fcntl;
use Getopt::Std;
use File::Spec;
use File::Temp qw(tempfile);
@@ -677,11 +678,7 @@ my $commit = sub {
waitpid($pid,0);
die "Error running git-commit-tree: $?\n" if $?;
- open(C,">$git_dir/refs/heads/$branch")
- or die "Cannot open branch $branch for update: $!\n";
- print C "$cid\n"
- or die "Cannot write branch $branch for update: $!\n";
- close(C)
+ system("git-update-ref refs/heads/$branch $cid") == 0
or die "Cannot write branch $branch for update: $!\n";
if($tag) {
^ permalink raw reply related
* Re: sending git-format-patch files with mailx.
From: Junio C Hamano @ 2006-03-30 9:14 UTC (permalink / raw)
To: David Ho; +Cc: git
In-Reply-To: <4dd15d180603291236j4ca4654fvbe5b6375e8623081@mail.gmail.com>
"David Ho" <davidkwho@gmail.com> writes:
> Very stupid question.
>
> I have patches created by git-format-patch. However I suppose I can
> send it off directly using mailx, but I have a hard time figuring how
> this is done.
>
> Someone here can probably answer this in a second.
Perhaps:
$ mailx -s 'my subject' upstream@maintainer.example.com
~r 0001-my-patch.txt
(that's tilde r).
But I thought we had a command for that: git-send-email. I
admit I haven't used it for anything real, though, since I do
not have an upstream maintainer anymore.
^ permalink raw reply
* [PATCH] contrib/git-svn: force GIT_DIR to an absolute path
From: Eric Wong @ 2006-03-30 6:37 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Eric Wong
We chdir internally, so we need a consistent GIT_DIR variable.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
40a9f8f87bbf041966c61431536186d03acefb50
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index 3e5733e..59dd504 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -9,7 +9,11 @@ use vars qw/ $AUTHOR $VERSION
$GIT_DIR $REV_DIR/;
$AUTHOR = 'Eric Wong <normalperson@yhbt.net>';
$VERSION = '0.11.0';
-$GIT_DIR = $ENV{GIT_DIR} || "$ENV{PWD}/.git";
+
+use Cwd qw/abs_path/;
+$GIT_DIR = abs_path($ENV{GIT_DIR} || '.git');
+$ENV{GIT_DIR} = $GIT_DIR;
+
# make sure the svn binary gives consistent output between locales and TZs:
$ENV{TZ} = 'UTC';
$ENV{LC_ALL} = 'C';
@@ -69,7 +73,6 @@ GetOptions(%opts, 'help|H|h' => \$_help,
$GIT_SVN ||= $ENV{GIT_SVN_ID} || 'git-svn';
$GIT_SVN_INDEX = "$GIT_DIR/$GIT_SVN/index";
-$ENV{GIT_DIR} ||= $GIT_DIR;
$SVN_URL = undef;
$REV_DIR = "$GIT_DIR/$GIT_SVN/revs";
$SVN_WC = "$GIT_DIR/$GIT_SVN/tree";
--
1.3.0.rc1.g709a5
^ permalink raw reply related
* Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?
From: Matt McCutchen @ 2006-03-30 3:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7ys4nwk.fsf@assigned-by-dhcp.cox.net>
On Wed, 2006-03-29 at 19:22 -0800, Junio C Hamano wrote:
> It should have been
>
> $ git format-patch --stdout origin master | git am -3
Thanks! My kernel is finally merged and is building as I write! It
turns out that parts of my commits #2-#4 had already been addressed
between 2.6.15.6 and 2.6.16. I had to merge #2 with what had already
been done, and #3 and #4 became unnecessary.
--
Matt McCutchen
hashproduct@verizon.net
http://hashproduct.metaesthetics.net/
^ permalink raw reply
* Re: Rebase semantic and cherry-pick
From: Junio C Hamano @ 2006-03-30 3:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603291852140.27203@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> For consistency reasons, we should probably allow that to be written as
> just "..branch", the same way we can write "branch.." to mean "everything
> in HEAD but not in "branch".
Something like this, perhaps.
-- >8 --
revision arguments: ..B means HEAD..B, just like A.. means A..HEAD
For consistency reasons, we should probably allow that to be written as
just "..branch", the same way we can write "branch.." to mean "everything
in HEAD but not in "branch".
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/rev-parse.c b/rev-parse.c
index f176c56..e956cd5 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -315,16 +315,17 @@ int main(int argc, char **argv)
dotdot = strstr(arg, "..");
if (dotdot) {
unsigned char end[20];
- char *n = dotdot+2;
+ char *next = dotdot + 2;
+ char *this = arg;
*dotdot = 0;
- if (!get_sha1(arg, sha1)) {
- if (!*n)
- n = "HEAD";
- if (!get_sha1(n, end)) {
- show_rev(NORMAL, end, n);
- show_rev(REVERSED, sha1, arg);
- continue;
- }
+ if (!*next)
+ next = "HEAD";
+ if (dotdot == arg)
+ this = "HEAD";
+ if (!get_sha1(this, sha1) && !get_sha1(next, end)) {
+ show_rev(NORMAL, end, next);
+ show_rev(REVERSED, sha1, this);
+ continue;
}
*dotdot = '.';
}
diff --git a/revision.c b/revision.c
index 745b0d2..2cda7e0 100644
--- a/revision.c
+++ b/revision.c
@@ -642,14 +642,19 @@ int setup_revisions(int argc, const char
if (dotdot) {
unsigned char from_sha1[20];
char *next = dotdot + 2;
+ char *this = arg;
+ static const char HEAD[] = "HEAD";
*dotdot = 0;
if (!*next)
- next = "HEAD";
- if (!get_sha1(arg, from_sha1) && !get_sha1(next, sha1)) {
+ next = HEAD;
+ if (dotdot == arg)
+ this = HEAD;
+ if (!get_sha1(this, from_sha1) &&
+ !get_sha1(next, sha1)) {
struct commit *exclude;
struct commit *include;
- exclude = get_commit_reference(revs, arg, from_sha1, flags ^ UNINTERESTING);
+ exclude = get_commit_reference(revs, this, from_sha1, flags ^ UNINTERESTING);
include = get_commit_reference(revs, next, sha1, flags);
if (!exclude || !include)
die("Invalid revision range %s..%s", arg, next);
^ permalink raw reply related
* Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?
From: Junio C Hamano @ 2006-03-30 3:22 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <1143687710.2524.1.camel@mattlaptop.metaesthetics.net>
Matt McCutchen <hashproduct@verizon.net> writes:
>> you could:
>>
>> $ git fetch git://../torvalds/linux-2.6.git tag v2.6.16
>> $ git checkout -b 2.6.16-matt v2.6.16
>> $ git format-patch origin master | git am -3
>...
> What is wrong?
Me ;-).
It should have been
$ git format-patch --stdout origin master | git am -3
Sorry.
> Perhaps this is just politics, but which kernel repository is more
> official, and why? Linus's or the one I have been using,
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
> ?
Linus tree is the main development for the 2.6.(X+1), and
2.6.x.y are managed by the stable team. They serve different
purposes, and both are "official".
^ permalink raw reply
* Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?
From: Junio C Hamano @ 2006-03-30 3:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603291102440.15714@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> For example, in the most trivial format, doing a
>
> git rebase <branchname>
>
> the _logical_ thing (from just reading the command) to believe the above
> does is to think that it rebases the named branch. I pretty much guarantee
> that that is what any native English speaker would think it does, if they
> thought about it.
Not really. Most of the commands in git suite operate on the
current branch.
After thinking about it a bit more, I still agree with you that
things are not as easy to explain as they should be, but I do
not think rebase is so broken anymore.
> In contrast, here's an alternate workflow that is much easier to explain,
> and doesn't involve "rebase" at all:
>
> git checkout his
> git cherry-pick origin..mine
This is _easy_ to explain, yes. However, I do not necessarily
agree with what you said here:
> In particular, what do you think happens when a patch in the series
> doesn't apply under the two circumstances? Which workflow has the
> "intuitive" way of recovering, and which does not?
>
> Right. The second one has a very intuitive way to recover. In fact, it's
> so intuitive that the answer may be "ok, I'll skip that one commit
> entirely because I don't know how to resolve it, and instead cherry-pick
> the rest, and ask the original author to cherry-pick it for me later". And
> doing so is as easy as
>
> git reset --hard # undo the mess from the failed one,
> # the same way we always do for all
> # other failed things
>
> git cherry-pick next..mine # do the rest
It is not so easy to figure out what the next should be. If we
limit ourselves to the simplest case that origin is an ancestor
of mine, yes, but in general, no. We are rebasing presumably
because upstream made independent progress so "origin" would not
be an ancestor of mine anymore; and you are talking about the
generic rev-list syntax next..mine === ^next mine.
"reset --hard" to stop cherry picking is easy. I do not think
continuing is as easy as you made it sound like.
There was a nontrivial amount of thought went into making the
"rebase" restartable. Actually, that thought was really for
making the "am" restartable, and the hope was once the user
becomes familiar with how to restart "am", restarting "rebase"
is just as easy because you restart them the same way. You have
it fall back to 3-way merge (and in the case of rebase, it _can_
fall back to 3-way when the patch does not apply, because all
the blob object names recorded in the intermediate patch format
are from your local repository), you resolve and prepare the
index to be committed, and say "git am --resolved". We _could_
make "git rebase --resolved" a synonym for "git am --resolved",
because "rebase" being tied to "am" only because the former is
implemented in terms of the latter behind the user _is_
unintiutive.
> See? That's a very logical thing to do. It's different from "git rebase",
> but it's different in a _good_ way.
As I said, yes, the part to punt is easy. But that is different
from being able to continue smoothly. And if you want to punt
during "rebase", you could just as easily do "git reset --hard
ORIG_HEAD", just like you would punt a failed merge with "git
reset --hard ORIG_HEAD".
The non-English (and no natural language I presume) syntax
rebase takes is a mistake from understandability point of view.
I fully agree with that. Let me think aloud how we could
rephrase them better.
(1) git rebase origin
A---B---C master (HEAD)
/
---o---o---o---o origin
I started building on tip of his but while I was woking on
it he made independent progress. I want to rebuild my
branch as if I started at the tip of his current branch.
A---B---C master (HEAD)
/
---o---o---o---o origin
(2) git rebase --onto origin A..C
A---B---C master (HEAD)
/
---o---o---o---o origin
I started building on tip of his but while I was woking on
it he made independent progress. I want to rebuild my
branch as if I started at the tip of his current branch, but
come to think of it I do not need A anymore.
B---C master (HEAD)
/
---o---o---o---o origin
I personally feel _this_ form is the most logical, and form
(1) for the sake of consistency could be spelled as:
$ git rebase --onto origin origin..master
So you could think of (1) a convenient shorthand for this
spelled-out form.
(3) git rebase --onto origin A..C topic
B---C topic
/
.---A---. master (HEAD)
/
---o---o---o---o origin
I have a topic that interferes with what he did in his
latest updates, and I'd like to resolve the conflicts
early. Currently I am not on that branch so first let me
switch to it.
.---A---. master
/
---o---o---o---o origin
\
B---C topic (HEAD)
This form was done only as a shorthand to save typing "git
checkout topic" at the beginning, just like "git checkout -b
newbranch" can be used to save typing "git branch newbranch"
before the checkout, but I agree it may have made things
more confusing. We _could_ deprecate this form and require
the user to always switch branches before starting the
rebase.
^ permalink raw reply
* Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?
From: Matt McCutchen @ 2006-03-30 3:01 UTC (permalink / raw)
To: git
In-Reply-To: <7vmzfac7gn.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]
On Tue, 2006-03-28 at 18:26 -0800, Junio C Hamano wrote:
> v2.6.15 v2.6.16
> ---o---o---o---...---o---o
> \ \
> \ y---y---y 2.6.16-matt
> \
> o---o---o v2.6.15.6
> \
> x---x---x 2.6.15.6-matt
>
> to happen, where y---y---y are analogous to x---x---x.
>
> Assuming your branches are:
>
> origin - v2.6.15.6 (from stable team)
> master - your changes (2.6.15.6-matt)
Beautiful diagram. This is exactly my situation.
> you could:
>
> $ git fetch git://../torvalds/linux-2.6.git tag v2.6.16
> $ git checkout -b 2.6.16-matt v2.6.16
> $ git format-patch origin master | git am -3
This looks like what I want. When I run the third command, however, I
get "no patch found". Four files corresponding to my four commits
appear in my repository; I have attached them. What is wrong?
> Alternatively, you might want to do a real merge:
> [...] If you do not understand
> what the stable team did in order to reimplement certain fixes,
> you would have a very difficult time deciding on how to resolve
> conflicts with this merge.
Yes, I think this is the problem what I ran into before when I was
trying to pull.
Perhaps this is just politics, but which kernel repository is more
official, and why? Linus's or the one I have been using,
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
?
Thanks for the help!
--
Matt McCutchen
hashproduct@verizon.net
http://hashproduct.metaesthetics.net/
[-- Attachment #2: 0001-Changes-for-Matt-s-custom-kernel-the-Stickier-Patch-and-appropriate-markers.txt --]
[-- Type: text/plain, Size: 11630 bytes --]
>From nobody Mon Sep 17 00:00:00 2001
From: Matt McCutchen <matt@mattlaptop.metaesthetics.net>
Date: Sun Mar 5 20:14:20 2006 -0500
Subject: [PATCH] Changes for Matt's custom kernel: the Stickier Patch and appropriate markers.
---
Documentation/filesystems/stickier.txt | 24 ++++++
README.matt | 1
fs/namei.c | 132 ++++++++++++++++++++++++++------
localversion-matt | 1
4 files changed, 132 insertions(+), 26 deletions(-)
create mode 100644 Documentation/filesystems/stickier.txt
create mode 100644 README.matt
create mode 100644 localversion-matt
6a2fe5757614310ca63e7b2bac1acb5c2081d86c
diff --git a/Documentation/filesystems/stickier.txt b/Documentation/filesystems/stickier.txt
new file mode 100644
index 0000000..03db966
--- /dev/null
+++ b/Documentation/filesystems/stickier.txt
@@ -0,0 +1,24 @@
+Matt McCutchen's Stickier Patch
+-------------------------------
+
+In the official Linux kernel's filesystem support, the only thing the sticky bit does is restrict deletion and overwriting of directory entries: you can't unlink or move another file over a file you don't own in a sticky directory you don't own.
+
+The Stickier Patch makes two changes to the behavior of the sticky bit. First, creating a link to a file you don't own in a sticky directory you don't own is now forbidden. (Doing so used to be possible but irreversible, which I considered an incongruity.)
+
+Second, a sticky directory you don't own has restrictions on lookup by name beyond the requirement of execute permission. You can always look up a file that you own or on which you have at least one permission (read, write, or execute). If you try to look up another file, you get EPERM. If you try to look up a nonexistent file, you get ENOENT if you can read or write the directory, but EPERM if you can only execute it. These restrictions apply to all path following, so every system call that follows paths can potentially cause EPERM.
+
+Why this change? If you want to allow everyone on your computer to read a folder in your home directory, you can set its permissions to 755; however, to get to the folder, people need execute on your home directory. But giving them execute opens the door to loads of abuse. People can guess filenames and see if those files exist in your home directory; if the files exist, people can stat them and learn their atimes, mtimes, and sizes. Maybe they won't hit upon any of your personal files, but the names of your mailbox and your dotfiles are likely to be well-known. People can find out when you last got mail and about how big the mail was, what programs you've used recently, and so forth.
+
+With the Stickier Patch, you can set your home directory sticky (mode 1711). People can still get to the public folder, but trying to access any other name will cause EPERM. They can't even learn whether the files exist, much less stat them.
+
+Alternatively, you can set your home directory to mode 1755, in which case others can list the names of all files but only see stat information for the public ones:
+ drwxr-xr-t 81 matt matt 4096 Jan 18 16:13 .
+ drwxr-xr-x 3 root root 4096 Jan 8 16:46 ..
+ ?--------- ? ? ? ? ? .bashrc
+ lrwxrwxrwx 1 matt matt 18 Jan 18 16:14 symlink -> some/target/path
+ drwxr-xr-x 1 matt matt 18 Jan 18 16:14 public
+ ?--------- ? ? ? ? ? private
+
+Note that the symlink appears and is stattable because it grants everyone every permission; there's nothing you can do about this unless/until I make another patch that adds lchmod and meaningful symlink permissions (r == readlink, w == writelink (to be implemented), x == traverse). In addition, the Stickier Patch does not change the behavior of readdir, which often gives the i-number and type of a file along with its name. (In fact, a short-form ls listing will classify private directories as directories, not as unstattable, because short-form ls bases classification on readdir.)
+
+Future versions of the Stickier Patch may address these issues and may also provide a way to set a directory so private entries are hidden from readdir (setuid bit?). In the meantime, if any of these issues is a concern, one should remove read permission and announce the names of files others may access in another venue so they don't have to guess.
diff --git a/README.matt b/README.matt
new file mode 100644
index 0000000..8df642d
--- /dev/null
+++ b/README.matt
@@ -0,0 +1 @@
+This is Matt McCutchen's custom kernel. Right now, the only difference between it and the official one is the Stickier Patch, described in Documentation/filesystems/sticker.txt , which changes the behavior of the sticky bit on directories.
diff --git a/fs/namei.c b/fs/namei.c
index 6dbbd42..baea761 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -766,6 +766,66 @@ fail:
}
/*
+ * It's inline, so penalty for filesystems that don't use sticky bit is
+ * minimal.
+ * MATT -- null inode allowed, it's as if nobody owns it
+ */
+static inline int check_sticky(struct inode *dir, struct inode *inode)
+{
+ if (!(dir->i_mode & S_ISVTX))
+ return 0;
+ if (inode && inode->i_uid == current->fsuid)
+ return 0;
+ if (dir->i_uid == current->fsuid)
+ return 0;
+ return !capable(CAP_FOWNER);
+}
+
+/*
+ * MATT -- Will a new entry refuse to adhere to the directory? :)
+ */
+static inline int check_unsticky(struct inode *dir, uid_t new_owner)
+{
+ if (!(dir->i_mode & S_ISVTX))
+ return 0;
+ if (new_owner == current->fsuid)
+ return 0;
+ if (dir->i_uid == current->fsuid)
+ return 0;
+ return !capable(CAP_FOWNER);
+}
+
+/*
+ * MATT
+ * Check whether we can traverse a directory entry; return 0 or -Exxxx.
+ * 1. We can if the directory entry isn't sticky for us (see check_sticky).
+ * 2. If the entry points nowhere, we can traverse it if we can read or
+ * write the directory.
+ * 3. If the entry points to a file, we can traverse it if we can read,
+ * write, or execute the file.
+ * Because of the clumsy interface, we need several permission checks.
+ */
+static inline int may_traverse(struct inode *dir,struct inode *inode)
+{
+ if (!check_sticky(dir, inode))
+ return 0;
+ if (inode) {
+ if (permission(inode, MAY_READ, NULL) == 0
+ || permission(inode, MAY_WRITE, NULL) == 0
+ || permission(inode, MAY_EXEC, NULL) == 0)
+ return 0;
+ else
+ return -EPERM;
+ } else {
+ if (permission(dir, MAY_READ, NULL) == 0
+ || permission(dir, MAY_WRITE, NULL) == 0)
+ return 0;
+ else
+ return -EPERM;
+ }
+}
+
+/*
* Name resolution.
* This is the basic name resolution function, turning a pathname into
* the final dentry. We expect 'base' to be positive and a directory.
@@ -794,6 +854,7 @@ static fastcall int __link_path_walk(con
unsigned long hash;
struct qstr this;
unsigned int c;
+ struct inode *dirsave;
nd->flags |= LOOKUP_CONTINUE;
err = exec_permission_lite(inode, nd);
@@ -801,6 +862,7 @@ static fastcall int __link_path_walk(con
err = vfs_permission(nd, MAY_EXEC);
if (err)
break;
+ dirsave = inode;
this.name = name;
c = *(const unsigned char *)name;
@@ -852,8 +914,16 @@ static fastcall int __link_path_walk(con
if (err)
break;
- err = -ENOENT;
inode = next.dentry->d_inode;
+ /*
+ * MATT -- May we traverse the entry?
+ * inode might be null; may_traverse checks this case and
+ * might cause EPERM to conceal whether the inode exists.
+ */
+ err = may_traverse(dirsave, inode);
+ if (err)
+ goto out_dput;
+ err = -ENOENT;
if (!inode)
goto out_dput;
err = -ENOTDIR;
@@ -906,6 +976,14 @@ last_component:
if (err)
break;
inode = next.dentry->d_inode;
+ /*
+ * MATT -- May we traverse the entry?
+ * inode might be null; may_traverse checks this case and
+ * might cause EPERM to conceal whether the inode exists.
+ */
+ err = may_traverse(dirsave, inode);
+ if (err)
+ break;
if ((lookup_flags & LOOKUP_FOLLOW)
&& inode && inode->i_op && inode->i_op->follow_link) {
err = do_follow_link(&next, nd);
@@ -1260,21 +1338,6 @@ int fastcall __user_walk(const char __us
}
/*
- * It's inline, so penalty for filesystems that don't use sticky bit is
- * minimal.
- */
-static inline int check_sticky(struct inode *dir, struct inode *inode)
-{
- if (!(dir->i_mode & S_ISVTX))
- return 0;
- if (inode->i_uid == current->fsuid)
- return 0;
- if (dir->i_uid == current->fsuid)
- return 0;
- return !capable(CAP_FOWNER);
-}
-
-/*
* Check whether we can remove a link victim from directory dir, check
* whether the type of victim is right.
* 1. We can't do it if dir is read-only (done in permission())
@@ -1333,12 +1396,27 @@ static inline int may_delete(struct inod
* 4. We can't do it if dir is immutable (done in permission())
*/
static inline int may_create(struct inode *dir, struct dentry *child,
- struct nameidata *nd)
+ struct nameidata *nd, uid_t new_owner)
{
if (child->d_inode)
return -EEXIST;
if (IS_DEADDIR(dir))
return -ENOENT;
+ if (check_unsticky(dir, new_owner))
+ return -EPERM;
+ return permission(dir,MAY_WRITE | MAY_EXEC, nd);
+}
+
+/* Same as may_create but allow the child to already exist.
+ * Separately you should check may_delete on an existing child, if any.
+ */
+static inline int may_create_or_overwrite(struct inode *dir, struct dentry *child,
+ struct nameidata *nd, uid_t new_owner)
+{
+ if (IS_DEADDIR(dir))
+ return -ENOENT;
+ if (check_unsticky(dir, new_owner))
+ return -EPERM;
return permission(dir,MAY_WRITE | MAY_EXEC, nd);
}
@@ -1405,7 +1483,7 @@ void unlock_rename(struct dentry *p1, st
int vfs_create(struct inode *dir, struct dentry *dentry, int mode,
struct nameidata *nd)
{
- int error = may_create(dir, dentry, nd);
+ int error = may_create(dir, dentry, nd, current->fsuid);
if (error)
return error;
@@ -1721,7 +1799,7 @@ EXPORT_SYMBOL_GPL(lookup_create);
int vfs_mknod(struct inode *dir, struct dentry *dentry, int mode, dev_t dev)
{
- int error = may_create(dir, dentry, NULL);
+ int error = may_create(dir, dentry, NULL, current->fsuid);
if (error)
return error;
@@ -1794,7 +1872,7 @@ out:
int vfs_mkdir(struct inode *dir, struct dentry *dentry, int mode)
{
- int error = may_create(dir, dentry, NULL);
+ int error = may_create(dir, dentry, NULL, current->fsuid);
if (error)
return error;
@@ -2032,7 +2110,7 @@ slashes:
int vfs_symlink(struct inode *dir, struct dentry *dentry, const char *oldname, int mode)
{
- int error = may_create(dir, dentry, NULL);
+ int error = may_create(dir, dentry, NULL, current->fsuid);
if (error)
return error;
@@ -2092,7 +2170,7 @@ int vfs_link(struct dentry *old_dentry,
if (!inode)
return -ENOENT;
- error = may_create(dir, new_dentry, NULL);
+ error = may_create(dir, new_dentry, NULL, inode->i_uid);
if (error)
return error;
@@ -2285,12 +2363,14 @@ int vfs_rename(struct inode *old_dir, st
if (error)
return error;
- if (!new_dentry->d_inode)
- error = may_create(new_dir, new_dentry, NULL);
- else
- error = may_delete(new_dir, new_dentry, is_dir);
+ error = may_create_or_overwrite(new_dir, new_dentry, NULL, old_dentry->d_inode->i_uid);
if (error)
return error;
+ if (new_dentry->d_inode) {
+ error = may_delete(new_dir, new_dentry, is_dir);
+ if (error)
+ return error;
+ }
if (!old_dir->i_op || !old_dir->i_op->rename)
return -EPERM;
diff --git a/localversion-matt b/localversion-matt
new file mode 100644
index 0000000..fd815c7
--- /dev/null
+++ b/localversion-matt
@@ -0,0 +1 @@
+.matt1
--
1.2.4
[-- Attachment #3: 0002-Create-and-add-to-.gitignore-files-so-that-source-tree-is-git-clean-after-I.txt --]
[-- Type: text/plain, Size: 1852 bytes --]
>From nobody Mon Sep 17 00:00:00 2001
From: Matt McCutchen <matt@mattlaptop.metaesthetics.net>
Date: Sun Mar 5 20:16:19 2006 -0500
Subject: [PATCH] Create and add to .gitignore files so that source tree is git-clean after I
build the kernel.
---
arch/i386/kernel/.gitignore | 3 +++
drivers/ieee1394/.gitignore | 1 +
drivers/scsi/aic7xxx/.gitignore | 4 ++++
include/asm-i386/.gitignore | 1 +
scripts/kconfig/.gitignore | 1 +
5 files changed, 10 insertions(+), 0 deletions(-)
create mode 100644 arch/i386/kernel/.gitignore
create mode 100644 drivers/ieee1394/.gitignore
create mode 100644 drivers/scsi/aic7xxx/.gitignore
create mode 100644 include/asm-i386/.gitignore
a52dcfea1864b643a58ab2e1693487037f64f233
diff --git a/arch/i386/kernel/.gitignore b/arch/i386/kernel/.gitignore
new file mode 100644
index 0000000..e8ef014
--- /dev/null
+++ b/arch/i386/kernel/.gitignore
@@ -0,0 +1,3 @@
+vsyscall-int80.so
+vsyscall-sysenter.so
+vsyscall.lds
diff --git a/drivers/ieee1394/.gitignore b/drivers/ieee1394/.gitignore
new file mode 100644
index 0000000..33da10a
--- /dev/null
+++ b/drivers/ieee1394/.gitignore
@@ -0,0 +1 @@
+oui.c
diff --git a/drivers/scsi/aic7xxx/.gitignore b/drivers/scsi/aic7xxx/.gitignore
new file mode 100644
index 0000000..a1a7fcd
--- /dev/null
+++ b/drivers/scsi/aic7xxx/.gitignore
@@ -0,0 +1,4 @@
+aic79xx_reg.h
+aic79xx_seq.h
+aic7xxx_reg.h
+aic7xxx_seq.h
diff --git a/include/asm-i386/.gitignore b/include/asm-i386/.gitignore
new file mode 100644
index 0000000..62b0ac8
--- /dev/null
+++ b/include/asm-i386/.gitignore
@@ -0,0 +1 @@
+asm-offsets.h
diff --git a/scripts/kconfig/.gitignore b/scripts/kconfig/.gitignore
index 2dac344..8298ca8 100644
--- a/scripts/kconfig/.gitignore
+++ b/scripts/kconfig/.gitignore
@@ -14,3 +14,4 @@ mconf
qconf
gconf
kxgettext
+zconf.hash.c
--
1.2.4
[-- Attachment #4: 0003-More-ignore-files-for-build-outputs.txt --]
[-- Type: text/plain, Size: 872 bytes --]
>From nobody Mon Sep 17 00:00:00 2001
From: Matt McCutchen <matt@mattlaptop.metaesthetics.net>
Date: Sun Mar 5 23:12:19 2006 -0500
Subject: [PATCH] More ignore files for build outputs
---
arch/i386/boot/.gitignore | 3 +++
arch/i386/boot/tools/.gitignore | 1 +
2 files changed, 4 insertions(+), 0 deletions(-)
create mode 100644 arch/i386/boot/.gitignore
create mode 100644 arch/i386/boot/tools/.gitignore
94eb588607845f97f0fceb6e95690142ba8a807a
diff --git a/arch/i386/boot/.gitignore b/arch/i386/boot/.gitignore
new file mode 100644
index 0000000..495f20c
--- /dev/null
+++ b/arch/i386/boot/.gitignore
@@ -0,0 +1,3 @@
+bootsect
+bzImage
+setup
diff --git a/arch/i386/boot/tools/.gitignore b/arch/i386/boot/tools/.gitignore
new file mode 100644
index 0000000..378eac2
--- /dev/null
+++ b/arch/i386/boot/tools/.gitignore
@@ -0,0 +1 @@
+build
--
1.2.4
[-- Attachment #5: 0004-Fix-setlocalversion-to-follow-a-ref-when-looking-for-a-GIT-version-suffix.txt --]
[-- Type: text/plain, Size: 858 bytes --]
>From nobody Mon Sep 17 00:00:00 2001
From: Matt McCutchen <matt@mattlaptop.metaesthetics.net>
Date: Sun Mar 5 23:16:01 2006 -0500
Subject: [PATCH] Fix setlocalversion to follow a `ref: ' when looking for a GIT version suffix
---
scripts/setlocalversion | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
75f8f156ff1f7869b23edf795e9588e25755be5d
diff --git a/scripts/setlocalversion b/scripts/setlocalversion
index 7c805c8..229bda7 100644
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -35,6 +35,13 @@ sub do_git_checks {
my $head = <H>;
chomp $head;
close(H);
+ # Follow a ref: in the HEAD
+ if ($head =~ s/^ref: //) {
+ open(H,"<.git/" . $head) or return;
+ $head = <H>;
+ chomp $head;
+ close(H);
+ }
opendir(D,".git/refs/tags") or return;
foreach my $tagfile (grep !/^\.{1,2}$/, readdir(D)) {
--
1.2.4
^ permalink raw reply related
* Re: Rebase semantic and cherry-pick
From: Linus Torvalds @ 2006-03-30 2:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: jnareb, git
In-Reply-To: <7vwtec7j37.fsf@assigned-by-dhcp.cox.net>
On Wed, 29 Mar 2006, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Perhaps if possible also have
> >
> > git cherry-pick --whole-branch branchname
> >
> > meaning
> >
> > git cherry-pick branchname:begining..branchname:HEAD
>
> There is no branchname:beginning in git.
Well, in this case you don't need it. You just do
git cherry-pick HEAD..branch
and it just magically does the right thing.
For consistency reasons, we should probably allow that to be written as
just "..branch", the same way we can write "branch.." to mean "everything
in HEAD but not in "branch".
Linus
^ permalink raw reply
* Re: Rebase semantic and cherry-pick
From: Junio C Hamano @ 2006-03-30 2:38 UTC (permalink / raw)
To: jnareb; +Cc: git
In-Reply-To: <e0fe1h$d5r$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Perhaps if possible also have
>
> git cherry-pick --whole-branch branchname
>
> meaning
>
> git cherry-pick branchname:begining..branchname:HEAD
There is no branchname:beginning in git.
^ permalink raw reply
* Re: Rebase semantic and cherry-pick
From: Jakub Narebski @ 2006-03-30 1:59 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0603291102440.15714@g5.osdl.org>
Linus Torvalds wrote:
> In contrast, here's an alternate workflow that is much easier to explain,
> and doesn't involve "rebase" at all:
>
> git checkout his
> git cherry-pick origin..mine
[...]
> Now, "git cherry-pick" doesn't actually support the above format, and I'm
> not saying that the "git rebase" name itself is evil. I think we could fix
> "git rebase" to work better, but the semantics - the way they are
> _designed_ right now - are just horrible.
Perhaps if possible also have
git cherry-pick --whole-branch branchname
meaning
git cherry-pick branchname:begining..branchname:HEAD
--
Jakub Narebski
^ 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