* git svn can't handle giant commit
From: fREW Schmidt @ 2011-12-19 15:28 UTC (permalink / raw)
To: Git List
Hey guys,
I'm working on an import of some repos and I discovered that I can't
import a certain commit due to it's size. This is the commit:
http://perlcritic.tigris.org/source/browse/perlcritic?view=rev&revision=2676
Clearly it's large :-)
Anyway, here's the error message I get:
Svndiff data contains invalid instruction: Invalid diff stream:
[new] insn 4 overflows the new data section at
/opt/libexec/git-core/git-svn line 5653
This is not a deal breaker as I'm fairly sure I can do the clone in
pieces as opposed to from the root (I just did the root to get a list
of authors anyway) but it seems like there should be a way to handle
something like this...
--
fREW Schmidt
http://blog.afoolishmanifesto.com
^ permalink raw reply
* [PATCHv2 1/2] attr: map builtin userdiff drivers to well-known extensions
From: Jeff King @ 2011-12-19 15:49 UTC (permalink / raw)
To: git
Cc: Johannes Sixt, Junio C Hamano, Brandon Casey, Jonathan Nieder,
Philip Oakley
In-Reply-To: <20111217033808.GA8683@elie.hsd1.il.comcast.net>
We already provide sane hunk-header patterns for specific
languages.
However, the user has to manually map common extensions to
use them. It's not that hard to do, but it's an extra step
that the user might not even know is an option. Let's be
nice and do it automatically.
It could be a problem in the future if the builtin userdiff
drivers started growing more invasive options, like
automatically claiming to be non-binary (i.e., setting
diff.cpp.binary = false by default), but right now we do not
do that, so it should be safe. To help safeguard against
future changes, we add a new test to t4012 making sure that
we don't consider binary files as text by their extension.
We also have to update t4018, which assumed that without a
.gitattributes file, we would receive the default funcname
pattern for a file matching "*.java". This is not covering
up a regression, but rather the feature working as intended.
Signed-off-by: Jeff King <peff@peff.net>
---
This drops the objc mappings from v1. I still have no data on how much
worse the objc funcname performs on Matlab files, but I'd rather be
conservative until an objc person wants to show up and argue about it.
The C mappings are still here, but see the next patch.
attr.c | 22 ++++++++++++++++++++++
t/t4012-diff-binary.sh | 13 +++++++++++++
t/t4018-diff-funcname.sh | 10 +++++++++-
3 files changed, 44 insertions(+), 1 deletions(-)
diff --git a/attr.c b/attr.c
index 76b079f..10713f3 100644
--- a/attr.c
+++ b/attr.c
@@ -306,6 +306,28 @@ static void free_attr_elem(struct attr_stack *e)
static const char *builtin_attr[] = {
"[attr]binary -diff -text",
+ "*.html diff=html",
+ "*.htm diff=html",
+ "*.java diff=java",
+ "*.perl diff=perl",
+ "*.pl diff=perl",
+ "*.php diff=php",
+ "*.py diff=python",
+ "*.rb diff=ruby",
+ "*.bib diff=bibtex",
+ "*.tex diff=tex",
+ "*.c diff=cpp",
+ "*.cc diff=cpp",
+ "*.cxx diff=cpp",
+ "*.cpp diff=cpp",
+ "*.h diff=cpp",
+ "*.hpp diff=cpp",
+ "*.cs diff=csharp",
+ "*.[Ff] diff=fortran",
+ "*.[Ff][0-9][0-9] diff=fortran",
+ "*.pas diff=pascal",
+ "*.pp diff=pascal",
+ "*.lpr diff=pascal",
NULL,
};
diff --git a/t/t4012-diff-binary.sh b/t/t4012-diff-binary.sh
index 2d9f9a0..b2fc807 100755
--- a/t/t4012-diff-binary.sh
+++ b/t/t4012-diff-binary.sh
@@ -90,4 +90,17 @@ test_expect_success 'diff --no-index with binary creation' '
test_cmp expected actual
'
+test_expect_success 'binary files are not considered text by file extension' '
+ echo Q | q_to_nul >binary.c &&
+ git add binary.c &&
+ cat >expect <<-\EOF &&
+ diff --git a/binary.c b/binary.c
+ new file mode 100644
+ index 0000000..1f2a4f5
+ Binary files /dev/null and b/binary.c differ
+ EOF
+ git diff --cached binary.c >actual &&
+ test_cmp expect actual
+'
+
test_done
diff --git a/t/t4018-diff-funcname.sh b/t/t4018-diff-funcname.sh
index 4bd2a1c..a6227ef 100755
--- a/t/t4018-diff-funcname.sh
+++ b/t/t4018-diff-funcname.sh
@@ -124,7 +124,9 @@ do
done
test_expect_success 'default behaviour' '
- rm -f .gitattributes &&
+ cat >.gitattributes <<-\EOF &&
+ *.java diff=default
+ EOF
test_expect_funcname "public class Beer\$"
'
@@ -187,4 +189,10 @@ test_expect_success 'alternation in pattern' '
test_expect_funcname "public static void main("
'
+test_expect_success 'custom diff drivers override built-in extension matches' '
+ test_config diff.foo.funcname "int special" &&
+ echo "*.java diff=foo" >.gitattributes &&
+ test_expect_funcname "int special"
+'
+
test_done
--
1.7.8.rc2.38.gd9625
^ permalink raw reply related
* [PATCHv2 2/2] attr: drop C/C++ default extension mapping
From: Jeff King @ 2011-12-19 15:57 UTC (permalink / raw)
To: git
Cc: Johannes Sixt, Junio C Hamano, Brandon Casey, Jonathan Nieder,
Philip Oakley
In-Reply-To: <20111217033808.GA8683@elie.hsd1.il.comcast.net>
The point of this mapping is largely to get funcname
support. However, there's been some indication that our C
funcname pattern produces worse results than the default
pattern, so let's leave it unmapped for now.
If and when it improves, this commit can be reverted.
Signed-off-by: Jeff King <peff@peff.net>
---
Obviously this could just be squashed into the first patch. But I think
I'd rather leave a more explicit note in the history.
When writing the justification for this commit message, though, I did
notice that my reasoning is slightly flawed. The complaint is that the C
funcname pattern sucks, and therefore a user who hasn't configured
anything has a worse experience with patch 1. But enabling that sucky
experience is a two-step process:
1. map *.c, etc to the diff driver "cpp"
2. diff driver "cpp" has a funcname (which is reportedly bad)
Since this series is about tweaking extension mapping, the natural thing
to do is not enable (1).
But when you think about it, if our funcname pattern is bad, shouldn't
preventing (2) be the right thing? That is, if our funcname pattern is
really worse than the default language-agnostic match, wouldn't we be
doing everybody a service to simply remove the builtin
diff.cpp.xfuncname pattern?
Then you're not only not causing a regression for users who haven't
configured anything; you're actively helping people who have set
"diff=cpp" themselves.
Of course you're causing a regression to people who _like_ the current
diff.cpp.xfuncname. But if they are so widespread, then why is there so
much opposition to turning it on by default? My theory is that people
aren't actually using the builtin diff.cpp.xfuncname.
attr.c | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/attr.c b/attr.c
index 10713f3..2f33128 100644
--- a/attr.c
+++ b/attr.c
@@ -316,12 +316,6 @@ static void free_attr_elem(struct attr_stack *e)
"*.rb diff=ruby",
"*.bib diff=bibtex",
"*.tex diff=tex",
- "*.c diff=cpp",
- "*.cc diff=cpp",
- "*.cxx diff=cpp",
- "*.cpp diff=cpp",
- "*.h diff=cpp",
- "*.hpp diff=cpp",
"*.cs diff=csharp",
"*.[Ff] diff=fortran",
"*.[Ff][0-9][0-9] diff=fortran",
--
1.7.8.rc2.38.gd9625
^ permalink raw reply related
* Re: Escape character for .gitconfig
From: Dirk Süsserott @ 2011-12-19 15:59 UTC (permalink / raw)
To: Jeff King; +Cc: Erik Blake, git
In-Reply-To: <20111218095120.GA2290@sigill.intra.peff.net>
Am 18.12.2011 10:51 schrieb Jeff King:
> On Sun, Dec 18, 2011 at 08:53:09AM +0100, Erik Blake wrote:
>
[...]
>> Now, however, I have a different problem in that notepad++ is somehow
>> signalling git that editing is complete before I even get a chance to
>> edit the file. I am trying the command
>>> git commit --amend
[...]
>
> I know nothing about notepad++, but a quick google turned up the
> "-multiInst" option, which would avoid attaching to the existing
> instance. That might work for you.
>
> -Peff
Jeff is right! I also use notepad++ and have set
export GIT_EDITOR='notepad++ -multiInst'
in my .bashrc (msysGit). And btw: notepad++ DOES handle cr/lf. Look at
the "Format" menu.
Dirk
^ permalink raw reply
* Re: Re* How to generate pull-request with info of signed tag
From: Aneesh Kumar K.V @ 2011-12-19 16:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7viplfdlpb.fsf@alter.siamese.dyndns.org>
On Sat, 17 Dec 2011 11:47:44 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
>
> > Tested-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> >
> > -aneesh
>
> Thanks.
It would be nice to get the below working
git fetch git-url tag remote-tag-name:local-namespace/tag-name
That way we can make sure before merging i can cut-paste that url and
the local tag name i wish to store this to. And then do a git-merge.
-aneesh
^ permalink raw reply
* Re: How can I do an automatic stash when doing a checkout?
From: Dirk Süsserott @ 2011-12-19 16:18 UTC (permalink / raw)
To: DeMarcus; +Cc: git
In-Reply-To: <jckvpk$i8v$1@dough.gmane.org>
Am 18.12.2011 16:10 schrieb DeMarcus:
[...]
>>> With the git stash command I can clean the directory the way I want
>>> but the stash command is not connected to a particular branch.
>>>
>>> Is there a way to have git checkout do an automatic stash when doing a
>>> checkout to another branch, and then do an automatic git stash apply
>>> with the correct stash when changing back to the previous branch
>>> again?
>>
>> You probably don't want to use stash. Just commit whatever partial work
>> you've done.
>>
>
> It feels strange doing a commit of partial work. Some of the files may
> not even be supposed to be checked in.
>
>> You could also just checkout different branches in different
>> directories. Nothing wrong with doing that in git.
>>
>
> Ok thanks, that would give me the same behavior as I have today.
>
> However, I can see some benefits with have everything in the same
> directory as git allows compared to other VCSs. And since the stashing
> feature is already there in git, it would be nice if the git checkout
> with some flag could use stashing automatically.
>
>
DeMarcus,
probably a post-checkout hook could help you with autostashing, but that
would need some scripting. Have a look at "git hooks --help".
I sometimes use such a hook to auto-update submodules when checking out
a branch. To be fair: I don't know how to identify the "right" stash then.
And also have a look at the script "git-new-workdir". It comes with git
but in some contrib directory or so. It's not in the $PATH by default.
It allows different working dirs for different branches; some of my
co-workers use it and like it. It won't work with Windows, I guess,
because it makes use of symlinks.
Dirk
^ permalink raw reply
* [PATCH 4/3 v2 (bugfix)] gitweb: Fix fallback mode of to_utf8 subroutine
From: Jakub Narebski @ 2011-12-19 16:21 UTC (permalink / raw)
To: git; +Cc: Juergen Kreileder, Junio Hamano
In-Reply-To: <201112191311.58787.jnareb@gmail.com>
e5d3de5 (gitweb: use Perl built-in utf8 function for UTF-8 decoding.,
2007-12-04) was meant to make gitweb faster by using Perl's internals
(see subsection "Messing with Perl's Internals" in Encode(3pm) manpage)
Simple benchmark confirms that (old = 00f429a, new = this version):
note that it is synthetic benchmark of standalone subroutines, not
of gitweb itself (where probably no visible difference in performace
will show)
Rate old new
old 1582/s -- -64%
new 4453/s 181% --
Unfortunately it made fallback mode of to_utf8 do not work... except
for default value 'latin1' of $fallback_encoding (because 'latin1' is
Perl native encoding), which is probably why it was not noticed for so
long.
utf8::valid(STRING) is an internal function that tests whether STRING
is in a _consistent state_ regarding UTF-8. It returns true is
well-formed UTF-8 and has the UTF-8 flag on _*or*_ if string is held
as bytes (both these states are 'consistent').
For gitweb in most cases the second option was true, as output from
git commands is opened without ':utf8' layer. So utf8::valid is not
useful for to_utf8.
What made it look as if to_utf8() fallback mode worked correctly
(though only for $fallback_encoding at its default value 'latin1')
was the fact that utf8::decode(STRING) turns on UTF-8 flag only if
source string^W octets form a valid UTF-8 and it contains multi-byte
UTF-8 characters... this means that if string was not valid UTF-8
it didn't get UTF-8 flag.
When string doesn't have UTF-8 flag set, it is treated as if it was in
native Perl encoding, which is 'latin1' (unless native encoding is
EBCDIC ;-)). So it was ':utf8' layer that actually converted 'latin1'
(no UTF-8 flag == native == 'latin1) to 'utf8', and not to_utf8()
subroutine. Fallback mode was never triggered.
Let's make use of the fact that utf8::decode(STRING) returns false if
STRING is invalid as UTF-8 to check whether to enable fallback mode.
Note however that if STRING has UTF-8 flag set already, then
utf8::decode also returns false, which could cause problems if given
string was already converted with to_utf8(). Such double conversion
can happen in gitweb. Therefore we have to check if STRING has UTF-8
flag set with utf8::is_utf8(); if this subroutine returns true then we
have already decoded (converted) string, and don't have to do it
second time.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Jakub Narebski wrote:
> P.S. I started to get strange errors
>
> XML Parsing Error: xml processing instruction not at start of external entity
> Location: http://localhost/cgi-bin/gitweb/gitweb.cgi
> Line Number 37, Column 1:
> <?xml version="1.0" encoding="utf-8"?>
> ^
>
> while "show source" shows that '<?xml version="1.0" encoding="utf-8"?>'
> is the first line. WTF?!?
>
> P.P.S. Now I am getting errors when running gitweb, but only in some
> cases (via mod_cgi not as standalone script, only when using lynx),
> namely it looks like it falls back to 'latin1' when doing content
> which is valid UTF-8.
>
> Will investigate.
Now it is fixed; the error was caused by to_utf8 not dealing with double
encoding for strings outside 7bit ASCII.
gitweb/gitweb.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d24763b..fc41b07 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1443,8 +1443,8 @@ sub validate_refname {
sub to_utf8 {
my $str = shift;
return undef unless defined $str;
- if (utf8::valid($str)) {
- utf8::decode($str);
+
+ if (utf8::is_utf8($str) || utf8::decode($str)) {
return $str;
} else {
return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
--
1.7.6
^ permalink raw reply related
* Re: Infinite loop in cascade_filter_fn()
From: Carlos Martín Nieto @ 2011-12-19 16:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Henrik Grubbström, Git Mailing list
In-Reply-To: <7viplggoq9.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]
On Fri, Dec 16, 2011 at 02:01:50PM -0800, Junio C Hamano wrote:
> Carlos Martín Nieto <cmn@elego.de> writes:
>
> > Subject: [PATCHv2] convert: track state in LF-to-CRLF filter
> >
> > There may not be enough space to store CRLF in the output. If we don't
> > fill the buffer, then the filter will keep getting called with the same
> > short buffer and will loop forever.
> >
> > Instead, always store the CR and record whether there's a missing LF
> > if so we store it in the output buffer the next time the function gets
> > called.
> >
> > Reported-by: Henrik Grubbström <grubba@roxen.com>
> > Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
> > ---
> > convert.c | 50 +++++++++++++++++++++++++++++++++++++-------------
> > 1 files changed, 37 insertions(+), 13 deletions(-)
> >
> > diff --git a/convert.c b/convert.c
> > index 86e9c29..1c91409 100644
> > --- a/convert.c
> > +++ b/convert.c
> > @@ -876,24 +876,39 @@ int is_null_stream_filter(struct stream_filter *filter)
> > /*
> > * LF-to-CRLF filter
> > */
> > +
> > +struct lf_to_crlf_filter {
> > + struct stream_filter filter;
> > + int want_lf;
> > +};
> > +
> > static int lf_to_crlf_filter_fn(struct stream_filter *filter,
> > const char *input, size_t *isize_p,
> > char *output, size_t *osize_p)
> > {
> > - size_t count;
> > + size_t count, o = 0;
> > + struct lf_to_crlf_filter *lfcrlf = (struct lf_to_crlf_filter *) filter;
> > +
> > + /* Output a pending LF if we need to */
> > + if (lfcrlf->want_lf) {
> > + output[o++] = '\n';
> > + lfcrlf->want_lf = 0;
> > + }
> >
> > if (!input)
> > - return 0; /* we do not keep any states */
> > + return 0; /* We've already dealt with the state */
> > +
>
> Shouldn't we be decrementing *osize_p by 'o' to signal that we used that
> many bytes in the output buffer here before returning to the caller?
Yes we should, thanks for spotting it.
>
> > count = *isize_p;
> > if (count) {
> > - size_t i, o;
> > - for (i = o = 0; o < *osize_p && i < count; i++) {
> > + size_t i;
> > + for (i = 0; o < *osize_p && i < count; i++) {
> > char ch = input[i];
> > if (ch == '\n') {
> > - if (o + 1 < *osize_p)
> > - output[o++] = '\r';
> > - else
> > - break;
> > + output[o++] = '\r';
> > + if (o >= *osize_p) {
> > + lfcrlf->want_lf = 1;
> > + continue; /* We need to increase i */
> > + }
> > }
> > output[o++] = ch;
> > }
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Big Mess--How to use Git to resolve
From: Holger Hellmuth @ 2011-12-19 17:04 UTC (permalink / raw)
To: hs_glw; +Cc: git
In-Reply-To: <1324147247781-7104493.post@n2.nabble.com>
On 17.12.2011 19:40, hs_glw wrote:
> Randal, thank you for the comprehensive answer. I have one follow-up: we
> have the working files, then in our installation files we have .PL files
> that are worked on by some iteration of "make" to insert paths both into
> .cgi files and config files, should these installation files be setup as a
> branch? or is there a more correct way of implementing this?
If I understand you correctly the working aka source files are patched
in place to adapt to a customer. I would suggest changing that a bit so
that the source filename is different from the installation filename.
Add the source file into the repo and add the installation filenames
into .gitignore
That way you don't have generated files in the repository. Which is
usually avoided because they easily get out of sync with their source.
The renaming should be done so you never erraneously add installation
files into the repository in place of the source files
^ permalink raw reply
* Re: [PATCH] remote-curl: don't pass back fake refs
From: Jeff King @ 2011-12-19 17:10 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Junio C Hamano
In-Reply-To: <20111217104539.GA23844@sigill.intra.peff.net>
On Sat, Dec 17, 2011 at 05:45:39AM -0500, Jeff King wrote:
> Most of the time this bug goes unnoticed, as the fake ref
> won't match our refspecs. However, if "--mirror" is used,
> then we see it as remote cruft to be pruned, and try to pass
> along a deletion refspec for it. Of course this refspec has
> bogus syntax (because of the ^{}), and the helper complains,
> aborting the push.
>
> Let's have remote-curl mirror what the builtin
> get_refs_via_connect does (at least for the case of using
> git protocol; we can leave the dumb info/refs reader as it
> is).
I did some experimenting, and this also fixes another bug: pushing with
--mirror to a smart-http remote that uses alternates.
The fake ".have" refs that the server produces are similarly bogus and
should not be passed back from remote-curl to the parent git process.
Currently they are, so you get:
remote part of refspec is not a valid name in :.have
in the --mirror case.
I had thought this patch wouldn't make a difference there, since
get_remote_heads handles ".have" specifically before the check_refname
call. But it only does so if you pass in a non-NULL extra_have_objects
pointer. We do for regular git (since we care about the .haves for
efficiency, obviously).
But for smart-http, we actually end up parsing the refs twice: once to
get the list of refs to hand back to the parent git process, and then
again later in a send-pack subprocess that actually does care about the
.haves. In the first one, we just pass NULL for extra_have, and
get_remote_heads happily adds the bogus ones to the list.
For the same reason that this patch squelches the bogus "capability^{}",
it also squelches the bogus ".have" refs (but of course they are still
in our buffer to be handed to send-pack, so there is no loss of
efficiency).
Perhaps we should squash in the test below, which demonstrates the
breakage. I also wonder if this is maint-worthy.
-Peff
---
diff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh
index 89232b2..9b85d42 100755
--- a/t/t5541-http-push.sh
+++ b/t/t5541-http-push.sh
@@ -168,5 +168,23 @@ test_expect_success 'push --mirror can push to empty repo' '
git push --mirror "$HTTPD_URL"/smart/empty-mirror.git
'
+test_expect_success 'push --all to repo with alternates' '
+ s=$HTTPD_DOCUMENT_ROOT_PATH/test_repo.git &&
+ d=$HTTPD_DOCUMENT_ROOT_PATH/alternates-all.git &&
+ git clone --bare --shared "$s" "$d" &&
+ git --git-dir="$d" config http.receivepack true &&
+ git --git-dir="$d" repack -adl &&
+ git push --all "$HTTPD_URL"/smart/alternates-all.git
+'
+
+test_expect_success 'push --mirror to repo with alternates' '
+ s=$HTTPD_DOCUMENT_ROOT_PATH/test_repo.git &&
+ d=$HTTPD_DOCUMENT_ROOT_PATH/alternates-mirror.git &&
+ git clone --bare --shared "$s" "$d" &&
+ git --git-dir="$d" config http.receivepack true &&
+ git --git-dir="$d" repack -adl &&
+ git push --mirror "$HTTPD_URL"/smart/alternates-mirror.git
+'
+
stop_httpd
test_done
^ permalink raw reply related
* Re: Pushing with --mirror over HTTP?
From: Jeff King @ 2011-12-19 17:12 UTC (permalink / raw)
To: Eli Barzilay; +Cc: git
In-Reply-To: <20072.12104.965815.994761@winooski.ccs.neu.edu>
On Wed, Sep 07, 2011 at 10:58:16PM -0400, Eli Barzilay wrote:
> 5 hours ago, Jeff King wrote:
> > On Mon, Sep 05, 2011 at 12:05:37AM -0400, Eli Barzilay wrote:
> >
> > > Is there anything broken with pushing with mirror over HTTP? I'm
> > > trying that with a github url, and I get a broken-looking error
> > > message:
> > >
> > > remote part of refspec is not a valid name in :.have
> >
> > It's probably nothing to do with http, but rather with alternate
> > object databases on the server (which GitHub uses heavily). The
> > server hands out fake ".have" refs telling you it has some other
> > branch tips to base packs off of. So I suspect the "push --mirror"
> > code is simply wrong for trying to update those refs (it may be
> > exacerbated by using http, though, as the remote helper code seems
> > to have some extra checks).
Sorry for the very delayed response on your bug, but at least I have
good news. :)
It should be fixed by:
http://article.gmane.org/gmane.comp.version-control.git/187373
(I was trying to fix another bug there, but see my followup for a
discussion of .have).
-Peff
^ permalink raw reply
* Re: How can I do an automatic stash when doing a checkout?
From: Holger Hellmuth @ 2011-12-19 17:24 UTC (permalink / raw)
To: DeMarcus; +Cc: git
In-Reply-To: <jckvpk$i8v$1@dough.gmane.org>
On 18.12.2011 16:10, DeMarcus wrote:
>> You probably don't want to use stash. Just commit whatever partial work
>> you've done.
>>
>
> It feels strange doing a commit of partial work. Some of the files may
> not even be supposed to be checked in.
You have heard of "git commit --amend" ? Makes partial commits really
easy to work with.
^ permalink raw reply
* Re: [PATCHv2 1/2] attr: map builtin userdiff drivers to well-known extensions
From: Jonathan Nieder @ 2011-12-19 18:07 UTC (permalink / raw)
To: Jeff King
Cc: git, Johannes Sixt, Junio C Hamano, Brandon Casey, Philip Oakley
In-Reply-To: <20111219154938.GA19829@sigill.intra.peff.net>
Hi,
Two quick thoughts:
Jeff King wrote:
> The C mappings are still here, but see the next patch.
This is adding a regression in order to remove it. I guess it's
harmless, but I don't see the point.
[...]
> --- a/t/t4012-diff-binary.sh
> +++ b/t/t4012-diff-binary.sh
> @@ -90,4 +90,17 @@ test_expect_success 'diff --no-index with binary creation' '
> test_cmp expected actual
> '
>
> +test_expect_success 'binary files are not considered text by file extension' '
> + echo Q | q_to_nul >binary.c &&
> + git add binary.c &&
> + cat >expect <<-\EOF &&
> + diff --git a/binary.c b/binary.c
> + new file mode 100644
> + index 0000000..1f2a4f5
> + Binary files /dev/null and b/binary.c differ
> + EOF
> + git diff --cached binary.c >actual &&
> + test_cmp expect actual
Re the idea of this test: very good idea.
Re the mechanics: I would have been happier to see
echo Q | q_to_nul >binary.c &&
git add binary.c &&
git diff --cached binary.c >diff &&
grep Binary files diff
since that would avoid hard-coding some assumptions:
- the blob name of binary.c
- that [diff] mnemonicprefix defaults to false (I'd like to see the
default change to true)
- that [core] abbrev defaults to 7 (it probably won't change, but
it's a distracting detail, and if we were starting over 8 might be
a better default)
A bonus comment: :)
[...]
> --- a/t/t4018-diff-funcname.sh
> +++ b/t/t4018-diff-funcname.sh
> @@ -124,7 +124,9 @@ do
> done
>
> test_expect_success 'default behaviour' '
> - rm -f .gitattributes &&
> + cat >.gitattributes <<-\EOF &&
> + *.java diff=default
> + EOF
> test_expect_funcname "public class Beer\$"
> '
echo "*.java diff=default" >.gitattributes
would do the same with two lines fewer. :)
Thanks for working on this. I owe you a beer.
Jonathan
^ permalink raw reply
* Re: [PATCHv2 2/2] attr: drop C/C++ default extension mapping
From: Jonathan Nieder @ 2011-12-19 18:10 UTC (permalink / raw)
To: Jeff King
Cc: git, Johannes Sixt, Junio C Hamano, Brandon Casey, Philip Oakley
In-Reply-To: <20111219155737.GB19829@sigill.intra.peff.net>
Jeff King wrote:
> But when you think about it, if our funcname pattern is bad, shouldn't
> preventing (2) be the right thing? That is, if our funcname pattern is
> really worse than the default language-agnostic match, wouldn't we be
> doing everybody a service to simply remove the builtin
> diff.cpp.xfuncname pattern?
I don't see why. Anyone who has set "diff=cpp" either likes suffering
(maybe they are hoping to improve the pattern) or is working with a
codebase for which the current pattern works better than the default
behavior (maybe their codebase has a lot of goto labels aligned at
column zero). So removing the funcname pattern can only hurt them.
^ permalink raw reply
* Re: [PATCHv2 1/2] attr: map builtin userdiff drivers to well-known extensions
From: Jeff King @ 2011-12-19 18:55 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Johannes Sixt, Junio C Hamano, Brandon Casey, Philip Oakley
In-Reply-To: <20111219180733.GA12200@elie.hsd1.il.comcast.net>
On Mon, Dec 19, 2011 at 12:07:33PM -0600, Jonathan Nieder wrote:
> > The C mappings are still here, but see the next patch.
>
> This is adding a regression in order to remove it. I guess it's
> harmless, but I don't see the point.
It's purely an attempt to help somebody reading "git log" later
understand what happened. Maybe a comment in the commit message is more
appropriate.
> > +test_expect_success 'binary files are not considered text by file extension' '
> > + echo Q | q_to_nul >binary.c &&
> > + git add binary.c &&
> > + cat >expect <<-\EOF &&
> > + diff --git a/binary.c b/binary.c
> > + new file mode 100644
> > + index 0000000..1f2a4f5
> > + Binary files /dev/null and b/binary.c differ
> > + EOF
> > + git diff --cached binary.c >actual &&
> > + test_cmp expect actual
>
> Re the idea of this test: very good idea.
>
> Re the mechanics: I would have been happier to see
>
> echo Q | q_to_nul >binary.c &&
> git add binary.c &&
> git diff --cached binary.c >diff &&
> grep Binary files diff
Yeah, I think that's fine, and I'll squash it in to my local version.
It does miss one problem, though (that is also present in my original):
using "binary.c" is no longer a good name, since the next patch will
revert the "*.c" bits. :)
> > --- a/t/t4018-diff-funcname.sh
> > +++ b/t/t4018-diff-funcname.sh
> > @@ -124,7 +124,9 @@ do
> > done
> >
> > test_expect_success 'default behaviour' '
> > - rm -f .gitattributes &&
> > + cat >.gitattributes <<-\EOF &&
> > + *.java diff=default
> > + EOF
> > test_expect_funcname "public class Beer\$"
> > '
>
> echo "*.java diff=default" >.gitattributes
>
> would do the same with two lines fewer. :)
Yup. I was following the style of the test directly below, which sets
both java and perl drivers. But the "default" test that needed updating
only checks the java case.
Will squash.
> Thanks for working on this. I owe you a beer.
You're welcome. :)
-Peff
^ permalink raw reply
* Re: [PATCH] remote-curl: don't pass back fake refs
From: Junio C Hamano @ 2011-12-19 19:28 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce, Junio C Hamano
In-Reply-To: <20111219171055.GA21227@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Perhaps we should squash in the test below, which demonstrates the
> breakage. I also wonder if this is maint-worthy.
Thanks for a thorough analysis. I agree that this should go to maint even
more so, as it fixes a case to push to a non-empty repository.
^ permalink raw reply
* Re: Re* How to generate pull-request with info of signed tag
From: Junio C Hamano @ 2011-12-19 19:55 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Git Mailing List
In-Reply-To: <87iplch79e.fsf@linux.vnet.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> It would be nice to get the below working
>
> git fetch git-url tag remote-tag-name:local-namespace/tag-name
AFAIR "fetch tag $v" is a shorthand for "fetch refs/tags/$v:refs/tags/$"
invented back when Linus was the maintainer of Git. You can say
$ git fetch $url refs/tags/remote-tag-name:refs/tags/whatever-tag-name-you-want
to rename their tag to whatever name in your local repository.
Come to think of it, the last patch I sent out on request pull was very
wrong. The point of the recent change to allow you to pull this way
(notice the lack of "tag")
$ git pull $url $signed_tag_name
is so that you do not have to contaminate your own ref namespace with tags
that are used to leave audit trails in the history graph.
> That way we can make sure before merging i can cut-paste that url and
> the local tag name i wish to store this to. And then do a git-merge.
^ permalink raw reply
* Re: Re* How to generate pull-request with info of signed tag
From: Junio C Hamano @ 2011-12-19 20:06 UTC (permalink / raw)
To: Git Mailing List; +Cc: Aneesh Kumar K.V
In-Reply-To: <7vobv4mj4r.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Come to think of it, the last patch I sent out on request pull was very
> wrong....
And this should fix it.
-- >8 --
Subject: [PATCH] request-pull: do not emit "tag" before the tagname
The whole point of the recent update to allow "git pull $url $tagname" is
so that the integrator does not have to store the (signed) tag that is
used to convey authenticity to be recorded in the resulting merge in the
local repository's tag namespace. Asking for a merge be made with "git
pull $url tag $tagname" defeats it.
Note that the request can become ambiguous if the requestor has a branch
with the same name as the tag, but that is not a new problem limited to
pulling. I wouldn't mind if somebody wants to add disambiguation to the
find_matching_ref logic in the script as a separate patch, though.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-request-pull.sh | 4 +---
t/t5150-request-pull.sh | 2 +-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index 7b5c777..d7ba117 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -63,10 +63,8 @@ die "fatal: No commits in common between $base and $head"
find_matching_ref='
sub abbr {
my $ref = shift;
- if ($ref =~ s|refs/heads/||) {
+ if ($ref =~ s|refs/heads/|| || $ref =~ s|refs/tags/||) {
return $ref;
- } elsif ($ref =~ s|refs/tags/||) {
- return "tag $ref";
} else {
return $ref;
}
diff --git a/t/t5150-request-pull.sh b/t/t5150-request-pull.sh
index aec842f..da25bc2 100755
--- a/t/t5150-request-pull.sh
+++ b/t/t5150-request-pull.sh
@@ -180,7 +180,7 @@ test_expect_success 'request names an appropriate branch' '
read branch
} <digest &&
{
- test "$branch" = tag--full ||
+ test "$branch" = full ||
test "$branch" = master ||
test "$branch" = for-upstream
}
--
1.7.8.370.gb3269
^ permalink raw reply related
* Re: [PATCH 2/2] push: hint to use push.default=upstream when appropriate
From: Junio C Hamano @ 2011-12-19 20:16 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111219103746.GB1736@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> It seems like the real problem is that they are on branch "foo", but the
> matching behavior tried to push "bar", which didn't work. And we are
> worried that they may be surprised that we even attempted to push "bar"
> at all.
Of we may be seeing a non-fast-forward on 'foo' itself, which is your
1. below.
> And that probably happened because of the situation you describe, but we
> (and the user) don't have to think about that. We can just think about
> the more immediate mistake of "oops, I didn't want to push 'bar'".
>
> Which leads me to two ideas:
>
> 1. This is not good advice to give when pushing the _current_ branch
> failed due to non-ff. Setting push.default to "upstream" would
> probably yield the same error. We should probably tighten the
> condition for showing this message to when a non-HEAD branch failed
> to fast-forward.
>
> 2. The text should focus on the (possible) local misconfiguration, not
> the repo setup.
OK, I think we are in agreement.
> So maybe something like:
>
> By default, git pushes all branches that have a matching counterpart
> on the remote. In this case, some of your local branches were stale
> with respect to their remote counterparts. If you did not intend to
> push these branches, you may want to set the 'push.default'
> configuration variable to 'upstream' to push only the current branch.
>
> I'm not 100% happy with that text, but I think you can see the direction
> I am talking about.
As long as we can tighten the condition further to ensure that the advice
above is triggered only when appropriate, I actually am 100% happy with
that text. Seeing others do the real work for me always makes me happy ;-)
In addition to "did we use default-matching?", we should use "did we get
non-fast-forward error on a branch that is _not_ the current one?" instead
of the "did we get any non-fast-forward error?" in my patch, and the text
should match the situation more-or-less exactly.
> ... If we follow my suggestion above and
> only print this message for non-HEAD refs, then these two messages
> become an either/or situation, I think. If the HEAD failed to
> fast-forward, then the right advice is probably "git pull && git push".
> If a non-HEAD failed, then the right advice is either "git checkout $X
> && git pull && git push" or "here's how to avoid accidentally pushing
> $X".
>
> So the logic would be something like:
>
> if (nonfastforward == NONFASTFORWARD_HEAD)
> advise_pull_before_push();
> else if (nonfastforward == NONFASTFORWAD_OTHER) {
> if (default_matching_used)
> advise_use_upstream();
> else
> advise_checkout_pull_push();
> }
Sounds good. Spelling things out at this detail would let others who may
be interested in getting their hands dirty try to come up with an updated
patch ;-).
Thanks.
^ permalink raw reply
* Re: git 1.7.7.5
From: Junio C Hamano @ 2011-12-19 20:22 UTC (permalink / raw)
To: Thomas Jarosch; +Cc: Jonathan Nieder, git
In-Reply-To: <201112191041.07629.thomas.jarosch@intra2net.com>
Thomas Jarosch <thomas.jarosch@intra2net.com> writes:
> On Friday, 16. December 2011 11:57:58 Jonathan Nieder wrote:
>> I noticed that v1.7.7.5 was tagged a few days ago (b36dcd72), but
>> there is no corresponding tarball at
>>
>> http://code.google.com/p/git-core/downloads/list
>>
>> Will there be an official tarball?
>>
>> I don't mind either way, but it would be useful to know whether
>> distributors should make their own or just wait.
>
> Looks like a bug, the front page of "git-scm.com" also shows 1.7.7.5
> as latest stable release and leads to a dead link.
There actually is no bug; I just haven't got around to generating signed
tarballs yet.
I tend to agree that after 1.7.8 was released, showing 1.7.7.5 as the
latest stable indeed a bug (1.7.8 is still the latest stable and the next
latest stable will be 1.7.8.1), but that site is not under my direct
control, so...
^ permalink raw reply
* Re: [PATCH] lf_to_crlf_filter(): tell the caller we added "\n" when draining
From: Junio C Hamano @ 2011-12-19 20:23 UTC (permalink / raw)
To: Henrik Grubbström; +Cc: Git Mailing list, Carlos Martín Nieto
In-Reply-To: <Pine.GSO.4.63.1112191114010.4136@shipon.roxen.com>
Henrik Grubbström <grubba@roxen.com> writes:
> We probably ought to have a corresponding test in the testsuite.
> A blob consisting of a singe 'A' followed by 8192 linefeeds should
> be sufficient to trigger the problems.
Sounds good. Please make it so.
^ permalink raw reply
* Re: [PATCHv2 2/2] attr: drop C/C++ default extension mapping
From: Thomas Rast @ 2011-12-19 20:51 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Jeff King, git, Johannes Sixt, Junio C Hamano, Brandon Casey,
Philip Oakley
In-Reply-To: <20111219181003.GB12200@elie.hsd1.il.comcast.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Jeff King wrote:
>
>> But when you think about it, if our funcname pattern is bad, shouldn't
>> preventing (2) be the right thing? That is, if our funcname pattern is
>> really worse than the default language-agnostic match, wouldn't we be
>> doing everybody a service to simply remove the builtin
>> diff.cpp.xfuncname pattern?
>
> I don't see why. Anyone who has set "diff=cpp" either likes suffering
> (maybe they are hoping to improve the pattern) or is working with a
> codebase for which the current pattern works better than the default
> behavior (maybe their codebase has a lot of goto labels aligned at
> column zero). So removing the funcname pattern can only hurt them.
FWIW, the funcname pattern is not the only feature of the diff
attributes. I set it mainly to get the built-in --word-diff split
regexes.
I agree with Peff's patches though, until the cpp pattern improves, we
should not turn them on by default.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH] t4018: introduce test cases for the internal hunk header patterns
From: Brandon Casey @ 2011-12-19 20:52 UTC (permalink / raw)
To: peff; +Cc: git, j6t, gitster, jrnieder, Brandon Casey
In-Reply-To: <20111217012118.GB20225@sigill.intra.peff.net>
From: Brandon Casey <drafnel@gmail.com>
Recently it has been pointed out that one or more of the internal hunk
header patterns are sub-optimal. Specifically, the C/C++ "cpp" pattern was
called out.
Let's introduce some infrastructure to make it easy to create test cases
for the hunk header patterns and provide a few cases for the cpp pattern.
* new test cases can be dropped into the t4018 directory
* filenames end with the pattern name e.g. .cpp .objc .matlab etc.
* filenames should be descriptive since it will be used in the test
suite output
* broken test cases should be given a filename prefixed with "broken_"
* test cases must provide a function named "RIGHT_function_hunk_header"
- this is the function name that should appear on the hunk header line
- the body of this function should have an assignment like
answer = 0
The test suite will modify the above line to produce a difference
from the original. Additionally, this should be far enough within
the body of the function so that the function name is not part of
the lines of context.
Example test case:
int WRONG_function_hunk_header (void)
{
return 0;
}
int RIGHT_function_hunk_header (void)
{
/*
* Filler
* Filler
* Filler
*/
int answer = 0;
return 0;
}
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
On Fri, Dec 16, 2011 at 7:21 PM, Jeff King <peff@peff.net> wrote:
> On Fri, Dec 16, 2011 at 11:05:27PM +0100, Johannes Sixt wrote:
>
<snip>
>> ... in order to ultimately
>> improve the built-in pattern. The topic came up just the other day, and
>> I took Thomas Rast's suggestion to experiment with a simplified pattern:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/186355/focus=186439
>>
>> But as is, the built-in pattern misses way too many anchor points in C++
>> code.
>
> Yeah, I can certainly agree that the patterns could be better.
>
> Maybe we should just table the extension mapping for now, then, and see
> if the patterns improve? Or maybe just drop the C ones (and probably the
> objc one based on other parts of the thread) and do the rest?
/methinks t4018 needs to be greatly expanded. There is no way to tell what
is currently broken by the current pattern, or what is newly broken by a
new pattern.
How about this for a start?
-Brandon
t/t4018-diff-funcname.sh | 18 ++++++++++++
t/t4018/broken_class_constructor.cpp | 34 +++++++++++++++++++++++
t/t4018/broken_class_destructor.cpp | 34 +++++++++++++++++++++++
t/t4018/broken_gnu_style.cpp | 35 +++++++++++++++++++++++
t/t4018/broken_reference.cpp | 34 +++++++++++++++++++++++
t/t4018/broken_template.cpp | 34 +++++++++++++++++++++++
t/t4018/class_method.cpp | 34 +++++++++++++++++++++++
t/t4018/simple.cpp | 50 ++++++++++++++++++++++++++++++++++
t/t4018/static.cpp | 34 +++++++++++++++++++++++
9 files changed, 307 insertions(+), 0 deletions(-)
create mode 100644 t/t4018/broken_class_constructor.cpp
create mode 100644 t/t4018/broken_class_destructor.cpp
create mode 100644 t/t4018/broken_gnu_style.cpp
create mode 100644 t/t4018/broken_reference.cpp
create mode 100644 t/t4018/broken_template.cpp
create mode 100644 t/t4018/class_method.cpp
create mode 100644 t/t4018/simple.cpp
create mode 100644 t/t4018/static.cpp
diff --git a/t/t4018-diff-funcname.sh b/t/t4018-diff-funcname.sh
index 4bd2a1c..5a1f7b7 100755
--- a/t/t4018-diff-funcname.sh
+++ b/t/t4018-diff-funcname.sh
@@ -121,6 +121,24 @@ do
! grep fatal msg &&
! grep error msg
'
+
+ for f in "$TEST_DIRECTORY"/t4018/*.$p; do
+ test -f "$f" || continue
+ name=`basename "$f" .$p`
+ test_expect_which=test_expect_success
+ if test "$name" != "${name#broken_}"; then
+ name=${name#broken_}
+ test_expect_which=test_expect_failure
+ fi
+ $test_expect_which \
+ "builtin $p pattern works correctly for $name case" "
+ echo \"*.$p diff=$p\" >.gitattributes &&
+ sed -e 's/answer = 0/answer = 42/' < \"$f\" > \"$name.$p\" &&
+ test_expect_code 1 git diff --no-index \"$f\" \
+ \"$name.$p\" >actual &&
+ egrep '^@@ .* @@ .*RIGHT_function_hunk_header' actual
+ "
+ done
done
test_expect_success 'default behaviour' '
diff --git a/t/t4018/broken_class_constructor.cpp b/t/t4018/broken_class_constructor.cpp
new file mode 100644
index 0000000..1e4cb9c
--- /dev/null
+++ b/t/t4018/broken_class_constructor.cpp
@@ -0,0 +1,34 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+RIGHT_function_hunk_header::RIGHT_function_hunk_header (void)
+{
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ int answer = 0;
+
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ return answer;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/broken_class_destructor.cpp b/t/t4018/broken_class_destructor.cpp
new file mode 100644
index 0000000..84d9506
--- /dev/null
+++ b/t/t4018/broken_class_destructor.cpp
@@ -0,0 +1,34 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+RIGHT_function_hunk_header::~RIGHT_function_hunk_header (void)
+{
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ int answer = 0;
+
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ return answer;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/broken_gnu_style.cpp b/t/t4018/broken_gnu_style.cpp
new file mode 100644
index 0000000..ffba9b9
--- /dev/null
+++ b/t/t4018/broken_gnu_style.cpp
@@ -0,0 +1,35 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+int
+RIGHT_function_hunk_header (void)
+{
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ int answer = 0;
+
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ return answer;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/broken_reference.cpp b/t/t4018/broken_reference.cpp
new file mode 100644
index 0000000..ea90b82
--- /dev/null
+++ b/t/t4018/broken_reference.cpp
@@ -0,0 +1,34 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+int& RIGHT_function_hunk_header (void)
+{
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ int answer = 0;
+
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ return answer;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/broken_template.cpp b/t/t4018/broken_template.cpp
new file mode 100644
index 0000000..95a6dd5
--- /dev/null
+++ b/t/t4018/broken_template.cpp
@@ -0,0 +1,34 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+template <class T> int RIGHT_function_hunk_header (T unused)
+{
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ int answer = 0;
+
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ return answer;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/class_method.cpp b/t/t4018/class_method.cpp
new file mode 100644
index 0000000..2e51853
--- /dev/null
+++ b/t/t4018/class_method.cpp
@@ -0,0 +1,34 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+int test_class::RIGHT_function_hunk_header (void)
+{
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ int answer = 0;
+
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ return answer;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/simple.cpp b/t/t4018/simple.cpp
new file mode 100644
index 0000000..b8fca06
--- /dev/null
+++ b/t/t4018/simple.cpp
@@ -0,0 +1,50 @@
+/*
+ * Test file for testing the internal hunk header patterns
+ *
+ * The "RIGHT" hunk header function, the one that should appear on the
+ * hunk header line, should be named "RIGHT_function_hunk_header" and
+ * the body of this function should have an assignment that looks like
+ *
+ * answer = 0
+ *
+ * within it, deep enough so the lines of context do not include the
+ * function name.
+ *
+ * If the name of this file begins with "broken_", then it will be
+ * interpreted as a pattern which does not work, but which should.
+ */
+
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+int RIGHT_function_hunk_header (void)
+{
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ int answer = 0;
+
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ return answer;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/static.cpp b/t/t4018/static.cpp
new file mode 100644
index 0000000..fcc48f2
--- /dev/null
+++ b/t/t4018/static.cpp
@@ -0,0 +1,34 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+static int RIGHT_function_hunk_header (void)
+{
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ int answer = 0;
+
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ return answer;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
--
1.7.7.4
^ permalink raw reply related
* Re: [PATCH] remote-curl: don't pass back fake refs
From: Jeff King @ 2011-12-19 21:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce
In-Reply-To: <7vty4wmkdt.fsf@alter.siamese.dyndns.org>
On Mon, Dec 19, 2011 at 11:28:14AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Perhaps we should squash in the test below, which demonstrates the
> > breakage. I also wonder if this is maint-worthy.
>
> Thanks for a thorough analysis. I agree that this should go to maint even
> more so, as it fixes a case to push to a non-empty repository.
Do you want to squash in those tests, or should I re-send with a commit
message more fully explaining the situation?
-Peff
^ permalink raw reply
* Re: [PATCH] remote-curl: don't pass back fake refs
From: Junio C Hamano @ 2011-12-19 21:28 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20111219211203.GA18396@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Dec 19, 2011 at 11:28:14AM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > Perhaps we should squash in the test below, which demonstrates the
>> > breakage. I also wonder if this is maint-worthy.
>>
>> Thanks for a thorough analysis. I agree that this should go to maint even
>> more so, as it fixes a case to push to a non-empty repository.
>
> Do you want to squash in those tests, or should I re-send with a commit
> message more fully explaining the situation?
I was lazy and added these three lines at the end:
This also fixes pushing with --mirror to a smart-http remote that uses
alternates. The fake ".have" refs the server gives to avoid unnecessary
network transfer has a similar bad interactions with the machinery.
but it may warrant a more thorough write-up there.
^ 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