* 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: [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: [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 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: 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 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
* 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 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
* 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 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
* $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 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
* 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 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
* 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
* [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
* [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] 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
* 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
* Re: [PATCH] Remove misleading date form api-index-skel.txt
From: Junio C Hamano @ 2012-12-16 19:59 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Thomas Ackermann, git
In-Reply-To: <m2ip828jtx.fsf@linux-m68k.org>
Andreas Schwab <schwab@linux-m68k.org> writes:
> s/form/from/
>
> Andreas.
Thanks; will apply.
^ permalink raw reply
* [PATCH v2 2/2] Makefile: detect when PYTHON_PATH changes
From: Christian Couder @ 2012-12-16 19:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When make is run, the python scripts are created from *.py files that
are changed to use the python given by PYTHON_PATH. And PYTHON_PATH
is set by default to /usr/bin/python on Linux.
This is nice except when you run make another time setting a
different PYTHON_PATH, because, as the python scripts have already
been created, make finds nothing to do.
The goal of this patch is to detect when the PYTHON_PATH changes and
to create the python scripts again when this happens. To do that we
use the same trick that is done to track other variables like prefix,
flags, tcl/tk path and shell path. We update a GIT-PYTHON-VARS file
with the PYTHON_PATH and check if it changed.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
.gitignore | 1 +
Makefile | 16 ++++++++++++++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/.gitignore b/.gitignore
index 6d69ae1..086c5af 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,6 +2,7 @@
/GIT-CFLAGS
/GIT-LDFLAGS
/GIT-PREFIX
+/GIT-PYTHON-VARS
/GIT-SCRIPT-DEFINES
/GIT-USER-AGENT
/GIT-VERSION-FILE
diff --git a/Makefile b/Makefile
index 585b2eb..7db8445 100644
--- a/Makefile
+++ b/Makefile
@@ -2245,7 +2245,7 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)) git-instaweb: % : unimplemented.sh
endif # NO_PERL
ifndef NO_PYTHON
-$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS GIT-PREFIX
+$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS GIT-PREFIX GIT-PYTHON-VARS
$(patsubst %.py,%,$(SCRIPT_PYTHON)): % : %.py
$(QUIET_GEN)$(RM) $@ $@+ && \
INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C git_remote_helpers -s \
@@ -2624,6 +2624,18 @@ ifdef GIT_PERF_MAKE_OPTS
@echo GIT_PERF_MAKE_OPTS=\''$(subst ','\'',$(subst ','\'',$(GIT_PERF_MAKE_OPTS)))'\' >>$@
endif
+### Detect Python interpreter path changes
+ifndef NO_PYTHON
+TRACK_PYTHON = $(subst ','\'',-DPYTHON_PATH='$(PYTHON_PATH_SQ)')
+
+GIT-PYTHON-VARS: FORCE
+ @VARS='$(TRACK_PYTHON)'; \
+ if test x"$$VARS" != x"`cat $@ 2>/dev/null`" ; then \
+ echo 1>&2 " * new Python interpreter location"; \
+ echo "$$VARS" >$@; \
+ fi
+endif
+
test_bindir_programs := $(patsubst %,bin-wrappers/%,$(BINDIR_PROGRAMS_NEED_X) $(BINDIR_PROGRAMS_NO_X) $(TEST_PROGRAMS_NEED_X))
all:: $(TEST_PROGRAMS) $(test_bindir_programs)
@@ -2899,7 +2911,7 @@ ifndef NO_TCLTK
$(MAKE) -C git-gui clean
endif
$(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-BUILD-OPTIONS
- $(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES
+ $(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES GIT-PYTHON-VARS
.PHONY: all install profile-clean clean strip
.PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
--
1.8.1.rc1.2.g8740035
^ permalink raw reply related
* [PATCH v2 1/2] Makefile: remove tracking of TCLTK_PATH
From: Christian Couder @ 2012-12-16 19:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
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 patch removes the useless code used to do this tracking.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
.gitignore | 1 -
Makefile | 14 +-------------
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/.gitignore b/.gitignore
index f702415..6d69ae1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,7 +1,6 @@
/GIT-BUILD-OPTIONS
/GIT-CFLAGS
/GIT-LDFLAGS
-/GIT-GUI-VARS
/GIT-PREFIX
/GIT-SCRIPT-DEFINES
/GIT-USER-AGENT
diff --git a/Makefile b/Makefile
index 4ad6fbd..585b2eb 100644
--- a/Makefile
+++ b/Makefile
@@ -2624,18 +2624,6 @@ ifdef GIT_PERF_MAKE_OPTS
@echo GIT_PERF_MAKE_OPTS=\''$(subst ','\'',$(subst ','\'',$(GIT_PERF_MAKE_OPTS)))'\' >>$@
endif
-### Detect Tck/Tk interpreter path changes
-ifndef NO_TCLTK
-TRACK_VARS = $(subst ','\'',-DTCLTK_PATH='$(TCLTK_PATH_SQ)')
-
-GIT-GUI-VARS: FORCE
- @VARS='$(TRACK_VARS)'; \
- if test x"$$VARS" != x"`cat $@ 2>/dev/null`" ; then \
- echo 1>&2 " * new Tcl/Tk interpreter location"; \
- echo "$$VARS" >$@; \
- fi
-endif
-
test_bindir_programs := $(patsubst %,bin-wrappers/%,$(BINDIR_PROGRAMS_NEED_X) $(BINDIR_PROGRAMS_NO_X) $(TEST_PROGRAMS_NEED_X))
all:: $(TEST_PROGRAMS) $(test_bindir_programs)
@@ -2910,7 +2898,7 @@ ifndef NO_TCLTK
$(MAKE) -C gitk-git clean
$(MAKE) -C git-gui clean
endif
- $(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-GUI-VARS GIT-BUILD-OPTIONS
+ $(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-BUILD-OPTIONS
$(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES
.PHONY: all install profile-clean clean strip
--
1.8.1.rc1.2.g8740035
^ permalink raw reply related
* [PATCH 2/3] Documentation: move support for old compilers to CodingGuidelines
From: Adam Spiers @ 2012-12-16 19:36 UTC (permalink / raw)
To: git list
In-Reply-To: <1355686561-1057-1-git-send-email-git@adamspiers.org>
The "Try to be nice to older C compilers" text is clearly a guideline
to be borne in mind whilst coding rather than when submitting patches.
Signed-off-by: Adam Spiers <git@adamspiers.org>
---
Documentation/CodingGuidelines | 8 ++++++++
Documentation/SubmittingPatches | 13 -------------
2 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 57da6aa..69f7e9b 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -112,6 +112,14 @@ For C programs:
- We try to keep to at most 80 characters per line.
+ - We try to support a wide range of C compilers to compile git with,
+ including old ones. That means that you should not use C99
+ initializers, even if a lot of compilers grok it.
+
+ - Variables have to be declared at the beginning of the block.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
- When declaring pointers, the star sides with the variable
name, i.e. "char *string", not "char* string" or
"char * string". This makes it easier to understand code
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index c107cb1..c34c9d1 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -127,19 +127,6 @@ in templates/hooks--pre-commit. To help ensure this does not happen,
run git diff --check on your changes before you commit.
-(1a) Try to be nice to older C compilers
-
-We try to support a wide range of C compilers to compile
-git with. That means that you should not use C99 initializers, even
-if a lot of compilers grok it.
-
-Also, variables have to be declared at the beginning of the block
-(you can check this with gcc, using the -Wdeclaration-after-statement
-option).
-
-Another thing: NULL pointers shall be written as NULL, not as 0.
-
-
(2) Generate your patch using git tools out of your commits.
git based diff tools generate unidiff which is the preferred format.
--
1.7.12.1.396.g53b3ea9
^ permalink raw reply related
* [PATCH 3/3] Makefile: use -Wdeclaration-after-statement if supported
From: Adam Spiers @ 2012-12-16 19:36 UTC (permalink / raw)
To: git list
In-Reply-To: <1355686561-1057-1-git-send-email-git@adamspiers.org>
CodingGuidelines requests that code should be nice to older C compilers.
Since modern gcc can warn on code written using newer dialects such as C99,
it makes sense to take advantage of this by auto-detecting this capability
and enabling it when found.
Signed-off-by: Adam Spiers <git@adamspiers.org>
---
If we adopt this approach, it may make sense to enable other flags
where available (e.g. -Wzero-as-null-pointer-constant, maybe even
-ansi). In that case, something like this might be a more efficient
way of writing it:
GCC_FLAGS=-Wdeclaration-after-statement,-Wanother-flag,-Wand-another
GCC_FLAGS_REGEXP=$(shell echo $(GCC_FLAGS) | sed 's/,/\\|/g')
GCC_SUPPORTED_FLAGS=$(shell cc --help -v 2>&1 | \
sed -n '/.* \($(GCC_FLAGS_REGEXP)\) .*/{s//\1/;p}')
Makefile | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
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)
STRIP ?= strip
--
1.7.12.1.396.g53b3ea9
^ permalink raw reply related
* [PATCH 1/3] SubmittingPatches: add convention of prefixing commit messages
From: Adam Spiers @ 2012-12-16 19:35 UTC (permalink / raw)
To: git list
In-Reply-To: <1355686561-1057-1-git-send-email-git@adamspiers.org>
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)
- 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.
--
1.7.12.1.396.g53b3ea9
^ 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