Re: [PATCH 2/2] Introduce git submodule attached update
Francesco Pretto cez...@gmail.com writes: - In which situations does the developer or maintainer switch between your attached/detached mode? The developer/maintainer does so optionally and voluntarily and it effects only its private working tree. This does not answer my question. I would like to find out the reason why one would do the switch. The developer does it voluntarily, at his responsibility, because he may decide to partecipate more actively to the development of the submodule and still want to use a simple git submodule update to updates his submodules, overriding its configuration as it can be done for other properties like, for example, branch. It is still unclear to me why we need attached/detached mode for that. The developer may want to do an exploratory development, whose result is unknown to deserve to be committed on the specified branch at the beginning, and choose to build on a detached HEAD, which is a perfectly normal thing to do. But the standard way to do so, whether the developer is working in the top-level superproject or in a submodule, would be to just do: cd $there git checkout HEAD^0 or use whatever commit the state to be detached is at instead of HEAD in the above example, no? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Introduce git submodule attached update
Francesco Pretto cez...@gmail.com writes: My bottom line: - For what I understand, detached HEAD it's a way to say hey, you have to stay on this commit. Also don't even think you can push to the upstream branch. This sometimes can't be spurious, as in the use case I wrote above: access control on the remote repositories should be enough. I think maintainers should have the option to make developers to clone a repository starting with an attached HEAD on the branch suggested in submodule.$name.branch; - git submodule update is missing a property to do automatically --remote. I think in the use case I wrote it's really handy to have a git submodule update to act like this. The short version I read in the message is that your workflow, in which partipants want to work on a branch, gets frustrating with the current system only because the default update/initial cloning detaches HEAD and will stay in that state until the user gets out of the detached state manually. Once that initial detachment is fixed, there is no more major issue, as update will stay on that branch. Am I reading you correctly? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Introduce git submodule attached update
2014/1/7 Junio C Hamano gits...@pobox.com: Francesco Pretto cez...@gmail.com writes: My bottom line: - For what I understand, detached HEAD it's a way to say hey, you have to stay on this commit. Also don't even think you can push to the upstream branch. This sometimes can't be spurious, as in the use case I wrote above: access control on the remote repositories should be enough. I think maintainers should have the option to make developers to clone a repository starting with an attached HEAD on the branch suggested in submodule.$name.branch; - git submodule update is missing a property to do automatically --remote. I think in the use case I wrote it's really handy to have a git submodule update to act like this. The short version I read in the message is that your workflow, in which partipants want to work on a branch, gets frustrating with the current system only because the default update/initial cloning detaches HEAD and will stay in that state until the user gets out of the detached state manually. Once that initial detachment is fixed, there is no more major issue, as update will stay on that branch. Am I reading you correctly? Yep, you got it correctly. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Introduce git submodule attached update
On Mon, Jan 06, 2014 at 08:21:24PM +0100, David Engster wrote: +---+ | master | -- +---++---+| Merges to/from master | CEDET | | done only by CEDET developers +---+ | +---+| | stable | -- +---+ | | | | Any Emacs developer | can push and commit | submodule +++--+ | | Emacs | -- | lisp/cedet submodule | - +++--+ This looks reasonable, and except for the detached-HEAD after the initial update-clone, I think Git already supports everything you need. If you set submodule.cedet.update to 'rebase' (or 'merge') you can easily integrate your local master changes with cedet/master (e.g. if a CEDET dev updates cedet/master before the Emacs dev has a chance to push their fix). With the non-checkout update mode, you'll also stay on your checked-out master branch during 'submodule update' calls. AFAICS the main problem with this approach is that one always has to think of committing the new SHA1 of the submodule. … However, as Heiko notes, the history must be preserved to be able to go back to earlier revisions, so there must be some kind of commit for the submodule when 'stable' changes; maybe that could be automated somehow? If an Emacs dev in the submodule makes the CEDET change, you could use a post-commit hook (in the CEDET submodule) to also commit the change to the Emacs superproject). However, commiting only the submodule bump may not be what you want. Maybe there are other superproject changes that should be committed alongside the submodule bump. Maybe there is stuff in the superprojects's staging area that should *not* be committed alongside the submodule bump. This ambiguity makes it tricky for Git to automatically do “the right thing”. If cedet/master is updated independently by the CEDET devs, there's no way for the local Emacs repo to know about the change, so it's impossible to automatically update Emacs (without polling for CEDET updates or some other transgression ;). Cheers, Trevor -- 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 signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2] Introduce git submodule attached update
2014/1/7 Junio C Hamano gits...@pobox.com: Francesco Pretto cez...@gmail.com writes: The developer does it voluntarily, at his responsibility, because he may decide to partecipate more actively to the development of the submodule and still want to use a simple git submodule update to updates his submodules, overriding its configuration as it can be done for other properties like, for example, branch. It is still unclear to me why we need attached/detached mode for that. The developer may want to do an exploratory development, whose result is unknown to deserve to be committed on the specified branch at the beginning, and choose to build on a detached HEAD, which is a perfectly normal thing to do. But the standard way to do so, whether the developer is working in the top-level superproject or in a submodule, would be to just do: cd $there git checkout HEAD^0 or use whatever commit the state to be detached is at instead of HEAD in the above example, no? Because of the overlapping change with the the other patch proposed by Trevor, and to not generate confusion, I will stop for now pursuing for an attach|detach command/switch specific for submodules, waiting for Trevors's patch possible acceptance. After that I will see it still makes sense or not. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [PATCH 2/2] Introduce git submodule attached update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Jan 06, 2014 at 08:10:04PM -0800, W. Trevor King wrote: Here's an attempted summary of our desires, and my ideal route forward: * Preferred local submodule branches for each superproject branch. * Not currently supported by Git. * Requires some sort of per-superproject-branch .git/config. * Fall back to the remote-tracking submodule.name.branch? * Auto checkout of the preferred branch * Can do this at clone-update time with my patch. * For later submodule branch switches, maybe we want: git submodule checkout [-b branch] [paths…] Then if a user blows off their detached HEAD, at least they'll feel a bit sheepish afterwards. Well, for development on a detached HEAD in a submodule we are currently not very careful anyway. A simple git submodule update will already blow away any detached HEAD work. But AFAIK it should trigger the you are leaving commits from a detached HEAD behind warning, so there is some safeguard and recovery. Cheers Heiko -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iEYEARECAAYFAlLMhPAACgkQjLR3Aoip+rqP6wCeIhtpWLJC3XVO3nu2ViQTbHPg T5wAoLLEZ256GOOjBxoTKo2/FmfvQGLp =+bqm -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Introduce git submodule attached update
On Tue, Jan 07, 2014 at 11:51:28PM +0100, Heiko Voigt wrote: On Mon, Jan 06, 2014 at 08:10:04PM -0800, W. Trevor King wrote: Here's an attempted summary of our desires, and my ideal route forward: * Preferred local submodule branches for each superproject branch. * Not currently supported by Git. * Requires some sort of per-superproject-branch .git/config. * Fall back to the remote-tracking submodule.name.branch? * Auto checkout of the preferred branch * Can do this at clone-update time with my patch. * For later submodule branch switches, maybe we want: git submodule checkout [-b branch] [paths…] Then if a user blows off their detached HEAD, at least they'll feel a bit sheepish afterwards. Well, for development on a detached HEAD in a submodule we are currently not very careful anyway. A simple git submodule update will already blow away any detached HEAD work. Only if you use the checkout strategy. With --merge or --rebase, you'll have the $sha1 (or upstream remote with --remote) integrated with your detached HEAD work. You end up with a new detached HEAD containing the result of the integration (just confirmed with tests using Git v1.8.3.2). That seems reasonable to me, so I'm happy with the integration logic. But AFAIK it should trigger the you are leaving commits from a detached HEAD behind warning, so there is some safeguard and recovery. I did not see those in testing with Git v1.8.3.2, likely because of the '-f -q' we pass to 'git checkout' for checkout-mode updates. Regardless of branch integration issues, I think a per-superproject-branch preferred submodule branch is important for 'git checkout' to work in the superproject. If you want: * submodule branch master for superproject branch master, and * submodule branch my-feature for superproject branch my-feature, $ git checkout my-feature in the superproject is currently going to leave you with the submodule on master, which is not convenient ;). I think we should come up with a better solution to the superproject checkout problem before adding in additional complications due to branch integration ;). Cheers, Trevor -- 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 signature.asc Description: OpenPGP digital signature
Re: Re: [PATCH 2/2] Introduce git submodule attached update
On Sun, Jan 05, 2014 at 10:46:11PM +0100, Francesco Pretto wrote: 2014/1/5 Heiko Voigt hvo...@hvoigt.net: The following questions directly pop into my mind: - What means the maintainer does not track the submodules sha1? Does that mean the superproject always refers to submodule commits using branches? It means he doesn't need to control other developers commit to be checked out so he sets submodule.name.ignore to all. In this way he and the developers can work actively in their submodule copy. So practically speaking: You mean that the value of submodule.name.ignore is set to all in the master branch of the superproject? From your other email referring to svn:externals I figure that. - What happens if you want to go back to an earlier revision? Lets say a tagged release? How is ensured that you get the correct revision in the submodules? submodule.name.branch is one setting that is not copied in .git/config by git submodule init. git submodule update will use the setting in .gitmodules if not overridden voluntarily by the developer in .git/config. The maintainer can change that setting in .gitmodules and commit the change. Modifies will be propagated by the next git pull git submodule update of the developer in the superproject. I do not understand how does that ensure you get the correct submodule revision when checking out a tagged release? To get a precise revision the superproject needs to track a sha1 of a submodule commit. I do not see how that has anything to do with submodule.name.branch? - In which situations does the developer or maintainer switch between your attached/detached mode? The developer/maintainer does so optionally and voluntarily and it effects only its private working tree. This does not answer my question. I would like to find out the reason why one would do the switch. - What is the repository branch which is given to the developer by the maintainer used for? Who creates this branch and who merges into it? The branch of course must exist prior submodule adding. In this use-case it does not really matter who creates it and who merges into it. Everyone with the right to merge into it has to work in the submodule seamlessly, as it was working on separate clone of the same repository used as the submodule. o Here is the same. I am searching for a description like: If the developer works on a feature that needs a submodule change he: - creates a submodule branch - configures that submodule branch in the superproject: git config -f .gitmodules submodule.common.branch dev/some-feature git commit -am TEMP: track submodule common on branch - and pushes out his superproject branch The submodule branch is then posted for review and continued to work on. Once everyone involved is happy with the submodule change the branch in there gets merged to master. Now the branch in the superproject is modified to drop the change in .gitmodules and the sha1 reference in the superproject is updated to the current master of the superproject. The superproject branch is posted for review. ... Could you describe something like this for your workflow? A complete change lifecycle when a developer works, as you call it, actively in a submodule? - What are these subsequent merge or rebase update operations? Do you mean everyone has submodule.name.update configured to merge or rebase? subsequent merge or rebase update operations are just the ones after the initial clone/checkout, nothing particular. To clarify you are talking about issuing git merge or git rebase commands in the superproject? Cheers Heiko -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [PATCH 2/2] Introduce git submodule attached update
On Mon, Jan 06, 2014 at 12:22:23AM +0100, Francesco Pretto wrote: 2014/1/5 Heiko Voigt hvo...@hvoigt.net: Could you please extend the description of your use-case so we can understand your goal better? Maybe I found better words to explain you my goal: the current git submodule use-case threats the submodule as a project independent dependency. My use case threats the submodule as part of the superproject repository. It could be easier to say that in this way submodules would behave very similarly to svn:externals, something that is actually missing in git. My goal is obtain this without altering git behavior for the existing use case. I am not so sure. svn:externals was IMO a hack in SVN to bind projects together. It does not record the revision and so has nothing to do with version control. If you simply want to always checkout the development tip of some project you could do something like this: git submodule foreach 'git fetch git checkout origin/master' The demand for this 'missing feature' which we call the 'floating submodules' model has been around for some time but until now we could convince people that its not a feature but you are actually loosing history information. The workflow could always be changed to allow recording revisions. Which is why you use git in the first place right? If you discard revisions for submodules tracking down regression bugs can become a big problem or completely impossible. Try using git bisect on such a history. - In which situations does the developer or maintainer switch between your attached/detached mode? As I told you in the other answer this is voluntary done by the developer, as he prefers. Could you tell me a typical reason? I came to the conclusion that the --attach|--detach switches for the update command are not that useful and can be removed. It's still possible to obtain the switch between detached/attached very easily in this way: # Attach submodule $ git config submodule.name.attached true $ git submodule update # Detach submodule $ git config submodule.name.attached false $ git submodule update # Unset property in both .gitmodules and .git/config means - do nothing $ git config --unset submodule.name.attached $ git submodule update Also my submodule.name.attached property at the moment behaves like submodule.name.update: it is copied in .git/config by git submodule init. This is probably a mistake: the overridden value should be stored in .git/config only at the developer will, so the maintainer has still a chance to modify it in .gitmodules and propagate the behavior. I would send an updated patch but at this point I prefer to wait for a full review. Lets first discuss and figure out what is the real missing feature here and what should be implemented before working further on the code. Cheers Heiko -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Introduce git submodule attached update
On Mon, Jan 06, 2014 at 03:18:05PM +0100, Heiko Voigt wrote: If you simply want to always checkout the development tip of some project you could do something like this: git submodule foreach 'git fetch git checkout origin/master' Or (respecting submodule.name.branch): $ git submodule update --remote You can even: $ git submodule update --remote --recursive whenever you get an itch to upgrade everything everything in one sweeping, hard-to-debug move ;). Cheers, Trevor -- 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 signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2] Introduce git submodule attached update
(Hmmpth, forgot signoff...) To whom it may interest, added some CC. 2014/1/5 Francesco Pretto cez...@gmail.com: At the current state, the following use-case is not supported very well in git: - a maintainer adds a submodule, checking out a specific branch of the repository. He doesn't track the upstream submodule revision sha1; - a developer checkout the repository branch decided by the maintainer. Subsequent merge or rebase update operations don't detach the HEAD. To ease the above use-case this patch: - introduces a submodule.module.attached property that, when set to true, ensures that the update operation will result in the HEAD attached to a branch; - introduces --attach|--dettach switches to the submodule update command: they attach/detach the HEAD, overriding submodule.module.attached property value; - introduces --attached-update switch to the add operation. It: * sets submodule.module.attached to true; * sets submodule.module.ignore to all. Using the '--attach' switch or operating in a repository with 'submodule.name.attached' set to 'true' during update will: - checkout a branch with an attached HEAD if the repository was just cloned; - perform a fast-forward only merge of changes if it's a 'checkout' update operation; - reattach the HEAD prior performing a 'merge', 'rebase' or '!command' update operation if the HEAD was found detached. Orphaned commits will also be merged back in the branch. '--attach' or 'submodule.name.attached' set to true also implies '--remote'. Using the '--detach' switch or operating in a repository with 'submodule.name.attached' set to 'false' during update will: - checkout a detached HEAD if the repository was just cloned; - detach the HEAD prior performing a 'merge', 'rebase' or '!command' update operation if the HEAD was found attached. 'submodule.name.attached' works similarly to 'submodule.name.update' property: git copies the values found in .gitmodules in .git/config when performing an init command. update looks for values in .git/config only. '--attach' and '--detach' switches override an opposite behaviour of 'submodule.name.attached' properties. The patch is strongly additive and doesn't break any submodule specific test. It also adds some tests specific to the added feature. --- Documentation/git-submodule.txt| 48 +-- Documentation/gitmodules.txt | 10 +- git-submodule.sh | 154 +++-- t/t7410-submodule-attached-head.sh | 268 + 4 files changed, 457 insertions(+), 23 deletions(-) create mode 100755 t/t7410-submodule-attached-head.sh diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index bfef8a0..b97eefb 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -10,13 +10,14 @@ SYNOPSIS [verse] 'git submodule' [--quiet] add [-b branch] [-f|--force] [--name name] - [--reference repository] [--depth depth] [--] repository [path] + [--reference repository] [--attached-update] [--depth depth] + [--] 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] - [-f|--force] [--rebase] [--reference repository] [--depth depth] - [--merge] [--recursive] [--] [path...] + [-f|--force] [--rebase] [--reference repository] [--attach | --detach] + [--depth depth] [--merge] [--recursive] [--] [path...] 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) n] [commit] [--] [path...] 'git submodule' [--quiet] foreach [--recursive] command @@ -107,6 +108,9 @@ is the superproject and submodule repositories will be kept together in the same relative location, and only the superproject's URL needs to be provided: git-submodule will correctly locate the submodule using the relative URL in .gitmodules. ++ +If `--attached-update` is specified, the property `submodule.name.attached` +will be set to `true` and `submodule.name.ignore` will be set to `all`. status:: Show the status of the submodules. This will print the SHA-1 of the @@ -156,12 +160,15 @@ 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. - This will make the submodules HEAD be detached unless `--rebase` or - `--merge` is specified or the key `submodule.$name.update` is set to - `rebase`, `merge` or `none`. `none` can be overridden by specifying - `--checkout`. Setting the key `submodule.$name.update` to `!command` - will cause
Re: [PATCH 2/2] Introduce git submodule attached update
2014/1/5 Heiko Voigt hvo...@hvoigt.net: Could you please extend the description of your use-case so we can understand your goal better? Just in case you missed the first patch iteration[1]. The following questions directly pop into my mind: - What means the maintainer does not track the submodules sha1? Does that mean the superproject always refers to submodule commits using branches? It means he doesn't need to control other developers commit to be checked out so he sets submodule.name.ignore to all. In this way he and the developers can work actively in their submodule copy. - What happens if you want to go back to an earlier revision? Lets say a tagged release? How is ensured that you get the correct revision in the submodules? submodule.name.branch is one setting that is not copied in .git/config by git submodule init. git submodule update will use the setting in .gitmodules if not overridden voluntarily by the developer in .git/config. The maintainer can change that setting in .gitmodules and commit the change. Modifies will be propagated by the next git pull git submodule update of the developer in the superproject. - In which situations does the developer or maintainer switch between your attached/detached mode? The developer/maintainer does so optionally and voluntarily and it effects only its private working tree. - What is the repository branch which is given to the developer by the maintainer used for? Who creates this branch and who merges into it? The branch of course must exist prior submodule adding. In this use-case it does not really matter who creates it and who merges into it. Everyone with the right to merge into it has to work in the submodule seamlessly, as it was working on separate clone of the same repository used as the submodule. - What are these subsequent merge or rebase update operations? Do you mean everyone has submodule.name.update configured to merge or rebase? subsequent merge or rebase update operations are just the ones after the initial clone/checkout, nothing particular. Greetings, Francesco [1] http://marc.info/?l=gitm=138836829531511w=2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Introduce git submodule attached update
2014/1/5 Heiko Voigt hvo...@hvoigt.net: Could you please extend the description of your use-case so we can understand your goal better? Maybe I found better words to explain you my goal: the current git submodule use-case threats the submodule as a project independent dependency. My use case threats the submodule as part of the superproject repository. It could be easier to say that in this way submodules would behave very similarly to svn:externals, something that is actually missing in git. My goal is obtain this without altering git behavior for the existing use case. - In which situations does the developer or maintainer switch between your attached/detached mode? As I told you in the other answer this is voluntary done by the developer, as he prefers. I came to the conclusion that the --attach|--detach switches for the update command are not that useful and can be removed. It's still possible to obtain the switch between detached/attached very easily in this way: # Attach submodule $ git config submodule.name.attached true $ git submodule update # Detach submodule $ git config submodule.name.attached false $ git submodule update # Unset property in both .gitmodules and .git/config means - do nothing $ git config --unset submodule.name.attached $ git submodule update Also my submodule.name.attached property at the moment behaves like submodule.name.update: it is copied in .git/config by git submodule init. This is probably a mistake: the overridden value should be stored in .git/config only at the developer will, so the maintainer has still a chance to modify it in .gitmodules and propagate the behavior. I would send an updated patch but at this point I prefer to wait for a full review. Thank you, Francesco -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html