* Re: git-subtree Ready for Inspection
From: David A. Greene @ 2012-02-09 21:52 UTC (permalink / raw)
To: Nazri Ramliy; +Cc: David A. Greene, Jan, git
In-Reply-To: <CAEY4ZpPs_3Ym=3gsVzwwXFAmk1DbgvvcdnK3p0WUaCOWg9TpMQ@mail.gmail.com>
Nazri Ramliy <ayiehere@gmail.com> writes:
> On Thu, Feb 9, 2012 at 1:02 PM, David A. Greene <greened@obbligato.org> wrote:
>> Do you mean running gitweb? Are you not able to access the above
>> repository? I can do that if it makes things easier but it will take a
>> bit of time.
>
> It asks for password:
>
> $ git clone gitolite@sources.obbligato.org:git.git
> Cloning into 'git'...
> gitolite@sources.obbligato.org's password:
Grr...Ok, I'll see if I can fix it or I will put up a gitweb fork.
-Dave
^ permalink raw reply
* Re: Silly Question About Timing
From: Hilco Wijbenga @ 2012-02-09 21:48 UTC (permalink / raw)
To: Seth Robertson; +Cc: Git Users
In-Reply-To: <201202092116.q19LGnTY024797@no.baka.org>
On 9 February 2012 13:16, Seth Robertson <in-gitvger@baka.org> wrote:
>
> In message <CAE1pOi1+FQNoPZ_P-fmFx-YhnUYzMQT=6zh3s-OyT71vcDm=wQ@mail.gmail.com>, Hilco Wijbenga writes:
>
> I've noticed that entering a Git controlled project directory takes
> quite some time so I wanted to measure exactly how much (it's the
> prompt I'm using that's taking the time, I suspect). I first tried (a
> bit naive, I admit :-) )
>
> time cd my-project
>
> Your confusion is because you are measuring the wrong thing. I'm
> assuming, here, that you have a shell prompt which is giving you all
> sorts of status about the git repository. The "cd" operation is
> instantaneous, it is the shell attempting to compute the new prompt
> which is slow.
Yes, exactly.
> Exactly how your shell does this is shell dependent, but you might
> want to look at your setting of $PROMPT_COMMAND. Then you can test it
> by running something like:
>
> time sh -c "cd git-directory; $PROMPT_COMMAND"
I tried that and it's still instantaneous.
The culprit is
export PS1='\[\033[01;32m\]\u@\h\[\033[01;34m\] \w \W$(__git_ps1 "
(%s)")\$\[\033[00m\] '
but I can't get that to run. Simply running
echo $PS1
doesn't work and I have been unable to get the __git_ps1 part to do anything.
^ permalink raw reply
* Re: git merge <tag>: Spawning an editor can't be disabled
From: Junio C Hamano @ 2012-02-09 21:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Guido Günther, git
In-Reply-To: <7vpqdnvh3b.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Your approach is the right one, though. A patch for 1.7.9.1, on top of
> b5c9f1c (merge: do not create a signed tag merge under --ff-only option,
> 2012-02-05), would look like this, I think.
> ...
I tweaked the message to credit your initial analysis and added the
following test (again on top of b5c9f1c).
Thanks.
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index a598dfa..9e27bbf 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -683,4 +683,16 @@ test_expect_success GPG 'merge --ff-only tag' '
test_cmp actual expect
'
+test_expect_success GPG 'merge --no-edit tag should skip editor' '
+ git reset --hard c0 &&
+ git commit --allow-empty -m "A newer commit" &&
+ git tag -f -s -m "A newer commit" signed &&
+ git reset --hard c0 &&
+
+ EDITOR=false git merge --no-edit signed &&
+ git rev-parse signed^0 >expect &&
+ git rev-parse HEAD^2 >actual &&
+ test_cmp actual expect
+'
+
test_done
^ permalink raw reply related
* Git, Builds, and Filesystem Type
From: Hilco Wijbenga @ 2012-02-09 21:23 UTC (permalink / raw)
To: Git Users
Hi all,
I'm thinking about trying out different filesystems over the weekend
to see if, say, BTRFS or XFS is faster when using Git and running our
build.
Currently, I'm using ReiserFS and it's not like it's not working. I'm
very pleased with ReiserFS but after seeing talks about BTRFS and XFS
I'm curious if another (newer) FS is better suited to our specific
environment. Anything to make the build a little faster. :-)
For the record, our (Java) project is quite small. It's 43MB (source
and images) and the entire directory tree after building is about
1.6GB (this includes all JARs downloaded by Maven). So we're not
talking TBs of data.
Any thoughts on which FSs to include in my tests? Or simply which FS
might be more appropriate?
Cheers,
Hilco
^ permalink raw reply
* Re: git merge <tag>: Spawning an editor can't be disabled
From: Junio C Hamano @ 2012-02-09 21:20 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Guido Günther, git
In-Reply-To: <20120209160803.GA5742@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Patch relies on "merge: use editor by default in interactive sessions"
> from master. If this looks like a sane approach, I can resend with a
> proposed log message and a test for t/t7600-merge.sh. (Or if someone
> else wants to do it first, even better.)
Please do not depend on that one that will never be merged to 1.7.9.x
maintenance track.
Your approach is the right one, though. A patch for 1.7.9.1, on top of
b5c9f1c (merge: do not create a signed tag merge under --ff-only option,
2012-02-05), would look like this, I think.
I think various "0 < option_edit" we can find in f824628 (merge: use
editor by default in interactive sessions, 2012-01-10) and f26af3f (merge:
add instructions to the commit message when editing, 2012-01-30) can and
should be reverted back to just "option_edit", as nobody should be looking
at option_edit before the "if edit is negative, set it to the default" we
can see in the last hunk of this patch (except for the "merging tag? turn
editing on by default unless --no-edit is given" that is the topic of this
thread).
Thanks.
-- >8 --
Subject: merge: do not launch an editor on "--no-edit $tag"
When the user explicitly asked us not to, don't launch an editor.
But do everything else the same way as the "edit" case, i.e. leave the
comment with verification result in the log template and record the
mergesig in the resulting merge commit for later inspection.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/merge.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index b4fbc60..f385b8a 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -48,7 +48,7 @@ static const char * const builtin_merge_usage[] = {
static int show_diffstat = 1, shortlog_len = -1, squash;
static int option_commit = 1, allow_fast_forward = 1;
-static int fast_forward_only, option_edit;
+static int fast_forward_only, option_edit = -1;
static int allow_trivial = 1, have_message;
static int overwrite_ignore = 1;
static struct strbuf merge_msg = STRBUF_INIT;
@@ -193,7 +193,7 @@ static struct option builtin_merge_options[] = {
"create a single commit instead of doing a merge"),
OPT_BOOLEAN(0, "commit", &option_commit,
"perform a commit if the merge succeeds (default)"),
- OPT_BOOLEAN('e', "edit", &option_edit,
+ OPT_BOOL('e', "edit", &option_edit,
"edit message before committing"),
OPT_BOOLEAN(0, "ff", &allow_fast_forward,
"allow fast-forward (default)"),
@@ -1287,11 +1287,15 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
merge_remote_util(commit) &&
merge_remote_util(commit)->obj &&
merge_remote_util(commit)->obj->type == OBJ_TAG) {
- option_edit = 1;
+ if (option_edit < 0)
+ option_edit = 1;
allow_fast_forward = 0;
}
}
+ if (option_edit < 0)
+ option_edit = 0;
+
if (!use_strategies) {
if (!remoteheads->next)
add_strategies(pull_twohead, DEFAULT_TWOHEAD);
^ permalink raw reply related
* Re: Silly Question About Timing
From: Seth Robertson @ 2012-02-09 21:16 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Git Users
In-Reply-To: <CAE1pOi1+FQNoPZ_P-fmFx-YhnUYzMQT=6zh3s-OyT71vcDm=wQ@mail.gmail.com>
In message <CAE1pOi1+FQNoPZ_P-fmFx-YhnUYzMQT=6zh3s-OyT71vcDm=wQ@mail.gmail.com>, Hilco Wijbenga writes:
I've noticed that entering a Git controlled project directory takes
quite some time so I wanted to measure exactly how much (it's the
prompt I'm using that's taking the time, I suspect). I first tried (a
bit naive, I admit :-) )
time cd my-project
Your confusion is because you are measuring the wrong thing. I'm
assuming, here, that you have a shell prompt which is giving you all
sorts of status about the git repository. The "cd" operation is
instantaneous, it is the shell attempting to compute the new prompt
which is slow.
Exactly how your shell does this is shell dependent, but you might
want to look at your setting of $PROMPT_COMMAND. Then you can test it
by running something like:
time sh -c "cd git-directory; $PROMPT_COMMAND"
-Seth Robertson
^ permalink raw reply
* Silly Question About Timing
From: Hilco Wijbenga @ 2012-02-09 21:10 UTC (permalink / raw)
To: Git Users
Hi all,
This is a bit silly but I'm trying to time how long it takes to enter
a Git controlled directory. I guess this is more of a GNU/Linux
question then anything else.
I've noticed that entering a Git controlled project directory takes
quite some time so I wanted to measure exactly how much (it's the
prompt I'm using that's taking the time, I suspect). I first tried (a
bit naive, I admit :-) )
time cd my-project
This doesn't work of course. Obviously, writing a script doesn't work
either because then the prompt isn't calculated. Next I tried
date +%H:%M:%S.%N ; cd my-project-abc ; date +%H:%M:%S.%N
but, surprisingly (to me), that doesn't work either. It simply prints
the two timestamps and *then* does the cd (or, at least, that's how it
seems to behave).
So how would one do this? :-)
Cheers,
Hilco
P.S. This slow cd is only the first time, afterwards things have been cached.
^ permalink raw reply
* Re: Git performance results on a large repository
From: Joshua Redstone @ 2012-02-09 21:06 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git@vger.kernel.org
In-Reply-To: <CACsJy8AxOZQ7S42V1g-b0vdBxPpjhFZe6qDkGaALnxQ6LiUssw@mail.gmail.com>
Hi Nguyen,
I like the notion of using --assume-unchanged to cut down the set of
things that git considers may have changed.
It seems to me that there may still be situations that require operations
on the order of the # of files in the repo and hence may still be slow.
Following is a list of potential candidates that occur to me.
1. Switching branches, especially if you switch to an old branch.
Sometimes I've seen branch switching taking a long time for what I thought
was close to where HEAD was.
2. Interactive rebase in which you reorder a few commits close to the tip
of the branch (I observed this taking a long time, but haven't profiled it
yet). I include here other types of cherry-picking of commits.
3. Any working directory operations that fail part-way through and make
you want to do a 'git reset --hard' or at least a full 'git-status'. That
is, when you have reason to believe that files with 'assume-unchange' may
have accidentally changed.
4. Operations that require rewriting the index - I think git-add is one?
If the working-tree representation is the full set of all files
materialized on disk and it's the same as the representation of files
changed, then I'm not sure how to avoid some of these without playing file
system games or using wrapper scripts.
What do you (or others) think?
Josh
On 2/7/12 8:43 AM, "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> wrote:
>On Mon, Feb 6, 2012 at 10:40 PM, Joey Hess <joey@kitenet.net> wrote:
>>> Someone on HN suggested making assume-unchanged files read-only to
>>> avoid 90% accidentally changing a file without telling git. When
>>> assume-unchanged bit is cleared, the file is made read-write again.
>>
>> That made me think about using assume-unchanged with git-annex since it
>> already has read-only files.
>>
>> But, here's what seems a misfeature...
>
>because, well.. assume-unchanged was designed to avoid stat() and
>nothing else. We are basing a new feature on top of it.
>
>> If an assume-unstaged file has
>> modifications and I git add it, nothing happens. To stage a change, I
>> have to explicitly git update-index --no-assume-unchanged and only then
>> git add, and then I need to remember to reset the assume-unstaged bit
>> when I'm done working on that file for now. Compare with running git mv
>> on the same file, which does stage the move despite assume-unstaged. (So
>> does git rm.)
>
>This is normal in the lock-based "checkout/edit/checkin" model. mv/rm
>operates on directory content, which is not "locked - no edit allowed"
>(in our case --assume-unchanged) in git. But lock-based model does not
>map really well to git anyway. It does not have the index (which may
>make things more complicated). Also at index level, git does not
>really understand directories.
>
>I think we could add a protection layer to index, where any changes
>(including removal) to an index entry are only allowed if the entry is
>"unlocked" (i.e no assume-unchanged bit). Locked entries are read-only
>and have assume-unchanged bit set. "git (un)lock" are introduced as
>new UI. Does that make assume-unchanged friendlier?
>--
>Duy
>--
>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
^ permalink raw reply
* Re: [PATCH 1/2] git-svn.perl: perform deletions before anything else
From: Thomas Rast @ 2012-02-09 20:55 UTC (permalink / raw)
To: Steven Walter; +Cc: normalperson, git
In-Reply-To: <CAK8d-aJ3wi0e_NPunow-aBnhs1=o5K25r3e-Ha0m1U0ujTv7OA@mail.gmail.com>
Oops, as Steven noticed I accidentally hit the wrong reply button. So
here's my earlier reply and his answer.
Steven Walter <stevenrwalter@gmail.com> writes:
> On Thu, Feb 9, 2012 at 2:16 PM, Thomas Rast <trast@inf.ethz.ch> wrote:
>> Steven Walter <stevenrwalter@gmail.com> writes:
>>
>>> If we delete a file and recreate it as a directory in a single commit,
>>> we have to tell the server about the deletion first or else we'll get
>>> "RA layer request failed: Server sent unexpected return value (405
>>> Method Not Allowed) in response to MKCOL request"
>> [...]
>>> - my %o = ( D => 1, R => 0, C => -1, A => 3, M => 3, T => 3 );
>>> + my %o = ( D => -2, R => 0, C => -1, A => 3, M => 3, T => 3 );
>>
>> You are making it delete first, but the original code seems to quite
>> deliberately put deletion after R (rename?). Are you sure you're not
>> breaking anything else?
>
> No, I'm not 100% sure of that.
>
> In fact, looking at cf52b8f063 where this code seems to have started,
> it lists my case explicitly as one that subversion does not support:
>
> "a file is removed and a directory of the same name of the removed
> file is created."
>
> One thing that might make a difference is that the "file" that removed
> was actually a symlink. So either svn treats symlinks as a special
> case to that rule, or else the limitation the commit was meant to
> address is not present on recent versions of svn. I can run some
> checks to see if that is the case.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 1/2] git-svn.perl: perform deletions before anything else
From: Steven Walter @ 2012-02-09 20:52 UTC (permalink / raw)
To: gitster, normalperson, git
In-Reply-To: <7vzkcrvkfa.fsf@alter.siamese.dyndns.org>
> I suspect that writing it this way [...] would make it much easier to
> follow.
Agreed. New patch to follow, this time with sign-off.
^ permalink raw reply
* [PATCH 1/2] git-svn.perl: perform deletions before anything else
From: Steven Walter @ 2012-02-09 20:52 UTC (permalink / raw)
To: gitster, normalperson, git; +Cc: Steven Walter, Steven Walter
In-Reply-To: <1328820742-4795-1-git-send-email-stevenrwalter@gmail.com>
From: Steven Walter <swalter@lexmark.com>
If we delete a file and recreate it as a directory in a single commit,
we have to tell the server about the deletion first or else we'll get
"RA layer request failed: Server sent unexpected return value (405
Method Not Allowed) in response to MKCOL request"
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index eeb83d3..06c9322 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -5374,7 +5374,7 @@ sub DESTROY {
sub apply_diff {
my ($self) = @_;
my $mods = $self->{mods};
- my %o = ( D => 1, R => 0, C => -1, A => 3, M => 3, T => 3 );
+ my %o = ( D => 0, C => 1, R => 2, A => 3, M => 4, T => 5 );
foreach my $m (sort { $o{$a->{chg}} <=> $o{$b->{chg}} } @$mods) {
my $f = $m->{chg};
if (defined $o{$f}) {
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] gitweb: Harden parse_commit and parse_commits
From: Jakub Narebski @ 2012-02-09 20:14 UTC (permalink / raw)
To: rajesh boyapati; +Cc: git
In-Reply-To: <CA+EqV8xiLYo8XE--c1QfuXdhentUFpHqfPYXHt72eCpEA_hCNQ@mail.gmail.com>
Please do not remove git@vger.kernel.org (git mailing list) from Cc,
i.e. please use "Reply to all" instead of just "Reply to author".
On Wed, 8 Feb 2012, rajesh boyapati wrote:
> 2012/2/8 Jakub Narebski <jnareb@gmail.com>
[...]
> > Does the following patch help, and does it fix the issue?
> >
> > (Nb. you can try to simply change filename, and apply it with fuzz
> > against index.cgi file).
> > -- >8 -- ----- ----- ----- ----- ----- -- >8 --
> > From: Jakub Narebski <jnareb@gmail.com>
> > Subject: [PATCH] gitweb: Harden parse_commit and parse_commits
[...]
> When I applied the above patch and also the patch from your previous
> e-mail, I am getting this error
> >>>>>>>>>>>>>
> [2012-02-08 14:09:58,396] ERROR
> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: fatal: bad revision
> 'HEAD'
> [2012-02-08 14:10:06,732] ERROR
> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: fatal: bad revision
> 'HEAD'
> [2012-02-08 14:10:11,404] ERROR
> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: fatal: bad revision
> 'HEAD'
> [2012-02-08 14:10:15,270] ERROR
> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: fatal: Not a valid
> object name HEAD
> <<<<<<<<<<<<<<
> With these patches, the previous errors at line numbers are gone.
Thanks for information.
This final issue will be a bit harder to fix. This error message
fatal: bad revision 'HEAD'
comes from git (I think from "git rev-list" command), and not from gitweb.
It is printed on STDERR of git command. What has to be done to fix it is
to capture stderr of a process, or silence it.
Unfortunately it is not that easy. We use list form of open, which avoids
using a shell interpreter to run command, and is safer wrt. shell escaping.
The only place where gitweb cares about redirecting standard error from git
command is git_object(). It is a bit hacky, and might be not entirely safe.
To fix this issue we would have to do the same in parse_commit*() as in
git_object(), or provide some kind of wrapper like IPC::Run provides
for redirecting stderr of called command.
Note that this issue was not considered very important, because this message
doesn't goes into web server logs when running gitweb via mod_cgi with
Apache... and probably also with other web servers. Gerrit (or rather
whatever it uses for serving CGI scripts) might be exception here.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH v2 1/2] submodules: always use a relative path to gitdir
From: Jens Lehmann @ 2012-02-09 20:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Antony Male, Phil Hord
In-Reply-To: <7vd39nx0br.fsf@alter.siamese.dyndns.org>
Am 09.02.2012 20:40, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>> Since recently a submodule with name <name> has its git directory in the
>
> I understand that "recently" refers to efc5fb6a77 and this is potentially
> a maint material for v1.7.8.X; am I correct?
That's correct.
>> The first version was whitespace damaged, please use this one instead.
>
> Thanks.
>
> When applied to v1.7.8.x maintenance track, this failed the first step in
> t5526, but with the earlier jl/submodule-re-add topic everything seems to
> pass just fine.
Ah, I only tested these patches on current master. But you are right,
this belongs on top of jl/submodule-re-add for maint.
^ permalink raw reply
* Re: [PATCH 1/2] git-svn.perl: perform deletions before anything else
From: Junio C Hamano @ 2012-02-09 20:08 UTC (permalink / raw)
To: Steven Walter; +Cc: normalperson, git
In-Reply-To: <1328813725-16638-1-git-send-email-stevenrwalter@gmail.com>
Steven Walter <stevenrwalter@gmail.com> writes:
> - my %o = ( D => 1, R => 0, C => -1, A => 3, M => 3, T => 3 );
> + my %o = ( D => -2, R => 0, C => -1, A => 3, M => 3, T => 3 );
I know this code arrangement dates back to cf52b8f (git-svn: fix several
corner-case and rare bugs with 'commit', 2006-02-20), but somehow I find
it extremely hard to follow. The absolute values do not matter (this is
only used to sort the classes of operations), and the fact that A/M/T
shares the same value does not help a stable sort result (as it is used as
a key to sort {} that is not given any key other than $o{$ab->{chg}} to
tie-break). I suspect that writing it this way
my %o = (D => 0, C => 1, R => 2, A => 3, M => 4, T => 5)
or even
my $ord = 0;
my %o = map { $_ => $ord++ } qw(D C R A M T);
would make it much easier to follow.
^ permalink raw reply
* Re: git merge <tag>: Spawning an editor can't be disabled
From: Junio C Hamano @ 2012-02-09 19:54 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jonathan Nieder, Guido Günther, git
In-Reply-To: <4F34158D.3030903@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> It should behave as if the editor was spawned and the user did not
> change the content of the commit message.
> ...
> Contrived? Dunno.
No, just "Sane".
Thanks. And I think Jonathan's original patch is just fine as-is; the
commented verification result should be stripspace()'ed out when we make
the final commit if we do so ourselves, and will stay if the user ends up
having to help resolving the merge.
^ permalink raw reply
* Re: [PATCH v2 1/2] submodules: always use a relative path to gitdir
From: Junio C Hamano @ 2012-02-09 19:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, Git Mailing List, Antony Male, Phil Hord
In-Reply-To: <7vd39nx0br.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> When applied to v1.7.8.x maintenance track, this failed the first step in
> t5526, but with the earlier jl/submodule-re-add topic everything seems to
> pass just fine.
What I meant to say is that "this and the other topic need to be merged to
that maintenance track together"; I didn't mean to say there is any
breakage in this patch.
Sorry for a potentially confusing statement.
^ permalink raw reply
* [RFC/PATCH] tag: make list exclude !<pattern>
From: Tom Grennan @ 2012-02-09 19:43 UTC (permalink / raw)
To: git; +Cc: gitster, peff
In-Reply-To: <1328816616-18124-1-git-send-email-tmgrennan@gmail.com>
Use the "!" prefix to ignore tags of the given pattern.
This has precedence over other matching patterns.
For example,
$ git tag -l \!*-rc? v1.7.8*
v1.7.8
v1.7.8.1
v1.7.8.2
v1.7.8.3
v1.7.8.4
$ git tag -l v1.7.8* \!*-rc?
v1.7.8
v1.7.8.1
v1.7.8.2
v1.7.8.3
v1.7.8.4
This is equivalent to,
$ git tag -l v1.7.8* | grep -v '\-rc.'
v1.7.8
v1.7.8.1
v1.7.8.2
v1.7.8.3
v1.7.8.4
Signed-off-by: Tom Grennan <tmgrennan@gmail.com>
---
builtin/tag.c | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index 31f02e8..b9ef718 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -32,13 +32,18 @@ struct tag_filter {
static int match_pattern(const char **patterns, const char *ref)
{
+ int ret;
+
/* no pattern means match everything */
if (!*patterns)
return 1;
- for (; *patterns; patterns++)
- if (!fnmatch(*patterns, ref, 0))
- return 1;
- return 0;
+ for (ret = 0; *patterns; patterns++)
+ if (**patterns == '!') {
+ if (!fnmatch(*patterns+1, ref, 0))
+ return 0;
+ } else if (!fnmatch(*patterns, ref, 0))
+ ret = 1;
+ return ret;
}
static int in_commit_list(const struct commit_list *want, struct commit *c)
--
1.7.8
^ permalink raw reply related
* [RFC/PATCH] tag: make list exclude !<pattern>
From: Tom Grennan @ 2012-02-09 19:43 UTC (permalink / raw)
To: git; +Cc: gitster, peff
Please see the following patch which filters the tag list of "!" prefaced
patterns. If this is deemed desirable and correct, I'll resubmit with updated
documentation and unit tests.
Thanks,
Tom Grennan (1):
tag: make list exclude !<pattern>
builtin/tag.c | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
--
1.7.8
^ permalink raw reply
* Re: [PATCH v2 1/2] submodules: always use a relative path to gitdir
From: Junio C Hamano @ 2012-02-09 19:40 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Git Mailing List, Antony Male, Phil Hord
In-Reply-To: <4F33814E.7050404@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Since recently a submodule with name <name> has its git directory in the
I understand that "recently" refers to efc5fb6a77 and this is potentially
a maint material for v1.7.8.X; am I correct?
> The first version was whitespace damaged, please use this one instead.
Thanks.
When applied to v1.7.8.x maintenance track, this failed the first step in
t5526, but with the earlier jl/submodule-re-add topic everything seems to
pass just fine.
^ permalink raw reply
* Re: [PATCH 0/2] config includes, take 2
From: Jeff King @ 2012-02-09 19:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: David Aguilar, git
In-Reply-To: <201202092024.43381.jnareb@gmail.com>
On Thu, Feb 09, 2012 at 08:24:42PM +0100, Jakub Narebski wrote:
> > So the patch would look something like this. However, is the actual
> > filename really what callers want? It seems like in David's case, an
> > annotation of "repo", "global", or "system" (possibly in addition to the
> > filename) would be the most useful (because in the git-cola UI, it is
> > still nice to list things as "repo" or "global" instead of spewing the
> > whole filename at the user -- but you would still want the individual
> > filename for handling updates of includes).
>
> I'm not sure if "system" / "global" / "local" or "repo" would be a good
> idea.
>
> First, in the case of includes you would have to provide pathnames of
> included files. This would introduce inconsistency. Is "system"
> the '/etc/gitconfig' file, or 'system' file in '.git' directory?
Yeah, it would have to be syntactically unambiguous with the filename.
I was thinking something of just including both, like this:
global:/home/peff/.gitconfig<TAB>include.path=other-file
global:/home/peff/other-file<TAB>some.key=value
That is, give a "context" (repo, global, system) to each lookup, and
then mention the individual file as well (either because it is the root
of that context, or because it was included). So a config editor could
present the context to the user as a purely decorative thing (i.e., tell
the user "these options affect all of your repos"), but use the filename
to actually update the values (i.e., "git config -f
/home/peff/other-file some.key newvalue").
> Second, people can have different build configuration, e.g. the prefix
> might differ, so that "system" is not always '/etc/gitconfig'. If you
> want to edit config you would want to know which file to edit... and though
> there is "git config --system --edit" it depends on having editor
> configured correctly.
Without includes, something like git-cola could possibly get away with:
git config --system some.key value
but that doesn't work for included files; for those, you'd want to have
the actual filename.
-Peff
^ permalink raw reply
* A note on modern git plus ancient meld ("wrong number of arguments")
From: Jeff Epler @ 2012-02-09 19:17 UTC (permalink / raw)
To: git
I note this just in case it helps someone else track down a similar
problem, not because I think any change needs to be made to git, as a
version of meld new enough to not be affected by this problem is 5 years
old.
At $DAYJOB, I recently encountered a problem after upgrading from (don't
laugh) git 1.7.1 to 1.7.8.3: one developer stated that meld failed to
run, instead displaying the error 'Wrong number of arguments (Got 5)'.
We determined that this user was running a very old version of meld
(1.1.1) from his home directory, as opposed to the also very old system
version of meld (1.1.5). It turns out that the check added in
f61bd9c mergetools/meld: Use '--output' when available
fails on meld 1.1.1, leading git to incorrectly believe the --output
flag is supporrted:
$ meld-1.1.1 --output /dev/null --help >/dev/null 2>&1; echo $?
0 # i.e., detected as supported
The test as written gives the correct ("not supported") result with meld
1.1.5:
$ meld-1.1.5 --output /dev/null --help >/dev/null 2>&1; echo $?
2 # i.e., detected as supported
so if you encounter the message 'Wrong number of arguments (Got 5)' from
meld, then check whether you have an ancient version of meld. If for
some reason you can't upgrade to at least 1.1.5, maybe you'd find the
following configuration flags useful:
[merge]
tool = ancientmeld
[mergetool "ancientmeld"]
cmd = meld-1.1.1 \"$LOCAL\" \"$MERGED\" \"$REMOTE\"
Jeff
^ permalink raw reply
* Re: [PATCH 0/2] config includes, take 2
From: Jakub Narebski @ 2012-02-09 19:24 UTC (permalink / raw)
To: Jeff King; +Cc: David Aguilar, git
In-Reply-To: <20120209033059.GA4347@sigill.intra.peff.net>
On Thu, 9 Feb 2012, Jeff King wrote:
> On Tue, Feb 07, 2012 at 11:16:47AM -0800, Jakub Narebski wrote:
> > Jeff King <peff@peff.net> writes:
> >
> > [...]
> > > Git-config could potentially help with that (and even simplify the
> > > current code) by allowing something like:
> > >
> > > $ git config --list-with-sources
> > > /home/peff/.gitconfig user.name=Jeff King
> > > /home/peff/.gitconfig user.email=peff@peff.net
> > > .git/config core.repositoryformatversion=0
> > > .git/config core.bare=false
> > > [etc]
> > >
> > > (you would use the "-z" form, of course, and the filenames would be
> > > NUL-separated, but I made up a human-readable output format above for
> > > illustration purposes).
> >
> > That would be _very_ nice to have (even without includes support).
> >
> > Filenames would be git-quoted like in ls-tree / diff-tree output without -z,
> > isn't it? And is that TAB or SPC as a separator?
>
> So the patch would look something like this. However, is the actual
> filename really what callers want? It seems like in David's case, an
> annotation of "repo", "global", or "system" (possibly in addition to the
> filename) would be the most useful (because in the git-cola UI, it is
> still nice to list things as "repo" or "global" instead of spewing the
> whole filename at the user -- but you would still want the individual
> filename for handling updates of includes).
I'm not sure if "system" / "global" / "local" or "repo" would be a good
idea.
First, in the case of includes you would have to provide pathnames of
included files. This would introduce inconsistency. Is "system"
the '/etc/gitconfig' file, or 'system' file in '.git' directory?
Second, people can have different build configuration, e.g. the prefix
might differ, so that "system" is not always '/etc/gitconfig'. If you
want to edit config you would want to know which file to edit... and though
there is "git config --system --edit" it depends on having editor
configured correctly.
Just my two cents.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [StGit PATCH] Parse commit object header correctly
From: Junio C Hamano @ 2012-02-09 19:04 UTC (permalink / raw)
To: Catalin Marinas
Cc: Karl Hasselström, Andy Green (林安廸), git
In-Reply-To: <CAHkRjk6dr=5wxm+iSC2_CSB-q3k2WG_Um+X7dwsy-H8tL508EA@mail.gmail.com>
Catalin Marinas <catalin.marinas@gmail.com> writes:
> On 8 February 2012 07:33, Junio C Hamano <gitster@pobox.com> wrote:
>> To allow parsing the header produced by versions of Git newer than the
>> code written to parse it, all commit parsers are expected to skip unknown
>> header lines, so that newer types of header lines can be added safely.
>> The only three things that are promised are:
>>
>> (1) the header ends with an empty line (just an LF, not "a blank line"),
>> (2) unknown lines can be skipped, and
>> (3) a header "field" begins with the field name, followed by a single SP
>> followed by the value.
>
> Thanks for looking into this. Is this the same as an email header? If
> yes, we could just use the python's email.Header.decode_header()
> function (I haven't tried yet).
If you are thinking about feeding everything up to the first empty line to
whatever is designed to parse email header, please don't. I do not think
they obey "skip unknown lines without barfing" rule [*1*], so we would be
back to square one if you did so.
The fix posted in this thread is necessary because the change to StGit
between v0.15 and v0.16 made to ignore lines starting with "encoding " was
a wrong way to work around the broken parser in v0.15 in the first place.
The parser assumed that (1) all whitespaces around the header lines can be
stripped, (2) the result after such stripping will always have at least
one whitespace so that line.split(None, 1) will never barf, and (3)
between the field name and its value there may be arbitrary number of
whitespace characters that can be ignored so that line.split(None, 1) is a
safe way to split it into a (key,value) pair. None of which is a safe
thing to assume. The rule for safe parsing is to ignore all lines it does
not understand without assuming anything, and I wrote the patch in this
thread to make sure it makes no such unwarranted assumption.
> BTW, does Git allow custom headers to be inserted by tools like StGit?
The header format is designed in such a way that it is safe for a parser
to silently ignore unknown cruft, but that also means tools that work on
an existing commit and produce a similar one, like "commit --amend", are
free to either ignore and drop them when creating a new commit out of the
original one, or replay it verbatim without adjusting them to the new
context they appear in. In that sense, they are technically "allowed",
but depending on the nature of the information you are putting there, it
semantically may or may not produce the desired result [*2*]. I would say
it is strongly discouraged to invent new types of header lines without
first consulting the people who maintain tools you must interoperate with,
so that they will also be aware of them, and hopefully their tools can be
adjusted to help you use them.
Sorry for the breakage and making you to deal with this post release. We
observed that recent StGit did not barf after we added "encoding " field
to Git, and assumed that StGit correctly ignored lines that it did not
understand, without inspecting its code.
At least we should have Cc'ed you guys directly when the change was being
discussed on the list.
[Footnote]
*1* I also suspect that it will handle a line that begins with a single SP
differently if you use email parsing rules. In a commit object header, the
content of such a line is appended to the value of the previous field
after turning that leading single SP into a LF, and the resulting value
will be a string that consists of multiple lines. The header folding rule
used for e-mail in RFC2822 is a way to represent a (logically) single line
as physically multiple lines, so the result of unfolding will become a
single line. This difference may not matter for the purpose of the
current StGit that understands nothing but tree/parent/author/committer,
but because we are discussing a forward-looking fix for its parser, I
wouldn't recommend "it does not matter because we do not currently care"
approach.
*2* For example, a line that begins with "gpgsig " is a field that records
the GPG signature of a commit itself (using "git commit -S"), and it
should not survive across "commit --amend". A line that begins with
"mergetag " is a field that records the tag information that was merged
from a side branch, and amending such a merge does not change what was
merged, so it should survive across "commit --amend".
^ permalink raw reply
* Re: git merge <tag>: Spawning an editor can't be disabled
From: Jonathan Nieder @ 2012-02-09 19:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Guido Günther, Johannes Sixt, git
In-Reply-To: <7vzkcrx4f2.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> If the editor is not spawned, there is no way for the user to review the
> result of signature verification before deciding to accept the merge.
> "git merge --no-edit v1.7.2" could error out saying "you cannot create
> this merge without reviewing". Or it could behave as if it was asked to
> "git merge --no-edit v1.7.2^0", dropping the signature verification and
> recording part altogether.
Others might want to read the tag message and check its signature,
even though the original committer was in a non-interactive rush.
Here's a toy patch (untested) to avoid wasting time verifying a
signature only to throw away the result. It's not actually a no-op,
since if conflicts are encountered, the operator who intervenes won't
get to see whether the signature was valid when her editor of choice
is launched.
diff --git i/builtin.h w/builtin.h
index 857b9c8a..62dffbdc 100644
--- i/builtin.h
+++ w/builtin.h
@@ -17,6 +17,7 @@ extern void prune_packed_objects(int);
struct fmt_merge_msg_opts {
unsigned add_title:1;
+ unsigned skip_tag_verification:1;
int shortlog_len;
};
diff --git i/builtin/fmt-merge-msg.c w/builtin/fmt-merge-msg.c
index c81a7fef..e99030d3 100644
--- i/builtin/fmt-merge-msg.c
+++ w/builtin/fmt-merge-msg.c
@@ -316,7 +316,8 @@ static void fmt_tag_signature(struct strbuf *tagbuf,
strbuf_add_lines(tagbuf, "# ", sig->buf, sig->len);
}
-static void fmt_merge_msg_sigs(struct strbuf *out)
+static void fmt_merge_msg_sigs(struct strbuf *out,
+ struct fmt_merge_msg_opts *opts)
{
int i, tag_number = 0, first_tag = 0;
struct strbuf tagbuf = STRBUF_INIT;
@@ -332,8 +333,8 @@ static void fmt_merge_msg_sigs(struct strbuf *out)
goto next;
len = parse_signature(buf, size);
- if (size == len)
- ; /* merely annotated */
+ if (size == len || opts->skip_tag_verification)
+ ; /* merely annotated, or caller disabled signature check */
else if (verify_signed_buffer(buf, len, buf + len, size - len, &sig)) {
if (!sig.len)
strbuf_addstr(&sig, "gpg verification failed.\n");
@@ -400,7 +401,7 @@ int fmt_merge_msg(struct strbuf *in, struct strbuf *out,
fmt_merge_msg_title(out, current_branch);
if (origins.nr)
- fmt_merge_msg_sigs(out);
+ fmt_merge_msg_sigs(out, opts);
if (opts->shortlog_len) {
struct commit *head;
diff --git i/builtin/merge.c w/builtin/merge.c
index c401106e..75e027b6 100644
--- i/builtin/merge.c
+++ w/builtin/merge.c
@@ -1295,6 +1295,10 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
opts.add_title = !have_message;
opts.shortlog_len = shortlog_len;
+ assert(0 <= option_edit);
+ if (option_commit && !option_edit)
+ opts.skip_tag_verification = 1;
+
fmt_merge_msg(&merge_names, &merge_msg, &opts);
if (merge_msg.len)
strbuf_setlen(&merge_msg, merge_msg.len - 1);
^ permalink raw reply related
* [PATCH 1/2] git-svn.perl: perform deletions before anything else
From: Steven Walter @ 2012-02-09 18:55 UTC (permalink / raw)
To: normalperson, git; +Cc: Steven Walter
If we delete a file and recreate it as a directory in a single commit,
we have to tell the server about the deletion first or else we'll get
"RA layer request failed: Server sent unexpected return value (405
Method Not Allowed) in response to MKCOL request"
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 570d83d..520b02b 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -5391,7 +5391,7 @@ sub DESTROY {
sub apply_diff {
my ($self) = @_;
my $mods = $self->{mods};
- my %o = ( D => 1, R => 0, C => -1, A => 3, M => 3, T => 3 );
+ my %o = ( D => -2, R => 0, C => -1, A => 3, M => 3, T => 3 );
foreach my $m (sort { $o{$a->{chg}} <=> $o{$b->{chg}} } @$mods) {
my $f = $m->{chg};
if (defined $o{$f}) {
--
1.7.9.4.ge7a0d
^ permalink raw reply related
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