Re: [PATCH 1/2] require pathspec for "git add -u/-A"
Matthieu Moy writes: > Junio C Hamano writes: > >> As promised in 0fa2eb530fb7 (add: warn when -u or -A is used without >> pathspec, 2013-01-28), "git add -u/-A" that is run without pathspec >> in a subdirectory will stop working sometime before Git 2.0, to wean >> users off of the old default, in preparation for adopting the new >> default in Git 2.0. > > I originally thought this step was necessary, but I changed my mind. The > warning is big enough and doesn't need to be turned into an error. I tend to agree. The plan requires the warning to be big enough and warning period to be long enough so that by the time Git 2.0 is released, no existing users will run "git add -u/-A" without pathspec expecting it to limit the operation to the current directory, so an extra step to error out such a command invocation is simply redundant. If it is not redundant, that would only mean that the warning period was not long enough. The only effect the extra "error it out" step would have is to hurt the people who jump on Git bandwagon after such release ships, as they do not have any reason to retrain their fingers---they instead can just get used to the new behaviour right away. So let's squash these two steps into one and keep that in 'next' until 2.0 ships. Thanks for an injection of sanity. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] require pathspec for "git add -u/-A"
Junio C Hamano writes: > So let's squash these two steps into one and keep that in 'next' > until 2.0 ships. OK, then we may update the comment describing the plan (for people digging in the code to find out what the plan is). Small patch serie follows with this (will probably give conflict with your patch, feel free to drop if resolving them is too painful given the benefit) and another minor improvement. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] add: update pathless 'add [-u|-A]' warning to reflect change of plan
We originally thought the transition would need a period where "git add
[-u|-A]" without pathspec would be forbidden, but the warning is big
enough to scare people and teach them not to use it (or, if so, to
understand the consequences).
Signed-off-by: Matthieu Moy
---
builtin/add.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/add.c b/builtin/add.c
index 0dd014e..ab1c9e8 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -328,9 +328,9 @@ static void warn_pathless_add(const char *option_name,
const char *short_name) {
* this is not the original behavior and can't be
* changed until users trained themselves not to type
* "git add -u" or "git add -A". For now, we warn and
-* keep the old behavior. Later, this warning can be
-* turned into a die(...), and eventually we may
-* reallow the command with a new behavior.
+* keep the old behavior. Later, the behavior can be changed
+* to tree-wide, keeping the warning for a while, and
+* eventually we can drop the warning.
*/
warning(_("The behavior of 'git add %s (or %s)' with no path argument
from a\n"
"subdirectory of the tree will change in Git 2.0 and should
not be used anymore.\n"
--
1.8.2.rc3.16.g0a33571.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] add: add a newline at the end of pathless 'add [-u|-A]' warning
When the commands give an actual output (e.g. when ran with -v), the
output is visually mixed with the warning. The newline makes the actual
output more visible.
Signed-off-by: Matthieu Moy
---
builtin/add.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/add.c b/builtin/add.c
index ab1c9e8..620bf00 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -344,7 +344,7 @@ static void warn_pathless_add(const char *option_name,
const char *short_name) {
" git add %s .\n"
" (or git add %s .)\n"
"\n"
- "With the current Git version, the command is restricted to
the current directory."),
+ "With the current Git version, the command is restricted to
the current directory.\n"),
option_name, short_name,
option_name, short_name,
option_name, short_name);
--
1.8.2.rc3.16.g0a33571.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Make help behaviour more consistent
Kevin Bracey writes: > Two significant usability flaws here: > - If using man, "man git" to side-step "git help" is obvious. But if >trying to use help.format=web, how to get the root html page? My >technique was "git help XXX" and click the "git(1) suite" link at the >bottom. "git help git" is non-obvious and apparently undocumented >(it's not mentioned by "git", "git help", or "git help help"...). Can't this be solved by adding something like See 'git help git' for general help about Git. to the output of "git help"? I think the fact that "git help" provides a small amount of output (typically: fits on one screen) is a nice feature that avoids scaring people too early with the actual doc. That said, I'm no longer a user of the short command list, so maybe I'm not a good judge ;-). > Option list shown in command-line usage re-ordered to match the manual > page, and git and git-help manual pages edited to reflect the new help > behaviour. This is typically better submitted as a separate patch. Putting uncontroversial changes in their own patches help the discussion to focus on important changes, and avoids distracting the review. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Textconv
Hello! Most of GUI for Git using 'git show' command to show differences between versions. For example: WebStorm IDE. But for now there is no way to specify text conversion command in git config for 'show' as it done for 'diff'. It makes problems when we dealing with encrypted repositories. Is there any alternative way to configure git repository? Or if it impossible will you implement such kind of feature? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Textconv
Dmitry Ilin writes: > Hello! > > Most of GUI for Git using 'git show' command to show differences > between versions. For example: WebStorm IDE. But for now there is no > way to specify text conversion command in git config for 'show' as it > done for 'diff'. Do you mean, to enable it, or to disable it? By default, "git show" does use the textconv filter to compute the diff, at least if you specified the textconv driver in your .gitattributes file. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Textconv
I mean that our filter doesn't work with 'git show' and I need to enable it for this command. This is part of my git config file: [filter "openssl"] smudge = openssl enc -d -base64 -aes-256-ecb -k 'abcde' 2> /dev/null || cat clean = openssl enc -base64 -aes-256-ecb -S '12345' -k 'abcde' [diff "openssl"] textconv = openssl enc -d -base64 -aes-256-ecb -k 'abcde' -in "$1" 2> /dev/null || cat "$1" [merge] renormalize = true And content of '.git/info/attributes': * filter=openssl diff=openssl How can I deal with it? On 03/11/2013 02:00 PM, Matthieu Moy wrote: Dmitry Ilin writes: Hello! Most of GUI for Git using 'git show' command to show differences between versions. For example: WebStorm IDE. But for now there is no way to specify text conversion command in git config for 'show' as it done for 'diff'. Do you mean, to enable it, or to disable it? By default, "git show" does use the textconv filter to compute the diff, at least if you specified the textconv driver in your .gitattributes file. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Textconv
Dmitry Ilin writes: > I mean that our filter doesn't work with 'git show' and I need to > enable it for this command. > > This is part of my git config file: > > [filter "openssl"] >smudge = openssl enc -d -base64 -aes-256-ecb -k 'abcde' 2> > /dev/null || cat >clean = openssl enc -base64 -aes-256-ecb -S '12345' -k 'abcde' > [diff "openssl"] >textconv = openssl enc -d -base64 -aes-256-ecb -k 'abcde' -in "$1" > 2> /dev/null || cat "$1" > [merge] >renormalize = true Maybe a bad interaction between the [filter ...] section and the [textconv ...] one. Can you run: GIT_TRACE=true git show to see what's going on? -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Textconv
I tried this command and I got following result: trace: built-in: git 'show' 'a1bffde' trace: run_command: 'openssl enc -d -base64 -aes-256-ecb -k '\''abcde'\'' 2> /dev/null || cat' trace: exec: 'sh' '-c' 'openssl enc -d -base64 -aes-256-ecb -k '\''abcde'\'' 2> /dev/null || cat' 'openssl enc -d -base64 -aes-256-ecb -k '\''abcde'\'' 2> /dev/null || cat' trace: run_command: 'openssl enc -d -base64 -aes-256-ecb -k '\''abcde'\'' -in $1 2> /dev/null || cat $1' '/tmp/CLPGPk_config.js' trace: exec: 'sh' '-c' 'openssl enc -d -base64 -aes-256-ecb -k '\''abcde'\'' -in $1 2> /dev/null || cat $1 "$@"' 'openssl enc -d -base64 -aes-256-ecb -k '\''abcde'\'' -in $1 2> /dev/null || cat $1' '/tmp/CLPGPk_config.js' trace: run_command: 'openssl enc -d -base64 -aes-256-ecb -k '\''abcde'\'' 2> /dev/null || cat' trace: exec: 'sh' '-c' 'openssl enc -d -base64 -aes-256-ecb -k '\''abcde'\'' 2> /dev/null || cat' 'openssl enc -d -base64 -aes-256-ecb -k '\''abcde'\'' 2> /dev/null || cat' trace: run_command: 'openssl enc -d -base64 -aes-256-ecb -k '\''abcde'\'' -in $1 2> /dev/null || cat $1' '/tmp/Uyc2Dj_config.js' trace: exec: 'sh' '-c' 'openssl enc -d -base64 -aes-256-ecb -k '\''abcde'\'' -in $1 2> /dev/null || cat $1 "$@"' 'openssl enc -d -base64 -aes-256-ecb -k '\''abcde'\'' -in $1 2> /dev/null || cat $1' '/tmp/Uyc2Dj_config.js' diff --git a/path/config.js b/path/config.js index c4ad2d4..a67d13f 100644 --- a/path/config.js +++ b/path/config.js And also not encrypted data of my commit. On 03/11/2013 02:41 PM, Matthieu Moy wrote: Dmitry Ilin writes: I mean that our filter doesn't work with 'git show' and I need to enable it for this command. This is part of my git config file: [filter "openssl"] smudge = openssl enc -d -base64 -aes-256-ecb -k 'abcde' 2> /dev/null || cat clean = openssl enc -base64 -aes-256-ecb -S '12345' -k 'abcde' [diff "openssl"] textconv = openssl enc -d -base64 -aes-256-ecb -k 'abcde' -in "$1" 2> /dev/null || cat "$1" [merge] renormalize = true Maybe a bad interaction between the [filter ...] section and the [textconv ...] one. Can you run: GIT_TRACE=true git show to see what's going on? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 05/23] contrib/subtree: Add commands pull_all and push_all
On Mon, Mar 11, 2013 at 5:03 AM, Junio C Hamano wrote:
> Paul Campbell writes:
>
>> From: bibendi
>>
>> For each subtree listed in .gittrees perform a push or a pull.
>>
>> Signed-off-by: Paul Campbell
>>
>> Conflicts:
>> contrib/subtree/git-subtree.sh
>
> The "Conflicts:" part is totally irrelevant. Please remove.
>
>> ---
>> contrib/subtree/git-subtree.sh | 25 ++---
>> 1 file changed, 22 insertions(+), 3 deletions(-)
>>
>> diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
>> index 1aff956..ddae56e 100755
>> --- a/contrib/subtree/git-subtree.sh
>> +++ b/contrib/subtree/git-subtree.sh
>> @@ -12,6 +12,7 @@ git subtree add --prefix=
>> git subtree add --prefix=
>> git subtree merge --prefix=
>> git subtree pull --prefix=
>> +git subtree pull_all
>
> Why isn't it "pull --all"?
>
>> git subtree push --prefix=
>
> Where did "push_all" go?
>
>> +cmd_pull_all()
>> +{
>> +git config -f .gittrees -l | grep subtree | grep path | grep -o '=.*' |
>> grep -o '[^=].*' |
>
> "grep -o" is not even in POSIX. Besides, what is this trying to
> parse? Is it expected to match lines like
>
> path.subtree=trash
>
> with this, or is it more like you only want something like this:
>
> subtree.over/there.path=foo
>
> in which case you would want to read with something like
>
> sed -n -e 's/^subtree\...*\.path=\(.*\)/\1/p'
>
> instead (modulo the usual caveat on $IFS whitespaces in path)?
>
>> +while read path; do
>> +git subtree pull -P $path master || exit $?
>> +done
>> +}
>
> I'd stop looking at this series myself at this step for now.
Thanks for your feedback. Plenty there for me already to get cracking on.
--
Paul [W] Campbell
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Rewriting references to existing commits in commit messages with filter-branch
Hello, I'm in the process of converting an existing svn repository to git. The first step was a standard "git svn clone" that went successfully (after taking 15 hours to complete). However I don't want to stop there and would like massage the repository a little before making it publicly available. The first thing I'd like to do is to replace all references to subversion revision numbers in the commit messages with the corresponding git commit SHA1s. I've written a small message filter script called "svnmsg2git" that searches for all occurrences of r12345, runs "git svn find-rev r12345" and then -- and this is the important part -- looks up the new commit id corresponding to this under .git-rewrite/map. This seemed to work well in limited testing I did initially but after running git filter-branch --msg-filter svnmsg2git --tag-name-filter cat -- --all on all ~50k revisions, I have a couple of dozens of errors which happen because the file .git-rewrite/map/$commit doesn't exist yet when I'm trying to look it up. Does anybody know of a way to fix this? This happens apparently because filter-branch doesn't process the commits in their svn order, and when one of them is on a branch while the other one is on the trunk, it can happen that the commit references a previous svn revision is processed before the commit corresponding to this revision itself. At least this is the only explanation I see. But even if my hypothesis is correct, I still have no idea about how to force filter-branch to do things in the "right" order. Thanks in advance for any ideas! VZ pgpUwEHVKRUuG.pgp Description: PGP signature
Re: Rewriting references to existing commits in commit messages with filter-branch
Vadim Zeitlin wrote: [...] > git filter-branch --msg-filter svnmsg2git --tag-name-filter cat -- --all git rev-list lists by default in chronological order. Do you want to pass --topo-order as one of the rev-list options? [...] Lawrence -- Lawrence Mitchell -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
The function-wide redirection used for __git_ls_files_helper and
__git_diff_index_helper work only with bash. Using ZSH, trying to
complete an inexistant directory gave this:
git add no-such-dir/__git_ls_files_helper:cd:2: no such file or directory:
no-such-dir/
Signed-off-by: Matthieu Moy
---
These two instances seem to be the only ones in the file.
I'm not sure whether the 2>/dev/null would be needed for the command
on the RHS of the && too (git ls-files and git diff-index).
contrib/completion/git-completion.bash | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index b62bec0..0640274 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -300,8 +300,8 @@ __git_index_file_list_filter ()
__git_ls_files_helper ()
{
# NOTE: $2 is not quoted in order to support multiple options
- cd "$1" && git ls-files --exclude-standard $2
-} 2>/dev/null
+ cd "$1" 2>/dev/null && git ls-files --exclude-standard $2
+}
# Execute git diff-index, returning paths relative to the directory
@@ -309,8 +309,8 @@ __git_ls_files_helper ()
# specified in the second argument.
__git_diff_index_helper ()
{
- cd "$1" && git diff-index --name-only --relative "$2"
-} 2>/dev/null
+ cd "$1" 2>/dev/null && git diff-index --name-only --relative "$2"
+}
# __git_index_files accepts 1 or 2 arguments:
# 1: Options to pass to ls-files (required).
--
1.8.2.rc3.16.g0a33571.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Rewriting references to existing commits in commit messages with filter-branch
Lawrence Mitchell gmx.li> writes: > Vadim Zeitlin wrote: > > [...] > > > git filter-branch --msg-filter svnmsg2git --tag-name-filter cat -- --all > > git rev-list lists by default in chronological order. Do you > want to pass --topo-order as one of the rev-list options? Thanks, this looked like a good idea but reading git-filter-branch code it seems to already do it, at https://github.com/git/git/blob/master/git-filter-branch.sh#L269 you can see that it does "git rev-list --reverse --topo-order ...". So this probably won't help (I could try it just in case I'm missing something but the first errors appear after almost 2 hours of running...). Notice that I could well be wrong in my explanation of what happens, perhaps it's not related to the order of processing of the branches/trunk at all. All I know is that when a chronologically later commit referring to preceding one on a different branch is processed by git-filter-branch, sometimes (or perhaps even always) the file corresponding to the previous commit is not yet present in .git-rewrite/map directory. Thanks again for any help with this, VZ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ZSH segmentation fault while completing "git mv dir/"
Hi, Since the recent update to bash completion, I often get a segmentation fault from ZSH. This is most likely a bug in ZSH, but it would be cool to avoid triggering it from Git. Steps to reproduce: moy@anie:/tmp$$ git init zsh Initialized empty Git repository in /tmp/zsh/.git/ moy@anie:/tmp$$ cd zsh/ moy@anie:/tmp/zsh$$ mkdir foo moy@anie:/tmp/zsh$$ touch foo/bar.txt moy@anie:/tmp/zsh$$ git mv foo/zsh: segmentation fault zsh moy@anie:~$ zsh --version zsh 4.3.10 (i686-pc-linux-gnu) (this is ZSH packaged with Debian stable) Any ZSH guru to look into it? Thanks, -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Rewriting references to existing commits in commit messages with filter-branch
Vadim Zeitlin writes:
> Lawrence Mitchell gmx.li> writes:
>
>> Vadim Zeitlin wrote:
>>
>> [...]
>>
>> > git filter-branch --msg-filter svnmsg2git --tag-name-filter cat -- --all
>>
>> git rev-list lists by default in chronological order. Do you
>> want to pass --topo-order as one of the rev-list options?
>
> Thanks, this looked like a good idea but reading git-filter-branch code it
> seems to already do it, at
> https://github.com/git/git/blob/master/git-filter-branch.sh#L269 you can see
> that it does "git rev-list --reverse --topo-order ...".
Try overring that with --date-order (you may have to patch the source).
--topo-order doesn't order by dates. --date-order does somewhat
(respecting topology), which in the absence of clock skew should do what
you are looking for.
Note that you cannot *remove* --topo-order and use the default, which is
to only respect dates and not topology; that would break filter-branch.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Rewriting references to existing commits in commit messages with filter-branch
On 03/11/2013 12:45 PM, Vadim Zeitlin wrote: > [...] > The first thing I'd like to do is to replace all references to subversion > revision numbers in the commit messages with the corresponding git commit > SHA1s. [...] I have a couple of dozens of errors which happen > because the file .git-rewrite/map/$commit doesn't exist yet when I'm trying > to look it up. The quick and dirty solution would be to rewrite your script such that if the commit is still unknown to Git, it emits a warning and leaves the commit message unchanged (i.e., leaves the Subversion revision number untouched). Then simply run the filter-branch a few times until it emits no warnings. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Rewriting references to existing commits in commit messages with filter-branch
Michael Haggerty alum.mit.edu> writes: > > On 03/11/2013 12:45 PM, Vadim Zeitlin wrote: > > [...] > > The first thing I'd like to do is to replace all references to subversion > > revision numbers in the commit messages with the corresponding git commit > > SHA1s. [...] I have a couple of dozens of errors which happen > > because the file .git-rewrite/map/$commit doesn't exist yet when I'm trying > > to look it up. > > The quick and dirty solution would be to rewrite your script such that > if the commit is still unknown to Git, it emits a warning and leaves the > commit message unchanged (i.e., leaves the Subversion revision number > untouched). Then simply run the filter-branch a few times until it > emits no warnings. Thanks, I did think about this but the trouble is that after the first rewrite "git svn find-rev" wouldn't work any more, so I'd have to do the substitutions manually. Which might be doable as there are not that many of them but, if possible, I'd rather do it automatically. FWIW I'm playing with --date-order now (thanks Thomas) but somehow it seems to create other problems while fixing (some of) the existing ones. I need to look at this more closely to understand what's going on here... VZ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Textconv
Dmitry Ilin venit, vidit, dixit 11.03.2013 12:30: > I tried this command and I got following result: > > trace: built-in: git 'show' 'a1bffde' > trace: run_command: 'openssl enc -d -base64 -aes-256-ecb -k > '\''abcde'\'' 2> /dev/null || cat' > trace: exec: 'sh' '-c' 'openssl enc -d -base64 -aes-256-ecb -k > '\''abcde'\'' 2> /dev/null || cat' 'openssl enc -d -base64 -aes-256-ecb > -k '\''abcde'\'' 2> /dev/null || cat' > trace: run_command: 'openssl enc -d -base64 -aes-256-ecb -k > '\''abcde'\'' -in $1 2> /dev/null || cat $1' '/tmp/CLPGPk_config.js' > trace: exec: 'sh' '-c' 'openssl enc -d -base64 -aes-256-ecb -k > '\''abcde'\'' -in $1 2> /dev/null || cat $1 "$@"' 'openssl enc -d > -base64 -aes-256-ecb -k '\''abcde'\'' -in $1 2> /dev/null || cat $1' > '/tmp/CLPGPk_config.js' > trace: run_command: 'openssl enc -d -base64 -aes-256-ecb -k > '\''abcde'\'' 2> /dev/null || cat' > trace: exec: 'sh' '-c' 'openssl enc -d -base64 -aes-256-ecb -k > '\''abcde'\'' 2> /dev/null || cat' 'openssl enc -d -base64 -aes-256-ecb > -k '\''abcde'\'' 2> /dev/null || cat' > trace: run_command: 'openssl enc -d -base64 -aes-256-ecb -k > '\''abcde'\'' -in $1 2> /dev/null || cat $1' '/tmp/Uyc2Dj_config.js' > trace: exec: 'sh' '-c' 'openssl enc -d -base64 -aes-256-ecb -k > '\''abcde'\'' -in $1 2> /dev/null || cat $1 "$@"' 'openssl enc -d > -base64 -aes-256-ecb -k '\''abcde'\'' -in $1 2> /dev/null || cat $1' > '/tmp/Uyc2Dj_config.js' > diff --git a/path/config.js b/path/config.js > index c4ad2d4..a67d13f 100644 > --- a/path/config.js > +++ b/path/config.js > > > And also not encrypted data of my commit. > > > On 03/11/2013 02:41 PM, Matthieu Moy wrote: >> Dmitry Ilin writes: >> >>> I mean that our filter doesn't work with 'git show' and I need to >>> enable it for this command. >>> >>> This is part of my git config file: >>> >>> [filter "openssl"] >>> smudge = openssl enc -d -base64 -aes-256-ecb -k 'abcde' 2> >>> /dev/null || cat >>> clean = openssl enc -base64 -aes-256-ecb -S '12345' -k 'abcde' >>> [diff "openssl"] >>> textconv = openssl enc -d -base64 -aes-256-ecb -k 'abcde' -in "$1" >>> 2> /dev/null || cat "$1" >>> [merge] >>> renormalize = true >> Maybe a bad interaction between the [filter ...] section and the >> [textconv ...] one. Can you run: >> >> GIT_TRACE=true git show >> >> to see what's going on? >> > "git show commit" uses textconv by default for the patch, but "git show blob" does not. There's a series on the list which deals with textconv for "grep" and "show blob", but I haven't had the time to polish it up. I don't think it's cooking in pu yet, but I've been running with it since. "running git with it", that is, not "running away with it" ;) Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Exclude optimizations
The hunt continues.. (and thanks everyone for suggestions). Now is_excluded() (and exclude machinery) is no longer the hot spot in read_directory. index_name_exists is the new star: function time (in seconds) treat_leading_path: 0.000 read_directory: 0.289 +treat_one_path: 0.147 ++is_excluded:0.013 +++prep_exclude: 0.006 +++matching: 0.004 ++dir_exists_in_index:0.008 ++index_name_exists: 0.117 <-- +++lazy_init_name_hash: 0.060 +simplify_away: 0.004 +dir_add_name:0.000 real0m0.372s user0m0.256s sys 0m0.114s <-- can't kill this one (*) until we get inotify support I think if we save the hash in index, we could nearly cut lazy_init_name_hash out (or not, perf reported insert_hash near the top, not hash_name). Any ideas to further reduce iname_name_exists cost are welcome. 0.117s on 2.50GHz turns to 0.549s on my Atom 1.6GHz, so I think it's worth doing something about it. (*) I tried breadth-first search, checking for .gitignore existence before opening, chdir() to shorten pathnames. Nothing worked. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ZSH segmentation fault while completing "git mv dir/"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 11/03/2013 13:30, Matthieu Moy ha scritto: > Hi, > > Since the recent update to bash completion, I often get a segmentation > fault from ZSH. This is most likely a bug in ZSH, but it would be cool > to avoid triggering it from Git. > > [...] > moy@anie:~$ zsh --version > zsh 4.3.10 (i686-pc-linux-gnu) > > (this is ZSH packaged with Debian stable) > I have the same system, but I can't reproduce the problem. What is the content of your .zshrc file? Regards Manlio Perillo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlE99NAACgkQscQJ24LbaURIwgCbB9HmepRfvTqN2vh6H5/Ew7Mw WQMAn3CSiFViQ7j62fuBVKg6WJK+Yg/0 =j4FV -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ZSH segmentation fault while completing "git mv dir/"
Manlio Perillo writes:
> I have the same system, but I can't reproduce the problem.
> What is the content of your .zshrc file?
I could reproduce with ~/.zshrc containing just:
--
fpath=(${HOME}/usr/etc/zsh ${fpath})
autoload -Uz compinit
compinit
eval "`dircolors`"
zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS}
--
${HOME}/usr/etc/zsh contains two links _git and git-completion.bash
pointing to Git's completion scripts in contrib/.
Removing any line aboves removes the segmentation fault.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Rewriting references to existing commits in commit messages with filter-branch
Thomas Rast student.ethz.ch> writes: > > Vadim Zeitlin zeitlins.org> writes: > > > Lawrence Mitchell gmx.li> writes: > > > >> Vadim Zeitlin wrote: > >> > >> [...] > >> > >> > git filter-branch --msg-filter svnmsg2git --tag-name-filter cat -- --all > >> > >> git rev-list lists by default in chronological order. Do you > >> want to pass --topo-order as one of the rev-list options? > > > > Thanks, this looked like a good idea but reading git-filter-branch code it > > seems to already do it, at > > https://github.com/git/git/blob/master/git-filter-branch.sh#L269 you can see > > that it does "git rev-list --reverse --topo-order ...". > > Try overring that with --date-order (you may have to patch the source). Thanks for the hint, this was indeed the solution. And there is actually no need to patch the source because, considering the way git-filter-branch.sh is written, the user-specified parameters come after the hard-coded --topo-order and it seems that --date-order overrides it if it comes after it. So I just had to use git filter-branch --msg-filter svnmsg2git --tag-name-filter cat -- --date-order --all instead of my original command. The only remaining question I have is why isn't --date-order the default? At least when using message filter, it seems to me that we always want to rewrite commits in chronological order to deal with possible back references (even when not migrating from svn, commit messages can still refer to previous commits, like e.g. the ones created by "git revert" do and they need to be updated when rewriting history). So why not use it in git-filter-branch.sh? BTW, the explanation for the new errors I was getting with --date-order was that I had some artificial commits generated by cvs2svn in the history of this repository which had _exactly_ the same date as the previous commit and --date-order sorted them in the wrong order for some reason. I got round this by simply checking for the specific form of the message (which is "This commit was generated by cvs2svn to compensate for changes in rN, which included commits to RCS files with non-trunk default branches.") and replacing "rN" with "the previous commit" in this particular case in order to avoid the problem. Thanks again for your help! VZ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] add: add a newline at the end of pathless 'add [-u|-A]' warning
Matthieu Moy writes:
> When the commands give an actual output (e.g. when ran with -v), the
> output is visually mixed with the warning. The newline makes the actual
> output more visible.
>
> Signed-off-by: Matthieu Moy
> ---
It would have been easier to immediately understand what is going on
if you said "blank line" instead of "newline" ;-)
An obvious issues is what if user does not run with "-v" or if "-v"
produces no results. We will be left with an extra blank line at
the end.
I suspect that the true reason why the warning does not stand out
and other output looks mixed in it may be because we only prefix the
first line with the "warning: " label. In the longer term, I have a
feeling that we should be showing something like this instead:
$ cd t && echo >>t*.sh && git add -u -v
warning: The behavior of 'git add --update (or -u)' with no path ar...
warning: subdirectory of the tree will change in Git 2.0 and should...
warning: To add content for the whole tree, run:
warning:
warning: git add --update :/
warning: (or git add -u :/)
warning:
warning: To restrict the command to the current directory, run:
warning:
warning: git add --update .
warning: (or git add -u .)
warning:
warning: With the current Git version, the command is restricted to...
add 't/t-basic.sh'
using a logic similar to what strbuf_add_commented_lines() and
strbuf_add_lines() use.
> builtin/add.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/add.c b/builtin/add.c
> index ab1c9e8..620bf00 100644
> --- a/builtin/add.c
> +++ b/builtin/add.c
> @@ -344,7 +344,7 @@ static void warn_pathless_add(const char *option_name,
> const char *short_name) {
> " git add %s .\n"
> " (or git add %s .)\n"
> "\n"
> - "With the current Git version, the command is restricted to
> the current directory."),
> + "With the current Git version, the command is restricted to
> the current directory.\n"),
> option_name, short_name,
> option_name, short_name,
> option_name, short_name);
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
Matthieu Moy writes:
> The function-wide redirection used for __git_ls_files_helper and
> __git_diff_index_helper work only with bash. Using ZSH, trying to
> complete an inexistant directory gave this:
>
> git add no-such-dir/__git_ls_files_helper:cd:2: no such file or directory:
> no-such-dir/
>
> Signed-off-by: Matthieu Moy
> ---
This is not bash-ism but POSIX.1, even though it is not very well
known. I recall commenting on this exact pattern during the review.
http://thread.gmane.org/gmane.comp.version-control.git/213232/focus=213286
After all, I was right when I said that some implementations may get
it wrong and we shouldn't use the construct X-<.
> These two instances seem to be the only ones in the file.
>
> I'm not sure whether the 2>/dev/null would be needed for the command
> on the RHS of the && too (git ls-files and git diff-index).
It would not hurt to discard their standard error.
> contrib/completion/git-completion.bash | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index b62bec0..0640274 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -300,8 +300,8 @@ __git_index_file_list_filter ()
> __git_ls_files_helper ()
> {
> # NOTE: $2 is not quoted in order to support multiple options
> - cd "$1" && git ls-files --exclude-standard $2
> -} 2>/dev/null
> + cd "$1" 2>/dev/null && git ls-files --exclude-standard $2
> +}
>
>
> # Execute git diff-index, returning paths relative to the directory
> @@ -309,8 +309,8 @@ __git_ls_files_helper ()
> # specified in the second argument.
> __git_diff_index_helper ()
> {
> - cd "$1" && git diff-index --name-only --relative "$2"
> -} 2>/dev/null
> + cd "$1" 2>/dev/null && git diff-index --name-only --relative "$2"
> +}
>
> # __git_index_files accepts 1 or 2 arguments:
> # 1: Options to pass to ls-files (required).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A bug or unhandled case
Michał Janiszewski writes: > Hi, > I think I've found a bug in git or at least a use case that is not handled. > In few words it can be described like this: if you push a remote > branch to another remote, which is bare repository, you cannot remove > that branch from said bare repository. > Here is a recipe how to reproduce that with git 1.8.0: > git init foo > git init --bare bar.git > git init --bare baz.git > cd foo > echo test > file > git commit -am "initial commit" Nothing added, nothing committed, at this point. I'd assume there is "git add file" before this commit. > git remote add bar ../bar.git > git remote add baz ../baz.git > git push bar master > cd .. > git clone bar.git bax > cd bax > git checkout -b "test_branch" > echo evil > file > git commit -am "evil commit" > git push origin test-branch error: src refspec test-branch does not match any. error: failed to push some refs to './bar.git' I'd assume that is test_branch > cd ../foo > git fetch bar > git push baz bar/test_branch > cd ../baz.git > > ### > # on that point in baz.git there is only one branch: Correct. > # remotes/bar/test_branch 8b96ffe evil commit > # trying to remove that branch yields no results: > $ git branch -D refs/remotes/bar/test_branch That is not the way to remove the remote tracking branch test_branch you have from remote bar, is it? git branch -r -D bar/test_branch -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A bug or unhandled case
Hmm, indeed it works. Sorry for the confusion then (and a bit mistaken commands, but you got them correct). I wasn't aware of the -r option. On Mon, Mar 11, 2013 at 5:29 PM, Junio C Hamano wrote: > Michał Janiszewski writes: > >> Hi, >> I think I've found a bug in git or at least a use case that is not handled. >> In few words it can be described like this: if you push a remote >> branch to another remote, which is bare repository, you cannot remove >> that branch from said bare repository. >> Here is a recipe how to reproduce that with git 1.8.0: >> git init foo >> git init --bare bar.git >> git init --bare baz.git >> cd foo >> echo test > file >> git commit -am "initial commit" > > Nothing added, nothing committed, at this point. > I'd assume there is "git add file" before this commit. > >> git remote add bar ../bar.git >> git remote add baz ../baz.git >> git push bar master >> cd .. >> git clone bar.git bax >> cd bax >> git checkout -b "test_branch" >> echo evil > file >> git commit -am "evil commit" >> git push origin test-branch > > error: src refspec test-branch does not match any. > error: failed to push some refs to './bar.git' > > I'd assume that is test_branch > >> cd ../foo >> git fetch bar >> git push baz bar/test_branch >> cd ../baz.git >> >> ### >> # on that point in baz.git there is only one branch: > > Correct. > >> # remotes/bar/test_branch 8b96ffe evil commit >> # trying to remove that branch yields no results: >> $ git branch -D refs/remotes/bar/test_branch > > That is not the way to remove the remote tracking branch test_branch > you have from remote bar, is it? > > git branch -r -D bar/test_branch > -- Michal Janiszewski -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
Junio C Hamano writes:
> After all, I was right when I said that some implementations may get
> it wrong and we shouldn't use the construct X-<.
>
>> These two instances seem to be the only ones in the file.
>>
>> I'm not sure whether the 2>/dev/null would be needed for the command
>> on the RHS of the && too (git ls-files and git diff-index).
>
> It would not hurt to discard their standard error.
So here is an updated based on your patch.
-- >8 --
From: Matthieu Moy
Date: Mon, 11 Mar 2013 13:21:27 +0100
Subject: [PATCH] git-completion.bash: zsh does not implement function
redirection correctly
A recent change added functions whose entire standard error stream
is redirected to /dev/null using a construct that is valid POSIX.1
but is not widely used:
funcname () {
funcbody
} 2>/dev/null
Even though this file is "git-completion.bash", zsh completion
support dot-sources it (instead of asking bash to grok it like tcsh
completion does), and zsh does not implement this redirection
correctly.
With zsh, trying to complete an inexistant directory gave this:
git add no-such-dir/__git_ls_files_helper:cd:2: no such file or directory:
no-such-dir/
It is easy to work around by refraining from using this construct.
The correct thing to do in the longer term may be to stop dot-sourcing
the source meant for bash into zsh, but this patch should suffice as
a band-aid in the meantime.
Signed-off-by: Matthieu Moy
Signed-off-by: Junio C Hamano
---
contrib/completion/git-completion.bash | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 51b8b3b..3d4cc7c 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -300,8 +300,8 @@ __git_index_file_list_filter ()
__git_ls_files_helper ()
{
# NOTE: $2 is not quoted in order to support multiple options
- cd "$1" && git ls-files --exclude-standard $2
-} 2>/dev/null
+ cd "$1" 2>/dev/null && git ls-files --exclude-standard $2 2>/dev/null
+}
# Execute git diff-index, returning paths relative to the directory
@@ -309,8 +309,8 @@ __git_ls_files_helper ()
# specified in the second argument.
__git_diff_index_helper ()
{
- cd "$1" && git diff-index --name-only --relative "$2"
-} 2>/dev/null
+ cd "$1" 2>/dev/null && git diff-index --name-only --relative "$2"
2>/dev/null
+}
# __git_index_files accepts 1 or 2 arguments:
# 1: Options to pass to ls-files (required).
--
1.8.2-rc3-271-g00e868e
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well
On Sat, Mar 09, 2013 at 07:18:48PM +0100, Jens Lehmann wrote:
> Am 05.03.2013 22:17, schrieb Phil Hord:
> > In a shell, it usually goes like this:
> >
> >git submodule foreach --recursive '${cmd}'
> >{30-ish}
> >
> > It'd be easier if I could just include a switch for this, and maybe
> > even create an alias for it. But maybe this is different command
> > altogether.
>
> Are you sure you wouldn't forget to provide such a switch too? ;-)
>
> I'm still not convinced we should add a new switch, as it can easily
> be achieved by adding "${cmd} &&" to your scripts. And on the command
> line you could use an alias like this one to achieve that:
>
> [alias]
> recurse = !sh -c \"$@ && git submodule foreach --recursive $@\"
I also think it would be useful to have a switch (or even configuration)
to include the superproject.
The following (quite typical) use cases come to my mind:
# Assuming some not yet existing configuration values
git config submodule.recursive true
git config submodule.includeSuper true
# commit your work over the whole tree into one branch
git submodule foreach git checkout -b hv/my-super-cool-feature
git submodule foreach --post-order git commit -a -m "DRAFT: finished work for
today"
git submodule foreach git push hvoigt hv/my-super-cool-feature
# cleanup
git submodule foreach git clean -xfd
# reset
git submodule foreach git reset --hard
...
Assuming you have a submodule heavy project and you work on multiple
submodules including the superproject. These are quite typical commands
you would use during development of your feature I imagine. Once you are
finished you need to get your feature upstream by the individual
submodule rules.
On a feature branch during development there is nothing wrong in simply
doing full cross-submodule project commits.
At some point we will probably extend the above commands with a
--recurse-submodules switch but until then this is a good substitute so
why not have a --include-super maybe even as a configuration option ?
Cheers Heiko
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
Junio C Hamano writes: > So here is an updated based on your patch. Perfect, thanks. > The correct thing to do in the longer term may be to stop dot-sourcing > the source meant for bash into zsh, but this patch should suffice as > a band-aid in the meantime. I disagree with this particular part though. I think using the same code for bash and zsh makes sense, and it implies restricting to the common subset. I don't consider it "band-aid", but "nice code factoring" ;-). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A bug or unhandled case
Michał Janiszewski writes: > Hmm, indeed it works. Sorry for the confusion then (and a bit mistaken > commands, but you got them correct). > I wasn't aware of the -r option. I think what tripped you was that "git branch" deals with branch names, and not refnames (which is the underlying but lower level concept). "git branch -d refs/heads/master" is not a way to remove your local mastar branch. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
Matthieu Moy writes: > Junio C Hamano writes: > >> So here is an updated based on your patch. > > Perfect, thanks. > >> The correct thing to do in the longer term may be to stop dot-sourcing >> the source meant for bash into zsh, but this patch should suffice as >> a band-aid in the meantime. > > I disagree with this particular part though. I think using the same code > for bash and zsh makes sense, and it implies restricting to the common > subset. Having to restrict to the common subset means that whenever bash adds new and useful features that this script could take advantage of to improve the user experience, they cannot be employed until zsh catches up (and worse yet, it is outside the control of this script if zsh may ever catch up in the specific feature). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] Documentation/technical/api-fswatch.txt: start with outline
On Mon, Mar 11, 2013 at 01:47:03AM +0530, Ramkumar Ramachandra wrote: > git operations are slow on repositories with lots of files, and lots > of tiny filesystem calls like lstat(), getdents(), open() are > reposible for this. On the linux-2.6 repository, for instance, the > numbers for "git status" look like this: > > top syscalls sorted top syscalls sorted > by acc. timeby number > -- > 0.401906 40950 lstat0.401906 40950 lstat > 0.190484 5343 getdents 0.150055 5374 open > 0.150055 5374 open 0.190484 5343 getdents > 0.074843 2806 close 0.074843 2806 close > 0.003216 157 read 0.003216 157 read > > To solve this problem, we propose to build a daemon which will watch > the filesystem using inotify and report batched up events over a UNIX > socket. Since inotify is Linux-only, we have to leave open the > possibility of writing similar daemons for other platforms. > Everything will continue to work as before if there is no helper > present. While talking about platform independence. How about Windows? AFAIK there are no file based sockets. How about using shared memory, thats available, instead? It would greatly reduce the needed porting effort. Since operations on a lot of files is especially expensive on Windows it is one of the platforms that would profit the most from such a daemon. Cheers Heiko -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 11/03/2013 17:17, Junio C Hamano ha scritto: > Matthieu Moy writes: > >> The function-wide redirection used for __git_ls_files_helper and >> __git_diff_index_helper work only with bash. Using ZSH, trying to >> complete an inexistant directory gave this: >> >> git add no-such-dir/__git_ls_files_helper:cd:2: no such file or directory: >> no-such-dir/ >> >> Signed-off-by: Matthieu Moy >> --- > > This is not bash-ism but POSIX.1, even though it is not very well > known. I recall commenting on this exact pattern during the review. > Yes, I was plainning to send another patch to fix this (and your other suggestion regarding the CDPATH environment variable, if I remember correctly), but I was busy with other things; sorry. > [...] Regards Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlE+D7QACgkQscQJ24LbaURBTgCffpMCPjmcsP53/WE/VIQ2FIIc fiIAn3obBJ1yrHVUEmslz32ezvESCZ4G =7nia -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 11/03/2013 18:01, Junio C Hamano ha scritto: > [...] > Having to restrict to the common subset means that whenever bash > adds new and useful features that this script could take advantage > of to improve the user experience, they cannot be employed until zsh > catches up (and worse yet, it is outside the control of this script > if zsh may ever catch up in the specific feature). > Maybe, to avoid this problem and code duplication (the main reason bash script is sourced, as far as I can tell), it may be useful to add additional reusable git commands, for use in shell completion? E.g: git suggest *args returns a line separed list of filenames affected by cmd. Regards Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlE+EJkACgkQscQJ24LbaURjNwCfdW73fET/n4FRGftKcSJPsK7M nu4An1CC0dspGxLe5zqR9BdXBBDHWl/Y =11j7 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
Manlio Perillo writes:
> Yes, I was plainning to send another patch to fix this (and your other
> suggestion regarding the CDPATH environment variable, if I remember
> correctly),...
Ahh, thanks for reminding me of this. You are right; these two
functions are broken when the user has CDPATH set, I think.
Here is a reroll.
-- >8 --
From: Matthieu Moy
Date: Mon, 11 Mar 2013 13:21:27 +0100
Subject: [PATCH] git-completion.bash: zsh does not implement function
redirection correctly
A recent change added functions whose entire standard error stream
is redirected to /dev/null using a construct that is valid POSIX.1
but is not widely used:
funcname () {
cd "$1" && run some command "$2"
} 2>/dev/null
Even though this file is "git-completion.bash", zsh completion
support dot-sources it (instead of asking bash to grok it like tcsh
completion does), and zsh does not implement this redirection
correctly.
With zsh, trying to complete an inexistant directory gave this:
git add no-such-dir/__git_ls_files_helper:cd:2: no such file or directory:
no-such-dir/
Also these functions use "cd" to first go somewhere else before
running a command, but the location the caller wants them to go that
is given as an argument to them should not be affected by CDPATH
variable the users may have set for their interactive session.
To fix both of these, wrap the body of the function in a subshell,
unset CDPATH at the beginning of the subshell, and redirect the
standard error stream of the subshell to /dev/null.
Signed-off-by: Matthieu Moy
Signed-off-by: Junio C Hamano
---
contrib/completion/git-completion.bash | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 51b8b3b..430566d 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -299,9 +299,12 @@ __git_index_file_list_filter ()
# the second argument.
__git_ls_files_helper ()
{
- # NOTE: $2 is not quoted in order to support multiple options
- cd "$1" && git ls-files --exclude-standard $2
-} 2>/dev/null
+ (
+ test -n "${CDPATH+set}" && unset CDPATH
+ # NOTE: $2 is not quoted in order to support multiple options
+ cd "$1" && git ls-files --exclude-standard $2
+ ) 2>/dev/null
+}
# Execute git diff-index, returning paths relative to the directory
@@ -309,8 +312,11 @@ __git_ls_files_helper ()
# specified in the second argument.
__git_diff_index_helper ()
{
- cd "$1" && git diff-index --name-only --relative "$2"
-} 2>/dev/null
+ (
+ test -n "${CDPATH+set}" && unset CDPATH
+ cd "$1" && git diff-index --name-only --relative "$2"
+ ) 2>/dev/null
+}
# __git_index_files accepts 1 or 2 arguments:
# 1: Options to pass to ls-files (required).
--
1.8.2-rc3-219-ge56455f
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
Junio C Hamano writes: > Ahh, thanks for reminding me of this. You are right; these two > functions are broken when the user has CDPATH set, I think. > > Here is a reroll. Thanks. Even nicer that the previous since the CDPATH implied the subshell anyway. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
Matthieu Moy writes: > Junio C Hamano writes: > >> Ahh, thanks for reminding me of this. You are right; these two >> functions are broken when the user has CDPATH set, I think. >> >> Here is a reroll. > > Thanks. Even nicer that the previous since the CDPATH implied the > subshell anyway. Actually, "cd", not CDPATH, is what implies that the caller must be calling us in a subshell, e.g. result=$(__git_ls_files_helper dir/ args...) Otherwise the user's shell would have been taken to an unexpected place, with or without CDPATH. So strictly speaking there is no reason for an extra subshell here, but writing this in the way the patch does makes our intention crystal clear, I think. In any case, let's queue this fix for the 1.8.2 final. The CDPATH thing will affect not just zsh but bash users. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
On Mon, 2013-03-11 at 11:09 -0700, Junio C Hamano wrote:
> So strictly speaking there is no reason for an extra subshell here,
> but writing this in the way the patch does makes our intention
> crystal clear, I think.
If you're concerned about the extra processing of the new shell you can
use {} instead of ():
{
test -n "${CDPATH+set}" && unset CDPATH
# NOTE: $2 is not quoted in order to support multiple options
cd "$1" && git ls-files --exclude-standard $2
} 2>/dev/null
Zsh does support this properly in my testing. It's only redirection of
an entire function body, as the original, that is working differently in
zsh and bash.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Make help behaviour more consistent
Matthieu Moy writes: > Kevin Bracey writes: > >> Two significant usability flaws here: >> - If using man, "man git" to side-step "git help" is obvious. But if >>trying to use help.format=web, how to get the root html page? My >>technique was "git help XXX" and click the "git(1) suite" link at the >>bottom. "git help git" is non-obvious and apparently undocumented >>(it's not mentioned by "git", "git help", or "git help help"...). > > Can't this be solved by adding something like > > See 'git help git' for general help about Git. > > to the output of "git help"? I think the fact that "git help" provides a > small amount of output (typically: fits on one screen) is a nice feature > that avoids scaring people too early with the actual doc. That sounds like a good direction to go in. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 11/03/2013 19:09, Junio C Hamano ha scritto:
> Matthieu Moy writes:
>
>> Junio C Hamano writes:
>>
>>> Ahh, thanks for reminding me of this. You are right; these two
>>> functions are broken when the user has CDPATH set, I think.
>>>
>>> Here is a reroll.
>>
>> Thanks. Even nicer that the previous since the CDPATH implied the
>> subshell anyway.
>
> Actually, "cd", not CDPATH, is what implies that the caller must be
> calling us in a subshell, e.g.
>
> result=$(__git_ls_files_helper dir/ args...)
>
> Otherwise the user's shell would have been taken to an unexpected
> place, with or without CDPATH.
>
Right; this is the reason I used the `{` grouping, instead of `(`.
However, since the `{` is already specified when the function is
defined, I did not add another `{}` grouping.
> [...]
Regards Manlio Perillo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlE+K/4ACgkQscQJ24LbaUQqvwCgmReHb4VtMJDT+tv+XF9RPmXE
DlEAnjhsgXszSBVG1iW0WCLM6212+fdA
=SYzh
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rebase: strange failures to apply patc 3-way
On 3/10/13, Max Horn wrote:
> I did run
>
> touch lib/*.* src/*.* && git update-index --refresh && git diff-files
>
> a couple dozen times (the "problematic" files where in src/ and lib), but
> nothing happened. I just re-checked, and the rebase still fails in the same
> why...
>
> Perhaps I should add some printfs into the git source to figure out what
> exactly it thinks is not right about those files... i.e. how does it come to
> the conclusion that I have local changes, exactly. I don't know how Git does
> that -- does it take the mtime from (l)stat into account? Perhaps problems
> with my machine's clock could be responsible?
Instead of using "touch", maybe it'd be better if you run "ls-files"
and "stat" at the point where rebase failed. You should run the
command as soon as rebase failed. Don't try to run any git commands,
as they might change the index state.
And yes, git does make use of mtime and ctime from lstat to some
degree when detecting file changes. Inserting printf's to print the
timestamp might help, but the output might be too overwhelming to make
out useful information, especially during a rebase.
BTW, it looks like "stat" command on OS X only prints out timestamps
in seconds, and doesn't show you the nanoseconds part, which may be
significant in your situation. Instead of using the "stat" command,
try using this python command to print out the nanoseconds parts:
python -c "import sys;import os;s=os.stat(sys.argv[1]);print('%d, %f,
%f' % (s.st_size, s.st_ctime, s.st_mtime))" file1
Perhaps you could hack git-am.sh a bit to get more debugging info too.
Hm, maybe a good place to start is un-silencing the output of "git
apply". Inside "git-am.sh", you should see a line like:
git apply $squelch
Remove the $squelch, and see what output it generates.
Also, since you're getting the 3-way merge, you could also insert the
"ls-files" and "stat" right after "git-merge-recursive", but before
"die".
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: sharing .git/config
Jeff King wrote: > 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 >> 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. This seems to be unnecessarily complex and inelegant. Maybe this functionality is best managed as a separate git repository: `repo` from depot_tools uses a manifest repository containing all the project metadata. Maybe we can extend it/ write an more general version? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ZSH segmentation fault while completing "git mv dir/"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 11/03/2013 16:37, Matthieu Moy ha scritto:
> [...]
> I could reproduce with ~/.zshrc containing just:
>
> --
> fpath=(${HOME}/usr/etc/zsh ${fpath})
>
> autoload -Uz compinit
> compinit
>
> eval "`dircolors`"
> zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS}
> --
>
> ${HOME}/usr/etc/zsh contains two links _git and git-completion.bash
> pointing to Git's completion scripts in contrib/.
>
Using this configuration I still can't reproduce the problem, using
git v1.8.2-rc3-8-g0c91a6f.
But I'm not a zsh expert.
Regards Manlio Perillo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlE+MZAACgkQscQJ24LbaUSTuACfYmZV9cvroPzBUdJspw9abh24
fk8AnRTjvCEJ3m8Y2m/5jCIVVNsJAcG7
=5p6c
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git.c: make usage match manual page
Re-ordered option list in command-line usage to match the manual page. Also makes it less than 80-characters wide. Signed-off-by: Kevin Bracey --- git.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/git.c b/git.c index d33f9b3..2a98624 100644 --- a/git.c +++ b/git.c @@ -6,10 +6,10 @@ #include "run-command.h" const char git_usage_string[] = - "git [--version] [--exec-path[=]] [--html-path] [--man-path] [--info-path]\n" + "git [--version] [--help] [-c name=value]\n" + " [--exec-path[=]] [--html-path] [--man-path] [--info-path]\n" " [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]\n" " [--git-dir=] [--work-tree=] [--namespace=]\n" - " [-c name=value] [--help]\n" "[]"; const char git_more_info_string[] = -- 1.8.2.rc3.7.g1100d09.dirty -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git.c: make usage match manual page
Kevin Bracey writes: > Re-ordered option list in command-line usage to match the manual page. > Also makes it less than 80-characters wide. Thanks (s/Re-ordered/reorder/ and s/makes/make/, though). Is git.c the only one whose "-h" output does not match the manual synopsis? > > Signed-off-by: Kevin Bracey > --- > git.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/git.c b/git.c > index d33f9b3..2a98624 100644 > --- a/git.c > +++ b/git.c > @@ -6,10 +6,10 @@ > #include "run-command.h" > > const char git_usage_string[] = > - "git [--version] [--exec-path[=]] [--html-path] [--man-path] > [--info-path]\n" > + "git [--version] [--help] [-c name=value]\n" > + " [--exec-path[=]] [--html-path] [--man-path] > [--info-path]\n" > " [-p|--paginate|--no-pager] [--no-replace-objects] > [--bare]\n" > " [--git-dir=] [--work-tree=] > [--namespace=]\n" > - " [-c name=value] [--help]\n" > "[]"; > > const char git_more_info_string[] = -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH] submodule: allow common rewind when merging submodules
Allow merge of two commits that are contained in each other and do the
same rewind. The rewind is calculated using the commit recorded in the
merge base of the superproject.
Signed-off-by: Heiko Voigt
---
On Sun, Mar 10, 2013 at 06:09:53PM +0100, Heiko Voigt wrote:
> On Sat, Mar 09, 2013 at 06:45:56PM +0100, Jens Lehmann wrote:
> > I agree that rewinds are a very good reason not merge two branches using
> > a fast-forward strategy, but I believe Daniel's use case is a (and maybe
> > the only) valid exception to that rule: both branches contain *exactly*
> > the same rewind. In that case I don't see any problem to just do a fast
> > forward to S21, as both agree on the commits to rewind.
>
> That is different than using the merge base of the two commits needing
> merge. I agree that rewinding to exactly the same commits is probably a
> valid exception. Will have a look into extending the submodule merge
> strategy to include this case.
So here is the patch that implements this case. I am still a little bit
unsure about the user experience.
I had to extend the merge test setup to include a loose commit h because
otherwise we get a different merge case.
E.g. if you have this in the subproject
a---b---d
\ /
--c-+h
And the superproject records
BASE(b)---A(d)
\
---B(c)
When you merge A and B the change from b to d can either be represented
as a forward change or as a rewind to a and then adding c, d. Since we
calculate the rewind using merge bases we find a forward change here. So
here we fail to merge as before.
If the superproject records
BASE(b)---A(h)
\
---B(c)
We will now find a rewind to a for both sides and merge cleanly since b
is not contained in h.
So the problem with the user experience here is:
Imagine a project does this kind of rewind because a bug is discovered
in b and then adds some other things using commits like c, h and so on. Then
there are more commits after b which will eventually fix it. Now the
project merges the b line into the h line in the submodule and can get a
merge conflict in the superproject like explained in the first case.
This might feel strange to them since the step to h (moving b -> c)
resolved cleanly but then a merge which *looks like* it just involves a
fast-forward in the submodule will fail.
Anyway its nothing technically wrong with our merge strategy just that
we can not decide which way the user went and so the merge fails.
One step I have in mind but not yet taken: If I see this correctly we
could simplify the code by just doing the is_common_rewind() check and
drop the commits_follow_merge_base() check since it is already contained
in the former.
The testsuite passes with this commit. You can also find this on github:
https://github.com/hvoigt/git/commits/hv/submodule-merge-bases-series1
Cheers Heiko
submodule.c| 42 +++---
t/t7405-submodule-merge.sh | 39 +--
2 files changed, 76 insertions(+), 5 deletions(-)
diff --git a/submodule.c b/submodule.c
index 9ba1496..e24d630 100644
--- a/submodule.c
+++ b/submodule.c
@@ -911,6 +911,44 @@ static void print_commit(struct commit *commit)
#define MERGE_WARNING(path, msg) \
warning("Failed to merge submodule %s (%s)", path, msg);
+static int is_common_rewind(struct commit *base, struct commit *a, struct
commit *b)
+{
+ struct commit_list *merge_bases_a, *merge_bases_b;
+ int result;
+
+ /* find single rewind commit for a */
+ merge_bases_a = get_merge_bases(a, base, 1);
+ if (!merge_bases_a || commit_list_count(merge_bases_a) != 1)
+ return 0;
+
+ /* find single rewind commit for b */
+ merge_bases_b = get_merge_bases(b, base, 1);
+ if (!merge_bases_b || commit_list_count(merge_bases_b) != 1)
+ return 0;
+
+ /* see if we rewind to the same commit */
+ result = !hashcmp(merge_bases_a->item->object.sha1,
+ merge_bases_b->item->object.sha1);
+ free_commit_list(merge_bases_a);
+ free_commit_list(merge_bases_b);
+
+ return result;
+}
+
+static int commits_follow_merge_base(struct commit *commit_base,
+ struct commit *commit_a, struct commit *commit_b)
+{
+ /* check whether both changes are forward */
+ if (in_merge_bases(commit_base, commit_a) &&
+ in_merge_bases(commit_base, commit_b))
+ return 1;
+
+ if (is_common_rewind(commit_base, commit_a, commit_b))
+ return 1;
+
+ return 0;
+}
+
int merge_submodule(unsigned char result[20], const char *path,
const unsigned char base[20], const unsigned char a[20],
const unsigned char b[20], int search)
@@ -944,9 +982,7 @@ int merge_submodule(unsigned char result[20], const char
*path,
return 0;
}
- /* c
Re: [PATCH] git.c: make usage match manual page
On 11/03/2013 21:58, Junio C Hamano wrote: Kevin Bracey writes: Re-ordered option list in command-line usage to match the manual page. Also makes it less than 80-characters wide. Thanks (s/Re-ordered/reorder/ and s/makes/make/, though). Got it. But I'm going to reword it, to follow the history of the manual change. Is git.c the only one whose "-h" output does not match the manual synopsis? Generally, "-h" just puts "" in the synopsis, and then prints a line per option, so most commands don't really match the manual "show all options on one line" style anyway. git.c is atypical. (Something else to look at for the whole git help thing? Should "git -h" print a option list in that style?) But, yes, I've found a few others that are show almost the same thing as the manual but with subtle pointless differences. "git remote", for example. That's a larger project, I feel; the 80-column thing is key here. Kevin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git.c: rearrange git synopsis to fit in 80 columns
Make the command line use the narrower synopsis layout that the man page has used since commit 68e4b55. Signed-off-by: Kevin Bracey --- git.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/git.c b/git.c index d33f9b3..2a98624 100644 --- a/git.c +++ b/git.c @@ -6,10 +6,10 @@ #include "run-command.h" const char git_usage_string[] = - "git [--version] [--exec-path[=]] [--html-path] [--man-path] [--info-path]\n" + "git [--version] [--help] [-c name=value]\n" + " [--exec-path[=]] [--html-path] [--man-path] [--info-path]\n" " [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]\n" " [--git-dir=] [--work-tree=] [--namespace=]\n" - " [-c name=value] [--help]\n" "[]"; const char git_more_info_string[] = -- 1.8.2.rc3.7.g1100d09.dirty -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Make help behaviour more consistent
From: "Junio C Hamano" Sent: Monday, March 11, 2013 7:02 PM Matthieu Moy writes: Kevin Bracey writes: Two significant usability flaws here: - If using man, "man git" to side-step "git help" is obvious. But if trying to use help.format=web, how to get the root html page? My technique was "git help XXX" and click the "git(1) suite" link at the bottom. "git help git" is non-obvious and apparently undocumented (it's not mentioned by "git", "git help", or "git help help"...). Can't this be solved by adding something like See 'git help git' for general help about Git. to the output of "git help"? I think the fact that "git help" provides a small amount of output (typically: fits on one screen) is a nice feature that avoids scaring people too early with the actual doc. That sounds like a good direction to go in. My earlier attempt, and Junio's reply http://thread.gmane.org/gmane.comp.version-control.git/217352 It is tricky making sure that the message covers help for git, help's own help, the guides, and the commands, all in one compact usage line, while also covering the -h and --help options (which may not be known to new Git users on Windows, though probably obvious to Linux/Unix users). Philip -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rebase: strange failures to apply patc 3-way
On 11.03.2013, at 20:15, Andrew Wong wrote:
> On 3/10/13, Max Horn wrote:
>> I did run
>>
>> touch lib/*.* src/*.* && git update-index --refresh && git diff-files
>>
>> a couple dozen times (the "problematic" files where in src/ and lib), but
>> nothing happened. I just re-checked, and the rebase still fails in the same
>> why...
>>
>> Perhaps I should add some printfs into the git source to figure out what
>> exactly it thinks is not right about those files... i.e. how does it come to
>> the conclusion that I have local changes, exactly. I don't know how Git does
>> that -- does it take the mtime from (l)stat into account? Perhaps problems
>> with my machine's clock could be responsible?
>
> Instead of using "touch", maybe it'd be better if you run "ls-files"
> and "stat" at the point where rebase failed. You should run the
> command as soon as rebase failed. Don't try to run any git commands,
> as they might change the index state.
So I tried this:
git rebase branches/stable-4.6 # ... which leads to the error
git ls-files -m
but got nothing. Perhaps you had something else in mind, though, but I am not
quite sure what... sorry for being dense, but if you let me know what exactly
you meant, I'll be happy to try that. As for the stat command:
>
> And yes, git does make use of mtime and ctime from lstat to some
> degree when detecting file changes. Inserting printf's to print the
> timestamp might help, but the output might be too overwhelming to make
> out useful information, especially during a rebase.
>
> BTW, it looks like "stat" command on OS X only prints out timestamps
> in seconds, and doesn't show you the nanoseconds part, which may be
> significant in your situation. Instead of using the "stat" command,
> try using this python command to print out the nanoseconds parts:
> python -c "import sys;import os;s=os.stat(sys.argv[1]);print('%d, %f,
> %f' % (s.st_size, s.st_ctime, s.st_mtime))" file1
I can do that, but I am not quite sure what the output should tell me? BTW, I
think OS X just does not provide the stat information on a nanosecond level, at
least that python command doesn't seem to yield useful extra data... Here is
what I got after I just triggered the failing rebase (today it's again a
different file it fails on that yesterday...). For comparision, I run stat
first on the file with "conflicts", and then on a file that is not being
touched by the rebase:
File: ‘BAD-FILE’
Size: 21058 Blocks: 48 IO Block: 4096 regular file
Device: e04h/234881028d Inode: 19108072Links: 1
Access: (0644/-rw-r--r--) Uid: ( 502/ mhorn) Gid: ( 20/ staff)
Access: 2013-03-11 21:40:14.0 +0100
Modify: 2013-03-11 21:40:12.0 +0100
Change: 2013-03-11 21:40:14.0 +0100
Birth: 2013-03-11 21:40:12.0 +0100
File: ‘NEUTRAL-FILE’
Size: 1425Blocks: 8 IO Block: 4096 regular file
Device: e04h/234881028d Inode: 18180450Links: 1
Access: (0644/-rw-r--r--) Uid: ( 502/ mhorn) Gid: ( 20/ staff)
Access: 2013-03-11 17:58:30.0 +0100
Modify: 2013-03-10 14:20:39.0 +0100
Change: 2013-03-10 14:20:39.0 +0100
Birth: 2013-02-27 16:18:57.0 +0100
Here is the output of the python script for the two files:
21058, 1363034414.00, 1363034412.00
1425, 1362921639.00, 1362921639.00
One thing I notice is that ctime equals atime and both are larger than mtime.
But I have no clue if that has any significance... hmm
> Perhaps you could hack git-am.sh a bit to get more debugging info too.
> Hm, maybe a good place to start is un-silencing the output of "git
> apply". Inside "git-am.sh", you should see a line like:
>git apply $squelch
> Remove the $squelch, and see what output it generates.
error: BAD-FILE: does not match index
I inserted "git ls-files -m" before that but that didn't print anything nor had
it any other effect.
>
> Also, since you're getting the 3-way merge, you could also insert the
> "ls-files" and "stat" right after "git-merge-recursive", but before
> "die".
>
Aha, so that was interesting: I inserted both a "stat" invocation, and also
invoked the "md5" tool to be able to tell whether the file content matched what
I thought it should match. Doing that caused the breaking commit to shift. So,
I added a second stat / md5 pair on the new breaking file. After doing that,
the rebase suddenly completed! I reset -- hard to the previous state, tried
again, and again it worked. And this after consistently failing (albeit in
differing places) in maybe a hundred or more tries before. Removing those two
calls, it failed again. I tried inserting a "sleep 1", just in case it's a
race, but with that it still failed.
I then re-added the stat / md5 calls, and -- it failed again, but this much
earlier (in commit 8, not around commits 14-18).
So I added the new conflicting fail to the stat/md5 calls (for a total of three
files), and
Re: rebase: strange failures to apply patc 3-way
PS: Just as a side note, I should mention that I have done tons of rebases on various repositories on this very machine: same hard drive, same file system; the git version of course has changed over time, but as I already described, I can reproduce the same issue with older git versions. All I want to say here is: While this may of course be a bug of OS X or my machine may be faulty or whatever, it is not as if this issue is occurring all over the place. It is so far somehow specific to this repository, or even the particular branch. So it is probably not something as simple as a faulty clock, because then I should be seeing rebases fail all over the place, right? (Hm, OK, admittedly I didn't try any other big rebases in the last couple days. And right now I have no good example at hand, i.e. a non-trivial branch that cleanly rebases to some other branch) Cheers, Max-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rebase: strange failures to apply patc 3-way
On 3/11/13, Max Horn wrote: > So I tried this: > > git rebase branches/stable-4.6 # ... which leads to the error > git ls-files -m > > but got nothing. Perhaps you had something else in mind, though, but I am > not quite sure what... sorry for being dense, but if you let me know what > exactly you meant, I'll be happy to try that. As for the stat command: I'm still digesting the information form the email. Just want to quickly mention that the "ls-files" command should be: $ git ls-files --debug file1 file2 You should always get output. It prints out stat-like information for files in the index. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] fix git-p4 client root symlink problems
Update from v1: * add SYMLINKS prerequisite to the new symlink test Thanks Hannes. Miklós pointed out in http://thread.gmane.org/gmane.comp.version-control.git/214915 that when the p4 client root included a symlink, bad things happen. It is fixable, but inconvenient, to use an absolute path in one's p4 client. It's not too hard to be smarter about this in git-p4. Thanks to Miklós for the patch, and to John for the style suggestions. I wrote a couple of tests to make sure this part doesn't break again. This is maybe a bug introduced by bf1d68f (git-p4: use absolute directory for PWD env var, 2011-12-09), but that's so long ago that I don't think this is a candidate for maint. -- Pete Miklós Fazekas (1): git p4: avoid expanding client paths in chdir Pete Wyckoff (2): git p4 test: make sure P4CONFIG relative path works git p4 test: should honor symlink in p4 client root git-p4.py | 29 ++--- t/t9808-git-p4-chdir.sh | 41 + 2 files changed, 63 insertions(+), 7 deletions(-) -- 1.8.2.rc2.65.g92f3e2d -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] git p4 test: make sure P4CONFIG relative path works
This adds a test for the fix in bf1d68f (git-p4: use absolute directory for PWD env var, 2011-12-09). It is necessary to set PWD to an absolute path so that p4 can find files referenced by non-absolute paths, like the value of the P4CONFIG environment variable. P4 does not open files directly; it builds a path by prepending the contents of the PWD environment variable. Signed-off-by: Pete Wyckoff --- t/t9808-git-p4-chdir.sh | 14 ++ 1 file changed, 14 insertions(+) diff --git a/t/t9808-git-p4-chdir.sh b/t/t9808-git-p4-chdir.sh index dc92e60..55c5e36 100755 --- a/t/t9808-git-p4-chdir.sh +++ b/t/t9808-git-p4-chdir.sh @@ -42,6 +42,20 @@ test_expect_success 'P4CONFIG and relative dir clone' ' ) ' +# Common setup using .p4config to set P4CLIENT and P4PORT breaks +# if clone destination is relative. Make sure that chdir() expands +# the relative path in --dest to absolute. +test_expect_success 'p4 client root would be relative due to clone --dest' ' + test_when_finished cleanup_git && + ( + echo P4PORT=$P4PORT >git/.p4config && + P4CONFIG=.p4config && + export P4CONFIG && + unset P4PORT && + git p4 clone --dest="git" //depot + ) +' + test_expect_success 'kill p4d' ' kill_p4d ' -- 1.8.2.rc2.65.g92f3e2d -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] git p4 test: should honor symlink in p4 client root
This test fails when the p4 client root includes a symlink. It complains: Path /vol/bar/projects/foo/... is not under client root /p/foo and dumps a traceback. Signed-off-by: Pete Wyckoff --- t/t9808-git-p4-chdir.sh | 27 +++ 1 file changed, 27 insertions(+) diff --git a/t/t9808-git-p4-chdir.sh b/t/t9808-git-p4-chdir.sh index 55c5e36..4773296 100755 --- a/t/t9808-git-p4-chdir.sh +++ b/t/t9808-git-p4-chdir.sh @@ -56,6 +56,33 @@ test_expect_success 'p4 client root would be relative due to clone --dest' ' ) ' +# When the p4 client Root is a symlink, make sure chdir() does not use +# getcwd() to convert it to a physical path. +test_expect_failure SYMLINKS 'p4 client root symlink should stay symbolic' ' + physical="$TRASH_DIRECTORY/physical" && + symbolic="$TRASH_DIRECTORY/symbolic" && + test_when_finished "rm -rf \"$physical\"" && + test_when_finished "rm \"$symbolic\"" && + mkdir -p "$physical" && + ln -s "$physical" "$symbolic" && + test_when_finished cleanup_git && + ( + P4CLIENT=client-sym && + p4 client -i <<-EOF && + Client: $P4CLIENT + Description: $P4CLIENT + Root: $symbolic + LineEnd: unix + View: //depot/... //$P4CLIENT/... + EOF + git p4 clone --dest="$git" //depot && + cd "$git" && + test_commit file2 && + git config git-p4.skipSubmitEdit true && + git p4 submit + ) +' + test_expect_success 'kill p4d' ' kill_p4d ' -- 1.8.2.rc2.65.g92f3e2d -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Make help behaviour more consistent
"Philip Oakley" writes: > From: "Junio C Hamano" >> Matthieu Moy writes: >> >>> See 'git help git' for general help about Git. >>> >>> to the output of "git help"? >> ... >> That sounds like a good direction to go in. > > My earlier attempt, and Junio's reply > http://thread.gmane.org/gmane.comp.version-control.git/217352 Yeah, I threw "git help git" in the general category of "git help " in that message, and now I realize that it may arguably be confusing to some people. Perhaps spend one more line to do something like this? 'git help -a' and 'git help -g' lists available subcommands and concept guides. See 'git help ' or 'git help ' to read about a specific subcommand or concept. For an overview, see 'git help git'. I am neutral between the above and this: For an overview, see 'git help git'. 'git help -a' and 'git help -g' lists available subcommands and concept guides. See 'git help ' or 'git help ' to read about a specific subcommand or concept. Hrm? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] git p4: avoid expanding client paths in chdir
From: Miklós Fazekas The generic chdir() helper sets the PWD environment variable, as that is what is used by p4 to know its current working directory. Normally the shell would do this, but in git-p4, we must do it by hand. However, when the path contains a symbolic link, os.getcwd() will return the physical location. If the p4 client specification includes symlinks, setting PWD to the physical location causes p4 to think it is not inside the client workspace. It complains, e.g. Path /vol/bar/projects/foo/... is not under client root /p/foo One workaround is to use AltRoots in the p4 client specification, but it is cleaner to handle it directly in git-p4. Other uses of chdir still require setting PWD to an absolute path so p4 features like P4CONFIG work. See bf1d68f (git-p4: use absolute directory for PWD env var, 2011-12-09). [ pw: tweak patch and commit message ] Thanks-to: John Keeping Signed-off-by: Pete Wyckoff --- git-p4.py | 29 ++--- t/t9808-git-p4-chdir.sh | 2 +- 2 files changed, 23 insertions(+), 8 deletions(-) diff --git a/git-p4.py b/git-p4.py index 647f110..7288c0b 100755 --- a/git-p4.py +++ b/git-p4.py @@ -79,12 +79,27 @@ def p4_build_cmd(cmd): real_cmd += cmd return real_cmd -def chdir(dir): -# P4 uses the PWD environment variable rather than getcwd(). Since we're -# not using the shell, we have to set it ourselves. This path could -# be relative, so go there first, then figure out where we ended up. -os.chdir(dir) -os.environ['PWD'] = os.getcwd() +def chdir(path, is_client_path=False): +"""Do chdir to the given path, and set the PWD environment + variable for use by P4. It does not look at getcwd() output. + Since we're not using the shell, it is necessary to set the + PWD environment variable explicitly. + + Normally, expand the path to force it to be absolute. This + addresses the use of relative path names inside P4 settings, + e.g. P4CONFIG=.p4config. P4 does not simply open the filename + as given; it looks for .p4config using PWD. + + If is_client_path, the path was handed to us directly by p4, + and may be a symbolic link. Do not call os.getcwd() in this + case, because it will cause p4 to think that PWD is not inside + the client path. + """ + +os.chdir(path) +if not is_client_path: +path = os.getcwd() +os.environ['PWD'] = path def die(msg): if verbose: @@ -1624,7 +1639,7 @@ class P4Submit(Command, P4UserMap): new_client_dir = True os.makedirs(self.clientPath) -chdir(self.clientPath) +chdir(self.clientPath, is_client_path=True) if self.dry_run: print "Would synchronize p4 checkout in %s" % self.clientPath else: diff --git a/t/t9808-git-p4-chdir.sh b/t/t9808-git-p4-chdir.sh index 4773296..11d2b51 100755 --- a/t/t9808-git-p4-chdir.sh +++ b/t/t9808-git-p4-chdir.sh @@ -58,7 +58,7 @@ test_expect_success 'p4 client root would be relative due to clone --dest' ' # When the p4 client Root is a symlink, make sure chdir() does not use # getcwd() to convert it to a physical path. -test_expect_failure SYMLINKS 'p4 client root symlink should stay symbolic' ' +test_expect_success SYMLINKS 'p4 client root symlink should stay symbolic' ' physical="$TRASH_DIRECTORY/physical" && symbolic="$TRASH_DIRECTORY/symbolic" && test_when_finished "rm -rf \"$physical\"" && -- 1.8.2.rc2.65.g92f3e2d -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rebase: strange failures to apply patc 3-way
On 3/11/13, Max Horn wrote: > PS: Just as a side note, I should mention that I have done tons of rebases > on various repositories on this very machine: same hard drive, same file > system; the git version of course has changed over time, but as I already > described, I can reproduce the same issue with older git versions. What if you do a "git clone" from this repo to an entirely new repo? I wonder if the rebase issue still happens in the new repo... Could you also post the .git/config file from the repo? If supported, git could actually make use of threading when doing "stat"... it should be disabled by default though, but you could try disabling it with this config: git config core.preloadindex false But I don't know why that'd only affect this one repo and not the others though... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git svn error "Not a valid object name"
Hi there, We have been attempting to move our smallish SVN repository for our Open Source project (ww.exist-db.org) from SourceForge over to GitHub and it is not going well at all. We started with svn2git as recommended by GitHub and that didnt work, we are not on to using 'git svn' directly. If you want the backlog of detail its here - http://markmail.org/message/khjx6n2jbvcdnnf5 Our public SourceForge Subversion repository is here: http://svn.code.sf.net/p/exist/code/trunk/eXist We cloned that to the local server using rsync and are attempting to migrate to git using the following commands: $ git svn init -t tags -b stable -T trunk file:///home/ec2-user/svn-rsync/code new-git-repo $ cd new-git-repo $ git config svn-remote.svn.preserve-empty-dirs true $ git config svn-remote.svn.rewriteRoot https://svn.code.sf.net/p/exist/code $ git svn fetch -A /home/ec2-user/.svn2git/authors.txt It all started well and was running away for quite some hours, when the following error occurred: fatal: Not a valid object name ls-tree -z ./webapp/api/: command returned error: 128 I have no idea what this means, or how to fix this. We are using Git version 1.8.1.GIT on Amazon EC2 Linux. Any suggestions please? I reproduce the log of the last two revisions output from running 'git svn fetch ...' below, in case that provides any clues: r3447 = e7d8dd23f78464228128e9b72711c5722b07ad42 (refs/remotes/trunk) M eXist-1.0/src/org/exist/xquery/test/XQueryFunctionsTest.java M eXist-1.0/src/org/exist/xquery/functions/FunString.java r3448 = 811a870bb7b83d36ce41b2afab39b2fecf59803d (refs/remotes/trunk) Found possible branch point: file:///home/ec2-user/svn-rsync/code/trunk/eXist-1.0 => file:///home/ec2-user/svn-rsync/code/tags/DLN3445-pre-merge, 3452 Initializing parent: refs/remotes/tags/DLN3445-pre-merge@3452 A conf.xml A src/org/exist/xmldb.xsl A src/org/exist/Parser.java A src/org/exist/util/LockOwner.java A src/org/exist/util/CollectionScanner.java A src/org/exist/util/SyntaxException.java A src/org/exist/util/VariableByteInputStream.java A src/org/exist/util/VariableByteOutputStream.java A src/org/exist/util/LockException.java A src/org/exist/util/Configuration.java A src/org/exist/util/OrderedLinkedList.java A src/org/exist/util/XMLFilenameFilter.java A src/org/exist/util/PorterStemmer.java A src/org/exist/util/SimpleTimeOutLock.java A src/org/exist/util/ByteConversion.java A src/org/exist/util/ProgressListener.java A src/org/exist/util/IncludeXMLFilter.java A src/org/exist/util/DatabaseConfigurationException.java A src/org/exist/util/FastByteBuffer.java A src/org/exist/util/Lockable.java A src/org/exist/util/DirectoryScanner.java A src/org/exist/util/FastStringBuffer.java A src/org/exist/util/LongLinkedList.java A src/org/exist/util/Lock.java A src/org/exist/util/ProgressBar.java A src/org/exist/util/LongArrayList.java A src/org/exist/util/ReadOnlyException.java A src/org/exist/util/VariableByteCoding.java A src/org/exist/util/XMLUtil.java A src/org/exist/util/test/VariableByteStreamTest.java A src/org/exist/util/ObjectPool.java A src/org/exist/util/Arrays.java A src/org/exist/util/ProgressIndicator.java A src/org/exist/util/SelectorUtils.java A src/org/exist/http/HttpServer.java A src/org/exist/http/HttpServerConnection.java A src/org/exist/dom/NodeListImpl.java A src/org/exist/dom/TextImpl.java A src/org/exist/dom/NodeImpl.java A src/org/exist/dom/VirtualNodeSet.java A src/org/exist/dom/CharacterDataImpl.java A src/org/exist/dom/NamedNodeMapImpl.java A src/org/exist/dom/ElementImpl.java A src/org/exist/dom/SymbolTable.java A src/org/exist/dom/NodeIDSet.java A src/org/exist/dom/NodeProxyFactory.java A src/org/exist/dom/EmptyNodeSet.java A src/org/exist/dom/SortedNodeSet.java A src/org/exist/dom/DocumentFragmentImpl.java A src/org/exist/dom/CommentImpl.java A src/org/exist/dom/DOMImplementation.java A src/org/exist/dom/NodeProxy.java A src/org/exist/dom/DocumentIterator.java A src/org/exist/dom/DocumentSet.java A src/org/exist/dom/ArraySet.java A src/org/exist/dom/Collection.java A src/org/exist/dom/AttrImpl.java A src/org/exist/dom/ProcessingInstructionImpl.java A src/org/exist/do
Re: rebase: strange failures to apply patc 3-way
On 11.03.2013, at 22:34, Andrew Wong wrote: > On 3/11/13, Max Horn wrote: >> So I tried this: >> >> git rebase branches/stable-4.6 # ... which leads to the error >> git ls-files -m >> >> but got nothing. Perhaps you had something else in mind, though, but I am >> not quite sure what... sorry for being dense, but if you let me know what >> exactly you meant, I'll be happy to try that. As for the stat command: > > I'm still digesting the information form the email. Just want to > quickly mention that the "ls-files" command should be: >$ git ls-files --debug file1 file2 > > You should always get output. It prints out stat-like information for > files in the index. Aha, I see. I inserted that into git-am, once right before git-merge-recursive and once right after it (just before a call to rerere). This is what I got; Applying: COMMIT X error: BAD-FILE: does not match index Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... GOOD-FILE ctime: 1362921639:0 mtime: 1362921639:0 dev: 234881028ino: 18665879 uid: 502 gid: 20 size: 25429 flags: 0 BAD-FILE ctime: 1363040264:0 mtime: 1363040264:0 dev: 234881028ino: 19170773 uid: 502 gid: 20 size: 52906 flags: 0 error: Your local changes to the following files would be overwritten by merge: BAD-FILE Please, commit your changes or stash them before you can merge. Aborting GOOD-FILE ctime: 1362921639:0 mtime: 1362921639:0 dev: 234881028ino: 18665879 uid: 502 gid: 20 size: 25429 flags: 0 BAD-FILE ctime: 1363040264:0 mtime: 1363040264:0 dev: 234881028ino: 19170773 uid: 502 gid: 20 size: 52906 flags: 0 Failed to merge in the changes. Patch failed at 0015 COMMIT X ... So the ctime/mtine for the BAD-FILE do not differ. After this, I also run "ls-files" on the command line, and got: GOOD-FILE gd ctime: 1362921639:0 mtime: 1362921639:0 dev: 234881028ino: 18665879 uid: 502 gid: 20 size: 25429 flags: 0 BAD-FILE ctime: 1363040266:0 mtime: 1363040264:0 dev: 234881028ino: 19170773 uid: 502 gid: 20 size: 52906 flags: 0 So now the ctime of the bad file is more recent than the mtime. Max-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Mar 2013, #03; Mon, 11)
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The final will be tagged in a few days; we have enough material for
post 1.8.2 cycle already, and it will be a busy few weeks towards
the end of the month once the dust settles.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--
[Graduated to "master"]
* gp/add-u-A-documentation (2013-03-07) 1 commit
(merged to 'next' on 2013-03-08 at d86f8b3)
+ add: Clarify documentation of -A and -u
(this branch is used by jc/add-2.0-delete-default and
jc/add-2.0-u-A-sans-pathspec.)
--
[New Topics]
* jc/maint-push-refspec-default-doc (2013-03-08) 1 commit
- Documentation/git-push: clarify the description of defaults
Clarify in the documentation "what" gets pushed to "where" when the
command line to "git push" does not say these explicitly.
Needs proofreading.
* jc/reflog-reverse-walk (2013-03-08) 3 commits
- reflog: add for_each_reflog_ent_reverse() API
- for_each_recent_reflog_ent(): simplify opening of a reflog file
- for_each_reflog_ent(): extract a helper to process a single entry
An internal function used to implementate "git checkout @{-1}" was
hard to use correctly.
* jk/alias-in-bare (2013-03-08) 3 commits
(merged to 'next' on 2013-03-09 at 2f9d72a)
+ setup: suppress implicit "." work-tree for bare repos
+ environment: add GIT_PREFIX to local_repo_env
+ cache.h: drop LOCAL_REPO_ENV_SIZE
An aliased command spawned from a bare repository that does not say
it is bare with "core.bare = yes" is treated as non-bare by mistake.
Will cook in 'next'.
* pw/p4-symlinked-root (2013-03-11) 3 commits
- git p4: avoid expanding client paths in chdir
- git p4 test: should honor symlink in p4 client root
- git p4 test: make sure P4CONFIG relative path works
Will merge to 'next'.
* jc/add-2.0-delete-default (2013-03-08) 3 commits
- git add ... defaults to "-A"
- git add: start preparing for "git add ..." to default to "-A"
- builtin/add.c: simplify boolean variables
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
There seemed to be some interest in this topic, so resurrected and
rebased on top of recent documentation updates to propose a
possible transition plan.
* jc/add-2.0-u-A-sans-pathspec (2013-03-11) 1 commit
- git add: -u/-A now affects the entire working tree
"git add -u/-A" without pathspec has traditonally limited its
operation to the current directory and its subdirectories, but in
Git 1.8.2 we started encouraging users to be more explicit to
specify "." when they mean it (and use ":/" to make it affect the
entire working tree). With this, we finally change the behaviour
and make it affect the entire working tree in Git 2.0.
* jk/empty-archive (2013-03-10) 2 commits
- archive: handle commits with an empty tree
- test-lib: factor out $GIT_UNZIP setup
"git archive" reports a failure when asked to create an archive out
of an empty tree. It would be more intuitive to give an empty
archive back in such a case.
Will merge to 'next'.
* kb/p4merge (2013-03-09) 3 commits
- git-merge-one-file: revise merge error reporting
- mergetools/p4merge: create a base if none available
- mergetools/p4merge: swap LOCAL and REMOTE
Expecting a reroll.
--
[Stalled]
* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
- Highlight the link target line in Gitweb using CSS
Expecting a reroll.
$gmane/211935
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a reroll.
$gmane/210151
"The first remote becomes the default" bit is better done as a
separate step.
--
[Cooking]
* po/help-guides (2013-03-03) 5 commits
- help doc: include --guide option description
- help.c: add list_common_guides_help() function
- help.c: add --guide option
- help.c: use OPT_COUNTUP
- show 'git help ' usage, with examples
Give more visibility to "concept guides" to help "git help" users.
Expecting a reroll.
$gmane/217384
* jk/graph-c-expose-symbols-for-cgit (2013-03-03
Re: rebase: strange failures to apply patc 3-way
On 11.03.2013, at 23:10, Andrew Wong wrote: > On 3/11/13, Max Horn wrote: >> PS: Just as a side note, I should mention that I have done tons of rebases >> on various repositories on this very machine: same hard drive, same file >> system; the git version of course has changed over time, but as I already >> described, I can reproduce the same issue with older git versions. > > What if you do a "git clone" from this repo to an entirely new repo? I > wonder if the rebase issue still happens in the new repo... The problem seems to be non-existent in a clone. > > Could you also post the .git/config file from the repo? [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true ignorecase = true precomposeunicode = false Other than that, it just contains some a [remote] section and several [branch] sections. None of these contains any fancy (i.e. the branch sections just say "remote = origin" and give the name of the remote branch). Looking at the git config man page to check what each of my config settings does, I discovered "trustctime". And adding trustctime = false to .git/config made the rebase work, every single time. Huh. Adding this to the fact that a clone works fine, I wonder if something *is* touching my files, but just in that directory. But what could it be? One nagging suspicion is the "file versioning" feature Apple introduced as part of Time Machine in OS X 10.7; it's kind of a "version control system for n00bs" for arbitrary documents. It has caused me some pain in the past. But I just re-checked, and problematic repos is explicitly on the Time Machine exclusion list. I also used the "tmutil isexcluded FILES" to verify that the problematic files are really on the TM exclusion list. Finally, I moved the one of the repos subdirectory containing most of the problematic files, and then run "git checkout". In other instances, this sufficed to "disassociate" a file from an unwanted TM version history. But doing that had no effect here, i.e. also with the freshly regenerated files, the problems appear. > > If supported, git could actually make use of threading when doing > "stat"... it should be disabled by default though, but you could try > disabling it with this config: >git config core.preloadindex false > > But I don't know why that'd only affect this one repo and not the > others though... > This setting doesn't seem to have any effect on the issue at hand. Cheers, Max-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] shell: new no-interactive-login command to print a custom message
Ramkumar Ramachandra wrote: > Jonathan Nieder wrote: >> * If the file ~/git-shell-commands/no-interactive-login exists, >>run no-interactive-login to let the server say what it likes, >>then hang up. [...] > If "no-interactive-login" doesn't have execute permissions, we'll get > an error from here: > > fatal: cannot exec 'git-shell-commands/no-interactive-login': Permission > denied Yep. Intended. Thanks for looking it over, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rebase: strange failures to apply patc 3-way
On 3/11/13, Max Horn wrote: > Looking at the git config man page to check what each of my config settings > does, I discovered "trustctime". And adding > trustctime = false > to .git/config made the rebase work, every single time. Huh. > > > Adding this to the fact that a clone works fine, I wonder if something *is* > touching my files, but just in that directory. But what could it be? One > nagging suspicion is the "file versioning" feature Apple introduced as part > of Time Machine in OS X 10.7; it's kind of a "version control system for > n00bs" for arbitrary documents. It has caused me some pain in the past. > > But I just re-checked, and problematic repos is explicitly on the Time > Machine exclusion list. I also used the "tmutil isexcluded FILES" to verify > that the problematic files are really on the TM exclusion list. Finally, I > moved the one of the repos subdirectory containing most of the problematic > files, and then run "git checkout". In other instances, this sufficed to > "disassociate" a file from an unwanted TM version history. But doing that > had no effect here, i.e. also with the freshly regenerated files, the > problems appear. Would you be able to turn off Time Machine completely and do a few tests? If it does works, then it becomes a matter of fixing Time Machine... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rebase: strange failures to apply patc 3-way
On 11.03.2013, at 23:54, Andrew Wong wrote: > On 3/11/13, Max Horn wrote: >> Looking at the git config man page to check what each of my config settings >> does, I discovered "trustctime". And adding >> trustctime = false >> to .git/config made the rebase work, every single time. Huh. >> >> >> Adding this to the fact that a clone works fine, I wonder if something *is* >> touching my files, but just in that directory. But what could it be? One >> nagging suspicion is the "file versioning" feature Apple introduced as part >> of Time Machine in OS X 10.7; it's kind of a "version control system for >> n00bs" for arbitrary documents. It has caused me some pain in the past. >> >> But I just re-checked, and problematic repos is explicitly on the Time >> Machine exclusion list. I also used the "tmutil isexcluded FILES" to verify >> that the problematic files are really on the TM exclusion list. Finally, I >> moved the one of the repos subdirectory containing most of the problematic >> files, and then run "git checkout". In other instances, this sufficed to >> "disassociate" a file from an unwanted TM version history. But doing that >> had no effect here, i.e. also with the freshly regenerated files, the >> problems appear. > > Would you be able to turn off Time Machine completely and do a few > tests? If it does works, then it becomes a matter of fixing Time > Machine... I did turn it off just now, but no effect. Then again, daemons like revisiond were still running... One more thing: I used the "fs_usage" to monitor what process accessed what file during one of those failing "git rebase" runs. I then searched through this to determine which processes accessed the "bad" file in this time. The result where these processes (aggregated): git revisiond fseventsd git-merge-recursive Note that Time Machine was not running, but revisiond is... from its manpage: revisiond is the daemon that manages document revisions created by applications and system services. There are no configurations to revisiond, and users should not run revisiond manually. This is the process I am suspecting. Specifically, a fchflags call it makes (see that attached excerpt of the fs_usage output). I am not sure, but my guess would be that it sets SF_ARCHIVED on the file. Causing its ctime to wander... Yuck. But I don't know how to control it... and I am not sure if I can just kill it. Hrm. I'll try to dig some more into it, perhaps I can somehow confirm that this is *really* the cause of the problems, and somehow prevent it. Cheers, Max 00:59:54.349156 lstat64src/BAD_FILE 0.50 git.623953 00:59:54.349160 open F=5(R_) src/BAD_FILE 0.04 git.623953 00:59:54.350659 close F=5 0.07 git.623953 00:59:54.371716 lstat64src/BAD_FILE 0.02 git.623955 00:59:54.429674 lstat64src/BAD_FILE 0.02 git.623959 00:59:54.600060 lstat64src/BAD_FILE 0.07 git.623959 00:59:54.600151 stat64 /Users/mhorn/the-path-to-my-repository/src/BAD_FILE 0.06 revisiond.623963 00:59:54.600154 stat64 /Users/mhorn/the-path-to-my-repository/src 0.03 revisiond.623963 00:59:54.600160 open F=7(R_) /Users/mhorn/the-path-to-my-repository/src/BAD_FILE 0.06 revisiond.623963 00:59:54.600161 fstatfs64 F=7 0.02 revisiond.623963 00:59:54.600163 close F=7 0.02 revisiond.623963 00:59:54.600387 unlink src/BAD_FILE 0.000328 W git.623959 00:59:54.600429 open F=5(_WC__E) src/BAD_FILE 0.39 git.623959 00:59:54.602910 write F=5B=0x4000 0.40 git.623959 00:59:54.602932 write F=5B=0x4000 0.17 git.623959 00:59:54.602947 write F=5B=0x4000 0.11 git.623959 00:59:54.602958 write F=5B=0x4000 0.09 git.623959 00:59:54.602969 write F=5B=0x4000
Re: rebase: strange failures to apply patc 3-way
On 11.03.2013, at 23:54, Andrew Wong wrote: > On 3/11/13, Max Horn wrote: >> Looking at the git config man page to check what each of my config settings >> does, I discovered "trustctime". And adding >> trustctime = false >> to .git/config made the rebase work, every single time. Huh. >> >> >> Adding this to the fact that a clone works fine, I wonder if something *is* >> touching my files, but just in that directory. But what could it be? One >> nagging suspicion is the "file versioning" feature Apple introduced as part >> of Time Machine in OS X 10.7; it's kind of a "version control system for >> n00bs" for arbitrary documents. It has caused me some pain in the past. >> >> But I just re-checked, and problematic repos is explicitly on the Time >> Machine exclusion list. I also used the "tmutil isexcluded FILES" to verify >> that the problematic files are really on the TM exclusion list. Finally, I >> moved the one of the repos subdirectory containing most of the problematic >> files, and then run "git checkout". In other instances, this sufficed to >> "disassociate" a file from an unwanted TM version history. But doing that >> had no effect here, i.e. also with the freshly regenerated files, the >> problems appear. > > Would you be able to turn off Time Machine completely and do a few > tests? If it does works, then it becomes a matter of fixing Time > Machine... > sudo launchctl unload /System/Library/LaunchDaemons/com.apple.revisiond.plist -> this exits revisiond, and prevents launchd from respawning it. After that, the problem is gone, on several attempts. And once I reactivate revisions, the problem reoccurs. So it seems pretty clear what the cause of this is. Now I still need to figure out why it affects that particular repository and not others. But at this point I guess it is safe to say that Apple's auto-crap-magic revisiond is the root of the problem, and git is purely a victim. So I'll stop spamming this list with this issue for now, and see if I can figure out a fix that is less invasive than turning off revisiond completely (which some application rely on, so disabling it may break them badly). Andrew, thank you very much for your persistent guidance and help. I definitely owe you a beverage-of-your-choice ;-). Cheers, Max-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rebase: strange failures to apply patc 3-way
On Mon, Mar 11, 2013 at 8:29 PM, Max Horn wrote: [snip] > > sudo launchctl unload /System/Library/LaunchDaemons/com.apple.revisiond.plist > > -> this exits revisiond, and prevents launchd from respawning it. After that, > the problem is gone, on several attempts. And once I reactivate revisions, > the problem reoccurs. > > So it seems pretty clear what the cause of this is. Now I still need to > figure out why it affects that particular repository and not others. But at > this point I guess it is safe to say that Apple's auto-crap-magic revisiond > is the root of the problem, and git is purely a victim. So I'll stop spamming > this list with this issue for now, and see if I can figure out a fix that is > less invasive than turning off revisiond completely (which some application > rely on, so disabling it may break them badly). I just wanted to say thank you for spamming the list with this. I've not upgraded to a new Mac OS X yet, but now I know I need to watch out for this issue. I'm glad you were able to get to the bottom of it, and I'd love to hear if you find a reasonable solution. -John -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Make help behaviour more consistent
On 11/03/2013 05:03, Junio C Hamano wrote: Hmm, I feel more confused than convinced after reading the above three times. Perhaps that is because I am too used to the way how "git" potty itself behaves, especially the part that "git help git" is the way to ask "git" (the first token on the command line) to give me "help" about "git" (the second) itself. But you are nowhere told that "git help" will give you information on any topic other than Git commands. Starting from just typing "git", all you are told is that you can type "git help ". Given that information, you could at least logically deduce that "git help help" will give you help on "git help". (Not that it would help anyway - even git-help.txt doesn't say that you can specify anything other than a Git command, like "git" or "cli". But sounds like Philip's already on there case there). If you can figure out "man git" for yourself (and if it's available - Windows?) then from there you're explicitly told how to directly access all the other docs using man itself, including gitrevisions(7), etc. And having gotten to "man gitrevisions", I figured out that "git help revisions" could get to the HTML equivalent. Not documented, but at least fits the pattern, give or take a hyphen. But I never figured out "git help git", until I read the source. Why do I need to add the extra "git" to the help command for that page, and that page only? "git" isn't a Git command, and there's no "man gitgit" topic! Even if I explicitly try to point explicitly that I want a web page with "git help -w", I don't get it... I think at the very minimum you need to make it explicitly clear right up front that "git help git" is available: See 'git help git' for more information on Git See 'git help ' for more information on a specific command. Seems ugly though. I'm at a loss to understand why "git help", the manual launching command, shouldn't by default simply launch the root of the manual tree, rather than replicate the behaviour of "git"/"git --help". And something needs to be done to advertise the general existence of usage on commands. "-h" is currently hidden on page 4 of "man gitcli". (Is it anywhere else?) I've managed to avoid finding out about it for years! Checking a few people around me, none of them knew about it either. At the minute "git" tells you about "git --help", which shows usage, but "git add --help" launches the manual. (Huh?) Given that, I always assumed there was no usage available for individual commands - if there was usage, surely it would be there on --help, like on "git". Never occurred to me it would be there under "-h" instead. So how about going further than that patch, and making it even simpler. Collapse --help and -h to be synonyms. Then under either spelling, --help|-h always shows usage for "git" or "git ", as per GNU guidelines. Then the manual launch only happens for "git help ..." and, "git help" on its own launches the root. And the output of "git [--help]" ends with: See 'git help []' for more information. Kevin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rebase: strange failures to apply patc 3-way
On Tue, Mar 12, 2013 at 01:29:45AM +0100, Max Horn wrote: > So it seems pretty clear what the cause of this is. Now I still need > to figure out why it affects that particular repository and not > others. But at this point I guess it is safe to say that Apple's > auto-crap-magic revisiond is the root of the problem, and git is > purely a victim. So I'll stop spamming this list with this issue for > now, and see if I can figure out a fix that is less invasive than > turning off revisiond completely (which some application rely on, so > disabling it may break them badly). >From "git help config": core.trustctime If false, the ctime differences between the index and the working tree are ignored; useful when the inode change time is regularly modified by something outside Git (file system crawlers and some backup systems). See git-update- index(1). True by default. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rebase: strange failures to apply patc 3-way
On 03/11/13 20:29, Max Horn wrote: > sudo launchctl unload /System/Library/LaunchDaemons/com.apple.revisiond.plist > > -> this exits revisiond, and prevents launchd from respawning it. After that, > the problem is gone, on several attempts. And once I reactivate revisions, > the problem reoccurs. > > So it seems pretty clear what the cause of this is. Now I still need to > figure out why it affects that particular repository and not others. But at > this point I guess it is safe to say that Apple's auto-crap-magic revisiond > is the root of the problem, and git is purely a victim. So I'll stop spamming > this list with this issue for now, and see if I can figure out a fix that is > less invasive than turning off revisiond completely (which some application > rely on, so disabling it may break them badly). > > Andrew, thank you very much for your persistent guidance and help. I > definitely owe you a beverage-of-your-choice ;-). Awesome! I was starting to worry that we'd never figure out what the issue is. Good thing you know your way around OS X and its debugging tools. :) Maybe drop an email if you figure out what's causing revisiond to be so persistent about those specific files. Might help any who run into similar issues in the future. Cheers! -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rebase: strange failures to apply patc 3-way
On 03/11/13 21:01, Jeff King wrote: > From "git help config": > > core.trustctime > If false, the ctime differences between the index and the working > tree are ignored; useful when the inode change time is regularly > modified by something outside Git (file system crawlers and some > backup systems). See git-update- index(1). True by default. In an earlier email, Max did mention setting the config does workaround the issue. But it's still strange that it only happens to a few specific files in this particular repo. The issue never popped up in other repos that he has, which I assume has all been excluded from Time Machine... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rebase: strange failures to apply patc 3-way
On Mon, Mar 11, 2013 at 09:03:42PM -0400, Andrew Wong wrote: > On 03/11/13 21:01, Jeff King wrote: > > From "git help config": > > > > core.trustctime > > If false, the ctime differences between the index and the working > > tree are ignored; useful when the inode change time is regularly > > modified by something outside Git (file system crawlers and some > > backup systems). See git-update- index(1). True by default. > > In an earlier email, Max did mention setting the config does workaround > the issue. But it's still strange that it only happens to a few specific > files in this particular repo. The issue never popped up in other repos > that he has, which I assume has all been excluded from Time Machine... Ah, sorry, I missed the earlier reference to it. trustctime is the only sensible thing to do from the git side. I think figuring out the rest is deep Apple magic that I'm not qualified to comment on. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ZSH segmentation fault while completing "git mv dir/"
If it's dependent on eval "`dircolors`", it suggests it might be dependent on the size of the environment. Maybe try with FOO=`perl -e 'print "x"x1000'` for various values of 1000... Jeff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git files from another branch in a separate repository
I'm currently working on a git project( vwf - virtualworldframework ), and we need to get a couple of files from another repository( threes ). We've forked threejs into our repository, but I need to be able to grab only those few files that I need. I thought I wanted to do a sub-tree merge, but after reading about the -tree options, I don't think that is what I need to do. Do I want to right a hook script to pull in those files? TIA, Scott-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
