* 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
* Re: [PATCH] remote-curl: don't pass back fake refs
From: Jeff King @ 2011-12-19 21:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce
In-Reply-To: <7v39cgmety.fsf@alter.siamese.dyndns.org>
On Mon, Dec 19, 2011 at 01:28:09PM -0800, Junio C Hamano wrote:
> > 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.
I think that's probably enough. I could restructure the whole text to
talk less about capabilities^{} and more about generically preventing
fake refs, but I really don't think there's much point.
-Peff
^ permalink raw reply
* Re: git-svn: multiple fetch lines
From: Nathan Gray @ 2011-12-19 21:40 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Eric Wong
In-Reply-To: <20111217100521.GA12610@elie.hsd1.il.comcast.net>
Hi,
On Sat, Dec 17, 2011 at 2:05 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi Nathan,
>
> Nathan Gray wrote:
>
>> I'm in a conversation with the support fellow of the very nice Tower
>> git interface for OS X and we need clarification on a point. Does
>> git-svn explicitly support multiple "fetch =" lines in an svn-remote
>> section or is it just an accident that it works? My belief is that
>> such support is intended and his is that it is accidental.
>
> It's true that the documentation is not as clear about this as one
> might like. Documentation/git-svn.txt leaves it to the reader to
> infer that this is supported by analogy with "fetch =" lines in native
> git [remote] sections:
Thanks Jonathan, that's just what I suspected.
[snip]
> Perhaps such an example would be useful for the git-svn(1) manpage,
> too. Any ideas for where to add such a note, and how it should be
> worded? (Of course, if you can phrase such an idea in patch form,
> that would be the most convenient.)
The existing CONFIGURATION section of the man page seems like a
sensible place to mention multiple fetch entries. I've also found the
documentation on creating branches in the presence of multiple branch
keys to be confusing and in need of an example, so maybe that could go
in as well. How about something along these lines:
"""
In order to simplify working with messy subversion repositories you
can configure multiple fetch, branches, and tags keys. For example:
[svn-remote "messy-repo"]
url = http://server.org/svn
fetch = trunk/project-a:refs/remotes/project-a/trunk
fetch = branches/demos/june-project-a-demo:refs/remotes/project-a/demos/june-demo
branches = branches/server/*:refs/remotes/project-a/branches/*
branches = branches/demos/2011/*:refs/remotes/project-a/2011-demos/*
tags = tags/server/*:refs/remotes/project-a/tags/*
To create a branch in this configuration you need to specify the
location for the new branch using the -d or --destination flag. For
example:
git svn branch -d wtf-goes-here-anyway?? release-2-3-0
"""
The thing about the -d option that confuses me is that I'm not sure if
I'm supposed to be supplying a full svn path, a partial svn path, the
glob from the config file, etc. An example would make it obvious.
Personally, I always take the coward's way out and comment out the
extra branches keys, make the branch without -d, then restore them in
order to avoid any potential problems. :^)
Thanks,
-Nathan
--
HexaLex: A New Angle on Crossword Games for iPhone and iPod Touch
http://hexalex.com
On The App Store: http://bit.ly/8Mj1CU
On Facebook: http://bit.ly/9MIJiV
On Twitter: http://twitter.com/hexalexgame
http://n8gray.org
^ permalink raw reply
* Re: How can I do an automatic stash when doing a checkout?
From: DeMarcus @ 2011-12-19 21:43 UTC (permalink / raw)
To: git
In-Reply-To: <4EEF63CA.4030201@dirk.my1.cc>
On 2011-12-19 17:18, Dirk Süsserott wrote:
> 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.
>
Thanks! I'll check that out. Maybe the right stash could be checked-in
itself somehow.
^ permalink raw reply
* Re: How can I do an automatic stash when doing a checkout?
From: DeMarcus @ 2011-12-19 21:46 UTC (permalink / raw)
To: git
In-Reply-To: <4EEF736A.4070802@ira.uka.de>
On 2011-12-19 18:24, Holger Hellmuth wrote:
> 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.
>
>
Yes, I know that one. It's just that I know myself, I don't really like
to go back rearranging. I prefer to keep things spread out at first and
then inserted properly when it's time. But maybe I'm just unused to the
git workflow.
^ permalink raw reply
* [PATCH] t4018: add a few more test cases for cpp hunk header matching
From: Brandon Casey @ 2011-12-19 21:53 UTC (permalink / raw)
To: peff; +Cc: git, j6t, gitster, jrnieder, trast, Brandon Casey
In-Reply-To: <31E9klcRboMV0wSJY5WO-N7nIBOUOa_wr6MVfWY9AInImxJIqC0flahvpDrVGMIuZ9e7Ouha1HDuesbwTGaNQA4dgN-FShNJKkfMG_cHLUJAT2rE539shnQxzM0dQyZIb5661As6Tvs@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
Add one case for matching a function returning a pointer.
Plus add examples of things we explicitly do not match:
labels
function declarations
global variable declarations
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
This can be squashed into the original patch with the other test cases.
This just introduces a few more cases pointed out by Thomas Rast in the
email Johannes referenced.
http://thread.gmane.org/gmane.comp.version-control.git/186355/focus=186439
Also, note that all of the tests pass except for ignore_global.cpp with
Johannes's pattern:
"!^[ \\t]*[a-zA-Z_][a-zA-Z_0-9]*[^()]*:[[:space:]]*$\n^[a-zA-Z_][a-zA-Z_0-9]*.*"
-Brandon
t/t4018/ignore_declaration.cpp | 35 +++++++++++++++++++++++++++++++++++
t/t4018/ignore_global.cpp | 36 ++++++++++++++++++++++++++++++++++++
t/t4018/ignore_label.cpp | 35 +++++++++++++++++++++++++++++++++++
t/t4018/pointer_return.cpp | 34 ++++++++++++++++++++++++++++++++++
4 files changed, 140 insertions(+), 0 deletions(-)
create mode 100644 t/t4018/ignore_declaration.cpp
create mode 100644 t/t4018/ignore_global.cpp
create mode 100644 t/t4018/ignore_label.cpp
create mode 100644 t/t4018/pointer_return.cpp
diff --git a/t/t4018/ignore_declaration.cpp b/t/t4018/ignore_declaration.cpp
new file mode 100644
index 0000000..615aea0
--- /dev/null
+++ b/t/t4018/ignore_declaration.cpp
@@ -0,0 +1,35 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+int RIGHT_function_hunk_header (void)
+{
+ void WRONG_function_declaration_within_body (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/ignore_global.cpp b/t/t4018/ignore_global.cpp
new file mode 100644
index 0000000..df6b8aa
--- /dev/null
+++ b/t/t4018/ignore_global.cpp
@@ -0,0 +1,36 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+int RIGHT_function_hunk_header (void)
+{
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ return answer;
+}
+
+int WRONG_global_variable;
+
+/*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+int answer = 0;
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/ignore_label.cpp b/t/t4018/ignore_label.cpp
new file mode 100644
index 0000000..2e3ce10
--- /dev/null
+++ b/t/t4018/ignore_label.cpp
@@ -0,0 +1,35 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+int RIGHT_function_hunk_header (void)
+{
+WRONG_should_not_match_label:
+ /*
+ * 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/pointer_return.cpp b/t/t4018/pointer_return.cpp
new file mode 100644
index 0000000..fd85545
--- /dev/null
+++ b/t/t4018/pointer_return.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: How can I do an automatic stash when doing a checkout?
From: Junio C Hamano @ 2011-12-19 22:24 UTC (permalink / raw)
To: DeMarcus; +Cc: git
In-Reply-To: <jcobbo$jab$1@dough.gmane.org>
DeMarcus <demarcus@hotmail.com> writes:
> ... I don't really like to go back rearranging. I prefer to keep things
> spread out at first and then inserted properly when it's time. But maybe
> I'm just unused to the git workflow.
That does not have to do much with "the" git workflow.
If you are a kind of person who likes to work on N things concurrently
without ever making and recording mistakes but would rather keep
unfinished work without committing until done, you would need to have them
in your working trees. By definition you would need to use N working
trees, each of which permanently checks out its own branch, instead of a
single working tree where you checkout one of N branches at a time to work
on.
That is also a perfectly fine git workflow that we support with the
contributed script git-new-workdir.
^ permalink raw reply
* Re: [PATCH] t4018: introduce test cases for the internal hunk header patterns
From: Junio C Hamano @ 2011-12-19 22:37 UTC (permalink / raw)
To: Brandon Casey; +Cc: peff, git, j6t, jrnieder, Brandon Casey
In-Reply-To: <31E9klcRboMV0wSJY5WO-N7nIBOUOa_wr6MVfWY9AInImxJIqC0flahvpDrVGMIuZ9e7Ouha1HDuesbwTGaNQA4dgN-FShNJKkfMG_cHLUJAT2rE539shnQxzM0dQyZIb5661As6Tvs@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> * 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_"
Cute. I like the general idea.
> * 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.
Although I do not think of any language with a syntax rule where that the
overlong RIGHT_func... token is an illegal symbol offhand, this feels a
bit _too_ specific to the C language. I would prefer something like this
instead:
* a test case must have one (and only one) line that contains "RIGHT"
(all uppercase) and that line should become the hunk header for the
test to succeed.
* after the line that contains "RIGHT" token, there should be one (and
only one) line that contains "ChangeMe". The test modifies this
token to "IWasChanged", compares the original with the modified
result, and expects the "RIGHT" token above appears on the hunk
header.
Also I would prefer not to require "enough filler", as we might want to
enhance the logic to consider using a line in the pre-context as the hunk
header in some cases, e.g.
@@ ... @@ int RIGHT_function_hunk_header(void)
int RIGHT_function_hunk_header(void)
{
- int ChangeME;
+ int IWasChanged;
printf("Hello, world\n");
return 0;
}
@@ ...
^ permalink raw reply
* Re: [PATCH] t4018: introduce test cases for the internal hunk header patterns
From: Brandon Casey @ 2011-12-19 22:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brandon Casey, peff, git, j6t, jrnieder
In-Reply-To: <7vty4wkx19.fsf@alter.siamese.dyndns.org>
On Mon, Dec 19, 2011 at 4:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>> * 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.
>
> Although I do not think of any language with a syntax rule where that the
> overlong RIGHT_func... token is an illegal symbol offhand, this feels a
> bit _too_ specific to the C language.
Good point. "RIGHT_function_hunk_header" doesn't really have much
meaning for non-programming language patterns like tex and html.
> I would prefer something like this
> instead:
>
> * a test case must have one (and only one) line that contains "RIGHT"
> (all uppercase) and that line should become the hunk header for the
> test to succeed.
>
> * after the line that contains "RIGHT" token, there should be one (and
> only one) line that contains "ChangeMe". The test modifies this
> token to "IWasChanged", compares the original with the modified
> result, and expects the "RIGHT" token above appears on the hunk
> header.
Both good improvements.
> Also I would prefer not to require "enough filler", as we might want to
> enhance the logic to consider using a line in the pre-context as the hunk
> header in some cases, e.g.
>
> @@ ... @@ int RIGHT_function_hunk_header(void)
>
> int RIGHT_function_hunk_header(void)
> {
> - int ChangeME;
> + int IWasChanged;
> printf("Hello, world\n");
> return 0;
> }
> @@ ...
Yeah, I didn't mean to imply that "enough filler" was a requirement of
the test, just trying to point out the requirement imposed by the hunk
header logic. I'll remove this statement.
Will reroll.
-Brandon
^ permalink raw reply
* Re: [PATCH] t4018: introduce test cases for the internal hunk header patterns
From: Junio C Hamano @ 2011-12-19 23:17 UTC (permalink / raw)
To: Brandon Casey; +Cc: Brandon Casey, peff, git, j6t, jrnieder
In-Reply-To: <CA+sFfMeogJ==ud6NdPj_KZFUKFeB--RBmPkLndjrQwhg15V5ig@mail.gmail.com>
Brandon Casey <drafnel@gmail.com> writes:
>> * after the line that contains "RIGHT" token, there should be one (and
>> only one) line that contains "ChangeMe". The test modifies this
>> token to "IWasChanged", compares the original with the modified
>> result, and expects the "RIGHT" token above appears on the hunk
>> header.
>
> Both good improvements.
Let's not call "ChangeMe" a *token*, as I think the easiest example would
look like the following and it would not use it as such. Rephrasing it as
a "string" would be better.
@@ ... @@ int RIGHT_function_hunk_header(void)
int RIGHT_function_hunk_header(void)
{
- const char *msg = "ChangeME";
+ const char *msg = "IWasChanged";
printf("Hello, world, %s\n", msg);
return 0;
}
@@ ...
^ permalink raw reply
* Re: git 1.7.7.5
From: Junio C Hamano @ 2011-12-20 0:03 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20111216105757.GA11174@elie.hsd1.il.comcast.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> 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.
I personally would prefer distros to get stuff from the tagged release
point directly from SCM themselves, instead of using tarballs, but anyway
I've uploaded both 1.7.7.5 and 1.7.6.5 tarballs.
Thanks.
^ permalink raw reply
* Introducing vcsh - manage config files in $HOME via fake bare git repositories
From: Richard Hartmann @ 2011-12-20 0:17 UTC (permalink / raw)
To: Git List
Hi all,
some of you may be familiar with fake bare git repositories[1].
Basically, they allow you to keep the git directory and its working
directory separate from each other. This allows you to have an
arbitrary number of repositories with working trees in $HOME. That, in
turn, allows you to have one repo for zsh, one for vim, one for git,
etc pp.
vcsh[2] is a front-end for dealing with fake bare git repos, i.e. it
saves you a lot of typing and automates many things. It's written in
pure POSIX shell.
vcsh's userbase is slowly expanding and as it's feature set and syntax
are stable and there are no known bugs I think this is a good time to
try to increase adoption rate. I strongly believe that a lot of people
on this list could benefit from using it; hopefully you agree.
Publishing it here makes sense as if you are reading this, you are
obviously familiar with and using git already, anyway.
Feedback is very welcome. Good, bad or indifference, I will take it all.
Two notes:
* There is no test suite, yet. If anyone has a suggestion as to which
test suite has a reasonable feature set while having a syntax that
does not make you violently sick, or is even interested in helping to
write said test suite, do let me know.
* I am pondering renaming/aliasing vcsh to git-fbare.sh or similar.
That has a few issues, though..
** extra typing involved
** adds another command level of to otherwise standard git commands,
for example `git fbare zsh commit -a -m 'new feature'`
** forces everyone to have a default location for vcsh repos
Regards,
Richard
[1] http://lists.madduck.net/pipermail/vcs-home/2011-April/000378.html
[2] https://github.com/RichiH/vcsh
^ permalink raw reply
* Re: Debugging git-commit slowness on a large repo
From: Joshua Redstone @ 2011-12-20 0:51 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy, Carlos Martín Nieto, Tomas Carnecky,
Junio C Hamano
Cc: git@vger.kernel.org
In-Reply-To: <CB0BCE02.2CD42%joshua.redstone@fb.com>
I've managed to speed up git-commit on large repos by 4x by removing some
safeguards that caused git to stat every file in the repo on commits that
touch a small number of files. The diff, for illustrative purposes only,
is at:
https://gist.github.com/1499621
With a repo with 1 million files (but few commits), the diff drops the
commit time down from 7.3 seconds to 1.8 seconds, a 75% decrease. The
optimizations are:
1. Remove call to refresh_cache_or_die that stats every file in the repo,
i think the purpose is to detect any changes between git-add and
git-commit.
2. Pass missing_ok=true to cache_tree_update. This causes the tree
generation code to not stat every file in the repo to verify it still
exists as a git object.
3. Remove pair discard_cache/read_cache_from, which rereads the index
file. I think this was in case a pre-commit hook changed the set of things
being committed.
It may be worth making some of these flag-enabled.
Josh
On 12/12/11 4:15 PM, "Joshua Redstone" <joshua.redstone@fb.com> wrote:
>Sorry for the poor formatting of the stack trace.
>
>I've written two scripts to reproduce the slow commit behavior that I see.
> I've posted both to:
> https://gist.github.com/1469760
>
>To repro, first create a dir with lots of files (it defaults to creating 1
>million files in 1000 dirs):
>
>$ loadGen.py --baseDir=./bigdir
>
>then, run the simulator scripts to generate and commit a series of small
>changes to the repo:
>
>$ git reset --hard HEAD && simulate.py ./bigdir git
>
>The git reset is to clean up any cruft left over from a previous partial
>invocation of simulate.py
>
>Note that loadGen.py defaults to creating 1 million files and committing
>them in one commit. With a flash drive this took < 30 min, and subsequent
>small commits in simulate.py took about 6 seconds. With a hard-drive,
>it's taking > 1hr (still waiting for it to finish).
>
>Cheers,
>Josh
>
>
>On 12/8/11 4:17 PM, "Joshua Redstone" <joshua.redstone@fb.com> wrote:
>
>>Btw, I also tried doing some very poor-man's profiling on "git commit"
>>without any of the readtree/writetree/updateindex commands.
>>
>>Around 50% of the time was in (bottom few frames may have varied)
>>
>>#1 0x00000000004c467e in find_pack_entry (sha1=0x1475a44 ,
>>e=0x7fff2621f070) at sha1_file.c:2027
>>#2 0x00000000004c57b0 in has_sha1_file (sha1=0x7fe2cd9c7900 "00") at
>>sha1_file.c:2567
>>
>>
>>#3 0x000000000046e4af in update_one (it=<value optimized out>,
>>cache=<value optimized out>, entries=<value optimized out>, base=<value
>>optimized out>, baselen=<value optimized out>, missing_ok=<value
>>optimized
>>out>, dryrun=0) at cache-\
>>tree.c:333
>>
>>
>>
>>#4 0x000000000046e278 in update_one (it=<value optimized out>,
>>cache=<value optimized out>, entries=<value optimized out>, base=<value
>>optimized out>, baselen=<value optimized out>, missing_ok=<value
>>optimized
>>out>, dryrun=0) at cache-\
>>tree.c:285
>>
>>
>>
>>#5 0x000000000046e278 in update_one (it=<value optimized out>,
>>cache=<value optimized out>, entries=<value optimized out>, base=<value
>>optimized out>, baselen=<value optimized out>, missing_ok=<value
>>optimized
>>out>, dryrun=0) at cache-\
>>tree.c:285
>>
>>
>>
>>#6 0x000000000046e278 in update_one (it=<value optimized out>,
>>cache=<value optimized out>, entries=<value optimized out>, base=<value
>>optimized out>, baselen=<value optimized out>, missing_ok=<value
>>optimized
>>out>, dryrun=0) at cache-\
>>tree.c:285
>>
>>
>>
>>#7 0x000000000046e278 in update_one (it=<value optimized out>,
>>cache=<value optimized out>, entries=<value optimized out>, base=<value
>>optimized out>, baselen=<value optimized out>, missing_ok=<value
>>optimized
>>out>, dryrun=0) at cache-\
>>tree.c:285
>>
>>
>>
>>#8 0x000000000046e278 in update_one (it=<value optimized out>,
>>cache=<value optimized out>, entries=<value optimized out>, base=<value
>>optimized out>, baselen=<value optimized out>, missing_ok=<value
>>optimized
>>out>, dryrun=0) at cache-\
>>tree.c:285
>>
>>
>>
>>#9 0x000000000046e869 in cache_tree_update (it=<value optimized out>,
>>cache=<value optimized out>, entries=dwarf2_read_address: Corrupted DWARF
>>expression.
>>
>>) at cache-tree.c:379
>>
>>
>>
>>#10 0x000000000041cade in prepare_to_commit (index_file=0x781740
>>".git/index", prefix=<value optimized out>, current_head=<value optimized
>>out>, s=0x7fff26220d00, author_ident=<value optimized out>) at
>>builtin/commit.c:866
>>#11 0x000000000041d891 in cmd_commit (argc=0, argv=0x7fff262213a0,
>>prefix=0x0) at builtin/commit.c:1407
>>
>>
>>#12 0x0000000000404bf7 in handle_internal_command (argc=4,
>>argv=0x7fff262213a0) at git.c:308
>>
>>
>>#13 0x0000000000404e2f in main (argc=4, argv=0x7fff262213a0) at git.c:512
>>
>>
>>
>>
>>
>>
>>And 30% of the time was in:
>>
>>#0 0x00000034af2c34a5 in _lxstat () from /lib64/libc.so.6
>>
>>
>>
>>#1 0x00000000004abe0f in refresh_cache_ent (istate=0x780940,
>>ce=0x7f8462a34e40, options=0, err=0x7fff6dd9f588) at
>>/usr/include/sys/stat.h:443
>>
>>#2 0x00000000004ac1a0 in refresh_index (istate=0x780940, flags=<value
>>optimized out>, pathspec=<value optimized out>, seen=<value optimized
>>out>, header_msg=0x0) at read-cache.c:1133
>>
>>#3 0x000000000041b60a in refresh_cache_or_die (refresh_flags=<value
>>optimized out>) at builtin/commit.c:331
>>
>>
>>#4 0x000000000041bc39 in prepare_index (argc=0, argv=0x7fff6dda0310,
>>prefix=0x0, current_head=<value optimized out>, is_status=<value
>>optimized
>>out>) at builtin/commit.c:414
>>
>>#5 0x000000000041d878 in cmd_commit (argc=0, argv=0x7fff6dda0310,
>>prefix=0x0) at builtin/commit.c:1403
>>
>>
>>
>>
>>
>>Josh
>>
>>
>>On 12/8/11 4:09 PM, "Joshua Redstone" <joshua.redstone@fb.com> wrote:
>>
>>>On 12/7/11 5:39 PM, "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> wrote:
>>>
>>>>On Thu, Dec 8, 2011 at 5:48 AM, Joshua Redstone
>>>><joshua.redstone@fb.com>
>>>>wrote:
>>>>> Hi Duy,
>>>>> Thanks for the documentation link.
>>>>>
>>>>> git ls-files shows 100k files, which matches # of files in the
>>>>>working
>>>>> tree ('find . -type f -print | wc -l').
>>>>
>>>>Any chance you can split it into smaller repositories, or remove files
>>>>from working directory (e.g. if you store logs, you don't have to keep
>>>>logs from all time in working directory, they can be retrieved from
>>>>history).
>>>
>>>It's not really feasible to split it into smaller repositories. In
>>>fact,
>>>we're expecting it to grow between 3x and 5x in number of files and
>>>number
>>>of commits.
>>>
>>>>
>>>>> I added a 'git read-tree HEAD' before the git-add, and a 'git
>>>>>write-tree'
>>>>> after the add. With that, the commit time slowed down to 8 seconds
>>>>>per
>>>>> commit, plus 4 more seconds for the read-tree/add/write-tree ops.
>>>>>The
>>>>> read-tree/add/write-tree each took about a second.
>>>>
>>>>read-tree destroys stat info in index, refreshing 100k entries in
>>>>index in this case may take some time. Try this to see if commit time
>>>>reduces and how much time update-index takes
>>>>
>>>>read-tree HEAD
>>>>update-index --refresh
>>>>add ....
>>>>write-tree
>>>>commit -q
>>>
>>>I added the "update-index --refresh" and the time for commit became more
>>>like 0.6 seconds.
>>>In this setup: read-tree takes ~2 seconds, update-index takes ~8
>>>seconds,
>>>git-add takes 1 to 4 seconds, and write-tree takes less than 1 second.
>>>
>>>>
>>>>> As an experiment, I also tried removing the 'git read-tree' and just
>>>>> having the git-write-tree. That sped up commits to 0.6 seconds, but
>>>>>the
>>>>> overall time for add/write-tree/commit was still 3 to 6 seconds.
>>>>
>>>>overall time is not really important because we duplicate work here
>>>>(write-tree is done as part of commit again). What I'm trying to do is
>>>>to determine how much time each operation in commit may take.
>>>>--
>>>>Duy
>>>
>>
>
^ permalink raw reply
* Re: Tracking file metadata in git -- fix metastore or enhance git?
From: Richard Hartmann @ 2011-12-20 0:55 UTC (permalink / raw)
To: johnnyutahh; +Cc: git
In-Reply-To: <1323838492627-7092383.post@n2.nabble.com>
On Wed, Dec 14, 2011 at 05:54, johnnyutahh
<git.nabble.com@johnnyutahh.com> wrote:
> Any further movement on this topic?
Not really. ATM, our best bet is to agree on a language and just implement it.
Richard
^ permalink raw reply
* Re: Debugging git-commit slowness on a large repo
From: Junio C Hamano @ 2011-12-20 1:21 UTC (permalink / raw)
To: Joshua Redstone
Cc: Nguyen Thai Ngoc Duy, Carlos Martín Nieto, Tomas Carnecky,
git@vger.kernel.org
In-Reply-To: <CB1518AB.2D649%joshua.redstone@fb.com>
Joshua Redstone <joshua.redstone@fb.com> writes:
> I've managed to speed up git-commit on large repos by 4x by removing some
> safeguards that caused git to stat every file in the repo on commits that
> touch a small number of files. The diff, for illustrative purposes only,
> is at:
>
> https://gist.github.com/1499621
>
>
> With a repo with 1 million files (but few commits), the diff drops the
> commit time down from 7.3 seconds to 1.8 seconds, a 75% decrease. The
> optimizations are:
I do not know if these kind of changes are called "optimizations" or
merely making the command record a random tree object that may have some
resemblance to what you wanted to commit but is subtly incorrect. I didn't
fetch your safety removal, though.
Wouldn't you get a similar speed-up without being unsafe if you simply ran
"git commit" without any parameter (i.e. write out the current index as a
tree and make a commit), combined with "--no-status" and perhaps "-q" to
avoid running the comparison between the resulting commit and the working
tree state after the commit?
^ permalink raw reply
* [RFC/PATCH 0/2] Re: git-svn: multiple fetch lines
From: Jonathan Nieder @ 2011-12-20 1:22 UTC (permalink / raw)
To: Nathan Gray; +Cc: git, Eric Wong
In-Reply-To: <CA+7g9JzatFYViMk302uU-X=YQGF2wEsmASkLPm0tDfQvpL_-vQ@mail.gmail.com>
Nathan Gray wrote:
> How about something along these lines:
Sounds sensible. Here's a patch series along those lines to get
things started. Please feel free to try them (use "make -C
Documentation git-svn.1" to test), tweak to taste, and resend when
ready for Eric to pick up.
Thanks,
Jonathan Nieder (1):
git-svn: clarify explanation of --destination argument
Nathan Gray (1):
git-svn: multiple fetch/branches/tags keys are supported
Documentation/git-svn.txt | 31 ++++++++++++++++++++++++++-----
1 files changed, 26 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH 1/2] git-svn: multiple fetch/branches/tags keys are supported
From: Jonathan Nieder @ 2011-12-20 1:23 UTC (permalink / raw)
To: Nathan Gray; +Cc: git, Eric Wong
In-Reply-To: <20111220012236.GB20979@elie.hsd1.il.comcast.net>
From: Nathan Gray <n8gray@n8gray.org>
"git svn" can be configured to use multiple fetch, branches, and tags
refspecs by passing multiple --branches or --tags options at init time
or editing the configuration file later, which can be handy when
working with messy Subversion repositories. Add a note to the
configuration section documenting how this works.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-svn.txt | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 34ee7850..66fd60a4 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -923,6 +923,18 @@ comma-separated list of names within braces. For example:
tags = tags/{1.0,2.0}/src:refs/remotes/tags/*
------------------------------------------------------------------------
+Multiple fetch, branches, and tags keys are supported:
+
+------------------------------------------------------------------------
+[svn-remote "messy-repo"]
+ url = http://server.org/svn
+ fetch = trunk/project-a:refs/remotes/project-a/trunk
+ fetch = branches/demos/june-project-a-demo:refs/remotes/project-a/demos/june-demo
+ branches = branches/server/*:refs/remotes/project-a/branches/*
+ branches = branches/demos/2011/*:refs/remotes/project-a/2011-demos/*
+ tags = tags/server/*:refs/remotes/project-a/tags/*
+------------------------------------------------------------------------
+
Note that git-svn keeps track of the highest revision in which a branch
or tag has appeared. If the subset of branches or tags is changed after
fetching, then .git/svn/.metadata must be manually edited to remove (or
--
1.7.8
^ permalink raw reply related
* [PATCH 2/2] git-svn: clarify explanation of --destination argument
From: Jonathan Nieder @ 2011-12-20 1:24 UTC (permalink / raw)
To: Nathan Gray; +Cc: git, Eric Wong
In-Reply-To: <20111220012236.GB20979@elie.hsd1.il.comcast.net>
The existing documentation for "-d" does not make it obvious whether
its argument is supposed to be a full svn path, a partial svn path,
the glob from the config file, or what. Clarify the text and add an
example to get the reader started.
Reported-by: Nathan Gray <n8gray@n8gray.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-svn.txt | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 66fd60a4..a343c261 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -254,13 +254,15 @@ first have already been pushed into SVN.
Create a tag by using the tags_subdir instead of the branches_subdir
specified during git svn init.
--d;;
---destination;;
+-d<path>;;
+--destination=<path>;;
+
If more than one --branches (or --tags) option was given to the 'init'
or 'clone' command, you must provide the location of the branch (or
- tag) you wish to create in the SVN repository. The value of this
- option must match one of the paths specified by a --branches (or
- --tags) option. You can see these paths with the commands
+ tag) you wish to create in the SVN repository. <path> specifies which
+ path to use to create the branch or tag and should match the pattern
+ on the left-hand side of one of the configured branches or tags
+ refspecs. You can see these refspecs with the commands
+
git config --get-all svn-remote.<name>.branches
git config --get-all svn-remote.<name>.tags
@@ -935,6 +937,13 @@ Multiple fetch, branches, and tags keys are supported:
tags = tags/server/*:refs/remotes/project-a/tags/*
------------------------------------------------------------------------
+Creating a branch in such a configuration requires disambiguating which
+location to use using the -d or --destination flag:
+
+------------------------------------------------------------------------
+$ git svn branch -d branches/server release-2-3-0
+------------------------------------------------------------------------
+
Note that git-svn keeps track of the highest revision in which a branch
or tag has appeared. If the subset of branches or tags is changed after
fetching, then .git/svn/.metadata must be manually edited to remove (or
--
1.7.8
^ permalink raw reply related
* Re: [PATCHv3 02/11] git-p4: test debug macro
From: Pete Wyckoff @ 2011-12-20 1:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Luke Diamand, git
In-Reply-To: <7vwr9to8kk.fsf@alter.siamese.dyndns.org>
gitster@pobox.com wrote on Sun, 18 Dec 2011 13:48 -0800:
> You may have found this handy yourself, but I would rather not to see it
> here in the current form for multiple reasons.
>
> - Why "ctrl-c"? You are not even spawning shell from here but are having
> the user interact with this state in the middle of a test from another
> shell, no?
>
> Why not "When done, type <RET>" and have a "read junk" or something
> instead? That would be a lot simpler and you do not have to worry about
> portability with many lines of comments.
>
> An alternative is to spawn an interactive shell here, and change the
> "Debug me" comment to say "ctrl-d when done".
Good point. I'll get rid of all that trap business.
> - This is not linked to the generic "debug" option "txxxx-name.sh -d".
> Shouldn't you be extending test_debug so that it can go interactive,
> give customized comments&insns (i.e. "cd $here" may be useful for test
> scripts outside testing p4, but "P4PORT=..." would not be, so the user
> of test_debug in t9800-git-p4.* needs customizability of the message).
That's good advice; each (set of) script(s) could customize as
needed.
The pain of having to track down the P4PORT, which varies with
each test script, was my main motivation for trying to automate
this.
I'll not resubmit this one until coming up with something
prettier.
> Also could we please rename p4 related tests in t/t98* series so that it
> is clear that they are about git-p4 from "ls t/" output (i.e. have them
> all have "git-p4" in their names)?
Sure. That was a mistake. We'll fix it up.
-- Pete
^ permalink raw reply
* Re: Debugging git-commit slowness on a large repo
From: Joshua Redstone @ 2011-12-20 1:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nguyen Thai Ngoc Duy, Carlos Martín Nieto, Tomas Carnecky,
git@vger.kernel.org
In-Reply-To: <7vehw0kphc.fsf@alter.siamese.dyndns.org>
You're right, more than optimizations, they are modifications that reduce
safety checks and make assumptions about the way one is using git (e.g.,
you always remember to add each file you want to commit). I focused on
them because:
1. In our installation, we don't use commit hooks that change what's
being committed, so it's good to know that in principle, there's a big
perf benefit to be had by leveraging that fact.
2. At an abstract level, it seems like the cost of doing a commit should
be proportional to the amount of the repository touched by the commit, not
by the size of the repository. These experiments are demonstrations of
one direction that a set of optimizations would need to go to get commit
performance more along those lines.
3. We're also exploring storage systems that support more efficient ways
to query what's changed than stat'ing every file.
I forgot to mention, the times I quoted where with --no-verify and
--no-status. Adding '-q' didn't speed up performance at all.
As a bonus, I've also profiled git-add on the 1-million file repo, and it
looks like, as you might expect, the time is dominated by reading and
writing the index. The time for git-add is a couple of seconds.
Josh
On 12/19/11 5:21 PM, "Junio C Hamano" <gitster@pobox.com> wrote:
>Joshua Redstone <joshua.redstone@fb.com> writes:
>
>> I've managed to speed up git-commit on large repos by 4x by removing
>>some
>> safeguards that caused git to stat every file in the repo on commits
>>that
>> touch a small number of files. The diff, for illustrative purposes
>>only,
>> is at:
>>
>> https://gist.github.com/1499621
>>
>>
>> With a repo with 1 million files (but few commits), the diff drops the
>> commit time down from 7.3 seconds to 1.8 seconds, a 75% decrease. The
>> optimizations are:
>
>I do not know if these kind of changes are called "optimizations" or
>merely making the command record a random tree object that may have some
>resemblance to what you wanted to commit but is subtly incorrect. I didn't
>fetch your safety removal, though.
>
>Wouldn't you get a similar speed-up without being unsafe if you simply ran
>"git commit" without any parameter (i.e. write out the current index as a
>tree and make a commit), combined with "--no-status" and perhaps "-q" to
>avoid running the comparison between the resulting commit and the working
>tree state after the commit?
^ permalink raw reply
* What's cooking in git.git (Dec 2011, #07; Mon, 19)
From: Junio C Hamano @ 2011-12-20 1:44 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'.
The second large batch of topics for 1.7.9 graduated to 'master', and the
tip of it should be 85% feature complete for this cycle (modulo fixes and
tweaks).
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint and master:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches:
https://github.com/gitster/git
The preformatted documentation in HTML and man format are found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
--------------------------------------------------
[New Topics]
* jc/advice-doc (2011-12-18) 1 commit
(merged to 'next' on 2011-12-19 at 0b410e5)
+ advice: Document that they all default to true
(this branch is used by jc/advise-push-default.)
Will merge to "master".
--------------------------------------------------
[Graduated to "master"]
* ab/enable-i18n (2011-12-05) 1 commit
(merged to 'next' on 2011-12-13 at 65af8cd)
+ i18n: add infrastructure for translating Git with gettext
* ci/stripspace-docs (2011-12-12) 1 commit
(merged to 'next' on 2011-12-13 at 35b2cdf)
+ Update documentation for stripspace
* ew/keepalive (2011-12-05) 1 commit
(merged to 'next' on 2011-12-13 at 1b5d5c4)
+ enable SO_KEEPALIVE for connected TCP sockets
* jc/checkout-m-twoway (2011-12-15) 3 commits
(merged to 'next' on 2011-12-15 at cc64fed)
+ checkout_merged(): squelch false warning from some gcc
(merged to 'next' on 2011-12-11 at b61057f)
+ Test 'checkout -m -- path'
(merged to 'next' on 2011-12-09 at c946009)
+ checkout -m: no need to insist on having all 3 stages
* jk/credentials (2011-12-12) 14 commits
(merged to 'next' on 2011-12-12 at 7a6d658)
+ t: add test harness for external credential helpers
+ credentials: add "store" helper
+ strbuf: add strbuf_add*_urlencode
+ Makefile: unix sockets may not available on some platforms
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ credential: make relevance of http path configurable
+ credential: add credential.*.username
+ credential: apply helper config
+ http: use credential API to get passwords
+ credential: add function for parsing url components
+ introduce credentials API
+ t5550: fix typo
+ test-lib: add test_config_global variant
(this branch is used by jk/git-prompt.)
* jk/fetch-no-tail-match-refs (2011-12-13) 4 commits
(merged to 'next' on 2011-12-13 at 805c018)
+ connect.c: drop path_match function
+ fetch-pack: match refs exactly
+ t5500: give fully-qualified refs to fetch-pack
+ drop "match" parameter from get_remote_heads
* jk/maint-mv (2011-12-12) 5 commits
(merged to 'next' on 2011-12-13 at 58caedb)
+ mv: be quiet about overwriting
+ mv: improve overwrite warning
+ mv: make non-directory destination error more clear
+ mv: honor --verbose flag
+ docs: mention "-k" for both forms of "git mv"
* jk/maint-push-over-dav (2011-12-13) 2 commits
(merged to 'next' on 2011-12-13 at 45e376c)
+ http-push: enable "proactive auth"
+ t5540: test DAV push with authentication
* jk/maint-snprintf-va-copy (2011-12-12) 1 commit
(merged to 'next' on 2011-12-13 at d37a7e1)
+ compat/snprintf: don't look at va_list twice
* jn/maint-sequencer-fixes (2011-12-12) 7 commits
(merged to 'next' on 2011-12-13 at 5b3950c)
+ revert: stop creating and removing sequencer-old directory
+ Revert "reset: Make reset remove the sequencer state"
+ revert: do not remove state until sequence is finished
+ revert: allow single-pick in the middle of cherry-pick sequence
+ revert: pass around rev-list args in already-parsed form
+ revert: allow cherry-pick --continue to commit before resuming
+ revert: give --continue handling its own function
(this branch is used by rr/revert-cherry-pick.)
* nd/resolve-ref (2011-12-13) 3 commits
(merged to 'next' on 2011-12-13 at c7002e9)
+ Rename resolve_ref() to resolve_ref_unsafe()
+ Convert resolve_ref+xstrdup to new resolve_refdup function
+ revert: convert resolve_ref() to read_ref_full()
* rr/test-chaining (2011-12-11) 7 commits
(merged to 'next' on 2011-12-13 at b08445e)
+ t3401: use test_commit in setup
+ t3401: modernize style
+ t3040 (subprojects-basic): fix '&&' chaining, modernize style
+ t1510 (worktree): fix '&&' chaining
+ t3030 (merge-recursive): use test_expect_code
+ test: fix '&&' chaining
+ t3200 (branch): fix '&&' chaining
* tr/cache-tree (2011-12-06) 5 commits
(merged to 'next' on 2011-12-13 at e0da64d)
+ reset: update cache-tree data when appropriate
+ commit: write cache-tree data when writing index anyway
+ Refactor cache_tree_update idiom from commit
+ Test the current state of the cache-tree optimization
+ Add test-scrap-cache-tree
--------------------------------------------------
[Cooking]
* cn/maint-lf-to-crlf-filter (2011-12-16) 1 commit
- lf_to_crlf_filter(): tell the caller we added "\n" when draining
(this branch is used by jc/maint-lf-to-crlf-keep-crlf.)
A recent fix to the codepath was not quite correct.
Will merge to "next".
* jc/maint-lf-to-crlf-keep-crlf (2011-12-18) 1 commit
- lf_to_crlf_filter(): resurrect CRLF->CRLF hack
(this branch uses cn/maint-lf-to-crlf-filter.)
The lf-to-crlf filter in the streaming checkout codepath forgot that we
try not to convert LF to CRLF if the repository data already has CRLF.
Will merge to "next".
* jc/request-pull-show-head-4 (2011-12-19) 2 commits
(merged to 'next' on 2011-12-19 at 771939b)
+ request-pull: do not emit "tag" before the tagname
(merged to 'next' on 2011-12-16 at bea51ac)
+ request-pull: update the "pull" command generation logic
Will merge to "master".
* jk/doc-fsck (2011-12-16) 1 commit
- docs: brush up obsolete bits of git-fsck manpage
Will merge to "next".
* jk/follow-rename-score (2011-12-16) 1 commit
- use custom rename score during --follow
Will merge to "next".
* jk/pretty-reglog-ent (2011-12-16) 1 commit
- pretty: give placeholders to reflog identity
Will merge to "next".
* jk/http-push-to-empty (2011-12-19) 1 commit
(merged to 'next' on 2011-12-19 at 845e2a1)
+ remote-curl: don't pass back fake refs
* jk/maint-push-v-is-verbose (2011-12-17) 1 commit
- make "git push -v" actually verbose
Will merge to "next".
* jk/maint-strbuf-missing-init (2011-12-18) 2 commits
- Update jk/maint-strbuf-missing-init to builtin/ rename
- commit, merge: initialize static strbuf
Will merge to "next".
* rs/diff-tree-combined-clean-up (2011-12-17) 3 commits
- submodule: use diff_tree_combined_merge() instead of diff_tree_combined()
- pass struct commit to diff_tree_combined_merge()
- use struct sha1_array in diff_tree_combined()
Will merge to "next".
* jn/maint-gitweb-utf8-fix (2011-12-19) 4 commits
- gitweb: Fix fallback mode of to_utf8 subroutine
- gitweb: Output valid utf8 in git_blame_common('data')
- gitweb: esc_html() site name for title in OPML
- gitweb: Call to_utf8() on input string in chop_and_escape_str()
Will merge to "next".
* pw/p4-docs-and-tests (2011-12-18) 11 commits
- git-p4: document and test submit options
- git-p4: test and document --use-client-spec
- git-p4: test --keep-path
- git-p4: test --max-changes
- git-p4: document and test --import-local
- git-p4: honor --changesfile option and test
- git-p4: document and test clone --branch
- git-p4: test cloning with two dirs, clarify doc
- git-p4: clone does not use --git-dir
- git-p4: test debug macro
- git-p4: introduce asciidoc documentation
Waiting for a reroll.
* jc/advise-push-default (2011-12-18) 1 commit
- push: hint to use push.default=upstream when appropriate
(this branch uses jc/advice-doc.)
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?
Waiting for a reroll.
* ef/setenv-putenv (2011-12-14) 2 commits
- compat/setenv.c: error if name contains '='
- compat/setenv.c: update errno when erroring out
(this branch is used by ef/x-setenv-putenv.)
Will merge to "next".
* jk/maint-do-not-feed-stdin-to-tests (2011-12-15) 1 commit
- test-lib: redirect stdin of tests
Will merge to "next".
* jn/test-cleanup-7006 (2011-12-14) 1 commit
- test: errors preparing for a test are not special
Will merge to "next".
* nd/war-on-nul-in-commit (2011-12-15) 3 commits
- commit_tree(): refuse commit messages that contain NULs
- Convert commit_tree() to take strbuf as message
- merge: abort if fails to commit
Will merge to "next".
* jk/git-prompt (2011-12-12) 10 commits
- contrib: add credential helper for OS X Keychain
- Makefile: OS X has /dev/tty
- Makefile: linux has /dev/tty
- credential: use git_prompt instead of git_getpass
- prompt: use git_terminal_prompt
- add generic terminal prompt function
- refactor git_getpass into generic prompt function
- move git_getpass to its own source file
- imap-send: don't check return value of git_getpass
- imap-send: avoid buffer overflow
Will merge to 'next' after taking another look.
* mh/ref-api-rest (2011-12-12) 35 commits
- repack_without_ref(): call clear_packed_ref_cache()
- read_packed_refs(): keep track of the directory being worked in
- is_refname_available(): query only possibly-conflicting references
- refs: read loose references lazily
- read_loose_refs(): take a (ref_entry *) as argument
- struct ref_dir: store a reference to the enclosing ref_cache
- sort_ref_dir(): take (ref_entry *) instead of (ref_dir *)
- do_for_each_ref_in_dir*(): take (ref_entry *) instead of (ref_dir *)
- add_entry(): take (ref_entry *) instead of (ref_dir *)
- search_ref_dir(): take (ref_entry *) instead of (ref_dir *)
- find_containing_direntry(): use (ref_entry *) instead of (ref_dir *)
- add_ref(): take (ref_entry *) instead of (ref_dir *)
- read_packed_refs(): take (ref_entry *) instead of (ref_dir *)
- find_ref(): take (ref_entry *) instead of (ref_dir *)
- is_refname_available(): take (ref_entry *) instead of (ref_dir *)
- get_loose_refs(): return (ref_entry *) instead of (ref_dir *)
- get_packed_refs(): return (ref_entry *) instead of (ref_dir *)
- refs: wrap top-level ref_dirs in ref_entries
- get_ref_dir(): keep track of the current ref_dir
- do_for_each_ref(): only iterate over the subtree that was requested
- refs: sort ref_dirs lazily
- sort_ref_dir(): do not sort if already sorted
- refs: store references hierarchically
- refs.c: rename ref_array -> ref_dir
- struct ref_entry: nest the value part in a union
- check_refname_component(): return 0 for zero-length components
- free_ref_entry(): new function
- refs.c: reorder definitions more logically
- is_refname_available(): reimplement using do_for_each_ref_in_array()
- names_conflict(): simplify implementation
- names_conflict(): new function, extracted from is_refname_available()
- repack_without_ref(): reimplement using do_for_each_ref_in_array()
- do_for_each_ref_in_arrays(): new function
- do_for_each_ref_in_array(): new function
- do_for_each_ref(): correctly terminate while processesing extra_refs
(this branch uses mh/ref-api.)
The API for extra anchoring points may require rethought first; that would
hopefully make the "ref" part a lot simpler.
Waiting for a reroll.
* mh/ref-api (2011-12-12) 16 commits
(merged to 'next' on 2011-12-15 at d65a830)
+ add_ref(): take a (struct ref_entry *) parameter
+ create_ref_entry(): extract function from add_ref()
+ repack_without_ref(): remove temporary
+ resolve_gitlink_ref_recursive(): change to work with struct ref_cache
+ Pass a (ref_cache *) to the resolve_gitlink_*() helper functions
+ resolve_gitlink_ref(): improve docstring
+ get_ref_dir(): change signature
+ refs: change signatures of get_packed_refs() and get_loose_refs()
+ is_dup_ref(): extract function from sort_ref_array()
+ add_ref(): add docstring
+ parse_ref_line(): add docstring
+ is_refname_available(): remove the "quiet" argument
+ clear_ref_array(): rename from free_ref_array()
+ refs: rename parameters result -> sha1
+ refs: rename "refname" variables
+ struct ref_entry: document name member
(this branch is used by mh/ref-api-rest.)
Later part split out to expedite moving the earlier good bits forward.
Will merge to "master".
* tr/grep-threading (2011-12-16) 3 commits
- grep: disable threading in non-worktree case
- grep: enable threading with -p and -W using lazy attribute lookup
- grep: load funcname patterns for -W
Will merge to 'next' after taking another look.
* tr/pty-all (2011-12-19) 1 commit
- test-terminal: set output terminals to raw mode
Kept only the second one from the original.
Will merge to "next".
* jc/push-ignore-stale (2011-12-14) 2 commits
- push: --ignore-stale option
- set_ref_status_for_push(): use transport-flags abstraction
Probably solving a wrong problem and encouraging a wrong workflow while at
it. jc/advise-push-default might be a better approach.
Will drop.
* rr/revert-cherry-pick (2011-12-15) 6 commits
- t3502, t3510: clarify cherry-pick -m failure
- t3510 (cherry-pick-sequencer): use exit status
- revert: simplify getting commit subject in format_todo()
- revert: tolerate extra spaces, tabs in insn sheet
- revert: make commit subjects in insn sheet optional
- revert: free msg in format_todo()
Will merge to "next".
* jc/split-blob (2011-12-01) 6 commits
. WIP (streaming chunked)
- 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.
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.
* jc/signed-commit (2011-11-29) 5 commits
- gpg-interface: allow use of a custom GPG binary
- pretty: %G[?GS] placeholders
- test "commit -S" and "log --show-signature"
- log: --show-signature
- commit: teach --gpg-sign option
Not urgent.
^ permalink raw reply
* Re: git-p4: labels
From: Pete Wyckoff @ 2011-12-20 1:47 UTC (permalink / raw)
To: Vitor Antunes; +Cc: Luke Diamand, Git List, Michael Horowitz
In-Reply-To: <CAOpHH-W1hE6bw51NKXrdf1QtF3T+v4aLwxMn+_5xPP5j=uJr3w@mail.gmail.com>
vitor.hda@gmail.com wrote on Mon, 19 Dec 2011 10:28 +0000:
> On Sun, Dec 18, 2011 at 6:33 PM, Luke Diamand <luke@diamand.org> wrote:
> > I've been looking at fixing the --detect-labels flag in git-p4. I'm now
> > thinking that the current way it's done is just all wrong.
> >
> > The current code has a few annoying bugs which I mostly have fixes for:
> >
> > - it only works when there is no more than one label per changelist;
> >
> > - if the count of files in the p4 label doesn't match the count of files in
> > the p4 changelist then the label gets dropped (by design);
> >
> > - git-p4 rebase ignores --detect-labels
> >
> > - it imports all the label/file mappings each time (I haven't fixed this
> > yet)
> >
> > However, the thing that's more annoying is that it only imports labels when
> > importing the changelist they are pointing at.
> >
> > So, for example, if you do something like this:
> >
> > p4 edit; p4 submit
> > p4 tag TAG1
> > git-p4 rebase
> > p4 tag TAG2
> > git-p4 rebase
> >
> > then TAG1 will be detected, but TAG2 won't.
> >
> > This is a particular nuisance for me, as I just have git-p4 running all the
> > time eating commits, so there's no scope for a human to delay the git-p4 and
> > pickup the label.
> >
> > I think what's needed is to do something completely different.
> >
> > This is speculation at the moment, and I'd welcome comments before I start
> > hacking.
> >
> > There will be a new _command_, import-labels. This command will find all the
> > labels that git knows about, and the labels that p4 knows about, and then do
> > the obvious diff. It will then create tags as needed directly (i.e. not
> > using fast-import).
> >
> > It will unfortunately need to hunt through the revision history looking for
> > the git hash <h> that matches p4 changelist <c>. This could get quite slow,
> > although no worse than O(n).
> >
> > Something like:
> >
> > p4 edit; p4 submit
> > p4 tag TAG1
> > git-p4 rebase
> > git-p4 import-labels
> > p4 tag TAG2
> > git-p4 import-labels
> >
> > I'm going to try to work up a patch with some test cases but in the meantime
> > if anyone thinks I've missed something, please let me know.
>
> Hi Luke,
>
> Personally, I would prefer to keep the label import working together
> with git-p4 rebase/sync so that it doesn't need to go over P4 history
> twice. The sanity check currently implemented seems completely bogus. In
> my opinion that check should be completely rewritten (maybe move it into
> a specific class method?). On a first approach it should at least check
> if all files in the label exist in the repository/branch. Ideally, if
> not all repository/branch files are labelled, then a special branch
> should be created that would not contain those files and the label would
> be applied to that. I'm not sure what to do in the case where the label
> contains files that are not part of the repository/branch... maybe we
> can simply ignore them with a Warning?
Agree we can at least keep what's currently working, especially
with the bug fixes mentioned. It's pretty blatantly broken in
those cases. I imagine for some flows, like where labels are old
compared to git checkouts, it's okay.
But adding a new command to go back and look for _new_ labels
makes sense too. Finding the new ones isn't so bad, given that
p4 can just print them directly, and we keep them as tags in git.
> If you are really sure that this is not the way to go and that the
> import-labels command needs to be created, then I would advise you to
> search P4 history backwards until you find a label that was already
> imported. This way the script only has to go over P4 history until the
> last time import-labels was run. Of course, it still needs to do this
> for all branches (hope you are not forgeting them ;).
Yeah. That's probably a good bet. Find the tag that points to
the most recent change number and stop there.
I'm not too worried about walking backwards looking for a given
change number either. You could even bisect if you feel clever. :)
Off and on, it has felt like a good idea to keep that mapping
permanent somewhere, matching up tags to change numbers. This
has come up on the list outside of p4 discussions too.
But isn't there a step in label detection that looks an awful lot
like branch point detection? You've got a label, which is a
bunch of files, not a p4 change number. Now you have to figure
out the change number so you can go hunt that down in the git
history. Vitor's take on this was to use git diff machinery to
find it, not trawling through the p4 change/filelog/describe
history, mainly because it's likely much faster to do it locally
in git.
-- Pete
^ permalink raw reply
* Re: Introducing vcsh - manage config files in $HOME via fake bare git repositories
From: Sitaram Chamarty @ 2011-12-20 2:25 UTC (permalink / raw)
To: Richard Hartmann; +Cc: Git List
In-Reply-To: <CAD77+gTO35ZFdcOjTEEcymgDKMq4Uh3JZcqgXWR07kGksfkBqg@mail.gmail.com>
On Tue, Dec 20, 2011 at 5:47 AM, Richard Hartmann
<richih.mailinglist@gmail.com> wrote:
> Hi all,
>
>
> some of you may be familiar with fake bare git repositories[1].
>
> Basically, they allow you to keep the git directory and its working
> directory separate from each other. This allows you to have an
> arbitrary number of repositories with working trees in $HOME. That, in
> turn, allows you to have one repo for zsh, one for vim, one for git,
> etc pp.
My method is to put everything in one repo (I call it "hobbits" --
little things that save the world, heh).
My reasoning is that nothing is an island. I am a heavy user of vim,
fugitive (git plugin for vim), tig, and ranger, and at least these 4
are linked to each other. You could argue that I should use
submodules or gitslave or something but I keep it simple. Even my
"irssi" settings are tied into that, because of certain macros I use
to reply quickly to queries.
There's a piece of my ".additional.bashrc" that automatically symlinks
everything that are best left in $HOME (like ~/.gitconfig) and sets up
environment variables for everything else (like TIGRC_USER) that can
get along without.
There are 2 helper scripts. One packs all of this into a tarball so I
can easily untar it on any machine on which I have to work
temporarily, and the other cleans up the unpacked directory and
symlinks when I leave.
Just offering a different perspective.
regards
sitaram
>
> vcsh[2] is a front-end for dealing with fake bare git repos, i.e. it
> saves you a lot of typing and automates many things. It's written in
> pure POSIX shell.
>
>
> vcsh's userbase is slowly expanding and as it's feature set and syntax
> are stable and there are no known bugs I think this is a good time to
> try to increase adoption rate. I strongly believe that a lot of people
> on this list could benefit from using it; hopefully you agree.
> Publishing it here makes sense as if you are reading this, you are
> obviously familiar with and using git already, anyway.
>
> Feedback is very welcome. Good, bad or indifference, I will take it all.
>
> Two notes:
>
> * There is no test suite, yet. If anyone has a suggestion as to which
> test suite has a reasonable feature set while having a syntax that
> does not make you violently sick, or is even interested in helping to
> write said test suite, do let me know.
> * I am pondering renaming/aliasing vcsh to git-fbare.sh or similar.
> That has a few issues, though..
> ** extra typing involved
> ** adds another command level of to otherwise standard git commands,
> for example `git fbare zsh commit -a -m 'new feature'`
> ** forces everyone to have a default location for vcsh repos
>
>
> Regards,
> Richard
>
> [1] http://lists.madduck.net/pipermail/vcs-home/2011-April/000378.html
> [2] https://github.com/RichiH/vcsh
> --
> 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
--
Sitaram
^ permalink raw reply
* [PATCH v2] t4018: introduce test cases for the internal hunk header patterns
From: Brandon Casey @ 2011-12-20 2:42 UTC (permalink / raw)
To: gitster; +Cc: git, peff, j6t, jrnieder, trast, Brandon Casey
In-Reply-To: <7vmxaokv6k.fsf@alter.siamese.dyndns.org>
Recently it has been pointed out that one (or more?) of the internal hunk
header patterns is 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_"
* a test case must have one (and only one) line that contains "RIGHT"
(all uppercase) and that line should become the hunk header for the
test to succeed
* after the line that contains "RIGHT" token, there should be one (and
only one) line that contains the string "ChangeMe". The test modifies
this string to "IWasChanged", compares the original with the modified
result, and expects the "RIGHT" token above to appear on the hunk
header
Example test case:
int WRONG_function_hunk_header (void)
{
return 0;
}
int RIGHT_function_hunk_header (void)
{
const char *msg = "ChangeMe";
printf("Hello, world, %s\n", msg);
return 0;
}
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
Updated based on Junio's comments and squashed the additional tests I
sent. Plus I added -U1 to the git diff line so that the filler lines are
no longer necessary.
-Brandon
t/t4018-diff-funcname.sh | 18 ++++++++++++++++++
t/t4018/broken_class_constructor.cpp | 16 ++++++++++++++++
t/t4018/broken_class_destructor.cpp | 16 ++++++++++++++++
t/t4018/broken_gnu_style.cpp | 17 +++++++++++++++++
t/t4018/broken_reference.cpp | 16 ++++++++++++++++
t/t4018/broken_template.cpp | 16 ++++++++++++++++
t/t4018/class_method.cpp | 16 ++++++++++++++++
t/t4018/ignore_declaration.cpp | 17 +++++++++++++++++
t/t4018/ignore_global.cpp | 19 +++++++++++++++++++
t/t4018/ignore_label.cpp | 17 +++++++++++++++++
t/t4018/pointer_return.cpp | 16 ++++++++++++++++
t/t4018/simple.cpp | 32 ++++++++++++++++++++++++++++++++
t/t4018/static.cpp | 16 ++++++++++++++++
13 files changed, 232 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/ignore_declaration.cpp
create mode 100644 t/t4018/ignore_global.cpp
create mode 100644 t/t4018/ignore_label.cpp
create mode 100644 t/t4018/pointer_return.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..a3c4577 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/ChangeMe/IWasChanged/' < \"$f\" > \"$name.$p\" &&
+ test_expect_code 1 git diff -U1 --no-index \"$f\" \
+ \"$name.$p\" >actual &&
+ egrep '^@@ .* @@ .*RIGHT' 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..774c7f9
--- /dev/null
+++ b/t/t4018/broken_class_constructor.cpp
@@ -0,0 +1,16 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+RIGHT_function_hunk_header::RIGHT_function_hunk_header (void)
+{
+ const char *msg = "ChangeMe";
+ printf("Hello, world, %s\n", msg);
+ return 0;
+}
+
+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..3045fd1
--- /dev/null
+++ b/t/t4018/broken_class_destructor.cpp
@@ -0,0 +1,16 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+RIGHT_function_hunk_header::~RIGHT_function_hunk_header (void)
+{
+ const char *msg = "ChangeMe";
+ printf("Hello, world, %s\n", msg);
+ return 0;
+}
+
+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..58e574a
--- /dev/null
+++ b/t/t4018/broken_gnu_style.cpp
@@ -0,0 +1,17 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+int
+RIGHT_function_hunk_header (void)
+{
+ const char *msg = "ChangeMe";
+ printf("Hello, world, %s\n", msg);
+ return 0;
+}
+
+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..4d4549f
--- /dev/null
+++ b/t/t4018/broken_reference.cpp
@@ -0,0 +1,16 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+int& RIGHT_function_hunk_header (void)
+{
+ const char *msg = "ChangeMe";
+ printf("Hello, world, %s\n", msg);
+ return 0;
+}
+
+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..5c62e73
--- /dev/null
+++ b/t/t4018/broken_template.cpp
@@ -0,0 +1,16 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+template <class T> int RIGHT_function_hunk_header (T unused)
+{
+ const char *msg = "ChangeMe";
+ printf("Hello, world, %s\n", msg);
+ return 0;
+}
+
+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..fe53620
--- /dev/null
+++ b/t/t4018/class_method.cpp
@@ -0,0 +1,16 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+int test_class::RIGHT_function_hunk_header (void)
+{
+ const char *msg = "ChangeMe";
+ printf("Hello, world, %s\n", msg);
+ return 0;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/ignore_declaration.cpp b/t/t4018/ignore_declaration.cpp
new file mode 100644
index 0000000..ce7a0f6
--- /dev/null
+++ b/t/t4018/ignore_declaration.cpp
@@ -0,0 +1,17 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+int RIGHT_function_hunk_header (void)
+{
+ void WRONG_function_declaration_within_body (void);
+ const char *msg = "ChangeMe";
+ printf("Hello, world, %s\n", msg);
+ return 0;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/ignore_global.cpp b/t/t4018/ignore_global.cpp
new file mode 100644
index 0000000..95e23bc
--- /dev/null
+++ b/t/t4018/ignore_global.cpp
@@ -0,0 +1,19 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+int RIGHT_function_hunk_header (void)
+{
+ printf("Hello, world\n");
+ return 0;
+}
+
+int WRONG_global_variable;
+
+int ChangeMe;
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/ignore_label.cpp b/t/t4018/ignore_label.cpp
new file mode 100644
index 0000000..a8f407d
--- /dev/null
+++ b/t/t4018/ignore_label.cpp
@@ -0,0 +1,17 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+int RIGHT_function_hunk_header (void)
+{
+WRONG_should_not_match_label:
+ const char *msg = "ChangeMe";
+ printf("Hello, world, %s\n", msg);
+ return 0;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/pointer_return.cpp b/t/t4018/pointer_return.cpp
new file mode 100644
index 0000000..ea30d2d
--- /dev/null
+++ b/t/t4018/pointer_return.cpp
@@ -0,0 +1,16 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+static int *RIGHT_function_hunk_header (void)
+{
+ const char *msg = "ChangeMe";
+ printf("Hello, world, %s\n", msg);
+ return 0;
+}
+
+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..c96ad87
--- /dev/null
+++ b/t/t4018/simple.cpp
@@ -0,0 +1,32 @@
+/*
+ * 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)
+{
+ const char *msg = "ChangeMe";
+ printf("Hello, world, %s\n", msg);
+ return 0;
+}
+
+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..f6ee0f3
--- /dev/null
+++ b/t/t4018/static.cpp
@@ -0,0 +1,16 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+static int RIGHT_function_hunk_header (void)
+{
+ const char *msg = "ChangeMe";
+ printf("Hello, world, %s\n", msg);
+ return 0;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
--
1.7.8
^ permalink raw reply related
* Re: [PATCH 1/2] git-svn: multiple fetch/branches/tags keys are supported
From: Nathan Gray @ 2011-12-20 6:42 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Eric Wong
In-Reply-To: <20111220012350.GC20979@elie.hsd1.il.comcast.net>
Looks good! These doc changes will help a lot.
Thanks,
-Nathan
On Mon, Dec 19, 2011 at 5:23 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> From: Nathan Gray <n8gray@n8gray.org>
>
> "git svn" can be configured to use multiple fetch, branches, and tags
> refspecs by passing multiple --branches or --tags options at init time
> or editing the configuration file later, which can be handy when
> working with messy Subversion repositories. Add a note to the
> configuration section documenting how this works.
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> Documentation/git-svn.txt | 12 ++++++++++++
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index 34ee7850..66fd60a4 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -923,6 +923,18 @@ comma-separated list of names within braces. For example:
> tags = tags/{1.0,2.0}/src:refs/remotes/tags/*
> ------------------------------------------------------------------------
>
> +Multiple fetch, branches, and tags keys are supported:
> +
> +------------------------------------------------------------------------
> +[svn-remote "messy-repo"]
> + url = http://server.org/svn
> + fetch = trunk/project-a:refs/remotes/project-a/trunk
> + fetch = branches/demos/june-project-a-demo:refs/remotes/project-a/demos/june-demo
> + branches = branches/server/*:refs/remotes/project-a/branches/*
> + branches = branches/demos/2011/*:refs/remotes/project-a/2011-demos/*
> + tags = tags/server/*:refs/remotes/project-a/tags/*
> +------------------------------------------------------------------------
> +
> Note that git-svn keeps track of the highest revision in which a branch
> or tag has appeared. If the subset of branches or tags is changed after
> fetching, then .git/svn/.metadata must be manually edited to remove (or
> --
> 1.7.8
>
--
HexaLex: A New Angle on Crossword Games for iPhone and iPod Touch
http://hexalex.com
On The App Store: http://bit.ly/8Mj1CU
On Facebook: http://bit.ly/9MIJiV
On Twitter: http://twitter.com/hexalexgame
http://n8gray.org
^ 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