* Re: Proposal: sharing .git/config
From: Thomas Rast @ 2013-02-19 10:39 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Thomas Rast, Git List
In-Reply-To: <CALkWK0m--MbtNzGH9hNPCCLJWhv6rjF9Y=WQ4qnHUFnE61p6kw@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Thomas Rast wrote:
>> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>>> There are also other things in .git/config that would be nice to
>>> share, like whether to do a --word-diff (why isn't it a configuration
>>> variable yet?)
>>
>> Because that would break pretty much every script that uses git-diff?
>
> diff.c already makes a differentiation between git_diff_ui_config()
> and git_diff_basic_config(); there are configuration options that
> should only be applied when the command is called interactively.
It still breaks every other use of diff unless you make the diff output
depend on whether the user runs directly at the terminal (possibly using
git's own paging).
For example, if you just say something like 'git diff >file' for
inclusion in an email, you expect that to be a git-apply compatible
diff.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH/RFC] clone: suggest index version 4 when the index is bigger than 512 KiB
From: Thomas Ackermann @ 2013-02-19 10:45 UTC (permalink / raw)
To: git
In-Reply-To: <1360848843-12092-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds <at> gmail.com> writes:
>
> I just realized that many of my big repos are still on index v2 while
> v4 should reduce its size significantly (3.8M -> 2.9M for linux-2.6
> and 25M -> 14M for webkit, for example). I wanted to propose index v4
> as the new default version, because I guess that not many people
> outside git <at> vger are aware of it, but perhaps this approach is less
> drastic. It only suggest index v4 when the index size after clone hits
> 512K limit.
>
Is V4 really recommended for general use?
Default seems to be V3 and all I found in the docs is
the coresponding release not describing V4 as "experimental".
(I have repos with index files > 40MiB (!) which will shrink to
approx. 20MiB with V4 so using V4 would be an interessting option for me.)
---
Thomas
^ permalink raw reply
* Re: [PATCH/RFC] clone: suggest index version 4 when the index is bigger than 512 KiB
From: Duy Nguyen @ 2013-02-19 10:54 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: git, Junio C Hamano
In-Reply-To: <loom.20130219T113730-546@post.gmane.org>
On Tue, Feb 19, 2013 at 5:45 PM, Thomas Ackermann <th.acker@arcor.de> wrote:
> Nguyễn Thái Ngọc Duy <pclouds <at> gmail.com> writes:
>
>>
>> I just realized that many of my big repos are still on index v2 while
>> v4 should reduce its size significantly (3.8M -> 2.9M for linux-2.6
>> and 25M -> 14M for webkit, for example). I wanted to propose index v4
>> as the new default version, because I guess that not many people
>> outside git <at> vger are aware of it, but perhaps this approach is less
>> drastic. It only suggest index v4 when the index size after clone hits
>> 512K limit.
>>
>
> Is V4 really recommended for general use?
> Default seems to be V3 and all I found in the docs is
> the coresponding release not describing V4 as "experimental".
> (I have repos with index files > 40MiB (!) which will shrink to
> approx. 20MiB with V4 so using V4 would be an interessting option for me.)
The default could be either v2 or v3, depending on whether you use
some extra features. v4 is basically v3 with pathname compression.
Yes, I think it's ok for general use.
--
Duy
^ permalink raw reply
* Re: Is this a bug?
From: Duy Nguyen @ 2013-02-19 11:02 UTC (permalink / raw)
To: kusmabite; +Cc: David Wade, git@vger.kernel.org
In-Reply-To: <CABPQNSY4ordHh2ee8mk-2kCD40+sMf_SxrjfzGbkyGGTNW1TzA@mail.gmail.com>
On Tue, Feb 19, 2013 at 4:47 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> On Tue, Feb 19, 2013 at 10:32 AM, David Wade <DAWAD@statoil.com> wrote:
>> Hi,
>>
>> I wrote a commit message beginning with a hash (#) character, like this: 'git commit -m "#ifdef ...." '
>>
>> Everything went okay when committing, but then I tried 'git commit -amend' and without editing the commit message I was told I had an empty commit message.
>>
>> Is this a problem with my text editor (vim 7.2) or git itself? (git version 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do ;-) ?
>
> The problem is that when doing interactive editing of messages (like
> 'git commit --amend' does), git considers '#' as a comment-character.
> You can disable this by using the --cleanup=verbatim switch (or some
> other suiting cleanup-setting, see 'git help commit').
Nobody is always conscious about the leading # in commit message to do
that. I once edited a commit message and the auto-wrap feature put '#'
at the beginning of the line. I saved and went on without noticing one
line was lost until much later :( Perhaps we should change the comment
signature a bit to reduce accidents, like only recognize '#' lines as
comments after a special line like
# this is not a comment
### START OF COMMENT ###
# this is a comment
--
Duy
^ permalink raw reply
* [PATCH] Documentation/githooks: Explain pre-rebase parameters
From: W. Trevor King @ 2013-02-19 11:03 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
From: "W. Trevor King" <wking@tremily.us>
Descriptions borrowed from templates/hooks--pre-rebase.sample.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
I'm not 100% convinced about this, because the git-rebase.sh uses:
"$GIT_DIR/hooks/pre-rebase" ${1+"$@"}
I haven't been able to find documentation for the ${1+"$@"} syntax.
Is it in POSIX? It's not in the Bash manual:
$ man bash | grep '\${.*[+]'
(${BASH_SOURCE[$i+1]}) where ${FUNCNAME[$i]} was called (or
${BASH_SOURCE[$i+1]}.
${BASH_SOURCE[$i+1]} at line number ${BASH_LINENO[$i]}. The
${parameter:+word}
In my local tests, it seems equivalent to "$@".
Also, it appears that the `git-rebase--*.sh` handlers don't use the
pre-rebase hook. Is this intentional?
Cheers,
Trevor
Documentation/githooks.txt | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index b9003fe..bc837c6 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -140,9 +140,10 @@ the outcome of 'git commit'.
pre-rebase
~~~~~~~~~~
-This hook is called by 'git rebase' and can be used to prevent a branch
-from getting rebased.
-
+This hook is called by 'git rebase' and can be used to prevent a
+branch from getting rebased. The hook takes two parameters: the
+upstream the series was forked from and the branch being rebased. The
+second parameter will be empty when rebasing the current branch.
post-checkout
~~~~~~~~~~~~~
--
1.8.1.336.g94702dd
^ permalink raw reply related
* Re: [RFC/PATCH] Introduce branch.<name>.pushremote
From: Blind @ 2013-02-19 11:18 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List
In-Reply-To: <CALkWK0kBjsHtK1_7imJx-7CATSKFzpUgGzH6Hs9DAQ8c7jRUPw@mail.gmail.com>
2013/2/19 Ramkumar Ramachandra:
> No. I don't see why push.default is limiting.
I just want to find a way to exclude a branch (or infact a group of
branches) from $git push --all.
so when I read your thing, I thought for a second that it could be a
possibility... But seems its not the case.
... or branch.<name>.pushremote can support some kind of a "none" value?
Blind.
^ permalink raw reply
* [PATCH] Bugfix: undefined htmldir in config.mak.autogen
From: Jiang Xin @ 2013-02-19 11:23 UTC (permalink / raw)
To: Junio C Hamano, Christoph J. Thompson; +Cc: Git List, Jiang Xin
Html documents will be installed to root dir (/) no matter what prefix
is set, if run these commands before `make` and `make install-html`:
$ make configure
$ ./configure --prefix=<PREFIX>
After the installation, all the html documents will copy to rootdir (/),
and:
$ git --html-path
<PREFIX>
$ git help -w something
fatal: '<PREFIX>': not a documentation directory.
This is because the variable "htmldir" points to a undefined variable
"$(docdir)" in file "config.mak.autogen", which is generated by running
`./configure`. This bug comes from commit fc1c541 (Honor configure's
htmldir switch), since v1.8.1.3-537-g1d321.
Add the required two variables "PACKAGE_TARNAME" and "docdir" to file
"config.mak.in" will resolve this problem.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
---
config.mak.in | 2 ++
1 file changed, 2 insertions(+)
diff --git a/config.mak.in b/config.mak.in
index d7c49..fa02bd 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -8,6 +8,7 @@ LDFLAGS = @LDFLAGS@
AR = @AR@
TAR = @TAR@
DIFF = @DIFF@
+PACKAGE_TARNAME = @PACKAGE_TARNAME@
#INSTALL = @INSTALL@ # needs install-sh or install.sh in sources
prefix = @prefix@
@@ -17,6 +18,7 @@ gitexecdir = @libexecdir@/git-core
datarootdir = @datarootdir@
template_dir = @datadir@/git-core/templates
sysconfdir = @sysconfdir@
+docdir = @docdir@
mandir = @mandir@
htmldir = @htmldir@
--
1.8.2.rc0.18.g63af42f.dirty
^ permalink raw reply
* Re: [RFC/PATCH] Introduce branch.<name>.pushremote
From: Ramkumar Ramachandra @ 2013-02-19 11:30 UTC (permalink / raw)
To: Blind; +Cc: Git List
In-Reply-To: <CAGL0X-qLikj3bKervpASEixnEVLjBGDN=8QX8K6SG-A2Z_dVUg@mail.gmail.com>
Blind wrote:
> 2013/2/19 Ramkumar Ramachandra:
>> No. I don't see why push.default is limiting.
>
> I just want to find a way to exclude a branch (or infact a group of
> branches) from $git push --all.
> so when I read your thing, I thought for a second that it could be a
> possibility... But seems its not the case.
What is your usecase? If you have a local branch with the same name
as on the remote, why wouldn't you want to push-to-update it when you
make changes in the branch? In other words, why doesn't push.default
= matching suffice for most practical purposes.
> ... or branch.<name>.pushremote can support some kind of a "none" value?
Not a bad idea at all, provided you tell me your usecase.
^ permalink raw reply
* Re: [RFC/PATCH] Introduce branch.<name>.pushremote
From: Blind @ 2013-02-19 11:51 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List
In-Reply-To: <CALkWK0nJbbA_wjo--LW9v7pP35LS4SUOhZjHVh4dbZqDjSJnew@mail.gmail.com>
2013/2/19 Ramkumar Ramachandra:
>
> What is your usecase? If you have a local branch with the same name
> as on the remote, why wouldn't you want to push-to-update it when you
> make changes in the branch? In other words, why doesn't push.default
> = matching suffice for most practical purposes.
>
>> ... or branch.<name>.pushremote can support some kind of a "none" value?
>
> Not a bad idea at all, provided you tell me your usecase.
The question is infact about branches who are not on the remote.
push.default=matching wouldn't upload the branches which are not there already.
push --all on other hand pushes .. all (as expected :-))...
Its difficult for me to manage quickly, lets say, "news-to-push/*" and
"crazy-ideas/*" branches ...
Blind.
^ permalink raw reply
* [PATCH v2 0/3] contrib/subtree: Store subtree sources in .gitsubtree
From: Paul Campbell @ 2013-02-19 12:28 UTC (permalink / raw)
To: git
Cc: Jonathan Nieder, Adam Tkac, David A. Greene, Jesper L. Nielsen,
Michael Schubert, Techlive Zheng
Thanks to Jonathan for the constructive criticism of the tests. Here
is the latest version.
I suspect I'll need to leave it until after David's changes to the
tests are merged into master, unless anyone thinks I should rebase
elsewhere. I think my tests only need a minor update to accommodate
those changes.
--
Paul [W] Campbell
^ permalink raw reply
* [PATCH v2 1/3] contrib/subtree: Store subtree sources in .gitsubtree
From: Paul Campbell @ 2013-02-19 12:29 UTC (permalink / raw)
To: git
Cc: Jonathan Nieder, Adam Tkac, David A. Greene, Jesper L. Nielsen,
Michael Schubert, Techlive Zheng
Add the prefix, repository and refspec in the file .gitsubtree when
git subtree add is used. Then when a git subtree push or pull is needed
the repository and refspec from .gitsubtree are used as the default
values.
Having to remember what subtree came from what source is a waste of
developer memory and doesn't transfer easily to other developers.
git subtree push/pull operations would typically be to/from the same
source that the original subtree was cloned from with git subtree add.
The <repository> and <refspec>, or <commit>, used in the git subtree add
operation are stored in .gitsubtree. One line each, delimited by a space:
"<prefix> <repository> <refspec>" or "<prefix> . <commit>".
Subsequent git subtree push/pull operations now default to the values
stored in .gitsubtree, unless overridden from the command line.
The .gitsubtree file should be tracked as part of the repo as it
describes where parts of the tree came from and can be used to update
to and from that source.
Signed-off-by: Paul Campbell <pcampbell@kemitix.net>
---
contrib/subtree/git-subtree.sh | 75 +++++++++++++++++++++++++++++++++++-------
1 file changed, 64 insertions(+), 11 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 8a23f58..1d0bf35 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -11,8 +11,8 @@ OPTS_SPEC="\
git subtree add --prefix=<prefix> <commit>
git subtree add --prefix=<prefix> <repository> <commit>
git subtree merge --prefix=<prefix> <commit>
-git subtree pull --prefix=<prefix> <repository> <refspec...>
-git subtree push --prefix=<prefix> <repository> <refspec...>
+git subtree pull --prefix=<prefix> [<repository> <refspec...>]
+git subtree push --prefix=<prefix> [<repository> <refspec...>]
git subtree split --prefix=<prefix> <commit...>
--
h,help show the help
@@ -489,6 +489,28 @@ ensure_clean()
fi
}
+add_subtree () {
+ if ( grep "^$dir " .gitsubtree 2>/dev/null )
+ then
+ # remove $dir from .gitsubtree - there's probably a clever way to
do this with sed
+ grep -v "^$dir " .gitsubtree >.gitsubtree.temp
+ rm .gitsubtree
+ mv .gitsubtree.temp .gitsubtree
+ fi
+ if test $# -eq 1
+ then
+ # Only a commit provided, thus use the current repository
+ echo "$dir . $@" >>.gitsubtree
+ elif test $# -eq 2
+ then
+ echo "$dir $@" >>.gitsubtree
+ fi
+}
+
+get_subtree () {
+ grep "^$dir " .gitsubtree || die "Subtree not found in .gitsubtree: " "$dir"
+}
+
cmd_add()
{
if [ -e "$dir" ]; then
@@ -497,6 +519,8 @@ cmd_add()
ensure_clean
+ add_subtree "$@"
+
if [ $# -eq 1 ]; then
git rev-parse -q --verify "$1^{commit}" >/dev/null ||
die "'$1' does not refer to a commit"
@@ -700,7 +724,23 @@ cmd_merge()
cmd_pull()
{
ensure_clean
- git fetch "$@" || exit $?
+ if test $# -eq 0
+ then
+ subtree=($(get_subtree))
+ repository=${subtree[1]}
+ refspec=${subtree[2]}
+ if test "$repository" == "."
+ then
+ echo "Pulling into $dir from branch $refspec"
+ else
+ echo "Pulling into $dir from $repository $refspec"
+ fi
+ echo "git fetch using: " $repository $refspec
+ git fetch "$repository" "$refspec" || exit $?
+ else
+ echo "git fetch using: $@"
+ git fetch "$@" || exit $?
+ fi
revs=FETCH_HEAD
set -- $revs
cmd_merge "$@"
@@ -708,16 +748,29 @@ cmd_pull()
cmd_push()
{
- if [ $# -ne 2 ]; then
- die "You must provide <repository> <refspec>"
+ repository=$1
+ refspec=$2
+ if test $# -eq 0
+ then
+ subtree=($(get_subtree))
+ repository=${subtree[1]}
+ refspec=${subtree[2]}
+ if test "$repository" == "."
+ then
+ echo "Pushing from $dir into branch $refspec"
+ else
+ echo "Pushing from $dir into $repository $refspec"
+ fi
+ elif test $# -ne 2
+ then
+ die "You must provide <repository> <refspec>, or a <prefix> listed
in .gitsubtree"
fi
- if [ -e "$dir" ]; then
- repository=$1
- refspec=$2
- echo "git push using: " $repository $refspec
- git push $repository $(git subtree split
--prefix=$prefix):refs/heads/$refspec
+ if test -e "$dir"
+ then
+ echo "git push using: " $repository $refspec
+ git push $repository $(git subtree split
--prefix=$prefix):refs/heads/$refspec
else
- die "'$dir' must already exist. Try 'git subtree add'."
+ die "'$dir' must already exist. Try 'git subtree add'."
fi
}
--
1.8.2.rc0.16.g20a599e
^ permalink raw reply related
* [PATCH v2 2/3] contrib/subtree/t: Added tests for .gitsubtree support
From: Paul Campbell @ 2013-02-19 12:31 UTC (permalink / raw)
To: git
Cc: Jonathan Nieder, Adam Tkac, David A. Greene, Jesper L. Nielsen,
Michael Schubert, Techlive Zheng
add: ensure details are added to .gitsubtree
push: check for a SHA1 update line
pull: add a file on one subtree, push it to a branch, then pull into
another subtree containing the same branch and confirm the files match
add: ensure stale .gitsubtree entry is replaced
Signed-off-by: Paul Campbell <pcampbell@kemitix.net>
---
contrib/subtree/t/t7900-subtree.sh | 42 ++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/contrib/subtree/t/t7900-subtree.sh
b/contrib/subtree/t/t7900-subtree.sh
index 80d3399..f1a24cf 100755
--- a/contrib/subtree/t/t7900-subtree.sh
+++ b/contrib/subtree/t/t7900-subtree.sh
@@ -465,4 +465,46 @@ test_expect_success 'verify one file change per commit' '
))
'
+# return to mainline
+cd ../..
+
+# .gitsubtree
+test_expect_success 'added repository appears in .gitsubtree' '
+ git subtree add --prefix=copy0 sub1 &&
+ grep "^copy0 \. sub1$" .gitsubtree
+'
+
+test_expect_success 'change in subtree is pushed okay' '
+ (
+ cd copy0 &&
+ create new_file &&
+ git commit -m"Added new_file"
+ ) &&
+ git ls-tree refs/heads/sub1 >output &&
+ ! grep "new_file$" output &&
+ git subtree push --prefix=copy0 &&
+ git ls-tree refs/heads/sub1 >output &&
+ grep "new_file$" output
+'
+
+test_expect_success 'pull into subtree okay' '
+ git subtree add --prefix=copy1 sub1 &&
+ git subtree add --prefix=copy2 sub1 &&
+ (
+ cd copy1 &&
+ create new_file_in_copy1 &&
+ git commit -m"Added new_file_in_copy1"
+ ) &&
+ git subtree push --prefix=copy1 &&
+ git subtree pull --prefix=copy2 >output &&
+ grep "^ create mode 100644 copy2/new_file_in_copy1$" output
+'
+
+test_expect_success 'replace outdated entry in .gitsubtree' '
+ echo "copy3 . sub2" >>.gitsubtree &&
+ git subtree add --prefix=copy3 sub1 &&
+ ! grep "^copy3 . sub2$" .gitsubtree &&
+ grep "^copy3 . sub1$" .gitsubtree
+'
+
test_done
--
1.8.2.rc0.16.g20a599e
^ permalink raw reply related
* [PATCH v2 3/3] contrib/subtree: update documentation
From: Paul Campbell @ 2013-02-19 12:32 UTC (permalink / raw)
To: git
Cc: Jonathan Nieder, Adam Tkac, David A. Greene, Jesper L. Nielsen,
Michael Schubert, Techlive Zheng
Indicate that repository and refspec are now optional on push and pull.
Add notes to add, push and pull about storing values in .gitsubtree
and their use as default values.
Signed-off-by: Paul Campbell <pcampbell@kemitix.net>
---
contrib/subtree/git-subtree.txt | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt
index 7ba853e..2ad9278 100644
--- a/contrib/subtree/git-subtree.txt
+++ b/contrib/subtree/git-subtree.txt
@@ -11,8 +11,8 @@ SYNOPSIS
[verse]
'git subtree' add -P <prefix> <refspec>
'git subtree' add -P <prefix> <repository> <refspec>
-'git subtree' pull -P <prefix> <repository> <refspec...>
-'git subtree' push -P <prefix> <repository> <refspec...>
+'git subtree' pull -P [<prefix> <repository> <refspec...>]
+'git subtree' push -P [<prefix> <repository> <refspec...>]
'git subtree' merge -P <prefix> <commit>
'git subtree' split -P <prefix> [OPTIONS] [<commit>]
@@ -72,7 +72,9 @@ add::
A new commit is created automatically, joining the imported
project's history with your own. With '--squash', imports
only a single commit from the subproject, rather than its
- entire history.
+ entire history. Details of the <prefix> are added to the
+ .gitsubtree file, where they will be used as defaults for
+ 'push' and 'pull'.
merge::
Merge recent changes up to <commit> into the <prefix>
@@ -91,13 +93,16 @@ merge::
pull::
Exactly like 'merge', but parallels 'git pull' in that
it fetches the given commit from the specified remote
- repository.
+ repository. Default values for <repository> and <refspec>
+ are taken from the .gitsubtree file.
push::
Does a 'split' (see below) using the <prefix> supplied
and then does a 'git push' to push the result to the
repository and refspec. This can be used to push your
subtree to different branches of the remote repository.
+ Default values for <repository> and <refspec> are taken
+ from the .gitsubtree file.
split::
Extract a new, synthetic project history from the
--
1.8.2.rc0.16.g20a599e
^ permalink raw reply related
* Re: inotify to minimize stat() calls
From: Drew Northup @ 2013-02-19 13:16 UTC (permalink / raw)
To: Duy Nguyen
Cc: Ramkumar Ramachandra, Robert Zeh, Junio C Hamano, Git List,
finnag
In-Reply-To: <CACsJy8DeM5--WVXg3b65RxLBS7Jho-7KmcGwWk7B5uAx77yOEw@mail.gmail.com>
On Sun, Feb 10, 2013 at 12:24 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Sun, Feb 10, 2013 at 12:10 AM, Ramkumar Ramachandra
> <artagnon@gmail.com> wrote:
>> Finn notes in the commit message that it offers no speedup, because
>> .gitignore files in every directory still have to be read. I think
>> this is silly: we really should be caching .gitignore, and touching it
>> only when lstat() reports that the file has changed.
>> ...
>> Really, the elephant in the room right now seems to be .gitignore.
>> Until that is fixed, there is really no use of writing this inotify
>> daemon, no? Can someone enlighten me on how exactly .gitignore files
>> are processed?
>
> .gitignore is a different issue. I think it's mainly used with
> read_directory/fill_directory to collect ignored files (or not-ignored
> files). And it's not always used (well, status and add does, but diff
> should not). I think wee need to measure how much mass lstat
> elimination gains us (especially on big repos) and how much
> .gitignore/.gitattributes caching does. I don't think .gitignore has
> such a big impact though. strace on git.git tells me "git status"
> issues about 2500 lstat calls, and just 740 open+getdents calls (on
> total 3800 syscalls). I will think if we can do something about
> .gitignore/.gitattributes.
> --
> Duy
Duy,
Did your testing turn up anything about the amount of time spent
parsing the .gitignore/.gitattributes files? Not the syscall count,
but the actual time spent running the parser (which I presume is
largely CPU-bound). The other notable bit of information to know would
be how much time is spent applying what has been parsed out of those
files to the content of the tree. Both will give a clear signal of the
prominence of those segments of code versus others elsewhere in the
"git stat" flow path. That information will tell us more clearly what,
if anything, it is worth keeping a cache of and what form that cache
should take.
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: [PATCH] Documentation/githooks: Explain pre-rebase parameters
From: Thomas Rast @ 2013-02-19 13:17 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git, Junio C Hamano
In-Reply-To: <c19c03f51d71a58fa3795f665fe4a4c0461fa58f.1361271116.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> I'm not 100% convinced about this, because the git-rebase.sh uses:
>
> "$GIT_DIR/hooks/pre-rebase" ${1+"$@"}
>
> I haven't been able to find documentation for the ${1+"$@"} syntax.
> Is it in POSIX? It's not in the Bash manual:
[...]
> In my local tests, it seems equivalent to "$@".
It's definitely in the bash manual and POSIX[1]: it's a special case of
the ${parameter+word} expansion.
${parameter:+word}
Use Alternate Value. If parameter is null or unset, nothing is
substituted, otherwise the expansion of word is substituted.
plus
... bash tests for a parameter that is unset or null. Omitting the
colon results in a test only for a parameter that is unset.
IIRC this particular usage was designed to suppress warnings about unset
variables.
Footnotes:
[1] http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] Documentation/githooks: Explain pre-rebase parameters
From: W. Trevor King @ 2013-02-19 13:23 UTC (permalink / raw)
To: Thomas Rast; +Cc: Git, Junio C Hamano
In-Reply-To: <878v6ksars.fsf@pctrast.inf.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 673 bytes --]
On Tue, Feb 19, 2013 at 02:17:43PM +0100, Thomas Rast wrote:
> "W. Trevor King" <wking@tremily.us> writes:
> > I haven't been able to find documentation for the ${1+"$@"} syntax.
> > Is it in POSIX? It's not in the Bash manual:
> [...]
> > In my local tests, it seems equivalent to "$@".
>
> It's definitely in the bash manual and POSIX[1]: it's a special case of
> the ${parameter+word} expansion.
I need to read more carefully ;). There's even a nice table in the
POSIX specs…
Thanks,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [BUG] git-check-ignore: Segmentation fault
From: Adam Spiers @ 2013-02-19 13:40 UTC (permalink / raw)
To: Zoltan Klinger; +Cc: GIT Mailing-list
In-Reply-To: <CAKJhZwR7AT6VfCZYwaTvWYyjtYWg+RxBSmB5NaJY0LrqMUnD6A@mail.gmail.com>
On Tue, Feb 19, 2013 at 5:24 AM, Zoltan Klinger
<zoltan.klinger@gmail.com> wrote:
> Hi there,
>
> The new git-check-ignore command seg faults when
> (1) it is called with single dot path name at $GIT_DIR level _AND_
> (2) and .gitignore has at least one directory pattern.
>
> Git version: 1.8.2.rc0.16.g20a599e
>
> Reproduce the bug:
> $ git --version
> git version 1.8.2.rc0.16.g20a599e
> $ mkdir test
> $ cd test
> $ git init
> $ git check-ignore . # All good, no errors here
> $ echo "dirpattern/" > .gitignore
> $ git check-ignore .
> Segmentation fault (core dumped)
>
> The segmentation fault is actually caused by hash_name(const char
> *name, int namelen) function in name-hash.c when the 'name' argument
> is an empty stringi and namelen is 0.
>
> The empty string comes from a call to the prefix_path(prefix, len,
> path) function in setup.c. In this instance arguments 'prefix' is
> NULL, 'len' is 0 and 'path' is "." .
Good catch! Thanks for the very helpful bug report. I can reproduce
this, and have a fix - see follow-up mail to follow shortly.
^ permalink raw reply
* Re: inotify to minimize stat() calls
From: Duy Nguyen @ 2013-02-19 13:47 UTC (permalink / raw)
To: Drew Northup
Cc: Ramkumar Ramachandra, Robert Zeh, Junio C Hamano, Git List,
finnag
In-Reply-To: <CAM9Z-nnWE9LeHaefKdju_p=_he7aJcOunGf1Ms6K=vEXgxS25w@mail.gmail.com>
On Tue, Feb 19, 2013 at 8:16 PM, Drew Northup <n1xim.email@gmail.com> wrote:
> Did your testing turn up anything about the amount of time spent
> parsing the .gitignore/.gitattributes files? Not the syscall count,
> but the actual time spent running the parser (which I presume is
> largely CPU-bound). The other notable bit of information to know would
> be how much time is spent applying what has been parsed out of those
> files to the content of the tree. Both will give a clear signal of the
> prominence of those segments of code versus others elsewhere in the
> "git stat" flow path. That information will tell us more clearly what,
> if anything, it is worth keeping a cache of and what form that cache
> should take.
Not specifically parsing, but we do waste CPU on
.gitignore/.gitattributes stuff. See
http://thread.gmane.org/gmane.comp.version-control.git/216347/focus=216381
Other measurements (which led to the above patch):
http://thread.gmane.org/gmane.comp.version-control.git/215820/focus=215900
http://thread.gmane.org/gmane.comp.version-control.git/215820/focus=216029
http://thread.gmane.org/gmane.comp.version-control.git/215820/focus=216195
So far we could reduce lstat, {open,read,close}dir syscalls with the
help of inotify, which saves time. I'm not sure if we should cache the
list of untracked-but-not-ignored files. It cuts down cpu time on
.gitignore but invalidation could be complicated.
--
Duy
^ permalink raw reply
* [PATCH 1/2] t0008: document test_expect_success_multi
From: Adam Spiers @ 2013-02-19 14:06 UTC (permalink / raw)
To: git list; +Cc: Zoltan Klinger
In-Reply-To: <CAOkDyE_96Ef5CjoxNk3mbsNi+ZAuv6XeHcO7r8RQ-Of5ELsuKw@mail.gmail.com>
test_expect_success_multi() helper function warrants some explanation,
since at first sight it may seem like generic test framework plumbing,
but is in fact specific to testing check-ignore, and allows more
thorough testing of the various output formats without significantly
increase the size of t0008.
Signed-off-by: Adam Spiers <git@adamspiers.org>
---
t/t0008-ignores.sh | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
index d7df719..ebe7c70 100755
--- a/t/t0008-ignores.sh
+++ b/t/t0008-ignores.sh
@@ -75,6 +75,16 @@ test_check_ignore () {
stderr_empty_on_success "$expect_code"
}
+# Runs the same code with 3 different levels of output verbosity,
+# expecting success each time. Takes advantage of the fact that
+# check-ignore --verbose output is the same as normal output except
+# for the extra first column.
+#
+# Arguments:
+# - (optional) prereqs for this test, e.g. 'SYMLINKS'
+# - test name
+# - output to expect from -v / --verbose mode
+# - code to run (should invoke test_check_ignore)
test_expect_success_multi () {
prereq=
if test $# -eq 4
--
1.8.1.291.g0730ed6
^ permalink raw reply related
* [PATCH 2/2] check-ignore.c: fix segfault with '.' argument from repo root
From: Adam Spiers @ 2013-02-19 14:06 UTC (permalink / raw)
To: git list; +Cc: Zoltan Klinger
In-Reply-To: <1361282783-1413-1-git-send-email-git@adamspiers.org>
Fix a corner case where check-ignore would segfault when run with the
'.' argument from the top level of a repository, due to prefix_path()
converting '.' into the empty string. It doesn't make much sense to
call check-ignore from the top level with '.' as a parameter, since
the top-level directory would never typically be ignored, but of
course it should not segfault in this case.
Signed-off-by: Adam Spiers <git@adamspiers.org>
---
builtin/check-ignore.c | 2 +-
t/t0008-ignores.sh | 5 +++++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/builtin/check-ignore.c b/builtin/check-ignore.c
index 709535c..b0dd7c2 100644
--- a/builtin/check-ignore.c
+++ b/builtin/check-ignore.c
@@ -89,7 +89,7 @@ static int check_ignore(const char *prefix, const char **pathspec)
? strlen(prefix) : 0, path);
full_path = check_path_for_gitlink(full_path);
die_if_path_beyond_symlink(full_path, prefix);
- if (!seen[i] && path[0]) {
+ if (!seen[i] && full_path[0]) {
exclude = last_exclude_matching_path(&check, full_path,
-1, &dtype);
if (exclude) {
diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
index ebe7c70..9c1bde1 100755
--- a/t/t0008-ignores.sh
+++ b/t/t0008-ignores.sh
@@ -138,6 +138,7 @@ test_expect_success 'setup' '
cat <<-\EOF >.gitignore &&
one
ignored-*
+ top-level-dir/
EOF
for dir in . a
do
@@ -177,6 +178,10 @@ test_expect_success 'setup' '
#
# test invalid inputs
+test_expect_success_multi '. corner-case' '' '
+ test_check_ignore . 1
+'
+
test_expect_success_multi 'empty command line' '' '
test_check_ignore "" 128 &&
stderr_contains "fatal: no path specified"
--
1.8.1.291.g0730ed6
^ permalink raw reply related
* Re: inotify to minimize stat() calls
From: Karsten Blees @ 2013-02-19 14:25 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Duy Nguyen, kusmabite, Robert Zeh, Junio C Hamano, Git List,
finnag
In-Reply-To: <CALkWK0=XFBfZjO3oCJ8Jxya1ud79MQcQFm6pmZpOU8c3MxVtqQ@mail.gmail.com>
Am 19.02.2013 10:49, schrieb Ramkumar Ramachandra:
> Karsten Blees wrote:
>> Am 11.02.2013 04:53, schrieb Duy Nguyen:
>>> On Sun, Feb 10, 2013 at 11:58 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>>>> Karsten Blees has done something similar-ish on Windows, and he posted
>>>> the results here:
>>>>
>>>> https://groups.google.com/forum/#!topic/msysgit/fL_jykUmUNE/discussion
>>>>
>>
>> The new hashtable implementation in fscache [1] supports O(1) removal and has no mingw dependencies - might come in handy for anyone trying to implement an inotify daemon.
>>
>> [1] https://github.com/kblees/git/commit/f7eb85c2
>
> Thanks! I'm cherry-picking this. Why didn't you propose replacing
> hash.{c,h} with this in git.git though?
>
I was planning to, but didn't find the time yet to adapt existing hash.[ch] uses to the new version, and there's not much use adding four more files of dead code. If someone else could jump in here that would be great.
Note that there's another t0007 now, so t/t0007-hashmap.sh needs to be renamed.
>>>> I also seem to remember he doing a ReadDirectoryChangesW version, but
>>>> I don't remember what happened with that.
>>>
>>> Thanks. I came across that but did not remember. For one thing, we
>>> know the inotify alternative for Windows: ReadDirectoryChangesW.
>>>
>>
>> I dropped ReadDirectoryChangesW because maintaining a 'live' file system cache became more and more complicated. For example, according to MSDN docs, ReadDirectoryChangesW *may* report short DOS 8.3 names (i.e. "PROGRA~1" instead of "Program Files"), so a correct and fast cache implementation would have to be indexed by long *and* short names...
>>
>> Another problem was that the 'live' cache had quite negative performance impact on mutating git commands (checkout, reset...). An inotify daemon running as a background process (not in-process as fscache) will probably affect everyone that modifies the working copy, e.g. running 'make' or the test-suite. This should be considered in the design.
>
> Yes, an external daemon would report creation of *.o files, from the
> compile, for instance. We need a way for it to be filtered at the
> daemon itself, so git isn't burdened with the filtering.
>
...and this filtering should affect foreground processes as little as possible. For example, gaining 1 s per git-status is counter-productive if compile time increases by 10 s because the daemon re-reads .gitignore files for every new *.o.
^ permalink raw reply
* Re: Proposal: sharing .git/config
From: Adam Spiers @ 2013-02-19 14:38 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List
In-Reply-To: <CALkWK0npW6TLdMNd5_zw-RAB0bjF9DDoyAVSx4Zx=7AmvdEo3w@mail.gmail.com>
On Tue, Feb 19, 2013 at 9:25 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Hi,
>
> I have this itch where I want to share my remotes config between
> machines. In my fork, I should be able to specify where my upstream
> sources are, so remotes get set up automatically when I clone. There
> are also other things in .git/config that would be nice to share, like
> whether to do a --word-diff (why isn't it a configuration variable
> yet?) on the repository. The only problem is that I have no clue how
> to implement this: I'm currently thinking a special remote ref?
I handle these kinds of configuration tasks out of band using mr,
and it works pretty well:
https://github.com/aspiers/mr-config/#readme
https://github.com/aspiers/mr-config/blob/master/sh.d/git-remotes
Food for thought ...
^ permalink raw reply
* Re: [PATCH] l10n: de.po: translate 35 new messages
From: Michael J Gruber @ 2013-02-19 15:06 UTC (permalink / raw)
To: Ralf Thielow; +Cc: trast, jk, stimming, git
In-Reply-To: <1361211754-5641-1-git-send-email-ralf.thielow@gmail.com>
Ralf Thielow venit, vidit, dixit 18.02.2013 19:22:
> Translate 35 new messages came from git.pot update
> in 9caaf23 (l10n: Update git.pot (35 new, 14 removed
> messages)).
>
> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
> ---
> po/de.po | 140 +++++++++++++++++++++++++++++++--------------------------------
> 1 file changed, 68 insertions(+), 72 deletions(-)
>
> diff --git a/po/de.po b/po/de.po
> index df98a0f..9690cd7 100644
> --- a/po/de.po
> +++ b/po/de.po
> @@ -358,14 +358,14 @@ msgid "gpg failed to sign the data"
> msgstr "gpg beim Signieren der Daten fehlgeschlagen"
>
> #: gpg-interface.c:112
> -#, fuzzy, c-format
> +#, c-format
> msgid "could not create temporary file '%s': %s"
> -msgstr "konnte Datei '%s' nicht erstellen"
> +msgstr "konnte temporäre Datei '%s' nicht erstellen: %s"
>
> #: gpg-interface.c:115
> -#, fuzzy, c-format
> +#, c-format
> msgid "failed writing detached signature to '%s': %s"
> -msgstr "Fehler beim Erstellen des Pfades '%s'%s"
> +msgstr "Fehler beim Schreiben der Signatur nach '%s': %s"
>
> #: grep.c:1622
> #, c-format
> @@ -1443,9 +1443,8 @@ msgid "failed to unlink '%s'"
> msgstr "Konnte '%s' nicht entfernen"
Maybe a "." at the end, or begin with lower case.
> #: builtin/add.c:20
> -#, fuzzy
> msgid "git add [options] [--] <pathspec>..."
> -msgstr "git add [Optionen] [--] [<Dateimuster>...]"
> +msgstr "git add [Optionen] [--] [<Pfadspezifikation>...]"
>
> #: builtin/add.c:63
> #, c-format
> @@ -1601,6 +1600,21 @@ msgid ""
> "With the current Git version, the command is restricted to the current "
> "directory."
> msgstr ""
> +"Das Verhalten von 'git add %s (oder %s)' ohne ein Pfad-Argument von\n"
> +"einem Unterverzeichnis aus, wird in Git 2.0 geändert und sollte nicht\n"
There should be no "," here because there is no subclause.
> +"mehr verwendet werden.\n"
> +"Um Dateien des gesamten Projektverzeichnisses hinzuzufügen, führen Sie aus:\n"
There can be a comma here, it is a (shortened subclause).
> +"\n"
> +" git add %s :/\n"
> +" (oder git add %s :/)\n"
> +"\n"
> +"Zur Einschränkung auf das aktuelle Verzeichnis, führen Sie aus:\n"
There should be no "," here because there is no subclause.
Rest looks fine (Thomas mentioned the missed "rename" already).
> +"\n"
> +" git add %s .\n"
> +" (oder git add %s .)\n"
> +"\n"
> +"Mit der aktuellen Version von Git ist das Kommando auf das aktuelle\n"
> +"Verzeichnis beschränkt."
>
> #: builtin/add.c:381
> msgid "-A and -u are mutually incompatible"
> @@ -2412,16 +2426,16 @@ msgstr "[%d voraus, %d hinterher]"
>
> #: builtin/branch.c:469
> msgid " **** invalid ref ****"
> -msgstr ""
> +msgstr " **** ungültige Referenz ****"
>
> #: builtin/branch.c:560
> msgid "(no branch)"
> msgstr "(kein Zweig)"
>
> #: builtin/branch.c:593
> -#, fuzzy, c-format
> +#, c-format
> msgid "object '%s' does not point to a commit"
> -msgstr "'%s' zeigt auf keine Version"
> +msgstr "Objekt '%s' zeigt auf keine Version"
>
> #: builtin/branch.c:625
> msgid "some refs could not be read"
> @@ -2571,33 +2585,30 @@ msgid "--column and --verbose are incompatible"
> msgstr "Die Optionen --column und --verbose sind inkompatibel."
>
> #: builtin/branch.c:845
> -#, fuzzy
> msgid "branch name required"
> -msgstr "Kein Zweigname spezifiziert"
> +msgstr "Zweigname erforderlich"
>
> #: builtin/branch.c:860
> -#, fuzzy
> msgid "Cannot give description to detached HEAD"
> -msgstr "Kann Hauptzweig des externen Projektarchivs nicht bestimmen"
> +msgstr "zu losgelöster Zweigspitze (HEAD) kann keine Beschreibung hinterlegt werden"
>
> #: builtin/branch.c:865
> -#, fuzzy
> msgid "cannot edit description of more than one branch"
> -msgstr "bearbeitet die Beschreibung für den Zweig"
> +msgstr "Beschreibung von mehr als einem Zweig kann nicht bearbeitet werden"
>
> #: builtin/branch.c:872
> -#, fuzzy, c-format
> +#, c-format
> msgid "No commit on branch '%s' yet."
> -msgstr "Kein solcher Zweig '%s'"
> +msgstr "Noch keine Version in Zweig '%s'."
>
> #: builtin/branch.c:875
> -#, fuzzy, c-format
> +#, c-format
> msgid "No branch named '%s'."
> -msgstr "Ungültiger Zweig-Name: '%s'"
> +msgstr "Zweig '%s' nicht vorhanden."
>
> #: builtin/branch.c:888
> msgid "too many branches for a rename operation"
> -msgstr ""
> +msgstr "zu viele Zweige angegeben"
>
> #: builtin/branch.c:893
> #, c-format
> @@ -2731,28 +2742,24 @@ msgid "suppress progress reporting"
> msgstr "unterdrückt Fortschrittsanzeige"
>
> #: builtin/check-ignore.c:151
> -#, fuzzy
> msgid "cannot specify pathnames with --stdin"
> -msgstr "kann -a nicht mit -d benutzen"
> +msgstr "Angabe von Pfadnamen kann nicht gemeinsam mit --stdin verwendet werden"
>
> #: builtin/check-ignore.c:154
> msgid "-z only makes sense with --stdin"
> -msgstr ""
> +msgstr "Die Option -z kann nur mit --stdin verwendet werden."
>
> #: builtin/check-ignore.c:156
> -#, fuzzy
> msgid "no path specified"
> -msgstr "kein externes Projektarchiv angegeben"
> +msgstr "kein Pfad angegeben"
>
> #: builtin/check-ignore.c:160
> -#, fuzzy
> msgid "--quiet is only valid with a single pathname"
> -msgstr "verwendet [PATCH n/m] auch mit einzelnem Patch"
> +msgstr "Die Option --quiet ist nur mit einem einzelnen Pfadnamen gültig."
>
> #: builtin/check-ignore.c:162
> -#, fuzzy
> msgid "cannot have both --quiet and --verbose"
> -msgstr "Kann den aktuellen Zustand der Bereitstellung nicht speichern"
> +msgstr "Die Optionen --quiet und --verbose können nicht gemeinsam verwendet werden."
>
> #: builtin/checkout-index.c:126
> msgid "git checkout-index [options] [--] [<file>...]"
> @@ -3421,14 +3428,12 @@ msgid "--command must be the first argument"
> msgstr "Die Option --command muss an erster Stelle stehen."
>
> #: builtin/commit.c:34
> -#, fuzzy
> msgid "git commit [options] [--] <pathspec>..."
> -msgstr "git commit [Optionen] [--] <Dateimuster>..."
> +msgstr "git commit [Optionen] [--] <Pfadspezifikation>..."
>
> #: builtin/commit.c:39
> -#, fuzzy
> msgid "git status [options] [--] <pathspec>..."
> -msgstr "git status [Optionen] [--] <Dateimuster>..."
> +msgstr "git status [Optionen] [--] <Pfadspezifikation>..."
>
> #: builtin/commit.c:44
> msgid ""
> @@ -3604,17 +3609,17 @@ msgstr ""
> "und versuchen Sie es erneut.\n"
>
> #: builtin/commit.c:735
> -#, fuzzy, c-format
> +#, c-format
> msgid ""
> "Please enter the commit message for your changes. Lines starting\n"
> "with '%c' will be ignored, and an empty message aborts the commit.\n"
> msgstr ""
> "Bitte geben Sie eine Versionsbeschreibung für Ihre Änderungen ein. Zeilen,\n"
> -"die mit '#' beginnen, werden ignoriert, und eine leere Versionsbeschreibung\n"
> +"die mit '%c' beginnen, werden ignoriert, und eine leere Versionsbeschreibung\n"
> "bricht die Eintragung ab.\n"
>
> #: builtin/commit.c:740
> -#, fuzzy, c-format
> +#, c-format
> msgid ""
> "Please enter the commit message for your changes. Lines starting\n"
> "with '%c' will be kept; you may remove them yourself if you want to.\n"
> @@ -3622,7 +3627,7 @@ msgid ""
> msgstr ""
> "Bitte geben Sie eine Versionsbeschreibung für Ihre Änderungen ein. Zeilen, "
> "die\n"
> -"mit '#' beginnen, werden beibehalten; wenn Sie möchten, können Sie diese "
> +"mit '%c' beginnen, werden beibehalten; wenn Sie möchten, können Sie diese "
> "entfernen.\n"
> "Eine leere Versionsbeschreibung bricht die Eintragung ab.\n"
>
> @@ -4403,9 +4408,8 @@ msgid "deepen history of shallow clone"
> msgstr "vertieft die Historie eines flachen Klon"
>
> #: builtin/fetch.c:86
> -#, fuzzy
> msgid "convert to a complete repository"
> -msgstr "um von einem lokalen Projektarchiv zu klonen"
> +msgstr "konvertiert zu einem vollständigen Projektarchiv"
>
> #: builtin/fetch.c:88 builtin/log.c:1119
> msgid "dir"
> @@ -4561,14 +4565,13 @@ msgid "You need to specify a tag name."
> msgstr "Sie müssen den Namen der Markierung angeben."
>
> #: builtin/fetch.c:981
> -#, fuzzy
> msgid "--depth and --unshallow cannot be used together"
> -msgstr "Die Optionen -x und -X können nicht gemeinsam verwendet werden."
> +msgstr "Die Optionen --depth und --unshallow können nicht gemeinsam verwendet werden."
>
> #: builtin/fetch.c:983
> -#, fuzzy
> msgid "--unshallow on a complete repository does not make sense"
> -msgstr "Die Option --name-only kann nicht verwendet werden."
> +msgstr "Die Option --unshallow kann nicht in einem vollständigen Projektarchiv "
> +"verwendet werden."
>
> #: builtin/fetch.c:1002
> msgid "fetch --all does not take a repository argument"
> @@ -6122,7 +6125,7 @@ msgstr ""
> "Zusammenführung abzuschließen.\n"
>
> #: builtin/merge.c:788
> -#, fuzzy, c-format
> +#, c-format
> msgid ""
> "Please enter a commit message to explain why this merge is necessary,\n"
> "especially if it merges an updated upstream into a topic branch.\n"
> @@ -6135,7 +6138,7 @@ msgstr ""
> "insbesondere wenn es einen aktualisierten, externen Zweig mit einem Thema-"
> "Zweig zusammenführt.\n"
> "\n"
> -"Zeilen beginnend mit '#' werden ignoriert, und eine leere Beschreibung "
> +"Zeilen beginnend mit '%c' werden ignoriert, und eine leere Beschreibung "
> "bricht die Eintragung ab.\n"
>
> #: builtin/merge.c:812
> @@ -6606,9 +6609,8 @@ msgid "unable to start 'show' for object '%s'"
> msgstr "konnte 'show' für Objekt '%s' nicht starten"
>
> #: builtin/notes.c:143
> -#, fuzzy
> msgid "could not read 'show' output"
> -msgstr "Konnte '%s' nicht lesen"
> +msgstr "Konnte Ausgabe von 'show' nicht lesen."
>
> #: builtin/notes.c:151
> #, c-format
> @@ -7213,7 +7215,6 @@ msgstr ""
> "für weitere Details."
>
> #: builtin/push.c:224
> -#, fuzzy
> msgid ""
> "Updates were rejected because the remote contains work that you do\n"
> "not have locally. This is usually caused by another repository pushing\n"
> @@ -7221,18 +7222,18 @@ msgid ""
> "'git pull') before pushing again.\n"
> "See the 'Note about fast-forwards' in 'git push --help' for details."
> msgstr ""
> -"Aktualisierungen wurden zurückgewiesen, weil die Spitze Ihres aktuellen\n"
> -"Zweiges hinter seinem externen Gegenstück zurückgefallen ist. Führen Sie\n"
> -"die externen Änderungen zusammen (z.B. 'git pull') bevor Sie erneut\n"
> -"versenden.\n"
> +"Aktualisierungen wurden zurückgewiesen, weil das Fernarchiv Versionen enthält,\n"
> +"die lokal nicht vorhanden sind. Das wird üblicherweise durch das Versenden von\n"
> +"Versionen auf dieselbe Referenz von einem anderen Projektarchiv aus verursacht.\n"
> +"Vielleicht müssen Sie die externen Änderungen zusammenzuführen (z.B. 'git pull')\n"
> +"bevor Sie erneut versenden.\n"
> "Siehe auch die Sektion 'Note about fast-forwards' in 'git push --help'\n"
> "für weitere Details."
>
> #: builtin/push.c:231
> -#, fuzzy
> msgid "Updates were rejected because the tag already exists in the remote."
> msgstr ""
> -"Aktualisierungen wurden zurückgewiesen, weil die Zielreferenz bereits\n"
> +"Aktualisierungen wurden zurückgewiesen, weil die Markierung bereits\n"
> "im Fernarchiv existiert."
>
> #: builtin/push.c:234
> @@ -7241,6 +7242,9 @@ msgid ""
> "or update a remote ref to make it point at a non-commit object,\n"
> "without using the '--force' option.\n"
> msgstr ""
> +"Sie können keine externe Referenz aktualisieren, die auf ein Objekt zeigt,\n"
> +"das keine Version ist, oder es auf ein solches Objekt zeigen lassen, ohne\n"
> +"die Option '--force' zu verwenden.\n"
>
> #: builtin/push.c:294
> #, c-format
> @@ -7351,9 +7355,8 @@ msgid "prune locally removed refs"
> msgstr "entfernt lokal gelöschte Referenzen"
>
> #: builtin/push.c:439
> -#, fuzzy
> msgid "bypass pre-push hook"
> -msgstr "umgeht \"pre-commit hook\""
> +msgstr "umgeht \"pre-push hook\""
>
> #: builtin/push.c:448
> msgid "--delete is incompatible with --all, --mirror and --tags"
> @@ -8536,20 +8539,18 @@ msgid "could not verify the tag '%s'"
> msgstr "Konnte Markierung '%s' nicht verifizieren"
>
> #: builtin/tag.c:249
> -#, fuzzy, c-format
> +#, c-format
> msgid ""
> "\n"
> "Write a tag message\n"
> "Lines starting with '%c' will be ignored.\n"
> msgstr ""
> "\n"
> -"#\n"
> -"# Geben Sie eine Markierungsbeschreibung ein.\n"
> -"# Zeilen, die mit '#' beginnen, werden ignoriert.\n"
> -"#\n"
> +"Geben Sie eine Markierungsbeschreibung ein.\n"
> +"Zeilen, die mit '%c' beginnen, werden ignoriert.\n"
>
> #: builtin/tag.c:253
> -#, fuzzy, c-format
> +#, c-format
> msgid ""
> "\n"
> "Write a tag message\n"
> @@ -8557,11 +8558,9 @@ msgid ""
> "want to.\n"
> msgstr ""
> "\n"
> -"#\n"
> -"# Geben Sie eine Markierungsbeschreibung ein.\n"
> -"# Zeilen, die mit '#' beginnen, werden behalten; Sie dürfen diese\n"
> -"# selbst entfernen wenn Sie möchten.\n"
> -"#\n"
> +"Geben Sie eine Markierungsbeschreibung ein.\n"
> +"Zeilen, die mit '%c' beginnen, werden behalten; Sie dürfen diese\n"
> +"selbst entfernen wenn Sie möchten.\n"
>
> #: builtin/tag.c:292
> msgid "unable to sign the tag"
> @@ -8942,7 +8941,6 @@ msgid "Print lines matching a pattern"
> msgstr "Stellt Zeilen dar, die einem Muster entsprechen"
>
> #: common-cmds.h:17
> -#, fuzzy
> msgid "Create an empty Git repository or reinitialize an existing one"
> msgstr ""
> "Erstellt ein leeres Git-Projektarchiv oder initialisiert ein bestehendes neu"
> @@ -9869,14 +9867,12 @@ msgid "blob"
> msgstr "Blob"
>
> #: git-submodule.sh:979
> -#, fuzzy
> msgid "Submodules changed but not updated:"
> -msgstr "# Unterprojekte geändert, aber nicht aktualisiert:"
> +msgstr "Unterprojekte geändert, aber nicht aktualisiert:"
>
> #: git-submodule.sh:981
> -#, fuzzy
> msgid "Submodule changes to be committed:"
> -msgstr "# Änderungen in Unterprojekt zum Eintragen:"
> +msgstr "Änderungen in Unterprojekt zum Eintragen:"
>
> #: git-submodule.sh:1129
> #, sh-format
>
^ permalink raw reply
* Re: Git Merge 2013 Conference, Berlin
From: Michael J Gruber @ 2013-02-19 15:20 UTC (permalink / raw)
To: Scott Chacon; +Cc: Jeff King, Thomas Rast, git list
In-Reply-To: <CAP2yMaKwdwBiE0q6Cqmjf-g3iV269+UvOS+DaKtaXNOfQLkpeg@mail.gmail.com>
Scott Chacon venit, vidit, dixit 18.02.2013 22:29:
> Right now we have:
>
> Dev day: 50
> User day: 295
> Hack day: 200
>
> I'm not sure what the actual turnout will be, but it looks like it's
> going to be pretty massive. I wanted to go through the Dev day
> signups and figure out if everyone really belongs there (is an actual
> contributor to a core git project) but it's basically on the honor
> system now.
>
> If anyone on this list that should be there (Junio, Shawn, etc) wants
> to attend and would like sponsorship for the flight/lodging, please
> let me know. We would love to have as many of the core people there
> as possible. I will also try to record everything and summarize as
> much as I can after the fact, so if you can't attend it should still
> be possible to get the general idea of what occurred and was
> discussed.
>
> I'm going to try doing something similar in the SF area in maybe 6-8
> months from this, assuming it's a success.
>
> Scott
>
> On Mon, Feb 18, 2013 at 1:17 PM, Jeff King <peff@peff.net> wrote:
>> On Mon, Feb 18, 2013 at 09:52:34PM +0100, Thomas Rast wrote:
>>
>>> Scott Chacon <schacon@gmail.com> writes:
>>>
>>>> We're starting off in Berlin, May 9-11th. GitHub has secured
>>>> conference space at the Radisson Blu Berlin for those days. I have a
>>>> smaller room for the first day so we can get 30-40 Git implementors
>>>> together to talk about the future of Git and whatnot.
>>> [...]
>>>> http://git-merge.com/
>>>
>>> So this has been fairly quiet -- is anyone else coming? :-)
>>
>> I am. I think Scott may have actual numbers, but my third-hand
>> impression was that there have been a lot of signups.
>>
>> -Peff
Well, all days are listed as "sold out" on the eventbrite site. Maybe
it's because eventbrite has "trouble connecting to facebook" because I
"don't have facebook"?
I do plan to come (unless I'm out due to lack of an eventbrite ticket)
but will stay with family rather than at the Radisson Blu.
Michael
^ permalink raw reply
* Re: Proposal: sharing .git/config
From: Jeff King @ 2013-02-19 15:36 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Ramkumar Ramachandra, Git List
In-Reply-To: <CACsJy8Ch70gZMkT7ScY3R-FNQU4QjtUe8UhoGRzE27cH9mu0HA@mail.gmail.com>
On Tue, Feb 19, 2013 at 05:34:43PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra
> <artagnon@gmail.com> wrote:
> > Hi,
> >
> > I have this itch where I want to share my remotes config between
> > machines. In my fork, I should be able to specify where my upstream
> > sources are, so remotes get set up automatically when I clone. There
> > are also other things in .git/config that would be nice to share, like
> > whether to do a --word-diff (why isn't it a configuration variable
> > yet?) on the repository. The only problem is that I have no clue how
> > to implement this: I'm currently thinking a special remote ref?
>
> If you check out the config file, then include.path should work. You
> could add include.ref to point to a ref, but you need to deal with the
> attached security implications. This has been proposed before (and
> turned down, I think).
Here's the patch:
http://article.gmane.org/gmane.comp.version-control.git/189144
The basic argument against it is that you would _not_ want to do:
$ git config include.ref origin/config
because it's unsafe (you immediately start using config fetched from the
remote, before you even get a chance to inspect it). So the recommended
way to use it is:
$ git config include.ref config
$ git show origin/config ;# make sure it looks reasonable
$ git update-ref refs/config origin/config
[time passes...]
$ git fetch
$ git diff config origin/config ;# inspect changes
$ git update-ref refs/config origin/config
But it was pointed out that you could also just do:
$ git config include.ref upstream-config
$ git show origin/config ;# make sure it looks reasonable
$ git show origin/config >.git/upstream-config
and so forth. There are some ways that a pure ref can be more
convenient (e.g., if you are carrying local changes on top of the
upstream config and want to merge), but ultimately, you can replicate
any include.ref workflow with include.path by adding a "deploy" step
where you copy the file into $GIT_DIR.
-Peff
^ 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