* Re: Re: [PATCH v3 4/9] user-manual: Mention 'git remote add' for remote branch config
From: W. Trevor King @ 2013-02-18 2:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git, Jonathan Nieder
In-Reply-To: <7vwqu6cq7i.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 695 bytes --]
On Sun, Feb 17, 2013 at 06:26:25PM -0800, Junio C Hamano wrote:
> "W. Trevor King" <wking@tremily.us> writes:
> > -------------------------------------------------
> > +$ git fetch git://example.com/proj.git +refs/heads/*:refs/remotes/example/*
> > +$ git fetch example +refs/heads/*:refs/remotes/example/*
> > $ git fetch example
> > -------------------------------------------------
>
> These _three_ commands will do the same.
Oops. Feel free to fix this for me, and consider the revised version
signed off by me ;).
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v3 4/9] user-manual: Mention 'git remote add' for remote branch config
From: Junio C Hamano @ 2013-02-18 2:26 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git, Jonathan Nieder
In-Reply-To: <1ef8fd5d7754ef65a9aaf26250b7b9f0488ff59c.1361146398.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> I hardly ever setup remote.<name>.url using 'git config'. While it
> may be instructive to do so, we should also point out 'git remote
> add'.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
This looks like a good 'maint' material that can be applied straight
away there in preparation for 1.8.1.4 to me (modulo one nit);
reviewers watching from the sideline, please stop me if you see
issues.
> +After configuring the remote, the following two commands will do the
> +same thing:
>
> -------------------------------------------------
> +$ git fetch git://example.com/proj.git +refs/heads/*:refs/remotes/example/*
> +$ git fetch example +refs/heads/*:refs/remotes/example/*
> $ git fetch example
> -------------------------------------------------
These _three_ commands will do the same.
^ permalink raw reply
* Re: [PATCH v3 3/9] user-manual: Give 'git push -f' as an alternative to +master
From: Junio C Hamano @ 2013-02-18 2:24 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git, Jonathan Nieder
In-Reply-To: <dadeb91c29bf6758cbe463b569146991d9eb455a.1361146398.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> This mirrors existing language in the description of 'git fetch'.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
This looks like a good 'maint' material that can be applied straight
away there in preparation for 1.8.1.4 to me; reviewers watching from
the sideline, please stop me if you see issues.
> Documentation/user-manual.txt | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index dbffd0a..ba06b7e 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -2051,6 +2051,13 @@ branch name with a plus sign:
> $ git push ssh://yourserver.com/~you/proj.git +master
> -------------------------------------------------
>
> +Note the addition of the `+` sign. Alternatively, you can use the
> +`-f` flag to force the remote update, as in:
> +
> +-------------------------------------------------
> +$ git push -f ssh://yourserver.com/~you/proj.git master
> +-------------------------------------------------
> +
> Normally whenever a branch head in a public repository is modified, it
> is modified to point to a descendant of the commit that it pointed to
> before. By forcing a push in this situation, you break that convention.
^ permalink raw reply
* Re: [PATCH v3 2/9] user-manual: Reorganize the reroll sections, adding 'git rebase -i'
From: Junio C Hamano @ 2013-02-18 2:23 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git, Jonathan Nieder
In-Reply-To: <31c45d95acaf062428f171c33c4c164d80b4becb.1361146398.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> I think this interface is often more convenient than extended cherry
> picking or using 'git format-patch'. In fact, I removed the
> cherry-pick section entirely. The entry-level suggestions for
> rerolling are now:
>
> 1. git commit --amend
> 2. git format-patch origin
> git reset --hard origin
> ...edit and reorder patches...
> git am *.patch
> 3. git rebase -i origin
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> Documentation/user-manual.txt | 110 ++++++++++++++++++++++++------------------
> 1 file changed, 63 insertions(+), 47 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index a060eb6..dbffd0a 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -2538,6 +2538,12 @@ return mywork to the state it had before you started the rebase:
> $ git rebase --abort
> -------------------------------------------------
>
> +If you need to reorder or edit a number of commits in a branch, it may
> +be easier to use `git rebase -i`, which allows you to reorder and
> +squash commits, as well as marking them for individual editing during
> +the rebase. See <<interactive-rebase>> for details, and
> +<<reordering-patch-series>> for alternatives.
> +
> [[rewriting-one-commit]]
> Rewriting a single commit
> -------------------------
> @@ -2552,71 +2558,81 @@ $ git commit --amend
> which will replace the old commit by a new commit incorporating your
> changes, giving you a chance to edit the old commit message first.
>
... A lot of lines removed here ...
> +[[reordering-patch-series]]
This change makes the [[rewriting-one-commit]] section say "We
already saw you can do 'commit --amend'" and nothing else. It makes
me wonder if the remaining section is worth keeping if we go this
route.
> +[[reordering-patch-series]]
> +Reordering or selecting from a patch series
> +-------------------------------------------
>
> +Sometimes you want to edit a commit deeper in your history. One
> +approach is to use `git format-patch` to create a series of patches,
> +then reset the state to before the patches:
>
> -------------------------------------------------
> +$ git format-patch origin
> +$ git reset --hard origin
> -------------------------------------------------
>
> +Then modify, reorder, or eliminate patches as preferred before applying
> +them again with linkgit:git-am[1]:
>
> -------------------------------------------------
> +$ git am *.patch
> -------------------------------------------------
It may be just me, but s/preferred/needed/, perhaps?
> +This will open your editor with a list of the commits you're rebasing
>
> -------------------------------------------------
> +pick deadbee The oneline of this commit
> +pick fa1afe1 The oneline of the next commit
> +...
>
> +# Rebase c0ffeee..deadbee onto c0ffeee
> +#
> +# Commands:
> ...
> +# Note that empty commits are commented out
> +-------------------------------------------------
> +
> +As explained in the comments, you can reorder commits, squash them
> +together, edit commit messages, etc. by editing the list. Once you
> +are satisfied, save the list and close your editor, and the rebase
> +will begin.
> +
> +The rebase will stop when `pick` has been replaced with `edit` or when
> +a command fails due to merge errors. When you are done editing and/or
> +resolving conflicts...
I am afraid that "due to merge errors" and "resolving conflicts" do
not look corresponding to each other for a new reader. Also here we
say "when a command fails", but the explanation before this part
never says "list of commands". Besides, "command" itself is not a
very good word to use as "pick" is not really a "command" (we do not
have "git pick" or "git squash"---that is why I almost always call
this "insn sheet" myself, by the way).
A way to reword the above to reduce possible confusion may be to
start with:
This will open your editor with a list of steps to be taken
to perform your rebase.
and then say
... with `edit` or when a step in the list fails to
mechanically resolve conflicts and needs your help. When
you are done editing ...
or something.
^ permalink raw reply
* Re: [PATCH v3 1/9] user-manual: Use 'remote add' to setup push URLs
From: Jonathan Nieder @ 2013-02-18 2:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: W. Trevor King, Git
In-Reply-To: <7vbobie62v.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> "W. Trevor King" <wking@tremily.us> writes:
>> There is no need to use here documents to setup this configuration.
>> It is easier, less confusing, and more robust to use `git remote add`
>> directly.
[...]
> This looks like a good 'maint' material that can be applied straight
> away there in preparation for 1.8.1.4 to me; reviewers watching from
> the sideline, please stop me if you see issues.
Agreed --- this looks good.
[...]
> As the additional "remote.public-repo.fetch" line hints, this does
> more than "lets you do the same push with just [lazily]"; it also
> starts pretending to have run a fetch from there immediately after
> you pushed and update the remote tracking branches. I couldn't
> decide if it is a good idea to point it out in this point of the
> flow as well, or it is too much detail that is not exactly relevant
> while teaching "git push". I tend to think it would be the latter.
I think it's possible to improve the text here to hint that there's
more to learn (maybe a forward-reference to a section about the
remotes/* hierarchy) without getting lost in the details. But that
problem was already there, and I don't think it should block this
improvement.
Thanks.
Jonathan
^ permalink raw reply
* Re: [PATCH v3 1/9] user-manual: Use 'remote add' to setup push URLs
From: Junio C Hamano @ 2013-02-18 1:58 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git, Jonathan Nieder
In-Reply-To: <0016ba69f4157996dfbe66938056c4192bed62c1.1361146398.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> There is no need to use here documents to setup this configuration.
> It is easier, less confusing, and more robust to use `git remote add`
> directly.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
This looks like a good 'maint' material that can be applied straight
away there in preparation for 1.8.1.4 to me; reviewers watching from
the sideline, please stop me if you see issues.
> Documentation/user-manual.txt | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 5077e7c..a060eb6 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1998,16 +1998,21 @@ will not be updated by the push. This may lead to unexpected results if
> the branch you push to is the currently checked-out branch!
>
> As with `git fetch`, you may also set up configuration options to
> -save typing; so, for example, after
> +save typing; so, for example:
> +
> +-------------------------------------------------
> +$ git remote add public-repo ssh://yourserver.com/~you/proj.git
> +-------------------------------------------------
> +
> +adds the following to `.git/config`:
>
> -------------------------------------------------
> -$ cat >>.git/config <<EOF
> [remote "public-repo"]
> - url = ssh://yourserver.com/~you/proj.git
> -EOF
> + url = yourserver.com:proj.git
> + fetch = +refs/heads/*:refs/remotes/example/*
> -------------------------------------------------
>
> -you should be able to perform the above push with just
> +which lets you do the same push with just
As the additional "remote.public-repo.fetch" line hints, this does
more than "lets you do the same push with just [lazily]"; it also
starts pretending to have run a fetch from there immediately after
you pushed and update the remote tracking branches. I couldn't
decide if it is a good idea to point it out in this point of the
flow as well, or it is too much detail that is not exactly relevant
while teaching "git push". I tend to think it would be the latter.
^ permalink raw reply
* Re: [PATCH 3/3] remote-curl: sanity check ref advertisement from server
From: Jonathan Nieder @ 2013-02-18 1:41 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20130217192830.GB25096@sigill.intra.peff.net>
Jeff King wrote:
> On Sun, Feb 17, 2013 at 03:05:34AM -0800, Jonathan Nieder wrote:
>> Jeff King wrote:
>>> + if (verify_ref_advertisement(last->buf, last->len) < 0)
>>> + die("ref advertisement is invalid at %s", refs_url);
>>
>> Won't this error out with
>>
>> protocol error: bad line length character: ERR
>>
>> instead of the current more helpful behavior for ERR lines?
>
> I don't think so. Don't ERR lines appear inside their own packets?
Yes, I misread get_remote_heads for some reason. Thanks for checking.
[...]
> The one thing we do also check, though, is that we end with a flush
> packet. So depending on what servers produce, it may mean we trigger
> this complaint instead of passing the ERR along to fetch-pack.
>
> Rather than doing this fake syntactic verification, I wonder if we
> should simply call get_remote_heads, which does a more thorough check
I'm not sure whether servers are expected to send a flush after an
ERR packet. The only codepath I know of in git itself that sends
such packets is git-daemon, which does not flush after the error (but
is not used in the stateless-rpc case). http-backend uses HTTP error
codes for its errors.
If I am reading get_remote_heads correctly, calling it with the
following tweak should work ok. The extra thread is just to feed a
string into a fd-based interface and could be avoided for "list", too,
if it costs too much.
diff --git i/connect.c w/connect.c
index 49e56ba3..55ee7de7 100644
--- i/connect.c
+++ w/connect.c
@@ -68,7 +68,8 @@ struct ref **get_remote_heads(int in, struct ref **list,
{
int got_at_least_one_head = 0;
- *list = NULL;
+ if (list)
+ *list = NULL;
for (;;) {
struct ref *ref;
unsigned char old_sha1[20];
@@ -92,6 +93,9 @@ struct ref **get_remote_heads(int in, struct ref **list,
die("protocol error: expected sha/ref, got '%s'", buffer);
name = buffer + 41;
+ if (!list)
+ continue;
+
name_len = strlen(name);
if (len != name_len + 41) {
free(server_capabilities);
^ permalink raw reply related
* Re: [PATCH 2/3] remote-curl: verify smart-http metadata lines
From: Jonathan Nieder @ 2013-02-18 0:54 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20130217191422.GA25096@sigill.intra.peff.net>
Jeff King wrote:
> On Sun, Feb 17, 2013 at 02:49:39AM -0800, Jonathan Nieder wrote:
>> Jeff King wrote:
>>> --- a/remote-curl.c
[...]
>>> + if (read_packets_until_flush(&last->buf, &last->len) < 0)
>>
>> Style nit: this made me wonder "What would it mean if
>> read_packets_until_flush() > 0?"
[...]
> My intent was that it followed the error convention of "negative is
> error, 0 is success, and positive is not used, but reserved for
> future use".
>From a maintainability perspective, that kind of contract would be
dangerous, since some *other* caller could arrive and use the function
without a "< 0" without knowing it is doing anything wrong. When new
return values appear, the function should be renamed to help the patch
author and reviewers remember to check all callers.
That is, from the point of view of maintainability, there is no
distinction between "if (read_packets_until_... < 0)" and
"if (read_packets_until_...)" and either form is fine.
My comment was just to say the "< 0" forced me to pause a moment and
check out the implementation. This is basically a stylistic thing and
if you prefer to keep the "< 0", that's fine with me.
> If
> an implementation is producing bogus packet lines and expecting us not
> to complain, it really needs to be fixed.
Agreed completely. Thanks again for the patch.
Jonathan
^ permalink raw reply
* What's cooking in git.git (Feb 2013, #07; Sun, 17)
From: Junio C Hamano @ 2013-02-18 0:54 UTC (permalink / raw)
To: git
What's cooking in git.git (Feb 2013, #07; Sun, 17)
--------------------------------------------------
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' is at 1.8.2-rc0; new topics that are not
listed in this report are likely to be too late for the upcoming
release.
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]
* da/difftool-fixes (2013-02-17) 5 commits
- [DONTMERGE] expect reroll $gmane/216376
- t7800: "defaults" is no longer a builtin tool name
- t7800: modernize tests
- t7800: Update copyright notice
- difftool: silence uninitialized variable warning
Minor maintenance updates to difftool, and updates to its tests.
Expecting a reroll.
$gmane/216376
* jk/smart-http-robustify (2013-02-17) 3 commits
- remote-curl: sanity check ref advertisement from server
- remote-curl: verify smart-http metadata lines
- pkt-line: teach packet_get_line a no-op mode
Parse the HTTP exchange that implements the native Git protocol as
a series of stateless RPC more carefully to diagnose protocol
breakage better.
Will merge to and hold in 'next'.
* nd/read-directory-recursive-optim (2013-02-17) 1 commit
- read_directory: avoid invoking exclude machinery on tracked files
"git status" has been optimized by taking advantage of the fact
that paths that are already known to the index do not have to be
checked against the .gitignore mechanism under some conditions.
Will merge to and hold in 'next'.
--------------------------------------------------
[Graduated to "master"]
* da/p4merge-mktemp-fix (2013-02-10) 1 commit
(merged to 'next' on 2013-02-14 at c5fc5ba)
+ p4merge: fix printf usage
* ef/non-ascii-parse-options-error-diag (2013-02-11) 1 commit
(merged to 'next' on 2013-02-14 at 10cbdf8)
+ parse-options: report uncorrupted multi-byte options
* jc/hidden-refs (2013-02-07) 3 commits
(merged to 'next' on 2013-02-14 at b69f9cc)
+ upload/receive-pack: allow hiding ref hierarchies
+ upload-pack: simplify request validation
+ upload-pack: share more code
(this branch is used by jc/fetch-raw-sha1.)
Allow the server side to redact the refs/ namespace it shows to the
client.
* jk/read-commit-buffer-data-after-free (2013-02-11) 1 commit
(merged to 'next' on 2013-02-14 at 220e3a8)
+ log: re-encode commit messages before grepping
"git log --grep=<pattern>" has been taught to honor the logoutput
encoding when matching the log message against the given pattern.
* jk/rebase-i-comment-char (2013-02-12) 1 commit
(merged to 'next' on 2013-02-14 at 0ed2f48)
+ rebase -i: respect core.commentchar
Finishing touches to core.commentchar topic to teach it to "rebase
-i" as well.
* mk/make-rm-depdirs-could-be-empty (2013-02-13) 1 commit
(merged to 'next' on 2013-02-14 at d966248)
+ Makefile: don't run "rm" without any files
"make COMPUTE_HEADER_DEPENDENCIES=no clean" would try to run "rm
-rf $(dep_dirs)" with an empty dep_dir, but some implementations of
"rm -rf" barf on an empty argument list.
* mk/old-expat (2013-02-11) 1 commit
(merged to 'next' on 2013-02-14 at 5fb47ce)
+ Allow building with xmlparse.h
Old expat needs to include xmlparse.h instead of expat.h header
file.
* mm/config-local-completion (2013-02-12) 1 commit
(merged to 'next' on 2013-02-14 at 26bf6c2)
+ completion: support 'git config --local'
* mp/diff-algo-config (2013-01-16) 3 commits
(merged to 'next' on 2013-02-14 at cd765dc)
+ diff: Introduce --diff-algorithm command line option
+ config: Introduce diff.algorithm variable
+ git-completion.bash: Autocomplete --minimal and --histogram for git-diff
Add diff.algorithm configuration so that the user does not type
"diff --histogram".
* mw/bash-prompt-show-untracked-config (2013-02-13) 3 commits
(merged to 'next' on 2013-02-14 at 809dbcf)
+ t9903: add extra tests for bash.showDirtyState
+ t9903: add tests for bash.showUntrackedFiles
+ shell prompt: add bash.showUntrackedFiles option
Allows skipping the untracked check GIT_PS1_SHOWUNTRACKEDFILES
asks for the git-prompt (in contrib/) per repository.
* wk/man-deny-current-branch-is-default-these-days (2013-02-14) 1 commit
(merged to 'next' on 2013-02-14 at 6fab9d4)
+ user-manual: Update for receive.denyCurrentBranch=refuse
--------------------------------------------------
[Stalled]
* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
- Highlight the link target line in Gitweb using CSS
Expecting a reroll.
$gmane/211935
* 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.
There seems to be some interest. Let's see if it results in a solid
execution of a sensible transition plan towards Git 2.0.
* 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 reroll.
$gmane/210151
"The first remote becomes the default" bit is better done as a
separate step.
--------------------------------------------------
[Cooking]
* mg/gpg-interface-using-status (2013-02-14) 5 commits
- pretty: make %GK output the signing key for signed commits
- pretty: parse the gpg status lines rather than the output
- gpg_interface: allow to request status return
- log-tree: rely upon the check in the gpg_interface
- gpg-interface: check good signature in a reliable way
Call "gpg" using the right API when validating the signature on
tags.
* mm/config-intro-in-git-doc (2013-02-15) 1 commit
- git.txt: update description of the configuration mechanism
Will merge to 'master'.
* jn/shell-disable-interactive (2013-02-11) 2 commits
- shell: pay attention to exit status from 'help' command
- shell doc: emphasize purpose and security model
Expecting a reroll.
$gmane/216229
* jc/fetch-raw-sha1 (2013-02-07) 4 commits
(merged to 'next' on 2013-02-14 at ffa3c65)
+ fetch: fetch objects by their exact SHA-1 object names
+ upload-pack: optionally allow fetching from the tips of hidden refs
+ fetch: use struct ref to represent refs to be fetched
+ parse_fetch_refspec(): clarify the codeflow a bit
Allows requests to fetch objects at any tip of refs (including
hidden ones). It seems that there may be use cases even outside
Gerrit (e.g. $gmane/215701).
Will cook in 'next'.
* mn/send-email-works-with-credential (2013-02-12) 6 commits
- git-send-email: use git credential to obtain password
- Git.pm: add interface for git credential command
- Git.pm: allow pipes to be closed prior to calling command_close_bidi_pipe
- Git.pm: refactor command_close_bidi_pipe to use _cmd_close
- Git.pm: fix example in command_close_bidi_pipe documentation
- Git.pm: allow command_close_bidi_pipe to be called as method
Hooks the credential system to send-email.
Rerolled.
Waiting for a review.
* nd/branch-show-rebase-bisect-state (2013-02-08) 1 commit
- branch: show rebase/bisect info when possible instead of "(no branch)"
Expecting a reroll.
$gmane/215771
* nd/count-garbage (2013-02-15) 4 commits
- count-objects: report how much disk space taken by garbage files
- count-objects: report garbage files in pack directory too
- sha1_file: reorder code in prepare_packed_git_one()
- git-count-objects.txt: describe each line in -v output
Will merge to 'next'.
* tz/credential-authinfo (2013-02-05) 1 commit
- Add contrib/credentials/netrc with GPG support
A new read-only credential helper (in contrib/) to interact with
the .netrc/.authinfo files. Hopefully mn/send-email-authinfo topic
can rebuild on top of something like this.
Expecting a reroll.
$gmane/215556
* jl/submodule-deinit (2013-02-17) 1 commit
- 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.
* jc/remove-export-from-config-mak-in (2013-02-12) 2 commits
(merged to 'next' on 2013-02-12 at eb8af04)
+ Makefile: do not export mandir/htmldir/infodir
(merged to 'next' on 2013-02-07 at 33f7d4f)
+ config.mak.in: remove unused definitions
config.mak.in template had an "export" line to cause a few
common makefile variables to be exported; if they need to be
expoted for autoconf/configure users, they should also be exported
for people who write config.mak the same way. Move the "export" to
the main Makefile. Also, stop exporting mandir that used to be
exported (only) when config.mak.autogen was used. It would have
broken installation of manpages (but not other documentation
formats).
Will cook in 'next'.
* jc/mention-tracking-for-pull-default (2013-01-31) 1 commit
- doc: mention tracking for pull.default
We stopped mentioning `tracking` is a deprecated but supported
synonym for `upstream` in pull.default even though we have no
intention of removing the support for it.
This is my "don't list it to catch readers' eyes, but make sure it
can be found if the reader looks for it" version; I'm not married
to the layout and will be happy to take a replacement patch.
Will merge to 'next'.
* jc/remove-treesame-parent-in-simplify-merges (2013-01-17) 1 commit
(merged to 'next' on 2013-01-30 at b639b47)
+ simplify-merges: drop merge from irrelevant side branch
The --simplify-merges logic did not cull irrelevant parents from a
merge that is otherwise not interesting with respect to the paths
we are following.
This touches a fairly core part of the revision traversal
infrastructure; even though I think this change is correct, please
report immediately if you find any unintended side effect.
Will cook in 'next'.
* jc/push-2.0-default-to-simple (2013-01-16) 14 commits
(merged to 'next' on 2013-01-16 at 23f5df2)
+ t5570: do not assume the "matching" push is the default
+ t5551: do not assume the "matching" push is the default
+ t5550: do not assume the "matching" push is the default
(merged to 'next' on 2013-01-09 at 74c3498)
+ doc: push.default is no longer "matching"
+ push: switch default from "matching" to "simple"
+ t9401: do not assume the "matching" push is the default
+ t9400: do not assume the "matching" push is the default
+ t7406: do not assume the "matching" push is the default
+ t5531: do not assume the "matching" push is the default
+ t5519: do not assume the "matching" push is the default
+ t5517: do not assume the "matching" push is the default
+ t5516: do not assume the "matching" push is the default
+ t5505: do not assume the "matching" push is the default
+ t5404: do not assume the "matching" push is the default
Will cook in 'next' until Git 2.0 ;-).
* bc/append-signed-off-by (2013-02-12) 12 commits
- Unify appending signoff in format-patch, commit and sequencer
- format-patch: update append_signoff prototype
- 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: require a conforming footer to be preceded by a blank line
- 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
- commit, cherry-pick -s: remove broken support for multiline rfc2822 fields
- sequencer.c: rework search for start of footer to improve clarity
Waiting for further reviews.
$gmane/216327 may need to be addressed.
--------------------------------------------------
[Discarded]
* 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.
* 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.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
- Teach git-completion about git p4
Comment from Pete will need to be addressed ($gmane/206172).
^ permalink raw reply
* [ANNOUNCE] Git v1.8.2-rc0
From: Junio C Hamano @ 2013-02-18 0:52 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
An early preview Git v1.8.2-rc0 for the upcoming release is now
available for testing at the usual places. The preview includes
contributions from 80+ people, totaling some 570+ no-merge changes
since v1.8.1 and should give you more or less a complete picture of
what the upcoming 1.8.2 would look like.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
3d19b5bc224a7a3427b21c4587c4ab342435e8b6 git-1.8.2.rc0.tar.gz
77dcebd8856cb6c8600dcf2a56ca3554aef9866f git-htmldocs-1.8.2.rc0.tar.gz
26a75c32c75ed05939c13684581698f2daa0feae git-manpages-1.8.2.rc0.tar.gz
Also the following public repositories all have a copy of the v1.8.2-rc0
tag and the master branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.8.2 Release Notes (draft)
========================
Backward compatibility notes
----------------------------
In the upcoming major release (tentatively called 1.8.2), we will
change the behavior of the "git push" command.
When "git push [$there]" does not say what to push, we have used the
traditional "matching" semantics so far (all your branches were sent
to the remote as long as there already are branches of the same name
over there). We will use the "simple" semantics that pushes the
current branch to the branch with the same name, only when the current
branch is set to integrate with that remote branch. There is a user
preference configuration variable "push.default" to change this.
"git push $there tag v1.2.3" used to allow replacing a tag v1.2.3
that already exists in the repository $there, if the rewritten tag
you are pushing points at a commit that is a decendant of a commit
that the old tag v1.2.3 points at. This was found to be error prone
and starting with this release, any attempt to update an existing
ref under refs/tags/ hierarchy will fail, without "--force".
Updates since v1.8.1
--------------------
UI, Workflows & Features
* Initial ports to QNX and z/OS UNIX System Services have started.
* Output from the tests is coloured using "green is okay, yellow is
questionable, red is bad and blue is informative" scheme.
* Mention of "GIT/Git/git" in the documentation have been updated to
be more uniform and consistent. The name of the system and the
concept it embodies is "Git"; the command the users type is "git".
All-caps "GIT" was merely a way to imitate "Git" typeset in small
caps in our ASCII text only documentation and to be avoided.
* The completion script (in contrib/completion) used to let the
default completer to suggest pathnames, which gave too many
irrelevant choices (e.g. "git add" would not want to add an
unmodified path). It learnt to use a more git-aware logic to
enumerate only relevant ones.
* In bare repositories, "git shortlog" and other commands now read
mailmap files from the tip of the history, to help running these
tools in server settings.
* Color specifiers, e.g. "%C(blue)Hello%C(reset)", used in the
"--format=" option of "git log" and friends can be disabled when
the output is not sent to a terminal by prefixing them with
"auto,", e.g. "%C(auto,blue)Hello%C(auto,reset)".
* Scripts can ask Git that wildcard patterns in pathspecs they give do
not have any significance, i.e. take them as literal strings.
* The patterns in .gitignore and .gitattributes files can have **/,
as a pattern that matches 0 or more levels of subdirectory.
E.g. "foo/**/bar" matches "bar" in "foo" itself or in a
subdirectory of "foo".
* When giving arguments without "--" disambiguation, object names
that come earlier on the command line must not be interpretable as
pathspecs and pathspecs that come later on the command line must
not be interpretable as object names. This disambiguation rule has
been tweaked so that ":/" (no other string before or after) is
always interpreted as a pathspec; "git cmd -- :/" is no longer
needed, you can just say "git cmd :/".
* Various "hint" lines Git gives when it asks the user to edit
messages in the editor are commented out with '#' by default. The
core.commentchar configuration variable can be used to customize
this '#' to a different character.
* "git add -u" and "git add -A" without pathspec issues warning to
make users aware that they are only operating on paths inside the
subdirectory they are in. Use ":/" (everything from the top) or
"." (everything from the $cwd) to disambiguate.
* "git blame" (and "git diff") learned the "--no-follow" option.
* "git branch" now rejects some nonsense combinations of command line
arguments (e.g. giving more than one branch name to rename) with
more case-specific error messages.
* "git check-ignore" command to help debugging .gitignore files has
been added.
* "git cherry-pick" can be used to replay a root commit to an unborn
branch.
* "git commit" can be told to use --cleanup=whitespace by setting the
configuration variable commit.cleanup to 'whitespace'.
* "git diff" and other Porcelain commands can be told to use a
non-standard algorithm by setting diff.algorithm configuration
variable.
* "git fetch --mirror" and fetch that uses other forms of refspec
with wildcard used to attempt to update a symbolic ref that match
the wildcard on the receiving end, which made little sense (the
real ref that is pointed at by the symbolic ref would be updated
anyway). Symbolic refs no longer are affected by such a fetch.
* "git format-patch" now detects more cases in which a whole branch
is being exported, and uses the description for the branch, when
asked to write a cover letter for the series.
* "git format-patch" learned "-v $count" option, and prepends a
string "v$count-" to the names of its output files, and also
automatically sets the subject prefix to "PATCH v$count". This
allows patches from rerolled series to be stored under different
names and makes it easier to reuse cover letter messsages.
* "git log" and friends can be told with --use-mailmap option to
rewrite the names and email addresses of people using the mailmap
mechanism.
* "git log --cc --graph" now shows the combined diff output with the
ancestry graph.
* "git log --grep=<pattern>" honors i18n.logoutputencoding to look
for the pattern after fixing the log message to the specified
encoding.
* "git mergetool" and "git difftool" learned to list the available
tool backends in a more consistent manner.
* "git mergetool" is aware of TortoiseGitMerge now and uses it over
TortoiseMerge when available.
* "git push" now requires "-f" to update a tag, even if it is a
fast-forward, as tags are meant to be fixed points.
* Error messages from "git push" when it stops to prevent remote refs
from getting overwritten by mistake have been improved to explain
various situations separately.
* "git push" will stop without doing anything if the new "pre-push"
hook exists and exits with a failure.
* When "git rebase" fails to generate patches to be applied (e.g. due
to oom), it failed to detect the failure and instead behaved as if
there were nothing to do. A workaround to use a temporary file has
been applied, but we probably would want to revisit this later, as
it hurts the common case of not failing at all.
* Input and preconditions to "git reset" has been loosened where
appropriate. "git reset $fromtree Makefile" requires $fromtree to
be any tree (it used to require it to be a commit), for example.
"git reset" (without options or parameters) used to error out when
you do not have any commits in your history, but it now gives you
an empty index (to match non-existent commit you are not even on).
* "git status" says what branch is being bisected or rebased when
able, not just "bisecting" or "rebasing".
* "git submodule" started learning a new mode to integrate with the
tip of the remote branch (as opposed to integrating with the commit
recorded in the superproject's gitlink).
* "git upload-pack" which implements the service "ls-remote" and
"fetch" talk to can be told to hide ref hierarchies the server
side internally uses (and that clients have no business learning
about) with transfer.hiderefs configuration.
Foreign Interface
* "git fast-export" has been updated for its use in the context of
the remote helper interface.
* A new remote helper to interact with bzr has been added to contrib/.
* "git p4" got various bugfixes around its branch handling. It is
also made usable with Python 2.4/2.5. In addition, its various
portability issues for Cygwin have been addressed.
* The remote helper to interact with Hg in contrib/ has seen a few
fixes.
Performance, Internal Implementation, etc.
* "git fsck" has been taught to be pickier about entries in tree
objects that should not be there, e.g. ".", ".git", and "..".
* Matching paths with common forms of pathspecs that contain wildcard
characters has been optimized further.
* We stopped paying attention to $GIT_CONFIG environment that points
at a single configuration file from any command other than "git config"
quite a while ago, but "git clone" internally set, exported, and
then unexported the variable during its operation unnecessarily.
* "git reset" internals has been reworked and should be faster in
general. We tried to be careful not to break any behaviour but
there could be corner cases, especially when running the command
from a conflicted state, that we may have missed.
* The implementation of "imap-send" has been updated to reuse xml
quoting code from http-push codepath, and lost a lot of unused
code.
* There is a simple-minded checker for the test scripts in t/
directory to catch most common mistakes (it is not enabled by
default).
* You can build with USE_WILDMATCH=YesPlease to use a replacement
implementation of pattern matching logic used for pathname-like
things, e.g. refnames and paths in the repository. This new
implementation is not expected change the existing behaviour of Git
in this release, except for "git for-each-ref" where you can now
say "refs/**/master" and match with both refs/heads/master and
refs/remotes/origin/master. We plan to use this new implementation
in wider places (e.g. "git ls-files '**/Makefile' may find Makefile
at the top-level, and "git log '**/t*.sh'" may find commits that
touch a shell script whose name begins with "t" at any level) in
future versions of Git, but we are not there yet. By building with
USE_WILDMATCH, using the resulting Git daily and reporting when you
find breakages, you can help us get closer to that goal.
* Some reimplementations of Git do not write all the stat info back
to the index due to their implementation limitations (e.g. jgit).
A configuration option can tell Git to ignore changes to most of
the stat fields and only pay attention to mtime and size, which
these implementations can reliably update. This can be used to
avoid excessive revalidation of contents.
* Some platforms ship with old version of expat where xmlparse.h
needs to be included instead of expat.h; the build procedure has
been taught about this.
* "make clean" on platforms that cannot compute header dependencies
on the fly did not work with implementations of "rm" that do not
like an empty argument list.
Also contains minor documentation updates and code clean-ups.
Fixes since v1.8.1
------------------
Unless otherwise noted, all the fixes since v1.8.1 in the maintenance
track are contained in this release (see release notes to them for
details).
* An element on GIT_CEILING_DIRECTORIES list that does not name the
real path to a directory (i.e. a symbolic link) could have caused
the GIT_DIR discovery logic to escape the ceiling.
* When attempting to read the XDG-style $HOME/.config/git/config and
finding that $HOME/.config/git is a file, we gave a wrong error
message, instead of treating the case as "a custom config file does
not exist there" and moving on.
* The behaviour visible to the end users was confusing, when they
attempt to kill a process spawned in the editor that was in turn
launched by Git with SIGINT (or SIGQUIT), as Git would catch that
signal and die. We ignore these signals now.
(merge 0398fc34 pf/editor-ignore-sigint later to maint).
* A child process that was killed by a signal (e.g. SIGINT) was
reported in an inconsistent way depending on how the process was
spawned by us, with or without a shell in between.
* After failing to create a temporary file using mkstemp(), failing
pathname was not reported correctly on some platforms.
* We used to stuff "user@" and then append what we read from
/etc/mailname to come up with a default e-mail ident, but a bug
lost the "user@" part.
* The attribute mechanism didn't allow limiting attributes to be
applied to only a single directory itself with "path/" like the
exclude mechanism does. The initial implementation of this that
was merged to 'maint' and 1.8.1.2 was with a severe performance
degradations and needs to merge a fix-up topic.
* The smart HTTP clients forgot to verify the content-type that comes
back from the server side to make sure that the request is being
handled properly.
(merge 3443db5 sp/smart-http-content-type-check later to maint).
* "git am" did not parse datestamp correctly from Hg generated patch,
when it is run in a locale outside C (or en).
* "git apply" misbehaved when fixing whitespace breakages by removing
excess trailing blank lines.
* "git apply --summary" has been taught to make sure the similarity
value shown in its output is sensible, even when the input had a
bogus value.
(merge afcb6ac jk/apply-similaritly-parsing later to maint).
* A tar archive created by "git archive" recorded a directory in a
way that made NetBSD's implementation of "tar" sometimes unhappy.
* "git archive" did not record uncompressed size in the header when
streaming a zip archive, which confused some implementations of unzip.
* "git archive" did not parse configuration values in tar.* namespace
correctly.
(merge b3873c3 jk/config-parsing-cleanup later to maint).
* Attempt to "branch --edit-description" an existing branch, while
being on a detached HEAD, errored out.
* "git clean" showed what it was going to do, but sometimes end up
finding that it was not allowed to do so, which resulted in a
confusing output (e.g. after saying that it will remove an
untracked directory, it found an embedded git repository there
which it is not allowed to remove). It now performs the actions
and then reports the outcome more faithfully.
(merge f538a91 zk/clean-report-failure later to maint).
* When "git clone --separate-git-dir=$over_there" is interrupted, it
failed to remove the real location of the $GIT_DIR it created.
This was most visible when interrupting a submodule update.
* "git cvsimport" mishandled timestamps at DST boundary.
(merge 48c9162 bw/get-tz-offset-perl later to maint).
* We used to have an arbitrary 32 limit for combined diff input,
resulting in incorrect number of leading colons shown when showing
the "--raw --cc" output.
(merge edbc00e jc/combine-diff-many-parents later to maint).
* "git fetch --depth" was broken in at least three ways. The
resulting history was deeper than specified by one commit, it was
unclear how to wipe the shallowness of the repository with the
command, and documentation was misleading.
(merge cfb70e1 nd/fetch-depth-is-broken later to maint).
* "git log --all -p" that walked refs/notes/textconv/ ref can later
try to use the textconv data incorrectly after it gets freed.
(merge be5c9fb jk/read-commit-buffer-data-after-free later to maint).
* We forgot to close the file descriptor reading from "gpg" output,
killing "git log --show-signature" on a long history.
* The way "git svn" asked for password using SSH_ASKPASS and
GIT_ASKPASS was not in line with the rest of the system.
* The --graph code fell into infinite loop when asked to do what the
code did not expect.
* http transport was wrong to ask for the username when the
authentication is done by certificate identity.
* "git pack-refs" that ran in parallel to another process that
created new refs had a nasty race.
* Rebasing the history of superproject with change in the submodule
has been broken since v1.7.12.
* After "git add -N" and then writing a tree object out of the
index, the cache-tree data structure got corrupted.
* "git clone" used to allow --bare and --separate-git-dir=$there
options at the same time, which was nonsensical.
(merge 95b63f1 nd/clone-no-separate-git-dir-with-bare later to maint).
* "git rebase --preserve-merges" lost empty merges in recent versions
of Git.
* "git merge --no-edit" computed who were involved in the work done
on the side branch, even though that information is to be discarded
without getting seen in the editor.
* "git merge" started calling prepare-commit-msg hook like "git
commit" does some time ago, but forgot to pay attention to the exit
status of the hook.
* A failure to push due to non-ff while on an unborn branch
dereferenced a NULL pointer when showing an error message.
* When users spell "cc:" in lowercase in the fake "header" in the
trailer part, "git send-email" failed to pick up the addresses from
there. As e-mail headers field names are case insensitive, this
script should follow suit and treat "cc:" and "Cc:" the same way.
* Output from "git status --ignored" showed an unexpected interaction
with "--untracked".
* "gitweb", when sorting by age to show repositories with new
activities first, used to sort repositories with absolutely
nothing in it early, which was not very useful.
* "gitweb"'s code to sanitize control characters before passing it to
"highlight" filter lost known-to-be-safe control characters by
mistake.
* "gitweb" pages served over HTTPS, when configured to show picon or
gravatar, referred to these external resources to be fetched via
HTTP, resulting in mixed contents warning in browsers.
(merge 5748558 ab/gitweb-use-same-scheme later to maint).
* 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.
* Command line completion leaked an unnecessary error message while
looking for possible matches with paths in <tree-ish>.
* Command line completion for "tcsh" emitted an unwanted space
after completing a single directory name.
* Command line completion code was inadvertently made incompatible with
older versions of bash by using a newer array notation.
* "git push" was taught to refuse updating the branch that is
currently checked out long time ago, but the user manual was left
stale.
(merge d9be248 wk/man-deny-current-branch-is-default-these-days later to maint).
* Some shells do not behave correctly when IFS is unset; work it
around by explicitly setting it to the default value.
* Some scripted programs written in Python did not get updated when
PYTHON_PATH changed.
(cherry-pick 96a4647fca54031974cd6ad1 later to maint).
* When autoconf is used, any build on a different commit always ran
"config.status --recheck" even when unnecessary.
* A fix was added to the build procedure to work around buggy
versions of ccache broke the auto-generation of dependencies, which
unfortunately is still relevant because some people use ancient
distros.
* The autoconf subsystem passed --mandir down to generated
config.mak.autogen but forgot to do the same for --htmldir.
(merge fc1c541 ct/autoconf-htmldir later to maint).
* We have been carrying a translated and long-unmaintained copy of an
old version of the tutorial; removed.
* t0050 had tests expecting failures from a bug that was fixed some
time ago.
* t4014, t9502 and t0200 tests had various portability issues that
broke on OpenBSD.
* t9020 and t3600 tests had various portability issues.
* t9200 runs "cvs init" on a directory that already exists, but a
platform can configure this fail for the current user (e.g. you
need to be in the cvsadmin group on NetBSD 6.0).
* t9020 and t9810 had a few non-portable shell script construct.
* Scripts to test bash completion was inherently flaky as it was
affected by whatever random things the user may have on $PATH.
^ permalink raw reply
* Re: [PATCH 2/3] contrib/subtree/t: Added tests for .gitsubtree support
From: Jonathan Nieder @ 2013-02-18 0:35 UTC (permalink / raw)
To: Paul Campbell
Cc: git, Adam Tkac, David A. Greene, Jesper L. Nielsen,
Michael Schubert, Techlive Zheng
In-Reply-To: <CALeLG_n-WocsMTvRZHm6v-+wrCNVvCh6O2baVDALSE3JB8ibng@mail.gmail.com>
Paul Campbell wrote:
> Here's the updated version of the tests:
Just a few more nits:
> --- a/contrib/subtree/t/t7900-subtree.sh
> +++ b/contrib/subtree/t/t7900-subtree.sh
> @@ -465,4 +465,37 @@ test_expect_success 'verify one file change per commit' '
[...]
> +test_expect_success 'change in subtree is pushed okay' '
> + (cd copy0 && create new_file && git commit -m"Added new_file") &&
Style: this would be easier to read with each command on a separate
line, like so:
(
cd copy0 &&
create new_file &&
test_tick &&
git commit -m "Add new_file"
) &&
[...]
> +test_expect_success 'pull into subtree okay' '
> + git subtree add --prefix=copy1 sub1 &&
> + git subtree add --prefix=copy2 sub1 &&
> + (cd copy1 && create new_file_in_copy1 && git commit -m"Added new_file_in_copy1") &&
Likewise (and as a nice side-benefit, it would avoid a long line that
mailers like to wrap).
> + git subtree push --prefix=copy1 &&
> + git subtree pull --prefix=copy2 | grep "^ create mode 100644 copy2/new_file_in_copy1$"
Likewise. More importantly, this forgets the exit status from "git
subtree pull", so if it were to segfault after writing appropriate
output, the test wouldn't notice. How about:
git subtree pull --prefix=copy2 >output &&
grep "^ create mode 100644 copy2/new_file_in_copy1\$" output
Thanks,
Jonathan
^ permalink raw reply
* [PATCH v3 8/9] user-manual: Flesh out uncommitted changes and submodule updates
From: W. Trevor King @ 2013-02-18 0:16 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, Jonathan Nieder, W. Trevor King
In-Reply-To: <cover.1361146398.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
If you try and update a submodule with a dirty working directory, you
get an error message like:
$ git submodule update
error: Your local changes to the following files would be overwritten by checkout:
...
Please, commit your changes or stash them before you can switch branches.
Aborting
...
Mention this in the submodule notes. The previous phrase was short
enough that I originally thought it might have been referring to the
reflog note (obviously, uncommitted changes will not show up in the
reflog either ;).
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index cf09ddf..3381c22 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3729,7 +3729,9 @@ module a
NOTE: The changes are still visible in the submodule's reflog.
-This is not the case if you did not commit your changes.
+If you did not commit your submodule changes, the changes will *not*
+be silently overwritten. Instead, you get the usual warning about not
+being able switch from a dirty branch.
[[low-level-operations]]
Low-level Git operations
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v3 9/9] user-manual: Use -o latest.tar.gz to create a gzipped tarball
From: W. Trevor King @ 2013-02-18 0:16 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, Jonathan Nieder, W. Trevor King
In-Reply-To: <cover.1361146398.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
This functionality was introduced by 0e804e09 (archive: provide
builtin .tar.gz filter, 2011-07-21) for v1.7.7.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 3381c22..af6c09d 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -931,11 +931,20 @@ The linkgit:git-archive[1] command can create a tar or zip archive from
any version of a project; for example:
-------------------------------------------------
-$ git archive --format=tar --prefix=project/ HEAD | gzip >latest.tar.gz
+$ git archive -o latest.tar.gz --prefix=project/ HEAD
-------------------------------------------------
-will use HEAD to produce a tar archive in which each filename is
-preceded by `project/`.
+will use HEAD to produce a gzipped tar archive in which each filename
+is preceded by `project/`. The output file format is inferred from
+the output file extension if possible, see linkgit:git-archive[1] for
+details.
+
+Versions of Git older than 1.7.7 don't know about the 'tar.gz' format,
+you'll need to use gzip explicitly:
+
+-------------------------------------------------
+$ git archive --format=tar --prefix=project/ HEAD | gzip >latest.tar.gz
+-------------------------------------------------
If you're releasing a new version of a software project, you may want
to simultaneously make a changelog to include in the release
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v3 6/9] user-manual: Use 'git config --global user.*' for setup
From: W. Trevor King @ 2013-02-18 0:15 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, Jonathan Nieder, W. Trevor King
In-Reply-To: <cover.1361146398.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
A simple command line call is easier than spawning an editor,
especially for folks new to ideas like the "command line" and "text
editors". This is also the approach suggested by 'git commit' if you
try and commit without having configured user.name or user.email.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index a79b3e31..d9276d7 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -991,9 +991,16 @@ Developing with Git
Telling Git your name
---------------------
-Before creating any commits, you should introduce yourself to Git. The
-easiest way to do so is to make sure the following lines appear in a
-file named `.gitconfig` in your home directory:
+Before creating any commits, you should introduce yourself to Git.
+The easiest way to do so is to use linkgit:git-config[1]:
+
+------------------------------------------------
+$ git config --global user.name 'Your Name Comes Here'
+$ git config --global user.email 'you@yourdomain.example.com'
+------------------------------------------------
+
+Which will adds the following to a file named `.gitconfig` in your
+home directory:
------------------------------------------------
[user]
@@ -1001,8 +1008,9 @@ file named `.gitconfig` in your home directory:
email = you@yourdomain.example.com
------------------------------------------------
-(See the "CONFIGURATION FILE" section of linkgit:git-config[1] for
-details on the configuration file.)
+See the "CONFIGURATION FILE" section of linkgit:git-config[1] for
+details on the configuration file. The file is plain text, so you can
+also edit it with your favorite editor.
[[creating-a-new-repository]]
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v3 5/9] user-manual: Standardize backtick quoting
From: W. Trevor King @ 2013-02-18 0:15 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, Jonathan Nieder, W. Trevor King
In-Reply-To: <cover.1361146398.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
I tried to always use backticks for:
* Paths and filenames (e.g. `.git/config`)
* Compound refs (e.g. `origin/HEAD`)
* Git commands (e.g. `git log`)
* Command arguments (e.g. `--pretty`)
* URLs (e.g. `git://`), as a subset of command arguments
* Special characters (e.g. `+` in diffs).
* Config options (e.g. `branch.<name>.remote`)
Branch and tag names are sometimes set off with double quotes,
sometimes set off with backticks, and sometimes left bare. I tried to
judge when the intention was introducing new terms or conventions
(double quotes), to reference a recently used command argument
(backticks), or to reference the abstract branch/commit (left bare).
Obviously these are not particularly crisp definitions, so my
decisions are fairly arbitrary ;). When a reference had already been
introduced, I changed further double-quoted instances to backticked
instances.
When new backticks increased the length of a line beyond others in
that block, I re-wrapped blocks to 72 columns.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 288 +++++++++++++++++++++---------------------
1 file changed, 145 insertions(+), 143 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 91f1822..a79b3e31 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -19,7 +19,7 @@ Further chapters cover more specialized topics.
Comprehensive reference documentation is available through the man
pages, or linkgit:git-help[1] command. For example, for the command
-"git clone <repo>", you can either use:
+`git clone <repo>`, you can either use:
------------------------------------------------
$ man git-clone
@@ -66,11 +66,11 @@ $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
The initial clone may be time-consuming for a large project, but you
will only need to clone once.
-The clone command creates a new directory named after the project ("git"
-or "linux-2.6" in the examples above). After you cd into this
+The clone command creates a new directory named after the project (`git`
+or `linux-2.6` in the examples above). After you cd into this
directory, you will see that it contains a copy of the project files,
called the <<def_working_tree,working tree>>, together with a special
-top-level directory named ".git", which contains all the information
+top-level directory named `.git`, which contains all the information
about the history of the project.
[[how-to-check-out]]
@@ -188,7 +188,7 @@ As you can see, a commit shows who made the latest change, what they
did, and why.
Every commit has a 40-hexdigit id, sometimes called the "object name" or the
-"SHA-1 id", shown on the first line of the "git show" output. You can usually
+"SHA-1 id", shown on the first line of the `git show` output. You can usually
refer to a commit by a shorter name, such as a tag or a branch name, but this
longer name can also be useful. Most importantly, it is a globally unique
name for this commit: so if you tell somebody else the object name (for
@@ -268,35 +268,35 @@ Manipulating branches
Creating, deleting, and modifying branches is quick and easy; here's
a summary of the commands:
-git branch::
+`git branch`::
list all branches
-git branch <branch>::
- create a new branch named <branch>, referencing the same
+`git branch <branch>`::
+ create a new branch named `<branch>`, referencing the same
point in history as the current branch
-git branch <branch> <start-point>::
- create a new branch named <branch>, referencing
- <start-point>, which may be specified any way you like,
+`git branch <branch> <start-point>`::
+ create a new branch named `<branch>`, referencing
+ `<start-point>`, which may be specified any way you like,
including using a branch name or a tag name
-git branch -d <branch>::
- delete the branch <branch>; if the branch you are deleting
+`git branch -d <branch>`::
+ delete the branch `<branch>`; if the branch you are deleting
points to a commit which is not reachable from the current
branch, this command will fail with a warning.
-git branch -D <branch>::
+`git branch -D <branch>`::
even if the branch points to a commit not reachable
from the current branch, you may know that that commit
is still reachable from some other branch or tag. In that
case it is safe to use this command to force Git to delete
the branch.
-git checkout <branch>::
- make the current branch <branch>, updating the working
- directory to reflect the version referenced by <branch>
-git checkout -b <new> <start-point>::
- create a new branch <new> referencing <start-point>, and
+`git checkout <branch>`::
+ make the current branch `<branch>`, updating the working
+ directory to reflect the version referenced by `<branch>`
+`git checkout -b <new> <start-point>`::
+ create a new branch `<new>` referencing `<start-point>`, and
check it out.
The special symbol "HEAD" can always be used to refer to the current
-branch. In fact, Git uses a file named "HEAD" in the .git directory to
-remember which branch is current:
+branch. In fact, Git uses a file named `HEAD` in the `.git` directory
+to remember which branch is current:
------------------------------------------------
$ cat .git/HEAD
@@ -346,7 +346,7 @@ of the HEAD in the repository that you cloned from. That repository
may also have had other branches, though, and your local repository
keeps branches which track each of those remote branches, called
remote-tracking branches, which you
-can view using the "-r" option to linkgit:git-branch[1]:
+can view using the `-r` option to linkgit:git-branch[1]:
------------------------------------------------
$ git branch -r
@@ -364,7 +364,7 @@ In this example, "origin" is called a remote repository, or "remote"
for short. The branches of this repository are called "remote
branches" from our point of view. The remote-tracking branches listed
above were created based on the remote branches at clone time and will
-be updated by "git fetch" (hence "git pull") and "git push". See
+be updated by `git fetch` (hence `git pull`) and `git push`. See
<<Updating-a-repository-With-git-fetch>> for details.
You might want to build on one of these remote-tracking branches
@@ -374,7 +374,7 @@ on a branch of your own, just as you would for a tag:
$ git checkout -b my-todo-copy origin/todo
------------------------------------------------
-You can also check out "origin/todo" directly to examine it or
+You can also check out `origin/todo` directly to examine it or
write a one-off patch. See <<detached-head,detached head>>.
Note that the name "origin" is just the name that Git uses by default
@@ -386,17 +386,17 @@ Naming branches, tags, and other references
Branches, remote-tracking branches, and tags are all references to
commits. All references are named with a slash-separated path name
-starting with "refs"; the names we've been using so far are actually
+starting with `refs`; the names we've been using so far are actually
shorthand:
- - The branch "test" is short for "refs/heads/test".
- - The tag "v2.6.18" is short for "refs/tags/v2.6.18".
- - "origin/master" is short for "refs/remotes/origin/master".
+ - The branch `test` is short for `refs/heads/test`.
+ - The tag `v2.6.18` is short for `refs/tags/v2.6.18`.
+ - `origin/master` is short for `refs/remotes/origin/master`.
The full name is occasionally useful if, for example, there ever
exists a tag and a branch with the same name.
-(Newly created refs are actually stored in the .git/refs directory,
+(Newly created refs are actually stored in the `.git/refs` directory,
under the path given by their name. However, for efficiency reasons
they may also be packed together in a single file; see
linkgit:git-pack-refs[1]).
@@ -418,7 +418,7 @@ Eventually the developer cloned from will do additional work in her
repository, creating new commits and advancing the branches to point
at the new commits.
-The command "git fetch", with no arguments, will update all of the
+The command `git fetch`, with no arguments, will update all of the
remote-tracking branches to the latest version found in her
repository. It will not touch any of your own branches--not even the
"master" branch that was created for you on clone.
@@ -438,7 +438,7 @@ $ git fetch linux-nfs
-------------------------------------------------
New remote-tracking branches will be stored under the shorthand name
-that you gave "git remote add", in this case linux-nfs:
+that you gave `git remote add`, in this case `linux-nfs`:
-------------------------------------------------
$ git branch -r
@@ -446,10 +446,10 @@ linux-nfs/master
origin/master
-------------------------------------------------
-If you run "git fetch <remote>" later, the remote-tracking branches for the
-named <remote> will be updated.
+If you run `git fetch <remote>` later, the remote-tracking branches
+for the named `<remote>` will be updated.
-If you examine the file .git/config, you will see that Git has added
+If you examine the file `.git/config`, you will see that Git has added
a new stanza:
-------------------------------------------------
@@ -462,7 +462,7 @@ $ cat .git/config
-------------------------------------------------
This is what causes Git to track the remote's branches; you may modify
-or delete these configuration options by editing .git/config with a
+or delete these configuration options by editing `.git/config` with a
text editor. (See the "CONFIGURATION FILE" section of
linkgit:git-config[1] for details.)
@@ -499,7 +499,7 @@ Bisecting: 3537 revisions left to test after this
[65934a9a028b88e83e2b0f8b36618fe503349f8e] BLOCK: Make USB storage depend on SCSI rather than selecting it [try #6]
-------------------------------------------------
-If you run "git branch" at this point, you'll see that Git has
+If you run `git branch` at this point, you'll see that Git has
temporarily moved you in "(no branch)". HEAD is now detached from any
branch and points directly to a commit (with commit id 65934...) that
is reachable from "master" but not from v2.6.18. Compile and test it,
@@ -545,11 +545,11 @@ id, and check it out with:
$ git reset --hard fb47ddb2db...
-------------------------------------------------
-then test, run "bisect good" or "bisect bad" as appropriate, and
+then test, run `bisect good` or `bisect bad` as appropriate, and
continue.
-Instead of "git bisect visualize" and then "git reset --hard
-fb47ddb2db...", you might just want to tell Git that you want to skip
+Instead of `git bisect visualize` and then `git reset --hard
+fb47ddb2db...`, you might just want to tell Git that you want to skip
the current commit:
-------------------------------------------------
@@ -561,8 +561,8 @@ bad one between some first skipped commits and a later bad commit.
There are also ways to automate the bisecting process if you have a
test script that can tell a good from a bad commit. See
-linkgit:git-bisect[1] for more information about this and other "git
-bisect" features.
+linkgit:git-bisect[1] for more information about this and other `git
+bisect` features.
[[naming-commits]]
Naming commits
@@ -591,7 +591,7 @@ $ git show HEAD~4 # the great-great-grandparent
-------------------------------------------------
Recall that merge commits may have more than one parent; by default,
-^ and ~ follow the first parent listed in the commit, but you can
+`^` and `~` follow the first parent listed in the commit, but you can
also choose:
-------------------------------------------------
@@ -640,7 +640,7 @@ running
$ git tag stable-1 1b2e1d63ff
-------------------------------------------------
-You can use stable-1 to refer to the commit 1b2e1d63ff.
+You can use `stable-1` to refer to the commit 1b2e1d63ff.
This creates a "lightweight" tag. If you would also like to include a
comment with the tag, and possibly sign it cryptographically, then you
@@ -669,7 +669,7 @@ $ git log -S'foo()' # commits which add or remove any file data
-------------------------------------------------
And of course you can combine all of these; the following finds
-commits since v2.5 which touch the Makefile or any file under fs:
+commits since v2.5 which touch the `Makefile` or any file under `fs`:
-------------------------------------------------
$ git log v2.5.. Makefile fs/
@@ -681,7 +681,7 @@ You can also ask git log to show patches:
$ git log -p
-------------------------------------------------
-See the "--pretty" option in the linkgit:git-log[1] man page for more
+See the `--pretty` option in the linkgit:git-log[1] man page for more
display options.
Note that git log starts with the most recent commit and works
@@ -742,8 +742,8 @@ Examples
Counting the number of commits on a branch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Suppose you want to know how many commits you've made on "mybranch"
-since it diverged from "origin":
+Suppose you want to know how many commits you've made on `mybranch`
+since it diverged from `origin`:
-------------------------------------------------
$ git log --pretty=oneline origin..mybranch | wc -l
@@ -780,7 +780,7 @@ $ git rev-list master
e05db0fd4f31dde7005f075a84f96b360d05984b
-------------------------------------------------
-Or you could recall that the ... operator selects all commits
+Or you could recall that the `...` operator selects all commits
contained reachable from either one reference or the other but not
both: so
@@ -880,7 +880,7 @@ Showing commits unique to a given branch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suppose you would like to see all the commits reachable from the branch
-head named "master" but not from any other head in your repository.
+head named `master` but not from any other head in your repository.
We can list all the heads in this repository with
linkgit:git-show-ref[1]:
@@ -894,7 +894,7 @@ a07157ac624b2524a059a3414e99f6f44bebc1e7 refs/heads/master
1e87486ae06626c2f31eaa63d26fc0fd646c8af2 refs/heads/tutorial-fixes
-------------------------------------------------
-We can get just the branch-head names, and remove "master", with
+We can get just the branch-head names, and remove `master`, with
the help of the standard utilities cut and grep:
-------------------------------------------------
@@ -935,7 +935,7 @@ $ git archive --format=tar --prefix=project/ HEAD | gzip >latest.tar.gz
-------------------------------------------------
will use HEAD to produce a tar archive in which each filename is
-preceded by "project/".
+preceded by `project/`.
If you're releasing a new version of a software project, you may want
to simultaneously make a changelog to include in the release
@@ -993,7 +993,7 @@ Telling Git your name
Before creating any commits, you should introduce yourself to Git. The
easiest way to do so is to make sure the following lines appear in a
-file named .gitconfig in your home directory:
+file named `.gitconfig` in your home directory:
------------------------------------------------
[user]
@@ -1045,7 +1045,7 @@ at step 3, Git maintains a snapshot of the tree's contents in a
special staging area called "the index."
At the beginning, the content of the index will be identical to
-that of the HEAD. The command "git diff --cached", which shows
+that of the HEAD. The command `git diff --cached`, which shows
the difference between the HEAD and the index, should therefore
produce no output at that point.
@@ -1084,7 +1084,7 @@ $ git diff
shows the difference between the working tree and the index file.
-Note that "git add" always adds just the current contents of a file
+Note that `git add` always adds just the current contents of a file
to the index; further changes to the same file will be ignored unless
you run `git add` on the file again.
@@ -1155,8 +1155,9 @@ annoying to have these untracked files lying around; e.g. they make
`git add .` practically useless, and they keep showing up in the output of
`git status`.
-You can tell Git to ignore certain files by creating a file called .gitignore
-in the top level of your working directory, with contents such as:
+You can tell Git to ignore certain files by creating a file called
+`.gitignore` in the top level of your working directory, with contents
+such as:
-------------------------------------------------
# Lines starting with '#' are considered comments.
@@ -1180,10 +1181,10 @@ for other users who clone your repository.
If you wish the exclude patterns to affect only certain repositories
(instead of every repository for a given project), you may instead put
-them in a file in your repository named .git/info/exclude, or in any file
-specified by the `core.excludesfile` configuration variable. Some Git
-commands can also take exclude patterns directly on the command line.
-See linkgit:gitignore[5] for the details.
+them in a file in your repository named `.git/info/exclude`, or in any
+file specified by the `core.excludesfile` configuration variable.
+Some Git commands can also take exclude patterns directly on the
+command line. See linkgit:gitignore[5] for the details.
[[how-to-merge]]
How to merge
@@ -1196,10 +1197,10 @@ linkgit:git-merge[1]:
$ git merge branchname
-------------------------------------------------
-merges the development in the branch "branchname" into the current
+merges the development in the branch `branchname` into the current
branch.
-A merge is made by combining the changes made in "branchname" and the
+A merge is made by combining the changes made in `branchname` and the
changes made up to the latest commit in your current branch since
their histories forked. The work tree is overwritten by the result of
the merge when this combining is done cleanly, or overwritten by a
@@ -1321,7 +1322,7 @@ that part is not conflicting and is not shown. Same for stage 3).
The diff above shows the differences between the working-tree version of
file.txt and the stage 2 and stage 3 versions. So instead of preceding
-each line by a single "+" or "-", it now uses two columns: the first
+each line by a single `+` or `-`, it now uses two columns: the first
column is used for differences between the first parent and the working
directory copy, and the second for differences between the second parent
and the working directory copy. (See the "COMBINED DIFF FORMAT" section
@@ -1602,7 +1603,7 @@ dangling tree b24c2473f1fd3d91352a624795be026d64c8841f
You will see informational messages on dangling objects. They are objects
that still exist in the repository but are no longer referenced by any of
-your branches, and can (and will) be removed after a while with "gc".
+your branches, and can (and will) be removed after a while with `gc`.
You can run `git fsck --no-dangling` to suppress these messages, and still
view real errors.
@@ -1614,9 +1615,9 @@ Recovering lost changes
Reflogs
^^^^^^^
-Say you modify a branch with +linkgit:git-reset[1] \--hard+, and then
-realize that the branch was the only reference you had to that point in
-history.
+Say you modify a branch with <<fixing-mistakes,`git reset --hard`>>,
+and then realize that the branch was the only reference you had to
+that point in history.
Fortunately, Git also keeps a log, called a "reflog", of all the
previous values of each branch. So in this case you can still find the
@@ -1627,8 +1628,8 @@ $ git log master@{1}
-------------------------------------------------
This lists the commits reachable from the previous version of the
-"master" branch head. This syntax can be used with any Git command
-that accepts a commit, not just with git log. Some other examples:
+`master` branch head. This syntax can be used with any Git command
+that accepts a commit, not just with `git log`. Some other examples:
-------------------------------------------------
$ git show master@{2} # See where the branch pointed 2,
@@ -1732,8 +1733,8 @@ one step:
$ git pull origin master
-------------------------------------------------
-In fact, if you have "master" checked out, then this branch has been
-configured by "git clone" to get changes from the HEAD branch of the
+In fact, if you have `master` checked out, then this branch has been
+configured by `git clone` to get changes from the HEAD branch of the
origin repository. So often you can
accomplish the above with just a simple
@@ -1748,11 +1749,11 @@ the current branch.
More generally, a branch that is created from a remote-tracking branch
will pull
by default from that branch. See the descriptions of the
-branch.<name>.remote and branch.<name>.merge options in
+`branch.<name>.remote` and `branch.<name>.merge` options in
linkgit:git-config[1], and the discussion of the `--track` option in
linkgit:git-checkout[1], to learn how to control these defaults.
-In addition to saving you keystrokes, "git pull" also helps you by
+In addition to saving you keystrokes, `git pull` also helps you by
producing a default commit message documenting the branch and
repository that you pulled from.
@@ -1760,7 +1761,7 @@ repository that you pulled from.
<<fast-forwards,fast-forward>>; instead, your branch will just be
updated to point to the latest commit from the upstream branch.)
-The `git pull` command can also be given "." as the "remote" repository,
+The `git pull` command can also be given `.` as the "remote" repository,
in which case it just merges in a branch from the current repository; so
the commands
@@ -1785,7 +1786,7 @@ $ git format-patch origin
-------------------------------------------------
will produce a numbered series of files in the current directory, one
-for each patch in the current branch but not in origin/HEAD.
+for each patch in the current branch but not in `origin/HEAD`.
`git format-patch` can include an initial "cover letter". You can insert
commentary on individual patches after the three dash line which
@@ -1807,7 +1808,7 @@ Importing patches to a project
Git also provides a tool called linkgit:git-am[1] (am stands for
"apply mailbox"), for importing such an emailed series of patches.
Just save all of the patch-containing messages, in order, into a
-single mailbox file, say "patches.mbox", then run
+single mailbox file, say `patches.mbox`, then run
-------------------------------------------------
$ git am -3 patches.mbox
@@ -1815,7 +1816,7 @@ $ git am -3 patches.mbox
Git will apply each patch in order; if any conflicts are found, it
will stop, and you can fix the conflicts as described in
-"<<resolving-a-merge,Resolving a merge>>". (The "-3" option tells
+"<<resolving-a-merge,Resolving a merge>>". (The `-3` option tells
Git to perform a merge; if you would prefer it just to abort and
leave your tree and index untouched, you may omit that option.)
@@ -1891,7 +1892,7 @@ We explain how to do this in the following sections.
Setting up a public repository
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Assume your personal repository is in the directory ~/proj. We
+Assume your personal repository is in the directory `~/proj`. We
first create a new clone of the repository and tell `git daemon` that it
is meant to be public:
@@ -1901,10 +1902,10 @@ $ touch proj.git/git-daemon-export-ok
-------------------------------------------------
The resulting directory proj.git contains a "bare" git repository--it is
-just the contents of the ".git" directory, without any files checked out
+just the contents of the `.git` directory, without any files checked out
around it.
-Next, copy proj.git to the server where you plan to host the
+Next, copy `proj.git` to the server where you plan to host the
public repository. You can use scp, rsync, or whatever is most
convenient.
@@ -1915,8 +1916,8 @@ Exporting a Git repository via the Git protocol
This is the preferred method.
If someone else administers the server, they should tell you what
-directory to put the repository in, and what git:// URL it will appear
-at. You can then skip to the section
+directory to put the repository in, and what `git://` URL it will
+appear at. You can then skip to the section
"<<pushing-changes-to-a-public-repository,Pushing changes to a public
repository>>", below.
@@ -1951,7 +1952,7 @@ $ mv hooks/post-update.sample hooks/post-update
(For an explanation of the last two lines, see
linkgit:git-update-server-info[1] and linkgit:githooks[5].)
-Advertise the URL of proj.git. Anybody else should then be able to
+Advertise the URL of `proj.git`. Anybody else should then be able to
clone or pull from that URL, for example with a command line like:
-------------------------------------------------
@@ -1974,8 +1975,8 @@ access, which you will need to update the public repository with the
latest changes created in your private repository.
The simplest way to do this is using linkgit:git-push[1] and ssh; to
-update the remote branch named "master" with the latest state of your
-branch named "master", run
+update the remote branch named `master` with the latest state of your
+branch named `master`, run
-------------------------------------------------
$ git push ssh://yourserver.com/~you/proj.git master:master
@@ -1991,7 +1992,7 @@ As with `git fetch`, `git push` will complain if this does not result in a
<<fast-forwards,fast-forward>>; see the following section for details on
handling this case.
-Note that the target of a "push" is normally a
+Note that the target of a `push` is normally a
<<def_bare_repository,bare>> repository. You can also push to a
repository that has a checked-out working tree, but the working tree
will not be updated by the push. This may lead to unexpected results if
@@ -2018,9 +2019,9 @@ which lets you do the same push with just
$ git push public-repo master
-------------------------------------------------
-See the explanations of the remote.<name>.url, branch.<name>.remote,
-and remote.<name>.push options in linkgit:git-config[1] for
-details.
+See the explanations of the `remote.<name>.url`,
+`branch.<name>.remote`, and `remote.<name>.push` options in
+linkgit:git-config[1] for details.
[[forcing-push]]
What to do when a push fails
@@ -2155,7 +2156,7 @@ linkgit:git-fetch[1] to keep them up-to-date; see
Now create the branches in which you are going to work; these start out
at the current tip of origin/master branch, and should be set up (using
-the --track option to linkgit:git-branch[1]) to merge changes in from
+the `--track` option to linkgit:git-branch[1]) to merge changes in from
Linus by default.
-------------------------------------------------
@@ -2174,7 +2175,7 @@ Important note! If you have any local changes in these branches, then
this merge will create a commit object in the history (with no local
changes Git will simply do a "fast-forward" merge). Many people dislike
the "noise" that this creates in the Linux history, so you should avoid
-doing this capriciously in the "release" branch, as these noisy commits
+doing this capriciously in the `release` branch, as these noisy commits
will become part of the permanent history when you ask Linus to pull
from the release branch.
@@ -2216,7 +2217,7 @@ patches), and create a new branch from a recent stable tag of
Linus's branch. Picking a stable base for your branch will:
1) help you: by avoiding inclusion of unrelated and perhaps lightly
tested changes
-2) help future bug hunters that use "git bisect" to find problems
+2) help future bug hunters that use `git bisect` to find problems
-------------------------------------------------
$ git checkout -b speed-up-spinlocks v2.6.35
@@ -2241,9 +2242,9 @@ It is unlikely that you would have any conflicts here ... but you might if you
spent a while on this step and had also pulled new versions from upstream.
Some time later when enough time has passed and testing done, you can pull the
-same branch into the "release" tree ready to go upstream. This is where you
+same branch into the `release` tree ready to go upstream. This is where you
see the value of keeping each patch (or patch series) in its own branch. It
-means that the patches can be moved into the "release" tree in any order.
+means that the patches can be moved into the `release` tree in any order.
-------------------------------------------------
$ git checkout release && git pull . speed-up-spinlocks
@@ -2276,7 +2277,7 @@ If it has been merged, then there will be no output.)
Once a patch completes the great cycle (moving from test to release,
then pulled by Linus, and finally coming back into your local
-"origin/master" branch), the branch for this change is no longer needed.
+`origin/master` branch), the branch for this change is no longer needed.
You detect this when the output from:
-------------------------------------------------
@@ -2291,8 +2292,8 @@ $ git branch -d branchname
Some changes are so trivial that it is not necessary to create a separate
branch and then merge into each of the test and release branches. For
-these changes, just apply directly to the "release" branch, and then
-merge that into the "test" branch.
+these changes, just apply directly to the `release` branch, and then
+merge that into the `test` branch.
To create diffstat and shortlog summaries of changes to include in a "please
pull" request to Linus you can use:
@@ -2467,8 +2468,8 @@ you are rewriting history.
Keeping a patch series up to date using git rebase
--------------------------------------------------
-Suppose that you create a branch "mywork" on a remote-tracking branch
-"origin", and create some commits on top of it:
+Suppose that you create a branch `mywork` on a remote-tracking branch
+`origin`, and create some commits on top of it:
-------------------------------------------------
$ git checkout -b mywork origin
@@ -2480,7 +2481,7 @@ $ git commit
-------------------------------------------------
You have performed no merges into mywork, so it is just a simple linear
-sequence of patches on top of "origin":
+sequence of patches on top of `origin`:
................................................
o--o--O <-- origin
@@ -2489,7 +2490,7 @@ sequence of patches on top of "origin":
................................................
Some more interesting work has been done in the upstream project, and
-"origin" has advanced:
+`origin` has advanced:
................................................
o--o--O--o--o--o <-- origin
@@ -2497,7 +2498,7 @@ Some more interesting work has been done in the upstream project, and
a--b--c <-- mywork
................................................
-At this point, you could use "pull" to merge your changes back in;
+At this point, you could use `pull` to merge your changes back in;
the result would create a new merge commit, like this:
................................................
@@ -2516,7 +2517,7 @@ $ git rebase origin
-------------------------------------------------
This will remove each of your commits from mywork, temporarily saving
-them as patches (in a directory named ".git/rebase-apply"), update mywork to
+them as patches (in a directory named `.git/rebase-apply`), update mywork to
point at the latest version of origin, then apply each of the saved
patches to the new mywork. The result will look like:
@@ -2780,10 +2781,10 @@ arbitrary name:
$ git fetch origin todo:my-todo-work
-------------------------------------------------
-The first argument, "origin", just tells Git to fetch from the
+The first argument, `origin`, just tells Git to fetch from the
repository you originally cloned from. The second argument tells Git
-to fetch the branch named "todo" from the remote repository, and to
-store it locally under the name refs/heads/my-todo-work.
+to fetch the branch named `todo` from the remote repository, and to
+store it locally under the name `refs/heads/my-todo-work`.
You can also fetch branches from other repositories; so
@@ -2791,8 +2792,8 @@ You can also fetch branches from other repositories; so
$ git fetch git://example.com/proj.git master:example-master
-------------------------------------------------
-will create a new branch named "example-master" and store in it the
-branch named "master" from the repository at the given URL. If you
+will create a new branch named `example-master` and store in it the
+branch named `master` from the repository at the given URL. If you
already have a branch named example-master, it will attempt to
<<fast-forwards,fast-forward>> to the commit given by example.com's
master branch. In more detail:
@@ -2801,7 +2802,7 @@ master branch. In more detail:
git fetch and fast-forwards
---------------------------
-In the previous example, when updating an existing branch, "git fetch"
+In the previous example, when updating an existing branch, `git fetch`
checks to make sure that the most recent commit on the remote
branch is a descendant of the most recent commit on your copy of the
branch before updating your copy of the branch to point at the new
@@ -2827,11 +2828,11 @@ resulting in a situation like:
o--o--o <-- new head of the branch
................................................
-In this case, "git fetch" will fail, and print out a warning.
+In this case, `git fetch` will fail, and print out a warning.
In that case, you can still force Git to update to the new head, as
described in the following section. However, note that in the
-situation above this may mean losing the commits labeled "a" and "b",
+situation above this may mean losing the commits labeled `a` and `b`,
unless you've already created a reference of your own pointing to
them.
@@ -2846,7 +2847,7 @@ descendant of the old head, you may force the update with:
$ git fetch git://example.com/proj.git +master:refs/remotes/example/master
-------------------------------------------------
-Note the addition of the "+" sign. Alternatively, you can use the "-f"
+Note the addition of the `+` sign. Alternatively, you can use the `-f`
flag to force updates of all the fetched branches, as in:
-------------------------------------------------
@@ -2860,7 +2861,7 @@ may be lost, as we saw in the previous section.
Configuring remote-tracking branches
------------------------------------
-We saw above that "origin" is just a shortcut to refer to the
+We saw above that `origin` is just a shortcut to refer to the
repository that you originally cloned from. This information is
stored in Git configuration variables, which you can see using
linkgit:git-config[1]:
@@ -2969,7 +2970,7 @@ Commit Object
~~~~~~~~~~~~~
The "commit" object links a physical state of a tree with a description
-of how we got there and why. Use the --pretty=raw option to
+of how we got there and why. Use the `--pretty=raw` option to
linkgit:git-show[1] or linkgit:git-log[1] to examine your favorite
commit:
@@ -3011,7 +3012,7 @@ of the tree referred to by this commit with the trees associated with
its parents. In particular, Git does not attempt to record file renames
explicitly, though it can identify cases where the existence of the same
file data at changing paths suggests a rename. (See, for example, the
--M option to linkgit:git-diff[1]).
+`-M` option to linkgit:git-diff[1]).
A commit is usually created by linkgit:git-commit[1], which creates a
commit whose parent is normally the current HEAD, and whose tree is
@@ -3062,7 +3063,7 @@ Blob Object
~~~~~~~~~~~
You can use linkgit:git-show[1] to examine the contents of a blob; take,
-for example, the blob in the entry for "COPYING" from the tree above:
+for example, the blob in the entry for `COPYING` from the tree above:
------------------------------------------------
$ git show 6ff87c4664
@@ -3145,14 +3146,14 @@ nLE/L9aUXdWeTFPron96DLA=
See the linkgit:git-tag[1] command to learn how to create and verify tag
objects. (Note that linkgit:git-tag[1] can also be used to create
"lightweight tags", which are not tag objects at all, but just simple
-references whose names begin with "refs/tags/").
+references whose names begin with `refs/tags/`).
[[pack-files]]
How Git stores objects efficiently: pack files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Newly created objects are initially created in a file named after the
-object's SHA-1 hash (stored in .git/objects).
+object's SHA-1 hash (stored in `.git/objects`).
Unfortunately this system becomes inefficient once a project has a
lot of objects. Try this on an old project:
@@ -3193,9 +3194,9 @@ $ git prune
to remove any of the "loose" objects that are now contained in the
pack. This will also remove any unreferenced objects (which may be
-created when, for example, you use "git reset" to remove a commit).
+created when, for example, you use `git reset` to remove a commit).
You can verify that the loose objects are gone by looking at the
-.git/objects directory or by running
+`.git/objects` directory or by running
------------------------------------------------
$ git count-objects
@@ -3222,7 +3223,7 @@ branch still exists, as does everything it pointed to. The branch
pointer itself just doesn't, since you replaced it with another one.
There are also other situations that cause dangling objects. For
-example, a "dangling blob" may arise because you did a "git add" of a
+example, a "dangling blob" may arise because you did a `git add` of a
file, but then, before you actually committed it and made it part of the
bigger picture, you changed something else in that file and committed
that *updated* thing--the old state that you added originally ends up
@@ -3265,14 +3266,14 @@ $ git show <dangling-blob/tree-sha-goes-here>
------------------------------------------------
to show what the contents of the blob were (or, for a tree, basically
-what the "ls" for that directory was), and that may give you some idea
+what the `ls` for that directory was), and that may give you some idea
of what the operation was that left that dangling object.
Usually, dangling blobs and trees aren't very interesting. They're
almost always the result of either being a half-way mergebase (the blob
will often even have the conflict markers from a merge in it, if you
have had conflicting merges that you fixed up by hand), or simply
-because you interrupted a "git fetch" with ^C or something like that,
+because you interrupted a `git fetch` with ^C or something like that,
leaving _some_ of the new objects in the object database, but just
dangling and useless.
@@ -3283,16 +3284,16 @@ state, you can just prune all unreachable objects:
$ git prune
------------------------------------------------
-and they'll be gone. But you should only run "git prune" on a quiescent
+and they'll be gone. But you should only run `git prune` on a quiescent
repository--it's kind of like doing a filesystem fsck recovery: you
don't want to do that while the filesystem is mounted.
-(The same is true of "git fsck" itself, btw, but since
+(The same is true of `git fsck` itself, btw, but since
`git fsck` never actually *changes* the repository, it just reports
on what it found, `git fsck` itself is never 'dangerous' to run.
Running it while somebody is actually changing the repository can cause
confusing and scary messages, but it won't actually do anything bad. In
-contrast, running "git prune" while somebody is actively changing the
+contrast, running `git prune` while somebody is actively changing the
repository is a *BAD* idea).
[[recovering-from-repository-corruption]]
@@ -3330,7 +3331,7 @@ missing blob 4b9458b3786228369c63936db65827de3cc06200
Now you know that blob 4b9458b3 is missing, and that the tree 2d9263c6
points to it. If you could find just one copy of that missing blob
object, possibly in some other repository, you could move it into
-.git/objects/4b/9458b3... and be done. Suppose you can't. You can
+`.git/objects/4b/9458b3...` and be done. Suppose you can't. You can
still examine the tree that pointed to it with linkgit:git-ls-tree[1],
which might output something like:
@@ -3345,10 +3346,10 @@ $ git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
------------------------------------------------
So now you know that the missing blob was the data for a file named
-"myfile". And chances are you can also identify the directory--let's
-say it's in "somedirectory". If you're lucky the missing copy might be
+`myfile`. And chances are you can also identify the directory--let's
+say it's in `somedirectory`. If you're lucky the missing copy might be
the same as the copy you have checked out in your working tree at
-"somedirectory/myfile"; you can test whether that's right with
+`somedirectory/myfile`; you can test whether that's right with
linkgit:git-hash-object[1]:
------------------------------------------------
@@ -3403,7 +3404,7 @@ $ git hash-object -w <recreated-file>
and your repository is good again!
-(Btw, you could have ignored the fsck, and started with doing a
+(Btw, you could have ignored the `fsck`, and started with doing a
------------------------------------------------
$ git log --raw --all
@@ -3417,7 +3418,7 @@ just missing one particular blob version.
The index
-----------
-The index is a binary file (generally kept in .git/index) containing a
+The index is a binary file (generally kept in `.git/index`) containing a
sorted list of path names, each with permissions and the SHA-1 of a blob
object; linkgit:git-ls-files[1] can show you the contents of the index:
@@ -3557,7 +3558,7 @@ $ ls -a
The `git submodule add <repo> <path>` command does a couple of things:
-- It clones the submodule from <repo> to the given <path> under the
+- It clones the submodule from `<repo>` to the given `<path>` under the
current directory and by default checks out the master branch.
- It adds the submodule's clone path to the linkgit:gitmodules[5] file and
adds this file to the index, ready to be committed.
@@ -3685,11 +3686,11 @@ Unable to checkout '261dfac35cb99d380eb966e102c1197139f7fa24' in submodule path
In older Git versions it could be easily forgotten to commit new or modified
files in a submodule, which silently leads to similar problems as not pushing
-the submodule changes. Starting with Git 1.7.0 both "git status" and "git diff"
+the submodule changes. Starting with Git 1.7.0 both `git status` and `git diff`
in the superproject show submodules as modified when they contain new or
-modified files to protect against accidentally committing such a state. "git
-diff" will also add a "-dirty" to the work tree side when generating patch
-output or used with the --submodule option:
+modified files to protect against accidentally committing such a state. `git
+diff` will also add a `-dirty` to the work tree side when generating patch
+output or used with the `--submodule` option:
-------------------------------------------------
$ git diff
@@ -3863,7 +3864,7 @@ or, if you want to check out all of the index, use `-a`.
NOTE! `git checkout-index` normally refuses to overwrite old files, so
if you have an old version of the tree already checked out, you will
-need to use the "-f" flag ('before' the "-a" flag or the filename) to
+need to use the `-f` flag ('before' the `-a` flag or the filename) to
'force' the checkout.
@@ -3874,7 +3875,7 @@ from one representation to the other:
Tying it all together
~~~~~~~~~~~~~~~~~~~~~
-To commit a tree you have instantiated with "git write-tree", you'd
+To commit a tree you have instantiated with `git write-tree`, you'd
create a "commit" object that refers to that tree and the history
behind it--most notably the "parent" commits that preceded it in
history.
@@ -4135,8 +4136,9 @@ As a result, the general consistency of an object can always be tested
independently of the contents or the type of the object: all objects can
be validated by verifying that (a) their hashes match the content of the
file and (b) the object successfully inflates to a stream of bytes that
-forms a sequence of <ascii type without space> {plus} <space> {plus} <ascii decimal
-size> {plus} <byte\0> {plus} <binary object data>.
+forms a sequence of
+`<ascii type without space> + <space> + <ascii decimal size> +
+<byte\0> + <binary object data>`.
The structured objects can further have their structure and
connectivity to other objects verified. This is generally done with
@@ -4615,10 +4617,10 @@ Think about how to create a clear chapter dependency graph that will
allow people to get to important topics without necessarily reading
everything in between.
-Scan Documentation/ for other stuff left out; in particular:
+Scan `Documentation/` for other stuff left out; in particular:
- howto's
-- some of technical/?
+- some of `technical/`?
- hooks
- list of commands in linkgit:git[1]
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v3 3/9] user-manual: Give 'git push -f' as an alternative to +master
From: W. Trevor King @ 2013-02-18 0:15 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, Jonathan Nieder, W. Trevor King
In-Reply-To: <cover.1361146398.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
This mirrors existing language in the description of 'git fetch'.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index dbffd0a..ba06b7e 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2051,6 +2051,13 @@ branch name with a plus sign:
$ git push ssh://yourserver.com/~you/proj.git +master
-------------------------------------------------
+Note the addition of the `+` sign. Alternatively, you can use the
+`-f` flag to force the remote update, as in:
+
+-------------------------------------------------
+$ git push -f ssh://yourserver.com/~you/proj.git master
+-------------------------------------------------
+
Normally whenever a branch head in a public repository is modified, it
is modified to point to a descendant of the commit that it pointed to
before. By forcing a push in this situation, you break that convention.
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v3 7/9] user-manual: Use request-pull to generate "please pull" text
From: W. Trevor King @ 2013-02-18 0:15 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, Jonathan Nieder, W. Trevor King
In-Reply-To: <cover.1361146398.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
Less work and more error checking (e.g. does a merge base exist?).
Add an explicit push before request-pull to satisfy request-pull,
which checks to make sure the references are publically available.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index d9276d7..cf09ddf 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2304,16 +2304,11 @@ these changes, just apply directly to the `release` branch, and then
merge that into the `test` branch.
To create diffstat and shortlog summaries of changes to include in a "please
-pull" request to Linus you can use:
+pull" request to Linus you can use linkgit:git-request-pull[1]:
-------------------------------------------------
-$ git diff --stat origin..release
--------------------------------------------------
-
-and
-
--------------------------------------------------
-$ git log -p origin..release | git shortlog
+$ git push mytree
+$ git request-pull origin mytree release
-------------------------------------------------
Here are some of the scripts that simplify all this even further.
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v3 2/9] user-manual: Reorganize the reroll sections, adding 'git rebase -i'
From: W. Trevor King @ 2013-02-18 0:15 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, Jonathan Nieder, W. Trevor King
In-Reply-To: <cover.1361146398.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
I think this interface is often more convenient than extended cherry
picking or using 'git format-patch'. In fact, I removed the
cherry-pick section entirely. The entry-level suggestions for
rerolling are now:
1. git commit --amend
2. git format-patch origin
git reset --hard origin
...edit and reorder patches...
git am *.patch
3. git rebase -i origin
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 110 ++++++++++++++++++++++++------------------
1 file changed, 63 insertions(+), 47 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index a060eb6..dbffd0a 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2538,6 +2538,12 @@ return mywork to the state it had before you started the rebase:
$ git rebase --abort
-------------------------------------------------
+If you need to reorder or edit a number of commits in a branch, it may
+be easier to use `git rebase -i`, which allows you to reorder and
+squash commits, as well as marking them for individual editing during
+the rebase. See <<interactive-rebase>> for details, and
+<<reordering-patch-series>> for alternatives.
+
[[rewriting-one-commit]]
Rewriting a single commit
-------------------------
@@ -2552,71 +2558,81 @@ $ git commit --amend
which will replace the old commit by a new commit incorporating your
changes, giving you a chance to edit the old commit message first.
-You can also use a combination of this and linkgit:git-rebase[1] to
-replace a commit further back in your history and recreate the
-intervening changes on top of it. First, tag the problematic commit
-with
-
--------------------------------------------------
-$ git tag bad mywork~5
--------------------------------------------------
-
-(Either gitk or `git log` may be useful for finding the commit.)
+[[reordering-patch-series]]
+Reordering or selecting from a patch series
+-------------------------------------------
-Then check out that commit, edit it, and rebase the rest of the series
-on top of it (note that we could check out the commit on a temporary
-branch, but instead we're using a <<detached-head,detached head>>):
+Sometimes you want to edit a commit deeper in your history. One
+approach is to use `git format-patch` to create a series of patches,
+then reset the state to before the patches:
-------------------------------------------------
-$ git checkout bad
-$ # make changes here and update the index
-$ git commit --amend
-$ git rebase --onto HEAD bad mywork
+$ git format-patch origin
+$ git reset --hard origin
-------------------------------------------------
-When you're done, you'll be left with mywork checked out, with the top
-patches on mywork reapplied on top of your modified commit. You can
-then clean up with
+Then modify, reorder, or eliminate patches as preferred before applying
+them again with linkgit:git-am[1]:
-------------------------------------------------
-$ git tag -d bad
+$ git am *.patch
-------------------------------------------------
-Note that the immutable nature of Git history means that you haven't really
-"modified" existing commits; instead, you have replaced the old commits with
-new commits having new object names.
+[[interactive-rebase]]
+Using interactive rebases
+-------------------------
-[[reordering-patch-series]]
-Reordering or selecting from a patch series
--------------------------------------------
+You can also edit a patch series with an interactive rebase. This is
+the same as <<reordering-patch-series,reordering a patch series using
+`format-patch`>>, so use whichever interface you like best.
-Given one existing commit, the linkgit:git-cherry-pick[1] command
-allows you to apply the change introduced by that commit and create a
-new commit that records it. So, for example, if "mywork" points to a
-series of patches on top of "origin", you might do something like:
+Rebase your current HEAD on the last commit you want to retain as-is.
+For example, if you want to reorder the last 5 commits, use:
-------------------------------------------------
-$ git checkout -b mywork-new origin
-$ gitk origin..mywork &
+$ git rebase -i HEAD~5
-------------------------------------------------
-and browse through the list of patches in the mywork branch using gitk,
-applying them (possibly in a different order) to mywork-new using
-cherry-pick, and possibly modifying them as you go using `git commit --amend`.
-The linkgit:git-gui[1] command may also help as it allows you to
-individually select diff hunks for inclusion in the index (by
-right-clicking on the diff hunk and choosing "Stage Hunk for Commit").
-
-Another technique is to use `git format-patch` to create a series of
-patches, then reset the state to before the patches:
+This will open your editor with a list of the commits you're rebasing
-------------------------------------------------
-$ git format-patch origin
-$ git reset --hard origin
--------------------------------------------------
+pick deadbee The oneline of this commit
+pick fa1afe1 The oneline of the next commit
+...
-Then modify, reorder, or eliminate patches as preferred before applying
-them again with linkgit:git-am[1].
+# Rebase c0ffeee..deadbee onto c0ffeee
+#
+# Commands:
+# p, pick = use commit
+# r, reword = use commit, but edit the commit message
+# e, edit = use commit, but stop for amending
+# s, squash = use commit, but meld into previous commit
+# f, fixup = like "squash", but discard this commit's log message
+# x, exec = run command (the rest of the line) using shell
+#
+# These lines can be re-ordered; they are executed from top to bottom.
+#
+# If you remove a line here THAT COMMIT WILL BE LOST.
+#
+# However, if you remove everything, the rebase will be aborted.
+#
+# Note that empty commits are commented out
+-------------------------------------------------
+
+As explained in the comments, you can reorder commits, squash them
+together, edit commit messages, etc. by editing the list. Once you
+are satisfied, save the list and close your editor, and the rebase
+will begin.
+
+The rebase will stop when `pick` has been replaced with `edit` or when
+a command fails due to merge errors. When you are done editing and/or
+resolving conflicts you can continue with `git rebase --continue`. If
+you decide that things are getting too hairy, you can always bail out
+with `git rebase --abort`. Even after the rebase is complete, you can
+still recover the original branch by using the <<reflogs,reflog>>.
+
+For a more detailed discussion of the procedure and additional tips,
+see the "INTERACTIVE MODE" section of linkgit:git-rebase[1].
[[patch-series-tools]]
Other tools
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v3 4/9] user-manual: Mention 'git remote add' for remote branch config
From: W. Trevor King @ 2013-02-18 0:15 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, Jonathan Nieder, W. Trevor King
In-Reply-To: <cover.1361146398.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
I hardly ever setup remote.<name>.url using 'git config'. While it
may be instructive to do so, we should also point out 'git remote
add'.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 40 +++++++++++++---------------------------
1 file changed, 13 insertions(+), 27 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index ba06b7e..91f1822 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2878,48 +2878,34 @@ branch.master.merge=refs/heads/master
If there are other repositories that you also use frequently, you can
create similar configuration options to save typing; for example,
-after
-------------------------------------------------
-$ git config remote.example.url git://example.com/proj.git
+$ git remote add example git://example.com/proj.git
-------------------------------------------------
-then the following two commands will do the same thing:
+adds the following to `.git/config`:
-------------------------------------------------
-$ git fetch git://example.com/proj.git master:refs/remotes/example/master
-$ git fetch example master:refs/remotes/example/master
+[remote "example"]
+ url = git://example.com/proj.git
+ fetch = +refs/heads/*:refs/remotes/example/*
-------------------------------------------------
-Even better, if you add one more option:
-
--------------------------------------------------
-$ git config remote.example.fetch master:refs/remotes/example/master
--------------------------------------------------
+Also note that the above configuration can be performed by directly
+editing the file `.git/config` instead of using linkgit:git-remote[1].
-then the following commands will all do the same thing:
+After configuring the remote, the following two commands will do the
+same thing:
-------------------------------------------------
-$ git fetch git://example.com/proj.git master:refs/remotes/example/master
-$ git fetch example master:refs/remotes/example/master
+$ git fetch git://example.com/proj.git +refs/heads/*:refs/remotes/example/*
+$ git fetch example +refs/heads/*:refs/remotes/example/*
$ git fetch example
-------------------------------------------------
-You can also add a "+" to force the update each time:
-
--------------------------------------------------
-$ git config remote.example.fetch +master:refs/remotes/example/master
--------------------------------------------------
-
-Don't do this unless you're sure you won't mind "git fetch" possibly
-throwing away commits on 'example/master'.
-
-Also note that all of the above configuration can be performed by
-directly editing the file .git/config instead of using
-linkgit:git-config[1].
-
See linkgit:git-config[1] for more details on the configuration
-options mentioned above.
+options mentioned above and linkgit:git-fetch[1] for more details on
+the refspec syntax.
[[git-concepts]]
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v3 1/9] user-manual: Use 'remote add' to setup push URLs
From: W. Trevor King @ 2013-02-18 0:15 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, Jonathan Nieder, W. Trevor King
In-Reply-To: <cover.1361146398.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
There is no need to use here documents to setup this configuration.
It is easier, less confusing, and more robust to use `git remote add`
directly.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 5077e7c..a060eb6 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1998,16 +1998,21 @@ will not be updated by the push. This may lead to unexpected results if
the branch you push to is the currently checked-out branch!
As with `git fetch`, you may also set up configuration options to
-save typing; so, for example, after
+save typing; so, for example:
+
+-------------------------------------------------
+$ git remote add public-repo ssh://yourserver.com/~you/proj.git
+-------------------------------------------------
+
+adds the following to `.git/config`:
-------------------------------------------------
-$ cat >>.git/config <<EOF
[remote "public-repo"]
- url = ssh://yourserver.com/~you/proj.git
-EOF
+ url = yourserver.com:proj.git
+ fetch = +refs/heads/*:refs/remotes/example/*
-------------------------------------------------
-you should be able to perform the above push with just
+which lets you do the same push with just
-------------------------------------------------
$ git push public-repo master
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v3 0/9] User manual updates
From: W. Trevor King @ 2013-02-18 0:15 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, Jonathan Nieder, W. Trevor King
In-Reply-To: <20130217170606.GA3432@odin.tremily.us>
From: "W. Trevor King" <wking@tremily.us>
Changes since v2 (v2 numbering):
* 01: user-manual: Rewrite git-gc section for automatic packing
- Dropped (graduated to 'maint')
* 02: user-manual: Update for receive.denyCurrentBranch=refuse
- Dropped (graduated to 'master')
* 03: user-manual: Use 'remote add' to setup push URLs
- Removed 'git config' examples
- Show .git/config changes made by 'remote add'
* 04: user-manual: Use git branch --merged
- Dropped (not an improvement)
* 05: user-manual: Add a few references to 'git rebase -i'
- Removed an extra blank line
- Restructured reroll sections:
* cherry-pick suggestions removed
* commit --amend discussion isolated in its own section
* format-patch restructuring moved to its own section
* new interactive rebase section. The contents of this section
borrow liberally from git-rebase.txt.
* 06: user-manual: Give 'git push -f' as an alternative to +master
* 07: user-manual: Mention 'git remote add' for remote branch config
- Simplified section to avoid 'git config'
* 08: user-manual: Standardize backtick quoting
- Fix `{plus}` -> `+` in backticked text
* 09: user-manual: Use 'git config --global user.*' for setup
- Remove reference to "stanza".
* 10: user-manual: Fix 'both: so' -> 'both; so' typo
- Dropped (graduated to 'maint')
* 11: user-manual: Fix 'http' -> 'HTTP' typos
- Dropped (graduated to 'maint')
* 12: user-manual: Use request-pull to generate "please pull" text
- Add an explicit push before request-pull
- Use the `mytree` remote instead of an explicit example URL
* 13: user-manual: Fix 'you - Git' -> 'you--Git' typo
- Dropped (graduated to 'maint')
* 14: user-manual: Flesh out uncommitted changes and submodule updates
* 15: user-manual: Use --format=tar.gz to create a gzipped tarball
- Use `-o latest.tar.gz` instead of `--format=tar.gz`.
W. Trevor King (9):
user-manual: Use 'remote add' to setup push URLs
user-manual: Reorganize the reroll sections, adding 'git rebase -i'
user-manual: Give 'git push -f' as an alternative to +master
user-manual: Mention 'git remote add' for remote branch config
user-manual: Standardize backtick quoting
user-manual: Use 'git config --global user.*' for setup
user-manual: Use request-pull to generate "please pull" text
user-manual: Flesh out uncommitted changes and submodule updates
user-manual: Use -o latest.tar.gz to create a gzipped tarball
Documentation/user-manual.txt | 504 ++++++++++++++++++++++--------------------
1 file changed, 267 insertions(+), 237 deletions(-)
--
1.8.1.336.g94702dd
^ permalink raw reply
* Re: [PATCH v2] read_directory: avoid invoking exclude machinery on tracked files
From: Junio C Hamano @ 2013-02-17 23:18 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Karsten Blees, kusmabite, Ramkumar Ramachandra, Robert Zeh,
finnag
In-Reply-To: <1360999078-27196-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> If path_handled is returned, contents goes up. And if check_only is
> true, the loop could be broken early. These will not happen when
> treat_one_path (and its wrapper treat_path) returns
> path_ignored. dir_add_name internally does a cache_name_exists() check
> so it makes no difference.
>
> To avoid this behavior change, treat_one_path is instructed to skip
> the optimization when check_only or contents is used.
OK, that makes more understandable why this is safe.
> @@ -1242,9 +1246,23 @@ enum path_treatment {
> static enum path_treatment treat_one_path(struct dir_struct *dir,
> struct strbuf *path,
> const struct path_simplify *simplify,
> - int dtype, struct dirent *de)
> + int dtype, struct dirent *de,
> + int exclude_shortcut_ok)
> {
> ...
> @@ -1331,18 +1347,29 @@ static int read_directory_recursive(struct dir_struct *dir,
> goto out;
>
> while ((de = readdir(fdir)) != NULL) {
> - switch (treat_path(dir, de, &path, baselen, simplify)) {
> + switch (treat_path(dir, de, &path, baselen,
> + simplify,
> + !check_only && !contents)) {
> ...
Between these two places we may want to say what kind of short-cut
we are talking about, but there only is one kind of short-cut at
this moment, so let's leave that to other people who want to further
optimize things in this codepath by adding other short-cuts.
Thanks; will queue.
^ permalink raw reply
* Re: [PATCH v4.1 09/12] sequencer.c: teach append_signoff to avoid adding a duplicate newline
From: John Keeping @ 2013-02-17 22:49 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, gitster, pclouds, jrnieder, Brandon Casey
In-Reply-To: <CA+sFfMecyfD7x_8Jk-hUDceL_nS5kuKq5nF0vRBqLROWFgdypA@mail.gmail.com>
On Fri, Feb 15, 2013 at 10:58:38AM -0800, Brandon Casey wrote:
> On Thu, Feb 14, 2013 at 9:58 AM, John Keeping <john@keeping.me.uk> wrote:
> > As Jonathan Nieder wondered before [1], this changes the behaviour when
> > the commit message is empty. Before this commit, there is an empty line
> > followed by the S-O-B line; now the S-O-B is on the first line of the
> > commit.
> >
> > The previous behaviour seems better to me since the empty line is
> > hinting that the user should fill something in. It looks particularly
> > strange if your editor has syntax highlighting for commit messages such
> > that the first line is in a different colour.
>
> Are you talking about the output produced by format-patch? Or are you
> talking about what happens when you do 'commit --amend -s' for a
> commit with an empty commit message. (The email that you referenced
> was about the behavior of format-patch).
I'm talking about plain 'commit -s' which seems to use the same code
path.
> I'm thinking you must be talking about the 'commit --amend -s'
> behavior since you mentioned your editor. Is there another case that
> is affected by this? Normally, any extra blank lines that precede or
> follow a commit message are removed before the commit object is
> created. So, I guess it wouldn't hurt to insert a newline (or maybe
> it should be two?) before the signoff in this case. Would this
> provide an improvement or change for any other commands than 'commit
> --amend -s'?
>
> If we want to do this, then I'd probably do it like this:
>
> - if (len && msgbuf->buf[len - 1] != '\n')
> + if (!len || msgbuf->buf[len - 1] != '\n')
> append_newlines = "\n\n";
> - else if (len > 1 && msgbuf->buf[len - 2] != '\n')
> + else if (len == 1 || msgbuf->buf[len - 2] != '\n')
> append_newlines = "\n";
>
> This would ensure there were two newlines preceding the sob. The
> editor would place its cursor on the top line where the user should
> begin typing in a commit message. If an editor was not opened up
> (e.g. if 'git cherry-pick -s --allow-empty-message ...' was used) then
> the normal mechanism that removes extra blank lines would trigger to
> remove the extra blank lines.
>
> I think that's reasonable.
Two blank lines seems like an improvement to me, FWIW.
John
^ permalink raw reply
* Re: [PATCH v5] submodule: add 'deinit' command
From: Junio C Hamano @ 2013-02-17 22:32 UTC (permalink / raw)
To: Jens Lehmann
Cc: Phil Hord, Git Mailing List, Heiko Voigt, Michael J Gruber,
Marc Branchaud, W. Trevor King
In-Reply-To: <5121384B.10009@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Here we go, changes to v4 are:
>
> - I decided to do the proposed special casing for "."; no messages
> about uninitialized submodules will show up anymore (this is also
> tested)
> - The spelling fixes and better 'uninitialized' message Phil proposed
> - Added the missing quotation for $sm_path in output strings
> - "deinit" is added to the submodule completion list
> - Added two missing "&&" in t7400
Thanks for being thorough. I honestly did not expect this topic to
take this many cycles before becoming 'next-ready'.
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 004c034..0fb6ee0 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -547,6 +548,82 @@ cmd_init()
> }
>
> #
> +# Unregister submodules from .git/config and remove their work tree
> +#
> +# $@ = requested paths (use '.' to deinit all submodules)
> +#
> +cmd_deinit()
> +{
> + # parse $args after "submodule ... init".
> + while test $# -ne 0
> + do
> ..
> + done
> +
> + if test $# = 0
> + then
> + die "$(eval_gettext "Use '.' if you really want to deinitialize all submodules")"
I do not think I saw anybody mentioned this so far, but how is
"deinit" supposed to work inside a subdirectory of a superproject?
If the answer is to work on submodules appear in that subdirectory,
'.' should probably not mean "all in the superproject" I think?
> + module_list "$@" |
> + while read mode sha1 stage sm_path
> + do
> + die_if_unmatched "$mode"
> + name=$(module_name "$sm_path") || exit
> + url=$(git config submodule."$name".url)
> + if test -z "$url"
> + then
> + test $# -ne 1 || test "$@" = "." ||
> + say "$(eval_gettext "Submodule '\$name' is not initialized for path '\$sm_path'")"
> + continue
> + fi
This 'test "$@" = "."' makes readers feel uneasy. This particular
invocation happens to be safe only because it is protected with
"test $# -ne 1 ||", but for all other values of $# this will result
in a syntax error. 'test "$1" = "."' would make the intention of
the check more clear.
But stepping back a bit, is the condition this test is trying to
warn against really worth warning?
It seems that this "warn if user told us to deinitialize a submodule
that hasn't been initialized" is from the very initial round of this
series, and not something other people asked for during the review.
If somebody did
git submodule deinit foo bar
and then later said:
git submodule deinit foo
would it a mistake that the user wants to be warned about?
Perhaps the user did not mean to deinitialize foo (e.g. wanted to
*initialize* foo instead, or wanted to deinitialize *foz* instead)
and that is worth warning about? I am not sure, but I have a
feeling that we can do without this check.
Also the value of submodule.$name.url is not used in the later
codepath to ensure that the named submodule is in the pristine state
in the superproject's working tree (i.e. no submodule.$name section
in the local configuration, no working tree for that submodule), so
it may be even a good change to remove the "does submodule.$name.url
exist" check and always do the "deinitialize" process. That would
give the users a way to recover from a state where a submodule is
only half initialized for some reason safely, no?
^ permalink raw reply
* [PATCH v5] submodule: add 'deinit' command
From: Jens Lehmann @ 2013-02-17 20:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: Phil Hord, Git Mailing List, Heiko Voigt, Michael J Gruber,
Marc Branchaud, W. Trevor King
In-Reply-To: <7vip5w6l8s.fsf@alter.siamese.dyndns.org>
With "git submodule init" the user is able to tell git he cares about one
or more submodules and wants to have it populated on the next call to "git
submodule update". But currently there is no easy way he could tell git he
does not care about a submodule anymore and wants to get rid of his local
work tree (except he knows a lot about submodule internals and removes the
"submodule.$name.url" setting from .git/config together with the work tree
himself).
Help those users by providing a 'deinit' command. This removes the whole
submodule.<name> section from .git/config either for the given
submodule(s) or for all those which have been initialized if '.' is
given. Fail if the current work tree contains modifications unless
forced. Complain when for a submodule given on the command line the url
setting can't be found in .git/config, but nonetheless don't fail.
Add tests and link the man pages of "git submodule deinit" and "git rm"
to assist the user in deciding whether removing or unregistering the
submodule is the right thing to do for him. Also add the deinit subcommand
to the completion list.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Am 13.02.2013 20:56, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>> Junio, this looks like a we have v5 as soon as we decide what to do
>> with the "not initialized" messages when '.' is used, right?
>
> OK. I myself do not deeply care if we end up special casing "." or
> not; I'll leave it up to you and other submodule folks.
Here we go, changes to v4 are:
- I decided to do the proposed special casing for "."; no messages
about uninitialized submodules will show up anymore (this is also
tested)
- The spelling fixes and better 'uninitialized' message Phil proposed
- Added the missing quotation for $sm_path in output strings
- "deinit" is added to the submodule completion list
- Added two missing "&&" in t7400
Documentation/git-rm.txt | 4 ++
Documentation/git-submodule.txt | 18 +++++-
contrib/completion/git-completion.bash | 2 +-
git-submodule.sh | 79 +++++++++++++++++++++++++-
t/t7400-submodule-basic.sh | 101 +++++++++++++++++++++++++++++++++
5 files changed, 201 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index 92bac27..1d876c2 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -149,6 +149,10 @@ files that aren't ignored are present in the submodules work tree.
Ignored files are deemed expendable and won't stop a submodule's work
tree from being removed.
+If you only want to remove the local checkout of a submodule from your
+work tree without committing the removal,
+use linkgit:git-submodule[1] `deinit` instead.
+
EXAMPLES
--------
`git rm Documentation/\*.txt`::
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index a0c9df8..bc06159 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -13,6 +13,7 @@ SYNOPSIS
[--reference <repository>] [--] <repository> [<path>]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
+'git submodule' [--quiet] deinit [-f|--force] [--] <path>...
'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch] [--rebase]
[--reference <repository>] [--merge] [--recursive] [--] [<path>...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
@@ -134,6 +135,19 @@ init::
the explicit 'init' step if you do not intend to customize
any submodule locations.
+deinit::
+ Unregister the given submodules, i.e. remove the whole
+ `submodule.$name` section from .git/config together with their work
+ tree. Further calls to `git submodule update`, `git submodule foreach`
+ and `git submodule sync` will skip any unregistered submodules until
+ they are initialized again, so use this command if you don't want to
+ have a local checkout of the submodule in your work tree anymore. If
+ you really want to remove a submodule from the repository and commit
+ that use linkgit:git-rm[1] instead.
++
+If `--force` is specified, the submodule's work tree will be removed even if
+it contains local modifications.
+
update::
Update the registered submodules, i.e. clone missing submodules and
checkout the commit specified in the index of the containing repository.
@@ -213,8 +227,10 @@ OPTIONS
-f::
--force::
- This option is only valid for add and update commands.
+ This option is only valid for add, deinit and update commands.
When running add, allow adding an otherwise ignored submodule path.
+ When running deinit the submodule work trees will be removed even if
+ they contain local changes.
When running update, throw away local changes in submodules when
switching to a different commit; and always run a checkout operation
in the submodule, even if the commit listed in the index of the
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 059ba9d..7cee9bd 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2401,7 +2401,7 @@ _git_submodule ()
{
__git_has_doubledash && return
- local subcommands="add status init update summary foreach sync"
+ local subcommands="add status init deinit update summary foreach sync"
if [ -z "$(__git_find_on_cmdline "$subcommands")" ]; then
case "$cur" in
--*)
diff --git a/git-submodule.sh b/git-submodule.sh
index 004c034..0fb6ee0 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -8,6 +8,7 @@ dashless=$(basename "$0" | sed -e 's/-/ /')
USAGE="[--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--] <repository> [<path>]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
or: $dashless [--quiet] init [--] [<path>...]
+ or: $dashless [--quiet] deinit [-f|--force] [--] <path>...
or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
or: $dashless [--quiet] foreach [--recursive] <command>
@@ -547,6 +548,82 @@ cmd_init()
}
#
+# Unregister submodules from .git/config and remove their work tree
+#
+# $@ = requested paths (use '.' to deinit all submodules)
+#
+cmd_deinit()
+{
+ # parse $args after "submodule ... init".
+ while test $# -ne 0
+ do
+ case "$1" in
+ -f|--force)
+ force=$1
+ ;;
+ -q|--quiet)
+ GIT_QUIET=1
+ ;;
+ --)
+ shift
+ break
+ ;;
+ -*)
+ usage
+ ;;
+ *)
+ break
+ ;;
+ esac
+ shift
+ done
+
+ if test $# = 0
+ then
+ die "$(eval_gettext "Use '.' if you really want to deinitialize all submodules")"
+ fi
+
+ module_list "$@" |
+ while read mode sha1 stage sm_path
+ do
+ die_if_unmatched "$mode"
+ name=$(module_name "$sm_path") || exit
+ url=$(git config submodule."$name".url)
+ if test -z "$url"
+ then
+ test $# -ne 1 || test "$@" = "." ||
+ say "$(eval_gettext "Submodule '\$name' is not initialized for path '\$sm_path'")"
+ continue
+ fi
+
+ # Remove the submodule work tree (unless the user already did it)
+ if test -d "$sm_path"
+ then
+ # Protect submodules containing a .git directory
+ if test -d "$sm_path/.git"
+ then
+ echo >&2 "$(eval_gettext "Submodule work tree '\$sm_path' contains a .git directory")"
+ die "$(eval_gettext "(use 'rm -rf' if you really want to remove it including all of its history)")"
+ fi
+
+ if test -z "$force"
+ then
+ git rm -n "$sm_path" ||
+ die "$(eval_gettext "Submodule work tree '\$sm_path' contains local modifications; use '-f' to discard them")"
+ fi
+ rm -rf "$sm_path" || say "$(eval_gettext "Could not remove submodule work tree '\$sm_path'")"
+ fi
+
+ mkdir "$sm_path" || say "$(eval_gettext "Could not create empty submodule directory '\$sm_path'")"
+
+ # Remove the whole section so we have a clean state when the
+ # user later decides to init this submodule again
+ git config --remove-section submodule."$name" &&
+ say "$(eval_gettext "Submodule '\$name' (\$url) unregistered for path '\$sm_path'")"
+ done
+}
+
+#
# Update each submodule path to correct revision, using clone and checkout as needed
#
# $@ = requested paths (default to all)
@@ -1157,7 +1234,7 @@ cmd_sync()
while test $# != 0 && test -z "$command"
do
case "$1" in
- add | foreach | init | update | status | summary | sync)
+ add | foreach | init | deinit | update | status | summary | sync)
command=$1
;;
-q|--quiet)
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 2683cba..e32b62b 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -757,4 +757,105 @@ test_expect_success 'submodule add with an existing name fails unless forced' '
)
'
+test_expect_success 'set up a second submodule' '
+ git submodule add ./init2 example2 &&
+ git commit -m "submodule example2 added"
+'
+
+test_expect_success 'submodule deinit should remove the whole submodule section from .git/config' '
+ git config submodule.example.foo bar &&
+ git config submodule.example2.frotz nitfol &&
+ git submodule deinit init &&
+ test -z "$(git config submodule.example.url)" &&
+ test -z "$(git config submodule.example.foo)" &&
+ test -n "$(git config submodule.example2.url)" &&
+ test -n "$(git config submodule.example2.frotz)" &&
+ test -f example2/.git &&
+ rmdir init
+'
+
+test_expect_success 'submodule deinit . deinits all initialized submodules' '
+ git submodule update --init &&
+ git config submodule.example.foo bar &&
+ git config submodule.example2.frotz nitfol &&
+ test_must_fail git submodule deinit &&
+ git submodule deinit . &&
+ test -z "$(git config submodule.example.url)" &&
+ test -z "$(git config submodule.example.foo)" &&
+ test -z "$(git config submodule.example2.url)" &&
+ test -z "$(git config submodule.example2.frotz)" &&
+ rmdir init example2
+'
+
+test_expect_success 'submodule deinit deinits a submodule when its work tree is missing or empty' '
+ git submodule update --init &&
+ rm -rf init example2/* example2/.git &&
+ git submodule deinit init example2 &&
+ test -z "$(git config submodule.example.url)" &&
+ test -z "$(git config submodule.example2.url)" &&
+ rmdir init
+'
+
+test_expect_success 'submodule deinit fails when the submodule contains modifications unless forced' '
+ git submodule update --init &&
+ echo X >>init/s &&
+ test_must_fail git submodule deinit init &&
+ test -n "$(git config submodule.example.url)" &&
+ test -f example2/.git &&
+ git submodule deinit -f init &&
+ test -z "$(git config submodule.example.url)" &&
+ rmdir init
+'
+
+test_expect_success 'submodule deinit fails when the submodule contains untracked files unless forced' '
+ git submodule update --init &&
+ echo X >>init/untracked &&
+ test_must_fail git submodule deinit init &&
+ test -n "$(git config submodule.example.url)" &&
+ test -f example2/.git &&
+ git submodule deinit -f init &&
+ test -z "$(git config submodule.example.url)" &&
+ rmdir init
+'
+
+test_expect_success 'submodule deinit fails when the submodule HEAD does not match unless forced' '
+ git submodule update --init &&
+ (
+ cd init &&
+ git checkout HEAD^
+ ) &&
+ test_must_fail git submodule deinit init &&
+ test -n "$(git config submodule.example.url)" &&
+ test -f example2/.git &&
+ git submodule deinit -f init &&
+ test -z "$(git config submodule.example.url)" &&
+ rmdir init
+'
+
+test_expect_success 'submodule deinit complains but does not fail when used on an uninitialized submodule' '
+ git submodule update --init &&
+ git submodule deinit init >actual &&
+ test_i18ngrep "Submodule .example. (.*) unregistered for path .init" actual &&
+ git submodule deinit init >actual &&
+ test_i18ngrep "Submodule .example. is not initialized for path .init" actual &&
+ git submodule deinit . >actual &&
+ test_i18ngrep "Submodule .example2. (.*) unregistered for path .example2" actual &&
+ test_i18ngrep ! "Submodule .example. is not initialized for path .init" actual &&
+ rmdir init example2
+'
+
+test_expect_success 'submodule deinit fails when submodule has a .git directory even when forced' '
+ git submodule update --init &&
+ (
+ cd init &&
+ rm .git &&
+ cp -R ../.git/modules/example .git &&
+ GIT_WORK_TREE=. git config --unset core.worktree
+ ) &&
+ test_must_fail git submodule deinit init &&
+ test_must_fail git submodule deinit -f init &&
+ test -d init/.git &&
+ test -n "$(git config submodule.example.url)"
+'
+
test_done
--
1.8.1.2.677.ga1bd48d
^ 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