* [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
* sending git-format-patch files with mailx.
From: David Ho @ 2006-03-29 20:36 UTC (permalink / raw)
To: git
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.
Thanks in advance,
David
^ permalink raw reply
* Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?
From: Junio C Hamano @ 2006-03-29 20:24 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:
> 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
Yes, I think it would be good to deprecate/discard the current
rebase and make cherry-pick the recommended workflow.
Optionally. I've been thinking about not using git-cherry while
cherrypicking, because falling back to three-way merge seems to
work equally well in dealing with "patch already applied" case.
Anyway, teaching the range notation to cherry-pick would be
something like this, I suppose.
---
diff --git a/git-cherry-pick.sh b/git-cherry-pick.sh
new file mode 100755
index 0000000..72a3828
--- /dev/null
+++ b/git-cherry-pick.sh
@@ -0,0 +1,6 @@
+#!/bin/sh
+
+. git-sh-setup
+
+git-format-patch --stdout --full-index -k "$@" |
+git-am --binary -3 -k
diff --git a/Makefile b/Makefile
index d945546..e130d8c 100644
--- a/Makefile
+++ b/Makefile
@@ -114,7 +114,7 @@ ### --- END CONFIGURATION SECTION ---
SCRIPT_SH = \
git-add.sh git-bisect.sh git-branch.sh git-checkout.sh \
- git-cherry.sh git-clone.sh git-commit.sh \
+ git-cherry.sh git-cherry-pick.sh git-clone.sh git-commit.sh \
git-count-objects.sh git-diff.sh git-fetch.sh \
git-format-patch.sh git-log.sh git-ls-remote.sh \
git-merge-one-file.sh git-parse-remote.sh \
@@ -139,7 +139,7 @@ SCRIPT_PYTHON = \
SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
$(patsubst %.perl,%,$(SCRIPT_PERL)) \
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
- git-cherry-pick git-show git-status
+ git-show git-status
# The ones that do not have to link with lcrypto nor lz.
SIMPLE_PROGRAMS = \
@@ -484,9 +484,6 @@ common-cmds.h: Documentation/git-*.txt
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
$@.py >$@
chmod +x $@
-
-git-cherry-pick: git-revert
- cp $< $@
git-show: git-whatchanged
cp $< $@
^ permalink raw reply related
* RE: Problem with git bisect between 2.6.15 and 2.6.16
From: Luck, Tony @ 2006-03-29 19:43 UTC (permalink / raw)
To: Greg Lee, git; +Cc: sean
> This was progressing fine until I ran into an issue that makes the kernel unstable causing
> it to crash at semi-random times. I'm down to about 350 commits left in the bisect. I've
> tried:
>
> git reset --hard HEAD~3
>
>no luck, same problem, unstable
You can try "git bisect visualize" to invoke gitk on the remaining commits, and
then pick a likely looking stable point for your next test. This is documented
reasonably well in the git Documentation/howto/isolate-bugs-with-bisect.txt
-Tony
^ permalink raw reply
* Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?
From: Linus Torvalds @ 2006-03-29 19:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603291102440.15714@g5.osdl.org>
On Wed, 29 Mar 2006, Linus Torvalds wrote:
>
> Right now, the sequence is:
>
> git checkout mine # if required
> git rebase --onto his origin
vs
> git checkout his
> git cherry-pick origin..mine
Btw, I realize that the advantage of "git rebase" is that it doesn't
change somebody elses branch. However, we'd still be a lot better off with
us simply doing the equivalent of something like
git checkout -b new-mine his &&
git cherry-pick origin..mine &&
git rename-branch -f new-mine mine
instead of what git-rebase does now.
Linus
^ permalink raw reply
* RE: Problem with git bisect between 2.6.15 and 2.6.16
From: Greg Lee @ 2006-03-29 19:28 UTC (permalink / raw)
To: git; +Cc: 'sean', 'Tony Luck'
In-Reply-To: <12c511ca0603271622n6e4614b2s6f936469863efd9d@mail.gmail.com>
> You'll need to invert "good" and bad" for this. I.e. mark 2.6.15 as good, 2.6.16 as
bad, and
> then as you test mark kernels with the bug as good, and ones without as bad. Try not to
go
> insane while working in this inverted parallel universe :-)
>
> -Tony
This was progressing fine until I ran into an issue that makes the kernel unstable causing
it to crash at semi-random times. I'm down to about 350 commits left in the bisect. I've
tried:
git reset --hard HEAD~3
no luck, same problem, unstable
then I tried --hard HEAD~50
no luck, same problem, unstable
I'm concerned about moving too much further in the "~" direction, will this cause me other
problems?
Greg
^ permalink raw reply
* Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?
From: Linus Torvalds @ 2006-03-29 19:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkutc36w.fsf@assigned-by-dhcp.cox.net>
On Tue, 28 Mar 2006, Junio C Hamano wrote:
>
> Having said that, you have been able to say format-patch A..B
> C..D E..F for quite some time (since November 21, 2005).
Yes, and the documentation still talks only about the old insane format..
> Rebase is even more strange, especially with --onto. When you do
>
> $ rebase --onto his origin mine
>
> in this picture,
>
> *---x---x---o---o---o---o
> \ ^origin ^mine
> .---.---.---.
> ^his
>
> you are discarding two 'x' commits, and lost-found is the only
> thing that would help you to recover them.
.. and this is largely because the whole interface is broken.
The breakage shows up as inflexibility and having a hard time explaining
what the thing does. It shows up as confusion about the usage, and about
the meaning of a simple command line.
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.
The fact that it actually does the _reverse_, and rebases not the named
branch, but the branch you are on right now.
The fact that when things go south, the old branch has gotten lost (unless
you remember about ORIG_HEAD) is all related to the same thing. It's just
a very non-intuitive interface.
That was fine when people weren't supposed to use it, and it was doing
something very very special, but that has clearly changed over time. Now
people are encouraged to use it, it's pretty well-known, and even new git
users seem to want to do it.
I think "git rebase" is a lost cause. It's just fundamentally a very very
badly designed command, because it does everything the wrong way around.
I personally believe that the _sane_ way of doing rebasing is to
- get rid of "git rebase" entirely
- teach "git cherry-pick" to take a _range_ of commits instead.
Lookie here, let's look at your example a bit more (which in turn comes
from the original question that started this thread):
*---x---x---o---o---o---o
\ ^origin ^mine
.---.---.---.
^his
We have three branch points, and we want to move the commits on "mine"
from "origin" onto "his". How would you do this so that it's _not_
confusing, and so that you can explain to a newbie user what he is doing,
_especially_ if things go wrong in the middle?
Right now, the sequence is:
git checkout mine # if required
git rebase --onto his origin
and if things go south during the rebase, it's immediately total chaos,
and you really _really_ need to understand what you are doing.
The above just doesn't make any sense. It's hard to explain why you would
do something like that.
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
Notice what this does? Show these two sequences to anybody who has some
basic familiarity with git terminology, but has perhaps never actually
used it, and ask them what the two sequences do. I pretty much guarantee
that the second sequence will make sense and get people to generally pick
the right answer, while the first sequence will make people maybe _guess_
the right answer, but it's not intuitive.
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
See? That's a very logical thing to do. It's different from "git rebase",
but it's different in a _good_ way.
In contrast, the "rebase" conflict resolution is pretty damn esoteric, and
using a simple "gitk --all" when things go wrong won't help you pick
things up at all.
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.
Linus
^ permalink raw reply
* Re: Git terminology
From: Sébastien Pierre @ 2006-03-29 16:11 UTC (permalink / raw)
To: Junio C Hamano, Git ML
In-Reply-To: <7vodzp9r8r.fsf@assigned-by-dhcp.cox.net>
On Wed, 29 Mar 2006 07:59:16 -0800
Junio C Hamano <junkio@cox.net> wrote:
> Probably we can just say "ref" where we say "refname".
>
> A fast-forward is where you have a revision and you are
> "merging" other's change that happen to be a descendant what you
> have. In such a case, you do not make a new merge commit but
> just update to his revision. That is:
>
> o---o---o---o his o---o---o---o his
> / -> / \
> o---o---o---o yours o---o---o---o-------* yours
>
> updating to his needs a merge like above, but in this case:
>
> o---o---o---o his o---o---o---o his = yours
> / -> /
> o---o yours o---o
>
> you just update to his.
Ah, ok. The diagrams are really helpful to get what "fast forward" is.
Thanks !
-- Sébastien
^ permalink raw reply
* Re: Git terminology
From: Junio C Hamano @ 2006-03-29 15:59 UTC (permalink / raw)
To: Sébastien Pierre; +Cc: git
In-Reply-To: <20060329052113.6a773480.sebastien@xprima.com>
Sébastien Pierre <sebastien@xprima.com> writes:
> In the process of learning git, and browsing the docs, I
> realized that many particular terms are used, but I had
> difficulties finding their definitions.
I had difficulties reading your message. Please fold your lines.
> Among those I found a bit arcane, there are (in no particular
> order) "refspec", "rebase", "rewound", "pickaxe", "refnames",
> "objectnames" ,"refnames", "fast-forward update".
I see some are missing from our glossary but some others are
found there.
refspec is used by fetch and push to describe the mapping
between remote ref and local ref. E.g. "git fetch $URL
refs/heads/master:refs/heads/origin" means "grab the master
branch head from there and store it as my origin branch head".
"git push $URL refs/heads/master:refs/heads/to-upstream" for
"publish my master branch head as to-upstream master head at
$URL".
Probably we can just say "ref" where we say "refname".
Probably we can just say "ref" where we say "refname".
A fast-forward is where you have a revision and you are
"merging" other's change that happen to be a descendant what you
have. In such a case, you do not make a new merge commit but
just update to his revision. That is:
o---o---o---o his o---o---o---o his
/ -> / \
o---o---o---o yours o---o---o---o-------* yours
updating to his needs a merge like above, but in this case:
o---o---o---o his o---o---o---o his = yours
/ -> /
o---o yours o---o
you just update to his.
A related concept is "being already up-to-date". In the latter
picture, if he attempts to "merge" your changes and notices he
is simply ahead of you (i.e. his revision is a descendant of
yours), nothing happens.
> If some of you are willing to detail/explain/define those
> terms (and some others not mentioned here), I would be glad to
> collect the definitions and make a "git terminology" document.
Thanks, and what J Bruce Fields already said.
^ permalink raw reply
* Re: Git terminology
From: J. Bruce Fields @ 2006-03-29 15:31 UTC (permalink / raw)
To: Sébastien Pierre; +Cc: Git ML
In-Reply-To: <20060329052113.6a773480.sebastien@xprima.com>
On Wed, Mar 29, 2006 at 05:21:13AM -0500, Sébastien Pierre wrote:
> If some of you are willing to detail/explain/define those terms (and
> some others not mentioned here), I would be glad to collect the
> definitions and make a "git terminology" document.
See Documentation/glossary.txt. It's missing some of the terms your
looking for, but I'm sure patches would be accepted.
--b.
^ permalink raw reply
* Git terminology
From: Sébastien Pierre @ 2006-03-29 10:21 UTC (permalink / raw)
To: Git ML
Hi all,
In the process of learning git, and browsing the docs, I realized that many particular terms are used, but I had difficulties finding their definitions.
Among those I found a bit arcane, there are (in no particular order) "refspec", "rebase", "rewound", "pickaxe", "refnames", "objectnames" ,"refnames", "fast-forward update".
Also, doing a "grep -rohE '<[a-z\-]+>' * | sort | uniq" in git source tree gave me the list of "parameter types" for git commands, where some would benefit from a formal definition : <base>, <blob>, <branch>, <branchname>, <comitish>, <tree>, <tree-ish>, <head>, <headsha>, <refspec>, and so on. Of course, some of these terms are already explained in the man pages, but it would be nice to have a "git terminlogy reference".
If some of you are willing to detail/explain/define those terms (and some others not mentioned here), I would be glad to collect the definitions and make a "git terminology" document.
-- Sébastien
^ permalink raw reply
* Re: [PATCH] Unclutter cg status with --directory as GIT does
From: Petr Baudis @ 2006-03-29 15:08 UTC (permalink / raw)
To: Blaisorblade; +Cc: git
In-Reply-To: <200603291704.14870.blaisorblade@yahoo.it>
Dear diary, on Wed, Mar 29, 2006 at 05:04:14PM CEST, I got a letter
where Blaisorblade <blaisorblade@yahoo.it> said that...
> Sorry, that's just an old patch then, I didn't note you did it yourself.
>
> I wrote it before you had the 1.1 dependency and didn't notice you made
> something similar.
Well, I've just applied your patch :-) :
commit 4e1cd8ac4815bdc3e6671a2a5a266a9ca675630d
author Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Thu, 19 Jan 2006 22:16:46 +0100
committer Petr Baudis <xpasky@machine.or.cz> Sat, 21 Jan 2006 02:21:13 +0100
Kind regards,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: [PATCH] Unclutter cg status with --directory as GIT does
From: Blaisorblade @ 2006-03-29 15:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060329145427.GI27689@pasky.or.cz>
On Wednesday 29 March 2006 16:54, Petr Baudis wrote:
> Dear diary, on Wed, Mar 29, 2006 at 04:25:59PM CEST, I got a letter
> where Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> said that...
> > Pass the new --directory option (from git 1.1) to git-ls-others for
> > list_untracked_files, as does git-status - it's very useful.
> > Probably this must be deferred to when the git 1.1 dependency is added,
> > however please queue it for then.
> Uh, I'm confused. Cogito now depends on git-1.1, and
> as you can see, if list_untracked_files was pssed the 'squashdirs'
> option, it will already pass it. What cg command would you like to
> squash dirs except cg-status?
Sorry, that's just an old patch then, I didn't note you did it yourself.
I wrote it before you had the 1.1 dependency and didn't notice you made
something similar.
Bye and sorry for the noise
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* Re: [PATCH] Unclutter cg status with --directory as GIT does
From: Petr Baudis @ 2006-03-29 14:54 UTC (permalink / raw)
To: Paolo 'Blaisorblade' Giarrusso; +Cc: git
In-Reply-To: <20060329142559.12059.52795.stgit@zion.home.lan>
Dear diary, on Wed, Mar 29, 2006 at 04:25:59PM CEST, I got a letter
where Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> said that...
> Pass the new --directory option (from git 1.1) to git-ls-others for
> list_untracked_files, as does git-status - it's very useful.
>
> Probably this must be deferred to when the git 1.1 dependency is added, however
> please queue it for then.
Uh, I'm confused. Cogito now depends on git-1.1, and
> diff --git a/cg-Xlib b/cg-Xlib
> index 2b93c11..3150470 100644
> --- a/cg-Xlib
> +++ b/cg-Xlib
> @@ -274,7 +274,7 @@ list_untracked_files()
> fi
> local listdirs=
> [ "$squashflag" = "squashdirs" ] && listdirs=--directory
> - git-ls-files -z --others $listdirs "${EXCLUDE[@]}"
> + git-ls-files -z --others --directory $listdirs "${EXCLUDE[@]}"
as you can see, if list_untracked_files was pssed the 'squashdirs'
option, it will already pass it. What cg command would you like to
squash dirs except cg-status?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* [PATCH] Pass --directory to git-ls-files for stg status
From: Paolo 'Blaisorblade' Giarrusso @ 2006-03-29 14:25 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Requires GIT 1.1.0 at least (don't know if this was backported in 1.0).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
stgit/git.py | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/stgit/git.py b/stgit/git.py
index 40d54ef..e8c816d 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -194,8 +194,8 @@ def __tree_status(files = None, tree_id
if noexclude:
extra_exclude = base_exclude = []
- lines = _output_lines(['git-ls-files', '--others'] + base_exclude
- + extra_exclude)
+ lines = _output_lines(['git-ls-files', '--others', '--directory']
+ + base_exclude + extra_exclude)
cache_files += [('?', line.strip()) for line in lines]
# conflicted files
^ permalink raw reply related
* [PATCH] Unclutter cg status with --directory as GIT does
From: Paolo 'Blaisorblade' Giarrusso @ 2006-03-29 14:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Pass the new --directory option (from git 1.1) to git-ls-others for
list_untracked_files, as does git-status - it's very useful.
Probably this must be deferred to when the git 1.1 dependency is added, however
please queue it for then.
Thanks.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
cg-Xlib | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cg-Xlib b/cg-Xlib
index 2b93c11..3150470 100644
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -274,7 +274,7 @@ list_untracked_files()
fi
local listdirs=
[ "$squashflag" = "squashdirs" ] && listdirs=--directory
- git-ls-files -z --others $listdirs "${EXCLUDE[@]}"
+ git-ls-files -z --others --directory $listdirs "${EXCLUDE[@]}"
}
pick_id()
^ permalink raw reply related
* Re: [PATCH] Support for pickaxe matching regular expressions
From: Petr Baudis @ 2006-03-29 13:09 UTC (permalink / raw)
To: Linus Torvalds, Johannes Schindelin; +Cc: Mark Wooding, git
In-Reply-To: <20060329001633.GF27689@pasky.or.cz>
Dear diary, on Wed, Mar 29, 2006 at 02:16:33AM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> The regex.h library is a rather stupid interface and I like pcre too, but
> with any luck it will be everywhere we will want to run Git on, it being
> POSIX.2 and all. I'm not sure if we can expect platforms like AIX to
> conform to POSIX.2 or if win32 has regex.h. We might add a flag to
> Makefile if there is a portability trouble potential.
Dear diary, on Wed, Mar 29, 2006 at 01:42:00PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> We already use regex.h (probably my fault).
Indeed, and since noone complained yet, the portability consideration is
apparently a non-issue.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ 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