* Re: 1.7.9, libcharset missing from EXTLIBS
From: Junio C Hamano @ 2012-02-10 20:25 UTC (permalink / raw)
To: git; +Cc: dilyan.palauzov, Ævar Arnfjörð Bjarmason
In-Reply-To: <7vipjer0yn.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Дилян Палаузов <dilyan.palauzov@aegee.org> writes:
>
>>>> What I am wondering is there are systems that need to include the header,
>>>> but locale_charset() does not live in /lib/libcharset.a, in which case we
>>>> cannot make HAVE_LIBCHARSET_H imply use of -lcharset.
>>
>> I do not understand this. If you want to use a function from
>> libcharset, you have to use both #include <libcharset.h> and
>> -lcharset.
>
> You are mistaken.
>
> The only constraint is that you have to "#include <libcharset.h>" and need
> to link with the library that has locale_charset() defined.
I think the follow-ups in this thread already demonstrated why it is an
insufficient solution to make HAVE_LIBCHARSET_H imply -lcharset.
We would instead need:
ifeq ($(uname_S),MyHomeBrewLinux)
HAVE_LIBCHARSET_H = YesPlease
EXTLIBS += -lcharset
endif
or
# Define NEEDS_CHARSETLIB if you use HAVE_LIBCHARSET_H and
# need to link with -lcharset
NEEDS_CHARSETLIB =
ifeq ($(uname_S),MyHomeBrewLinux)
HAVE_LIBCHARSET_H = YesPlease
NEEDS_CHARSETLIB = YesPlease
endif
ifdef NEEDS_CHARSETLIB
EXTLIBS += -lcharset
endif
or something like that, I guess.
^ permalink raw reply
* Re: [PATCH v2 28/51] refs.c: rename ref_array -> ref_dir
From: Jeff King @ 2012-02-10 20:44 UTC (permalink / raw)
To: Michael Haggerty
Cc: Junio C Hamano, git, Drew Northup, Jakub Narebski, Heiko Voigt,
Johan Herland, Julian Phillips
In-Reply-To: <4F352F03.2030104@alum.mit.edu>
On Fri, Feb 10, 2012 at 03:51:47PM +0100, Michael Haggerty wrote:
> First problem: everything_local() seems to be either broken or used
> incorrectly. I can't decide which because I don't know what its
> semantics are *supposed* to be.
>
> If everything_local() is trying to check that the references are all in
> the local repository itself, then it is incorrect for clone to enter
> alternates into extra_refs because everything_local() then mistakes them
> for local.
>
> If everything_local() is trying to check that the references are in the
> local repository plus alternates, then it is incorrect that
> everything_local() doesn't consider alternate references in its
> determination. My guess is that this is the case, and that something
> like the following might be the fix:
Junio could answer more authoritatively than I, but I am pretty sure it
is the latter. The point is to skip the expensive find_common
negotiation if we know that there are no objects to fetch. Thus the
"local" here is "do we have them on this side of the git-protocol
connection", not "do we have them in our non-alternates repository".
> > ----------------------------- builtin/fetch-pack.c -----------------------------
> > index 9500f35..4257a8d 100644
> > @@ -581,6 +581,11 @@ static void filter_refs(struct ref **refs, int nr_match, char **match)
> > *refs = newlist;
> > }
> >
> > +static void mark_alternate_complete(const struct ref *ref, void *unused)
> > +{
> > + mark_complete(NULL, ref->old_sha1, 0, NULL);
> > +}
> > +
> > static int everything_local(struct ref **refs, int nr_match, char **match)
> > {
> > struct ref *ref;
> > @@ -609,6 +614,7 @@ static int everything_local(struct ref **refs, int nr_match, char **match)
> >
> > if (!args.depth) {
> > for_each_ref(mark_complete, NULL);
> > + for_each_alternate_ref(mark_alternate_complete, NULL);
> > if (cutoff)
> > mark_recent_complete_commits(cutoff);
> > }
>
> With this patch, then the full test suite passes even if I take out the
> code that adds the alternate refs to extra_refs.
That looks sane to me.
> Specifically: (without the above patch) I commented out the call to
> add_extra_ref() in clone.c:add_one_reference(), then ran t5700 through
> step 8 then aborted. insert_one_alternate_ref() was called four times:
>
> insert_one_alternate_ref(ccc25a1f9655742174c93f48f616bea8ad0bc6ff)
> insert_one_alternate_ref(ccc25a1f9655742174c93f48f616bea8ad0bc6ff)
> insert_one_alternate_ref(5355551c5a927a2b6349505ada2da4bb702c0a49)
> insert_one_alternate_ref(5355551c5a927a2b6349505ada2da4bb702c0a49)
>
> (The duplication here seems strange.)
I think the duplication can be explained. The alternate-refs mechanism
gets the list of refs by running "git ls-remote" on each alternate.
The symbolic refs appear as refs in that list. So in t5700, for example,
I get:
$ git ls-remote B
56a2e291e54b1a92180fe2072152e6aa0919fc5f HEAD
56a2e291e54b1a92180fe2072152e6aa0919fc5f refs/heads/master
3ee812e8486c2474e2b03be5c0b42e33092da069 refs/remotes/origin/HEAD
3ee812e8486c2474e2b03be5c0b42e33092da069 refs/remotes/origin/master
Because you don't actually care about the alternate refs themselves, but
only about their sha1 values, you could eliminate duplicates early. The
code in receive-pack already does this; fetch-pack should probably do
the same (it's not _wrong_ not to, but in some pathological cases, the
duplicates can make performance worse).
> want 5355551c5a927a2b6349505ada2da4bb702c0a49 multi_ack_detailed
> side-band-64k thin-pack ofs-delta
> want 5355551c5a927a2b6349505ada2da4bb702c0a49
> #E
>
> The "5355551c" object corresponds to refs/remotes/origin/master in the
> alternate object store:
>
> $ (cd B; git for-each-ref)
> ccc25a1f9655742174c93f48f616bea8ad0bc6ff commit refs/heads/master
> 5355551c5a927a2b6349505ada2da4bb702c0a49 commit refs/remotes/origin/HEAD
> 5355551c5a927a2b6349505ada2da4bb702c0a49 commit refs/remotes/origin/master
>
> It seems to me that even in the absence of short-circuiting due to
> everything_local() returning true, the presence of the alternate refs
> should be suppressing the "want" lines for those references.
Yeah, that definitely seems like a bug in find_common.
-Peff
^ permalink raw reply
* Re: [PATCH] Remove empty ref directories while reading loose refs
From: Jeff King @ 2012-02-10 20:53 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Junio C Hamano, Michael Haggerty
In-Reply-To: <1328891127-17150-1-git-send-email-pclouds@gmail.com>
On Fri, Feb 10, 2012 at 11:25:27PM +0700, Nguyen Thai Ngoc Duy wrote:
> Empty directories in $GIT_DIR/refs increases overhead at startup.
> Removing a ref does not remove its parent directories even if it's the
> only file left so empty directories will be hanging around.
> [...]
> This patch removes empty directories as we see while traversing
> $GIT_DIR/refs and reverts be7c6d4 because it's no longer needed.
It feels wrong to me to be writing to the repository during what would
otherwise be a read-only operation. Especially without locking. Doesn't
this create a race condition with:
git update-ref refs/foo/bar $sha1 & (a)
git for-each-ref (b)
if you have this sequence of events:
1. (a) wants to create the ref, so it must first mkdir
".git/refs/foo".
2. (b) is reading refs and notices the empty "foo" directory. It
rmdirs it.
3. (a) now attempts to create "bar" inside the newly created "foo"
directory. This fails, because the directory does not exist.
A similar race already can happen with:
git update-ref refs/foo/bar $sha1 &
git update-ref refs/foo $sha1
since the latter will remove a stale "foo" directory before it can
create the new ref file. But that race is OK, I think. Those are both
write operations, and one of them _must_ fail, because they are in
conflict (and I think even with the race they fail gracefully, with the
latter one "winning").
> pack-refs was taught of cleaning up empty directories in be7c6d4
> (pack-refs: remove newly empty directories - 2010-07-06), but it only
> checks parent directories of packed refs only. Already empty dirs are
> left untouched.
I'd much rather have pack-refs simply learn to remove all stale
directories. We at least know that "gc" is a slightly riskier operation.
-Peff
^ permalink raw reply
* Re: [PATCH v2 28/51] refs.c: rename ref_array -> ref_dir
From: Junio C Hamano @ 2012-02-10 21:17 UTC (permalink / raw)
To: Jeff King
Cc: Michael Haggerty, Junio C Hamano, git, Drew Northup,
Jakub Narebski, Heiko Voigt, Johan Herland, Julian Phillips
In-Reply-To: <20120210204457.GD5504@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> If everything_local() is trying to check that the references are in the
>> local repository plus alternates, then it is incorrect that
>> everything_local() doesn't consider alternate references in its
>> determination. My guess is that this is the case, and that something
>> like the following might be the fix:
>
> Junio could answer more authoritatively than I, but I am pretty sure it
> is the latter. The point is to skip the expensive find_common
> negotiation if we know that there are no objects to fetch. Thus the
> "local" here is "do we have them on this side of the git-protocol
> connection", not "do we have them in our non-alternates repository".
Correct. The function is about "do we need to get any object from the
other side?" optimization.
I originally thought to go through the rest of your message, but I
realized I can just say "everything you said is correct and I have nothing
more to add."
Thanks.
^ permalink raw reply
* Re: Git documentation at kernel.org
From: Ted Ts'o @ 2012-02-10 21:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Konstantin Ryabitsev, Matthieu Moy, Clemens Buchacher, ftpadmin,
Petr Onderka, git
In-Reply-To: <7vhayyphlw.fsf@alter.siamese.dyndns.org>
On Fri, Feb 10, 2012 at 12:18:35PM -0800, Junio C Hamano wrote:
> That would not work very well without changing the historical directory
> structure (which I think was the point of this discussion "please keep
> these stale links alive").
>
> The toplevel index.html in the pub/software/scm/git/docs/ directory and
> its pointees were the set of docs for the latest version, and older
> versions were rooted at pub/software/scm/git/docs/vX.Y.Z/. Links that
> point at software/scm/git/docs/git-cat-file.html still need to work, and
> the path needs to be updatable without having to include the preformatted
> documentation for all the historical versions in the same tarball.
Hmm... good point. That does make it hard. I could imagine making it
work by having separate hierarchies, and then using apache rewrite
rules so that anything that doesn't begin with vX.Y.Z in the top level
of software/scm/git/docs/* gets redirected to LATEST/*, where LATEST is
a symlink that is managed via kup.
I don't know if the k.org folks would consider that acceptable, though.
- Ted
^ permalink raw reply
* Re: git svn problem
From: Sam Vilain @ 2012-02-10 21:21 UTC (permalink / raw)
To: Serhat Sevki Dincer; +Cc: git
In-Reply-To: <CAPqC6xRtZXwv+U6AKRUXDz=m-G4AjgWksbwqeMD_qzS8YC=DoQ@mail.gmail.com>
On 2/10/12 10:15 AM, Serhat Sevki Dincer wrote:
> Hi,
>
> I am using git-svn (1.7.4.1-3 on ubuntu) to get a project. It has two
> svn repositories, apparently disjoint. First half is at
> http://svn.plone.org/svn/plone/plone.app.locales, and the continuation
> at http://svn.plone.org/svn/collective/plone.app.locales
> How can i get a nice linear git-svn repository? the second one is the
> new location of the project. I am only interested in the trunks btw.
Import them separately to different git-svn remotes, and once they are
in the same repository you can graft them together using
.git/info/grafts (see man gitrepository-layout). Once it looks right
(check using 'gitk' etc), make it permanent using git filter-branch.
You'll also want to remove the .git/svn directory, and re–run 'git svn
fetch' so that git svn's revision database is recomputed. Don't forget
the -A option to 'git svn fetch'!
Good luck,
Sam
^ permalink raw reply
* Re: A note on modern git plus ancient meld ("wrong number of arguments")
From: Junio C Hamano @ 2012-02-10 21:28 UTC (permalink / raw)
To: Jonathan Nieder
Cc: David Aguilar, Jeff Epler, git, Sebastian Schuberth,
Charles Bailey
In-Reply-To: <20120210082106.GA7871@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Just parse version numbers instead. We can detect the version number
> by running "meld --version" and postprocessing it.
Hmm. I am debating myself if it may be more efficient, less error prone
and simpler for the users if we gave them "mergetool.meld.useOutput"
configuration option to tweak.
When an older meld fails when given --output for real (not with the dry
run current code tries with --help), can we sanely detect that particular
failure? If we can do so, another possibility may be to do something like
this:
merge_cmd () {
meld_has_output_option=$(git config --bool mergetool.meld.useOutput)
case "$meld_has_output_option" in
false)
... do the non-output thing ...
;;
true)
"$merge_tool_path" --output "$MERGED" "$LOCAL" "$BASE" "$REMOTE"
;;
*)
"$merge_tool_path" --output "$MERGED" "$LOCAL" "$BASE" "$REMOTE"
if it failed due to missing --output support?
then
meld_has_output_option=no
git config mergetool.meld.useOutput false
merge_cmd
fi
;;
esac
}
^ permalink raw reply
* Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Michał Kiedrowicz @ 2012-02-10 21:29 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120210202008.GA5874@sigill.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Fri, Feb 10, 2012 at 10:18:12AM +0100, Michał Kiedrowicz wrote:
>
> > The code that comares lines is based on
> > contrib/diff-highlight/diff-highlight, except that it works with
> > multiline changes too. It also won't highlight lines that are
> > completely different because that would only make the output unreadable.
> > Combined diffs are not supported but a following commit will change it.
>
> Have you considered contributing back the enhancements to
> contrib/diff-highlight?
Yeah, I did. In fact, at work I have a hacked version of your
diff-highlight that supports multiline changes and I use it every day.
But I just couldn't make myself fix your long README and send a
patch :).
Maybe I'll cook something in my spare time.
> I took a look at handling multi-line changes
> when I originally wrote it, but I was worried too much about failing to
> match up lines properly, and ending up with too much noise in the diff.
> Maybe your "don't highlight lines that are completely different" rule
> helps that, though.
I must say that it works great for me. Most often it's very helping.
Like every heuristics it sometimes goes the wrong way, but it's so rare
that I don't find it disturbing.
>
> Do you have any examples handy? (I was hoping not to need to get a
> running gitweb installation in order to see the output).
>
> -Peff
Nope. Except for comparing diffs in various commits in gitweb-1.7.9 and
from my branch, I just created a dummy commit with different kinds of
changes to check if they are properly colorized.
^ permalink raw reply
* Re: [PATCH 1/5] gitweb: Option for filling only specified info in fill_project_list_info
From: Jakub Narebski @ 2012-02-10 21:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsjiipiyu.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > If @fill_only is empty, it means for fill_project_list_info to fill
> > all the data, if it is not empty it means that those fields needs to
> > be filled.
>
> That is exactly what I am questioning. Do you need "I need all these
> fields to be present" and "I will fill these other fields" (which is what
> @fill_only is about, no?) that is different from the former?
"I need all these fields" is a property of callsite. fill_project_list_info()
will be called more than one time in 2/5 to incrementally complete project
info, see below.
"I will fill those fields" is a property of piece of code protected by
a conditional inside fill_project_list_info().
> > The code of fill_project_list_info goes like this
> >
> > if (do we need to fill 'age' or 'age_string'?) {
> > fill 'age' and 'age_string'
> > }
> > if (do we need to fill 'desc_long' or 'descr'?) {
> > fill 'descr_long' and 'descr'
> > }
> > if (we are interested in 'ctags' &&
> > do we need to fill 'ctags'?) {
> > fill 'ctags'
> > }
> > ...
>
> Exactly. Why do you need @fill_only at all? If you are interested in
> ctags and you want to make sure ctags is available, the question you want
> to ask the helper function is "Does the project structure already have
> ctags field?". Why does the helper function needs to know anything else?
It is to support incremental filling of project info. The code is to
go like this:
create
filter
fill part
filter
fill rest
We need @fill_only for the "fill part". As filling project info is
potentially expensive (especially the 'age' field), doing it on narrowed
(filtered) list of project is a performance win. That is what 2/5 is
about.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Jeff King @ 2012-02-10 21:32 UTC (permalink / raw)
To: Michał Kiedrowicz; +Cc: git
In-Reply-To: <20120210222916.2721e9e6@gmail.com>
On Fri, Feb 10, 2012 at 10:29:16PM +0100, Michał Kiedrowicz wrote:
> > Have you considered contributing back the enhancements to
> > contrib/diff-highlight?
>
> Yeah, I did. In fact, at work I have a hacked version of your
> diff-highlight that supports multiline changes and I use it every day.
> But I just couldn't make myself fix your long README and send a
> patch :).
Heh. Why don't you show your hack in the meantime. Even if the code is
ugly or the documentation is missing, I'd like to see the output, and
maybe we can fix those other things together.
-Peff
^ permalink raw reply
* Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Michał Kiedrowicz @ 2012-02-10 21:36 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120210213209.GA7582@sigill.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Fri, Feb 10, 2012 at 10:29:16PM +0100, Michał Kiedrowicz wrote:
>
> > > Have you considered contributing back the enhancements to
> > > contrib/diff-highlight?
> >
> > Yeah, I did. In fact, at work I have a hacked version of your
> > diff-highlight that supports multiline changes and I use it every day.
> > But I just couldn't make myself fix your long README and send a
> > patch :).
>
> Heh. Why don't you show your hack in the meantime. Even if the code is
> ugly or the documentation is missing, I'd like to see the output, and
> maybe we can fix those other things together.
>
> -Peff
Then just give must few minutes.
^ permalink raw reply
* Re: Git documentation at kernel.org
From: Junio C Hamano @ 2012-02-10 21:38 UTC (permalink / raw)
To: Ted Ts'o
Cc: Konstantin Ryabitsev, Matthieu Moy, Clemens Buchacher, ftpadmin,
Petr Onderka, git
In-Reply-To: <20120210212030.GD5381@thunk.org>
Ted Ts'o <tytso@mit.edu> writes:
> Hmm... good point. That does make it hard. I could imagine making it
> work by having separate hierarchies, and then using apache rewrite
> rules so that anything that doesn't begin with vX.Y.Z in the top level
> of software/scm/git/docs/* gets redirected to LATEST/*, where LATEST is
> a symlink that is managed via kup.
We could move vX.Y.Zs out of scm/git/docs/ hierarchy. The existing links
from external sites rarely point at a documentation page of a specific
version, I suspect.
People can be trained to look at scm/git/old-docs/vX.Y.Z when they want to
see how older command set looked like, even those who know that in olden
days they would have consulted scm/git/docs/vX.Y.Z for that information;
they are much less of a problem than existing pages whose links want to
stay working.
^ permalink raw reply
* Re: [PATCH 1/5] gitweb: Option for filling only specified info in fill_project_list_info
From: Junio C Hamano @ 2012-02-10 21:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <201202102230.13193.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
>> Exactly. Why do you need @fill_only at all? If you are interested in
>> ctags and you want to make sure ctags is available, the question you want
>> to ask the helper function is "Does the project structure already have
>> ctags field?". Why does the helper function needs to know anything else?
>
> It is to support incremental filling of project info. The code is to
> go like this:
>
> create
> filter
> fill part
> filter
> fill rest
>
> We need @fill_only for the "fill part".
Again, why?
> As filling project info is
> potentially expensive (especially the 'age' field),
So you wouldn't say "I am interested in 'age' field" but show interest in,
and fill, cheaper fields in the earlier "fill" calls, and then...
> doing it on narrowed
> (filtered) list of project is a performance win.
... you drop uninteresting projects by using the partially filled
information, and show interest in more expensive 'age' in the later round
for surviving projects.
It still does not explain why you need @fill_only.
Hrm...
^ permalink raw reply
* [PATCH] diff-highlight: Work for multiline changes too
From: Michał Kiedrowicz @ 2012-02-10 21:47 UTC (permalink / raw)
To: git; +Cc: Jeff King, Michał Kiedrowicz
In-Reply-To: <20120210213209.GA7582@sigill.intra.peff.net>
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
---
After looking at outputs I noticed that it can also ignore lines with
prefixes/suffixes that consist only of punctuation (asterisk, semicolon, dot,
etc), because otherwise whole line is highlighted except for terminating
punctuation.
contrib/diff-highlight/diff-highlight | 96 ++++++++++++++++++++++-----------
1 files changed, 65 insertions(+), 31 deletions(-)
diff --git a/contrib/diff-highlight/diff-highlight b/contrib/diff-highlight/diff-highlight
index d893898..4811550 100755
--- a/contrib/diff-highlight/diff-highlight
+++ b/contrib/diff-highlight/diff-highlight
@@ -1,28 +1,40 @@
#!/usr/bin/perl
+use warnings;
+use strict;
+
# Highlight by reversing foreground and background. You could do
# other things like bold or underline if you prefer.
my $HIGHLIGHT = "\x1b[7m";
my $UNHIGHLIGHT = "\x1b[27m";
my $COLOR = qr/\x1b\[[0-9;]*m/;
-my @window;
+my $context;
+my @removed = ();
+my @added = ();
+my $started = 0;
while (<>) {
- # We highlight only single-line changes, so we need
- # a 4-line window to make a decision on whether
- # to highlight.
- push @window, $_;
- next if @window < 4;
- if ($window[0] =~ /^$COLOR*(\@| )/ &&
- $window[1] =~ /^$COLOR*-/ &&
- $window[2] =~ /^$COLOR*\+/ &&
- $window[3] !~ /^$COLOR*\+/) {
- print shift @window;
- show_pair(shift @window, shift @window);
- }
- else {
- print shift @window;
+ if (/^$COLOR*-/) {
+ push @removed, $_;
+ } elsif (/^$COLOR*\+/) {
+ push @added, $_;
+ } else {
+ if ($started == 1 ) {
+ show_pairs(\@removed, \@added);
+ } else {
+ print @removed;
+ print @added;
+ }
+ @removed = ();
+ @added = ();
+ print $_;
+
+ if (/^$COLOR*(\@| )/) {
+ $started = 1;
+ } else {
+ $started = 0;
+ }
}
# Most of the time there is enough output to keep things streaming,
@@ -38,23 +50,33 @@ while (<>) {
}
}
-# Special case a single-line hunk at the end of file.
-if (@window == 3 &&
- $window[0] =~ /^$COLOR*(\@| )/ &&
- $window[1] =~ /^$COLOR*-/ &&
- $window[2] =~ /^$COLOR*\+/) {
- print shift @window;
- show_pair(shift @window, shift @window);
-}
-
-# And then flush any remaining lines.
-while (@window) {
- print shift @window;
-}
+show_pairs(\@removed, \@added);
exit 0;
-sub show_pair {
+sub show_pairs {
+ my $a = shift;
+ my $b = shift;
+
+ if (scalar(@{$a}) == scalar(@{$b}) && scalar(@${a}) > 0) {
+ my @removed;
+ my @added;
+
+ for(my $i = 0; $i < scalar(@{$a}); $i++) {
+ my ($rm, $add) = highlight_pair($a->[$i], $b->[$i]);
+ push @removed, $rm;
+ push @added, $add;
+ }
+
+ print @removed;
+ print @added;
+ } else {
+ print @{$a};
+ print @{$b};
+ }
+}
+
+sub highlight_pair {
my @a = split_line(shift);
my @b = split_line(shift);
@@ -101,8 +123,20 @@ sub show_pair {
}
}
- print highlight(\@a, $pa, $sa);
- print highlight(\@b, $pb, $sb);
+ my $prefa = join('', @a[0..($pa-1)]);
+ my $prefb = join('', @b[0..($pb-1)]);
+ my $sufa = join('', @a[($sa+1)..$#a]);
+ my $sufb = join('', @b[($sb+1)..$#b]);
+
+ # Highlight only if prefix or suffix is interesting (i.e. not consisting
+ # of color and (for prefix) +/-). Otherwise we would highlight whole
+ # lines.
+ if ($prefa =~ /^($COLOR)*-(\s|$COLOR)*$/ && $sufa =~ /^(\s|$COLOR)*$/
+ && $prefb =~ /^($COLOR)*\+(\s|$COLOR)*$/ && $sufb =~ /^(\s|$COLOR)*$/) {
+ return join('', @a), join('', @b);
+ } else {
+ return highlight(\@a, $pa, $sa), highlight(\@b, $pb, $sb);
+ }
}
sub split_line {
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Jakub Narebski @ 2012-02-10 21:56 UTC (permalink / raw)
To: Jeff King; +Cc: Michał Kiedrowicz, git
In-Reply-To: <20120210202008.GA5874@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> (I was hoping not to need to get a running gitweb installation in
> order to see the output).
Well, there is always git-instaweb ;-)
--
Jakub Narębski
^ permalink raw reply
* [PATCH] mergetools/meld: Use --help output to detect --output support
From: Jonathan Nieder @ 2012-02-10 21:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: David Aguilar, Jeff Epler, git, Sebastian Schuberth,
Charles Bailey
In-Reply-To: <7vwr7unzs8.fsf@alter.siamese.dyndns.org>
In v1.7.7-rc0~3^2 (2011-08-19), git mergetool's "meld" support learned
to use the --output option when calling versions of meld that are
detected to support it (1.5.0 and newer, hopefully).
Alas, it misdetects old versions (before 1.1.5, 2006-06-11) of meld as
supporting the option, so on systems with such meld, instead of
getting a nice merge helper, the operator gets a dialog box with the
text "Wrong number of arguments (Got 5)". (Version 1.1.5 is when meld
switched to using optparse. One consequence of that change was that
errors in usage are detected and signalled through the exit status
even when --help was passed.)
Luckily there is a simpler check that is more reliable: the usage
string printed by "meld --help" reliably reflects whether --output is
supported in a given version. Use it.
Reported-by: Jeff Epler <jepler@unpythonic.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Junio C Hamano wrote:
> When an older meld fails when given --output for real (not with the dry
> run current code tries with --help), can we sanely detect that particular
> failure?
Unfortunately it just pops up a GUI with a modal dialog box like this:
___________________________________
| |
| Wrong number of arguments (Got 5) |
| |
| [Quit] [OK] |
|___________________________________|
If I choose "Quit", the exit status is 0.
But how about this? "meld --help | grep -e --output" seems to detect
support for the option reliably. With 2>&1 on the upstream of the
pipe, this even seems futureproof. ;-)
mergetools/meld | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mergetools/meld b/mergetools/meld
index eaa115cc..cb672a55 100644
--- a/mergetools/meld
+++ b/mergetools/meld
@@ -23,7 +23,7 @@ check_meld_for_output_version () {
meld_path="$(git config mergetool.meld.path)"
meld_path="${meld_path:-meld}"
- if "$meld_path" --output /dev/null --help >/dev/null 2>&1
+ if "$meld_path" --help 2>&1 | grep -e --output >/dev/null
then
meld_has_output_option=true
else
--
1.7.9
^ permalink raw reply related
* Re: [PATCH 1/5] gitweb: Option for filling only specified info in fill_project_list_info
From: Jakub Narebski @ 2012-02-10 22:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vobt6nz31.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>>> Exactly. Why do you need @fill_only at all? If you are interested in
>>> ctags and you want to make sure ctags is available, the question you want
>>> to ask the helper function is "Does the project structure already have
>>> ctags field?". Why does the helper function needs to know anything else?
>>
>> It is to support incremental filling of project info. The code is to
>> go like this:
>>
>> create
>> filter
>> fill part
>> filter
>> fill rest
>>
>> We need @fill_only for the "fill part".
>
> Again, why?
So fill_project_list_info() knows what needs to be filled (notice: not
"what to fill"), as filter might need different fields in project info
to do its work.
> > As filling project info is
> > potentially expensive (especially the 'age' field),
>
> So you wouldn't say "I am interested in 'age' field" but show interest in,
> and fill, cheaper fields in the earlier "fill" calls, and then...
It is not about cheaper, it is about required by filter. It happens that
it is cheaper.
> > doing it on narrowed
> > (filtered) list of project is a performance win.
>
> ... you drop uninteresting projects by using the partially filled
> information, and show interest in more expensive 'age' in the later round
> for surviving projects.
>
> It still does not explain why you need @fill_only.
So I can use single subroutine fill_project_list_info() to fill what is
required, and to fill the rest of info.
create
filter
fill part('path', 'descr')
filter('path', 'descr')
fill rest
or
create
filter
fill part('ctags')
filter('ctags')
fill rest
Am I clear?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: nested git repos (not submodules)
From: Neal Kreitzinger @ 2012-02-10 22:07 UTC (permalink / raw)
To: Andrew Ardill; +Cc: Neal Kreitzinger, git
In-Reply-To: <CAH5451mU5G-_FaPkpuhKrHAt4_5wiECj=-j9wkA_Ctb=27ncQg@mail.gmail.com>
On 2/9/2012 9:47 PM, Andrew Ardill wrote:
> My understanding was that such a configuration is essentially
> tracking the same set of files in two different git repositories. The
> location of the .git is not important, I could just as easily set the
> working directory of any git repository to be a folder tracked by
> another repository.
>
> My concerns would be based primarily on the different repositories
> trying to act on the same files at the same time. Ignoring the
> sub-folder completely within the encompassing repository would avoid
> that, however you might have use cases that prohibit that.
>
WORKTREE/SUBDIR/ was already tracked by WORKTREE/.git because the files
in WORKTREE/SUBDIR/ directly correlate to WORKTREE/ files (ie.,
WORKTREE/., WORKTREE/SUBDIR2/., WORKTREE/SUBDIR3/.). This is the
published model.
> Out of interest, what itch are you scratching by using this model?
>
(I can only speculate) I think it was intended to ensure that he would
only be modifying the WORKTREE/SUBDIR/ files of WORKTREE/.git. He did
some sequence of commands with the end result of:
(a) bare repo HISPATH/SUBDIR.git
and
(b1)
WORKTREE/.git
WORKTREE/SUBDIR/
is now
(b2)
WORKTREE/.git
WORKTREE/SUBDIR/.git
which means that the files of WORKTREE/SUBDIR are now tracked by
WORKTREE/.git and WORKTREE/SUBDIR/.git, as you stated.
Due to a drop-dead short-term deadline, I am being compelled to "just
deal with it" (work around the annoyances) unless there is a dire reason
it will blow up in our faces. At this point, (b2) is more-or-less an
intermediate "integration repo" between (a) and (b1-canonical), and I'm
assuming I can just jump thru some hoops to accomplish the integration
when the time comes (unless I hear of or step on any landmines).
Now that the newsgroup has confirmed that having "a repo that tracks the
worktree of a nested repo" is not a sound model, I can advise against it
on a go-forward basis without being concerned that I'm not open to new
ideas.
v/r,
neal
^ permalink raw reply
* Re: [PATCH] mergetools/meld: Use --help output to detect --output support
From: Jeff Epler @ 2012-02-10 22:23 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, David Aguilar, git, Sebastian Schuberth,
Charles Bailey
In-Reply-To: <20120210215755.GL19216@burratino>
I appreciate the interest you've all taken in my report, but I really
don't think there's any need to do anything about this "problem" besides
let people find this thread, in which they can learn to try upgrading
their meld to one that's only 5 1/2 years old.
That said, another possibility is to test whether
meld --commandline-option-that-cannot-possibly-exist --help
exits with status 0; if it does, then exit-status based probing of
meld's capabilities won't work. In this case, assume --output is not
available.
Jeff
On Fri, Feb 10, 2012 at 03:57:55PM -0600, Jonathan Nieder wrote:
> In v1.7.7-rc0~3^2 (2011-08-19), git mergetool's "meld" support learned
> to use the --output option when calling versions of meld that are
> detected to support it (1.5.0 and newer, hopefully).
>
> Alas, it misdetects old versions (before 1.1.5, 2006-06-11) of meld as
> supporting the option, so on systems with such meld, instead of
> getting a nice merge helper, the operator gets a dialog box with the
> text "Wrong number of arguments (Got 5)". (Version 1.1.5 is when meld
> switched to using optparse. One consequence of that change was that
> errors in usage are detected and signalled through the exit status
> even when --help was passed.)
>
> Luckily there is a simpler check that is more reliable: the usage
> string printed by "meld --help" reliably reflects whether --output is
> supported in a given version. Use it.
>
> Reported-by: Jeff Epler <jepler@unpythonic.net>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> Junio C Hamano wrote:
>
> > When an older meld fails when given --output for real (not with the dry
> > run current code tries with --help), can we sanely detect that particular
> > failure?
>
> Unfortunately it just pops up a GUI with a modal dialog box like this:
> ___________________________________
> | |
> | Wrong number of arguments (Got 5) |
> | |
> | [Quit] [OK] |
> |___________________________________|
>
> If I choose "Quit", the exit status is 0.
>
> But how about this? "meld --help | grep -e --output" seems to detect
> support for the option reliably. With 2>&1 on the upstream of the
> pipe, this even seems futureproof. ;-)
>
> mergetools/meld | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/mergetools/meld b/mergetools/meld
> index eaa115cc..cb672a55 100644
> --- a/mergetools/meld
> +++ b/mergetools/meld
> @@ -23,7 +23,7 @@ check_meld_for_output_version () {
> meld_path="$(git config mergetool.meld.path)"
> meld_path="${meld_path:-meld}"
>
> - if "$meld_path" --output /dev/null --help >/dev/null 2>&1
> + if "$meld_path" --help 2>&1 | grep -e --output >/dev/null
> then
> meld_has_output_option=true
> else
> --
> 1.7.9
>
> --
> 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] mergetools/meld: Use --help output to detect --output support
From: Jeff Epler @ 2012-02-10 22:30 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, David Aguilar, git, Sebastian Schuberth,
Charles Bailey
In-Reply-To: <20120210215755.GL19216@burratino>
I can confirm that this iteration of the patch (meld --help | grep)
worked for me on meld 1.1.1, meld 1.1.5, and meld 1.3.0. Note however
that none of these are versions of meld that do support the --output
flag.
Tested-by: Jeff Epler <jepler@unpythonic.net>
Jeff
^ permalink raw reply
* Re: nested git repos (not submodules)
From: Neal Kreitzinger @ 2012-02-10 22:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Neal Kreitzinger, git
In-Reply-To: <7vd39ns4py.fsf@alter.siamese.dyndns.org>
On 2/9/2012 10:16 PM, Junio C Hamano wrote:
>
> The repository controlled by worktree/.git should behave as if subdir/
> does not exist, except that obviously the project cannot have a regular
> file "subdir" in it. When you chdir to worktree/subdir, everything in
> there should behave as if worktree/.git directory does not exist.
>
> At least that is the design, and it indeed is how I arrange my primary
> working tree (I have two "clones" at /git/git.git/ and /git/git.git/Meta,
> and the latter has a checkout of the "todo" branch), so I would make
> noises about any breakage for such a layout.
>
I now see that most of the concept of "a repo worktree path with an o/s
subdir containing another repo" is valid provided that the repo is
ignoring the worktree of the subdir repo.
> I do not know offhand if an attempt to add files inside subdir to the
> repository controlled by worktree/.git is always correctly prohibited by
> the code, though, as our code often forgets to error out "stupid user
> mistakes", and running "git add subdir/bar" when in worktree/ falls into
> that category.
>
In my situation, WORKTREE/.git is tracking the worktree of
WORKTREE/SUBDIR/.git. Before WORKTREE/SUBDIR/.git was created,
WORKTREE/SUBDIR/ was already being tracked by WORKTREE/.git because
WORKTREE/SUBDIR/. directly correlates to the rest of WORKTREE/.,
WORKTREE/SUBDIR2/., etc. Now that I know that having "a repo tracking
the worktree of a nested repo" is not a sound model, I can advise
against it on a go-forward basis without being concerned that I am not
open to new ideas.
> And the use of that layout predates the submodules by a large margin.
> In fact, when people suggest use of submodules when the toplevel and the
> sublevel do not even need tight version dependencies, some of their use
> cases might be better supported by using the simply-nested layout without
> even letting the toplevel be aware of the sublevel.
I will keep this in mind when adding submodules.
Thanks!
v/r,
neal
^ permalink raw reply
* Re: Splitting gitweb (was: Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff)
From: Jakub Narebski @ 2012-02-10 22:52 UTC (permalink / raw)
To: Michał Kiedrowicz; +Cc: git
In-Reply-To: <20120210183319.2f56ff88@gmail.com>
Michał Kiedrowicz wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
> > Well, except the fact
> > that I'm rather wary about adding more code to gitweb when it is still
> > single monolithic script, rather than split into packages.
> >
>
> Yeah, jumping between 2k'th and 5k'th line isn't a great fun. Do you
There is an easy part, an almost easy part, and a hard part.
The easy part of splitting gitweb is creating infrastructure for it,
at least in the basic case. The 'gitweb/split' branch in my git forks:
http://repo.or.cz/w/git/jnareb-git.git
https://github.com/jnareb/git
contains changes to gitweb and gitweb/Makefile, and splitting off
Gitweb::Util as an example; I'd have to update this branch to current
state of gitweb.
The almost easy part is to come up with a way to split gitweb. Do we
follow SVN::Web (Subversion web interface in Perl), or maybe Gitalist
(git web interface in Perl, using Catalyst MVC framework)? Do we use
MVC paradigm? Or do we split on functionality: diffs, blobs, trees,
logs, etc.?
The hard part is about splitting main parts of gitweb. It is easy to
put generic subroutines that are not specific to git or gitweb in
Gitweb::Util (or Gitweb::Util::* submodules). It would be almost as
easy to put parsing of git command output in Gitweb::Parse (or
Gitweb::Parse::* submodules).
The problem is with putting actual actions in separate submodules.
For that we would need to replace our hacky "longjmp"-based error handling
(nonlocal goto in Perl is roughly equivalent to longjmp() in C) to
exception-based one, as I don't think going back to exit-based error
ahndling is a good idea. We would need exception-based error handling
if we want to implement HTTP output caching anyway, I think.
Not to not reimplement the wheel, badly, we will do better to use some
non-core Perl modules, namely Try::Tiny for capturing exceptions, and
HTTP::Exception (based on Exception::Class) for throwing exceptions.
So we would have to add a way to handle such non-core modules, perhaps
bundling them with gitweb, like Error is bundled with Git.pm and used
if it is not present on install.
Maybe Module::Install would help us there with bundling of such
dependencies for install; maybe "push @INC, __DIR__.'/inc' would be
a good idea.
It needs thinking about.
--
Jakub Narebski
Poland
^ permalink raw reply
* What's cooking in git.git (Feb 2012, #04; Fri, 10)
From: Junio C Hamano @ 2012-02-10 23:37 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
This round mosty consists of topics to fix new features introduced in
1.7.9, in preparation for 1.7.9.1 maintenance release. There are a few
more of them to come.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* nk/ctype-for-perf (2012-02-10) 2 commits
(merged to 'next' on 2012-02-10 at b41c6bb)
+ ctype: implement islower/isupper macro
+ ctype.c only wants git-compat-util.h
* jn/ancient-meld-support (2012-02-10) 1 commit
- mergetools/meld: Use --help output to detect --output support
--------------------------------------------------
[Graduated to "master"]
* jc/branch-desc-typoavoidance (2012-02-05) 2 commits
(merged to 'next' on 2012-02-06 at 9fb0568)
+ branch --edit-description: protect against mistyped branch name
+ tests: add write_script helper function
(this branch is tangled with jk/tests-write-script.)
Typo in "git branch --edit-description my-tpoic" was not diagnosed.
* jc/merge-ff-only-stronger-than-signed-merge (2012-02-05) 1 commit
(merged to 'next' on 2012-02-06 at 0fabf12)
+ merge: do not create a signed tag merge under --ff-only option
(this branch is used by jn/merge-no-edit-fix.)
"git merge --ff-only $tag" failed because it cannot record the required
mergetag without creating a merge, but this is so common operation for
branch that is used _only_ to follow the upstream, so it is allowed to
fast-forward without recording the mergetag.
* jc/parse-date-raw (2012-02-03) 2 commits
(merged to 'next' on 2012-02-07 at 486ae6e)
+ parse_date(): '@' prefix forces git-timestamp
+ parse_date(): allow ancient git-timestamp
"rebase" and "commit --amend" failed to work on commits with ancient
timestamps near year 1970.
* jk/tests-write-script (2012-02-03) 2 commits
(merged to 'next' on 2012-02-05 at 4264ffa)
+ t0300: use write_script helper
+ tests: add write_script helper function
(this branch is tangled with jc/branch-desc-typoavoidance.)
* jn/rpm-spec (2012-02-03) 1 commit
(merged to 'next' on 2012-02-05 at dba940b)
+ git.spec: Workaround localized messages not put in any RPM
Fix breakage in v1.7.9 Makefile; rpmbuild notices an unpackaged but
installed *.mo file and fails.
* js/add-e-submodule-fix (2012-02-07) 1 commit
(merged to 'next' on 2012-02-08 at c8e2d28)
+ add -e: do not show difference in a submodule that is merely dirty
"add -e" learned not to show a diff for an otherwise unmodified submodule
that only has uncommitted local changes in the patch prepared by for the
user to edit.
--------------------------------------------------
[Stalled]
* jc/advise-push-default (2011-12-18) 1 commit
- push: hint to use push.default=upstream when appropriate
Peff had a good suggestion outlining an updated code structure so that
somebody new can try to dip his or her toes in the development. Any
takers?
* ss/git-svn-prompt-sans-terminal (2012-01-04) 3 commits
- fixup! 15eaaf4
- git-svn, perl/Git.pm: extend Git::prompt helper for querying users
- perl/Git.pm: "prompt" helper to honor GIT_ASKPASS and SSH_ASKPASS
The bottom one has been replaced with a rewrite based on comments from
Ævar. The second one needs more work, both in perl/Git.pm and prompt.c, to
give precedence to tty over SSH_ASKPASS when terminal is available.
* jc/split-blob (2012-01-24) 6 commits
- chunked-object: streaming checkout
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- varint-in-pack: refactor varint encoding/decoding
Not ready.
I finished the streaming checkout codepath, but as explained in 127b177
(bulk-checkin: support chunked-object encoding, 2011-11-30), these are
still early steps of a long and painful journey. At least pack-objects and
fsck need to learn the new encoding for the series to be usable locally,
and then index-pack/unpack-objects needs to learn it to be used remotely.
Given that I heard a lot of noise that people want large files, and that I
was asked by somebody at GitTogether'11 privately for an advice on how to
pay developers (not me) to help adding necessary support, I am somewhat
dissapointed that the original patch series that was sent almost two
months ago still remains here without much comments and updates from the
developer community. I even made the interface to the logic that decides
where to split chunks easily replaceable, and I deliberately made the
logic in the original patch extremely stupid to entice others, especially
the "bup" fanboys, to come up with a better logic, thinking that giving
people an easy target to shoot for, they may be encouraged to help
out. The plan is not working :-(.
* nd/columns (2012-02-08) 15 commits
- column: Fix some compiler and sparse warnings
- column: add a corner-case test to t3200
- columns: minimum coding style fixes
- tag: add --column
- column: support piping stdout to external git-column process
- status: add --column
- branch: add --column
- help: reuse print_columns() for help -a
- column: add column.ui for default column output settings
- column: support columns with different widths
- column: add columnar layout
- Stop starting pager recursively
- Add git-column and column mode parsing
- column: add API to print items in columns
- Save terminal width before setting up pager
The "show list of ..." mode of a handful of commands learn to produce
column-oriented output.
Expecting a reroll.
--------------------------------------------------
[Cooking]
* jk/config-include (2012-02-06) 2 commits
- config: add include directive
- docs: add a basic description of the config API
An assignment to the include.path pseudo-variable causes the named file
to be included in-place when Git looks up configuration variables.
* jk/maint-tag-show-fixes (2012-02-08) 3 commits
(merged to 'next' on 2012-02-08 at 18459c4)
+ tag: do not show non-tag contents with "-n"
+ tag: die when listing missing or corrupt objects
+ tag: fix output of "tag -n" when errors occur
Bugfixes to "git tag -n" that lacked much error checking.
Will merge to 'masster'.
* mm/empty-loose-error-message (2012-02-06) 1 commit
(merged to 'next' on 2012-02-07 at f119cac)
+ fsck: give accurate error message on empty loose object files
Updates the error message emitted when we see an empty loose object.
Will merge to 'masster'.
* jc/maint-commit-ignore-i-t-a (2012-02-07) 1 commit
(merged to 'next' on 2012-02-10 at e0040cf)
+ commit: ignore intent-to-add entries instead of refusing
Replaces the nd/commit-ignore-i-t-a series that was made unnecessary
complicated by bad suggestions I made earlier.
Will merge to 'masster'.
* jk/userdiff-config-simplify (2012-02-07) 1 commit
(merged to 'next' on 2012-02-10 at e9854c1)
+ drop odd return value semantics from userdiff_config
Code cleanup.
* nd/cache-tree-api-refactor (2012-02-07) 1 commit
(merged to 'next' on 2012-02-08 at a9abbca)
+ cache-tree: update API to take abitrary flags
Code cleanup.
* tg/tag-points-at (2012-02-08) 1 commit
(merged to 'next' on 2012-02-10 at 4bff88f)
+ tag: add --points-at list option
* jl/maint-submodule-relative (2012-02-09) 2 commits
- submodules: always use a relative path from gitdir to work tree
- submodules: always use a relative path to gitdir
The second one looked iffy.
* jn/merge-no-edit-fix (2012-02-09) 1 commit
(merged to 'next' on 2012-02-10 at 014eec9)
+ merge: do not launch an editor on "--no-edit $tag"
In 1.7.9, "merge --no-edit $tag" incorrectly ignored --no-edit.
* ld/git-p4-expanded-keywords (2012-02-09) 2 commits
- git-p4: initial demonstration of possible RCS keyword fixup
- git-p4: add test case for RCS keywords
Waiting for reviews and user reports.
* mp/make-cleanse-x-for-exe (2012-02-09) 1 commit
(merged to 'next' on 2012-02-09 at 35cc89d)
+ Explicitly set X to avoid potential build breakage
Will merge to 'master'.
* bw/inet-pton-ntop-compat (2012-02-05) 1 commit
(merged to 'next' on 2012-02-06 at 61303e6)
+ Drop system includes from inet_pton/inet_ntop compatibility wrappers
The inclusion order of header files bites Solaris again and this fixes it.
Will merge to 'master'.
* jc/checkout-out-of-unborn (2012-02-06) 1 commit
(merged to 'next' on 2012-02-07 at 60eb328)
+ git checkout -b: allow switching out of an unborn branch
I was fairly negative on this one, but Michael Haggerty and Peff convinced
me that selling this as "'checkout -b' that lack the <start point> is
about creating a new branch from my current state" is perfectly fine.
* jc/maint-mailmap-output (2012-02-06) 1 commit
(merged to 'next' on 2012-02-06 at 0a21425)
+ mailmap: always return a plain mail address from map_user()
map_user() was not rewriting its output correctly, which resulted in the
user visible symptom that "git blame -e" sometimes showed excess '>' at
the end of email addresses.
* tt/profile-build-fix (2012-02-09) 2 commits
(merged to 'next' on 2012-02-09 at 1c183af)
+ Makefile: fix syntax for older make
(merged to 'next' on 2012-02-07 at c8c5f3f)
+ Fix build problems related to profile-directed optimization
* nd/diffstat-gramnum (2012-02-03) 1 commit
(merged to 'next' on 2012-02-05 at 7335ecc)
+ Use correct grammar in diffstat summary line
The commands in the "git diff" family and "git apply --stat" that count
the number of files changed and the number of lines inserted/deleted have
been updated to match the output from "diffstat". This also opens the
door to i18n this line.
* jk/grep-binary-attribute (2012-02-02) 9 commits
(merged to 'next' on 2012-02-05 at 9dffa7e)
+ grep: pre-load userdiff drivers when threaded
+ grep: load file data after checking binary-ness
+ grep: respect diff attributes for binary-ness
+ grep: cache userdiff_driver in grep_source
+ grep: drop grep_buffer's "name" parameter
+ convert git-grep to use grep_source interface
+ grep: refactor the concept of "grep source" into an object
+ grep: move sha1-reading mutex into low-level code
+ grep: make locking flag global
Fixes a longstanding bug that there was no way to tell "git grep" that a
path may look like text but it is not, which "git diff" can do using the
attributes system. Now "git grep" honors the same "binary" (or "-diff")
attribute.
* jk/git-dir-lookup (2012-02-02) 1 commit
(merged to 'next' on 2012-02-05 at 1856d74)
+ standardize and improve lookup rules for external local repos
When you have both .../foo and .../foo.git, "git clone .../foo" did not
favor the former but the latter.
* jk/prompt-fallback-to-tty (2012-02-03) 2 commits
(merged to 'next' on 2012-02-06 at c0c995a)
+ prompt: fall back to terminal if askpass fails
+ prompt: clean up strbuf usage
The code to ask for password did not fall back to the terminal input when
GIT_ASKPASS is set but does not work (e.g. lack of X with GUI askpass
helper).
* jn/gitweb-search-utf-8 (2012-02-03) 1 commit
(merged to 'next' on 2012-02-05 at 055e446)
+ gitweb: Allow UTF-8 encoded CGI query parameters and path_info
Search box in "gitweb" did not accept non-ASCII characters correctly.
* fc/zsh-completion (2012-02-06) 3 commits
(merged to 'next' on 2012-02-06 at c94dd12)
+ completion: simplify __gitcomp and __gitcomp_nl implementations
+ completion: use ls -1 instead of rolling a loop to do that ourselves
+ completion: work around zsh option propagation bug
Fix git subcommand completion for zsh (in contrib/completion).
* nd/find-pack-entry-recent-cache-invalidation (2012-02-01) 2 commits
(merged to 'next' on 2012-02-01 at e26aed0)
+ find_pack_entry(): do not keep packed_git pointer locally
+ sha1_file.c: move the core logic of find_pack_entry() into fill_pack_entry()
* nd/pack-objects-parseopt (2012-02-01) 3 commits
(merged to 'next' on 2012-02-05 at d0dc25d)
+ pack-objects: convert to use parse_options()
+ pack-objects: remove bogus comment
+ pack-objects: do not accept "--index-version=version,"
"pack-objects" learned use parse-options, losing custom command line
parsing code.
^ permalink raw reply
* Re: git svn problem
From: Serhat Sevki Dincer @ 2012-02-11 0:52 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <4F358A53.8010409@vilain.net>
On Fri, Feb 10, 2012 at 11:21 PM, Sam Vilain <sam@vilain.net> wrote:
> Import them separately to different git-svn remotes, and once they are in
> the same repository you can graft them together using .git/info/grafts (see
> man gitrepository-layout). Once it looks right (check using 'gitk' etc),
> make it permanent using git filter-branch. You'll also want to remove the
> .git/svn directory, and re–run 'git svn fetch' so that git svn's revision
> database is recomputed. Don't forget the -A option to 'git svn fetch'!
That sounds too complicated. There should be an easier way (i hope:)
I have the following at the moment:
rm -rf plone.app.locales ; mkdir plone.app.locales ; cd plone.app.locales
git svn init -T trunk http://svn.plone.org/svn/plone/plone.app.locales
touch start ; git add start ; git commit -m start
git svn fetch -r49624:HEAD
git rebase --onto master --root trunk --preserve-merges
git checkout -b plone
plone branch looks good, now I would like to do the same with
collective/plone.app.locales. I tried a couple of things but ended up
getting errors like:
Rebuilding .git/svn/refs/remotes/trunk/.rev_map.db7f04ef-aaf3-0310-a811-c281ed44c4ad
...
Done rebuilding
.git/svn/refs/remotes/trunk/.rev_map.db7f04ef-aaf3-0310-a811-c281ed44c4ad
RA layer request failed: REPORT of '/svn/collective/!svn/vcc/default':
Could not read chunk size: connection was closed by server
(http://svn.plone.org) at /usr/lib/git-core/git-svn line 5131
Is there some way around these errors?
Thanks..
Serhat
^ permalink raw reply
* Re: [RFC/PATCH] tag: make list exclude !<pattern>
From: Tom Grennan @ 2012-02-11 2:16 UTC (permalink / raw)
To: pclouds; +Cc: git, gitster, krh, jasampler
In-Reply-To: <20120210185516.GA4903@tgrennan-laptop>
On Fri, 10 Feb 2012 10:55:16 -0800, Tom Grennan wrote:
>On Fri, Feb 10, 2012 at 01:34:26PM +0700, Nguyen Thai Ngoc Duy wrote:
>>On Fri, Feb 10, 2012 at 2:43 AM, Tom Grennan <tmgrennan@gmail.com> wrote:
>>> 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.
>>
>>git-branch, git-tag and git-for-each-ref are in the same family. I
>>think it's good to that all three commands share things, like this
>>pattern matching.
>
>Yes, git-branch and git-tag could now use a common match_patterns() but
>git-for-each-ref needs some rearranging; as will: git-describe,
>git-replace, git-ls-remote, git-name-rev, and git-show-branch.
>
>If we pursue this, it may be best to first add match_patterns() to ./refs.[ch]
>then incrementally modify these builtin commands to use it.
The following series implements !<pattern> with: git-tag, git-branch, and
git-for-each-ref.
This still requires Documentation and unit test updates but I think these are
close to functionally complete.
>>About the '!' for exclusion, maybe it's better to move from fnmatch()
>>as matching machinery to pathspec. Then when git learns negative
>>pathspec [1], we have this feature for free.
>>
>>[1] http://thread.gmane.org/gmane.comp.version-control.git/189645/focus=190072
After looking at this some more, I don't understand the value of replacing
libc:fnmatch(). Or are you just referring to '--exclude' instead of
[!]<pattern> argument parsing?
---
Tom Grennan (4):
refs: add common refname_match_patterns()
tag: use refs.c:refname_match_patterns()
branch: use refs.c:refname_match_patterns()
for-each-ref: use refs.c:refname_match_patterns()
Documentation/git-tag.txt | 10 ++++++----
builtin/branch.c | 16 ++--------------
builtin/for-each-ref.c | 23 +++--------------------
builtin/tag.c | 15 ++-------------
refs.c | 14 ++++++++++++++
refs.h | 8 ++++++++
6 files changed, 35 insertions(+), 51 deletions(-)
--
1.7.8
^ 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