* Re: [PATCH] git.c: make usage match manual page
From: Kevin Bracey @ 2013-03-11 20:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vli9t909a.fsf@alter.siamese.dyndns.org>
On 11/03/2013 21:58, Junio C Hamano wrote:
> Kevin Bracey <kevin@bracey.fi> 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 "<options>" 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
^ permalink raw reply
* [RFC/PATCH] submodule: allow common rewind when merging submodules
From: Heiko Voigt @ 2013-03-11 20:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Bratell, git, Jens Lehmann
In-Reply-To: <20130310170953.GA1248@sandbox-ub.fritz.box>
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 <hvoigt@hvoigt.net>
---
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;
}
- /* check whether both changes are forward */
- if (!in_merge_bases(commit_base, commit_a) ||
- !in_merge_bases(commit_base, commit_b)) {
+ if (!commits_follow_merge_base(commit_base, commit_a, commit_b)) {
MERGE_WARNING(path, "commits don't follow merge-base");
return 0;
}
diff --git a/t/t7405-submodule-merge.sh b/t/t7405-submodule-merge.sh
index 0d5b42a..66520c6 100755
--- a/t/t7405-submodule-merge.sh
+++ b/t/t7405-submodule-merge.sh
@@ -60,7 +60,7 @@ test_expect_success setup '
# / \
# init -- a d
# \ \ /
-# g c
+# g c---h
#
# a in the main repository records to sub-a in the submodule and
# analogous b and c. d should be automatically found by merging c into
@@ -109,7 +109,17 @@ test_expect_success 'setup for merge search' '
(cd sub &&
git checkout -b sub-g sub-c) &&
git add sub &&
- git commit -a -m "g")
+ git commit -a -m "g" &&
+
+ git checkout -b h c &&
+ (cd sub &&
+ git checkout -b sub-h sub-c &&
+ echo "file-h" >file-h &&
+ git add file-h &&
+ git commit -m "sub-h") &&
+ git add sub &&
+ git commit -a -m "h"
+ )
'
test_expect_success 'merge with one side as a fast-forward of the other' '
@@ -146,6 +156,31 @@ test_expect_success 'merging should fail for ambiguous common parent' '
git reset --hard)
'
+test_expect_success 'merging should succeed with common rewind' '
+ (cd merge-search &&
+ git checkout -b common-rewind-base init &&
+ (cd sub &&
+ git checkout sub-b
+ ) &&
+ git add sub &&
+ git commit -m "common-rewind-base" &&
+ git checkout -b common-rewind-a common-rewind-base &&
+ (cd sub &&
+ git checkout sub-c
+ ) &&
+ git add sub &&
+ git commit -m "common-rewind-a" &&
+ git checkout -b common-rewind-b common-rewind-base &&
+ (cd sub &&
+ git checkout sub-h
+ ) &&
+ git add sub &&
+ git commit -m "common-rewind-b" &&
+ git checkout -b common-rewind-merge common-rewind-a &&
+ git merge common-rewind-b
+ )
+'
+
# in a situation like this
#
# submodule tree:
--
1.8.2.rc2.5.gab0ecbc
^ permalink raw reply related
* Re: [PATCH] git.c: make usage match manual page
From: Junio C Hamano @ 2013-03-11 19:58 UTC (permalink / raw)
To: Kevin Bracey; +Cc: git
In-Reply-To: <1363031055-13562-1-git-send-email-kevin@bracey.fi>
Kevin Bracey <kevin@bracey.fi> 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 <kevin@bracey.fi>
> ---
> 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[=<path>]] [--html-path] [--man-path] [--info-path]\n"
> + "git [--version] [--help] [-c name=value]\n"
> + " [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]\n"
> " [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]\n"
> " [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]\n"
> - " [-c name=value] [--help]\n"
> " <command> [<args>]";
>
> const char git_more_info_string[] =
^ permalink raw reply
* [PATCH] git.c: make usage match manual page
From: Kevin Bracey @ 2013-03-11 19:44 UTC (permalink / raw)
To: git; +Cc: Kevin Bracey
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 <kevin@bracey.fi>
---
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[=<path>]] [--html-path] [--man-path] [--info-path]\n"
+ "git [--version] [--help] [-c name=value]\n"
+ " [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]\n"
" [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]\n"
" [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]\n"
- " [-c name=value] [--help]\n"
" <command> [<args>]";
const char git_more_info_string[] =
--
1.8.2.rc3.7.g1100d09.dirty
^ permalink raw reply related
* Re: ZSH segmentation fault while completing "git mv dir/"
From: Manlio Perillo @ 2013-03-11 19:33 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, felipe.contreras
In-Reply-To: <vpq8v5uueug.fsf@grenoble-inp.fr>
-----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-----
^ permalink raw reply
* Re: Proposal: sharing .git/config
From: Ramkumar Ramachandra @ 2013-03-11 19:31 UTC (permalink / raw)
To: Jeff King; +Cc: Duy Nguyen, Git List
In-Reply-To: <20130219153600.GA5338@sigill.intra.peff.net>
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
>> <artagnon@gmail.com> wrote:
>> > Hi,
>> >
>> > I have this itch where I want to share my remotes config between
>> > machines. In my fork, I should be able to specify where my upstream
>> > sources are, so remotes get set up automatically when I clone. There
>> > are also other things in .git/config that would be nice to share, like
>> > whether to do a --word-diff (why isn't it a configuration variable
>> > yet?) on the repository. The only problem is that I have no clue how
>> > to implement this: I'm currently thinking a special remote ref?
>>
>> If you check out the config file, then include.path should work. You
>> could add include.ref to point to a ref, but you need to deal with the
>> attached security implications. This has been proposed before (and
>> turned down, I think).
>
> Here's the patch:
>
> http://article.gmane.org/gmane.comp.version-control.git/189144
>
> The basic argument against it is that you would _not_ want to do:
>
> $ git config include.ref origin/config
>
> because it's unsafe (you immediately start using config fetched from the
> remote, before you even get a chance to inspect it). So the recommended
> way to use it is:
>
> $ git config include.ref config
> $ git show origin/config ;# make sure it looks reasonable
> $ git update-ref refs/config origin/config
>
> [time passes...]
>
> $ git fetch
> $ git diff config origin/config ;# inspect changes
> $ git update-ref refs/config origin/config
>
> But it was pointed out that you could also just do:
>
> $ git config include.ref upstream-config
> $ git show origin/config ;# make sure it looks reasonable
> $ git show origin/config >.git/upstream-config
>
> and so forth. There are some ways that a pure ref can be more
> convenient (e.g., if you are carrying local changes on top of the
> upstream config and want to merge), but ultimately, you can replicate
> any include.ref workflow with include.path by adding a "deploy" step
> where you copy the file into $GIT_DIR.
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?
^ permalink raw reply
* Re: rebase: strange failures to apply patc 3-way
From: Andrew Wong @ 2013-03-11 19:15 UTC (permalink / raw)
To: Max Horn; +Cc: git@vger.kernel.org
In-Reply-To: <C79E1B20-2C42-49FF-A964-285A7049FDED@quendi.de>
On 3/10/13, Max Horn <max@quendi.de> 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".
^ permalink raw reply
* Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
From: Manlio Perillo @ 2013-03-11 19:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7vwqtd95bm.fsf@alter.siamese.dyndns.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 11/03/2013 19:09, Junio C Hamano ha scritto:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Junio C Hamano <gitster@pobox.com> 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-----
^ permalink raw reply
* Re: [PATCH/RFC] Make help behaviour more consistent
From: Junio C Hamano @ 2013-03-11 19:02 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Kevin Bracey, git
In-Reply-To: <vpq620yfj6g.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> 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 sounds like a good direction to go in.
^ permalink raw reply
* Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
From: Paul Smith @ 2013-03-11 18:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, Manlio Perillo, git
In-Reply-To: <7vwqtd95bm.fsf@alter.siamese.dyndns.org>
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.
^ permalink raw reply
* Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
From: Junio C Hamano @ 2013-03-11 18:09 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Manlio Perillo, git
In-Reply-To: <vpqppz5u8te.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Junio C Hamano <gitster@pobox.com> 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.
^ permalink raw reply
* Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
From: Matthieu Moy @ 2013-03-11 17:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Manlio Perillo, git
In-Reply-To: <7v8v5talzu.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> 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/
^ permalink raw reply
* Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
From: Junio C Hamano @ 2013-03-11 17:23 UTC (permalink / raw)
To: Manlio Perillo; +Cc: Matthieu Moy, git
In-Reply-To: <513E0FB4.40607@gmail.com>
Manlio Perillo <manlio.perillo@gmail.com> 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 <Matthieu.Moy@imag.fr>
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 <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
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
^ permalink raw reply related
* Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
From: Manlio Perillo @ 2013-03-11 17:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7vfw01an1b.fsf@alter.siamese.dyndns.org>
-----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 <cmd> *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-----
^ permalink raw reply
* Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
From: Manlio Perillo @ 2013-03-11 17:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7v38w1c3ms.fsf@alter.siamese.dyndns.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 11/03/2013 17:17, Junio C Hamano ha scritto:
> Matthieu Moy <Matthieu.Moy@imag.fr> 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 <Matthieu.Moy@imag.fr>
>> ---
>
> 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-----
^ permalink raw reply
* Re: [RFC/PATCH] Documentation/technical/api-fswatch.txt: start with outline
From: Heiko Voigt @ 2013-03-11 17:05 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Git List, Duy Nguyen, Junio C Hamano, Torsten Bögershausen,
Robert Zeh, Jeff King, Erik Faye-Lund, Karsten Blees,
Drew Northup
In-Reply-To: <1362946623-23649-1-git-send-email-artagnon@gmail.com>
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. time by number
> ----------------------------------------------
> 0.401906 40950 lstat 0.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
^ permalink raw reply
* Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
From: Junio C Hamano @ 2013-03-11 17:01 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Manlio Perillo
In-Reply-To: <vpqtxohubmb.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Junio C Hamano <gitster@pobox.com> 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).
^ permalink raw reply
* Re: A bug or unhandled case
From: Junio C Hamano @ 2013-03-11 16:53 UTC (permalink / raw)
To: Michał Janiszewski; +Cc: git
In-Reply-To: <CABB6UqHgcsx9oK2GHhmwpuhv+T3aMAJk_udw8enkGB3OutzbNg@mail.gmail.com>
Michał Janiszewski <janisozaur@gmail.com> 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.
^ permalink raw reply
* Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
From: Matthieu Moy @ 2013-03-11 16:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Manlio Perillo
In-Reply-To: <7vobepany3.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> 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/
^ permalink raw reply
* Re: [PATCH/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well
From: Heiko Voigt @ 2013-03-11 16:46 UTC (permalink / raw)
To: Jens Lehmann
Cc: Phil Hord, Junio C Hamano, Eric Cousineau, git@vger.kernel.org
In-Reply-To: <513B7D08.20406@web.de>
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}'
> > <up><home><del>{30-ish}<end><backspace><enter>
> >
> > 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
^ permalink raw reply
* Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
From: Junio C Hamano @ 2013-03-11 16:41 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Manlio Perillo
In-Reply-To: <7v38w1c3ms.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> 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 <Matthieu.Moy@imag.fr>
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 <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
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
^ permalink raw reply related
* Re: A bug or unhandled case
From: Michał Janiszewski @ 2013-03-11 16:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvc8xaoia.fsf@alter.siamese.dyndns.org>
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 <gitster@pobox.com> wrote:
> Michał Janiszewski <janisozaur@gmail.com> 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
^ permalink raw reply
* Re: A bug or unhandled case
From: Junio C Hamano @ 2013-03-11 16:29 UTC (permalink / raw)
To: Michał Janiszewski; +Cc: git
In-Reply-To: <CABB6UqEfx=ssbiD1+2HA3AtmSrFeJeg5fmU3z1SKukNsKvd4qw@mail.gmail.com>
Michał Janiszewski <janisozaur@gmail.com> 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
^ permalink raw reply
* Re: [RFC/PATCH] git-completion.bash: remove bashism to fix ZSH compatibility
From: Junio C Hamano @ 2013-03-11 16:17 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Manlio Perillo
In-Reply-To: <1363004487-1193-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> 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 <Matthieu.Moy@imag.fr>
> ---
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).
^ permalink raw reply
* 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
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