* Re: [PATCH 2/2] add: add a newline at the end of pathless 'add [-u|-A]' warning
From: Junio C Hamano @ 2013-03-11 16:06 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1362988893-27539-2-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> 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 <Matthieu.Moy@imag.fr>
> ---
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 >>t0000*.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/t0000-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);
^ permalink raw reply
* A bug or unhandled case
From: Michał Janiszewski @ 2013-03-11 16:06 UTC (permalink / raw)
To: git
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"
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
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:
# remotes/bar/test_branch 8b96ffe evil commit
# trying to remove that branch yields no results:
$ git branch -D refs/remotes/bar/test_branch
error: branch 'refs/remotes/bar/test_branch' not found.
$ git branch -D remotes/bar/test_branch
error: branch 'remotes/bar/test_branch' not found.
$ git branch -D bar/test_branch
error: branch 'bar/test_branch' not found.
$ git branch -D test_branch
error: branch 'test_branch' not found.
git gc --prune=now
# also does nothing
The only way to remove that branch is to:
cd ../foo
git push baz :bar/test_branch
Shouldn't someone who owns bare repository be able to delete that kind
of branches as he is able to do with "regular" branches?
--
Michal Janiszewski
^ permalink raw reply
* Re: Rewriting references to existing commits in commit messages with filter-branch
From: Vadim Zeitlin @ 2013-03-11 15:58 UTC (permalink / raw)
To: git
In-Reply-To: <87y5dut72l.fsf@pctrast.inf.ethz.ch>
Thomas Rast <trast <at> student.ethz.ch> writes:
>
> Vadim Zeitlin <vz-git <at> zeitlins.org> writes:
>
> > Lawrence Mitchell <wence <at> 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 rNNNNN, which included commits
to RCS files with non-trunk default branches.") and replacing "rNNNNN" with "the
previous commit" in this particular case in order to avoid the problem.
Thanks again for your help!
VZ
^ permalink raw reply
* Re: ZSH segmentation fault while completing "git mv dir/"
From: Matthieu Moy @ 2013-03-11 15:37 UTC (permalink / raw)
To: Manlio Perillo; +Cc: git, felipe.contreras
In-Reply-To: <513DF4D1.6000500@gmail.com>
Manlio Perillo <manlio.perillo@gmail.com> 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/
^ permalink raw reply
* Re: ZSH segmentation fault while completing "git mv dir/"
From: Manlio Perillo @ 2013-03-11 15:14 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, felipe.contreras
In-Reply-To: <vpqd2v686fi.fsf@grenoble-inp.fr>
-----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-----
^ permalink raw reply
* Re: [PATCH v2 0/6] Exclude optimizations
From: Duy Nguyen @ 2013-03-11 15:11 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1362896070-17456-1-git-send-email-pclouds@gmail.com>
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
real 0m0.372s
user 0m0.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
^ permalink raw reply
* Re: Textconv
From: Michael J Gruber @ 2013-03-11 14:40 UTC (permalink / raw)
To: Dmitry Ilin; +Cc: Matthieu Moy, git
In-Reply-To: <513DC04D.9090904@mylovecompany.com>
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 <dmitry@mylovecompany.com> 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 <some-relevant-commit>
>>
>> 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
^ permalink raw reply
* Re: Rewriting references to existing commits in commit messages with filter-branch
From: Vadim Zeitlin @ 2013-03-11 14:05 UTC (permalink / raw)
To: git
In-Reply-To: <513DE1E8.7010302@alum.mit.edu>
Michael Haggerty <mhagger <at> 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
^ permalink raw reply
* Re: Rewriting references to existing commits in commit messages with filter-branch
From: Michael Haggerty @ 2013-03-11 13:53 UTC (permalink / raw)
To: Vadim Zeitlin; +Cc: git
In-Reply-To: <E1UF1Ag-0006m3-5k@smtp.tt-solutions.com>
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
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Rewriting references to existing commits in commit messages with filter-branch
From: Thomas Rast @ 2013-03-11 13:11 UTC (permalink / raw)
To: Vadim Zeitlin; +Cc: git
In-Reply-To: <loom.20130311T131746-169@post.gmane.org>
Vadim Zeitlin <vz-git@zeitlins.org> writes:
> Lawrence Mitchell <wence <at> 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
^ permalink raw reply
* ZSH segmentation fault while completing "git mv dir/"
From: Matthieu Moy @ 2013-03-11 12:30 UTC (permalink / raw)
To: git; +Cc: manlio.perillo, felipe.contreras
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/
^ permalink raw reply
* Re: Rewriting references to existing commits in commit messages with filter-branch
From: Vadim Zeitlin @ 2013-03-11 12:23 UTC (permalink / raw)
To: git
In-Reply-To: <87haki2la2.fsf@gmx.li>
Lawrence Mitchell <wence <at> 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
^ permalink raw reply
* [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
From: Matthieu Moy @ 2013-03-11 12:21 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
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 <Matthieu.Moy@imag.fr>
---
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
^ permalink raw reply related
* Re: Rewriting references to existing commits in commit messages with filter-branch
From: Lawrence Mitchell @ 2013-03-11 12:06 UTC (permalink / raw)
To: git
In-Reply-To: <E1UF1Ag-0006m3-5k@smtp.tt-solutions.com>
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 <wence@gmx.li>
^ permalink raw reply
* Rewriting references to existing commits in commit messages with filter-branch
From: Vadim Zeitlin @ 2013-03-11 11:45 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1588 bytes --]
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
[-- Attachment #2: Type: APPLICATION/PGP-SIGNATURE, Size: 196 bytes --]
^ permalink raw reply
* Re: [PATCH v2 05/23] contrib/subtree: Add commands pull_all and push_all
From: Paul Campbell @ 2013-03-11 11:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Greene
In-Reply-To: <7vk3pebkac.fsf@alter.siamese.dyndns.org>
On Mon, Mar 11, 2013 at 5:03 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Paul Campbell <pcampbell@kemitix.net> writes:
>
>> From: bibendi <bibendi@bk.ru>
>>
>> For each subtree listed in .gittrees perform a push or a pull.
>>
>> Signed-off-by: Paul Campbell <pcampbell@kemitix.net>
>>
>> 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=<prefix> <commit>
>> git subtree add --prefix=<prefix> <repository> <commit>
>> git subtree merge --prefix=<prefix> <commit>
>> git subtree pull --prefix=<prefix> <repository> <refspec...>
>> +git subtree pull_all
>
> Why isn't it "pull --all"?
>
>> git subtree push --prefix=<prefix> <repository> <refspec...>
>
> 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
^ permalink raw reply
* Re: Textconv
From: Dmitry Ilin @ 2013-03-11 11:30 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqd2v6b4n5.fsf@grenoble-inp.fr>
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 <dmitry@mylovecompany.com> 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 <some-relevant-commit>
>
> to see what's going on?
>
^ permalink raw reply
* Re: Textconv
From: Matthieu Moy @ 2013-03-11 10:41 UTC (permalink / raw)
To: Dmitry Ilin; +Cc: git
In-Reply-To: <513DB273.2090007@mylovecompany.com>
Dmitry Ilin <dmitry@mylovecompany.com> 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 <some-relevant-commit>
to see what's going on?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Textconv
From: Dmitry Ilin @ 2013-03-11 10:31 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqtxoicl2l.fsf@grenoble-inp.fr>
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 <dmitry@mylovecompany.com> 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.
>
^ permalink raw reply
* Re: Textconv
From: Matthieu Moy @ 2013-03-11 10:00 UTC (permalink / raw)
To: Dmitry Ilin; +Cc: git
In-Reply-To: <513DA7E1.7050206@mylovecompany.com>
Dmitry Ilin <dmitry@mylovecompany.com> 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/
^ permalink raw reply
* Textconv
From: Dmitry Ilin @ 2013-03-11 9:46 UTC (permalink / raw)
To: git
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?
^ permalink raw reply
* Re: thomas sabo uk have an impact on the particular economic system
From: yj1124 @ 2013-03-11 9:41 UTC (permalink / raw)
To: git
In-Reply-To: <1353479669151-7571657.post@n2.nabble.com>
Louis Tiffany had been additionally the complete minds at the rear of
allegedly the a lot of acclaimed
http://hottiffany4u.com/goods-70-Tiffany-Co-Outlet-Stack-Silver-Bangle.htmltiffany
somersettm wide angle in sterling silver medium designs, such as Tiffany
bedimmed cup lampshades. Aural 1940, Tiffany as able as Accretion relocated
through Broadway in acclimation to it's acclaimed beside beyond from 5th
Acclimation as able as 57th Road aural New york. The complete appellation
Tiffany & Company. is in actuality accompanying to archetypal as able as
adequate adequate products. These days, top of Tiffany's accretion arrives
via annual as able as online achievement sales, that acquire assisted bear
the complete Tiffany casting all over the angel as able as created the
complete activate accepting a bit of Tiffany jewellery attainable wherever
you reside.
--
View this message in context: http://git.661346.n2.nabble.com/thomas-sabo-uk-have-an-impact-on-the-particular-economic-system-tp7571657p7579400.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH/RFC] Make help behaviour more consistent
From: Matthieu Moy @ 2013-03-11 8:13 UTC (permalink / raw)
To: Kevin Bracey; +Cc: git
In-Reply-To: <1362937729-9050-1-git-send-email-kevin@bracey.fi>
Kevin Bracey <kevin@bracey.fi> 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/
^ permalink raw reply
* [PATCH 2/2] add: add a newline at the end of pathless 'add [-u|-A]' warning
From: Matthieu Moy @ 2013-03-11 8:01 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1362988893-27539-1-git-send-email-Matthieu.Moy@imag.fr>
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 <Matthieu.Moy@imag.fr>
---
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
^ permalink raw reply related
* [PATCH 1/2] add: update pathless 'add [-u|-A]' warning to reflect change of plan
From: Matthieu Moy @ 2013-03-11 8:01 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <vpqk3pefjs4.fsf@grenoble-inp.fr>
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 <Matthieu.Moy@imag.fr>
---
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
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox