* Re: [PATCH 1/2] Documentation/git-checkout.txt: clarify usage
From: Junio C Hamano @ 2012-12-17 7:21 UTC (permalink / raw)
To: Chris Rorvick; +Cc: git, Andrew Ardill, Tomas Carnecky, Woody Wu
In-Reply-To: <1355726702-27974-2-git-send-email-chris@rorvick.com>
Chris Rorvick <chris@rorvick.com> writes:
> The forms of checkout that do not take a path are lumped together in the
> DESCRIPTION section, but the description for this group is dominated by
> explanation of the -b|-B form. Split these apart for more clarity.
>
> Signed-off-by: Chris Rorvick <chris@rorvick.com>
> ---
> Documentation/git-checkout.txt | 26 +++++++++++++++++---------
> 1 file changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
> index 7958a47..a47555c 100644
> --- a/Documentation/git-checkout.txt
> +++ b/Documentation/git-checkout.txt
> @@ -22,17 +22,18 @@ also update `HEAD` to set the specified branch as the current
> branch.
>
> 'git checkout' [<branch>]::
> +
> + Update the index, working tree, and HEAD to reflect the
> + specified branch.
This is to "check out the branch" ;-)
But of course, we cannot define "checkout" in terms of "checkout",
so we need to phrase it without saying "checkout" and explain what
it *means* to check out the branch.
I am not sure "Reflect" is a good word. Making the result similar
to the branch is only one aspect of the act of checking out the
branch. The other equally important aspect is that this is done to
advance the history of the branch.
Perhaps...
Prepare to work on building new history on <branch>, by
pointing the HEAD to the branch and updating the index and
the files in the working tree. Local modifications to the
files in the working tree are kept, so that they can be
committed on the <branch>.
> 'git checkout' -b|-B <new_branch> [<start point>]::
>
> + Specifying `-b` causes a new branch to be created as if
> + linkgit:git-branch[1] were called and then checked out. In
> + this case you can use the `--track` or `--no-track` options,
> + which will be passed to 'git branch'. As a convenience,
> + `--track` without `-b` implies branch creation; see the
> + description of `--track` below.
> +
> If `-B` is given, <new_branch> is created if it doesn't exist; otherwise, it
> is reset. This is the transactional equivalent of
> @@ -45,6 +46,13 @@ $ git checkout <branch>
> that is to say, the branch is not reset/created unless "git checkout" is
> successful.
>
> +'git checkout' [--detach] [<commit>]::
> +
> + Update the index and working tree to reflect the specified
> + commit and set HEAD to point directly to <commit> (see
> + "DETACHED HEAD" section.) Passing `--detach` forces this
> + behavior even if <commit> is a branch.
Prepare to work on building new history on top of <commit>,
by detaching HEAD at the commit and ...(likewise)...
^ permalink raw reply
* [PATCH v3 2/4] Makefile: detect when PYTHON_PATH changes
From: Christian Couder @ 2012-12-17 7:17 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 v3 4/4] Makefile: replace "echo 1>..." with "echo >..."
From: Christian Couder @ 2012-12-17 7:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This is clearer to many people this way.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Makefile | 10 +++++-----
git-gui/Makefile | 6 +++---
gitk-git/Makefile | 2 +-
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Makefile b/Makefile
index 7db8445..e055c9a 100644
--- a/Makefile
+++ b/Makefile
@@ -2183,7 +2183,7 @@ endef
GIT-SCRIPT-DEFINES: FORCE
@FLAGS='$(SCRIPT_DEFINES)'; \
if test x"$$FLAGS" != x"`cat $@ 2>/dev/null`" ; then \
- echo 1>&2 " * new script parameters"; \
+ echo >&2 " * new script parameters"; \
echo "$$FLAGS" >$@; \
fi
@@ -2564,7 +2564,7 @@ TRACK_PREFIX = $(bindir_SQ):$(gitexecdir_SQ):$(template_dir_SQ):$(prefix_SQ):\
GIT-PREFIX: FORCE
@FLAGS='$(TRACK_PREFIX)'; \
if test x"$$FLAGS" != x"`cat GIT-PREFIX 2>/dev/null`" ; then \
- echo 1>&2 " * new prefix flags"; \
+ echo >&2 " * new prefix flags"; \
echo "$$FLAGS" >GIT-PREFIX; \
fi
@@ -2573,7 +2573,7 @@ TRACK_CFLAGS = $(CC):$(subst ','\'',$(ALL_CFLAGS)):$(USE_GETTEXT_SCHEME)
GIT-CFLAGS: FORCE
@FLAGS='$(TRACK_CFLAGS)'; \
if test x"$$FLAGS" != x"`cat GIT-CFLAGS 2>/dev/null`" ; then \
- echo 1>&2 " * new build flags"; \
+ echo >&2 " * new build flags"; \
echo "$$FLAGS" >GIT-CFLAGS; \
fi
@@ -2582,7 +2582,7 @@ TRACK_LDFLAGS = $(subst ','\'',$(ALL_LDFLAGS))
GIT-LDFLAGS: FORCE
@FLAGS='$(TRACK_LDFLAGS)'; \
if test x"$$FLAGS" != x"`cat GIT-LDFLAGS 2>/dev/null`" ; then \
- echo 1>&2 " * new link flags"; \
+ echo >&2 " * new link flags"; \
echo "$$FLAGS" >GIT-LDFLAGS; \
fi
@@ -2631,7 +2631,7 @@ 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 >&2 " * new Python interpreter location"; \
echo "$$VARS" >$@; \
fi
endif
diff --git a/git-gui/Makefile b/git-gui/Makefile
index e22ba5c..e9c2bc3 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -254,7 +254,7 @@ lib/tclIndex: $(ALL_LIBFILES) GIT-GUI-VARS
auto_mkindex lib '*.tcl' \
| $(TCL_PATH) $(QUIET_2DEVNULL); then : ok; \
else \
- echo 1>&2 " * $(TCL_PATH) failed; using unoptimized loading"; \
+ echo >&2 " * $(TCL_PATH) failed; using unoptimized loading"; \
rm -f $@ ; \
echo '# Autogenerated by git-gui Makefile' >$@ && \
echo >>$@ && \
@@ -274,8 +274,8 @@ TRACK_VARS = \
GIT-GUI-VARS: FORCE
@VARS='$(TRACK_VARS)'; \
if test x"$$VARS" != x"`cat $@ 2>/dev/null`" ; then \
- echo 1>&2 " * new locations or Tcl/Tk interpreter"; \
- echo 1>$@ "$$VARS"; \
+ echo >&2 " * new locations or Tcl/Tk interpreter"; \
+ echo >$@ "$$VARS"; \
fi
ifdef GITGUI_MACOSXAPP
diff --git a/gitk-git/Makefile b/gitk-git/Makefile
index 5acdc90..c2df22f 100644
--- a/gitk-git/Makefile
+++ b/gitk-git/Makefile
@@ -23,7 +23,7 @@ TRACK_TCLTK = $(subst ','\'',-DTCLTK_PATH='$(TCLTK_PATH_SQ)')
GIT-TCLTK-VARS: FORCE
@VARS='$(TRACK_TCLTK)'; \
if test x"$$VARS" != x"`cat $@ 2>/dev/null`" ; then \
- echo 1>&2 " * new Tcl/Tk interpreter location"; \
+ echo >&2 " * new Tcl/Tk interpreter location"; \
echo "$$VARS" >$@; \
fi
--
1.8.1.rc1.2.g8740035
^ permalink raw reply related
* [PATCH v3 1/4] Makefile: remove tracking of TCLTK_PATH
From: Christian Couder @ 2012-12-17 7:17 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.
Maybe this code should have been moved to gitk-git/Makefile by
62ba514 (Move gitk to its own subdirectory, 2007-11-17).
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 v3 3/4] gitk-git/Makefile: track TCLTK_PATH as it used to be tracked
From: Christian Couder @ 2012-12-17 7:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In 62ba514 (Move gitk to its own subdirectory, 2007-11-17) some
code used to track TCLTK_PATH was left in the main Makefile instead
of being moved to the new Makefile that was created in gitk-git/.
The code left in the main Makefile should have been removed by a
previous patch in the same series as this one.
And this patch puts some code back to track TCLTK_PATH properly
where it should be, that is in gitk-git/Makefile.
Note that there is already some code to do that in git-gui/Makefile.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
.gitignore | 1 -
gitk-git/.gitignore | 2 ++
gitk-git/Makefile | 16 ++++++++++++++--
3 files changed, 16 insertions(+), 3 deletions(-)
create mode 100644 gitk-git/.gitignore
diff --git a/.gitignore b/.gitignore
index 086c5af..56a4b2b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -171,7 +171,6 @@
/git-whatchanged
/git-write-tree
/git-core-*/?*
-/gitk-git/gitk-wish
/gitweb/GITWEB-BUILD-OPTIONS
/gitweb/gitweb.cgi
/gitweb/static/gitweb.js
diff --git a/gitk-git/.gitignore b/gitk-git/.gitignore
new file mode 100644
index 0000000..d7ebcaf
--- /dev/null
+++ b/gitk-git/.gitignore
@@ -0,0 +1,2 @@
+/GIT-TCLTK-VARS
+/gitk-wish
diff --git a/gitk-git/Makefile b/gitk-git/Makefile
index e1b6045..5acdc90 100644
--- a/gitk-git/Makefile
+++ b/gitk-git/Makefile
@@ -17,6 +17,16 @@ DESTDIR_SQ = $(subst ','\'',$(DESTDIR))
bindir_SQ = $(subst ','\'',$(bindir))
TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
+### Detect Tck/Tk interpreter path changes
+TRACK_TCLTK = $(subst ','\'',-DTCLTK_PATH='$(TCLTK_PATH_SQ)')
+
+GIT-TCLTK-VARS: FORCE
+ @VARS='$(TRACK_TCLTK)'; \
+ if test x"$$VARS" != x"`cat $@ 2>/dev/null`" ; then \
+ echo 1>&2 " * new Tcl/Tk interpreter location"; \
+ echo "$$VARS" >$@; \
+ fi
+
## po-file creation rules
XGETTEXT ?= xgettext
ifdef NO_MSGFMT
@@ -49,9 +59,9 @@ uninstall::
$(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
clean::
- $(RM) gitk-wish po/*.msg
+ $(RM) gitk-wish po/*.msg GIT-TCLTK-VARS
-gitk-wish: gitk
+gitk-wish: gitk GIT-TCLTK-VARS
$(QUIET_GEN)$(RM) $@ $@+ && \
sed -e '1,3s|^exec .* "$$0"|exec $(subst |,'\|',$(TCLTK_PATH_SQ)) "$$0"|' <gitk >$@+ && \
chmod +x $@+ && \
@@ -65,3 +75,5 @@ $(ALL_MSGFILES): %.msg : %.po
@echo Generating catalog $@
$(MSGFMT) --statistics --tcl $< -l $(basename $(notdir $<)) -d $(dir $@)
+.PHONY: all install uninstall clean update-po
+.PHONY: FORCE
--
1.8.1.rc1.2.g8740035
^ permalink raw reply related
* Re: How to specify remote branch correctly
From: Woody Wu @ 2012-12-17 7:02 UTC (permalink / raw)
To: git
In-Reply-To: <1355722245-ner-6603@calvin>
On 2012-12-17, Tomas Carnecky <tomas.carnecky@gmail.com> wrote:
> 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.
I think this is what exactly happened to me in the first time I got the
'foo'. One new thing to me is the '-t'. I am not sure wether the '-t'
was used or not in the background. How do I check the 'upstream'
relationships? Is there any file under .git recoreded that kind of
information?
--
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: Woody Wu @ 2012-12-17 6:48 UTC (permalink / raw)
To: git
In-Reply-To: <CAH5451kmTW+nO4V4pjSdaqhHAb=RX-tawLo=rJfuPnDRDWeSEA@mail.gmail.com>
On 2012-12-17, 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.
>
>> 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.
>
Andre, by this in further exaplaination, I think I fully understood.
Thanks a lot!
--
woody
I can't go back to yesterday - because I was a different person then.
^ permalink raw reply
* [PATCH 2/2] Documentation/git-checkout.txt: document 70c9ac2 behavior
From: Chris Rorvick @ 2012-12-17 6:45 UTC (permalink / raw)
To: git; +Cc: Chris Rorvick, Andrew Ardill, Tomas Carnecky, Woody Wu
In-Reply-To: <1355726702-27974-1-git-send-email-chris@rorvick.com>
Document the behavior implemented in 70c9ac2 (DWIM "git checkout
frotz" to "git checkout -b frotz origin/frotz").
Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
Documentation/git-checkout.txt | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index a47555c..db89cf7 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -25,6 +25,14 @@ branch.
Update the index, working tree, and HEAD to reflect the
specified branch.
++
+If <branch> is not found but there does exist a tracking branch in
+exactly one remote (call it <remote>) with a matching name, treat as
+equivalent to
++
+------------
+$ git checkout -b <branch> --track <remote>/<branch>
+------------
'git checkout' -b|-B <new_branch> [<start point>]::
--
1.8.1.rc1.203.g1ddc124
^ permalink raw reply related
* [PATCH 1/2] Documentation/git-checkout.txt: clarify usage
From: Chris Rorvick @ 2012-12-17 6:45 UTC (permalink / raw)
To: git; +Cc: Chris Rorvick, Andrew Ardill, Tomas Carnecky, Woody Wu
In-Reply-To: <1355726702-27974-1-git-send-email-chris@rorvick.com>
The forms of checkout that do not take a path are lumped together in the
DESCRIPTION section, but the description for this group is dominated by
explanation of the -b|-B form. Split these apart for more clarity.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
Documentation/git-checkout.txt | 26 +++++++++++++++++---------
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 7958a47..a47555c 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -22,17 +22,18 @@ also update `HEAD` to set the specified branch as the current
branch.
'git checkout' [<branch>]::
+
+ Update the index, working tree, and HEAD to reflect the
+ specified branch.
+
'git checkout' -b|-B <new_branch> [<start point>]::
-'git checkout' [--detach] [<commit>]::
- This form switches branches by updating the index, working
- tree, and HEAD to reflect the specified branch or commit.
-+
-If `-b` is given, a new branch is created as if linkgit:git-branch[1]
-were called and then checked out; in this case you can
-use the `--track` or `--no-track` options, which will be passed to
-'git branch'. As a convenience, `--track` without `-b` implies branch
-creation; see the description of `--track` below.
+ Specifying `-b` causes a new branch to be created as if
+ linkgit:git-branch[1] were called and then checked out. In
+ this case you can use the `--track` or `--no-track` options,
+ which will be passed to 'git branch'. As a convenience,
+ `--track` without `-b` implies branch creation; see the
+ description of `--track` below.
+
If `-B` is given, <new_branch> is created if it doesn't exist; otherwise, it
is reset. This is the transactional equivalent of
@@ -45,6 +46,13 @@ $ git checkout <branch>
that is to say, the branch is not reset/created unless "git checkout" is
successful.
+'git checkout' [--detach] [<commit>]::
+
+ Update the index and working tree to reflect the specified
+ commit and set HEAD to point directly to <commit> (see
+ "DETACHED HEAD" section.) Passing `--detach` forces this
+ behavior even if <commit> is a branch.
+
'git checkout' [-p|--patch] [<tree-ish>] [--] <pathspec>...::
When <paths> or `--patch` are given, 'git checkout' does *not*
--
1.8.1.rc1.203.g1ddc124
^ permalink raw reply related
* [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
* 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
* 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: 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: [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: 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: 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
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