* [PATCH 2/2] Documentation: make git-sh-setup docs less scary
From: Thomas Rast @ 2011-12-20 11:09 UTC (permalink / raw)
To: git
In-Reply-To: <c53feb0de8006c205fd26c2c07dcd78bd86b6c24.1324378986.git.trast@student.ethz.ch>
At least one IRC user was scared away by the introductory "This is not
a command the end user would want to run. Ever." to the point of not
reading on.
Reword it in a more matter-of-fact way that does not intentionally try
to scare the user away. Since 46bac90 (Do not install shell libraries
executable, 2010-01-31) it is not executable anyway, so the end user
would get
$ git sh-setup
fatal: cannot exec 'git-sh-setup': Permission denied
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/git-sh-setup.txt | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt
index bbfefca..612fb50 100644
--- a/Documentation/git-sh-setup.txt
+++ b/Documentation/git-sh-setup.txt
@@ -13,13 +13,10 @@ SYNOPSIS
DESCRIPTION
-----------
-This is not a command the end user would want to run. Ever.
-This documentation is meant for people who are studying the
-Porcelain-ish scripts and/or are writing new ones.
-
-The 'git sh-setup' scriptlet is designed to be sourced (using
-`.`) by other shell scripts to set up some variables pointing at
-the normal git directories and a few helper shell functions.
+This command cannot be run by the end user. Shell scripts can
+source it (using `.` as indicated above) to set up some variables
+pointing at the normal git directories and a few helper shell
+functions.
Before sourcing it, your script should set up a few variables;
`USAGE` (and `LONG_USAGE`, if any) is used to define message
--
1.7.8.484.gdad4270
^ permalink raw reply related
* [PATCH 1/2] git-sh-setup: make require_clean_work_tree part of the interface
From: Thomas Rast @ 2011-12-20 11:09 UTC (permalink / raw)
To: git
92c62a3 (Porcelain scripts: Rewrite cryptic "needs update" error
message, 2010-10-19) refactored git's own checking to a function in
git-sh-setup. This is a very useful thing for script writers, so
document it.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Noticed while helping ribasushi on IRC.
Documentation/git-sh-setup.txt | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt
index a2f346c..bbfefca 100644
--- a/Documentation/git-sh-setup.txt
+++ b/Documentation/git-sh-setup.txt
@@ -68,6 +68,15 @@ require_work_tree_exists::
cd_to_toplevel, which is impossible to do if there is no
working tree.
+require_clean_work_tree <action> [<hint>]::
+ checks if the working tree associated with the repository is
+ clean. Otherwise it emits an error message of the form
+ `Cannot <action>: <reason>. <hint>`, and dies. Example:
++
+----------------
+require_clean_work_tree rebase "Please commit or stash them."
+----------------
+
get_author_ident_from_commit::
outputs code for use with eval to set the GIT_AUTHOR_NAME,
GIT_AUTHOR_EMAIL and GIT_AUTHOR_DATE variables for a given commit.
--
1.7.8.484.gdad4270
^ permalink raw reply related
* Re: Introducing vcsh - manage config files in $HOME via fake bare git repositories
From: Richard Hartmann @ 2011-12-20 11:05 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Git List
In-Reply-To: <CAMK1S_hc4H7rUSY=SSR0EZwgBLy9CGa7b5H44eP6=fw+YC-inw@mail.gmail.com>
On Tue, Dec 20, 2011 at 03:25, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> 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.
Or mr[1]. That's _exactly_ what mr is for.
> Even my
> "irssi" settings are tied into that, because of certain macros I use
> to reply quickly to queries.
I doubt you want to keep your IRC passwords on a work machine, for
example. If you need repos to be together, check them out together.
But I doubt you want _everything_ _everywhere_.
> 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.
Symlinks are unclean, imo.
Personally, I like to use .zshrc.$HOSTNAME for local stuff. This sorts
more nicely than .$HOSTNAME.zshrc .
> 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.
Cloning from public repos seems to make more sense, especially if you
make local changes.
> Just offering a different perspective.
Appreciated. It's always great to know how others are approaching this.
Richard
^ permalink raw reply
* Re: Debugging git-commit slowness on a large repo
From: Thomas Rast @ 2011-12-20 9:23 UTC (permalink / raw)
To: Joshua Redstone
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy, Carlos Martín Nieto,
Tomas Carnecky, git@vger.kernel.org
In-Reply-To: <CB152498.2D6DB%joshua.redstone@fb.com>
Joshua Redstone <joshua.redstone@fb.com> writes:
> 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.
Note that the time to write the index itself is also rather small, but
the time needed to sha1 the index when loading and then again when
saving it really hurts.
(I noticed this while working on the commit-tree topic.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] t0090: be prepared that 'wc -l' writes leading blanks
From: Thomas Rast @ 2011-12-20 9:17 UTC (permalink / raw)
To: Johannes Sixt, Junio C Hamano; +Cc: Brian Gernhardt, Git List
In-Reply-To: <4EF04635.6020406@viscovery.net>
Sorry for slacking off on replying to this thread...
Johannes Sixt <j.sixt@viscovery.net> writes:
> Use 'printf %d $(whatever|wc -l)' so that the shell removes the blanks
> for us.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> Am 12/14/2011 16:41, schrieb Johannes Sixt:
>> I'd solve it by moving the command substitution outside the quoted string:
>>
>> printf "SHA (%d entries, 0 subtrees)\n" \
>> $(git ls-files | wc -l) >expect &&
>>
>> Other proposed solutions add another process. I don't like that on Windows ;)
>
> And here is a proper patch to that effect.
Acked-by: Thomas Rast <trast@student.ethz.ch>
This is the best solution also because it the formatting more (instead
of less) readable.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH v2] t4018: introduce test cases for the internal hunk header patterns
From: Thomas Rast @ 2011-12-20 9:13 UTC (permalink / raw)
To: Brandon Casey; +Cc: gitster, git, peff, j6t, jrnieder
In-Reply-To: <1324348939-27115-1-git-send-email-drafnel@gmail.com>
Brandon Casey <drafnel@gmail.com> writes:
> 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.
[...]
> int WRONG_function_hunk_header (void)
[...]
> int RIGHT_function_hunk_header (void)
> {
> const char *msg = "ChangeMe";
Excellent idea!
> +template <class T> int RIGHT_function_hunk_header (T unused)
> +{
> + const char *msg = "ChangeMe";
> + printf("Hello, world, %s\n", msg);
> + return 0;
> +}
I'd still like to have an extremely contrived overuse of templated
classes, like so:
---- 8< ----
int WRONG_function_hunk_header_preceding_the_right_one (void)
{
return 0;
}
foo::RIGHT<int*&,1>::operator<<(int bar)
{
const char *msg = "ChangeMe";
printf("Hello, world, %s\n", msg);
return 0;
}
int WRONG_function_hunk_header_following_the_right_one (void)
{
return 0;
}
---- >8 ----
That will guard us against updating the C++ pattern to something better
but still slightly too simple.
Other than that and Jakub's comments,
Acked-by: Thomas Rast <trast@student.ethz.ch>
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Escape character for .gitconfig
From: Erik Blake @ 2011-12-20 8:04 UTC (permalink / raw)
To: Dirk Süsserott; +Cc: Jeff King, git
In-Reply-To: <4EEF5F59.8030802@dirk.my1.cc>
Hi Dirk,
I ended up using "'C:/Program Files (x86)/Notepad++/notepad++.exe'
-multiInst -notabbar -nosession -noPlugin" which works nicely for me
(note the placement of the inner quotations).
It is notepad.exe (the default Windows editor) that fails on files with
only <lf> termination. That's why I was trying to set notepad++ as the
git editor as it is vastly superior.
Cheers,
Erik
On 2011-12-19 16:59, Dirk Süsserott wrote:
> 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: [PATCH v2] t4018: introduce test cases for the internal hunk header patterns
From: Jakub Narebski @ 2011-12-20 8:25 UTC (permalink / raw)
To: Brandon Casey; +Cc: gitster, git, peff, j6t, jrnieder, trast
In-Reply-To: <1324348939-27115-1-git-send-email-drafnel@gmail.com>
Brandon Casey <drafnel@gmail.com> writes:
> 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;
> +}
Shouldn't ChangeMe be inside function?
> 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
Shouldn't it be ChangeMe?
> + *
> + * 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.
> + */
--
Jakub Narêbski
^ permalink raw reply
* [PATCH] t0090: be prepared that 'wc -l' writes leading blanks
From: Johannes Sixt @ 2011-12-20 8:24 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List, Thomas Rast
In-Reply-To: <4EE8C3AD.9050605@viscovery.net>
From: Johannes Sixt <j6t@kdbg.org>
Use 'printf %d $(whatever|wc -l)' so that the shell removes the blanks
for us.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Am 12/14/2011 16:41, schrieb Johannes Sixt:
> I'd solve it by moving the command substitution outside the quoted string:
>
> printf "SHA (%d entries, 0 subtrees)\n" \
> $(git ls-files | wc -l) >expect &&
>
> Other proposed solutions add another process. I don't like that on Windows ;)
And here is a proper patch to that effect.
-- Hannes
t/t0090-cache-tree.sh | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/t/t0090-cache-tree.sh b/t/t0090-cache-tree.sh
index f972562..6c33e28 100755
--- a/t/t0090-cache-tree.sh
+++ b/t/t0090-cache-tree.sh
@@ -17,15 +17,13 @@ cmp_cache_tree () {
# test-dump-cache-tree already verifies that all existing data is
# correct.
test_shallow_cache_tree () {
- echo "SHA " \
- "($(git ls-files|wc -l) entries, 0 subtrees)" >expect &&
+ printf "SHA (%d entries, 0 subtrees)\n" $(git ls-files|wc -l) >expect &&
cmp_cache_tree expect
}
test_invalid_cache_tree () {
echo "invalid (0 subtrees)" >expect &&
- echo "SHA #(ref) " \
- "($(git ls-files|wc -l) entries, 0 subtrees)" >>expect &&
+ printf "SHA #(ref) (%d entries, 0 subtrees)\n" $(git ls-files|wc -l) >>expect &&
cmp_cache_tree expect
}
--
1.7.8.1499.g39f909
^ 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
* [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: 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
* 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
* 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: 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
* 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
* [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
* [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
* [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
* 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
* 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: 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
* 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: 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
* 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
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