* Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?
From: Daniel Barkalow @ 2009-11-24 20:45 UTC (permalink / raw)
To: Adrian May; +Cc: tytso, git, chromium-discuss
In-Reply-To: <65e170e70911231948l3b032dbeu7c99b65ce3ec97ff@mail.gmail.com>
On Tue, 24 Nov 2009, Adrian May wrote:
> > If you don't have bolt-on scripts, and you move that into the the core
> > SCM, then you force *all* projects to use whatever workflow was
> > decided as being the One True Way of doing things as seen by the SCM
> > designer. So the question is whether the SCM *should* regiment all
> > projects into following the SCM's designers idea of the One True
> > Workflow.
>
> Of course I'd want the workflow configurable by whoever controls the
> main repository. I couldn't possibly suggest that all git projects
> need the same workflow. The number of developers can vary by five
> orders of magnitude - that calls for different workflow models.
>
> > Git's approach is to say that it will be fairly flexible about
> > dictating workflow --- who pushs to whom; whether there is a single
> > "star" repository topology, or something that is more flexible, etc.
> > You seem to hate this flexibility, because it makes life harder until
> > you set up these bolt-on scripts. But that's what many of us like
> > about git; that it doesn't force us (the project lead) into a single
> > way of doing things.
>
> Leaving aside topology, I suppose we can agree that the subject
> divides into two aspects: offering the developer some optional tools,
> and asserting control over what gets commited to the official repo.
> Perhaps we can also agree that the former belongs under the control of
> the developer and the latter should be in the PM's hands. You seem to
> have opinions about which of these two aspects is more or less
> important, and to what extent git suffices, but I don't. I assume that
> the project manager has his own opinions about both aspects and I'm
> observing two big projects that independantly have augmented git's
> features with their own scripts. Their docs talk about both aspects,
> especially repo's, but they are entirely implemented in
> developer-overridable scripts. So any repo functions to do with the
> second aspect are either features that git needs to grow, or bits of
> the git manual that the repo designer didn't read. I'd kinda like to
> know which.
Repo (and gclient, which claims to be for SVN) seems to be mostly about
the fact that nothing really handles submodules (independant projects that
are also parts of larger projects) well. This is a known flaw with git,
but it's unclear as to whether repo does better. It's probably best to let
them work out a set of semantics which a real-world, full-scale project is
happy with, and consider adopting it for native submodules when there's
real-world positive experience behind it.
The other main thing I see repo doing is interfacing with gerrit, where
your pushes get redirected, and there are a million review branches you
can find on a web site, and where the server for a push is different from
the best server for a mainline fetch. Some of this is probably worth
having natively, but there's still the case of wanting to fetch a review
branch based on understanding stuff about gerrit. This is similar to
wanting to get a SVN revision out of bugzilla; you really want a tool
that's particular to the integration of the systems you're using, not
stuff built into your version control system. That said, if the submodule
stuff were taken care of, Google could provide a git-review program, and
do everything within the "git ..." wrapper instead of as an outer script.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* git-subtree: directory mismatch
From: Marc Fournier @ 2009-11-24 19:53 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git
Hi,
I've come across this weird behaviour using git-subtree: when updating a
directory created by git-subtree, the content of some (almost) random
neighbour directory gets replaced, instead of the directory specified by
"git-subtree --prefix".
mkdir /tmp/testrepo
cd /tmp/testrepo
git init .
mkdir -p modules/cognac/{manifests,files}
mkdir -p modules/cognac/manifests/{classes,definitions}
touch modules/cognac/README modules/cognac/manifests/classes/foo.pp
modules/cognac/manifests/definitions/bar.pp modules/cognac/files/blabla
git add modules/
git commit -m "test"
git remote add mapserver git://github.com/camptocamp/puppet-mapserver.git
git remote update
git-subtree add --prefix modules/mapserver 97f5985b # an older commit
# So far so good, I have 2 subdirectories in modules/ with completely
# different content.
# Then, the content of modules/cognac/ gets completely replaced by the
# content of HEAD from git://github.com/camptocamp/puppet-mapserver.git.
# modules/mapserver still contains the content of commit 97f5985b.
git-subtree pull --prefix modules/mapserver mapserver master
>From git://github.com/camptocamp/puppet-mapserver
* branch master -> FETCH_HEAD
Removing modules/cognac/files/blabla
Removing modules/cognac/manifests/classes/foo.pp
Removing modules/cognac/manifests/definitions/bar.pp
Merge made by subtree.
modules/cognac/files/apt-preferences | 3 +
modules/cognac/files/epsg.C2C | 5445 ++++++++++++++++++++
modules/cognac/files/epsg.legacy | 5445 ++++++++++++++++++++
modules/cognac/files/epsg.minimal | 14 +
modules/cognac/files/etc/apt/preferences-20070910 | 3 +
modules/cognac/files/etc/apt/preferences-20080225 | 35 +
modules/cognac/files/etc/apt/preferences-v5-2 | 35 +
modules/cognac/manifests/classes/epsg.pp | 21 +
.../cognac/manifests/classes/mapserver-debian.pp | 82 +
modules/cognac/manifests/classes/v5.pp | 46 +
modules/cognac/manifests/init.pp | 8 +
11 files changed, 11137 insertions(+), 0 deletions(-)
create mode 100644 modules/cognac/files/apt-preferences
delete mode 100644 modules/cognac/files/blabla
create mode 100755 modules/cognac/files/epsg.C2C
create mode 100755 modules/cognac/files/epsg.legacy
create mode 100644 modules/cognac/files/epsg.minimal
create mode 100644 modules/cognac/files/etc/apt/preferences-20070910
create mode 100644 modules/cognac/files/etc/apt/preferences-20080225
create mode 100644 modules/cognac/files/etc/apt/preferences-v5-2
create mode 100644 modules/cognac/manifests/classes/epsg.pp
delete mode 100644 modules/cognac/manifests/classes/foo.pp
create mode 100644 modules/cognac/manifests/classes/mapserver-debian.pp
create mode 100644 modules/cognac/manifests/classes/v5.pp
delete mode 100644 modules/cognac/manifests/definitions/bar.pp
create mode 100644 modules/cognac/manifests/init.pp
I was not able to reproduce this bug in any of the following cases:
- if the README file wasn't empty
- if modules/cognac is renamed to something else
- if modules/cognac doesn't have the same sub-directories than
modules/mapserver
This bug happens using git 1.5.5.6 as well as 1.6.5. It seems to happen
when git-subtree calls "git merge -s subtree".
Maybe something is broken in this puppet-mapserver.git repository I use ?
I've encountered the same problem with other directories too.
Any idea ?
Thanks !
Marc
^ permalink raw reply
* Re: [PATCH] git-count-objects: Fix a disk-space under-estimate on Cygwin
From: Ramsay Jones @ 2009-11-24 20:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
In-Reply-To: <7veinrnym4.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
>
>> I haven't tried this patch, but I think you may need to add something like
>> the following (*not tested*):
>>
>> --- >8 ---
>> diff --git a/compat/cygwin.c b/compat/cygwin.c
>> index b4a51b9..7e9edec 100644
>> --- a/compat/cygwin.c
>> +++ b/compat/cygwin.c
>> @@ -53,6 +53,7 @@ static int do_stat(const char *file_name, struct stat *buf, stat_fn_t cygstat)
>> buf->st_size = (off_t)fdata.nFileSizeLow;
>> #endif
>> buf->st_blocks = size_to_blocks(buf->st_size);
>> + buf->st_blksize = 512;
>> filetime_to_timespec(&fdata.ftLastAccessTime, &buf->st_atim);
>> filetime_to_timespec(&fdata.ftLastWriteTime, &buf->st_mtim);
>> filetime_to_timespec(&fdata.ftCreationTime, &buf->st_ctim);
>> --- >8 ---
>
> Doesn't this contradict with everything you said?
Err... no :-D
Note that my suggested addition to your patch is in the core.filemode == false
code path, and so does not affect the "disk-space under-estimate" problem at all.
[To be clear: the "disk-space under-estimate" problem only happens when
core.filemode == true and the regular cygwin lstat()/stat() functions are used.
When core.filemode == false, the code in compat/cygwin.c (namely cygwin_lstat()
and cygwin_stat()) will (most likely) be called instead. These functions use
WIN32 api calls to implement equivalent, but presumably faster, versions of the
stat functions]
> You are forcing st_blksize to 512 but still return the same old st_blocks;
> I do not understand what that would achieve.
Well, as I said, I haven't tested your patch, or my suggested addition, so I could
well be wrong... but what I aimed to achieve was to:
- avoid "undefined behaviour" in on_disk_bytes(), since the value in
st_blksize would otherwise be undefined (ie whatever happened to be
on the stack-frame of the count_objects() function).
- initialize the st_blksize field with a value consistent with the
st_blocks field, which is derived from the st_size field, as the
number of 512-byte blocks. (see the context line just before the
+ line in the above diff, along with the size_to_blocks macro)
- return the same answer from this code as before.
Note that the answer returned from this core.filemode == false code path
is different to the core.filemode == true code path. Which is why I *slightly*
prefer my original patch.
HTH.
ATB,
Ramsay Jones
^ permalink raw reply
* Re: git tag listing order
From: Peter van der Does @ 2009-11-24 19:24 UTC (permalink / raw)
To: git
In-Reply-To: <20091124185947.GA24409@coredump.intra.peff.net>
On Tue, 24 Nov 2009 14:00:23 -0500
Jeff King <peff@peff.net> wrote:
> On Tue, Nov 24, 2009 at 10:56:09AM -0500, Peter van der Does wrote:
>
> > I'm using git 1.6.5.3 on Ubuntu and was wondering if there is a way
> > to list tags in order of when they were added to the tree, instead
> > of alphabetical?
>
> You can use for-each-ref with its sort option:
>
> git for-each-ref --sort=taggerdate --format='%(refname:short)'
> refs/tags
>
> Though note that unannotated tags will have no taggerdate, and will
> all sort to the front of the list. To exclude them, I think you'd
> have to use a special format to grep and sort yourself. Something
> like:
>
> git for-each-ref \
> --format='%(taggerdate:iso8601) %(refname:short)' refs/tags |
> grep -v '^ ' |
> sort |
> cut -d' ' -f4-
>
> -Peff
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks for the info, just what I was looking for.
--
Peter van der Does
GPG key: E77E8E98
Twitter: @petervanderdoes
git Ubuntu Packages:
http://blog.avirtualhome.com/git-packages-for-ubuntu/
^ permalink raw reply
* Re: [PATCH RFC] git-send-email --expand-aliases
From: Karl Wiberg @ 2009-11-24 19:08 UTC (permalink / raw)
To: Alex Chiang; +Cc: Catalin Marinas, Junio C Hamano, git
In-Reply-To: <20091124184629.GB27418@ldl.fc.hp.com>
On Tue, Nov 24, 2009 at 7:46 PM, Alex Chiang <achiang@hp.com> wrote:
> * Catalin Marinas <catalin.marinas@gmail.com>:
>
> > If there are no other users of the stg mail templates, I'm happy
> > to let them go. Otherwise, we can replace the sendmail with
> > git-send-email in stgit.
> >
> > It seems that git-format-patch and git-send-email have all the
> > features stgit has. We would need to keep some of the interactive
> > options like --edit-cover and --edit-patches since we use
> > git-format-patch and git-send-email in one go.
>
> So, is this something you (or Karl) plan on doing? Or should I take
> a crack at it?
I wasn't planning to do it, at least. I haven't had much time for
StGit lately, but when I do there are other things I was planning to
fix before this.
If you feel like trying, please go ahead. I'll be happy to assist.
> I don't mind doing the work, but it will definitely take me longer
> than it would take you.
>
> All I was doing was trying to get stg mail to understand my mutt
> aliases. ;)
Yeah, sorry about that. ;-)
Seriously, though, doing just what you started out wanting to do would
be fine too. If you decide to do the larger project, it shouldn't be
because we made you feel you had to.
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Private remote repo setup
From: Derek D @ 2009-11-24 19:04 UTC (permalink / raw)
To: git
Hi all, I am new to Git and I am getting quite frustrated with setting a repo
on my server so that people with Windows machines can ssh to it and contribute.
This is what I am doing:
On the server:
#git --bare init
Initialized empty Git repository in /opt/apps/git-test/
In tortoiseGIT I go to git clone, provide correct url:
ssh://user@domain/opt/apps/git-test/
tortoiseGIT asks me for a password, I provide it, it's correct, the repository
gets created on the local machine and...
fatal: '/opt/apps/git-test': unable to chdir or not a git archive
Initialized empty Git repository in C:/path/.git/
fatal: The remote end hung up unexpectedly
Failed
What happened there?
^ permalink raw reply
* Re: git tag listing order
From: Jeff King @ 2009-11-24 19:00 UTC (permalink / raw)
To: Peter van der Does; +Cc: git
In-Reply-To: <20091124105609.0980e796@montecarlo.grandprix.int>
On Tue, Nov 24, 2009 at 10:56:09AM -0500, Peter van der Does wrote:
> I'm using git 1.6.5.3 on Ubuntu and was wondering if there is a way to
> list tags in order of when they were added to the tree, instead of
> alphabetical?
You can use for-each-ref with its sort option:
git for-each-ref --sort=taggerdate --format='%(refname:short)' refs/tags
Though note that unannotated tags will have no taggerdate, and will all
sort to the front of the list. To exclude them, I think you'd have to
use a special format to grep and sort yourself. Something like:
git for-each-ref \
--format='%(taggerdate:iso8601) %(refname:short)' refs/tags |
grep -v '^ ' |
sort |
cut -d' ' -f4-
-Peff
^ permalink raw reply
* Re: [PATCH RFC] git-send-email --expand-aliases
From: Alex Chiang @ 2009-11-24 18:46 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Wiberg, Junio C Hamano, git
In-Reply-To: <b0943d9e0911240243m13730f0bw34f2f18cf41f9079@mail.gmail.com>
* Catalin Marinas <catalin.marinas@gmail.com>:
> 2009/11/24 Karl Wiberg <kha@treskal.com>:
> > On Tue, Nov 24, 2009 at 1:45 AM, Alex Chiang <achiang@hp.com> wrote:
> >> * Junio C Hamano <gitster@pobox.com>:
> >> > I imagine the internal implementation of stg mail would work
> >> > something like:
> >> >
> >> > prepare messages to send out
> >> > call git-send-email and have it send them
> >> >
> >> > What am I missing?
> >>
> >> Your suggestion is much better. I'll take a closer look at StGit and
> >> see how feasible it is.
> >>
> >> Unless Catalin has strong objections?
> >
> > I think that sounds like a splendid idea. It would be interesting to
> > see just how thin a wrapper around git send-email (and format-patch)
> > stg mail could become, without sacrificing features anyone actually
> > uses. The main complication could be stg mail's templates.
> >
> > Catalin, how wedded are you to those? ;-)
>
> Historically, I think "stg mail" was implemented before git-send-email
> existed. It was also a good way to check who's using stgit for sending
> patches :-) (the message-id).
Heh, I like looking at that too. ;)
> If there are no other users of the stg mail templates, I'm happy to
> let them go. Otherwise, we can replace the sendmail with
> git-send-email in stgit.
>
> It seems that git-format-patch and git-send-email have all the
> features stgit has. We would need to keep some of the interactive
> options like --edit-cover and --edit-patches since we use
> git-format-patch and git-send-email in one go.
So, is this something you (or Karl) plan on doing? Or should I
take a crack at it?
I don't mind doing the work, but it will definitely take me
longer than it would take you.
All I was doing was trying to get stg mail to understand my mutt
aliases. ;)
Thanks,
/ac
^ permalink raw reply
* Re: [PATCH] send-email: new 'add-envelope' option
From: Felipe Contreras @ 2009-11-24 17:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7v7htice04.fsf@alter.siamese.dyndns.org>
On Mon, Nov 23, 2009 at 1:54 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> a) --add-envelope: add the sender envelope, by default it would be the
>> 'from' address, but could be overridden by --envelope-sender.
>
> I do not think the latter half of this description makes much sense, as
> the existing --envelope-sender=<this-address> alone already says "add this
> envelope sender".
--envelope-sender=foo@bar.com would imply --add-envelope.
> It is unfortunate that we cannot sanely have an option that takes an
> optional string argument from the command line. Ideally, if we can
> specify --envelope-sender without any argument, we could make it to mean
> "pretend as if the 'from' address is given to this option", but that would
> make the command line pasing ambiguous, so we would need an extra option
> like this one. "--envelope-sender=from" might be a more intuitive way to
> say this, though.
I agree, but --envelope-sender=from looks a bit strange to me.
>> b) --envelope-sender="" or "auto": this would require minimal changes
>> but looks a bita strange.
>
> An explicit empty string does look very strange, but I do not think a
> magic word like "auto" (or "from") that cannot sanely be your envelope
> sender address is a bad idea.
I think "auto" is the least worst option right now.
>> Any thoughts?
>
> It is much easier to work on the configuration front, by the way, and I
> expect people who regularly interact with multiple projects to appreciate
> this feature would configure their send-email once and forget about it, so
> the command line clunkiness might not be such a big issue.
>
> A user who works with more than one projects with different identity known
> to each project would use $HOME/.gitconfig and send-email configuration
> identity feature to set "sendemail.<identity>.from" and friends in there,
> while setting sendemail.identity configuration in .git/config for each
> project, so being able to say "use whatever 'from' as the envelope sender"
> once in $HOME/.gitconfig would be convenient.
>
> So I could have in $HOME/.gitconfig:
>
> [sendemail]
> ; used as a boolean to say "use from"
> envelopesender
> [sendemail.git]
> from = Junio C Hamano <gitster@pobox.com>
> to = git mailing list <git@vger.kernel.org>
> [sendemail.frotz]
> from = Junio C Hamano <frotzster@example.xz>
> to = frotz mailing list <frotz@example.xz>
>
> and then in my {git,frotz}.git/.git/config would have
>
> [sendemail] [sendemail]
> identity = git identity = frotz
>
> respectively. Without your patch, in $HOME/.gitconfig, I wouldn't have
> the global sendemail.envelopesender but have separate individual
> configuration variables sendemail.{git,frotz}.envelopesender defined.
I also thought about having an identity (profile) for sendmail; it
would be very useful to specify the smtp server, aliases file, and
from address that multiple repositories can share and can be easily
changed (working for my company vs working for myself).
However, even in this case I would like to have a global option to add
the sender automatically from the 'from' address.
--
Felipe Contreras
^ permalink raw reply
* git tag listing order
From: Peter van der Does @ 2009-11-24 15:56 UTC (permalink / raw)
To: git
I'm using git 1.6.5.3 on Ubuntu and was wondering if there is a way to
list tags in order of when they were added to the tree, instead of
alphabetical?
--
Peter van der Does
GPG key: E77E8E98
Twitter: @petervanderdoes
git Ubuntu Packages:
http://blog.avirtualhome.com/git-packages-for-ubuntu/
^ permalink raw reply
* Git over cvs
From: Michael J Gruber @ 2009-11-24 17:07 UTC (permalink / raw)
To: Git Mailing List
Hi there,
I got so annoyed by (my own incompetence using) cvs on mozdev that I got
myself to use git cvsimport/cvsexportcommit now, just shortly before it
gets obsoleted by the new shiny remote helpers, and knowing how many
failing tests we have for it now.
Setting up a convenient roundtrip with minimal exposure to cvs required
collecting some scattered info. I thought this makes a good first blog
entry (the one after the zeroth) for reference, so in case anyone is
interested:
http://grubix.blogspot.com/2009/11/git-over-cvs.html
I guess it does require some acquaintance with Git, that's intentional.
(In short it uses the combined work tree, -W approach.)
Cheers,
Michael
P.S.: There's AdSense on there. I assume you block it anyway using
NoScript, AdBlock etc. if you don't like it.
^ permalink raw reply
* Re: [PATCH] t/gitweb-lib: Split HTTP response with non-GNU sed
From: Jakub Narebski @ 2009-11-24 16:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Gernhardt, Git List
In-Reply-To: <7vocmtyu3v.fsf@alter.siamese.dyndns.org>
On Mon, 23 Nov 2009, Junio C Hamano wrote:
> Brian Gernhardt <brian@gernhardtsoftware.com> writes:
>
> > Recognizing \r in a regex is something GNU sed will do, but other sed
> > implementation's won't. (Found with BSD sed on OS X.) So use a
> > literal carriage return instead.
[...]
> > diff --git a/t/gitweb-lib.sh b/t/gitweb-lib.sh
> > index 32b841d..35dda58 100644
> > --- a/t/gitweb-lib.sh
> > +++ b/t/gitweb-lib.sh
> > @@ -52,8 +52,8 @@ gitweb_run () {
> > rm -f gitweb.log &&
> > perl -- "$SCRIPT_NAME" \
> > >gitweb.output 2>gitweb.log &&
> > - sed -e '/^\r$/q' <gitweb.output >gitweb.headers &&
> > - sed -e '1,/^\r$/d' <gitweb.output >gitweb.body &&
> > + sed -e '/^
> > $/q' <gitweb.output >gitweb.headers &&
> > + sed -e '1,/^
> > $/d' <gitweb.output >gitweb.body &&
> > if grep '^[[]' gitweb.log >/dev/null 2>&1; then false; else
> > true; fi
> > # gitweb.log is left for debugging
If we were to do it this way, I would prefer to set and then use
'cr' or 'crlf' variable (in sed expression).
>
> I'd actually prefer not having to deal with this issue. How about doing
> something like this instead?
>
> t/gitweb-lib.sh | 14 ++++++++++++--
> 1 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/t/gitweb-lib.sh b/t/gitweb-lib.sh
> index 32b841d..3121950 100644
> --- a/t/gitweb-lib.sh
> +++ b/t/gitweb-lib.sh
> @@ -52,8 +52,18 @@ gitweb_run () {
> rm -f gitweb.log &&
> perl -- "$SCRIPT_NAME" \
> >gitweb.output 2>gitweb.log &&
> - sed -e '/^\r$/q' <gitweb.output >gitweb.headers &&
> - sed -e '1,/^\r$/d' <gitweb.output >gitweb.body &&
> + perl -w -e '
"perl", or "$PERL", or "$PERL_PATH"?
> + open O, ">gitweb.headers";
Well, modern Perl would use here
+ open my $fh, ">", "gitweb.headers";
But it is not that important here.
> + while (<>) {
> + print O;
> + last if (/^\r$/ || /^$/);
> + }
> + open O, ">gitweb.body";
> + while (<>) {
> + print O;
> + }
> + close O;
> + ' gitweb.output &&
> if grep '^[[]' gitweb.log >/dev/null 2>&1; then false; else true; fi
>
> # gitweb.log is left for debugging
>
This is a good solution. We test Perl script anyway (so Perl is required
for running this test), and this way we can do this portably and in one
pass (one fork).
--
Jakub Narebski
Poland
^ permalink raw reply
* insecurity in verify-tag?
From: David Roundy @ 2009-11-24 16:56 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 2070 bytes --]
I've just been looking at the code and I see what looks like a (minor)
security hole in the verify-tag feature. In particular, the tag
verification code doesn't check that the tag is signed by the same
user that created the tag. To be fair, gpg does output the identity
of the key that created the signature as well as the key used to
create the signature, so an astute user could detect that some
shenanigans is going on.
An attack would simply require getting one's own public key into the
keyring of a user. This probably wouldn't be very easy at the moment,
but if people were to actually use encrypted email (and if they set
their mail agents to download public keys), it might require no more
then sending a signed email to a mailing list.
Of course, you'd also somehow have to trick them into pulling (or
cloning) your corrupt tag, which probably requires compromising a
server (or mirror) somewhere. But of course, the whole point of
signing tags is to eliminate precisely this danger.
What should be done about this? First, there ought to be a feature to
limit git verify-tag to use a specific keyring. Maybe there is an
environment variable, and it's just not documented in the man page?
It would also seem like a good idea to at a minimum check that the
name/email associated with the signature is the same as that of the
tagger. This doesn't gain you *too* much, since an attacker can
always create his own key with any name and email he likes, but at
least it means that users could feel safe adding keys to their public
keyring, as long as those keys have reasonable names/emails associated
with them, and as long as they run git show on a tag before trusting
that that tag came from a particular person. i.e. it seems reasonable
for me to expect that if I run:
$ git show v1.0
tag v1.0
Tagger: Linus Torvalds ...
...
[user carefully reads the Tagger line...]
$ git verify-tag v1.0 && make
That I won't be running make on a repository that wasn't signed by a
key that at least *claims* to belong to Linus Torvalds.
Thoughts?
--
David Roundy
[-- Attachment #2: tagtest.txt --]
[-- Type: text/plain, Size: 1496 bytes --]
mkdir temp
cd temp
git init
Initialized empty Git repository in /tmp/temp/.git/
date > foo
git add foo
export GIT_AUTHOR_NAME="Someone else"
export GIT_AUTHOR_EMAIL="notme@example.com"
export GIT_COMMITTER_NAME="Linus Torvalds"
export GIT_COMMITTER_EMAIL="linus@example.com"
git commit -m 'hello world'
Created initial commit dc3b7e9: hello world
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 foo
git tag -u droundy -m foo v1.0
gpg: Invalid passphrase; please try again ...
gpg: Invalid passphrase; please try again ...
git verify-tag v1.0
gpg: Signature made Tue 24 Nov 2009 11:41:49 AM EST using DSA key ID D3D5BCEC
gpg: Good signature from "David Roundy <roundyd@physics.oregonstate.edu>"
gpg: aka "David Roundy <droundy@darcs.net>"
gpg: aka "David Roundy <droundy@abridgegame.org>"
gpg: aka "David Roundy <daveroundy@gmail.com>"
git show v1.0
tag v1.0
Tagger: Linus Torvalds <linus@example.com>
Date: Tue Nov 24 11:41:49 2009 -0500
foo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEABECAAYFAksMDM0ACgkQQ6uZI9PVvOyXFQCgoc4UYfNFYzVH4HduLdh9VUc/
NSkAn05yr/ARnWGUC8I/OmjhZJEjG5Oa
=ro48
-----END PGP SIGNATURE-----
commit dc3b7e9f8f5c49bdfe8816abdb4bb392c30e3ef5
Author: Someone else <notme@example.com>
Date: Tue Nov 24 11:41:49 2009 -0500
hello world
diff --git a/foo b/foo
new file mode 100644
index 0000000..c1857fa
--- /dev/null
+++ b/foo
@@ -0,0 +1 @@
+Tue Nov 24 11:41:49 EST 2009
^ permalink raw reply related
* more problems with commit encoding [Was: [PATCH] shortlog: respect commit encoding]
From: Uwe Kleine-König @ 2009-11-24 16:08 UTC (permalink / raw)
To: git; +Cc: Jiri Kosina
In-Reply-To: <1259075555-7831-1-git-send-email-u.kleine-koenig@pengutronix.de>
Hello,
On Tue, Nov 24, 2009 at 04:12:35PM +0100, Uwe Kleine-König wrote:
> Before this change the author was taken from the raw commit without
> reencoding.
while at it, userformats have the same problem:
linux-2.6$ for rev in b71a8eb bc9be01; do git show --format=%an $rev | head -n1; git show $rev | grep Auth; done
Uwe Kleine-K�nig
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Uwe Kleine-König
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
That is, git show correctly reencodes its output for b71a8eb, but only
without --format=...
(The patches above are in linux-next.)
And now take this (assuming locale and commitencoding are utf-8):
git init
git config user.name 'Jöhännës Dschö'
echo spam > ham
git add ham
git commit -m 'initial commit'
git branch branch
echo more spam > ham
git add ham
git commit -m "Commitlog matching '\nencoding:'
encoding: latin1
"
git checkout branch
echo much more spam > ham
git add ham
git commit -C master
git show | grep Author:
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] shortlog: respect commit encoding
From: Uwe Kleine-König @ 2009-11-24 15:12 UTC (permalink / raw)
To: git; +Cc: Jiri Kosina
In-Reply-To: <20091111141342.GA1849@pengutronix.de>
Before this change the author was taken from the raw commit without
reencoding.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Jiri Kosina <jkosina@suse.cz>
---
builtin-shortlog.c | 25 +++++++++++++++----------
t/t4201-shortlog.sh | 24 ++++++++++++++++++++++++
2 files changed, 39 insertions(+), 10 deletions(-)
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index 8aa63c7..050bda8 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -139,14 +139,19 @@ static void read_from_stdin(struct shortlog *log)
void shortlog_add_commit(struct shortlog *log, struct commit *commit)
{
const char *author = NULL, *buffer;
+ struct strbuf buf = STRBUF_INIT;
+ struct strbuf ufbuf = STRBUF_INIT;
+ struct pretty_print_context ctx = {0};
- buffer = commit->buffer;
+ pretty_print_commit(CMIT_FMT_RAW, commit, &buf, &ctx);
+
+ buffer = buf.buf;
while (*buffer && *buffer != '\n') {
const char *eol = strchr(buffer, '\n');
- if (eol == NULL)
+ if (eol == NULL) {
eol = buffer + strlen(buffer);
- else
+ } else
eol++;
if (!prefixcmp(buffer, "author "))
@@ -157,20 +162,20 @@ void shortlog_add_commit(struct shortlog *log, struct commit *commit)
die("Missing author: %s",
sha1_to_hex(commit->object.sha1));
if (log->user_format) {
- struct strbuf buf = STRBUF_INIT;
struct pretty_print_context ctx = {0};
ctx.abbrev = DEFAULT_ABBREV;
ctx.subject = "";
ctx.after_subject = "";
ctx.date_mode = DATE_NORMAL;
- pretty_print_commit(CMIT_FMT_USERFORMAT, commit, &buf, &ctx);
- insert_one_record(log, author, buf.buf);
- strbuf_release(&buf);
- return;
- }
- if (*buffer)
+ pretty_print_commit(CMIT_FMT_USERFORMAT, commit, &ufbuf, &ctx);
+ buffer = ufbuf.buf;
+
+ } else if (*buffer)
buffer++;
+
insert_one_record(log, author, !*buffer ? "<none>" : buffer);
+ strbuf_release(&ufbuf);
+ strbuf_release(&buf);
}
static void get_from_rev(struct rev_info *rev, struct shortlog *log)
diff --git a/t/t4201-shortlog.sh b/t/t4201-shortlog.sh
index 405b971..118204b 100755
--- a/t/t4201-shortlog.sh
+++ b/t/t4201-shortlog.sh
@@ -51,5 +51,29 @@ git log HEAD > log
GIT_DIR=non-existing git shortlog -w < log > out
test_expect_success 'shortlog from non-git directory' 'test_cmp expect out'
+iconvfromutf8toiso885915() {
+ printf "%s" "$@" | iconv -f UTF-8 -t ISO-8859-15
+}
+
+git reset --hard "$commit"
+git config --unset i18n.commitencoding
+echo 2 > a1
+git commit --quiet -m "set a1 to 2 and some non-ASCII chars: Äßø" --author="Jöhännës \"Dschö\" Schindëlin <Johannes.Schindelin@gmx.de>" a1
+
+git config i18n.commitencoding "ISO-8859-15"
+echo 3 > a1
+git commit --quiet -m "$(iconvfromutf8toiso885915 "set a1 to 3 and some non-ASCII chars: áæï")" --author="$(iconvfromutf8toiso885915 "Jöhännës \"Dschö\" Schindëlin <Johannes.Schindelin@gmx.de>")" a1
+git config --unset i18n.commitencoding
+
+git shortlog HEAD~2.. > out
+
+cat > expect << EOF
+Jöhännës "Dschö" Schindëlin (2):
+ set a1 to 2 and some non-ASCII chars: Äßø
+ set a1 to 3 and some non-ASCII chars: áæï
+
+EOF
+
+test_expect_success 'shortlog encoding' 'test_cmp expect out'
test_done
--
1.6.5.3
^ permalink raw reply related
* Re: git init --bare --shared=group
From: Johannes Schindelin @ 2009-11-24 13:25 UTC (permalink / raw)
To: Eric Schaefer; +Cc: Git Mailing List
In-Reply-To: <34f8975d0911240505k4727fef2n8ef0efd3533aef1e@mail.gmail.com>
Hi,
On Tue, 24 Nov 2009, Eric Schaefer wrote:
> according to 'git help init' would --shared=group "Make the repository
> group-writable".
> I extracted a bare repo out of my local repo and scp'ed it to the
> server. There I did a 'git init --bare --shared=group'. It created the
> branches dir (there were no branches yet) and the config file and set
> the correct permissions. But it did not do so with the existsing files
> and dirs. Is it suffient to 'chmod -R g+ws .' or is there anything
> else to do to make the repo writeable for my group?
That should be enough, if all files and directories belong to the correct
group. Otherwise, you should 'chown -R .group .', too.
Ciao,
Dscho
^ permalink raw reply
* git init --bare --shared=group
From: Eric Schaefer @ 2009-11-24 13:05 UTC (permalink / raw)
To: Git Mailing List
Hello List,
according to 'git help init' would --shared=group "Make the repository
group-writable".
I extracted a bare repo out of my local repo and scp'ed it to the
server. There I did a 'git init --bare --shared=group'. It created the
branches dir (there were no branches yet) and the config file and set
the correct permissions. But it did not do so with the existsing files
and dirs. Is it suffient to 'chmod -R g+ws .' or is there anything
else to do to make the repo writeable for my group?
Thanks,
Eric
^ permalink raw reply
* Re: [PATCH 0/2] Add support for IPv6 on MinGW
From: Martin Storsjö @ 2009-11-24 11:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6lwrb5p.fsf@alter.siamese.dyndns.org>
On Mon, 23 Nov 2009, Junio C Hamano wrote:
> I am aware of the exchange between you and J6t on msysgit@googlegroups
> where he suggested you to send them here. Giving better visibility to
> these patches for public review is good.
>
> But you didn't have to Cc: me; in Windows API issues I have no clue so I
> won't be a good reviewer. I do not even compile git on Windows myself,
> let alone testing nor using.
Ah, sorry for notifying you prematurely there.
> As hinted by J6t, he will be saying Ack or something else, so I'll act on
> these patches when it happens.
And thanks for handling this!
// Martin
^ permalink raw reply
* Re: Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?
From: Bob Hazard @ 2009-11-24 11:29 UTC (permalink / raw)
To: adrian.alexander.may; +Cc: tytso, git, chromium-discuss
In-Reply-To: <65e170e70911231948l3b032dbeu7c99b65ce3ec97ff@mail.gmail.com>
Git's raison d'etre was to make merging cheaper. You are encouraged
to make as many local branches as you want to experiment on features
"if a longer experiment that I have committed several stages of turns
out to be a
blind alley, I'd like to go back a few steps on main, declare
everything after that to be a side branch that I'll probably never use
again, and continue on main with my next attempt. Is that possible?"
Yes.
This google tech talk by Randal Schwartz is a little old but it might help
http://www.youtube.com/watch?v=8dhZ9BXQgc4
2009/11/24 Adrian May <adrian.alexander.may@gmail.com>:
>> If you don't have bolt-on scripts, and you move that into the the core
>> SCM, then you force *all* projects to use whatever workflow was
>> decided as being the One True Way of doing things as seen by the SCM
>> designer. So the question is whether the SCM *should* regiment all
>> projects into following the SCM's designers idea of the One True
>> Workflow.
>
> Of course I'd want the workflow configurable by whoever controls the
> main repository. I couldn't possibly suggest that all git projects
> need the same workflow. The number of developers can vary by five
> orders of magnitude - that calls for different workflow models.
>
>> Git's approach is to say that it will be fairly flexible about
>> dictating workflow --- who pushs to whom; whether there is a single
>> "star" repository topology, or something that is more flexible, etc.
>> You seem to hate this flexibility, because it makes life harder until
>> you set up these bolt-on scripts. But that's what many of us like
>> about git; that it doesn't force us (the project lead) into a single
>> way of doing things.
>
> Leaving aside topology, I suppose we can agree that the subject
> divides into two aspects: offering the developer some optional tools,
> and asserting control over what gets commited to the official repo.
> Perhaps we can also agree that the former belongs under the control of
> the developer and the latter should be in the PM's hands. You seem to
> have opinions about which of these two aspects is more or less
> important, and to what extent git suffices, but I don't. I assume that
> the project manager has his own opinions about both aspects and I'm
> observing two big projects that independantly have augmented git's
> features with their own scripts. Their docs talk about both aspects,
> especially repo's, but they are entirely implemented in
> developer-overridable scripts. So any repo functions to do with the
> second aspect are either features that git needs to grow, or bits of
> the git manual that the repo designer didn't read. I'd kinda like to
> know which.
>
> Returning to topology, I think that also divides up similarly. The PM
> can't forbid you and me from casually swapping diffs back and forth,
> but he can dictate who we are supposed to submit our final candidate
> to for review. The very existence of a PM, who controls a subset of
> the repositories in the world, already implies a star topology, and I
> think pretty much everybody is using distributed source control in
> this way, at least when it comes down to *controlling* anything.
> People may also be causally bouncing diffs around, but that's not
> control, it's communication. I've got a one-man project on github
> which I edit from two locations, and even on that scale I find myself
> working star-fashion because either computer might have junk
> experiments in progress, but I only push to github if it's meaningful
> and tidy.
>
> That reminds me of a slightly different question: if a longer
> experiment that I have committed several stages of turns out to be a
> blind alley, I'd like to go back a few steps on main, declare
> everything after that to be a side branch that I'll probably never use
> again, and continue on main with my next attempt. Is that possible? I
> know that I can just start a new branch from the before the bad
> experiment, but if that happens a lot, the name of my current main
> branch would be changing all the time, and I think that's bad. I
> suspect what I want is possible, but I'm not sure how to do it.
>
>> As far as my wanting to impose a particular regimen on my project's
>> developers, I've never been a big fan of the Bondage and Discpline
>> school of software engineering. They can use whatever workflow they
>> like; they just have to deliver patches that are clean. If they are,
>> I'll pull from their repository. If they aren't, I won't.
>
> Repo talks a lot about automating the workflow that leads to precisely
> that decision. They evidently want something more evolved than
> somebody simply having a look at the code. I'm not sure what they
> want, but I'm pretty sure it's none of the developer's business.
>
> Adrian.
>
> --
> Chromium Discussion mailing list: chromium-discuss@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-discuss
--
Chromium Discussion mailing list: chromium-discuss@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-discuss
^ permalink raw reply
* [PATCH] mailinfo: remove [PATCH...] prefix from Subject regardless of length
From: Jim Meyering @ 2009-11-24 10:58 UTC (permalink / raw)
To: git list
Before this change, a [...] prefix would be removed only as long as
its length did not exceed 2/3 of the subject length. Now, when the
bracketed quantity starts with PATCH, it is removed unconditionally.
Otherwise, the existing behavior remains unchanged.
While with a bare "PATCH M/N" prefix, this inconsistency shows up only
on a subject of length 2 or 1 (assuming one-digit M and N), if you set
format.subjectprefix to the name of a project or sub-project, the
minimum affected length may be substantially larger.
Contrast the behavior before:
for i in 1234 123 12 1 ''; do echo 'Subject: [PATCH 1/1] '$i \
| git mailinfo m p | head -1; done
Subject: 1234
Subject: 123
Subject: [PATCH 1/1] 12
Subject: [PATCH 1/1] 1
Subject: [PATCH 1/1]
and after this change:
for i in 1234 123 12 1 ''; do echo 'Subject: [PATCH 1/1] '$i \
| ./git mailinfo m p | head -1; done
Subject: 1234
Subject: 123
Subject: 12
Subject: 1
Subject:
Along the way, I added a "const" to indicate that the "header"
array itself is constant.
Signed-off-by: Jim Meyering <meyering@redhat.com>
---
builtin-mailinfo.c | 10 ++++++++--
t/t5100-mailinfo.sh | 9 +++++++++
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 3c4f075..f07bca6 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -237,9 +237,15 @@ static void cleanup_subject(struct strbuf *subject)
strbuf_remove(subject, 0, 1);
continue;
case '[':
+ /* If there's a [...] enclosed prefix, always remove
+ it when it starts with "PATCH". If it does not
+ start with PATCH, remove the bracketed quantity
+ only as long as that removes no more than 2/3 of
+ the length. */
if ((pos = strchr(subject->buf, ']'))) {
remove = pos - subject->buf;
- if (remove <= (subject->len - remove) * 2) {
+ if (remove <= (subject->len - remove) * 2
+ || !prefixcmp (subject->buf + 1, "PATCH")) {
strbuf_remove(subject, 0, remove + 1);
continue;
}
@@ -265,7 +271,7 @@ static void cleanup_space(struct strbuf *sb)
}
static void decode_header(struct strbuf *line);
-static const char *header[MAX_HDR_PARSED] = {
+static const char *const header[MAX_HDR_PARSED] = {
"From","Subject","Date",
};
diff --git a/t/t5100-mailinfo.sh b/t/t5100-mailinfo.sh
index ebc36c1..86fb116 100755
--- a/t/t5100-mailinfo.sh
+++ b/t/t5100-mailinfo.sh
@@ -89,4 +89,13 @@ test_expect_success 'mailinfo on from header without name works' '
'
+test_expect_success 'mailinfo strips [PATCH... even on very short Subject' '
+
+ printf "Subject: [PATCH 1/1] ..\n" > in &&
+ printf "Subject: ..\n\n" > expect &&
+ git mailinfo /dev/null /dev/null < in > out &&
+ test_cmp expect out
+
+'
+
test_done
--
1.6.6.rc0.236.ge0b94
^ permalink raw reply related
* Re: What's cooking in git.git (Nov 2009, #05; Sun, 22)
From: Jakub Narebski @ 2009-11-24 10:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhbsl935q.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> * jn/gitweb-blame (2009-11-19) 6 commits.
> - gitweb.js: fix null object exception in initials calculation
> - gitweb: Minify gitweb.js if JSMIN is defined
> - gitweb: Create links leading to 'blame_incremental' using JavaScript
> (merged to 'next' on 2009-10-11 at 73c4a83)
> + gitweb: Colorize 'blame_incremental' view during processing
> + gitweb: Incremental blame (using JavaScript)
> + gitweb: Add optional "time to generate page" info in footer
>
> Ajax-y blame, with a few recent fixes.
Unfortunately current version does not work with IE8 (reported by
Stephen Boyd); it stops at the very beginning of JavaScript blaming
with the two JavaScript errors:
- "firstChild is null or not an object", caused by the fact that
'<a href=""> </a>' element doesn't have firstChild which is text
node with space as contents in DOM. This can be easily worked
around.
- "Unspecified error" (twice (sic!) for the same line), which
I have currently no idea how to fix; it points to the following
line:
if (xhr.readyState === 3 && xhr.status !== 200) {
> * pb/gitweb-no-project-list (2009-11-06) 3 commits.
> . gitweb: Polish the content tags support
> . gitweb: Support for no project list on gitweb front page
> . gitweb: Refactor project list routines
>
> I picked these up but didn't queue as Warthog9's comments made certain
> amount of sense to me.
I'd like to see at least refactoring project list subroutine:
currently printing list of projects is entangled with filtering
said list; IMHO filtering list of projects should be done upfront.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH RFC] git-send-email --expand-aliases
From: Catalin Marinas @ 2009-11-24 10:43 UTC (permalink / raw)
To: Karl Wiberg; +Cc: Alex Chiang, Junio C Hamano, git
In-Reply-To: <b8197bcb0911232312l251dfbc9va671388cfb7fe57b@mail.gmail.com>
2009/11/24 Karl Wiberg <kha@treskal.com>:
> On Tue, Nov 24, 2009 at 1:45 AM, Alex Chiang <achiang@hp.com> wrote:
>
>> * Junio C Hamano <gitster@pobox.com>:
>>
>> > If you are changing StGit to call git-send-email anyway, why not
>> > arrange stgit to call git-send-email to send the message out
>> > instead, instead of sending messages on its own?
>>
>> Yeah, I thought about that as I was poking around further in StGit
>> to figure out how it would be calling git-send-email. ;)
>>
>> > I imagine the internal implementation of stg mail would work
>> > something like:
>> >
>> > prepare messages to send out
>> > call git-send-email and have it send them
>> >
>> > What am I missing?
>>
>> My lack of familiarity with StGit internals. ;)
>>
>> Your suggestion is much better. I'll take a closer look at StGit and
>> see how feasible it is.
>>
>> Unless Catalin has strong objections?
>
> I think that sounds like a splendid idea. It would be interesting to
> see just how thin a wrapper around git send-email (and format-patch)
> stg mail could become, without sacrificing features anyone actually
> uses. The main complication could be stg mail's templates.
>
> Catalin, how wedded are you to those? ;-)
Historically, I think "stg mail" was implemented before git-send-email
existed. It was also a good way to check who's using stgit for sending
patches :-) (the message-id).
I use templates to send patches to the ARM Linux gatekeeper via a
patch management system which only accepts patches formatted in a
certain way (things improved a bit recently and the format was
relaxed). But I find myself mostly sending pull requests these days,
so that's not a critical feature for me.
If there are no other users of the stg mail templates, I'm happy to
let them go. Otherwise, we can replace the sendmail with
git-send-email in stgit.
It seems that git-format-patch and git-send-email have all the
features stgit has. We would need to keep some of the interactive
options like --edit-cover and --edit-patches since we use
git-format-patch and git-send-email in one go.
--
Catalin
^ permalink raw reply
* [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-24 8:56 UTC (permalink / raw)
To: git
While working inside a deep subdirectory, it sometimes is necessary to
find a string you see in a file you are working on from the files in the
entire project. This is especially true when you are dipping your toe
into an unfamiliar project.
By default, "git grep" limits its search space to the current directory
and below (i.e. as if "-r ." is specified), and it is rather cumbersome to
repeat ../ as many times as necessary. This new option tells "git grep"
not to limit the search space to the current directory.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* In http://article.gmane.org/gmane.comp.version-control.git/111717, I
once argued in the opposite way, but I think it is Ok to aim for making
the default --full-tree in the longer run (cf. $gmane/127885). This is
the first step in that direction.
I am not sure if there can be a sane way to flip the default without
hurting existing scripts and users. Backward compatibility always is
a pain.
builtin-grep.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 761799d..5787f35 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -693,6 +693,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
{
int hit = 0;
int cached = 0;
+ int full_tree = 0;
int external_grep_allowed = 1;
int seen_dashdash = 0;
struct grep_opt opt;
@@ -732,6 +733,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
OPT_BIT('H', NULL, &opt.pathname, "show filenames", 1),
OPT_NEGBIT(0, "full-name", &opt.relative,
"show filenames relative to top directory", 1),
+ OPT_BIT(0, "full-tree", &full_tree,
+ "search from the top of the tree", 1),
OPT_BOOLEAN('l', "files-with-matches", &opt.name_only,
"show only filenames instead of matching lines"),
OPT_BOOLEAN(0, "name-only", &opt.name_only,
@@ -862,7 +865,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
if (i < argc)
paths = get_pathspec(prefix, argv + i);
- else if (prefix) {
+ else if (prefix && !full_tree) {
paths = xcalloc(2, sizeof(const char *));
paths[0] = prefix;
paths[1] = NULL;
--
1.6.6.rc0.47.g1fdffa.dirty
^ permalink raw reply related
* Re: gitk does not show path file list
From: Junio C Hamano @ 2009-11-24 8:11 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Mark Blakeney, git
In-Reply-To: <4B0B91DC.1020902@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Mark Blakeney schrieb:
>> This seems to me to be a straight out bug but given I've had no response here
>> and given this is such a simple issue then I guess it's not a bug and I'm just
>> missing something? Please somebody, why does gitk (usually) not show the subset
>> list of files affected when you give it a path?
>>
>> E.g. If I am in a src dir then "gitk ." does not list files. Neither does "gitk
>> $PWD" nor "gitk ../src". However "cd ..; git src" does list files!?
>
> gitk doesn't list the files in your examples because the patterns you gave
> are not initial substrings of any files in the list.
Yes, but if you are in src/ and run "gitk .", then...
- clicking on a commit runs "diff-tree $commit .", that lists
src/hello.c, src/goodbye.c, etc.
- gitk tries to filter paths read from diff-tree with the "." given from
the command line as the filter---it removes paths that do not match.
So the only case that would produce any output would be for you to have:
src/src/hello.c
src/frotz.c
and run
cd src && gitk src
whose invocation of "diff-tree src" will show _only_ src/src/hello.c and
then the filter procedure will limit it to whatever begins with src/
(which would be everything).
That does not sound very useful to me...
^ permalink raw reply
* Re: gitk does not show path file list
From: Johannes Sixt @ 2009-11-24 7:57 UTC (permalink / raw)
To: Mark Blakeney; +Cc: git
In-Reply-To: <loom.20091124T060334-836@post.gmane.org>
Mark Blakeney schrieb:
> This seems to me to be a straight out bug but given I've had no response here
> and given this is such a simple issue then I guess it's not a bug and I'm just
> missing something? Please somebody, why does gitk (usually) not show the subset
> list of files affected when you give it a path?
>
> E.g. If I am in a src dir then "gitk ." does not list files. Neither does "gitk
> $PWD" nor "gitk ../src". However "cd ..; git src" does list files!?
gitk doesn't list the files in your examples because the patterns you gave
are not initial substrings of any files in the list.
-- Hannes
^ 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