* Re: [PATCH] Move api-command.txt to the end of API list in api-index.txt
From: Junio C Hamano @ 2012-12-16 20:01 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: git
In-Reply-To: <1702872710.62174.1355660592713.JavaMail.ngmail@webmail12.arcor-online.net>
Thomas Ackermann <th.acker@arcor.de> writes:
> - because it describes a different form of API than the other api-* documents
Drop that "- "; it is not like you are enumerating many reasons.
It makes me wonder if a more correct "fix" is to move this document
to the ../howto/ hierarchy.
>
> Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
> ---
> Documentation/technical/api-index.sh | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/technical/api-index.sh b/Documentation/technical/api-index.sh
> index 9c3f413..c2c68ed 100755
> --- a/Documentation/technical/api-index.sh
> +++ b/Documentation/technical/api-index.sh
> @@ -10,12 +10,16 @@
> while read filename
> do
> case "$filename" in
> - api-index-skel.txt | api-index.txt) continue ;;
> + api-index-skel.txt | api-index.txt | api-command.txt) continue ;;
> esac
> title=$(sed -e 1q "$filename")
> html=${filename%.txt}.html
> echo "* link:$html[$title]"
> done
> + filename=api-command.txt
> + title=$(sed -e 1q "$filename")
> + html=${filename%.txt}.html
> + echo "* link:$html[$title]"
> echo "$c"
> sed -n -e '/^\/\/ table of contents end/,$p' "$skel"
> ) >api-index.txt+
^ permalink raw reply
* [PATCH] git-completion.bash: add support for path completion
From: Manlio Perillo @ 2012-12-16 21:24 UTC (permalink / raw)
To: git; +Cc: Manlio Perillo
The git-completion.bash script did not implemented full support for
completion, for git commands that operate on files from the current
working directory or the index.
For these commands, only options completion was available.
Full support for completion is now implemented, for git commands where
the non-option arguments always refer to paths on the current working
directory or the index, as the follow:
* the path completion for the "git mv" and "git rm" commands is provided
using "git ls-files --exclude-standard"
* the path completion for the "git add" command is provided using
"git ls-files --exclude-standard -o -m"
* the path completion for the "git clean" command is provided using
"git ls-files --exclude-standard -o"
* the path completion for the "git commit" command is provides using
"git diff-index --name-only HEAD"
Signed-off-by: Manlio Perillo <manlio.perillo@gmail.com>
---
contrib/completion/git-completion.bash | 39 ++++++++++++++++++++++------------
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0b77eb1..8b348c3 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -233,6 +233,25 @@ __gitcomp_nl ()
COMPREPLY=($(compgen -P "${2-}" -S "${4- }" -W "$1" -- "${3-$cur}"))
}
+__git_files ()
+{
+ local dir="$(__gitdir)"
+ if [ -d "$dir" ]; then
+ git --git-dir="$dir" ls-files --exclude-standard $*
+ return
+ fi
+}
+
+# Return all staged files with modification from current HEAD
+__git_commit_files ()
+{
+ local dir="$(__gitdir)"
+ if [ -d "$dir" ]; then
+ git --git-dir="$dir" diff-index --name-only HEAD
+ return
+ fi
+}
+
__git_heads ()
{
local dir="$(__gitdir)"
@@ -770,8 +789,6 @@ _git_apply ()
_git_add ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "
@@ -780,7 +797,8 @@ _git_add ()
"
return
esac
- COMPREPLY=()
+ # XXX should we care for --update and --all options ?
+ __gitcomp_nl "$(__git_files -o -m)" "" "$cur" ""
}
_git_archive ()
@@ -930,15 +948,14 @@ _git_cherry_pick ()
_git_clean ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "--dry-run --quiet"
return
;;
esac
- COMPREPLY=()
+ # TODO: check for -x option
+ __gitcomp_nl "$(__git_files -o)" "" "$cur" ""
}
_git_clone ()
@@ -969,8 +986,6 @@ _git_clone ()
_git_commit ()
{
- __git_has_doubledash && return
-
case "$cur" in
--cleanup=*)
__gitcomp "default strip verbatim whitespace
@@ -998,7 +1013,7 @@ _git_commit ()
"
return
esac
- COMPREPLY=()
+ __gitcomp_nl "$(__git_commit_files)" "" "$cur" ""
}
_git_describe ()
@@ -1362,7 +1377,7 @@ _git_mv ()
return
;;
esac
- COMPREPLY=()
+ __gitcomp_nl "$(__git_files)" "" "$cur" ""
}
_git_name_rev ()
@@ -2068,15 +2083,13 @@ _git_revert ()
_git_rm ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "--cached --dry-run --ignore-unmatch --quiet"
return
;;
esac
- COMPREPLY=()
+ __gitcomp_nl "$(__git_files)" "" "$cur" ""
}
_git_shortlog ()
--
1.8.1.rc1.18.g9db0d25
^ permalink raw reply related
* [PATCH] git-completion.bash: update obsolete code.
From: Manlio Perillo @ 2012-12-16 21:50 UTC (permalink / raw)
To: git; +Cc: Manlio Perillo
The git-completion.bash script was using the git ls-tree command
without the --name-only option, with a sed filter to parse path names;
use the --name-only option, instead.
Signed-off-by: Manlio Perillo <manlio.perillo@gmail.com>
---
contrib/completion/git-completion.bash | 15 +--------------
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0b77eb1..85d9051 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -397,20 +397,7 @@ __git_complete_revlist_file ()
*) pfx="$ref:$pfx" ;;
esac
- __gitcomp_nl "$(git --git-dir="$(__gitdir)" ls-tree "$ls" \
- | sed '/^100... blob /{
- s,^.* ,,
- s,$, ,
- }
- /^120000 blob /{
- s,^.* ,,
- s,$, ,
- }
- /^040000 tree /{
- s,^.* ,,
- s,$,/,
- }
- s/^.* //')" \
+ __gitcomp_nl "$(git --git-dir="$(__gitdir)" ls-tree --name-only "$ls")" \
"$pfx" "$cur_" ""
;;
*...*)
--
1.8.1.rc1.18.g9db0d25
^ permalink raw reply related
* [PATCH v2] git-completion.bash: add support for path completion
From: Manlio Perillo @ 2012-12-16 22:20 UTC (permalink / raw)
To: git; +Cc: Manlio Perillo
The git-completion.bash script did not implemented full support for
completion, for git commands that operate on files from the current
working directory or the index.
For these commands, only options completion was available.
Full support for completion is now implemented, for git commands where
the non-option arguments always refer to paths on the current working
directory or the index, as the follow:
* the path completion for the "git mv" and "git rm" commands is provided
using "git ls-files --exclude-standard"
* the path completion for the "git add" command is provided using
"git ls-files --exclude-standard -o -m"
* the path completion for the "git clean" command is provided using
"git ls-files --exclude-standard -o"
* the path completion for the "git commit" command is provides using
"git diff-index --name-only HEAD"
Signed-off-by: Manlio Perillo <manlio.perillo@gmail.com>
---
Updated the script documentation.
contrib/completion/git-completion.bash | 40 +++++++++++++++++++++++-----------
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0b77eb1..3bd7fc8 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -13,6 +13,7 @@
# *) .git/remotes file names
# *) git 'subcommands'
# *) tree paths within 'ref:path/to/file' expressions
+# *) working directory and index file names
# *) common --long-options
#
# To use these routines:
@@ -233,6 +234,25 @@ __gitcomp_nl ()
COMPREPLY=($(compgen -P "${2-}" -S "${4- }" -W "$1" -- "${3-$cur}"))
}
+__git_files ()
+{
+ local dir="$(__gitdir)"
+ if [ -d "$dir" ]; then
+ git --git-dir="$dir" ls-files --exclude-standard $*
+ return
+ fi
+}
+
+# Return all staged files with modification from current HEAD
+__git_commit_files ()
+{
+ local dir="$(__gitdir)"
+ if [ -d "$dir" ]; then
+ git --git-dir="$dir" diff-index --name-only HEAD
+ return
+ fi
+}
+
__git_heads ()
{
local dir="$(__gitdir)"
@@ -770,8 +790,6 @@ _git_apply ()
_git_add ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "
@@ -780,7 +798,8 @@ _git_add ()
"
return
esac
- COMPREPLY=()
+ # XXX should we care for --update and --all options ?
+ __gitcomp_nl "$(__git_files -o -m)" "" "$cur" ""
}
_git_archive ()
@@ -930,15 +949,14 @@ _git_cherry_pick ()
_git_clean ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "--dry-run --quiet"
return
;;
esac
- COMPREPLY=()
+ # TODO: check for -x option
+ __gitcomp_nl "$(__git_files -o)" "" "$cur" ""
}
_git_clone ()
@@ -969,8 +987,6 @@ _git_clone ()
_git_commit ()
{
- __git_has_doubledash && return
-
case "$cur" in
--cleanup=*)
__gitcomp "default strip verbatim whitespace
@@ -998,7 +1014,7 @@ _git_commit ()
"
return
esac
- COMPREPLY=()
+ __gitcomp_nl "$(__git_commit_files)" "" "$cur" ""
}
_git_describe ()
@@ -1362,7 +1378,7 @@ _git_mv ()
return
;;
esac
- COMPREPLY=()
+ __gitcomp_nl "$(__git_files)" "" "$cur" ""
}
_git_name_rev ()
@@ -2068,15 +2084,13 @@ _git_revert ()
_git_rm ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "--cached --dry-run --ignore-unmatch --quiet"
return
;;
esac
- COMPREPLY=()
+ __gitcomp_nl "$(__git_files)" "" "$cur" ""
}
_git_shortlog ()
--
1.8.1.rc1.18.g9db0d25
^ permalink raw reply related
* compiler checks
From: Adam Spiers @ 2012-12-16 23:04 UTC (permalink / raw)
To: git list
In-Reply-To: <7vehlv5hg8.fsf@alter.siamese.dyndns.org>
On Fri, Sep 21, 2012 at 12:00:55PM -0700, Junio C Hamano wrote:
> Adam Spiers <git@adamspiers.org> writes:
>
> > It has been rebased on the latest master, and passed a full test run.
>
> FYI, I applied the attached on top before queuing it in 'pu'.
>
> Points to note:
>
> * We match the underline and the title of documentation header;
>
> * a few type mismatches (constness of full_path and treat_gitlink()
> signature) that broke compilation;
Of course I will incorporate these tweaks in my re-roll, but it
worries me that my environment yielded no compilation issues even
without these tweaks. Obviously I wouldn't have dreamed of submitting
a patch series which didn't even compile! I'm using a modern gcc, and
I guess you probably are too? Which would suggest to me that either
your environment is somehow set up to perform stricter type checking
than mine[1], or that there's a weird compiler-oriented bug somewhere
(e.g. in Makefile). Or maybe I'm missing something obvious ...
[1] I'm in favour of stricter compiler checks where possible:
http://article.gmane.org/gmane.comp.version-control.git/211607
^ permalink raw reply
* Re: [PATCH v6 0/7] make test output coloring more intuitive
From: Junio C Hamano @ 2012-12-16 23:11 UTC (permalink / raw)
To: Adam Spiers; +Cc: git list
In-Reply-To: <CAOkDyE9B_HfUZmqNqO35mtjTvdihBTiW=uOV2oEQgLUw1xyf=A@mail.gmail.com>
Adam Spiers <git@adamspiers.org> writes:
> On Sun, Dec 16, 2012 at 6:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Adam Spiers <git@adamspiers.org> writes:
>>
>>> This series of commits attempts to make test output coloring
>>> more intuitive,...
>>
>> Thanks; I understand that this is to replace the previous one
>> b465316 (tests: paint unexpectedly fixed known breakages in bold
>> red, 2012-09-19)---am I correct?
>
> Correct. AFAICS I have incorporated all feedback raised in previous
> reviews.
Seemed clean from a cursory look. Will replace. Thanks.
^ permalink raw reply
* Re: [PATCH 1/3] SubmittingPatches: add convention of prefixing commit messages
From: Junio C Hamano @ 2012-12-16 23:15 UTC (permalink / raw)
To: Adam Spiers; +Cc: git list
In-Reply-To: <1355686561-1057-2-git-send-email-git@adamspiers.org>
Adam Spiers <git@adamspiers.org> writes:
> Conscientious newcomers to git development will read SubmittingPatches
> and CodingGuidelines, but could easily miss the convention of
> prefixing commit messages with a single word identifying the file
> or area the commit touches.
>
> Signed-off-by: Adam Spiers <git@adamspiers.org>
> ---
> Documentation/SubmittingPatches | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index 0dbf2c9..c107cb1 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -9,6 +9,14 @@ Checklist (and a short version for the impatient):
> - the first line of the commit message should be a short
> description (50 characters is the soft limit, see DISCUSSION
> in git-commit(1)), and should skip the full stop
> + - it is also conventional in most cases to prefix the
> + first line with "area: " where the area is a filename
> + or identifier for the general area of the code being
> + modified, e.g.
> + . archive: ustar header checksum is computed unsigned
> + . git-cherry-pick.txt: clarify the use of revision range notation
> + (if in doubt which identifier to use, run "git log --no-merges"
> + on the files you are modifying to see the current conventions)
Thanks; I have to wonder if these details should be left in the
longer version to keep the "short" one short, though.
We should probably add "learn from good examples." (aka "read 'git
log' output and the pattern should be obvious to you") as the first
item to this list, too.
> - the body should provide a meaningful commit message, which:
> . explains the problem the change tries to solve, iow, what
> is wrong with the current code without the change.
^ permalink raw reply
* Re: [PATCH 12/12] Add git-check-ignore sub-command
From: Adam Spiers @ 2012-12-17 0:10 UTC (permalink / raw)
To: git
In-Reply-To: <7vmwzmtmyd.fsf@alter.siamese.dyndns.org>
On Tue, Oct 16, 2012 at 09:12:58AM -0700, Junio C Hamano wrote:
> Adam Spiers <git@adamspiers.org> writes:
> > On Mon, Oct 15, 2012 at 3:31 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> >>> +For each pathname given via the command-line or from a file via
> >>> +`--stdin`, this command will list the first exclude pattern found (if
> >>> +any) which explicitly excludes or includes that pathname. Note that
> >>> +within any given exclude file, later patterns take precedence over
> >>> +earlier ones, so any matching pattern which this command outputs may
> >>> +not be the one you would immediately expect.
> >>
> >> "The first exclude pattern" is very misleading, isn't it?
> >
> > I don't think so, because of the second sentence.
> >
> >> For example, with these in $GIT_DIR/info/exclude, I would get:
> >>
> >> $ cat -n .git/info/exclude
> >> 1 *~
> >> 2 Makefile~
> >> $ git check-ignore -v Makefile~
> >> .git/info/exclude:2:Makefile~ Makefile~
> >>
> >> which is the correct result (the last one in a single source decides
> >> the fate of the path), but it hardly is "first one found" and the
> >> matching pattern in the output would not be something unexpected for
> >> the users, either.
> >>
> >> The reason it is "the first one found" is because the implementation
> >> arranges the loop in such a way that it can stop early when it finds
> >> a match---it simply checks matches from the end of the source.
> >>
> >> But that is not visible to end-users,
> >
> > Correct; that's precisely why I wrote the second sentence which
> > explicitly explains this.
> >
> >> and they will find the above description just wrong, no?
> >
> > It's not wrong AFAICS, but suggestions for rewording this more clearly
> > are of course welcome. Maybe s/immediately/intuitively/ ?
>
> I think this is sufficient:
>
> For each pathname given via the command-line or from a file
> via `--stdin`, show the pattern from .gitignore (or other
> input files to the exclude mechanism) that decides if the
> pathname is excluded.
>
> and without "Note that" at all.
I don't think this is quite sufficient. Firstly, it does not cover
negated patterns (my original text contained "or includes").
Secondly, I think there is still potential for this rewording to
result in confused users. If the "backwards-ness" of the internal
algorithm is kept hidden from them, then in your example above, most
users would be more likely to intuitively expect check-ignore to
return the first line of .git/info/exclude ("*~"). When they saw it
returning the second, they might draw the conclusion that the first
line failed to match (e.g. by mistakenly thinking that the file format
requires regular expressions rather than globs), rather than that git
starts at the end of the file.
This is precisely why I chose not to hide this aspect of the
implementation when initially writing this documentation.
Unfortunately my wording managed to confuse several of you, so clearly
it was not adequate. Therefore I propose an extension of your
version:
For each pathname given via the command-line or from a file
via `--stdin`, show the pattern from .gitignore (or other
input files to the exclude mechanism) that decides if the
pathname is excluded or included. Later patterns within a
file take precedence over earlier ones.
^ permalink raw reply
* $PATH pollution and t9902-completion.sh
From: Adam Spiers @ 2012-12-17 1:05 UTC (permalink / raw)
To: git mailing list
t/t9902-completion.sh is currently failing for me because I happen to
have a custom shell-script called git-check-email in ~/bin, which is
on my $PATH. This is different to a similar-looking case reported
recently, which was due to an unclean working tree:
http://thread.gmane.org/gmane.comp.version-control.git/208085
It's not unthinkable that in the future other tests could break for
similar reasons. Therefore it would be good to sanitize $PATH in the
test framework so that it cannot destabilize tests, although I am
struggling to think of a good way of doing this. Naively stripping
directories under $HOME would not protect against git "plugins" such
as the above being installed into places like /usr/bin. Thoughts?
^ permalink raw reply
* Re: [PATCH 3/3] Makefile: use -Wdeclaration-after-statement if supported
From: Junio C Hamano @ 2012-12-17 1:52 UTC (permalink / raw)
To: Adam Spiers; +Cc: git list
In-Reply-To: <1355686561-1057-4-git-send-email-git@adamspiers.org>
Adam Spiers <git@adamspiers.org> writes:
> If we adopt this approach,...
> diff --git a/Makefile b/Makefile
> index a49d1db..aae70d4 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -331,8 +331,13 @@ endif
> # CFLAGS and LDFLAGS are for the users to override from the command line.
>
> CFLAGS = -g -O2 -Wall
> +GCC_DECL_AFTER_STATEMENT = \
> + $(shell $(CC) --help -v 2>&1 | \
> + grep -q -- -Wdeclaration-after-statement && \
> + echo -Wdeclaration-after-statement)
> +GCC_FLAGS = $(GCC_DECL_AFTER_STATEMENT)
> +ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS) $(GCC_FLAGS)
> LDFLAGS =
> -ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS)
> ALL_LDFLAGS = $(LDFLAGS)
Please do not do this.
People cannot disable it from the command line, like:
$ make V=1 CFLAGS='-g -O0 -Wall'
If anything, this should be part of the default CFLAGS.
More importantly, this will run the $(shell ...) struct once for
every *.o file we produce, I think, in addition to running it twice
for the whole build. If you add this:
@@ -345,7 +345,8 @@ CFLAGS = -g -O2 -Wall
GCC_DECL_AFTER_STATEMENT = \
$(shell $(CC) --help -v 2>&1 | \
grep -q -- -Wdeclaration-after-statement && \
- echo -Wdeclaration-after-statement)
+ echo -Wdeclaration-after-statement; \
+ echo >&2 GCC_DECL_AFTER_STATEMENT CRUFT)
GCC_FLAGS = $(GCC_DECL_AFTER_STATEMENT)
ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS) $(GCC_FLAGS)
LDFLAGS =
remove git.o and dir.o from a fully built tree, and then try to
rebuild these two files, you will get this:
$ make V=1 git.o dir.o
GCC_DECL_AFTER_STATEMENT CRUFT
GCC_DECL_AFTER_STATEMENT CRUFT
GCC_DECL_AFTER_STATEMENT CRUFT
cc -o git.o -c -MF ./.depend/git.o.d -MMD -MP -g -O2 -Wall \
-Wdeclaration-after-statement -I. -DHAVE_PATHS_H -DHAVE_DEV_TTY \
-DXDL_FAST_HASH -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY \
-DNO_MKSTEMPS -DSHELL_PATH='"/bin/sh"' \
'-DGIT_HTML_PATH="share/doc/git-doc"' '-DGIT_MAN_PATH="share/man"' \
'-DGIT_INFO_PATH="share/info"' git.c
GCC_DECL_AFTER_STATEMENT CRUFT
cc -o dir.o -c -MF ./.depend/dir.o.d -MMD -MP -g -O2 -Wall \
-Wdeclaration-after-statement -I. -DHAVE_PATHS_H -DHAVE_DEV_TTY \
-DXDL_FAST_HASH -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY \
-DNO_MKSTEMPS -DSHELL_PATH='"/bin/sh"' dir.c
$ make V=1 git.o dir.o
GCC_DECL_AFTER_STATEMENT CRUFT
GCC_DECL_AFTER_STATEMENT CRUFT
make: `dir.o' is up to date.
^ permalink raw reply
* Re: [PATCH 3/3] Makefile: use -Wdeclaration-after-statement if supported
From: Adam Spiers @ 2012-12-17 2:15 UTC (permalink / raw)
To: git list
In-Reply-To: <7vk3shphru.fsf@alter.siamese.dyndns.org>
On Sun, Dec 16, 2012 at 05:52:05PM -0800, Junio C Hamano wrote:
> Adam Spiers <git@adamspiers.org> writes:
>
> > If we adopt this approach,...
> > diff --git a/Makefile b/Makefile
> > index a49d1db..aae70d4 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -331,8 +331,13 @@ endif
> > # CFLAGS and LDFLAGS are for the users to override from the command line.
> >
> > CFLAGS = -g -O2 -Wall
> > +GCC_DECL_AFTER_STATEMENT = \
> > + $(shell $(CC) --help -v 2>&1 | \
> > + grep -q -- -Wdeclaration-after-statement && \
> > + echo -Wdeclaration-after-statement)
> > +GCC_FLAGS = $(GCC_DECL_AFTER_STATEMENT)
> > +ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS) $(GCC_FLAGS)
> > LDFLAGS =
> > -ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS)
> > ALL_LDFLAGS = $(LDFLAGS)
>
> Please do not do this.
>
> People cannot disable it from the command line, like:
>
> $ make V=1 CFLAGS='-g -O0 -Wall'
>
> If anything, this should be part of the default CFLAGS.
>
> More importantly, this will run the $(shell ...) struct once for
> every *.o file we produce, I think, in addition to running it twice
> for the whole build.
[snipped]
OK; I expect these issues with the implementation are all
surmountable. I did not necessarily expect this to be the final
implementation anyhow, as indicated by my comments below the divider
line. However it's not clear to me what you think about the idea in
principle, and whether other compiler flags would merit inclusion.
(And also, please don't let this discussion hold up acceptance of the
two prior patches in the series. Even though they are independent,
they are somewhat logically related so I grouped them into the same
series, although I'm not sure if that was the right thing to do.)
^ permalink raw reply
* Re: [PATCH v2] Documentation: don't link to example mail addresses
From: Junio C Hamano @ 2012-12-17 2:24 UTC (permalink / raw)
To: John Keeping; +Cc: Jeff King, git
In-Reply-To: <20121216140029.GE2725@river.lan>
John Keeping <john@keeping.me.uk> writes:
> diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
> index d1844ea..68bca1a 100644
> --- a/Documentation/git-fast-import.txt
> +++ b/Documentation/git-fast-import.txt
> @@ -427,7 +427,7 @@ they made it.
>
> Here `<name>` is the person's display name (for example
> ``Com M Itter'') and `<email>` is the person's email address
> -(``cm@example.com''). `LT` and `GT` are the literal less-than (\x3c)
> +(``\cm@example.com''). `LT` and `GT` are the literal less-than (\x3c)
I seem to be getting
(<tt>`\cm@example.com''). `LT</tt> and <tt>GT</tt> are the literal less-than (\x3c)
out of this part in the resulting HTML output, which is probably not
what you wanted to see.
I have a feeling that it might be a better solution to stop using
these pretty quotes. It's not like we use them a lot and a quick
scanning of "git grep '``'" output seems to tell me that many of
them should be `monospace output`, and the rest (mostly references
to section headers) can be "Section".
^ permalink raw reply
* How to specify remote branch correctly
From: Woody Wu @ 2012-12-17 2:30 UTC (permalink / raw)
To: git
Hi, List
I have two branches in the remote, say, origin/master, origin/foo. Then
when I tried to switch to the remote foo branch, the following two
methods gave me different results:
1. git checkout foo
2. git checkout origin/foo
The first method run silently with success, but the second method
complains that I got a 'detached HEAD'. So, I think I don't understand
the difference between 'foo' and 'origin/foo'. Can someone give me a
hint?
Supposing I have another remote defined in .git/config that points
to another repository but also have a same name branch, say
'remote-x/foo', how do I tell git which 'foo' I want to switch to?
The similar problem also exists for 'fetch' command to me. From the man
page, I don't find answer of how to specify which remote I am going to
fetch from. Can you help me?
Thanks in advance.
--
woody
I can't go back to yesterday - because I was a different person then.
^ permalink raw reply
* Re: [PATCH 3/3] Makefile: use -Wdeclaration-after-statement if supported
From: Junio C Hamano @ 2012-12-17 4:18 UTC (permalink / raw)
To: Adam Spiers; +Cc: git list
In-Reply-To: <20121217021501.GA13745@gmail.com>
Adam Spiers <git@adamspiers.org> writes:
> OK; I expect these issues with the implementation are all
> surmountable. I did not necessarily expect this to be the final
> implementation anyhow, as indicated by my comments below the divider
> line. However it's not clear to me what you think about the idea in
> principle, and whether other compiler flags would merit inclusion.
As different versions of GCC behave differently, and the same GCC
(mis)detect issues differently depending on the optimization level,
I do not know if it will be a fruitful exercise to try to come up
with one expression to come up with the set of flags to suit
everybody. One flag I prefer to use is -Werror, but that means the
other flags must have zero false positive rate.
If you are interested, the flags I personally use with the version
of GCC I happen to have is in the Make script on the 'todo' branch.
^ permalink raw reply
* Re: How to specify remote branch correctly
From: Andrew Ardill @ 2012-12-17 4:27 UTC (permalink / raw)
To: Woody Wu; +Cc: git@vger.kernel.org
In-Reply-To: <slrnkct0r3.dsp.narkewoody@zuhnb712.local.com>
On 17 December 2012 13:30, Woody Wu <narkewoody@gmail.com> wrote:
> 1. git checkout foo
> 2. git checkout origin/foo
>
> The first method run silently with success, but the second method
> complains that I got a 'detached HEAD'. So, I think I don't understand
> the difference between 'foo' and 'origin/foo'. Can someone give me a
> hint?
Hi Woody,
I think you are just missing a couple of important distinctions that
git makes about the different references that exist in your
repository.
A remote reference (origin/foo) describes exactly the state of
somebody else's branch at the time you last synchronised with them. It
does not make sense for you to be able to 'edit' this state, as it
doesn't belong to you. Instead, we create a copy of that reference and
give it a name (git checkout foo origin/foo) and call this a local
reference (foo). Git then provides machinery around keeping these in
sync with each other (git branch --set-upstream foo origin/foo) but we
don't _have_ to keep these in sync at all! In fact, the names can be
completely arbitrary and we don't have to track the upstream at all.
If I have some other remote (remote-x) that has the same branch as
origin but with some other changes I want to look at, we can just
check that out to another branch (git checkout remote-x-foo
remote-x/foo), or simply download it as a remote ref and merge the
changes on top of my existing local branch (git fetch remote-x; git
checkout foo; git merge remote-x/foo).
There are lots of patterns that can emerge from this functionality,
but the main thing to remember is that to create changes on top of a
remote branch, we first need to create a local copy of it. A 'detached
HEAD' here means that we are looking at the remote repository's branch
but don't have a local copy of it, so any changes we make might be
'lost' (that is, not have an easy to find branch name).
Regards,
Andrew Ardill
^ permalink raw reply
* Re: [PATCH v2 1/2] Makefile: remove tracking of TCLTK_PATH
From: Junio C Hamano @ 2012-12-17 4:31 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <20121216193850.23461.28099.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> It looks like we are tracking the value of TCLTK_PATH in the main
> Makefile for no good reason, as this is done in git-gui too and the
> GIT-GUI-VARS is not used in the Makefile.
This was added to the main Makefile when we slurped gitk to our
project at the top-level, so I am not surprised if git-gui were
not depending on it at all.
A better explanation is that t62ba514 (Move gitk to its own
subdirectory, 2007-11-17) should have moved these lines to
gitk-git/Makefile (and I think we should move them there in a
separate patch).
^ permalink raw reply
* Re: [PATCH] git-completion.bash: add support for path completion
From: Junio C Hamano @ 2012-12-17 4:50 UTC (permalink / raw)
To: Manlio Perillo; +Cc: git
In-Reply-To: <1355693080-4765-1-git-send-email-manlio.perillo@gmail.com>
Manlio Perillo <manlio.perillo@gmail.com> writes:
> The git-completion.bash script did not implemented full support for
> completion, for git commands that operate on files from the current
> working directory or the index.
>
> For these commands, only options completion was available.
Hrm, "git mv CO<TAB>" completes it to "COPYING" for me. Same for:
git rm CO<TAB>
git clean Doc<TAB>
git commit --edit Doc<TAB>
There must be something missing from the above description, and the
claim the above two paragraphs make does no make sense without that
something that is missing.
> * the path completion for the "git mv" and "git rm" commands is provided
> using "git ls-files --exclude-standard"
Does the above mean "git mv COPYING Doc<TAB>" would complete the
command line to move it to Documentation/ directory?
I think "using X" is of secondary importance. Reviewers and future
developers (who are reading "git log" output) can read it from the
patch. What is expected in the log message is why the implemenation
was chosen, and in order to achieve what effect.
For example, something like:
Each parameter between the first one and the one before the last
one to 'git mv' is completed to a tracked path or a leading
directory of a tracked path
should come first to explain what your patch wanted to do. It of
course is helpful to explain how you implemented that behaviour, by
appending ", using 'ls-files --exclude-standard'" at the end.
> * the path completion for the "git add" command is provided using
> "git ls-files --exclude-standard -o -m"
Likewise. You are adding "either a modified, or a new and
unignored" and use "ls-files --exclude-standard -o -m" to achieve
it.
> * the path completion for the "git clean" command is provided using
> "git ls-files --exclude-standard -o"
>
> * the path completion for the "git commit" command is provides using
> "git diff-index --name-only HEAD"
As long as all of the above stops completion at directory boundary,
I think the above sounds like a sensible thing to do. e.g. when
"ls-files" gives Documentation/Makefile and Documentation/git.txt,
"git cmd Doc<TAB>" first would give "git cmd Documentation/" and
then the second <TAB> would offer these two paths as choices. That
way, the user can choose to just execute "git cmd Documentation/"
without even looking at these individual paths.
I am not sure how you would handle the last parameter to "git mv",
though. That is by definition a path that does not exist,
i.e. cannot be completed.
> Signed-off-by: Manlio Perillo <manlio.perillo@gmail.com>
> ---
> contrib/completion/git-completion.bash | 39 ++++++++++++++++++++++------------
> 1 file changed, 26 insertions(+), 13 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 0b77eb1..8b348c3 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -233,6 +233,25 @@ __gitcomp_nl ()
> COMPREPLY=($(compgen -P "${2-}" -S "${4- }" -W "$1" -- "${3-$cur}"))
> }
>
> +__git_files ()
> +{
> + local dir="$(__gitdir)"
> + if [ -d "$dir" ]; then
> + git --git-dir="$dir" ls-files --exclude-standard $*
> + return
> + fi
> +}
> +
> +# Return all staged files with modification from current HEAD
> +__git_commit_files ()
> +{
> + local dir="$(__gitdir)"
> + if [ -d "$dir" ]; then
> + git --git-dir="$dir" diff-index --name-only HEAD
> + return
> + fi
> +}
> +
> __git_heads ()
> {
> local dir="$(__gitdir)"
> @@ -770,8 +789,6 @@ _git_apply ()
>
> _git_add ()
> {
> - __git_has_doubledash && return
> -
> case "$cur" in
> --*)
> __gitcomp "
> @@ -780,7 +797,8 @@ _git_add ()
> "
> return
> esac
> - COMPREPLY=()
> + # XXX should we care for --update and --all options ?
> + __gitcomp_nl "$(__git_files -o -m)" "" "$cur" ""
> }
>
> _git_archive ()
> @@ -930,15 +948,14 @@ _git_cherry_pick ()
>
> _git_clean ()
> {
> - __git_has_doubledash && return
> -
> case "$cur" in
> --*)
> __gitcomp "--dry-run --quiet"
> return
> ;;
> esac
> - COMPREPLY=()
> + # TODO: check for -x option
> + __gitcomp_nl "$(__git_files -o)" "" "$cur" ""
> }
>
> _git_clone ()
> @@ -969,8 +986,6 @@ _git_clone ()
>
> _git_commit ()
> {
> - __git_has_doubledash && return
> -
> case "$cur" in
> --cleanup=*)
> __gitcomp "default strip verbatim whitespace
> @@ -998,7 +1013,7 @@ _git_commit ()
> "
> return
> esac
> - COMPREPLY=()
> + __gitcomp_nl "$(__git_commit_files)" "" "$cur" ""
> }
>
> _git_describe ()
> @@ -1362,7 +1377,7 @@ _git_mv ()
> return
> ;;
> esac
> - COMPREPLY=()
> + __gitcomp_nl "$(__git_files)" "" "$cur" ""
> }
>
> _git_name_rev ()
> @@ -2068,15 +2083,13 @@ _git_revert ()
>
> _git_rm ()
> {
> - __git_has_doubledash && return
> -
> case "$cur" in
> --*)
> __gitcomp "--cached --dry-run --ignore-unmatch --quiet"
> return
> ;;
> esac
> - COMPREPLY=()
> + __gitcomp_nl "$(__git_files)" "" "$cur" ""
> }
>
> _git_shortlog ()
^ permalink raw reply
* Re: [PATCH] git-completion.bash: update obsolete code.
From: Junio C Hamano @ 2012-12-17 4:54 UTC (permalink / raw)
To: Manlio Perillo; +Cc: git
In-Reply-To: <1355694602-8771-1-git-send-email-manlio.perillo@gmail.com>
Manlio Perillo <manlio.perillo@gmail.com> writes:
> The git-completion.bash script was using the git ls-tree command
> without the --name-only option, with a sed filter to parse path names;
> use the --name-only option, instead.
>
> Signed-off-by: Manlio Perillo <manlio.perillo@gmail.com>
> ---
Did you miss the different handling between blobs and trees the
latter gets trailing slash in the completion)?
> contrib/completion/git-completion.bash | 15 +--------------
> 1 file changed, 1 insertion(+), 14 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 0b77eb1..85d9051 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -397,20 +397,7 @@ __git_complete_revlist_file ()
> *) pfx="$ref:$pfx" ;;
> esac
>
> - __gitcomp_nl "$(git --git-dir="$(__gitdir)" ls-tree "$ls" \
> - | sed '/^100... blob /{
> - s,^.* ,,
> - s,$, ,
> - }
> - /^120000 blob /{
> - s,^.* ,,
> - s,$, ,
> - }
> - /^040000 tree /{
> - s,^.* ,,
> - s,$,/,
> - }
> - s/^.* //')" \
> + __gitcomp_nl "$(git --git-dir="$(__gitdir)" ls-tree --name-only "$ls")" \
> "$pfx" "$cur_" ""
> ;;
> *...*)
^ permalink raw reply
* Re: How to specify remote branch correctly
From: Woody Wu @ 2012-12-17 5:06 UTC (permalink / raw)
To: git
In-Reply-To: <CAH5451=7frqa-YHXubvO=dMK2CvVoWR-VFZ3XCmKouNiQz4gAg@mail.gmail.com>
On 2012-12-17, Andrew Ardill <andrew.ardill@gmail.com> wrote:
> On 17 December 2012 13:30, Woody Wu <narkewoody@gmail.com> wrote:
>> 1. git checkout foo
>> 2. git checkout origin/foo
>>
>> The first method run silently with success, but the second method
>> complains that I got a 'detached HEAD'. So, I think I don't understand
>> the difference between 'foo' and 'origin/foo'. Can someone give me a
>> hint?
>
> Hi Woody,
>
> I think you are just missing a couple of important distinctions that
> git makes about the different references that exist in your
> repository.
>
> A remote reference (origin/foo) describes exactly the state of
> somebody else's branch at the time you last synchronised with them. It
> does not make sense for you to be able to 'edit' this state, as it
> doesn't belong to you. Instead, we create a copy of that reference and
> give it a name (git checkout foo origin/foo) and call this a local
> reference (foo). Git then provides machinery around keeping these in
> sync with each other (git branch --set-upstream foo origin/foo) but we
> don't _have_ to keep these in sync at all! In fact, the names can be
> completely arbitrary and we don't have to track the upstream at all.
>
> If I have some other remote (remote-x) that has the same branch as
> origin but with some other changes I want to look at, we can just
> check that out to another branch (git checkout remote-x-foo
> remote-x/foo), or simply download it as a remote ref and merge the
> changes on top of my existing local branch (git fetch remote-x; git
> checkout foo; git merge remote-x/foo).
Thanks for explaining the concept of branch to me. Now I understood the
difference between local and remote branch. But I still have
difficulties in answering my own questions.
1. git checkout foo.
By this command, I think I am checking out files in my local branch
named foo, and after that I also switch to the branch. Right?
2. git checkout origin/foo
By this command, I am checking out files in remote branch origin/foo,
but don't create a local branch, so I am not in any branch now. This is
the reason why git tell me that I am in a 'detached HEAD'. Is this
understanding right?
>
> There are lots of patterns that can emerge from this functionality,
> but the main thing to remember is that to create changes on top of a
> remote branch, we first need to create a local copy of it. A 'detached
> HEAD' here means that we are looking at the remote repository's branch
> but don't have a local copy of it, so any changes we make might be
> 'lost' (that is, not have an easy to find branch name).
>
I think here is a little confuse to me. You mean that a 'detached HEAD'
means I don't have a local copy, but I remember that if I run something
like:
$ git checkout a-tag-name
then I ususally went into 'detached HEAD' but my local files really get
switched to those files in the tag 'a-tag-name'. So what does you mean
by 'don't have a local copy'?
Many thanks!
--
woody
I can't go back to yesterday - because I was a different person then.
^ permalink raw reply
* Re: How to specify remote branch correctly
From: Andrew Ardill @ 2012-12-17 5:13 UTC (permalink / raw)
To: Woody Wu; +Cc: git@vger.kernel.org
In-Reply-To: <slrnkcta0j.mlu.narkewoody@zuhnb712.local.com>
On 17 December 2012 16:06, Woody Wu <narkewoody@gmail.com> wrote:
> 1. git checkout foo.
> By this command, I think I am checking out files in my local branch
> named foo, and after that I also switch to the branch. Right?
Correct. Your working directory (files) switch over to whatever your
local branch 'foo' points to, and your HEAD is updated to point to
your local branch 'foo'. Unless something goes wrong/you have
conflicting files/uncommitted changes etc.
> 2. git checkout origin/foo
> By this command, I am checking out files in remote branch origin/foo,
> but don't create a local branch, so I am not in any branch now. This is
> the reason why git tell me that I am in a 'detached HEAD'. Is this
> understanding right?
Correct! Your working directory is updated, however it doesn't make
sense for you to make changes to a remote branch, so HEAD is updated
to be detached.
>>
>> There are lots of patterns that can emerge from this functionality,
>> but the main thing to remember is that to create changes on top of a
>> remote branch, we first need to create a local copy of it. A 'detached
>> HEAD' here means that we are looking at the remote repository's branch
>> but don't have a local copy of it, so any changes we make might be
>> 'lost' (that is, not have an easy to find branch name).
>>
>
> I think here is a little confuse to me. You mean that a 'detached HEAD'
> means I don't have a local copy, but I remember that if I run something
> like:
> $ git checkout a-tag-name
> then I ususally went into 'detached HEAD' but my local files really get
> switched to those files in the tag 'a-tag-name'. So what does you mean
> by 'don't have a local copy'?
I should have been more clear. Here I mean that you don't have a local
copy of the branch reference. Your working directory is updated to be
in sync with the remote branch, but you haven't yet copied that remote
reference to a local branch that you can update with your changes.
Hope that clears it up.
Regards,
Andrew Ardill
^ permalink raw reply
* Re: [PATCH] Documentation: don't link to example mail addresses
From: Junio C Hamano @ 2012-12-17 5:29 UTC (permalink / raw)
To: John Keeping; +Cc: git, Jeff King
In-Reply-To: <20121215150314.GC2725@river.lan>
John Keeping <john@keeping.me.uk> writes:
> I can't see any other uses of the "$$" quote in the documentation, so
> it's probably worth noting that I've tested this with Asciidoc 8.6.8,
> although I can't see anything in the changelog to indicate that
> Asciidoc's treatment of it has changed recently.
Thanks.
> Documentation/git-fast-import.txt | 2 +-
> Documentation/git-tag.txt | 2 +-
> Documentation/mailmap.txt | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
> index d1844ea..05913cc 100644
> --- a/Documentation/git-fast-import.txt
> +++ b/Documentation/git-fast-import.txt
> @@ -427,7 +427,7 @@ they made it.
>
> Here `<name>` is the person's display name (for example
> ``Com M Itter'') and `<email>` is the person's email address
> -(``cm@example.com''). `LT` and `GT` are the literal less-than (\x3c)
> +(``$$cm@example.com$$''). `LT` and `GT` are the literal less-than (\x3c)
> and greater-than (\x3e) symbols. These are required to delimit
> the email address from the other fields in the line. Note that
> `<name>` and `<email>` are free-form and may contain any sequence
AsciiDoc 8.5.2 gives this:
asciidoc: WARNING: git-fast-import.txt: line 434: nested inline passthrough
Also in git-fast-import.1, there is this line:
... person\(cqs display name (for example `Com M Itter\(aq\(aq) and `<ema...
(notice two leftover `s); not that this is a new issue with this patch.
Which is puzzling, because the next input line formats better:
... email address (\(lqcm@example\&.com\(rq)\&. ...
Other two hunks for git-tag and mailmap seem to give us a better
results.
^ permalink raw reply
* Re: How to specify remote branch correctly
From: Tomas Carnecky @ 2012-12-17 5:30 UTC (permalink / raw)
To: Andrew Ardill, Woody Wu; +Cc: git@vger.kernel.org
In-Reply-To: <CAH5451kmTW+nO4V4pjSdaqhHAb=RX-tawLo=rJfuPnDRDWeSEA@mail.gmail.com>
On Mon, 17 Dec 2012 16:13:08 +1100, Andrew Ardill <andrew.ardill@gmail.com> wrote:
> On 17 December 2012 16:06, Woody Wu <narkewoody@gmail.com> wrote:
> > 1. git checkout foo.
> > By this command, I think I am checking out files in my local branch
> > named foo, and after that I also switch to the branch. Right?
>
> Correct. Your working directory (files) switch over to whatever your
> local branch 'foo' points to, and your HEAD is updated to point to
> your local branch 'foo'. Unless something goes wrong/you have
> conflicting files/uncommitted changes etc.
'git checkout foo' has special meaning if a local branch with that name
doesn't exist but there is a remote branch with that name. In that case it's
equivalent to: git checkout -t -b foo origin/foo. Because that's what people
usually want.
^ permalink raw reply
* Re: How to specify remote branch correctly
From: Andrew Ardill @ 2012-12-17 5:52 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: Woody Wu, git@vger.kernel.org
In-Reply-To: <1355722245-ner-6603@calvin>
On 17 December 2012 16:30, Tomas Carnecky <tomas.carnecky@gmail.com> wrote:
> 'git checkout foo' has special meaning if a local branch with that name
> doesn't exist but there is a remote branch with that name. In that case it's
> equivalent to: git checkout -t -b foo origin/foo. Because that's what people
> usually want.
This is true, but I don't think it is documented. Does anyone know if
this is documented anywhere in particular? The git checkout man pages
seem to not mention it, and the git branch page doesn't seem to
mention it either, but perhaps I am just missing it?
In any case, might be useful to make this behaviour more clear.
Regards,
Andrew Ardill
^ permalink raw reply
* Re: How to specify remote branch correctly
From: Chris Rorvick @ 2012-12-17 6:44 UTC (permalink / raw)
To: Andrew Ardill; +Cc: Tomas Carnecky, Woody Wu, git@vger.kernel.org
In-Reply-To: <CAH5451=KX5eZH6AUoaQ7YcWcNcKhUp8Lk8Uvs3o=jWW=vaYiCg@mail.gmail.com>
On Sun, Dec 16, 2012 at 11:52 PM, Andrew Ardill <andrew.ardill@gmail.com> wrote:
> This is true, but I don't think it is documented.
I noticed this, too. I was just about to send a patch to add this.
Chris
^ permalink raw reply
* [PATCH 0/2] Documentation: clarify usage of checkout
From: Chris Rorvick @ 2012-12-17 6:45 UTC (permalink / raw)
To: git; +Cc: Chris Rorvick, Andrew Ardill, Tomas Carnecky, Woody Wu
This is response to the questions posed in:
http://thread.gmane.org/gmane.comp.version-control.git/211624
It doesn't seem like the behavior implemented in 70c9ac2 is documented.
Chris Rorvick (2):
Documentation/git-checkout.txt: clarify usage
Documentation/git-checkout.txt: document 70c9ac2 behavior
Documentation/git-checkout.txt | 34 +++++++++++++++++++++++++---------
1 file changed, 25 insertions(+), 9 deletions(-)
--
1.8.1.rc1.203.g1ddc124
^ 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