Re: Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option
On Fri, Nov 23, 2012 at 11:23:29AM -0500, W. Trevor King wrote: > On Fri, Nov 23, 2012 at 04:55:21PM +0100, Heiko Voigt wrote: > > On Tue, Nov 20, 2012 at 11:52:46AM -0800, Junio C Hamano wrote: > > > "W. Trevor King" writes: > > > > > > > The superproject gitlink should only be updated after > > > > > > > > $ git submodule update --pull > > > > > > > > A plain > > > > > > > > $ git submodule update > > > > > > > > would still checkout the previously-recorded SHA, not the new upstream > > > > tip. > > > > > > Hrm, doesn't it make the "float at the tip of a branch" mode > > > useless, though? > > > > How about having a branch config option and reusing our > > submodule.$name.update option for specifying whether the user wants to > > always float to the tip of the branch? > > I'm adding "update --pull" as one of the update options in v4, which I > am writing up as we speak ;). On second thought, this does not seem to be a good idea. The current fancy update styles (--rebase, --merge) are both for cases where you have local commits in the submodule and are trying to incorporate new gitlinks from an updated superproject into the submodule's checked out branch: superproject $ cd submod superproject $ git checkout next submod $ …hack hack hack… submod $ git commit … submod $ cd .. …upstream superproject changes… superproject $ git pull …updated SHA1 for submod gitlink… superproject $ git submodule update --merge …merge superproject's gitlink SHA1 into local submod branch… My submodule..branch option gives a local branch to check out: …upstream submod changes… superproject $ git cd ssubmodule update --pull …fetch upstream submod changes and ff-merge into local submodule..branch… This seems suitably distinct that bundling it with the other update options will just add confusion. So, let's rethink this approach. I'm trying to pull the upstream version of my local submod branch. The difficulties with this are: 1. Checking out a local branch (from the default detached state) to do something on it requires an ungainly: $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && …' 2. The remote pulling behavior is configured in .git/modules//config, which is not tracked in the repository itself. I'm ok with forcing local users to handle 2 manually (or implicitly), but 1 is crazy. Addin submodule..branch explicitly to .gitmodules is a step towards fixing 1, but submod pull doesn't match an existing submodules-implemented workflow. Perhaps a better choice would be to borrow the implicit-local-checkout behaviour used by --rebase and --merge. We could add $ git submodule update --branch to checkout the gitlinked SHA1 as submodule..branch in each of the submodules, leaving the submodules on the .gitmodules-configured branch. Effectively (for each submodule): $ git branch -f $branch $sha1 $ git checkout $branch Then I could use $ git submodule foreach 'git pull' to update my submodule tracking branches (without further "git submodule" restructuring). This would help everyone that doesn't like the detached head state (me and --rebase/--merge users). I could avoid implementing "update --pull", and all of the difficulty in configuring upstream merge choices (2) would be punted to the user making local edits in .git/modules//config. 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 v3 1/3] git-submodule add: Add -r/--record option
On Fri, Nov 23, 2012 at 11:23:29AM -0500, W. Trevor King wrote: > On Fri, Nov 23, 2012 at 05:03:01PM +0100, Heiko Voigt wrote: > > There is an important question still unanswered here for me: How does > > the submodule get the configuration what the local branch tracks on the > > remote side? > > A good point ;). I'm actaully using submodule..branch to store > the submodule's local branch name. The remote branch name for the > pull is implicit, and defaults to something setup according to > branch.autosetupmerge (I think). If you want to get more complicated > than this, we'll probably have to add submodule..branch and > submodule..remote sections to augment the > submodule..branch setting. I'm not sure this is worth it. These settings are currently stored in .git/modules//config What we're missing is a place to store them in the .gitmodules file. I'll poke around in the module-config initialization and wait for inspiration ;). -- 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 v3 1/3] git-submodule add: Add -r/--record option
On Fri, Nov 23, 2012 at 04:55:21PM +0100, Heiko Voigt wrote: > On Tue, Nov 20, 2012 at 11:52:46AM -0800, Junio C Hamano wrote: > > "W. Trevor King" writes: > > > > > The superproject gitlink should only be updated after > > > > > > $ git submodule update --pull > > > > > > A plain > > > > > > $ git submodule update > > > > > > would still checkout the previously-recorded SHA, not the new upstream > > > tip. > > > > Hrm, doesn't it make the "float at the tip of a branch" mode > > useless, though? > > How about having a branch config option and reusing our > submodule.$name.update option for specifying whether the user wants to > always float to the tip of the branch? I'm adding "update --pull" as one of the update options in v4, which I am writing up as we speak ;). > 1. If submodule.$name.update is pull it would checkout the specified tip. and pull from the submodule's upstream. This doesn't need the recorded $sha1, so I may have to rework the current if (clear_local_git_env; cd "$sm_path" && $command "$sha1") > 2. If submodule.$name.update is checkout or none it would do the usual >thing and you need to specify --pull to get the tip. Exactly. > So currently I am more on the "have an automatically generated > commit message" side. Its in a similar corner like merge commits, that > are also generated, for me. We could have it as the default and a > --no-commit option (like merge) for people that want to stage submodules > individually. This sounds reasonable, but I'd like to postpone message-generation sugar until we get the basic functionality ironed out. On Fri, Nov 23, 2012 at 05:03:01PM +0100, Heiko Voigt wrote: > On Tue, Nov 20, 2012 at 07:19:12AM -0500, W. Trevor King wrote: > > The benefit is that Ævar's > > > > $ git submodule foreach 'git checkout $(git config --file > > $toplevel/.gitmodules submodule.$name.branch) && git pull' > > > > becomes > > > > $ git submodule update --pull > > There is an important question still unanswered here for me: How does > the submodule get the configuration what the local branch tracks on the > remote side? A good point ;). I'm actaully using submodule..branch to store the submodule's local branch name. The remote branch name for the pull is implicit, and defaults to something setup according to branch.autosetupmerge (I think). If you want to get more complicated than this, we'll probably have to add submodule..branch and submodule..remote sections to augment the submodule..branch setting. I'm not sure this is worth it. -- 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 v3 1/3] git-submodule add: Add -r/--record option
On Tue, Nov 20, 2012 at 07:19:12AM -0500, W. Trevor King wrote: > The benefit is that Ævar's > > $ git submodule foreach 'git checkout $(git config --file > $toplevel/.gitmodules submodule.$name.branch) && git pull' > > becomes > > $ git submodule update --pull There is an important question still unanswered here for me: How does the submodule get the configuration what the local branch tracks on the remote side? 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 v3 1/3] git-submodule add: Add -r/--record option
On Tue, Nov 20, 2012 at 11:52:46AM -0800, Junio C Hamano wrote: > "W. Trevor King" writes: > > > The superproject gitlink should only be updated after > > > > $ git submodule update --pull > > > > A plain > > > > $ git submodule update > > > > would still checkout the previously-recorded SHA, not the new upstream > > tip. > > Hrm, doesn't it make the "float at the tip of a branch" mode > useless, though? How about having a branch config option and reusing our submodule.$name.update option for specifying whether the user wants to always float to the tip of the branch? 1. If submodule.$name.update is pull it would checkout the specified tip. 2. If submodule.$name.update is checkout or none it would do the usual thing and you need to specify --pull to get the tip. I am still a little bit undecided about an automatically crafted commit. At $dayjob we sometimes update submodules to their tip without any superproject changes just to make sure we use the newest version. Most of the time the commit messages are along the lines of "updated submodule x to master". On one hand Junio is right that the person updating to the newest submodule stuff has no clue what to write in this message. On the other hand someone might as well just use this functionality to get all the tips of all the submodules checked out. He then individually decides which changes to take by using add but will then still use a commit message like the one above. So currently I am more on the "have an automatically generated commit message" side. Its in a similar corner like merge commits, that are also generated, for me. We could have it as the default and a --no-commit option (like merge) for people that want to stage submodules individually. 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: Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option
On Sat, Nov 17, 2012 at 10:31:30PM +0100, Heiko Voigt wrote: > On Sat, Nov 17, 2012 at 02:20:27PM -0500, W. Trevor King wrote: > > On Sat, Nov 17, 2012 at 04:30:07PM +0100, Heiko Voigt wrote: > > > > > (2) "git diff [$path]" and friends in the superproject compares the > > > > > HEAD of thecheckout of the submodule at $path with the tip of > > > > > the branch named by submodule.$name.branch in .gitmodules of > > > > > the superproject, instead of the commit that is recorded in the > > > > > index of the superproject. > > > > > > > > > > > > > Hmm. ???git diff??? compares the working tree with the local HEAD > > > > (just a > > > > SHA for submodules), so I don't think it should care about the status > > > > of a remote branch. This sounds like you want something like: > > > > > > > > $ git submodule foreach 'git diff origin/$submodule_branch' > > > > > > > > Perhaps this is enough motivation for keeping $submodule_* exports? > > > > > > > > > and the option were called something like "--follow-branch=$branch", > > > > > ??? > > > > > > I am not sure if hiding changes to the recorded SHA1 from the user is > > > such a useful thing. In the first step I would like it if it was kept > > > simple and only the submodule update machinery learned to follow a > > > branch. If that results in local changes that should be shown. The user > > > is still in charge of recording the updated SHA1 in his commit. > > > > I understand what you're warning against here, or what it has to do > > with "git diff". > > Is there a not missing here? Thanks. I'd meant to say "I don't understand…". > What I am talking about is the suggestion of Junio. Instead of > showing a diff if the SHA1 is different we show a diff if the > checkout in the worktree is different from the tip of the configured > branch. That would hide the fact that a submodule has changed during > a submodule update operation. Ahh, now I understand. I agree that comparing to the remote tip is a bad idea. -- 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: Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option
On Sat, Nov 17, 2012 at 02:20:27PM -0500, W. Trevor King wrote: > On Sat, Nov 17, 2012 at 04:30:07PM +0100, Heiko Voigt wrote: > > > > (2) "git diff [$path]" and friends in the superproject compares the > > > > HEAD of thecheckout of the submodule at $path with the tip of > > > > the branch named by submodule.$name.branch in .gitmodules of > > > > the superproject, instead of the commit that is recorded in the > > > > index of the superproject. > > > > > > > > > > Hmm. ???git diff??? compares the working tree with the local HEAD (just a > > > SHA for submodules), so I don't think it should care about the status > > > of a remote branch. This sounds like you want something like: > > > > > > $ git submodule foreach 'git diff origin/$submodule_branch' > > > > > > Perhaps this is enough motivation for keeping $submodule_* exports? > > > > > > > and the option were called something like "--follow-branch=$branch", > > > > ??? > > > > I am not sure if hiding changes to the recorded SHA1 from the user is > > such a useful thing. In the first step I would like it if it was kept > > simple and only the submodule update machinery learned to follow a > > branch. If that results in local changes that should be shown. The user > > is still in charge of recording the updated SHA1 in his commit. > > I understand what you're warning against here, or what it has to do > with "git diff". Is there a not missing here? Reads somehow like that. What I am talking about is the suggestion of Junio. Instead of showing a diff if the SHA1 is different we show a diff if the checkout in the worktree is different from the tip of the configured branch. That would hide the fact that a submodule has changed during a submodule update operation. > > From what I have heard of projects using this: They usually still have > > something that records the SHA1s on a regular basis. Thinking further, > > why not record them in git? We could add an option to update which > > creates such a commit. > > I think it's best to have users craft their own commit messages > explaining why the branch was updated. That said, an auto-generated > hint (a la "git merge") would probably be a useful extra feature. I have the same opinion. Commits should always be created by humans so you have someone to blame/ask why. But I guess there are people that expect this to be automatic. One argument somehow goes along the lines: "I already created a commit in the submodule why do I need to create another one in the superproject? Just follow the HEAD revision!" They think in subversions "submodules" which are merely pointers to other svn repositories without any revision information. I am unsure if its good to support this the same way. Another use case is big projects that have so many submodules that creating superproject commits would create to much maintenance work. They want to have their integration server make those commits. That would already be supported with update checking out the branch tips and the commit is just one extra thing to do by the integration server. So I think it should be fine just to teach update to checkout the configured branch tips (or forward them to their tracking branch tips) and leave the rest to the user. 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 v3 1/3] git-submodule add: Add -r/--record option
On Sat, Nov 17, 2012 at 04:04:42PM +0100, Heiko Voigt wrote: > > On Sat, Nov 10, 2012 at 01:44:37PM -0500, W. Trevor King wrote: > > > $ git submodule pull-branch > > > > I think "floating submodules" is a misleading name for this feature > > though, since the checkout SHA is explicitly specified. We're just > > making it more convenient to explicitly update the SHA. How about > > "tracking submodules"? > > Until now we have always called this workflow floating submodules. I > imaging since the submodule floats to the newest revision (whatever the > user chooses that to be) instead of staying at the recorded sha1. > > "tracking submodules" sounds strange to me since the term tracked in git > is mainly used in combination with exact recorded history (e.g. tracking > branch). Since it is about *not* checking out the recorded sha1 but > something that can change I think that could cause confusion. > > I think floating is a more unambiguous term and already known on the > list. I had been getting the impression that floating submodules would automatically update without explicit user intervention. After re-reading your initial floating submodules post, it looks like we do match up after the mapping: GitHeiko Trevor - - - update update --checkout update update update --pull So I'll go back to "floating" ;). On Sat, Nov 17, 2012 at 04:30:07PM +0100, Heiko Voigt wrote: > > > (2) "git diff [$path]" and friends in the superproject compares the > > > HEAD of the checkout of the submodule at $path with the tip of > > > the branch named by submodule.$name.branch in .gitmodules of > > > the superproject, instead of the commit that is recorded in the > > > index of the superproject. > > > > > > > Hmm. ???git diff??? compares the working tree with the local HEAD (just a > > SHA for submodules), so I don't think it should care about the status > > of a remote branch. This sounds like you want something like: > > > > $ git submodule foreach 'git diff origin/$submodule_branch' > > > > Perhaps this is enough motivation for keeping $submodule_* exports? > > > > > and the option were called something like "--follow-branch=$branch", > > > ??? > > I am not sure if hiding changes to the recorded SHA1 from the user is > such a useful thing. In the first step I would like it if it was kept > simple and only the submodule update machinery learned to follow a > branch. If that results in local changes that should be shown. The user > is still in charge of recording the updated SHA1 in his commit. I understand what you're warning against here, or what it has to do with "git diff". > From what I have heard of projects using this: They usually still have > something that records the SHA1s on a regular basis. Thinking further, > why not record them in git? We could add an option to update which > creates such a commit. I think it's best to have users craft their own commit messages explaining why the branch was updated. That said, an auto-generated hint (a la "git merge") would probably be a useful extra feature. -- 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 v3 1/3] git-submodule add: Add -r/--record option
Hi, On Sun, Nov 11, 2012 at 10:00:48AM -0500, W. Trevor King wrote: > On Sun, Nov 11, 2012 at 02:33:45AM -0800, Junio C Hamano wrote: > In order to avoid losing (or creating) local-only submodule commits, > I'll probably bail (with an error) on non-fast-forward pulls. Can > anyone else think of other safety concerns? That sounds like a good thing to do. We can allow more flexibility later if people come up with usecases. > This means that I'll probably drop Phil's $submodule_* export in v4, > because the only explicit use we have for it is this branch tracking. > I still think it is a useful idea, but it may not be useful enough to > be worth the complexity. Yes lets concentrate on the branch following first. > > (2) "git diff [$path]" and friends in the superproject compares the > > HEAD of the checkout of the submodule at $path with the tip of > > the branch named by submodule.$name.branch in .gitmodules of > > the superproject, instead of the commit that is recorded in the > > index of the superproject. > > > > Hmm. ???git diff??? compares the working tree with the local HEAD (just a > SHA for submodules), so I don't think it should care about the status > of a remote branch. This sounds like you want something like: > > $ git submodule foreach 'git diff origin/$submodule_branch' > > Perhaps this is enough motivation for keeping $submodule_* exports? > > > and the option were called something like "--follow-branch=$branch", > > ??? I am not sure if hiding changes to the recorded SHA1 from the user is such a useful thing. In the first step I would like it if it was kept simple and only the submodule update machinery learned to follow a branch. If that results in local changes that should be shown. The user is still in charge of recording the updated SHA1 in his commit. >From what I have heard of projects using this: They usually still have something that records the SHA1s on a regular basis. Thinking further, why not record them in git? We could add an option to update which creates such a commit. Since git is all about changes I am hesitant to hide them from the user. > I'll replace -r/--record with --follow-branch in v4. Sounds good. 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 v3 1/3] git-submodule add: Add -r/--record option
Hi, sorry for the late reply but my git time is limited. On Sat, Nov 10, 2012 at 02:02:32PM -0500, W. Trevor King wrote: > On Fri, Nov 09, 2012 at 05:29:27PM +0100, Heiko Voigt wrote: > > I think we should agree on a behavior for this option and implement it > > the same time when add learns about it. When we were discussing floating > > submodules as an important option for the gerrit people I already started > > to implement a proof of concept. Please have a look here: > > > > https://github.com/hvoigt/git/commits/hv/floating_submodules > > After skimming through this, something like > > $ git submodule update --pull > > would probably be better than introducing a new command: Yeah along the lines of that, but one thing to keep in mind: We already have --rebase and --merge which do slightly different things (I think). Adding --pull here should behave similar to them. Like fetch and merge is the same to pull without submodules. If I am understanding your goal correctly your --pull would be different. On the other hand: A --pull makes no sense if we apply it to the existing --merge option since it merges the recorded sha1 into the current HEAD. Just a fetch would not really make a difference. Thinking along the existing options I would probably still expect --pull to merge something into the current HEAD. So maybe we have to iron out where this command/option should go. But changing that once we have a patch to discuss should not be that much work. So please proceed with --pull and once we know exactly what it does we can polish that. > On Sat, Nov 10, 2012 at 01:44:37PM -0500, W. Trevor King wrote: > > $ git submodule pull-branch > > I think "floating submodules" is a misleading name for this feature > though, since the checkout SHA is explicitly specified. We're just > making it more convenient to explicitly update the SHA. How about > "tracking submodules"? Until now we have always called this workflow floating submodules. I imaging since the submodule floats to the newest revision (whatever the user chooses that to be) instead of staying at the recorded sha1. "tracking submodules" sounds strange to me since the term tracked in git is mainly used in combination with exact recorded history (e.g. tracking branch). Since it is about *not* checking out the recorded sha1 but something that can change I think that could cause confusion. I think floating is a more unambiguous term and already known on the list. 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
