* [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
* [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 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
* 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
* 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
* [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
* [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 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 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
* 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
* Re: [PATCH 2/2] Documentation/git-checkout.txt: document 70c9ac2 behavior
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-3-git-send-email-chris@rorvick.com>
Chris Rorvick <chris@rorvick.com> writes:
> 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>]::
Thanks; does it format well (I didn't check)?
^ permalink raw reply
* Re: How to specify remote branch correctly
From: Tomas Carnecky @ 2012-12-17 7:21 UTC (permalink / raw)
To: Woody Wu, git
In-Reply-To: <slrnkctgqh.mmj.narkewoody@zuhnb712.local.com>
On Mon, 17 Dec 2012 07:02:46 +0000, Woody Wu <narkewoody@gmail.com> wrote:
> On 2012-12-17, 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.
>
> 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?
Yes, that information is recorded in a file somewhere in .git. However, for
most users it's irrelevant which file it is. Git has commands to access this
information. Try one of these:
git branch -vv
git remote show origin
git rev-parse --abbrev-ref --symbolic-full-name @{u}
^ permalink raw reply
* What's cooking in git.git (Dec 2012, #04; Sun, 16)
From: Junio C Hamano @ 2012-12-17 7:22 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The tip of the 'master' branch is 1.8.1-rc2; hopefully we can go
final around the end of next week.
Many topics are getting into good shape in 'next', hopefully ready
to be merged soon after the 1.8.1 final.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* ja/directory-attrs (2012-12-13) 2 commits
- [squash] simplify find-basename in attr.c
- Add directory pattern matching to attributes
The attribute mechanism didn't allow limiting attributes to be
applied to only a single directory itself with "path/" like the
exclude mechanism does.
Will merge to 'next' after squashing the microfix.
* jk/mailmap-cleanup (2012-12-12) 5 commits
- contrib: update stats/mailmap script
- .mailmap: normalize emails for Linus Torvalds
- .mailmap: normalize emails for Jeff King
- .mailmap: fix broken entry for Martin Langhoff
- .mailmap: match up some obvious names/emails
Update various entries in our .mailmap file.
Will merge to 'next'.
* jk/mailmap-from-blob (2012-12-13) 5 commits
- mailmap: default mailmap.blob in bare repositories
- mailmap: fix some documentation loose-ends for mailmap.blob
- mailmap: clean up read_mailmap error handling
- mailmap: support reading mailmap from blobs
- mailmap: refactor mailmap parsing for non-file sources
Allow us to read, and default to read, mailmap files from the tip
of the history in bare repositories. This will help running tools
like shortlog in server settings.
Will merge to 'next'.
* nd/index-format-doc (2012-12-13) 1 commit
- index-format.txt: clarify what is "invalid"
Will merge to 'next'.
* as/doc-for-devs (2012-12-16) 2 commits
- Documentation: move support for old compilers to CodingGuidelines
- SubmittingPatches: add convention of prefixing commit messages
It might be a better idea to move the text the bottom one adds to
the extended description from the quick checklist part.
* cc/no-git-gui-rebuild-depend (2012-12-16) 2 commits
- Makefile: detect when PYTHON_PATH changes
- Makefile: remove tracking of TCLTK_PATH
The bottom one associates the issue with git-gui, but what it
removes is a remnant of gitk support when it did not have a
separate Makefile; we may need to add the logic there.
* dm/port (2012-12-15) 3 commits
- Generalize the inclusion of strings.h
- Detect when the passwd struct is missing pw_gecos
- Support builds when sys/param.h is missing
It could turn out that we may be able to get rid of sys/param.h
altogether, but one step at a time. Inputs from people on minority
platforms are very much appreciated---does your platform build fine
when the inclusion of the file is removed from git-compat-util.h?
Will merge to 'next'.
* jc/fetch-tags-doc (2012-12-13) 1 commit
- fetch --tags: clarify documentation
The explanation for "fetch --tags" was actually talking more about
"fetch --no-tags". Clariify what "--tags" really means.
Will merge to 'next'.
* jk/avoid-mailto-invalid-in-doc (2012-12-16) 1 commit
- Documentation: don't link to example mail addresses
Avoids invalid sample e-mail addresses from becoming mailto links
in the formatted output, which by itself is "Meh" for me (who
cares?) but it highlights some issues with ``pretty quotes''.
Will merge to 'next'.
* jk/complete-commit-c (2012-12-15) 1 commit
- completion: complete refs for "git commit -c"
Complete "git commmit -c foo<TAB>" into a refname that begins with
"foo".
Will merge to 'next'.
* jk/error-const-return (2012-12-15) 2 commits
- silence some -Wuninitialized false positives
- make error()'s constant return value more visible
Help compilers' flow analysis by making it more explicit that
error() always returns -1, to reduce false "variable used
uninitialized" warnings.
This is still an RFC.
* mk/qnx (2012-12-15) 2 commits
- Port to QNX
- Make lock local to fetch_pack
Port to QNX; we may want to rebase this on top of dm/port topic as
it also wants to use the HAVE_STRINGS_H mechanism it introduces.
* rj/maint-cygwin-say-color (2012-12-15) 1 commit
- tests: Allow customization of how say_color() prints
Even though I do not think of a cleaner way to do this, I am not
happy with the way how $GIT_TEST_PRINT and $GIT_TEST_PRINT_LN are
interpolated into the command line with token splitting at $IFS.
* sl/readme-gplv2 (2012-12-15) 2 commits
- README: it does not matter who the current maintainer is
- README: Git is released under the GPLv2, not just "the GPL"
Clarify that the project as a whole is GPLv2 only, with some parts
borrowed under different licenses that are compatible with GPLv2.
Will merge to 'next'.
* ta/api-index-doc (2012-12-16) 1 commit
- Remove misleading date from api-index-skel.txt
Will merge to 'next'.
--------------------------------------------------
[Graduated to "master"]
* mh/doc-remote-helpers (2012-12-07) 6 commits
(merged to 'next' on 2012-12-07 at 7ac8c25)
+ git-remote-helpers.txt: clarify options & ref list attributes
+ git-remote-helpers.txt: clarify command <-> capability correspondences
+ git-remote-helpers.txt: rearrange description of capabilities
+ git-remote-helpers.txt: minor grammar fix
+ git-remote-helpers.txt: document missing capabilities
+ git-remote-helpers.txt: document invocation before input format
--------------------------------------------------
[Stalled]
* jc/merge-blobs (2012-12-13) 5 commits
- [broken] wip to fix d/f conflicts
- merge-tree: add comments to clarify what these functions are doing
- merge-tree: lose unused "resolve_directories"
- merge-tree: lose unused "flags" from merge_list
- Which merge_file() function do you mean?
A beginning of a new merge strategy based on the disused merge-tree
proof-of-concept code.
* jc/doc-maintainer (2012-11-27) 1 commit
- update "howto maintain git"
An early draft that is still incomplete.
* fc/remote-bzr (2012-12-13) 10 commits
- (fixup) test-bzr.sh: fix multi-line string assignment
- remote-bzr: detect local repositories
- remote-bzr: add support for older versions of bzr
- remote-bzr: add support to push special modes
- remote-bzr: add support for fecthing special modes
- remote-bzr: add simple tests
- remote-bzr: update working tree upon pushing
- remote-bzr: add support for remote repositories
- remote-bzr: add support for pushing
- Add new remote-bzr transport helper
New remote helper for bzr (v3). With minor fixes, this may be ready
for 'next'.
* mo/cvs-server-updates (2012-12-09) 18 commits
- t9402: Use TABs for indentation
- t9402: Rename check.cvsCount and check.list
- t9402: Simplify git ls-tree
- t9402: Add missing &&; Code style
- t9402: No space after IO-redirection
- t9402: Dont use test_must_fail cvs
- t9402: improve check_end_tree() and check_end_full_tree()
- t9402: sed -i is not portable
- cvsserver Documentation: new cvs ... -r support
- cvsserver: add t9402 to test branch and tag refs
- cvsserver: support -r and sticky tags for most operations
- cvsserver: Add version awareness to argsfromdir
- cvsserver: generalize getmeta() to recognize commit refs
- cvsserver: implement req_Sticky and related utilities
- cvsserver: add misc commit lookup, file meta data, and file listing functions
- cvsserver: define a tag name character escape mechanism
- cvsserver: cleanup extra slashes in filename arguments
- cvsserver: factor out git-log parsing logic
Needs review by folks interested in cvsserver.
* as/check-ignore (2012-11-08) 14 commits
- t0007: fix tests on Windows
- Documentation/check-ignore: we show the deciding match, not the first
- Add git-check-ignore sub-command
- dir.c: provide free_directory() for reclaiming dir_struct memory
- pathspec.c: move reusable code from builtin/add.c
- dir.c: refactor treat_gitlinks()
- dir.c: keep track of where patterns came from
- dir.c: refactor is_path_excluded()
- dir.c: refactor is_excluded()
- dir.c: refactor is_excluded_from_list()
- dir.c: rename excluded() to is_excluded()
- dir.c: rename excluded_from_list() to is_excluded_from_list()
- dir.c: rename path_excluded() to is_path_excluded()
- dir.c: rename cryptic 'which' variable to more consistent name
Duy helped to reroll this.
Expecting a re-roll.
* aw/rebase-am-failure-detection (2012-10-11) 1 commit
- rebase: Handle cases where format-patch fails
I am unhappy a bit about the possible performance implications of
having to store the output in a temporary file only for a rare case
of format-patch aborting.
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* fc/remote-testgit-feature-done (2012-10-29) 1 commit
- remote-testgit: properly check for errors
Needs review and Ack (or Nack) from people involved in the remote
helper interface for this to move forward.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
(merged to 'next' on 2012-10-29 at af52cef)
+ Teach git-completion about git p4
Comment from Pete will need to be addressed in a follow-up patch.
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/blame-no-follow (2012-09-21) 2 commits
- blame: pay attention to --no-follow
- diff: accept --no-follow option
Teaches "--no-follow" option to "git blame" to disable its
whole-file rename detection.
Stalled mostly due to lack of responses.
* jc/doc-default-format (2012-11-26) 2 commits
- [SQAUSH] allow "cd Doc* && make DEFAULT_DOC_TARGET=..."
- Allow generating a non-default set of documentation
Need to address the installation half if this is to be any useful.
* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
- graph.c: infinite loop in git whatchanged --graph -m
The --graph code fell into infinite loop when asked to do what the
code did not expect ;-)
Anybody who worked on "--graph" wants to comment?
Stalled mostly due to lack of responses.
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Waiting for comments.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a re-roll.
"The first remote becomes the default" bit is better done as a
separate step.
--------------------------------------------------
[Cooking]
* as/test-tweaks (2012-12-16) 8 commits
- tests: paint unexpectedly fixed known breakages in bold red
- tests: test the test framework more thoroughly
- (squash) dq $name
- tests: refactor mechanics of testing in a sub test-lib
- tests: change info messages from yellow/brown to bold cyan
- tests: paint skipped tests in bold blue
- tests: paint known breakages in bold yellow
- tests: test number comes first in 'not ok $count - $message'
Various minor tweaks to the test framework to paint its output
lines in colors that match what they mean better.
Will merge to 'next' after squashing the microfix.
* sp/shortlog-missing-lf (2012-12-11) 2 commits
(merged to 'next' on 2012-12-11 at 64b8429)
+ strbuf_add_wrapped*(): Remove unused return value
+ shortlog: fix wrapping lines of wraplen
When a line to be wrapped has a solid run of non space characters
whose length exactly is the wrap width, "git shortlog -w" failed to
add a newline after such a line.
Will cook in 'next'.
* ap/log-mailmap (2012-12-15) 7 commits
- test: Add test for --use-mailmap option
- log: Add --use-mailmap option
- pretty: Use mailmap to display username and email
- mailmap: Add mailmap structure to rev_info and pp
- mailmap: Simplify map_user() interface
- mailmap: Remove buffer length limit in map_user
- Use split_ident_line to parse author and committer
Clean up various codepaths around mailmap and teach the "log"
machinery to use it.
Will merge to 'next' after reading it over once again.
* jc/fetch-ignore-symref (2012-12-11) 1 commit
- fetch: ignore wildcarded refspecs that update local symbolic refs
Avoid false error from an attempt to update local symbolic ref via
fetch.
Will merge to 'next'.
* md/gitweb-sort-by-age (2012-12-11) 1 commit
(merged to 'next' on 2012-12-13 at 9f39410)
+ gitweb: Sort projects with undefined ages last
Gitweb showed repositories without any commit at the top in its
age-sorted view, in which the users are interested in looking at
active projects; sorting them at the bottom makes it more useful.
Will cook in 'next'.
* ss/nedmalloc-compilation (2012-12-11) 1 commit
(merged to 'next' on 2012-12-13 at c1f0d7f)
+ nedmalloc: Fix a compile warning (exposed as error) with GCC 4.7.2
Will cook in 'next'.
* wk/submodule-update-remote (2012-12-12) 3 commits
- submodule add: If --branch is given, record it in .gitmodules
- submodule update: add --remote for submodule's upstream changes
- submodule: add get_submodule_config helper funtion
Expecting a re-roll.
* jc/maint-fbsd-sh-ifs-workaround (2012-12-10) 1 commit
(merged to 'next' on 2012-12-11 at 6659fdc)
+ sh-setup: work around "unset IFS" bug in some shells
Will cook in 'next'.
* jc/same-encoding (2012-12-10) 1 commit
- format_commit_message(): simplify calls to logmsg_reencode()
Finishing touches to the series to unify "Do we need to reencode
between these two encodings?" logic.
Will merge to 'next'.
* nd/invalidate-i-t-a-cache-tree (2012-12-15) 4 commits
- cache-tree: invalidate i-t-a paths after generating trees
- cache-tree: fix writing cache-tree when CE_REMOVE is present
- cache-tree: replace "for" loops in update_one with "while" loops
- cache-tree: remove dead i-t-a code in verify_cache()
Writing out a tree object when you still have intent-to-add entries
in the index left an incorrect cache-tree data there.
Will merge to 'next'.
* jl/submodule-deinit (2012-12-04) 1 commit
(merged to 'next' on 2012-12-07 at ea772f0)
+ submodule: add 'deinit' command
There was no Porcelain way to say "I no longer am interested in
this submodule", once you express your interest in a submodule with
"submodule init". "submodule deinit" is the way to do so.
Will cook in 'next'.
* sl/git-svn-docs (2012-12-05) 4 commits
(merged to 'next' on 2012-12-07 at 5bfbb73)
+ git-svn: Note about tags.
+ git-svn: Expand documentation for --follow-parent
+ git-svn: Recommend use of structure options.
+ git-svn: Document branches with at-sign(@).
Will cook in 'next'.
* pf/editor-ignore-sigint (2012-12-02) 5 commits
(merged to 'next' on 2012-12-07 at 6b04419)
+ launch_editor: propagate signals from editor to git
+ run-command: do not warn about child death from terminal
+ launch_editor: ignore terminal signals while editor has control
+ launch_editor: refactor to use start/finish_command
+ run-command: drop silent_exec_failure arg from wait_or_whine
Avoid confusing cases where the user hits Ctrl-C while in the editor
session, not realizing git will receive the signal. Since most editors
will take over the terminal and will block SIGINT, this is not likely
to confuse anyone.
Will cook in 'next'.
* bc/append-signed-off-by (2012-11-26) 11 commits
- Unify appending signoff in format-patch, commit and sequencer
- format-patch: update append_signoff prototype
- format-patch: stricter S-o-b detection
- t4014: more tests about appending s-o-b lines
- sequencer.c: teach append_signoff to avoid adding a duplicate newline
- sequencer.c: teach append_signoff how to detect duplicate s-o-b
- sequencer.c: always separate "(cherry picked from" from commit body
- sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
- t/t3511: add some tests of 'cherry-pick -s' functionality
- t/test-lib-functions.sh: allow to specify the tag name to test_commit
- sequencer.c: remove broken support for rfc2822 continuation in footer
Expecting a re-roll after a review.
* mh/unify-xml-in-imap-send-and-http-push (2012-12-02) 8 commits
(merged to 'next' on 2012-12-03 at d677090)
+ wrap_in_html(): process message in bulk rather than line-by-line
+ wrap_in_html(): use strbuf_addstr_xml_quoted()
+ imap-send: change msg_data from storing (ptr, len) to storing strbuf
+ imap-send: correctly report errors reading from stdin
+ imap-send: store all_msgs as a strbuf
+ lf_to_crlf(): NUL-terminate msg_data::data
+ xml_entities(): use function strbuf_addstr_xml_quoted()
+ Add new function strbuf_add_xml_quoted()
Update imap-send to reuse xml quoting code from http-push codepath,
clean up some code, and fix a small bug.
Will cook in 'next'.
* jk/fsck-dot-in-trees (2012-11-28) 2 commits
(merged to 'next' on 2012-11-28 at 519dabc)
+ fsck: warn about ".git" in trees
+ fsck: warn about '.' and '..' in trees
Will cook in 'next'.
* mh/pthreads-autoconf (2012-11-27) 1 commit
(merged to 'next' on 2012-11-28 at 780600e)
+ configure.ac: fix pthreads detection on Mac OS X
Will cook in 'next'.
* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
(merged to 'next' on 2012-11-28 at 43d51c2)
+ config: exit on error accessing any config file
+ doc: advertise GIT_CONFIG_NOSYSTEM
+ config: treat user and xdg config permission problems as errors
+ config, gitignore: failure to access with ENOTDIR is ok
An RFC to deal with a situation where .config/git is a file and we
notice .config/git/config is not readable due to ENOTDIR, not
ENOENT.
Will cook in 'next'.
* mh/ceiling (2012-10-29) 8 commits
(merged to 'next' on 2012-11-26 at d1ce76a)
+ string_list_longest_prefix(): remove function
+ setup_git_directory_gently_1(): resolve symlinks in ceiling paths
+ longest_ancestor_length(): require prefix list entries to be normalized
+ longest_ancestor_length(): take a string_list argument for prefixes
+ longest_ancestor_length(): use string_list_split()
+ Introduce new function real_path_if_valid()
+ real_path_internal(): add comment explaining use of cwd
+ Introduce new static function real_path_internal()
Elements of GIT_CEILING_DIRECTORIES list may not match the real
pathname we obtain from getcwd(), leading the GIT_DIR discovery
logic to escape the ceilings the user thought to have specified.
Resurrected from Stalled; the earlier performance fear was
unwarranted.
Will cook in 'next'.
* fc/fast-export-fixes (2012-12-03) 15 commits
(merged to 'next' on 2012-12-03 at f9df523)
+ fast-export: make sure updated refs get updated
+ fast-export: don't handle uninteresting refs
+ fast-export: fix comparison in tests
+ fast-export: trivial cleanup
+ remote-testgit: implement the "done" feature manually
+ remote-testgit: report success after an import
+ remote-testgit: exercise more features
+ remote-testgit: cleanup tests
+ remote-testgit: remove irrelevant test
+ remote-testgit: remove non-local functionality
+ Add new simplified git-remote-testgit
+ Rename git-remote-testgit to git-remote-testpy
+ remote-helpers: fix failure message
+ remote-testgit: fix direction of marks
+ fast-export: avoid importing blob marks
Will cook in 'next'.
* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
(merged to 'next' on 2012-11-26 at 3af69e7)
+ apply.c:update_pre_post_images(): the preimage can be truncated
Fix to update_pre_post_images() that did not take into account the
possibility that whitespace fix could shrink the preimage and
change the number of lines in it.
Will cook in 'next'.
* nd/pathspec-wildcard (2012-11-26) 4 commits
(merged to 'next' on 2012-12-03 at eca0fcb)
+ tree_entry_interesting: do basedir compare on wildcard patterns when possible
+ pathspec: apply "*.c" optimization from exclude
+ pathspec: do exact comparison on the leading non-wildcard part
+ pathspec: save the non-wildcard length part
Will cook in 'next'.
* nd/wildmatch (2012-12-15) 15 commits
(merged to 'next' on 2012-12-15 at c734714)
+ t3070: Disable some failing fnmatch tests
(merged to 'next' on 2012-11-21 at 151288f)
+ test-wildmatch: avoid Windows path mangling
(merged to 'next' on 2012-10-25 at 510e8df)
+ Support "**" wildcard in .gitignore and .gitattributes
+ wildmatch: make /**/ match zero or more directories
+ wildmatch: adjust "**" behavior
+ wildmatch: fix case-insensitive matching
+ wildmatch: remove static variable force_lower_case
+ wildmatch: make wildmatch's return value compatible with fnmatch
+ t3070: disable unreliable fnmatch tests
+ Integrate wildmatch to git
+ wildmatch: follow Git's coding convention
+ wildmatch: remove unnecessary functions
+ Import wildmatch from rsync
+ ctype: support iscntrl, ispunct, isxdigit and isprint
+ ctype: make sane_ctype[] const array
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
I suspect that this needs to be plugged to pathspec matching code;
otherwise "git log -- 'Docum*/**/*.txt'" would not show the log for
commits that touch Documentation/git.txt, which would be confusing
to the users.
Will cook in 'next'.
* cr/push-force-tag-update (2012-12-03) 10 commits
(merged to 'next' on 2012-12-04 at af2e3a9)
+ push: allow already-exists advice to be disabled
+ push: rename config variable for more general use
+ push: cleanup push rules comment
+ push: clarify rejection of update to non-commit-ish
+ push: require force for annotated tags
+ push: require force for refs under refs/tags/
+ push: flag updates that require force
+ push: keep track of "update" state separately
+ push: add advice for rejected tag reference
+ push: return reject reasons as a bitset
Require "-f" for push to update a tag, even if it is a fast-forward.
Will cook in 'next'.
^ permalink raw reply
* Re: [PATCH v2 1/2] Makefile: remove tracking of TCLTK_PATH
From: Christian Couder @ 2012-12-17 7:22 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <7v4njlpaet.fsf@alter.siamese.dyndns.org>
From: Junio C Hamano <gitster@pobox.com>
>
> 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).
Yeah, I just sent an updated patch series that does this.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH 2/2] Documentation/git-checkout.txt: document 70c9ac2 behavior
From: Andrew Ardill @ 2012-12-17 7:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: Chris Rorvick, git@vger.kernel.org, Tomas Carnecky, Woody Wu
In-Reply-To: <7vd2y9nnyb.fsf@alter.siamese.dyndns.org>
On 17 December 2012 18:21, Junio C Hamano <gitster@pobox.com> wrote:
> does it format well (I didn't check)?
It applied cleanly for me on latest master, and the output looked
consistent with existing documentation.
Regards,
Andrew Ardill
^ permalink raw reply
* Re: [PATCH 2/2] Documentation/git-checkout.txt: document 70c9ac2 behavior
From: Junio C Hamano @ 2012-12-17 7:26 UTC (permalink / raw)
To: Andrew Ardill
Cc: Chris Rorvick, git@vger.kernel.org, Tomas Carnecky, Woody Wu
In-Reply-To: <CAH5451kutMLhjGJbeQ0gw_DC8sE_9r2Hjg1SvTa75B5n7eXO1g@mail.gmail.com>
Andrew Ardill <andrew.ardill@gmail.com> writes:
> On 17 December 2012 18:21, Junio C Hamano <gitster@pobox.com> wrote:
>> does it format well (I didn't check)?
>
> It applied cleanly for me on latest master, and the output looked
> consistent with existing documentation.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 1/2] Makefile: remove tracking of TCLTK_PATH
From: Junio C Hamano @ 2012-12-17 7:32 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <20121217.082241.794967023844368825.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> From: Junio C Hamano <gitster@pobox.com>
>>
>> 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).
>
> Yeah, I just sent an updated patch series that does this.
It still seems to talk about git-gui which the snippet you removed
does not have anything to do with, though.
^ permalink raw reply
* Re: [PATCH v3 3/4] gitk-git/Makefile: track TCLTK_PATH as it used to be tracked
From: Junio C Hamano @ 2012-12-17 7:33 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <20121217071716.26209.54407.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> 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 ++++++++++++++--
I'll apply the .gitignore part to my tree, but could you split the
rest out and have Paul apply to his tree at
git://ozlabs.org/~paulus/gitk.git
> 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
^ permalink raw reply
* Re: How to specify remote branch correctly
From: Woody Wu @ 2012-12-17 7:41 UTC (permalink / raw)
To: git
In-Reply-To: <1355728904-ner-4851@calvin>
On 2012-12-17, Tomas Carnecky <tomas.carnecky@gmail.com> wrote:
> On Mon, 17 Dec 2012 07:02:46 +0000, Woody Wu <narkewoody@gmail.com> wrote:
>> On 2012-12-17, 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.
>>
>> 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?
>
> Yes, that information is recorded in a file somewhere in .git. However, for
> most users it's irrelevant which file it is. Git has commands to access this
> information. Try one of these:
>
> git branch -vv
Run this on my local linux tree, I got:
lgf2410-2.6.16.4 7af1fda - added a ignore rule in .gitignore
(*~)
* lgf2410-2.6.34.13 50d3f9d ax88796b verbose debug output
lgf2410-2.6.34.13-16C554 3ec82e0 more debug on 16C554
master 9489e9d [origin/master] Linux 3.7-rc7
Does this mean, I only have local branch master tracked to remote?
> git remote show origin
Running this I got,
...
linux-3.1.y tracked
linux-3.2.y tracked
linux-3.3.y tracked
linux-3.4.y tracked
linux-3.5.y tracked
linux-3.6.y tracked
linux-3.7.y new (next fetch will store in remotes/origin)
master tracked
Local branch configured for 'git pull':
master rebases onto remote master
Local ref configured for 'git push':
master pushes to master (local out of date)
I am curious to know how the last 4 lines were printed by git.
-----
Local branch configured for 'git pull':
master rebases onto remote master
-----
If I have addtional branch other than master that also track to some
remote branch, will it also be listed under this 'git pull' line?
----
Local ref configured for 'git push':
master pushes to master (local out of date)
---
This I totally don't understand, what it mean? I think I did not do a
modification on the local 'master'.
Thanks!
--
woody
I can't go back to yesterday - because I was a different person then.
^ permalink raw reply
* Re: [BUG] Cannot push some grafted branches
From: Yann Dirson @ 2012-12-17 7:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7v38zb3ux0.fsf@alter.siamese.dyndns.org>
On Wed, 12 Dec 2012 11:57:47 -0800
Junio C Hamano <gitster@pobox.com> wrote:
> Yann Dirson <dirson@bertin.fr> writes:
>
> > .... In this respect, they seem to be
> > lacking a few features, when compared to "replace" refs, but they have different
> > uses, ...
>
> Not reallyl; grafts were old hack whose use is still supported with
> its original limitations; replace is meant to replace all uses of
> grafts while removing grafts' largest warts.
OK, I'll take this into account.
But this situation should probably be make more clear in the docs. Currently,
gitrepository-layout.txt describes refs/replace/ (and shallow) by reference to grafts,
and those are not marked as discouraged-use or anything.
And we may still want the bug fixed, or would we just list it as a known bug ?
At least it does not seem to occur with "replace" refs:
git-test$ rm .git/info/grafts
git-test$ echo "fake merge" | git commit-tree master^{tree} -p master^ -p maint
b821b2aa00973a47936d7cd25c9a5978b1c839c6
git-test$ git replace master b821b2aa00973a47936d7cd25c9a5978b1c839c6
git-test$ git push origin maint
...
50b03b0..79211fe maint -> maint
--
Yann Dirson - Bertin Technologies
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/git-checkout.txt: clarify usage
From: Johannes Sixt @ 2012-12-17 8:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Chris Rorvick, git, Andrew Ardill, Tomas Carnecky, Woody Wu
In-Reply-To: <7vhanlnnz7.fsf@alter.siamese.dyndns.org>
Am 12/17/2012 8:21, schrieb Junio C Hamano:
> Chris Rorvick <chris@rorvick.com> writes:
>> 'git checkout' [<branch>]::
Is <branch> really optional in this form?
BTW, what does plain 'git checkout' do? Just report ahead/behind information?
>> +
>> + Update the index, working tree, and HEAD to reflect the
>> + specified branch.
...
>> +'git checkout' [--detach] [<commit>]::
The title here is better spelled as two lines:
'git checkout' <commit>::
'git checkout' --detach <branch>::
I don't think that <commit> or <branch> should be indicated as optional here.
>> +
>> + 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)...
-- Hannes
^ permalink raw reply
* [PATCH] log --format: teach %C(auto,black) to paint it black only on terminals
From: Junio C Hamano @ 2012-12-17 8:40 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: Nguyen Thai Ngoc Duy, Srb, Michal, Jeff King
In-Reply-To: <7v7gojtbgr.fsf@alter.siamese.dyndns.org>
Traditionally, %C(color attr) always emitted the ANSI color
sequence; it was up to the scripts that wanted to conditionally
color their output to omit %C(...) specifier when they do not want
colors.
Optionally allow "auto," to be prefixed to the color, so that the
output is colored iff it goes to the terminal.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This time with minimum test and documentation.
Documentation/pretty-formats.txt | 4 +++-
pretty.c | 13 ++++++++++---
t/t6006-rev-list-format.sh | 30 ++++++++++++++++++++++++++----
3 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index d9edded..2af017c 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -144,7 +144,9 @@ The placeholders are:
- '%Cgreen': switch color to green
- '%Cblue': switch color to blue
- '%Creset': reset color
-- '%C(...)': color specification, as described in color.branch.* config option
+- '%C(...)': color specification, as described in color.branch.* config option;
+ adding `auto,` at the beginning will emit color only when the
+ output is going to a terminal
- '%m': left, right or boundary mark
- '%n': newline
- '%%': a raw '%'
diff --git a/pretty.c b/pretty.c
index dba6828..b9fd972 100644
--- a/pretty.c
+++ b/pretty.c
@@ -960,12 +960,19 @@ static size_t format_commit_one(struct strbuf *sb, const char *placeholder,
switch (placeholder[0]) {
case 'C':
if (placeholder[1] == '(') {
- const char *end = strchr(placeholder + 2, ')');
+ const char *begin = placeholder + 2;
+ const char *end = strchr(begin, ')');
char color[COLOR_MAXLEN];
+
if (!end)
return 0;
- color_parse_mem(placeholder + 2,
- end - (placeholder + 2),
+ if (!memcmp(begin, "auto,", 5)) {
+ if (!want_color(-1))
+ return end - placeholder + 1;
+ begin += 5;
+ }
+ color_parse_mem(begin,
+ end - begin,
"--pretty format", color);
strbuf_addstr(sb, color);
return end - placeholder + 1;
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index f94f0c4..bfcc1c6 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -11,12 +11,12 @@ touch foo && git add foo && git commit -m "added foo" &&
'
# usage: test_format name format_string <expected_output
-test_format() {
+test_format () {
cat >expect.$1
test_expect_success "format $1" "
-git rev-list --pretty=format:'$2' master >output.$1 &&
-test_cmp expect.$1 output.$1
-"
+ git rev-list --pretty=format:'$2'${3:+ $3} master >output.$1 &&
+ test_cmp expect.$1 output.$1
+ "
}
test_format percent %%h <<'EOF'
@@ -124,6 +124,28 @@ commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
^[[1;31;43mfoo^[[m
EOF
+test_format advanced-colors-auto \
+ '%C(auto,red yellow bold)foo%C(auto,reset)' --color <<'EOF'
+commit 131a310eb913d107dd3c09a65d1651175898735d
+foo
+commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+foo
+EOF
+
+# %C(auto,...) should trump --color=always
+#
+# NEEDSWORK: --color=never should also be tested but we need to run a
+# similar test under pseudo-terminal with test_terminal which is too
+# much hassle for its worth.
+
+test_format advanced-colors-forced \
+ '%C(auto,red yellow bold)foo%C(auto,reset)' --color=always <<'EOF'
+commit 131a310eb913d107dd3c09a65d1651175898735d
+foo
+commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+foo
+EOF
+
cat >commit-msg <<'EOF'
Test printing of complex bodies
--
1.8.1.rc2.126.ge9b7782
^ permalink raw reply related
* Re: [BUG] Cannot push some grafted branches
From: Thomas Rast @ 2012-12-17 8:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Yann Dirson, git list
In-Reply-To: <7v38zb3ux0.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Yann Dirson <dirson@bertin.fr> writes:
>
>> .... In this respect, they seem to be
>> lacking a few features, when compared to "replace" refs, but they have different
>> uses, ...
>
> Not reallyl; grafts were old hack whose use is still supported with
> its original limitations; replace is meant to replace all uses of
> grafts while removing grafts' largest warts.
I suppose there's the additional issue that grafts are much easier to
use than replacements if you really only want to replace some parent
lists. With replace you need to handcraft the replacement commits, and
git-replace(1) unhelpfully does not say this, much less gives an example
how to do it.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/git-checkout.txt: clarify usage
From: Junio C Hamano @ 2012-12-17 8:48 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Chris Rorvick, git, Andrew Ardill, Tomas Carnecky, Woody Wu
In-Reply-To: <50CED5D4.5040705@viscovery.net>
Here is what I tentatively have (so that I do not forget) on 'pu',
marked with "(squash???)", as a suggested update on top of Chris's
patches.
Documentation/git-checkout.txt | 29 +++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git c/Documentation/git-checkout.txt w/Documentation/git-checkout.txt
index db89cf7..0e50eeb 100644
--- c/Documentation/git-checkout.txt
+++ w/Documentation/git-checkout.txt
@@ -21,10 +21,13 @@ or the specified tree. If no paths are given, 'git checkout' will
also update `HEAD` to set the specified branch as the current
branch.
-'git checkout' [<branch>]::
+'git checkout' <branch>::
- Update the index, working tree, and HEAD to reflect the
- specified branch.
+ 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>.
+
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
@@ -33,6 +36,11 @@ equivalent to
------------
$ git checkout -b <branch> --track <remote>/<branch>
------------
++
+You could omit <branch>, in which case the command degenerates to
+"check out the current branch", which is a glorified no-op with a
+rather expensive side-effects to show only the tracking information,
+if exists, for the current branch.
'git checkout' -b|-B <new_branch> [<start point>]::
@@ -54,12 +62,17 @@ $ git checkout <branch>
that is to say, the branch is not reset/created unless "git checkout" is
successful.
-'git checkout' [--detach] [<commit>]::
+'git checkout' --detach [<commit>]::
+'git checkout' <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 (see "DETACHED HEAD"
+ section), 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>.
++
+Passing `--detach` forces this behavior even if <commit> is a branch.
'git checkout' [-p|--patch] [<tree-ish>] [--] <pathspec>...::
^ permalink raw reply related
* Re: [PATCH 1/2] Documentation/git-checkout.txt: clarify usage
From: Andrew Ardill @ 2012-12-17 8:53 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Chris Rorvick, git@vger.kernel.org,
Tomas Carnecky, Woody Wu
In-Reply-To: <50CED5D4.5040705@viscovery.net>
Regards,
Andrew Ardill
On 17 December 2012 19:20, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 12/17/2012 8:21, schrieb Junio C Hamano:
>> Chris Rorvick <chris@rorvick.com> writes:
>>> 'git checkout' [<branch>]::
>
> Is <branch> really optional in this form?
>
> BTW, what does plain 'git checkout' do? Just report ahead/behind information?
I think it defaults to either HEAD or the current branch, which shows
uncommitted changes and relationship to upstream.
>>> +
>>> + Update the index, working tree, and HEAD to reflect the
>>> + specified branch.
> ...
>>> +'git checkout' [--detach] [<commit>]::
>
> The title here is better spelled as two lines:
>
> 'git checkout' <commit>::
> 'git checkout' --detach <branch>::
>
> I don't think that <commit> or <branch> should be indicated as optional here.
doing 'git checkout --detach' will detach from the current branch if
you have one, but maybe listing <branch> as optional would work in
that case?
Here is my suggestion, differing from what Junio put forward primarily
by first indicating that a checkout is a 'switch' to a different
branch or commit. This makes sense to me, and is used elsewhere in the
documentation, so I thought it might make sense here too.
-->8--
From: Andrew Ardill <andrew.ardill@gmail.com>
Date: Mon, 17 Dec 2012 18:53:41 +1100
Subject: [PATCH] Documentation/git-checkout.txt: Use consistent terminology
git checkout is described as 'switching' branches in places. Use this
terminology more consistently.
Expand on the purpose of switching to a branch or commit, which is
typically to prepare to build history on top of that branch or commit.
Signed-off-by: Andrew Ardill <andrew.ardill@gmail.com>
---
Documentation/git-checkout.txt | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index db89cf7..e6db14f 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -23,8 +23,11 @@ branch.
'git checkout' [<branch>]::
- Update the index, working tree, and HEAD to reflect the
- specified branch.
+ Switch to the specified <branch>. Prepares for building new
+ history on <branch>, by updating the index and the files in the
+ working tree, and by pointing HEAD at the branch. Local
+ modifications to the files in the working tree are kept, so that
+ they can be committed on the <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
@@ -56,10 +59,13 @@ 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.
+ Switch to the specified <commit>. Prepares for building new
+ history on top of <commit>, by updating the index and the files
+ in the working tree, and by pointing HEAD at <commit>. Local
+ modifications to the files in the working tree are kept, so that
+ they can be committed on top of <commit>. Passing `--detach`
+ forces HEAD to point directly at <commit> even if <commit> is a
+ branch (see "DETACHED HEAD" section.)
'git checkout' [-p|--patch] [<tree-ish>] [--] <pathspec>...::
--
^ 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