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..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 ] […] > > > > 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
-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..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 ] […] > > 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
2014/1/7 Junio C Hamano : > Francesco Pretto 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: [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 : > Francesco Pretto 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
Francesco Pretto 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
Francesco Pretto 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
On Mon, Jan 06, 2014 at 06:47:58PM +0100, Francesco Pretto wrote: > I'm really sorry, I thought this was already clear from the first > patch iteration. I will go more in depth: For me anyway, this extra detail is very helpful. Thanks :). > Maintainer of "project1" also prepares a branch > "project1-staging-featureA" on "common" and set ".gitmodules" of > "project1" to point to "project1-staging-featureA". Developers of > featureA would like to do this: > > $ git pull > $ git checkout staging-featureA > $ git submodule update # clones an attached HEAD of common on the branch > # 'submodule.common.project1.staging-featureA' > $ start coding in common seamlessly as they where in project1 So the checked-out branch switches depending on the local superproject branch. That sounds nice, but I'm not sure where the superproject-branch-to-local-submodule-branch mapping would be stored. We currently do this for remote-tracking submodule branches with an in-tree .gitmodules (which can differ between submodule branches) with local overides in a single out-of-tree .git/config (which is independent of the checked out branch). Ideally we'd have a way to add local overrides on a per-superproject-branch basis, but I don't know what that would look like. > Also developers do frequently rebase: > $ git pull --rebase > $ git submodule update > > Or maybe a shortcut of this: "git submodule update" should be given > the possibility to go "--remote" by default. Rebasing the superproject and then updating the submodules (to the superproject's gitlinked commits) is not the same as a --remote update (to the subproject's upstream branch tip). > Of course if "common" of the developer is in a branch different that > 'submodule..branch' "git submodule update" has not to switch > the branch. I don't understand what you're saying here. > >> Maybe who coded submodules at first was thinking that the best > >> way to contribute to a project is to checkout that repository, > >> and not work in the submodule. As said, this works well when the > >> submodule repository is a full project, and not a bunch of shared > >> code. > > > >Why not work in the submodule? See explanation above. > > Because, as said above, the submodule is not independent. It does > not have proper code that test it and the best test case is using > the submodule in the scope of the superproject. You can cd into the submodule, and develop it as an independent repository. When you want to test your changes, just cd back into the superproject and run your test suite. > 2014/1/6 Heiko Voigt : > > 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' > > This can be very unconvenient if the reccomended *starting* branch to > where attach the HEAD is not "master": > git submodule foreach 'branch="$(git config -f $toplevel/.gitmodules > submodule.$name.branch)"; git checkout origin/$branch Which is equivalent to: $ git submodule update --remote --checkout except for branch-vs-detached-HEAD. If you are doing local development, I'd recommend setting up submodule..update to a non-checkout strategy and using: $ git submodule update --remote which will integrate the upstream changes with any local changes (updating whichever local submodule branch you had checked out). > Also with the comit[1] that blocks copying of !command to > ".git/config" and sets default "none", you made it harder to offer a > mantainer decided default update behavior like the one I described. The maintainer can still suggest checkout/pull/rebase, and the developer can still clear remove the none from .git/config after initializing the submodule. You only need to do this once per submodule. > 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; I agree, and want to use a non-checkout submodule..update mode to identify developers who would want this. My v2 patch switches on submodule..branch, but I'll update it in v3 to switch on submodule..update. There's no need to confuse this with additional attach/detach functionality. > - "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. You can already add aliases, but a remote/local-gitlink config variable would be nice too. 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
Re: [PATCH 2/2] Introduce git submodule attached update
Francesco Pretto writes: > 2014/1/6 Heiko Voigt : >> 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? >> > > I'm really sorry, I thought this was already clear from the first > patch iteration. I will go more in depth: While I have some trouble understanding all the details of Francesco's description, I find the idea of "attaching submodules to branches" very useful. I think I could well use that to simplify my merging grunt work for GNU Emacs (which, in case you're wondering, is probably switching to git as its VCS). I don't mean to hijack this thread, and I guess my use case is a bit different than what Francesco has in mind; still, I think it is similar enough that my use case could help in talking about the details of his patch; if not, please feel free to ignore it. GNU Emacs ships with some pretty large packages, namely Gnus, Org and CEDET, which are also available as "stand-alone" versions for manual installation, and their development happens in separate upstream repositories. Since I'm a CEDET developer, I'll use it as an example in the following. First off, it is important to note that merges are always bi-directional: not only is new CEDET code pulled into Emacs, but Emacs developers also change things which have to be merged back upstream. So far, merging between the two repositories was done manually by me, which is error-prone (and boring). I think that by pulling in CEDET directly as a submodule, this merging could be made easier. Most importantly, my hope is that more people than me could do it. :-) Here's how I would like this to work; first the CEDET -> Emacs part, which is rather straight-forward: - The CEDET repository has two branches: 'master' and 'stable'. - The Emacs repository imports CEDET's 'stable' branch as a submodule. - CEDET's main development happens in 'master', and the CEDET developers are responsible for merging stable code to 'stable'. They will then make a new commit for the submodule in Emacs accordingly. The Emacs -> CEDET part is more hairy. Most of the time, the fixes happening in the Emacs repository for CEDET are very small and/or trivial and can usually be considered "always stable": fixes for spelling, compiler warnings, or small refactorings like renames, etc. This kind of "merging back to CEDET upstream" should hence be as easy as possible for Emacs developers: - When an Emacs developer changes something in the CEDET submodule, the changes they commit should by default automatically land in CEDET's 'stable' branch. That means that when they enter the submodule, they should be in the branch 'stable' instead of being detached, and a push should update the 'stable' branch in CEDET accordingly. The submodule must then be committed as well. - It is then up to the CEDET developers to merge these changes into the 'master' branch of the CEDET repo. I know that the "correct" workflow would be to always use feature branches, but it'd be nice if that could be avoided if one so chooses. A little picture in the hope that it makes things clearer: +---+ | master | <-- +---++---+| Merges to/from master | CEDET | | done only by CEDET developers +---+ | +---+| | stable | <-- < +---+ | | | | Any Emacs developer | can push and commit | submodule +++--+ | | Emacs | -- | lisp/cedet submodule | <- +++--+ AFAICS the main problem with this approach is that one always has to think of committing the new SHA1 of the submodule. If I understand Francesco correctly, he wants to eliminate the need for that by simply always taking the head of the attached branch. I also think that would be a nice feature, since in the above drawing, the lisp/cedet submodule should always follow the 'stable' branch in CEDET upstream. 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? -David -- 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
Dear Heiko, my replies below. I also take a couple excerpts from other emails, as I prefer to not flame on different threads :) . 2014/1/6 Heiko Voigt : > On Sun, Jan 05, 2014 at 10:46:11PM +0100, Francesco Pretto wrote: >> It means he doesn't need to control other developers commit to be >> checked out so he sets "submodule..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..ignore is set to "all" in the master branch of the > superproject? From your other email referring to svn:externals I figure > that. > Correct, but this works also if the branch of the superproject is a different branch than "master". I think you are right in a point, see the next reply. > 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. > Ok, you are right: setting "submodule..ignore" to "all" by default with a switch "--attached" in "git submodule add" is too much. My point is just make sure users will checkout an attached HEAD. >> "submodule..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..branch? > "submodule..attacched" set to true implies "--remote". sha1 of the latest commit is taken from "origin/$branch". In this way you get the latest commit of that branch, and you do a 'merge', 'rebase', 'checkout' or '!command' according to the configured ''. This mechanism is already in the patch at the current state. >> > - 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". This ability is of course already possible reattaching the HEAD manually but you loose the convenient ability to use "git submodule update". >> 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? > I'm really sorry, I thought this was already clear from the first patch iteration. I will go more in depth: Say we have our actual projects "project1" and "project2". Say we have a project "common". This "common" project is *not* independent: it exists only to serve "project1" and "project2" and it's tested only in the scope of "project1" and "project2". Also "common" is very actively developed and follows the same lifecyle of "project1" and "project2" on separate branches. I think that it's important that you get this point: developers of "common" don't cl
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..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: 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 : > > 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..attached "true" > $ git submodule update > > # Detach submodule > $ git config submodule..attached "false" > $ git submodule update > > # Unset property in both ".gitmodules" and ".git/config" means -> do nothing > $ git config --unset submodule..attached > $ git submodule update > > Also my "submodule..attached" property at the moment behaves > like "submodule..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: 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 : > > 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..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..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..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..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: [PATCH 2/2] Introduce git submodule attached update
2014/1/5 Heiko Voigt : > 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..attached "true" $ git submodule update # Detach submodule $ git config submodule..attached "false" $ git submodule update # Unset property in both ".gitmodules" and ".git/config" means -> do nothing $ git config --unset submodule..attached $ git submodule update Also my "submodule..attached" property at the moment behaves like "submodule..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
Re: [PATCH 2/2] Introduce git submodule attached update
2014/1/5 Heiko Voigt : > > 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..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..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=git&m=138836829531511&w=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
On Sun, Jan 05, 2014 at 03:50:49AM +0100, Francesco Pretto wrote: > 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. Could you please extend the description of your use-case so we can understand your goal better? 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? - 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? - In which situations does the developer or maintainer switch between your attached/detached mode? - 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? - What are these subsequent "merge" or "rebase" update operations? Do you mean everyone has submodule.name.update configured to merge or rebase? Still puzzled. 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
(Hmmpth, forgot signoff...) To whom it may interest, added some CC. 2014/1/5 Francesco Pretto : > 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..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..attached" property value; > - introduces "--attached-update" switch to the "add" operation. It: > * sets "submodule..attached" to true; > * sets "submodule..ignore" to all. > > Using the '--attach' switch or operating in a repository with > 'submodule..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..attached' set to true also implies '--remote'. > > Using the '--detach' switch or operating in a repository with > 'submodule..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..attached' works similarly to 'submodule..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..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 ] [-f|--force] [--name ] > - [--reference ] [--depth ] [--] > [] > + [--reference ] [--attached-update] [--depth ] > + [--] [] > 'git submodule' [--quiet] status [--cached] [--recursive] [--] [...] > 'git submodule' [--quiet] init [--] [...] > 'git submodule' [--quiet] deinit [-f|--force] [--] ... > 'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch] > - [-f|--force] [--rebase] [--reference ] [--depth > ] > - [--merge] [--recursive] [--] [...] > + [-f|--force] [--rebase] [--reference ] [--attach | > --detach] > + [--depth ] [--merge] [--recursive] [--] [...] > 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) > ] > [commit] [--] [...] > 'git submodule' [--quiet] foreach [--recursive] > @@ -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..attached` > +will be set to `true` and `submodule..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 `command` to be run. `command` can be any arbitrary shell > -
[PATCH 2/2] Introduce git submodule attached update
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..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..attached" property value; - introduces "--attached-update" switch to the "add" operation. It: * sets "submodule..attached" to true; * sets "submodule..ignore" to all. Using the '--attach' switch or operating in a repository with 'submodule..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..attached' set to true also implies '--remote'. Using the '--detach' switch or operating in a repository with 'submodule..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..attached' works similarly to 'submodule..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..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 ] [-f|--force] [--name ] - [--reference ] [--depth ] [--] [] + [--reference ] [--attached-update] [--depth ] + [--] [] 'git submodule' [--quiet] status [--cached] [--recursive] [--] [...] 'git submodule' [--quiet] init [--] [...] 'git submodule' [--quiet] deinit [-f|--force] [--] ... 'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch] - [-f|--force] [--rebase] [--reference ] [--depth ] - [--merge] [--recursive] [--] [...] + [-f|--force] [--rebase] [--reference ] [--attach | --detach] + [--depth ] [--merge] [--recursive] [--] [...] 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) ] [commit] [--] [...] 'git submodule' [--quiet] foreach [--recursive] @@ -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..attached` +will be set to `true` and `submodule..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 `command` to be run. `command` can be any arbitrary shell - command that takes a single argument, namely the sha1 to update to. + This will make the submodules HEAD be detached unless `--attach` is + specified or `submodule.$name.attached` is set to `true`. The last setting + can always be overridden specifying `--detach`. Update mode
