Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option
"W. Trevor King" writes: >> As the command takes other options whose names begin with 'r', I >> thought the longer term plan was to stop letting "--rebase" squat on >> short and sweet "-r" and leaving it undocumented (even though the >> short one was added by mistake) was meant to be the first step in >> that process. >> >> But maybe I am confusing an undocumented single-letter option from >> some other subcommand. Anybody remembers? > > Perhaps you are remembering: > > On Sun, Nov 11, 2012 at 02:33:45AM -0800, Junio C Hamano wrote: >> Ah, this reminds me of another thing I noticed when I saw that >> ... No. The discussion might or might not be the "-r" option to "submodule update", but even if it were so, I wasn't refering to that exchange but something more in the further past. -- 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 v3 1/3] git-submodule add: Add -r/--record option
On Wed, Nov 28, 2012 at 11:02:45AM -0800, Junio C Hamano wrote: > "W. Trevor King" writes: > > > From: "W. Trevor King" > > > > Signed-off-by: W. Trevor King > > --- > > Documentation/git-submodule.txt | 3 ++- > > git-submodule.sh| 2 +- > > 2 files changed, 3 insertions(+), 2 deletions(-) > > Hmm, I wonder why I have this funny feeling that this was proposed > and rejected already... > > As the command takes other options whose names begin with 'r', I > thought the longer term plan was to stop letting "--rebase" squat on > short and sweet "-r" and leaving it undocumented (even though the > short one was added by mistake) was meant to be the first step in > that process. > > But maybe I am confusing an undocumented single-letter option from > some other subcommand. Anybody remembers? Perhaps you are remembering: On Sun, Nov 11, 2012 at 02:33:45AM -0800, Junio C Hamano wrote: > Ah, this reminds me of another thing I noticed when I saw that > patch. The change seems to think "branch" is the _only_ thing the > user might want to record per submodule upon "git submodule add". > As an interface to muck with an uninterpreted random configuration, > it squats on a good option name for setting one single and arbitrary > variable---quite a selfish change that is not acceptable. > > Calling the option "--record-branch-for-submodule" or something more > specific might alleviate the problem, but then it would become even > less useful as a short-hand for "config submodule.$name.branch", I > would suspect. With this recent patch, I'm just documenting someone else's squatting ;). But yes, the reason I noticed was because I was tempted to make the same mistake again :p. In my defense, I think `update --remote` is a good deal more general than my earlier `add --record`. 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 -- 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 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: [PATCH v3 1/3] git-submodule add: Add -r/--record option
Am Freitag, 23. November 2012, 16:55:21 schrieb Heiko Voigt: > 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. I've been thinking about that for a while, when I started using submodules. In the end, I concluded, that what I really want to see in the commit message, is something similar to $(git shortlog $OLD_SHA1..$NEW_SHA1). I've scripted that and taught my CI-Server to do it automatically, if possible. So most of the time, I really don't want an "automatically crafted commit" whenever something causes the tip of a submodule to be at a new SHA1. Just my $.02, though. Sascha -- 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 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: [PATCH v3 1/3] git-submodule add: Add -r/--record option
"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? -- 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 v3 1/3] git-submodule add: Add -r/--record option
On Mon, Nov 19, 2012 at 09:39:34PM -0800, Junio C Hamano wrote: > "W. Trevor King" writes: > > > On Mon, Nov 19, 2012 at 04:49:09PM -0800, Junio C Hamano wrote: > >> "W. Trevor King" writes: > >> ... > >> > 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 am not quite sure I agree. When the project says "Use the tip of > >> 'bar' branch for the submodule 'foo'" at the top-level, does an > >> individual user who is not working on the submodule 'foo' but merely > >> is using it have any clue as to why the submodule's 'foo' branch > >> 'foo' moved, or does he necessarily even care? > > > > If he doesn't care, why is he updating the submodule gitlink? > > He may not be updating the gitlink with "git add foo" at the > top-level superproject level. He is just using that submodule as > part of the larger whole as he is working on either the top-level or > some other submodule. And checkout of 'foo' is necessary in the > working tree for him to work in the larger context of the project, > and 'foo' is set to float at the tip of its 'bar' branch. And that > checkout results in a commit that is different from the commit the > gitlink suggests, perhaps because somebody worked in 'foo' submodule > and advanced the tip of branch 'bar'. 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. The uncaring user should skip the "--pull", and there will be no superproject changes to worry about. > Or are you envisioning that such a check-out will and should show a > local difference at the submodule 'foo' by leaving the index of the > top-level superproject unchanged, A plain "git submodule update" will, yes. And this will clobber any changes that have happened in the submodule directory and its index (because the user explicitly asked to checkout the superproject-recorded SHA) > and the user should refrain from using "git commit -a" to avoid > having to describe the changes made on the 'bar' branch in the > meantime in his top-level commit? What would "git commit -a" be picking up? Nothing in the superproject has changed? > That is certainly fine by me (I am no a heavy submodule user to > begin with), but I am not sure if that is useful and helpful to the > submodule users. 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 Still an explicit pull, but much easier to remember. -- 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 v3 1/3] git-submodule add: Add -r/--record option
"W. Trevor King" writes: > On Mon, Nov 19, 2012 at 04:49:09PM -0800, Junio C Hamano wrote: >> "W. Trevor King" writes: >> ... >> > 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 am not quite sure I agree. When the project says "Use the tip of >> 'bar' branch for the submodule 'foo'" at the top-level, does an >> individual user who is not working on the submodule 'foo' but merely >> is using it have any clue as to why the submodule's 'foo' branch >> 'foo' moved, or does he necessarily even care? > > If he doesn't care, why is he updating the submodule gitlink? He may not be updating the gitlink with "git add foo" at the top-level superproject level. He is just using that submodule as part of the larger whole as he is working on either the top-level or some other submodule. And checkout of 'foo' is necessary in the working tree for him to work in the larger context of the project, and 'foo' is set to float at the tip of its 'bar' branch. And that checkout results in a commit that is different from the commit the gitlink suggests, perhaps because somebody worked in 'foo' submodule and advanced the tip of branch 'bar'. So: - at the top-level superproject level, entry 'foo' in the HEAD tree points at an older commit; - 'foo/.git/HEAD' points at refs/heads/bar, which matches the working tree of 'foo' and the index foo/.git/index.. I am not sure what should happen to the entry 'foo' in the index of the top-level superproject after such a 'submodule floats at the tip' checkout, but I imagine that it must match the contents of foo/.git/HEAD's tree. Otherwise, "git diff" at the top-level would report local changes. When committing his work at the top-level, he will see that 'foo' gitlink is updated in that commit; after all that combination is the context in which his work was done. Or are you envisioning that such a check-out will and should show a local difference at the submodule 'foo' by leaving the index of the top-level superproject unchanged, and the user should refrain from using "git commit -a" to avoid having to describe the changes made on the 'bar' branch in the meantime in his top-level commit? That is certainly fine by me (I am no a heavy submodule user to begin with), but I am not sure if that is useful and helpful to the submodule users. -- 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 v3 1/3] git-submodule add: Add -r/--record option
On Mon, Nov 19, 2012 at 04:49:09PM -0800, Junio C Hamano wrote: > "W. Trevor King" writes: > > >> 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 am not quite sure I agree. When the project says "Use the tip of > 'bar' branch for the submodule 'foo'" at the top-level, does an > individual user who is not working on the submodule 'foo' but merely > is using it have any clue as to why the submodule's 'foo' branch > 'foo' moved, or does he necessarily even care? If he doesn't care, why is he updating the submodule gitlink? > Now, since somebody created the top-level commit you have just > pulled and checked out, other people may have worked on submodule > 'foo' [*1*]. What should happen on "git submodule update foo"? If the 'foo' checkout is not the one listed in the superproject's .gitmodules, the update should bail with an appropriate error message, and let the user sort things out. $ git submodule update --pull foo error: Your local changes to the following submodule would be overwritten by update:… This is similar to how Git currently bails on dirty-tree branch switches: $ git checkout my-branch error: Your local changes to the following files would be overwritten by checkout:… Without "--pull", the update command is intended to checkout the hash specified in .gitmodules. If you've committed some local work in foo and then explicitly ask for an update, I suppose you get clobbered. > What should appear in "git diff"? The working tree taken as a whole > is different from what the superproject's commit describes (which is > the state the person who created the superproject wanted to record) > even though this user does not have anything to do with the change > at 'foo' from the recorded commit to the current tip of 'bar'. What > would his description for the reason why the branch was updated? The submodule content is not part of the superproject. All the superproject has is a gitlink. If the gitlink hasn't changed, "git diff" in the superproject shouldn't say anything. I'll probably have time to write up v4 over the weekend. Maybe having a more explicit example will clear things up. -- 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 v3 1/3] git-submodule add: Add -r/--record option
"W. Trevor King" writes: >> 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 am not quite sure I agree. When the project says "Use the tip of 'bar' branch for the submodule 'foo'" at the top-level, does an individual user who is not working on the submodule 'foo' but merely is using it have any clue as to why the submodule's 'foo' branch 'foo' moved, or does he necessarily even care? For such a user working at the top-level superproject, or working on one part of the project, possibly on a submodule other than 'foo', wouldn't the natural thing to do would be to run "git pull" at the top-level, maybe with "--recursive" to update the top-level and all the submodules to start the day. Now, since somebody created the top-level commit you have just pulled and checked out, other people may have worked on submodule 'foo' [*1*]. What should happen on "git submodule update foo"? It would notice that the submodule 'foo' is set to float, and would check out the tip of the branch 'bar', not the commit recorded in the top-level superproject, in the working tree for 'foo', no? What should appear in "git diff"? The working tree taken as a whole is different from what the superproject's commit describes (which is the state the person who created the superproject wanted to record) even though this user does not have anything to do with the change at 'foo' from the recorded commit to the current tip of 'bar'. What would his description for the reason why the branch was updated? I think I would agree that "git diff" should not hide such changes (after all, when this user records his change to the overall project in the top-level supermodule, he will be recording the state with the commit at the tip of 'bar' checked out in the working tree of the submodule 'foo'), but I am not sure if the user can say anything sensible, other than "tip of 'bar' branch in submodule 'foo' was changed by others", in the resulting commit. [Footnote] *1* This may look like a non-issue if you assume that the person who updates the 'bar' branch of submodule 'foo' always updates the gitlink in the superproject's commit to point at that updated commit, but that assumption is flawed; the submodule project is a project on its own and can be worked on without what other projects bind it as their submodules. -- 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
Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option
On Sun, Nov 11, 2012 at 02:33:45AM -0800, Junio C Hamano wrote: > The change seems to think "branch" is the _only_ thing the user > might want to record per submodule upon "git submodule add". I felt that earlier floating/tracking submodule patches were biting off more than they could chew, so I was looking for a lightweight fix to make the tracking workflow easier. It seems like I ended up with something that is too lightweight ;). > On the other hand, if this were one small part of a series to define > the "tip following mode" where (at least) > > (1) "git submodule update [$path]" makes sure that the checkout of > the submodule at $path matches the commit at 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; and As I mentioned earlier, I think $ git submodule update [$path] should keep its current “checkout the already-registered SHA” functionality, with $ git submodule update --pull [$path] pulling the tracked branch. I'll add a patch implementing this to v4. 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? 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. > (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'll replace -r/--record with --follow-branch in v4. -- 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 v3 1/3] git-submodule add: Add -r/--record option
"W. Trevor King" writes: > On Thu, Nov 08, 2012 at 11:34:54PM -0800, Junio C Hamano wrote: > >> I would not object to "git config submodule.$name.branch $value", on >> the other hand. "git config" can be used to set a piece of data >> that has specific meaning, but as a low-level tool, it is not >> _limited_ to variables that have defined meaning. > > This is what I'm doing now: > > $ git submodule add -b > $ git config --file .gitmodules submodule..branch > $ git submodule foreach 'git checkout $(git config --file > $toplevel/.gitmodules submodule.$name.branch) && git pull' > > With my second patch (Phil's config export), that becomes > > $ git submodule add -b > $ git config --file .gitmodules submodule..branch > $ git submodule foreach 'git checkout $submodule_branch && git pull' > > With my first patch, that becomes > > $ git submodule add -rb > $ git submodule foreach 'git checkout $submodule_branch && git pull' > > This seems pretty useful to me,... Ah, this reminds me of another thing I noticed when I saw that patch. The change seems to think "branch" is the _only_ thing the user might want to record per submodule upon "git submodule add". As an interface to muck with an uninterpreted random configuration, it squats on a good option name for setting one single and arbitrary variable---quite a selfish change that is not acceptable. Calling the option "--record-branch-for-submodule" or something more specific might alleviate the problem, but then it would become even less useful as a short-hand for "config submodule.$name.branch", I would suspect. On the other hand, if this were one small part of a series to define the "tip following mode" where (at least) (1) "git submodule update [$path]" makes sure that the checkout of the submodule at $path matches the commit at 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; and (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. and the option were called something like "--follow-branch=$branch", it would make much more sense for its initial implementation to set the name of the branch to submodule.$name.branch variable. Later iterations of such a feature may want to do more than just setting that single variable but that is a part of the implementation detail of the tip following mode the users do not have to know about, just like setting the submodule.$name.branch variable is. So in that sense, too, I would be somewhat unhappy to see this change in the current form to go in. -- 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 v3 1/3] git-submodule add: Add -r/--record option
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: 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"? -- 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 -- 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 v3 1/3] git-submodule add: Add -r/--record option
On Fri, Nov 09, 2012 at 02:46:07AM -0800, Matt Kraai wrote: > On Thu, Nov 08, 2012 at 10:35:12PM -0500, W. Trevor King wrote: > > @@ -366,6 +379,10 @@ Use -f if you really want to add it." >&2 > > > > git config -f .gitmodules submodule."$sm_path".path "$sm_path" && > > git config -f .gitmodules submodule."$sm_path".url "$repo" && > > + if test -n "$branch" > > + then > > + git config -f .gitmodules submodule."$sm_path".branch > > "$record_branch" > > + fi && > > git add --force .gitmodules || > > die "$(eval_gettext "Failed to register submodule '\$sm_path'")" > > } > > Should the if condition test that $record_branch is not the empty > string instead of testing that $branch is not the empty string? It > seems like this will set submodule."$sm_path".branch to the empty > string if -b is specified and no -r option is specified. Oops, thanks for catching that. Will fix with v4, once we figure out what to do about the semantic-pull situation. -- 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 -- 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 v3 1/3] git-submodule add: Add -r/--record option
On Thu, Nov 08, 2012 at 11:34:54PM -0800, Junio C Hamano wrote: > "W. Trevor King" writes: > > > By remaining agnostic on the variable usage, this patch makes > > submodule setup more convenient for all parties. > > I personally do not think "remaining agnostic on the usage" is a > good thing, at least for any option to commands at the higher level > on the stack, such as "git submodule". I am afraid that giving an > easier way to set up a variable with undefined semantics may make > setup more confusing for all parties. One party gives one specific > meaning to the field, while another party uses it for something > slightly different. > > I would not object to "git config submodule.$name.branch $value", on > the other hand. "git config" can be used to set a piece of data > that has specific meaning, but as a low-level tool, it is not > _limited_ to variables that have defined meaning. This is what I'm doing now: $ git submodule add -b $ git config --file .gitmodules submodule..branch $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull' With my second patch (Phil's config export), that becomes $ git submodule add -b $ git config --file .gitmodules submodule..branch $ git submodule foreach 'git checkout $submodule_branch && git pull' With my first patch, that becomes $ git submodule add -rb $ git submodule foreach 'git checkout $submodule_branch && git pull' This seems pretty useful to me, but I'm still using submodule..branch explicitly as a user, and Git is not interpreting the option directly. Users are free to store whatever they like in that option, and use it however they wish: $ git submodule foreach 'do-crazy-stuff.sh $submodule_branch' If we need a semantic interpretation to justify -r/--record, everyone that's chimed in so far has agreed on the same interpretation. I wouldn't be averse to $ git submodule add -rb $ git submodule pull-branch which makes the foreach pull logic internal. However, there has been a reasonable amount of resistance to this workflow in the past, so I thought that a patch series that avoided a semantic interpretation would be more acceptable. If neither an agnostic -r/--record or a semantic pull-branch command are acceptable, I suppose we'll have to drop my first and third patches and only keep the second. 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 -- 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 v3 1/3] git-submodule add: Add -r/--record option
Hi, On Thu, Nov 08, 2012 at 11:34:54PM -0800, Junio C Hamano wrote: > "W. Trevor King" writes: > > > By remaining agnostic on the variable usage, this patch makes > > submodule setup more convenient for all parties. > > I personally do not think "remaining agnostic on the usage" is a > good thing, at least for any option to commands at the higher level > on the stack, such as "git submodule". I am afraid that giving an > easier way to set up a variable with undefined semantics may make > setup more confusing for all parties. One party gives one specific > meaning to the field, while another party uses it for something > slightly different. > > I would not object to "git config submodule.$name.branch $value", on > the other hand. "git config" can be used to set a piece of data > that has specific meaning, but as a low-level tool, it is not > _limited_ to variables that have defined meaning. 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 AFAIK this does not yet implement the same behaviour the gerrit tools offer for this option. The main reason behind that was because I do not know the typical workflow behind such an option. So I am open to changes. Maybe you can use or base your work on this implementation for submodule update. Without submodule update using this option I think it would be better to implement this option in the tool you are using instead of submodule add. Everything else feels incomplete to me. 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 v3 1/3] git-submodule add: Add -r/--record option
"W. Trevor King" writes: > By remaining agnostic on the variable usage, this patch makes > submodule setup more convenient for all parties. I personally do not think "remaining agnostic on the usage" is a good thing, at least for any option to commands at the higher level on the stack, such as "git submodule". I am afraid that giving an easier way to set up a variable with undefined semantics may make setup more confusing for all parties. One party gives one specific meaning to the field, while another party uses it for something slightly different. I would not object to "git config submodule.$name.branch $value", on the other hand. "git config" can be used to set a piece of data that has specific meaning, but as a low-level tool, it is not _limited_ to variables that have defined meaning. -- 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
[PATCH v3 1/3] git-submodule add: Add -r/--record option
From: "W. Trevor King"
This option allows you to record a submodule..branch option in
.gitmodules. Git does not currently use this configuration option for
anything, but users have used it for several things, so it makes sense
to add some syntactic sugar for initializing the value.
Current consumers:
Ævar uses this setting to designate the upstream branch for pulling
submodule updates:
$ git submodule foreach 'git checkout $(git config --file
$toplevel/.gitmodules submodule.$name.branch) && git pull'
as he describes in
commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
Author: Ævar Arnfjörð Bjarmason
Date: Fri May 21 16:10:10 2010 +
git-submodule foreach: Add $toplevel variable
Gerrit uses the same interpretation for the setting, but because
Gerrit has direct access to the subproject repositories, it updates
the superproject repositories automatically when a subproject changes.
Gerrit also accepts the special value '.', which it expands into the
superproject's branch name.
By remaining agnostic on the variable usage, this patch makes
submodule setup more convenient for all parties.
[1]
https://gerrit.googlesource.com/gerrit/+/master/Documentation/user-submodules.txt
Signed-off-by: W. Trevor King
---
Documentation/git-submodule.txt | 11 ++-
git-submodule.sh| 19 ++-
t/t7400-submodule-basic.sh | 25 +
3 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index b4683bb..cbec363 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -9,7 +9,7 @@ git-submodule - Initialize, update or inspect submodules
SYNOPSIS
[verse]
-'git submodule' [--quiet] add [-b branch] [-f|--force]
+'git submodule' [--quiet] add [-b branch] [--record[=]] [-f|--force]
[--reference ] [--] []
'git submodule' [--quiet] status [--cached] [--recursive] [--] [...]
'git submodule' [--quiet] init [--] [...]
@@ -209,6 +209,15 @@ OPTIONS
--branch::
Branch of repository to add as submodule.
+-r::
+--record::
+ Record a branch name used as `submodule..branch` in
+ `.gitmodules` for future reference. If you do not list an explicit
+ name here, the name given with `--branch` will be recorded. If that
+ is not set either, `HEAD` will be recorded. Because the branch name
+ is optional, you must use the equal-sign form (`-r=`), not
+ `-r `.
+
-f::
--force::
This option is only valid for add and update commands.
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..bc33112 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
# Copyright (c) 2007 Lars Hjemli
dashless=$(basename "$0" | sed -e 's/-/ /')
-USAGE="[--quiet] add [-b branch] [-f|--force] [--reference ] [--]
[]
+USAGE="[--quiet] add [-b branch] [--record[=]] [-f|--force]
[--reference ] [--] []
or: $dashless [--quiet] status [--cached] [--recursive] [--] [...]
or: $dashless [--quiet] init [--] [...]
or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force]
[--rebase] [--reference ] [--merge] [--recursive] [--] [...]
@@ -20,6 +20,8 @@ require_work_tree
command=
branch=
+record_branch=
+record_branch_empty=
force=
reference=
cached=
@@ -257,6 +259,12 @@ cmd_add()
branch=$2
shift
;;
+ -r | --record)
+ record_branch_empty=true
+ ;;
+ -r=* | --record=*)
+ record_branch="${1#*=}"
+ ;;
-f | --force)
force=$1
;;
@@ -328,6 +336,11 @@ cmd_add()
git ls-files --error-unmatch "$sm_path" > /dev/null 2>&1 &&
die "$(eval_gettext "'\$sm_path' already exists in the index")"
+ if test -z "$record_branch" && test "$record_branch_empty" = "true"
+ then
+ record_branch="${branch:=HEAD}"
+ fi
+
if test -z "$force" && ! git add --dry-run --ignore-missing "$sm_path"
> /dev/null 2>&1
then
eval_gettextln "The following path is ignored by one of your
.gitignore files:
@@ -366,6 +379,10 @@ Use -f if you really want to add it." >&2
git config -f .gitmodules submodule."$sm_path".path "$sm_path" &&
git config -f .gitmodules submodule."$sm_path".url "$repo" &&
+ if test -n "$branch"
+ then
+ git config -f .gitmodules submodule."$sm_path".branch
"$record_branch"
+ fi &&
git add --force .gitmodules ||
die "$(eval_gettext "Failed to register submodule '\$sm_path'")"
}
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 5397037..88ae74c 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -133,6 +133,7 @@ test_expect_success 'submodule
