* [PATCH/RFCv3 2/2] receive-pack: don't pass non-existent refs to post-{receive,update} hooks in push deletions
From: Pang Yan Han @ 2011-09-28 15:39 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Sitaram Chamarty, Shawn O. Pearce, Jeff King,
Johannes Schindelin
When a push specifies deletion of non-existent refs, the post post-receive and
post-update hooks receive as input/arguments the non-existent refs.
For instance, for the following push, where refs/heads/nonexistent is a ref
which does not exist on the remote side:
git push origin :refs/heads/nonexistent
the post-receive hook receives from standard input:
<null-sha1> SP <null-sha1> SP refs/heads/nonexistent
and the post-update hook receives as arguments:
refs/heads/nonexistent
which does not make sense since it is a no-op.
Teach receive-pack to not pass non-existent refs as input / arguments to the
post-receive and post-update hooks in the event of a push involving
non-existent ref deletion.
Signed-off-by: Pang Yan Han <pangyanhan@gmail.com>
---
builtin/receive-pack.c | 31 ++++++++-
t/t5516-fetch-push.sh | 170 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 197 insertions(+), 4 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index ae164da..8a0a9d2 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -153,6 +153,26 @@ struct command {
char ref_name[FLEX_ARRAY]; /* more */
};
+/* For invalid refs */
+static struct command **invalid_delete;
+static size_t invalid_delete_nr;
+static size_t invalid_delete_alloc;
+
+static void invalid_delete_append(struct command *cmd)
+{
+ ALLOC_GROW(invalid_delete, invalid_delete_nr + 1, invalid_delete_alloc);
+ invalid_delete[invalid_delete_nr++] = cmd;
+}
+
+static int is_invalid_delete(struct command *cmd)
+{
+ size_t i;
+ for (i = 0; i < invalid_delete_nr; i++)
+ if (invalid_delete[i] == cmd)
+ return 1;
+ return 0;
+}
+
static const char pre_receive_hook[] = "hooks/pre-receive";
static const char post_receive_hook[] = "hooks/post-receive";
@@ -215,7 +235,7 @@ static int run_receive_hook(struct command *commands, const char *hook_name)
int have_input = 0, code;
for (cmd = commands; !have_input && cmd; cmd = cmd->next) {
- if (!cmd->error_string)
+ if (!cmd->error_string && !is_invalid_delete(cmd))
have_input = 1;
}
@@ -248,7 +268,7 @@ static int run_receive_hook(struct command *commands, const char *hook_name)
}
for (cmd = commands; cmd; cmd = cmd->next) {
- if (!cmd->error_string) {
+ if (!cmd->error_string && !is_invalid_delete(cmd)) {
size_t n = snprintf(buf, sizeof(buf), "%s %s %s\n",
sha1_to_hex(cmd->old_sha1),
sha1_to_hex(cmd->new_sha1),
@@ -447,6 +467,8 @@ static const char *update(struct command *cmd)
if (!parse_object(old_sha1)) {
rp_warning("Allowing deletion of corrupt ref.");
old_sha1 = NULL;
+ if (!ref_exists((char *) name))
+ invalid_delete_append(cmd);
}
if (delete_ref(namespaced_name, old_sha1, 0)) {
rp_error("failed to delete %s", name);
@@ -477,7 +499,7 @@ static void run_update_post_hook(struct command *commands)
struct child_process proc;
for (argc = 0, cmd = commands; cmd; cmd = cmd->next) {
- if (cmd->error_string)
+ if (cmd->error_string || is_invalid_delete(cmd))
continue;
argc++;
}
@@ -488,7 +510,7 @@ static void run_update_post_hook(struct command *commands)
for (argc = 1, cmd = commands; cmd; cmd = cmd->next) {
char *p;
- if (cmd->error_string)
+ if (cmd->error_string || is_invalid_delete(cmd))
continue;
p = xmalloc(strlen(cmd->ref_name) + 1);
strcpy(p, cmd->ref_name);
@@ -866,5 +888,6 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
}
if (use_sideband)
packet_flush(1);
+ free(invalid_delete);
return 0;
}
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 3abb290..c0d8a0e 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -40,6 +40,39 @@ mk_test () {
)
}
+mk_test_with_hooks() {
+ mk_test "$@" &&
+ (
+ cd testrepo &&
+ mkdir .git/hooks &&
+ cd .git/hooks &&
+
+ cat >pre-receive <<'EOF' &&
+#!/bin/sh
+cat - >>pre-receive.actual
+EOF
+
+ cat >update <<'EOF' &&
+#!/bin/sh
+printf "%s %s %s\n" "$@" >>update.actual
+EOF
+ cat >post-receive <<'EOF' &&
+#!/bin/sh
+cat - >>post-receive.actual
+EOF
+
+ cat >post-update <<'EOF' &&
+#!/bin/sh
+for ref in "$@"
+do
+ printf "%s\n" "$ref" >>post-update.actual
+done
+EOF
+
+ chmod u+x pre-receive update post-receive post-update
+ )
+}
+
mk_child() {
rm -rf "$1" &&
git clone testrepo "$1"
@@ -559,6 +592,143 @@ test_expect_success 'allow deleting an invalid remote ref' '
'
+test_expect_success 'pushing valid refs triggers post-receive and post-update hooks' '
+ mk_test_with_hooks heads/master heads/next &&
+ orgmaster=$(cd testrepo && git show-ref -s --verify refs/heads/master) &&
+ newmaster=$(git show-ref -s --verify refs/heads/master) &&
+ orgnext=$(cd testrepo && git show-ref -s --verify refs/heads/next) &&
+ newnext=$_z40 &&
+ git push testrepo refs/heads/master:refs/heads/master :refs/heads/next &&
+ (cd testrepo/.git &&
+ cat >pre-receive.expect <<'EOF' &&
+$orgmaster $newmaster refs/heads/master
+$orgnext $newnext refs/heads/next
+EOF
+
+ cat >update.expect <<'EOF' &&
+refs/heads/master $orgmaster $newmaster
+refs/heads/next $orgnext $newnext
+EOF
+
+ cat >post-receive.expect <<'EOF' &&
+$orgmaster $newmaster refs/heads/master
+$orgnext $newnext refs/heads/next
+EOF
+
+ cat >post-update.expect <<'EOF' &&
+refs/heads/master
+refs/heads/next
+EOF
+
+ test_cmp pre-receive.expect pre-receive.actual &&
+ test_cmp update.expect update.actual &&
+ test_cmp post-receive.expect post-receive.actual &&
+ test_cmp post-update.expect post-update.actual
+ )
+'
+
+test_expect_success 'deleting dangling ref triggers hooks with correct args' '
+ mk_test_with_hooks heads/master &&
+ rm -f testrepo/.git/objects/??/* &&
+ git push testrepo :refs/heads/master &&
+ (cd testrepo/.git &&
+ cat >pre-receive.expect <<'EOF' &&
+$_z40 $_z40 refs/heads/master
+EOF
+
+ cat >update.expect <<'EOF' &&
+refs/heads/master $_z40 $_z40
+EOF
+
+ cat >post-receive.expect <<'EOF' &&
+$_z40 $_z40 refs/heads/master
+EOF
+
+ cat >post-update.expect <<'EOF' &&
+refs/heads/master
+EOF
+
+ test_cmp pre-receive.expect pre-receive.actual &&
+ test_cmp update.expect update.actual &&
+ test_cmp post-receive.expect post-receive.actual &&
+ test_cmp post-update.expect post-update.actual
+ )
+'
+
+test_expect_success 'deleting non-existent ref does not trigger post-receive and post-update hooks' '
+ mk_test_with_hooks heads/master &&
+ orgmaster=$(cd testrepo && git show-ref -s --verify refs/heads/master) &&
+ newmaster=$(git show-ref -s --verify refs/heads/master) &&
+ git push testrepo master :refs/heads/nonexistent &&
+ (cd testrepo/.git &&
+ cat >pre-receive.expect <<'EOF' &&
+$orgmaster $newmaster refs/heads/master
+$_z40 $_z40 refs/heads/nonexistent
+EOF
+
+ cat >update.expect <<'EOF' &&
+refs/heads/master $orgmaster $newmaster
+refs/heads/nonexistent $_z40 $_z40
+EOF
+
+ cat >post-receive.expect <<'EOF' &&
+$orgmaster $newmaster refs/heads/master
+EOF
+
+ cat >post-update.expect <<'EOF' &&
+refs/heads/master
+EOF
+
+ test_cmp pre-receive.expect pre-receive.actual &&
+ test_cmp update.expect update.actual &&
+ test_cmp post-receive.expect post-receive.actual &&
+ test_cmp post-update.expect post-update.actual
+ )
+'
+
+test_expect_success 'mixed ref updates, deletes, invalid deletes trigger hooks with correct input' '
+ mk_test_with_hooks heads/master heads/next heads/pu &&
+ orgmaster=$(cd testrepo && git show-ref -s --verify refs/heads/master) &&
+ newmaster=$(git show-ref -s --verify refs/heads/master) &&
+ orgnext=$(cd testrepo && git show-ref -s --verify refs/heads/next) &&
+ newnext=$_z40 &&
+ orgpu=$(cd testrepo && git show-ref -s --verify refs/heads/pu) &&
+ newpu=$(git show-ref -s --verify refs/heads/master) &&
+ git push testrepo refs/heads/master:refs/heads/master refs/heads/master:refs/heads/pu :refs/heads/next :refs/heads/nonexistent &&
+ (cd testrepo/.git &&
+ cat >pre-receive.expect <<'EOF' &&
+$orgmaster $newmaster refs/heads/master
+$orgnext $newnext refs/heads/next
+$orgpu $newpu refs/heads/pu
+$_z40 $_z40 refs/heads/nonexistent
+EOF
+
+ cat >update.expect <<'EOF' &&
+refs/heads/master $orgmaster $newmaster
+refs/heads/next $orgnext $newnext
+refs/heads/pu $orgpu $newpu
+refs/heads/nonexistent $_z40 $_z40
+EOF
+
+ cat >post-receive.expect <<'EOF' &&
+$orgmaster $newmaster refs/heads/master
+$orgnext $newnext refs/heads/next
+$orgpu $newpu refs/heads/pu
+EOF
+
+ cat >post-update.expect <<'EOF' &&
+refs/heads/master
+refs/heads/next
+refs/heads/pu
+EOF
+
+ test_cmp pre-receive.expect pre-receive.actual &&
+ test_cmp update.expect update.actual &&
+ test_cmp post-receive.expect post-receive.actual &&
+ test_cmp post-update.expect post-update.actual
+ )
+'
+
test_expect_success 'allow deleting a ref using --delete' '
mk_test heads/master &&
(cd testrepo && git config receive.denyDeleteCurrent warn) &&
--
1.7.7.rc3.2.g6bf07
^ permalink raw reply related
* Re: error: addinfo_cache failed during merge
From: Stephen Bash @ 2011-09-28 15:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git discussion list
In-Reply-To: <7vehz01yhx.fsf@alter.siamese.dyndns.org>
----- Original Message -----
> From: "Junio C Hamano" <gitster@pobox.com>
> To: "Stephen Bash" <bash@genarts.com>
> Cc: "git discussion list" <git@vger.kernel.org>
> Sent: Wednesday, September 28, 2011 11:24:10 AM
> Subject: Re: error: addinfo_cache failed during merge
>
> Stephen Bash <bash@genarts.com> writes:
>
> > ... I should caveat that my local git/git is a little out of date
> > because I haven't repointed it since k.org went down (I use it very
> > rarely), so there might be something newer in this area.
>
> Indeed there have been a few fixs in this area and it would be really
> nice if you can test this with the latest master branch before 1.7.7
> final ships.
The problem reproduces on master (8d714b1). Git builds really fast when I don't need docs ;) In case it's important, this is all on MacOS 10.6.8.
Thanks,
Stephen
^ permalink raw reply
* Re: subversion-perl missing
From: Georg-Johann Lay @ 2011-09-28 15:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Christian Couder, git
In-Reply-To: <201109281459.31689.jnareb@gmail.com>
Jakub Narebski schrieb:
> On Wed, 28 Sep 2011, Georg-Johann Lay wrote:
>> As far as I understand, alien-svn comes with SVN sources which it uses for its
>> own perl packages to provide svn stuff to perl, but don't install/build new svn
>> version.
>
> Step by step instruction.
>
> 1. Follow instructions on local::lib manpage
> http://search.cpan.org/perldoc?local::lib
>
> c.f. http://perl.jonallen.info/writing/articles/install-perl-modules-without-root
>
> 2. (Optional). Follow instructions on cpanm manpage, e.g. http://cpanmin.us
> or http://search.cpan.org/perldoc?cpanm
>
> 3. Install Alien::SVN from CPAN using 'cpan' client or 'cpanm', e.g.
>
> $ cpanm Alien::SVN
>
> Now you are able to install Perl modules in your home directory.
Thank you very much, I never would have found the way through all that jungle
alone!
After steps 1-3 succeeded (as far as I can tell) I can run git svn (but not
git-svn) now.
With an SVN repo I can do
$ svn list http://repo/path
archive/
branches/
tags/
trunk/
and
$ svn checkout http://repo/path
but git svn complains:
$ git svn clone -s --username=georg http://repo/path
Initialized empty Git repository in /local/georg/path/.git/
Bad URL passed to RA layer: Unrecognized URL scheme for 'http://repo/path' at
/usr/local/libexec/git-core/git-svn line 1941
Does git svn not support http?
>From what I read in git svn --help this should suffice to checkout from SVN and
http is mentioned explicitly in an example.
So is my git-svn still broken/not functional or am I missing something from the
docs?
Johann
^ permalink raw reply
* 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch
From: Carlos Martín Nieto @ 2011-09-28 16:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]
Hello,
Whilst trying to do some work related to fetch, I came across a
regression in the 'next' branch. Bisecting gave me this commit as
breaking point (and I tried with the parent and there it worked). When
doing 'git fetch', rev-list will complain about usage, and fetch will
say that we didn't receive enough, even though earlier versions of git
have no problems. This fails both on github and on git.or.cz and for git
and http transports:
$ ./git-fetch git://repo.or.cz/git
usage: git rev-list [OPTION] <commit-id>... [ -- paths... ]
limiting output:
--max-count=<n>
--max-age=<epoch>
--min-age=<epoch>
--sparse
--no-merges
--min-parents=<n>
--no-min-parents
--max-parents=<n>
--no-max-parents
--remove-empty
--all
--branches
--tags
--remotes
--stdin
--quiet
ordering output:
--topo-order
--date-order
--reverse
formatting output:
--parents
--children
--objects | --objects-edge
--unpacked
--header | --pretty
--abbrev=<n> | --no-abbrev
--abbrev-commit
--left-right
special purpose:
--bisect
--bisect-vars
--bisect-all
error: git://repo.or.cz/git did not send all necessary objects
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Signed push progress?
From: Junio C Hamano @ 2011-09-28 16:35 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: Git Mailing List
In-Reply-To: <20110928075054.GA13727@orbis-terrarum.net>
"Robin H. Johnson" <robbat2@gentoo.org> writes:
> from CVS to Git (we're very close now), we've decided that the signed
> pushes will provide better security than our plan of previous plan of
> using signed notes, so we'd like to see signed pushes succeed.
Could you elaborate on your "previous plan" a bit? What is a signed note,
how would it help validate the authenticity, how do developers interact
using it and what do you perceive as weaknesses compared to the signed
push that we discussed a few weeks ago?
^ permalink raw reply
* SVN -> Git *but* with special changes
From: Abscissa @ 2011-09-28 16:37 UTC (permalink / raw)
To: git
I have a couple big projects in SVN that I'd like to convert to Git. Being in
SVN, they've operated under a couple assumptions that are not true under
Git. These assumptions are:
1. Directories can exist even if there's nothing in them (just like any
filesystem).
2. Keeping binary files in version control isn't a big deal because the
whole repo doesn't get copied to everyone's system or use up people's GitHub
storage space.
The SVN repos have been relying on those, but both are false under Git, so I
need to do a "modified" conversion, rather than just a straight one.
So, how can I convert an SVN repo to Git, and have the conversion add dummy
files to empty directories and exclude specific files? (Also, there are tags
and branches to be converted too, in the SVN-standard "tags" and "branches"
directories.)
--
View this message in context: http://git.661346.n2.nabble.com/SVN-Git-but-with-special-changes-tp6840904p6840904.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH v3] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael Witten @ 2011-09-28 16:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: Carlos Martín Nieto, vra5107, Michael J Gruber, Matthieu Moy,
Eric Raible, Philip Oakley, Jeff King, Jay Soffian, git
In-Reply-To: <553B5FA1A43748B1ADD759572EADA6FF@PhilipOakley>
See:
Re: Can a git changeset be created with no parent
Carlos Martín Nieto <cmn@elego.de>
Message-ID: <1317073309.5579.9.camel@centaur.lab.cmartin.tk>
http://article.gmane.org/gmane.comp.version-control.git/182170
and:
git help glossary
Signed-off-by: Michael Witten <mfwitten@gmail.com>
---
Documentation/git-checkout.txt | 65 +++++++++++++++++++++++++++------------
1 files changed, 45 insertions(+), 20 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index c0a96e6..0b6e528 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -125,29 +125,54 @@ explicitly give a name with '-b' in such a case.
below for details.
---orphan::
- Create a new 'orphan' branch, named <new_branch>, started from
- <start_point> and switch to it. The first commit made on this
- new branch will have no parents and it will be the root of a new
- history totally disconnected from all the other branches and
- commits.
-+
-The index and the working tree are adjusted as if you had previously run
-"git checkout <start_point>". This allows you to start a new history
-that records a set of paths similar to <start_point> by easily running
-"git commit -a" to make the root commit.
-+
-This can be useful when you want to publish the tree from a commit
-without exposing its full history. You might want to do this to publish
-an open source branch of a project whose current tree is "clean", but
-whose full history contains proprietary or otherwise encumbered bits of
-code.
-+
-If you want to start a disconnected history that records a set of paths
-that is totally different from the one of <start_point>, then you should
-clear the index and the working tree right after creating the orphan
-branch by running "git rm -rf ." from the top level of the working tree.
-Afterwards you will be ready to prepare your new files, repopulating the
-working tree, by copying them from elsewhere, extracting a tarball, etc.
+--orphan::
+ Tell git to turn the next commit you create into a root commit
+ (that is, a commit without any parent); creating the next commit
+ is similar to creating the first commit after running "git{nbsp}init",
+ except that the new commit will be referenced by the branch head
+ <new_branch> rather than "master".
++
+Furthermore, the working tree and index are adjusted as if you ran
+"git{nbsp}checkout{nbsp}<start_point>"; thus, by just running
+"git{nbsp}commit", you can create a root commit with a tree that is
+exactly the same as the tree of <start_point>.
++
+Naturally, before creating the commit, you may manipulate the index
+in any way you want. For example, if you want to create a root commit
+with a tree that is totally different from the tree of <start_point>,
+then just clear the working tree and index first: From the top level
+of the working tree, run "git{nbsp}rm{nbsp}-rf{nbsp}.", and then
+prepare your new working tree and index as desired.
++
+There are two common uses for this option:
++
+--
+ Separate history::
+ Suppose that for convenience, you want to maintain
+ the website for your project in the same repository
+ as the project itself. In such a case, it may not
+ make much sense to interleave the history of the
+ website with the history of the project; you can use
+ the "--orphan" option in order to create these two
+ completely separate histories.
+
+ Hidden history::
+ Suppose you have a project that has proprietary
+ material that is never meant to be released to the
+ public, yet you now want to maintain an open source
+ history that may be published widely.
++
+In this case, it would not be enough just to remove the proprietary
+material from the working tree and then create a new commit, because
+the proprietary material would still be accessible through the new
+commit's ancestry; the proprietary history must be hidden from the new
+commit, and the "--orphan" option allows you to do so by ensuring that
+the new commit has no parent.
++
+However, removing proprietary material from ancestry is usually a task
+that is better performed by linkgit:git-filter-branch[1] and
+linkgit:git-rebase[1], especially when there are multiple commits that
+are already suitable for the open source history.
+--
-m::
--merge::
--
1.7.6.409.ge7a85
^ permalink raw reply related
* Re: Lack of detached signatures
From: Junio C Hamano @ 2011-09-28 16:45 UTC (permalink / raw)
To: Joseph Parmelee
Cc: Carlos Martín Nieto, Olsen, Alan R, Michael Witten,
git@vger.kernel.org
In-Reply-To: <alpine.LNX.2.00.1109280555460.25187@bruno>
Joseph Parmelee <jparmele@wildbear.com> writes:
> There is confusion here between the repository and the tarball. Once you
> have produced the tarball there is NO cryptographic protection against
> forgeries unless you sign it with GPG.
True.
If I give you a URL http://code.google.com/p/git-core/downloads/list with
checksums
$ sha1sum git-1.7.7.rc3.tar.gz
c6ba05a833cab49dd66dd1e252306e187effbf2b git-1.7.7.rc3.tar.gz
You either have to trust that code.google.com/ is not broken, or this
message is coming from real Junio (provided if you can trust him in the
first place).
BUT.
The world is not so blank-and-white. Trust is ultimately among humans. If
this message is not from the real Junio, don't you think you will hear
something like "No, that c6ba05... is forgery, please don't use it!" from
him, when he finds this message on the Git mailing list? If he does not
exercise diligence to even do that much, does he deserve your trust in the
first place?
GPG does add security (if you have the key) but you can do pretty well
even without it in practice.
> It is only because kernel.org exercised due diligence in the production of
> tags and signatures on all their tarballs that the kernel code itself
> withstood their recent intrusion....
I do not think that is true at all. Developers just dropped *.tar.gz on a
'master' machine, and left the rest to a cron job that reflates the
tarball into *.tar.bz2, sign both using a GPG key, and mirror them to the
public-facing machines 'www'.
Somebody who had access to the 'master' machine could add a new tarball
and have it go thru the same exact process, getting signed by the cron.
^ permalink raw reply
* Re: Lack of detached signatures
From: Michael Witten @ 2011-09-28 16:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Joseph Parmelee, Carlos Martín Nieto, Olsen, Alan R,
git@vger.kernel.org
In-Reply-To: <7v1uv01uqm.fsf@alter.siamese.dyndns.org>
On Wed, Sep 28, 2011 at 16:45, Junio C Hamano <gitster@pobox.com> wrote:
> The world is not so blank-and-white. Trust is ultimately among humans. If
> this message is not from the real Junio, don't you think you will hear
> something like "No, that c6ba05... is forgery, please don't use it!" from
> him, when he finds this message on the Git mailing list? If he does not
> exercise diligence to even do that much, does he deserve your trust in the
> first place?
You are parroting Linus's drivel.
If we get to the point where we need the real Junio yelling:
DO NOT USE IT!
then things went too far long before. In that case, my trust in you as
the maintainer would also take a hit; I expect you to use the
available technology to avoid such a situation.
Not everybody manages to read every [real] message of yours, so we
need to provide people with ways to check for themselves that the
sources that they have *locally* already are sound.
^ permalink raw reply
* Re: Lack of detached signatures
From: Matthieu Moy @ 2011-09-28 16:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: Joseph Parmelee, Carlos Martín Nieto, Olsen, Alan R,
Michael Witten, git@vger.kernel.org
In-Reply-To: <7v1uv01uqm.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> The world is not so blank-and-white. Trust is ultimately among humans. If
> this message is not from the real Junio, don't you think you will hear
> something like "No, that c6ba05... is forgery, please don't use it!" from
> him, when he finds this message on the Git mailing list? If he does not
> exercise diligence to even do that much, does he deserve your trust in the
> first place?
This assumes you will see the message, so while it does solve simple
attacks like sending an email with a fake From: header to the actual
list, it does not solve more advanced attacks like compromising
kernel.org's mailing-list server to avoid delivering you the forged
email.
I know I'm being a little paranoid here, but given the recent events
with kernel.org, maybe we should be that paranoid :-(.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* RE: Lack of detached signatures
From: Ben Walton @ 2011-09-28 17:03 UTC (permalink / raw)
To: git
In-Reply-To: <4B2793BF110AAB47AB0EE7B90897038516F63A7C@ORSMSX101.amr.corp.intel.com>
Excerpts from Olsen, Alan R's message of Wed Sep 28 00:17:54 -0400 2011:
Hi Alan,
> What I would like to see in git would be signed commits. I have
> looked at what it would take to make it work, but I don't have all
> the details worked out. (Certain merges and cherry-picks would not
> work very well.)
I'm presuming that your intent is an optional signature, not a forced
one, but for discussion, consider the monotone[1] dvcs that forces a
signature on every commit.
While interesting, it was quite heavy weight. Their design was
complicated by the fact that they used their own pki solution instead
of relying on gpg (although they did integrate with gpg-agent).
Granting access to a new user meant sharing monotone-specific keys,
etc. It's been my experience that ssh keys are challenging enough for
many people, and asking them to use gpg keys is just not going to fly
unless mandated from the higher-ups.
We used monotone here for about a year and the key requirements were
the biggest turn off to adoption. Maybe using standard (gpg) tools
would have been less so, but for the most part, I don't think so.
In my (very humble) opinion, signed tags (or possibly the new signed
push certificates) are a much better solution to this. They offer the
same guarantees as having every commit signed (trust of all commits
can be determined based on a signle signature) but leave daily
interactions much more light weight and flexible.
Thanks
-Ben
[1] http://monotone.ca
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
^ permalink raw reply
* Re: SVN -> Git *but* with special changes
From: Stephen Bash @ 2011-09-28 17:10 UTC (permalink / raw)
To: Abscissa; +Cc: git
In-Reply-To: <1317227849979-6840904.post@n2.nabble.com>
----- Original Message -----
> From: "Abscissa" <bus_nabble_git@semitwist.com>
> To: git@vger.kernel.org
> Sent: Wednesday, September 28, 2011 12:37:29 PM
> Subject: SVN -> Git *but* with special changes
>
> I have a couple big projects in SVN that I'd like to convert to Git.
> Being in SVN, they've operated under a couple assumptions that are
> not true under Git. These assumptions are:
>
> 1. Directories can exist even if there's nothing in them (just like
> any filesystem).
What requires the empty directories to exist? The build system? Can you just let them go away in Git and fix it downstream in the user's working copy?
> 2. Keeping binary files in version control isn't a big deal because
> the whole repo doesn't get copied to everyone's system or use up
> people's GitHub storage space.
I'd eliminate these on the SVN side before converting to Git. If you have svnadmin access to the SVN repo svnadmin dump, svndumpfilter, svnadmin load is a pretty easy process.
> The SVN repos have been relying on those, but both are false under
> Git, so I need to do a "modified" conversion, rather than just a
> straight one.
>
> So, how can I convert an SVN repo to Git, and have the conversion add
> dummy files to empty directories and exclude specific files? (Also,
> there are tags and branches to be converted too, in the SVN-standard
> "tags" and "branches" directories.)
To do the actual conversion, svn-fe and git fast-import are by far the quickest way to get the data into Git. Filtering into tags and branches is a bit of a trick though [1]. git-svn has (IMO) a good branching UI, but can be very slow for large repositories.
[1] http://thread.gmane.org/gmane.comp.version-control.git/158940/focus=159151 : note this thread is almost a year out of date now, and even I know much better ways to go about this now -- but the scripts are not written.
HTH,
Stephen
^ permalink raw reply
* [PATCH 1/3] parseopt: add OPT_NOOP_NOARG
From: René Scharfe @ 2011-09-28 17:44 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Pierre Habouzit
In-Reply-To: <7v39fhv8se.fsf@alter.siamese.dyndns.org>
Add OPT_NOOP_NOARG, a helper macro to define deprecated options in a
standard way. The help text is taken from the no-op option -r of
git revert.
The callback could be made to emit a (conditional?) warning later. And
we could also add OPT_NOOP (requiring an argument) etc. as needed.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
Two follow-up patches use the new macro to replace OPTION_BOOLEAN in
three cases. Could be squashed in.
Documentation/technical/api-parse-options.txt | 5 +++++
parse-options-cb.c | 5 +++++
parse-options.h | 6 +++++-
t/t0040-parse-options.sh | 2 +-
test-parse-options.c | 1 +
5 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
index f6a4a36..c209046 100644
--- a/Documentation/technical/api-parse-options.txt
+++ b/Documentation/technical/api-parse-options.txt
@@ -198,6 +198,11 @@ There are some macros to easily define options:
"auto", set `int_var` to 1 if stdout is a tty or a pager,
0 otherwise.
+`OPT_NOOP_NOARG(short, long)`::
+ Introduce an option that has no effect and takes no arguments.
+ Use it to hide deprecated options that are still to be recognized
+ and ignored silently.
+
The last element of the array must be `OPT_END()`.
diff --git a/parse-options-cb.c b/parse-options-cb.c
index 6db0921..0de5fb1 100644
--- a/parse-options-cb.c
+++ b/parse-options-cb.c
@@ -123,3 +123,8 @@ int parse_opt_string_list(const struct option *opt, const char *arg, int unset)
string_list_append(v, xstrdup(arg));
return 0;
}
+
+int parse_opt_noop_cb(const struct option *opt, const char *arg, int unset)
+{
+ return 0;
+}
diff --git a/parse-options.h b/parse-options.h
index 59e0b52..47c11f3 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -148,7 +148,10 @@ struct option {
#define OPT_COLOR_FLAG(s, l, v, h) \
{ OPTION_CALLBACK, (s), (l), (v), "when", (h), PARSE_OPT_OPTARG, \
parse_opt_color_flag_cb, (intptr_t)"always" }
-
+#define OPT_NOOP_NOARG(s, l) \
+ { OPTION_CALLBACK, (s), (l), NULL, NULL, \
+ "no-op (backward compatibility)", \
+ PARSE_OPT_HIDDEN | PARSE_OPT_NOARG, parse_opt_noop_cb }
/* parse_options() will filter out the processed options and leave the
* non-option arguments in argv[].
@@ -210,6 +213,7 @@ extern int parse_opt_verbosity_cb(const struct option *, const char *, int);
extern int parse_opt_with_commit(const struct option *, const char *, int);
extern int parse_opt_tertiary(const struct option *, const char *, int);
extern int parse_opt_string_list(const struct option *, const char *, int);
+extern int parse_opt_noop_cb(const struct option *, const char *, int);
#define OPT__VERBOSE(var, h) OPT_BOOLEAN('v', "verbose", (var), (h))
#define OPT__QUIET(var, h) OPT_BOOLEAN('q', "quiet", (var), (h))
diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 007f39d..a1e4616 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -87,7 +87,7 @@ EOF
test_expect_success 'long options' '
test-parse-options --boolean --integer 1729 --boolean --string2=321 \
--verbose --verbose --no-dry-run --abbrev=10 --file fi.le\
- > output 2> output.err &&
+ --obsolete > output 2> output.err &&
test ! -s output.err &&
test_cmp expect output
'
diff --git a/test-parse-options.c b/test-parse-options.c
index 91a5701..36487c4 100644
--- a/test-parse-options.c
+++ b/test-parse-options.c
@@ -54,6 +54,7 @@ int main(int argc, const char **argv)
OPT_STRING(0, "string2", &string, "str", "get another string"),
OPT_STRING(0, "st", &string, "st", "get another string (pervert ordering)"),
OPT_STRING('o', NULL, &string, "str", "get another string"),
+ OPT_NOOP_NOARG(0, "obsolete"),
OPT_SET_PTR(0, "default-string", &string,
"set string to default", (unsigned long)"default"),
OPT_STRING_LIST(0, "list", &list, "str", "add str to list"),
--
1.7.7.rc2
^ permalink raw reply related
* Re: SVN -> Git *but* with special changes
From: Matthieu Moy @ 2011-09-28 17:44 UTC (permalink / raw)
To: Stephen Bash; +Cc: Abscissa, git
In-Reply-To: <16808473.33899.1317229852319.JavaMail.root@mail.hq.genarts.com>
Stephen Bash <bash@genarts.com> writes:
>> 2. Keeping binary files in version control isn't a big deal because
>> the whole repo doesn't get copied to everyone's system or use up
>> people's GitHub storage space.
>
> I'd eliminate these on the SVN side before converting to Git. If you
> have svnadmin access to the SVN repo svnadmin dump, svndumpfilter,
> svnadmin load is a pretty easy process.
Otherwise, you can do it on the Git side with:
git filter-branch --tree-filter 'rm -f some-large-blob'
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH 2/3] revert: use OPT_NOOP_NOARG
From: René Scharfe @ 2011-09-28 17:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Pierre Habouzit
In-Reply-To: <4E835CFE.7020501@lsrfire.ath.cx>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
builtin/revert.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index 3117776..db5b1d4 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -72,12 +72,10 @@ static int option_parse_x(const struct option *opt,
static void parse_args(int argc, const char **argv)
{
const char * const * usage_str = revert_or_cherry_pick_usage();
- int noop;
struct option options[] = {
OPT_BOOLEAN('n', "no-commit", &no_commit, "don't automatically commit"),
OPT_BOOLEAN('e', "edit", &edit, "edit the commit message"),
- { OPTION_BOOLEAN, 'r', NULL, &noop, NULL, "no-op (backward compatibility)",
- PARSE_OPT_NOARG | PARSE_OPT_HIDDEN, NULL, 0 },
+ OPT_NOOP_NOARG('r', NULL),
OPT_BOOLEAN('s', "signoff", &signoff, "add Signed-off-by:"),
OPT_INTEGER('m', "mainline", &mainline, "parent number"),
OPT_RERERE_AUTOUPDATE(&allow_rerere_auto),
--
1.7.7.rc2
^ permalink raw reply related
* [PATCH 3/3] apply: use OPT_NOOP_NOARG
From: René Scharfe @ 2011-09-28 17:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Pierre Habouzit
In-Reply-To: <4E835CFE.7020501@lsrfire.ath.cx>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
builtin/apply.c | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index f2edc52..872e40a 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3831,7 +3831,6 @@ int cmd_apply(int argc, const char **argv, const char *prefix_)
int i;
int errs = 0;
int is_not_gitdir = !startup_info->have_repository;
- int binary;
int force_apply = 0;
const char *whitespace_option = NULL;
@@ -3850,12 +3849,8 @@ int cmd_apply(int argc, const char **argv, const char *prefix_)
"ignore additions made by the patch"),
OPT_BOOLEAN(0, "stat", &diffstat,
"instead of applying the patch, output diffstat for the input"),
- { OPTION_BOOLEAN, 0, "allow-binary-replacement", &binary,
- NULL, "old option, now no-op",
- PARSE_OPT_HIDDEN | PARSE_OPT_NOARG },
- { OPTION_BOOLEAN, 0, "binary", &binary,
- NULL, "old option, now no-op",
- PARSE_OPT_HIDDEN | PARSE_OPT_NOARG },
+ OPT_NOOP_NOARG(0, "allow-binary-replacement"),
+ OPT_NOOP_NOARG(0, "binary"),
OPT_BOOLEAN(0, "numstat", &numstat,
"shows number of added and deleted lines in decimal notation"),
OPT_BOOLEAN(0, "summary", &summary,
--
1.7.7.rc2
^ permalink raw reply related
* Re: emacs as mergetool
From: Nick @ 2011-09-28 17:03 UTC (permalink / raw)
To: git; +Cc: thomas
In-Reply-To: <201109261821.28382.thomas@koch.ro>
On 26/09/11 17:21, Thomas Koch wrote:
> would you be so kind and give an emacs newbie (and vim refugee) a hint about
> using emacs as mergetool?
>
> - Which one? ediff vs. emerge (I don't bother learning, just give me the best)
I tend to use git.el - which provides the M-x git-status command - and therefore
ediff. It's not necessarily the best git interface, but I've been too lazy
learn anything else so far. git-status allows you to do basic git
adding/committing etc. and will show modification diffs.
Given a git-status buffer, a conflicted merge will show up with certain files in
red. You can then view the conflicted versions side-by-side positioning the
cursor over the conflicted file, and using the key-sequence 'd E' to start
interactive merges in ediff mode. Afterwards you have to save the buffers and
mark the file as 'resolved' in git-status ('r').
There are other things you can do in a git-status buffer. M-x describe-mode (C-h
m) and M-x describe-bindings (C-h b) will provide some idea.
> - I'd like to have a setup, where I can run mergetool with different options
> to
> - connect to a running emacs server
> - run emacs in X
> - or in the terminal (default)
git-status works with all the above. I don't use git-mergetool at all.
To keep things in one emacs session I sometimes use git directly in emacs shell
buffers. i.e.
- Run emacs
- Open the repo in dired: M-x find-file <path to your git repo>
- Invoke git-status: M-x git-status
- (do stuff)
- Open a shell M-x shell, M-x eshell, or M-x ansi-term
- (do more stuff)
> - Is it possible to resolve all conflicting files in one session instead of
> having emacs called again for every file?
As I said, I don't use git-mergetool, but git-status should allow most basic
things in fairly straightforward way. For anything more complicated (e.g. git
commit --amend, or git add --interactive) I open an shell in emacs.
If you tell git to use emacsclient as the editor, and then git commit and co.
will open an emacs buffer so you can invoke git from the command line without
leaving your emacs session. To do this:
- invoke: git config --global core.editor emacsclient
- in emacs: M-x server-start
(or add "(server-start)" to your ~/.emacs file)
At some point I might check out magit. I'd be interested to hear about
comparisons between git.el and the alternatives.
Cheers,
N
^ permalink raw reply
* Re: SVN -> Git *but* with special changes
From: Abscissa @ 2011-09-28 18:03 UTC (permalink / raw)
To: git
In-Reply-To: <16808473.33899.1317229852319.JavaMail.root@mail.hq.genarts.com>
>> 1. Directories can exist even if there's nothing in them (just like
>> any filesystem).
>
>What requires the empty directories to exist? The build system?
Yes.
>Can you just let them go away in Git and fix it downstream in the user's
working copy?
That won't work retroactively for already-existing revisions. I'd rather not
break the build system for older revisions just for such a goofy reason as
empty dirs being deemed unnecessary.
--
View this message in context: http://git.661346.n2.nabble.com/SVN-Git-but-with-special-changes-tp6840904p6841234.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Docs: git checkout --orphan: `root commit' and `branch head'
From: Junio C Hamano @ 2011-09-28 18:17 UTC (permalink / raw)
To: Matthieu Moy
Cc: Michael Witten, Jeff King, Philip Oakley, Eric Raible,
Michael J Gruber, Carlos Martín Nieto, vra5107, git
In-Reply-To: <vpq4nzwoj1o.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Michael Witten <mfwitten@gmail.com> writes:
>
>> Well, as Junio mentioned, "--orphan" could be deprecated in favor of
>> "--no-parent"; the uncommon nature of this task works to our
>> advantage, in that it makes a deprecation of "--orphan" easy.
>
> I agree that _some_ cases would be more natural with commit --no-parent,
> but I disagree that it is a better solution in general.
Just for the record, in my later message after reading Peff's response, I
said I agree that adding it to "commit" would be a mistake.
^ permalink raw reply
* Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch
From: Junio C Hamano @ 2011-09-28 18:50 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git
In-Reply-To: <1317225869.30267.18.camel@bee.lab.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
> Whilst trying to do some work related to fetch, I came across a
> regression in the 'next' branch....
>
> $ ./git-fetch git://repo.or.cz/git
That invocation of ./git-fetch looks suspicious.
Are you sure that it internally invokes ./git-rev-list from the same
version that knows --verify-objects option (you just built in your current
directory), or is it invoking an old git-rev-list that is installed and is
reachable from your usual $PATH, which does not know that option yet?
When I try a new version that was just built in my current directory, here
is an incantation I use:
GIT_EXEC_PATH=`pwd`
PATH=`pwd`:/usr/bin:/bin
GITPERLLIB=`pwd`/perl/blib/lib
export GIT_EXEC_PATH PATH GITPERLLIB
^ permalink raw reply
* Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch
From: Jeff King @ 2011-09-28 18:53 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Junio C Hamano, git
In-Reply-To: <1317225869.30267.18.camel@bee.lab.cmartin.tk>
On Wed, Sep 28, 2011 at 06:04:27PM +0200, Carlos Martín Nieto wrote:
> Whilst trying to do some work related to fetch, I came across a
> regression in the 'next' branch. Bisecting gave me this commit as
> breaking point (and I tried with the parent and there it worked). When
> doing 'git fetch', rev-list will complain about usage, and fetch will
> say that we didn't receive enough, even though earlier versions of git
> have no problems. This fails both on github and on git.or.cz and for git
> and http transports:
>
> $ ./git-fetch git://repo.or.cz/git
> usage: git rev-list [OPTION] <commit-id>... [ -- paths... ]
Hmm. I notice you're running a not-installed version of fetch. Might
this be a problem with a new git fetch running an older, installed
version of rev-list?
The commit you mention calls rev-list with --verify-objects, but that
feature is only added in the parent commit. So I can reproduce your
issue with:
$ git checkout 6d4bb38~2 ;# or anything before --verify-objects
$ make install
$ git checkout 6d4bb38
$ make
$ ./git-fetch git://repo.or.cz/git
but this works (because it sets the exec path properly):
$ ./bin-wrappers/git fetch git://repo.or.cz/git
as does this:
$ make install
$ ./git-fetch git://repo.or.cz/git
So I don't think there's a bug. It's just that running compiled programs
straight out of the build directory isn't supported. It works _most_ of
the time, but as you can see, you may end up calling older, installed
versions of git. The bin-wrappers scripts set up the exec path properly
to let you test.
-Peff
^ permalink raw reply
* Re: SVN -> Git *but* with special changes
From: Jeff King @ 2011-09-28 19:04 UTC (permalink / raw)
To: Abscissa; +Cc: git
In-Reply-To: <1317227849979-6840904.post@n2.nabble.com>
On Wed, Sep 28, 2011 at 09:37:29AM -0700, Abscissa wrote:
> I have a couple big projects in SVN that I'd like to convert to Git. Being in
> SVN, they've operated under a couple assumptions that are not true under
> Git. These assumptions are:
>
> 1. Directories can exist even if there's nothing in them (just like any
> filesystem).
The usual technique is to put an empty .gitignore file into the empty
directory, which will make sure it always exists. If you import with
git-svn, it supports "--preserve-empty-dirs", which will do this for you
automatically.
> 2. Keeping binary files in version control isn't a big deal because the
> whole repo doesn't get copied to everyone's system or use up people's GitHub
> storage space.
git-svn --ignore-paths will handle this for you.
Side note on the GitHub thing: all of the forks will share objects, so
it's not much as space as you might think. And all of the paid plans
count repos, not bytes. Of course, the painful part is probably cloning
the big objects to everybody's workstation. :)
> (Also, there are tags and branches to be converted too, in the
> SVN-standard "tags" and "branches" directories.)
git svn --stdlayout ?
-Peff
^ permalink raw reply
* Re: SVN -> Git *but* with special changes
From: Jeff King @ 2011-09-28 19:07 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Stephen Bash, Abscissa, git
In-Reply-To: <vpq62kc36kn.fsf@bauges.imag.fr>
On Wed, Sep 28, 2011 at 07:44:24PM +0200, Matthieu Moy wrote:
> > I'd eliminate these on the SVN side before converting to Git. If you
> > have svnadmin access to the SVN repo svnadmin dump, svndumpfilter,
> > svnadmin load is a pretty easy process.
>
> Otherwise, you can do it on the Git side with:
>
> git filter-branch --tree-filter 'rm -f some-large-blob'
It's much more efficient to do:
git filter-branch --index-filter \
'git rm --cached --ignore-unmatch some-large-blob'
which avoids checking out the large files over and over[1], just to
delete them. Of course, it's even more efficient not to import them from
svn in the first place. :)
-Peff
[1] This is straight from the filter-branch manpage, btw.
^ permalink raw reply
* Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch
From: Jakub Narebski @ 2011-09-28 19:12 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Junio C Hamano, git
In-Reply-To: <1317225869.30267.18.camel@bee.lab.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
> Hello,
>
> Whilst trying to do some work related to fetch, I came across a
> regression in the 'next' branch. Bisecting gave me this commit as
> breaking point (and I tried with the parent and there it worked). When
> doing 'git fetch', rev-list will complain about usage, and fetch will
> say that we didn't receive enough, even though earlier versions of git
> have no problems. This fails both on github and on git.or.cz and for git
> and http transports:
>
> $ ./git-fetch git://repo.or.cz/git
Have you tried
$ ./git fetch git://repo.or.cz/git
?
--
Jakub Narębski
^ permalink raw reply
* Re: Re* [PATCH 2/2] grep --no-index: don't use git standard exclusions
From: Bert Wesarg @ 2011-09-28 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vty7xwrsf.fsf_-_@alter.siamese.dyndns.org>
On Wed, Sep 28, 2011 at 00:21, Junio C Hamano <gitster@pobox.com> wrote:
> Bert Wesarg <bert.wesarg@googlemail.com> writes:
>
>> Would '--untracked-too' only be a synonym for '--no-index
>> --exclude-standard', i.e. the current behavior?
>
> That basically would be the idea. Perhaps something like this on top of
> a9e6436 (grep --no-index: don't use git standard exclusions, 2011-09-15).
>
> -- >8 --
> Subject: [PATCH 1/2] grep: teach --untracked and --exclude options
I would still vote to name the option --exclude-standard, like it is
done in 'git ls-files'. Which also has a --exclude=<pattern> option.
And I think a --exclude=<pattern> option would be useful for 'git
grep', too.
Else:
Acked-by: Bert Wesarg <bert.wesarg@googlemail.com>
Thanks.
Bert
>
> In a working tree of a git managed repository, "grep --untracked" would
> find the specified patterns from files in untracked files in addition to
> its usual behaviour of finding them in the tracked files.
>
> By default, when working with "--no-index" option, "grep" does not pay
> attention to .gitignore mechanism. "grep --no-index --exclude" can be
> used to tell the command to use .gitignore and stop reporting hits from
> files that would be ignored. Also, when working without "--no-index",
> "grep" honors .gitignore mechanism, and "grep --no-exclude" can be used
> to tell the command to include hits from files that are ignored.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> Documentation/git-grep.txt | 15 ++++++++++++++-
> builtin-grep.c | 25 ++++++++++++++++++-------
> 2 files changed, 32 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
> index e019e76..2ccfb90 100644
> --- a/Documentation/git-grep.txt
> +++ b/Documentation/git-grep.txt
> @@ -9,7 +9,7 @@ git-grep - Print lines matching a pattern
> SYNOPSIS
> --------
> [verse]
> -'git grep' [--cached]
> +'git grep' [--cached] [--untracked] [--excludes]
> [-a | --text] [-I] [-i | --ignore-case] [-w | --word-regexp]
> [-v | --invert-match] [-h|-H] [--full-name]
> [-E | --extended-regexp] [-G | --basic-regexp]
> @@ -36,6 +36,19 @@ OPTIONS
> Instead of searching in the working tree files, check
> the blobs registered in the index file.
>
> +--untracked::
> + In addition to searching in the tracked files in the working
> + tree, search also in untracked files.
> +
> +--no-excludes::
> + Also search in ignored files by not honoring the `.gitignore`
> + mechanism. Only useful with `--untracked`.
> +
> +--excludes::
> + Do not pay attention to ignored files specified via the `.gitignore`
> + mechanism. Only useful when searching files in the current directory
> + with `--no-index`.
> +
> -a::
> --text::
> Process binary files as if they were text.
> diff --git a/builtin-grep.c b/builtin-grep.c
> index a10946d..c6cfdf8 100644
> --- a/builtin-grep.c
> +++ b/builtin-grep.c
> @@ -646,12 +646,14 @@ static int grep_object(struct grep_opt *opt, const char **paths,
> die("unable to grep from object of type %s", typename(obj->type));
> }
>
> -static int grep_directory(struct grep_opt *opt, const char **paths)
> +static int grep_directory(struct grep_opt *opt, const char **paths, int exc_std)
> {
> struct dir_struct dir;
> int i, hit = 0;
>
> memset(&dir, 0, sizeof(dir));
> + if (exc_std)
> + setup_standard_excludes(&dir);
>
> fill_directory(&dir, paths);
> for (i = 0; i < dir.nr; i++) {
> @@ -749,7 +751,7 @@ static int help_callback(const struct option *opt, const char *arg, int unset)
> int cmd_grep(int argc, const char **argv, const char *prefix)
> {
> int hit = 0;
> - int cached = 0;
> + int cached = 0, untracked = 0, opt_exclude = -1;
> int seen_dashdash = 0;
> int external_grep_allowed__ignored;
> struct grep_opt opt;
> @@ -764,6 +766,10 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
> { OPTION_BOOLEAN, 0, "index", &use_index, NULL,
> "finds in contents not managed by git",
> PARSE_OPT_NOARG | PARSE_OPT_NEGHELP },
> + OPT_BOOLEAN(0, "untracked", &untracked,
> + "search in both tracked and untracked files"),
> + OPT_SET_INT(0, "exclude", &opt_exclude,
> + "search also in ignored files", 1),
> OPT_GROUP(""),
> OPT_BOOLEAN('v', "invert-match", &opt.invert,
> "show non-matching lines"),
> @@ -950,18 +956,23 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
> paths[1] = NULL;
> }
>
> - if (!use_index) {
> + if (!use_index && (untracked || cached))
> + die("--cached or --untracked cannot be used with --no-index.");
> +
> + if (!use_index || untracked) {
> int hit;
> - if (cached)
> - die("--cached cannot be used with --no-index.");
> + int use_exclude = (opt_exclude < 0) ? use_index : !!opt_exclude;
> if (list.nr)
> - die("--no-index cannot be used with revs.");
> - hit = grep_directory(&opt, paths);
> + die("--no-index or --untracked cannot be used with revs.");
> + hit = grep_directory(&opt, paths, use_exclude);
> if (use_threads)
> hit |= wait_all();
> return !hit;
> }
>
> + if (0 <= opt_exclude)
> + die("--exclude or --no-exclude cannot be used for tracked contents.");
> +
> if (!list.nr) {
> int hit;
> if (!cached)
> --
> 1.7.7.rc3.4.g8d714
>
>
>
^ 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