kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Michal Sojka	5c31acfbe2	submodule: improve documentation of update subcommand The documentation of 'git submodule update' has several problems: 1) It mentions that value 'none' of submodule.$name.update can be overridden by --checkout, but other combinations of configuration values and command line options are not mentioned. 2) The documentation of submodule.$name.update is scattered across three places, which is confusing. 3) The documentation of submodule.$name.update in gitmodules.txt is incorrect, because the code always uses the value from .git/config and never from .gitmodules. 4) Documentation of --force was incomplete, because it is only effective in case of checkout method of update. Fix all these problems by documenting submodule.*.update in git-submodule.txt and make everybody else refer to it. Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago
Jens Lehmann	1d2f393ac9	status/commit: show staged submodules regardless of ignore config Currently setting submodule.<name>.ignore and/or diff.ignoreSubmodules to "all" suppresses all output of submodule changes for the diff family, status and commit. For status and commit this is really confusing, as it even when the user chooses to record a new commit for an ignored submodule by adding it manually this change won't show up under the to-be-committed changes. To add insult to injury, a later "git commit" will error out with "nothing to commit" when only ignored submodules are staged. Fix that by making wt_status always print staged submodule changes, no matter what ignore settings are configured. The only exception is when the user explicitly uses the "--ignore-submodules=all" command line option, in that case the submodule output is still suppressed. This also makes "git commit" work again when only modifications of ignored submodules are staged, as that command uses the "commitable" member of the wt_status struct to determine if staged changes are present. But this only happens when the commit command uses the wt_status* functions to produce status output for human consumption (when forking an editor or with --dry-run), in all other cases (e.g. when run in a script with '-m') another code path is taken which uses index_differs_from() to determine if any changes are staged which still ignores submodules according to their configuration. This will be fixed in a follow-up commit. Change t7508 to reflect this new behavior and add three new tests to show that a single staged submodule configured to be ignored will be committed when the status output is generated and won't be if not. Also update the documentation of the ignore config options accordingly. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	11 years ago
Junio C Hamano	d851ffb91f	Revert "submodule: explicit local branch creation in module_clone" This reverts commit `23d25e48f5`, as it is broken for users who haven't opted into the new feature of checking out submodule.*.branch with update mode set to checkout.	11 years ago
W. Trevor King	23d25e48f5	submodule: explicit local branch creation in module_clone The previous code only checked out branches in cmd_add. This commit moves the branch-checkout logic into module_clone, where it can be shared by cmd_add and cmd_update. I also update the initial checkout command to use 'reset' to preserve branches setup during module_clone. With this change, folks cloning submodules for the first time via: $ git submodule update ... will get a local branch instead of a detached HEAD, unless they are using the default checkout-mode updates. This is a change from the previous situation where cmd_update always used checkout-mode logic (regardless of the requested update mode) for updates that triggered an initial clone, which always resulted in a detached HEAD. This commit does not change the logic for updates after the initial clone, which will continue to create detached HEADs for checkout-mode updates, and integrate remote work with the local HEAD (detached or not) in other modes. The motivation for the change is that developers doing local work inside the submodule are likely to select a non-checkout-mode for updates so their local work is integrated with upstream work. Developers who are not doing local submodule work stick with checkout-mode updates so any apparently local work is blown away during updates. For example, if upstream rolls back the remote branch or gitlinked commit to an earlier version, the checkout-mode developer wants their old submodule checkout to be rolled back as well, instead of getting a no-op merge/rebase with the rolled-back reference. By using the update mode to distinguish submodule developers from black-box submodule consumers, we can setup local branches for the developers who will want local branches, and stick with detached HEADs for the developers that don't care. Testing ======= In t7406, just-cloned checkouts now update to the gitlinked hash with 'reset', to preserve the local branch for situations where we're not on a detached HEAD. I also added explicit tests to t7406 for HEAD attachement after cloning updates, showing that it depends on their update mode: * Checkout-mode updates get detached HEADs * Everyone else gets a local branch, matching the configured submodule.<name>.branch and defaulting to master. The 'initial-setup' tag makes it easy to reset the superproject to a known state, as several earlier tests commit to submodules and commit the changed gitlinks to the superproject, but don't push the new submodule commits to the upstream subprojects. This makes it impossible to checkout the current super master, because it references submodule commits that don't exist in the upstream subprojects. For a specific example, see the tests that currently generate the 'two_new_submodule_commits' commits. Documentation ============= I updated the docs to describe the 'submodule update' modes in detail. The old documentation did not distinguish between cloning and non-cloning updates and lacked clarity on which operations would lead to detached HEADs, and which would not. The new documentation addresses these issues while updating the docs to reflect the changes introduced by this commit's explicit local branch creation in module_clone. I also add '--checkout' to the usage summary and group the update-mode options into a single set. Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>	11 years ago
W. Trevor King	43fda9455c	Documentation/gitmodules: Only 'update' and 'url' are required Descriptions for all the settings fell under the initial "Each submodule section also contains the following required keys:". The example shows sections with just 'path' and 'url' entries, which are indeed required, but we should still make the required/optional distinction explicit to clarify that the rest of them are optional. Signed-off-by: W. Trevor King <wking@tremily.us> Reviewed-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	11 years ago
Jens Lehmann	bb58b696c6	Improve documentation concerning the status.submodulesummary setting 'git status' and 'git commit' can be told to also show the output of "git submodule summary" by setting the "status.submodulesummary" config option. But status and commit also honor the "diff.ignoreSubmodules" and the "submodule.<name>.ignore" settings, which then disable the summary partly or completely. This - and the fact that the last two settings do not affect the "git submodule" commands at all - is not well documented. Extend the documentation in those places where "status.submodulesummary", "diff.ignoreSubmodules" and "submodule.<name>.ignore" are described to better explain these dependencies. Thanks-to: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Thomas Ackermann	2de9b71138	Documentation: the name of the system is 'Git', not 'git' Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
W. Trevor King	06b1abb5bd	submodule update: add --remote for submodule's upstream changes The current `update` command incorporates the superproject's gitlinked SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the options you use, it may checkout $sha1, rebase the $subsha1 onto $sha1, or merge $sha1 into $subsha1. This helps you keep up with changes in the upstream superproject. However, it's also useful to stay up to date with changes in the upstream subproject. Previous workflows for incorporating such changes include the ungainly: $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull' With this patch, all of the useful functionality for incorporating superproject changes can be reused to incorporate upstream subproject updates. When you specify --remote, the target $sha1 is replaced with a $sha1 of the submodule's origin/master tracking branch. If you want to merge a different tracking branch, you can configure the `submodule.<name>.branch` option in `.gitmodules`. You can override the `.gitmodules` configuration setting for a particular superproject by configuring the option in that superproject's default configuration (using the usual configuration hierarchy, e.g. `.git/config`, `~/.gitconfig`, etc.). Previous use of submodule.<name>.branch ======================================= Because we're adding a new configuration option, it's a good idea to check if anyone else is already using the option. The foreach-pull example above was described by Ævar in commit `f030c96d86` Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Date: Fri May 21 16:10:10 2010 +0000 git-submodule foreach: Add $toplevel variable Gerrit uses the same interpretation for the setting, but because Gerrit has direct access to the subproject repositories, it updates the superproject repositories automatically when a subproject changes. Gerrit also accepts the special value '.', which it expands into the superproject's branch name. Although the --remote functionality is using `submodule.<name>.branch` slightly differently, the effect is the same. The foreach-pull example uses the option to record the name of the local branch to checkout before pulls. The tracking branch to be pulled is recorded in `.git/modules/<name>/config`, which was initialized by the module clone during `submodule add` or `submodule init`. Because the branch name stored in `submodule.<name>.branch` was likely the same as the branch name used during the initial `submodule add`, the same branch will be pulled in each workflow. Implementation details ====================== In order to ensure a current tracking branch state, `update --remote` fetches the submodule's remote repository before calculating the SHA-1. However, I didn't change the logic guarding the existing fetch: if test -z "$nofetch" then # Run fetch only if $sha1 isn't present or it # is not reachable from a ref. (clear_local_git_env; cd "$path" && ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) && test -z "$rev") \|\| git-fetch)) \|\| die "$(eval_gettext "Unable to fetch in submodule path '\$path'")" fi There will not be a double-fetch, because the new $sha1 determined after the `--remote` triggered fetch should always exist in the repository. If it doesn't, it's because some racy process removed it from the submodule's repository and we should be re-fetching. Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Jens Lehmann	73b0898d0d	Teach "git submodule add" the --name option "git submodule add" initializes the name of a submodule to its path. This was ok as long as the .git directory lived inside the submodule's work tree, but since 1.7.8 it is stored in the .git/modules/<name> directory of the superproject, making the submodule name survive the removal of the submodule's work tree. This leads to problems when the user tries to add a different submodule at the same path - and thus the same name - later, as that will happily try to restore the submodule from the old repository instead of the one the user specified and will lead to a checkout of the wrong repository. Add the new "--name" option to let the user provide a name for the submodule. This enables the user to solve this conflict without having to remove .git/modules/<name> by hand (which is no viable solution as it makes it impossible to checkout a commit that records the old submodule and populate it, as that will still check out the new submodule for the same reason). To achieve that the submodule's name is added to the parameter list of the module_clone() helper function. This makes it possible to remove the call of module_name() there because both callers of module_clone() already know the name and can provide it as argument number two. Reported-by: Jonathan Johnson <me@jondavidjohn.com> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Heiko Voigt	e6a1c43aaf	document submdule.$name.update=none option for gitmodules This option was not yet described in the gitmodules documentation. We only described it in the 'git submodule' command documentation but gitmodules is the more natural place to look. A short reference in the 'git submodule' documentation should be sufficient since the details can now be found in the documentation to gitmodules. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jim Meyering	a7793a7491	correct spelling: an URL -> a URL Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jeff King	48bb914ed6	doc: drop author/documentation sections from most pages The point of these sections is generally to: 1. Give credit where it is due. 2. Give the reader an idea of where to ask questions or file bug reports. But they don't do a good job of either case. For (1), they are out of date and incomplete. A much more accurate answer can be gotten through shortlog or blame. For (2), the correct contact point is generally git@vger, and even if you wanted to cc the contact point, the out-of-date and incomplete fields mean you're likely sending to somebody useless. So let's drop the fields entirely from all manpages except git(1) itself. We already point people to the mailing list for bug reports there, and we can update the Authors section to give credit to the major contributors and point to shortlog and blame for more information. Each page has a "This is part of git" footer, so people can follow that to the main git manpage.	14 years ago
Jens Lehmann	bf42b38405	Submodules: Add 'on-demand' value for the 'fetchRecurseSubmodule' option Now the behavior of fetch and pull can be configured to the recently added 'on-demand' mode separately for each submodule too. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Ralf Wildenhues	469bfc962d	Fix typos in the documentation Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Jens Lehmann	c1a3c3640d	Submodules: Add the "fetchRecurseSubmodules" config option The new boolean "fetchRecurseSubmodules" config option controls the behavior for "git fetch" and "git pull". It specifies if these commands should recurse into submodules and fetch new commits there too and can be set separately for each submodule. In the .gitmodules file "submodule.<name>.fetchRecurseSubmodules" entries are read before looking for them in .git/config. Thus settings found in .git/config will override those from .gitmodules, thereby allowing the user to ignore settings given by the remote side while also letting upstream set reasonable defaults for those users who don't have special needs. This configuration can be overridden by the command line option "--[no-]recurse-submodules" of "git fetch" and "git pull". Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Ralf Wildenhues	3776ea9d70	Typos in code comments, an error message, documentation Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Jens Lehmann	302ad7a993	Submodules: Use "ignore" settings from .gitmodules too for diff and status The .gitmodules file is parsed for "submodule.<name>.ignore" entries before looking for them in .git/config. Thus settings found in .git/config will override those from .gitmodules, thereby allowing the local developer to ignore settings given by the remote side while also letting upstream set defaults for those users who don't have special needs. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Jonathan Nieder	47dc5d5fda	gitmodules.5: url can be a relative path There is already excellent documentation for this facility in git-submodule.1, but it is not so discoverable. Relative paths in .gitmodules can be useful for serving the same repository over multiple protocols, for example. Thanks to Peter for pointing this out. Cc: Peter Krefting <peter@softwolves.pp.se> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Johan Herland	42b4917862	git-submodule: add support for --merge. 'git submodule update --merge' merges the commit referenced by the superproject into your local branch, instead of checking it out on a detached HEAD. As evidenced by the addition of "git submodule update --rebase", it is useful to provide alternatives to the default 'checkout' behaviour of "git submodule update". One such alternative is, when updating a submodule to a new commit, to merge that commit into the current local branch in that submodule. This is useful in workflows where you want to update your submodule from its upstream, but you cannot use --rebase, because you have downstream people working on top of your submodule branch, and you don't want to disrupt their work. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Johan Herland	329484256e	Rename submodule.<name>.rebase to submodule.<name>.update The addition of "submodule.<name>.rebase" demonstrates the usefulness of alternatives to the default behaviour of "git submodule update". However, by naming the config variable "submodule.<name>.rebase", and making it a boolean choice, we are artificially constraining future git versions that may want to add _more_ alternatives than just "rebase". Therefore, while "submodule.<name>.rebase" is not yet in a stable git release, future-proof it, by changing it from submodule.<name>.rebase = true/false to submodule.<name>.update = rebase/checkout where "checkout" specifies the default behaviour of "git submodule update" (checking out the new commit to a detached HEAD), and "rebase" specifies the --rebase behaviour (where the current local branch in the submodule is rebase onto the new commit). Thus .update == checkout is equivalent to .rebase == false, and .update == rebase is equivalent to .rebase == true. Finally, leaving .update unset is equivalent to leaving .rebase unset. In future git versions, other alternatives to "git submodule update" behaviour can be included by adding them to the list of allowable values for the submodule.<name>.update variable. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Peter Hutterer	ca2cedba70	git-submodule: add support for --rebase. 'git submodule update --rebase' rebases your local branch on top of what would have been checked out to a detached HEAD otherwise. In some cases, detaching the HEAD when updating a submodule complicates the workflow to commit to this submodule (checkout master, rebase, then commit). For submodules that require frequent updates but infrequent (if any) commits, a rebase can be executed directly by the git-submodule command, ensuring that the submodules stay on their respective branches. git-config key: submodule.$name.rebase (bool) Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Gustaf Hendeby	e5b5c1d2cf	Document clarification: gitmodules, gitattributes The SYNOPSIS section of gitattibutes and gitmodule fail to clearly specify the name of the in tree files used. This patch brings in the initial `.' and the fact that the `.gitmodules' file should reside at the top-level of the working tree. Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Christian Couder	9e1f0a85c6	documentation: move git(7) to git(1) As the "git" man page describes the "git" command at the end-user level, it seems better to move it to man section 1. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Dan McGee	5162e69732	Documentation: rename gitlink macro to linkgit Between AsciiDoc 8.2.2 and 8.2.3, the following change was made to the stock Asciidoc configuration: @@ -149,7 +153,10 @@ # Inline macros. # Backslash prefix required for escape processing. # (?s) re flag for line spanning. -(?su)[\\]?(?P<name>\w(\w\|-)?):(?P<target>\S?)(\[(?P<attrlist>.?)\])= + +# Explicit so they can be nested. +(?su)[\\]?(?P<name>(http\|https\|ftp\|file\|mailto\|callto\|image\|link)):(?P<target>\S?)(\[(?P<attrlist>.?)\])= + # Anchor: [[[id]]]. Bibliographic anchor. (?su)[\\]?\[\[\[(?P<attrlist>[\w][\w-]?)\]\]\]=anchor3 # Anchor: [[id,xreflabel]] This default regex now matches explicit values, and unfortunately in this case gitlink was being matched by just 'link', causing the wrong inline macro template to be applied. By renaming the macro, we can avoid being matched by the wrong regex. Signed-off-by: Dan McGee <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Lars Hjemli	a88ca34277	gitmodules(5): remove leading period from synopsis Asciidoc treats a line starting with a period followed by a title as a blocktitle element. My introduction of gitmodules(5) unfortunatly broke the documentation build process due to this processing, since it made asciidoc generate an illegal (empty) synopsis element. Removing the leading period fixes the problem and also makes gitmodules(5) use the same synopsis notation as gitattributes(5). Noticed-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Lars Hjemli	891dbc6e40	Add gitmodules(5) This adds documentation for the .gitmodules file. Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago

25 Commits (728af2832c3e58222965521682414adb9a80932b)