* 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] 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 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
* 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: 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: [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: 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: 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
* [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
* [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
* Re: git-p4: labels
From: Vitor Antunes @ 2011-12-20 12:03 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: Luke Diamand, Git List, Michael Horowitz
In-Reply-To: <20111220014753.GD20591@padd.com>
On Tue, Dec 20, 2011 at 1:47 AM, Pete Wyckoff <pw@padd.com> wrote:
> 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.
Now that you say that, it is now very difficult to detect branches on an
already imported repository. Maybe the new command could also do that?
In this case I would call it "git-p4 resync".
> [...]
> 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.
In labels this is easier and fast:
p4 changes -m 1 @label_name
Then we could diff the label against the changelist. If equal simply tag
the commit, if different then we need to create a temporary branch to
commit the changes and tag that instead.
--
Vitor Antunes
^ permalink raw reply
* Rewriting history and public-private-ish branches
From: Jay Levitt @ 2011-12-20 12:33 UTC (permalink / raw)
To: git@vger.kernel.org
I frequently conflate git-as-version-control with git-as-deployer when I'm
editing on my Mac but testing on a server. I'll do things like...
Mac: checkout -b origin/topic-branch
Mac: make a major change, commit and push
server: pull
[do while buggy]
server: discover a typo
Mac: fix the typo, commit and push
server: pull
[end]
Mac: squash commits
Mac: checkout master
Mac: merge topic-branch
Mac: branch -d topic-branch
Mac: push origin :topic-branch
As long as I'm the only one who's seen this "published" history, am I doing
anything bad? Do I leave any residue behind in the repo?
Jay Levitt
^ permalink raw reply
* Metadata storage - let's do this (was: "Tracking file metadata in git -- fix metastore or enhance git?") (was: "Revisiting metadata storage")
From: Richard Hartmann @ 2011-12-20 15:45 UTC (permalink / raw)
To: Git List
Cc: jrnieder, Ronan Keryell, hilco.wijbenga, Thorsten Glaser,
git.nabble.com
Hi all,
to summarize the current situation: quite a few people want to have
this, but no one seems to be willing to actually jump into the cold
water and swim.
I decided to scratch my own itch and started to collect requirements,
etc. Obviously, those are mine. I can already tell you that I will
focus on mtime and possibly EXIF support as that is what I need this
whole thing for.
You are very welcome to comment on any of this.
Please note that I decided not to tie this into git but to use a
separate file. The rationale being that, this way, normal git
operations are not impacted in any way and allowing re-use elsewhere.
General:
* Must work with non-git
* Must play nicely with git
** Must merge easily when there are no conflicts
** Must conflict merges if layout version is changed
* No XML as that does not merge
* Assuming I spear-head this effort, it will be in Perl 5
* Possible names include
** metamonger
** metamangler
** git meta
* Needs test suite
Storage:
* Versioned storage layout
* Tab-seperated list (handle file names containing tabs via escaping?)
* UTF-8 for file names, ISO-8859-1 for metadata
* All binary data, if any (support for xattr?) will be ASCII-armoured
* Metadata will be both machine and human readable _and_ explicitly be
designed to facilitate manual editing
Syntax:
$0 save # save metadata, recursively, to .meta.db
$0 apply # apply metadata, recursively, from .meta.db
$0 diff # guess.
-q : quiet
-m : comma-seperated list to override what data will be stored/applied/diffed
-f : specify file name to store to/apply from
-F: store to/apply from .meta.db.$HOSTNAME
-U: store to/apply from .meta.db.$(cat /etc/hostuuid)
--exif-db : EXIF <> db
--exif-file : EXIF <> file
I would like to have this tool be able to operate on EXIF data to see
if the file's mtime and creation time are the same. Very specific use
case, but hey. Maybe factor that out into a cleanly modularized system
and call if via a more generic interface, though
Depending on the feedback I get and how busy I am before christmas, I
may get an initial version up and running before 2012.
If you want to help, nag or anything, please do it asap.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH v2] t4018: introduce test cases for the internal hunk header patterns
From: Brandon Casey @ 2011-12-20 15:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: gitster, git, peff, j6t, jrnieder, trast
In-Reply-To: <m3pqfjfy42.fsf@localhost.localdomain>
On Tue, Dec 20, 2011 at 2:25 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> 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?
No, this one is placed here after the WRONG_global_variable to make
sure that a global variable is not chosen for the hunk header. It
should chose the most recently encountered function name for the hunk
header, which is RIGHT_function_hunk_header.
>> 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?
Whoops, I forgot about that text. Thanks for noticing. Yes this is
incorrect now. I think I'll break that out into a README file.
v3 forthcoming.
-Brandon
^ permalink raw reply
* Re: [PATCH 2/2] Documentation: make git-sh-setup docs less scary
From: Junio C Hamano @ 2011-12-20 19:20 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <c8867738c264a76f9662080b64e00615ec1aa28f.1324378986.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> 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.
You would need to say what that IRC user needed to find out. Depending on
that, letting the user know that there is no point reading on early and
not waste his or her time may be a good thing. That was what the paragraph
was designed for. IOW, it is not to "scare" away, but to allow the users
to decide if they are intended audiences.
The reworded version does avoid sounding scary, but loses the "this
document is for people who want to write new or understand existing
Porcelain scripts", which is a documentation regression.
> 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
^ permalink raw reply
* Re: [PATCH 1/2] git-sh-setup: make require_clean_work_tree part of the interface
From: Junio C Hamano @ 2011-12-20 19:25 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <c53feb0de8006c205fd26c2c07dcd78bd86b6c24.1324378986.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> 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.
Can we avoid explaining "clean" with the same word "clean", which adds no
new information? IOW, what does "clean" mean in the context of this helper
shell function? No untracked cruft? No un-added changes? What are the kind
of dirtiness being checked?
> +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.
^ permalink raw reply
* Re: Debugging git-commit slowness on a large repo
From: Joshua Redstone @ 2011-12-20 19:26 UTC (permalink / raw)
To: Thomas Rast
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy, Carlos Martín Nieto,
Tomas Carnecky, git@vger.kernel.org
In-Reply-To: <87wr9rk35n.fsf@thomas.inf.ethz.ch>
I looked again at my poor-mans-profiling output of git-add. The Sha1
stuff under ce_write_entry->ce_write_flush takes a bunch of time.
commit_lock_file->rename takes about the same as well.
Btw, the perf numbers for commit and add are with a warm file cache. I
expect the benefit of skipping all the stat() calls will increase for cold
cache.
Josh
On 12/20/11 1:23 AM, "Thomas Rast" <trast@student.ethz.ch> wrote:
>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 2/2] Documentation: make git-sh-setup docs less scary
From: Ævar Arnfjörð Bjarmason @ 2011-12-20 19:45 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <c8867738c264a76f9662080b64e00615ec1aa28f.1324378986.git.trast@student.ethz.ch>
On Tue, Dec 20, 2011 at 12:09, Thomas Rast <trast@student.ethz.ch> wrote:
> 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.
Arguably that's the point isn't it? To not have people who aren't
maintaining Git itself waste time on reading it.
Anyway I don't care how it's worded, but if you're going to patch it
you should probably do these too for consistency, since they
copy/paste this same blurb:
$ git --no-pager grep -l 'This is not a command the end user would
want to run. Ever.'
Documentation/git-mergetool--lib.txt
Documentation/git-sh-i18n--envsubst.txt
Documentation/git-sh-i18n.txt
Documentation/git-sh-setup.txt
And actually we might want to do all those with some asciidoc include
mechanism.
^ permalink raw reply
* Re: Escape character for .gitconfig
From: Dirk Süsserott @ 2011-12-20 19:46 UTC (permalink / raw)
To: Erik Blake; +Cc: git
In-Reply-To: <4EF04199.1010008@icefield.yk.ca>
Am 20.12.2011 09:04 schrieb Erik Blake:
> 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
Hi Erik,
oops, I overread that you talked about notepad (not notepad++) and the
<lf> stuff. My fault. I use the portable version of notepad++ and don't
have the "space in path" problem. But if you mainly use the git-bash (as
I do) instead of cmd.exe, then probably you could tweak your .bashrc:
export PATH="/C:/Program Files (x86)/Notepad++":$PATH
and then run notepad++ w/o giving the absolute path.
Cheers,
Dirk
^ permalink raw reply
* Re: [PATCH v2] t4018: introduce test cases for the internal hunk header patterns
From: Johannes Sixt @ 2011-12-20 19:52 UTC (permalink / raw)
To: Brandon Casey; +Cc: gitster, git, peff, jrnieder, trast
In-Reply-To: <1324348939-27115-1-git-send-email-drafnel@gmail.com>
Am 20.12.2011 03:42, schrieb Brandon Casey:
> +int WRONG_global_variable;
Personally, I'm not a fan of this one. IMHO, global variable
definitions need not be ignored. (But I can live with it.)
But here are some more tests that I care about and that you can squash in.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
t/t4018/broken_class_constructor.cpp | 3 +-
t/t4018/broken_return_type_in_global_namespace.cpp | 16 ++++++++++++++
t/t4018/class_definition.cpp | 19 +++++++++++++++++
t/t4018/derived_class_definition.cpp | 20 ++++++++++++++++++
t/t4018/ignore_access_specifier.cpp | 22 ++++++++++++++++++++
5 files changed, 79 insertions(+), 1 deletions(-)
create mode 100644 t/t4018/broken_return_type_in_global_namespace.cpp
create mode 100644 t/t4018/class_definition.cpp
create mode 100644 t/t4018/derived_class_definition.cpp
create mode 100644 t/t4018/ignore_access_specifier.cpp
diff --git a/t/t4018/broken_class_constructor.cpp b/t/t4018/broken_class_constructor.cpp
index 774c7f9..28c1bc8 100644
--- a/t/t4018/broken_class_constructor.cpp
+++ b/t/t4018/broken_class_constructor.cpp
@@ -3,7 +3,8 @@ int WRONG_function_hunk_header_preceding_the_right_one (void)
return 0;
}
-RIGHT_function_hunk_header::RIGHT_function_hunk_header (void)
+RIGHT_function_hunk_header::RIGHT_function_hunk_header (int x) :
+ WRONG_member_initializer(x)
{
const char *msg = "ChangeMe";
printf("Hello, world, %s\n", msg);
diff --git a/t/t4018/broken_return_type_in_global_namespace.cpp b/t/t4018/broken_return_type_in_global_namespace.cpp
new file mode 100644
index 0000000..da9931b
--- /dev/null
+++ b/t/t4018/broken_return_type_in_global_namespace.cpp
@@ -0,0 +1,16 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+::TypeInGlobalNamespace RIGHT_function_hunk_header()
+{
+ 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_definition.cpp b/t/t4018/class_definition.cpp
new file mode 100644
index 0000000..fc3df34
--- /dev/null
+++ b/t/t4018/class_definition.cpp
@@ -0,0 +1,19 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+class RIGHT_class_name
+{
+ void WRONG_function_name_following_the_right_one()
+ {
+ 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/derived_class_definition.cpp b/t/t4018/derived_class_definition.cpp
new file mode 100644
index 0000000..b8501a5
--- /dev/null
+++ b/t/t4018/derived_class_definition.cpp
@@ -0,0 +1,20 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+class RIGHT_class_name :
+ public WRONG_class_name_following_the_right_one
+{
+ void WRONG_function_name_following_the_right_one()
+ {
+ 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_access_specifier.cpp b/t/t4018/ignore_access_specifier.cpp
new file mode 100644
index 0000000..d865040
--- /dev/null
+++ b/t/t4018/ignore_access_specifier.cpp
@@ -0,0 +1,22 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+class RIGHT_class_name
+{
+public:
+protected:
+private:
+ void WRONG_function_name_following_the_right_one()
+ {
+ 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.216.g2e426
^ permalink raw reply related
* Re: [PATCH] t4018: introduce test cases for the internal hunk header patterns
From: Junio C Hamano @ 2011-12-20 20:08 UTC (permalink / raw)
To: Brandon Casey; +Cc: peff, git, j6t, jrnieder, Brandon Casey
In-Reply-To: <7vty4wkx19.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> 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.
Actually, I do not like this "broken_" filename prefix part. Even though I
can imagine "git show -M" would do a reasonable job, marking that a fix to
a pattern makes a test that used not to pass succeed by renaming a file
goes against the convention of changing one line to turn the "failure" to
"success" in test_expect_failure used in normal tests.
Can we use stable filename that says what is being tested instead?
^ permalink raw reply
* Re: [PATCH 2/2] Documentation: make git-sh-setup docs less scary
From: Thomas Rast @ 2011-12-20 20:27 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: git
In-Reply-To: <CACBZZX5BSfh8S9Kf1Wbi+NPEKpxJNXU8TD8-hkC2o1Mi91Or6A@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> On Tue, Dec 20, 2011 at 12:09, Thomas Rast <trast@student.ethz.ch> wrote:
>> 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.
>
> Arguably that's the point isn't it? To not have people who aren't
> maintaining Git itself waste time on reading it.
Junio C Hamano writes:
> You would need to say what that IRC user needed to find out. Depending on
> that, letting the user know that there is no point reading on early and
> not waste his or her time may be a good thing. That was what the paragraph
> was designed for. IOW, it is not to "scare" away, but to allow the users
> to decide if they are intended audiences.
Well, the original question was [*]
<ribasushi> how do I write a batch-test (goes in a script, exit value matters only) to test if the current workdir is clean?
<ribasushi> i.e. nothing staged/unstaged to commit
<shruggar> last I looked, there was no "all in one" method :/
<shruggar> git diff -q && git diff —cached -q, perhaps
<charon> ribasushi: . "$(git --exec-path)/git-sh-setup" ; require_clean_worktree
<shruggar> but I think that's ignoring something
<ribasushi> lack of output of `git status -s` seems to be what I want
<ribasushi> hmmm
<ribasushi> charon: git-gh-setup's manpage does not seem to list what you gave me
<ribasushi> and the manpage says that I should not be touching it...
Leaving aside my worktree vs. work_tree mistake, he concluded that he
should not be using it even though he is a script writer.
Regardless, I don't really care enough about this one; let's just do the
first patch (v2 upcoming) so that we have documentation to point people
at.
[*] http://colabti.org/irclogger/irclogger_log/git?date=2011-12-20#l1284
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH v2] git-sh-setup: make require_clean_work_tree part of the interface
From: Thomas Rast @ 2011-12-20 20:29 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vwr9rjbaq.fsf@alter.siamese.dyndns.org>
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>
---
Documentation/git-sh-setup.txt | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt
index a2f346c..9a0e574 100644
--- a/Documentation/git-sh-setup.txt
+++ b/Documentation/git-sh-setup.txt
@@ -68,6 +68,16 @@ 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 that the working tree associated with the repository
+ has no uncommitted changes to tracked files. 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
* [PATCH] t/t2023-checkout-m.sh: fix use of test_must_fail
From: Ævar Arnfjörð Bjarmason @ 2011-12-20 20:37 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Pete Harlan,
Ævar Arnfjörð Bjarmason
In-Reply-To: <4EDF1631.5090906@pcharlan.com>
Change an invocation of test_must_fail() to be inside a
test_expect_success() as is our usual pattern. Having it outside
caused our tests to fail under prove(1) since we wouldn't print a
newline before TAP output:
CONFLICT (content): Merge conflict in both.txt
# GETTEXT POISON #ok 2 - -m restores 2-way conflicted+resolved file
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
t/t2023-checkout-m.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/t/t2023-checkout-m.sh b/t/t2023-checkout-m.sh
index 1a40ce0..7e18985 100755
--- a/t/t2023-checkout-m.sh
+++ b/t/t2023-checkout-m.sh
@@ -17,7 +17,9 @@ test_expect_success setup '
test_commit added_in_topic each.txt in_topic
'
-test_must_fail git merge master
+test_expect_success 'git merge master' '
+ test_must_fail git merge master
+'
clean_branchnames () {
# Remove branch names after conflict lines
--
1.7.7.3
^ permalink raw reply related
* Re: [PATCH v2] git-sh-setup: make require_clean_work_tree part of the interface
From: Junio C Hamano @ 2011-12-20 20:52 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <23d761193dcf25f36206adc3d392e8578c566cd7.1324412815.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> 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>
> ---
> Documentation/git-sh-setup.txt | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt
> index a2f346c..9a0e574 100644
> --- a/Documentation/git-sh-setup.txt
> +++ b/Documentation/git-sh-setup.txt
> @@ -68,6 +68,16 @@ 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 that the working tree associated with the repository
> + has no uncommitted changes to tracked files. Otherwise it
> + emits an error message of the form `Cannot <action>:
> + <reason>. <hint>`, and dies. Example:
Doesn't it also enforce cleanliness on the index, not just the working tree?
> ++
> +----------------
> +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.
^ 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