[git] How the blazes are you supposed to update all the submodules?
OK.... so I do a Git pull at the top level (note: using TortoiseGit), and I see lots of messages in the log indicating which libraries have updates, and judging by the time taken they seem to be downloaded (?), but I don't actually see any changes in the libraries themselves. BTW I have every library set explicitly to either "develop" or "master". If I do a "git pull" on an individual library then the changes do come through OK. So what's the right way to do this? I assume it's not a "submodule update" as that seems to leave everything in a detached head state which I take it is a bad idea? I'm also seeing a lot of negative comments about Git submodules on the web, for example: http://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt..., seems like there's a lot of potential to shoot yourself in the foot/head/chest here? Thanks, John.
On Thu, Dec 19, 2013 at 5:00 PM, John Maddock <john@johnmaddock.co.uk> wrote:
OK.... so I do a
Git pull
at the top level (note: using TortoiseGit), and I see lots of messages in the log indicating which libraries have updates, and judging by the time taken they seem to be downloaded (?), but I don't actually see any changes in the libraries themselves.
BTW I have every library set explicitly to either "develop" or "master".
If I do a "git pull" on an individual library then the changes do come through OK.
So what's the right way to do this?
When you pull the superproject, it only checks out the submodules at the specific revision that, I believe, is updated manually now by someone with the write access to the superproject. If you want to checkout the latest revisions of the develop or master branches of all submodules, you can use git submodule foreach, e.g.: git submodule foreach git checkout master git submodule foreach git pull
On 19 December 2013 13:26, Andrey Semashev <andrey.semashev@gmail.com> wrote:
When you pull the superproject, it only checks out the submodules at the specific revision that, I believe, is updated manually now by someone with the write access to the superproject.
I have a script which updates it, but I'm running it manually as it's not quite ready to be a cron job. If it's not too much for the server it should be updating automatically soon.
When you pull the superproject, it only checks out the submodules at the specific revision that, I believe, is updated manually now by someone with the write access to the superproject. I have a script which updates it, but I'm running it manually as it's not quite ready to be a cron job. If it's not too much for the server it should be updating automatically soon. May be, it is better to use github's service hooks instead of cron to initiate
On 19.12.2013 17:32, Daniel James wrote: the update? https://help.github.com/articles/post-receive-hooks -- Sergey Cheban
On 19 December 2013 14:11, Sergey Cheban <s.cheban@drweb.com> wrote:
On 19.12.2013 17:32, Daniel James wrote:
When you pull the superproject, it only checks out the submodules at the specific revision that, I believe, is updated manually now by someone with the write access to the superproject.
I have a script which updates it, but I'm running it manually as it's not quite ready to be a cron job. If it's not too much for the server it should be updating automatically soon.
May be, it is better to use github's service hooks instead of cron to initiate the update?
Maybe, but it would introduce concurrency issues (if two modules are pushed to in quick succession). If I get it working in a cron job, I can think about hooks later. FWIW I am using a hook to update the website.
On Thu, Dec 19, 2013 at 7:25 AM, Daniel James <daniel@calamity.org.uk>wrote:
On 19 December 2013 14:11, Sergey Cheban <s.cheban@drweb.com> wrote:
On 19.12.2013 17:32, Daniel James wrote:
When you pull the superproject, it only checks out the submodules at the specific revision that, I believe, is updated manually now by someone with the write access to the superproject.
I have a script which updates it, but I'm running it manually as it's not quite ready to be a cron job. If it's not too much for the server it should be updating automatically soon.
May be, it is better to use github's service hooks instead of cron to initiate the update?
Maybe, but it would introduce concurrency issues (if two modules are pushed to in quick succession). If I get it working in a cron job, I can think about hooks later. FWIW I am using a hook to update the website.
Once you have more than one git repository (superproject and submodules), by definition, you *will* have concurrency issues no matter how you do it. It's just the size of the window of vulnerability you can try to minimize. Michael
On 20 December 2013 00:39, Cox, Michael <mhcox@bluezoosoftware.com> wrote:
On Thu, Dec 19, 2013 at 7:25 AM, Daniel James <daniel@calamity.org.uk>wrote:
Maybe, but it would introduce concurrency issues (if two modules are pushed to in quick succession). If I get it working in a cron job, I can think about hooks later. FWIW I am using a hook to update the website.
Once you have more than one git repository (superproject and submodules), by definition, you *will* have concurrency issues no matter how you do it. It's just the size of the window of vulnerability you can try to minimize.
Guess why I'm cautious about running the script automatically. Anyway, I can linearise updates to submodules using the github events api. Which means I only have to deal with concurrent updates of the superproject which is an easier problem. What's tricky is dealing with concurrent changes to local state. There are obviously strategies to deal with that but if I can guarantee that there's a reasonable gap between each run of the script life is easier. It also means I don't have to maintain over 100 hooks.
On 19 December 2013 13:00, John Maddock <john@johnmaddock.co.uk> wrote:
BTW I have every library set explicitly to either "develop" or "master".
IMO for libraries that you're not working on the best thing is to use whatever the superproject uses and not bother with branches. We might set the submodules to a different commit for some reason, so you could end up developing against the wrong version of a module.
If I do a "git pull" on an individual library then the changes do come through OK.
So what's the right way to do this? I assume it's not a "submodule update" as that seems to leave everything in a detached head state which I take it is a bad idea?
I know some people are using something like 'git submodule foreach git pull' to pull every repo. I'm not very keen on that, so my current thinking is to configure modules I'm working on as 'dirty' so that submodule will ignore them. I haven't had any time to try that yet as I'm doing infrastructure things at the moment.
I'm also seeing a lot of negative comments about Git submodules on the web, for example: http://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt..., seems like there's a lot of potential to shoot yourself in the foot/head/chest here?
I believe the plan was to eventually transition to a package manage system. Although I don't think that's going to happen any time soon.
BTW I have every library set explicitly to either "develop" or "master".
IMO for libraries that you're not working on the best thing is to use whatever the superproject uses and not bother with branches. We might set the submodules to a different commit for some reason, so you could end up developing against the wrong version of a module.
OK, in other words basically ignore the issue? The danger of this is breakages - for example Boost.Build has completely stopped working for me because the super-project was updated but the subproject was not. A manual update of the boost.build subproject fixed things, but I suspect not everyone would realize that was what was needed. Whatever I suspect folks (well this one at least!) will need some very clear guidance on this, Thanks, John.
On 12/19/2013 07:40 AM, John Maddock wrote:
BTW I have every library set explicitly to either "develop" or "master".
IMO for libraries that you're not working on the best thing is to use whatever the superproject uses and not bother with branches. We might set the submodules to a different commit for some reason, so you could end up developing against the wrong version of a module.
Although on first glance this feels wrong, it's also what I've come to accept as the right approach. Check out a branch only when you're working in a module. At any point, you can use: git submodule summary to identify the practical differences between your workspace and the superproject configuration.
OK, in other words basically ignore the issue?
Not entirely. I just refreshed after the tools/build update with the two commands: git pull git submodule update all at the top level. Because of the way the submodules are defined, this also pulled all the submodules. The submodule update step is required to change the workspace contents, as documented for --recurse-submodules in git pull --help. These two steps fixed tools/build to have the right thing without any of the manual steps suggested in the "improving the history" thread. Peter
Peter A. Bigot wrote:
git pull git submodule update
That's what I do, too. This puts everything (back) into a detached head, so if I want to do work on, for example, smart_ptr, I have to then manually switch it to "devel" again: cd libs/smart_ptr git checkout devel but it's not that much of a bother, and the whole procedure can in principle be automated with a script.
On 19 December 2013 13:40, John Maddock <john@johnmaddock.co.uk> wrote:
BTW I have every library set explicitly to either "develop" or "master".
IMO for libraries that you're not working on the best thing is to use whatever the superproject uses and not bother with branches. We might set the submodules to a different commit for some reason, so you could end up developing against the wrong version of a module.
OK, in other words basically ignore the issue?
No.
The danger of this is breakages - for example Boost.Build has completely stopped working for me because the super-project was updated but the subproject was not. A manual update of the boost.build subproject fixed things, but I suspect not everyone would realize that was what was needed.
AFAICT both master and develop reference the latest version of build. What do you mean by, "the subproject was not"?
Whatever I suspect folks (well this one at least!) will need some very clear guidance on this,
I can't give you clear guidance because I'm still working these things out.
On 19 December 2013 13:00, John Maddock <john@johnmaddock.co.uk> wrote:
I assume it's not a "submodule update" as that seems to leave everything in a detached head state which I take it is a bad idea?
I'm not going to suggest it is a bad or good idea, but it is certainly how submodules work, yet it is different situation to what was in the SVN repository. A git submodule "always pointed at a particular commit" [1] in external repository. Clearly, this is not equivalent arrangement to SVN trunk which was: @Revision-Z /boost/fusion /boost/spirit and if I look at it, I can be certain I look at the same repository, at the same branch, at the same Boost snapshot. Now, we have @SHA:X /boost/fusion @SHA:Y /boost/spirit where X and Y are commits in different repositories, may be in different branches and Boost snapshot is a union of all @SHA:* linked from boost. The new order requires a kind of a shift in thinking. [1] https://www.kernel.org/pub/software/scm/git/docs/git-submodule.html Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net
On 12/19/2013 8:00 AM, John Maddock wrote:
OK.... so I do a
Git pull
at the top level (note: using TortoiseGit), and I see lots of messages in the log indicating which libraries have updates, and judging by the time taken they seem to be downloaded (?), but I don't actually see any changes in the libraries themselves.
What are reasons for ever 'pulling' the superproject ?
On 12/19/2013 09:05 AM, Edward Diener wrote:
On 12/19/2013 8:00 AM, John Maddock wrote:
OK.... so I do a
Git pull
at the top level (note: using TortoiseGit), and I see lots of messages in the log indicating which libraries have updates, and judging by the time taken they seem to be downloaded (?), but I don't actually see any changes in the libraries themselves.
What are reasons for ever 'pulling' the superproject ?
Without trying to find what it's intended to mean for Boost, in normal practice this means: Update to identify the versions of each submodule that are confirmed to interoperate correctly at the head of superproject branch that's being pulled. In other words, the latest successful results of integration testing. "git submodule update" is subsequently required to actually change the contents of the submodule working spaces to contain those versions. It's probably a separate step because that makes it easier to deal with conflicts in specific submodules that were locally modified. Peter
On 12/19/2013 10:27 AM, Peter A. Bigot wrote:
On 12/19/2013 09:05 AM, Edward Diener wrote:
On 12/19/2013 8:00 AM, John Maddock wrote:
OK.... so I do a
Git pull
at the top level (note: using TortoiseGit), and I see lots of messages in the log indicating which libraries have updates, and judging by the time taken they seem to be downloaded (?), but I don't actually see any changes in the libraries themselves.
What are reasons for ever 'pulling' the superproject ?
Without trying to find what it's intended to mean for Boost, in normal practice this means: Update to identify the versions of each submodule that are confirmed to interoperate correctly at the head of superproject branch that's being pulled.
In other words, the latest successful results of integration testing.
"git submodule update" is subsequently required to actually change the contents of the submodule working spaces to contain those versions. It's probably a separate step because that makes it easier to deal with conflicts in specific submodules that were locally modified.
I assume "git submodule update" is done at the superproject level. But as other have said, this puts everything back into detached state so that one needs to checkout whatever branches one was working on before again. Ugh !
"git submodule update" is subsequently required to actually change the contents of the submodule working spaces to contain those versions. It's probably a separate step because that makes it easier to deal with conflicts in specific submodules that were locally modified.
I assume "git submodule update" is done at the superproject level. But as other have said, this puts everything back into detached state so that one needs to checkout whatever branches one was working on before again. Ugh !
Ugh indeed. What happens to uncommitted changes in that case? John.
On 12/19/2013 05:55 PM, John Maddock wrote:
"git submodule update" is subsequently required to actually change the contents of the submodule working spaces to contain those versions. It's probably a separate step because that makes it easier to deal with conflicts in specific submodules that were locally modified.
I assume "git submodule update" is done at the superproject level. But as other have said, this puts everything back into detached state so that one needs to checkout whatever branches one was working on before again. Ugh !
Ugh indeed.
What happens to uncommitted changes in that case?
I don't think there is reason to worry. Git is very cautious not to loose data for you. -- Bjørn
On Thu, 19 Dec 2013 08:42:54 -0800, Edward Diener <eldiener@tropicsoft.com> wrote:
On 12/19/2013 10:27 AM, Peter A. Bigot wrote:
On 12/19/2013 09:05 AM, Edward Diener wrote:
On 12/19/2013 8:00 AM, John Maddock wrote:
OK.... so I do a
Git pull
at the top level (note: using TortoiseGit), and I see lots of messages in the log indicating which libraries have updates, and judging by the time taken they seem to be downloaded (?), but I don't actually see any changes in the libraries themselves.
What are reasons for ever 'pulling' the superproject ?
Without trying to find what it's intended to mean for Boost, in normal practice this means: Update to identify the versions of each submodule that are confirmed to interoperate correctly at the head of superproject branch that's being pulled.
In other words, the latest successful results of integration testing.
"git submodule update" is subsequently required to actually change the contents of the submodule working spaces to contain those versions. It's probably a separate step because that makes it easier to deal with conflicts in specific submodules that were locally modified.
I assume "git submodule update" is done at the superproject level. But as other have said, this puts everything back into detached state so that one needs to checkout whatever branches one was working on before again. Ugh !
I don't know if this might help, but this was mentioned before on this list: http://www.vogella.com/articles/Git/article.html#submodules "41.4. Tracking branches with submodules Since tracking of branches is a very common requirement, Git added the option to track a certain branch in its 1.8.2 release. ..." As opposed to "41.3. Tracking commits".
I don't know if this might help, but this was mentioned before on this list: Since tracking of branches is a very common requirement, Git added the option to track a certain branch in its 1.8.2 release. ..." I think that this is appropriate for the develop branch but not for the branch
On 19.12.2013 23:29, Mostafa wrote: that contains the final releases (including beta releases). -- Sergey Cheban
On 12/19/2013 05:42 PM, Edward Diener wrote:
On 12/19/2013 10:27 AM, Peter A. Bigot wrote:
On 12/19/2013 09:05 AM, Edward Diener wrote:
On 12/19/2013 8:00 AM, John Maddock wrote:
OK.... so I do a
Git pull
at the top level (note: using TortoiseGit), and I see lots of messages in the log indicating which libraries have updates, and judging by the time taken they seem to be downloaded (?), but I don't actually see any changes in the libraries themselves.
What are reasons for ever 'pulling' the superproject ?
Without trying to find what it's intended to mean for Boost, in normal practice this means: Update to identify the versions of each submodule that are confirmed to interoperate correctly at the head of superproject branch that's being pulled.
In other words, the latest successful results of integration testing.
"git submodule update" is subsequently required to actually change the contents of the submodule working spaces to contain those versions. It's probably a separate step because that makes it easier to deal with conflicts in specific submodules that were locally modified.
I assume "git submodule update" is done at the superproject level. But as other have said, this puts everything back into detached state so that one needs to checkout whatever branches one was working on before again. Ugh !
This can be automated in a number of ways, including use of git built in features such as: $git submodule update --rebase --rebase This option is only valid for the update command. Rebase the current branch onto the commit recorded in the superproject. If this option is given, the submodule’s HEAD will not be detached. If a merge failure prevents this process, you will have to resolve these failures with git-rebase(1). If the key submodule.$name.update is set to rebase, this option is implicit. -- Bjørn
On 12/19/2013 02:00 PM, John Maddock wrote:
OK.... so I do a
Git pull
at the top level (note: using TortoiseGit), and I see lots of messages in the log indicating which libraries have updates, and judging by the time taken they seem to be downloaded (?), but I don't actually see any changes in the libraries themselves.
BTW I have every library set explicitly to either "develop" or "master".
If I do a "git pull" on an individual library then the changes do come through OK.
So what's the right way to do this? I assume it's not a "submodule update" as that seems to leave everything in a detached head state which I take it is a bad idea?
I'm also seeing a lot of negative comments about Git submodules on the web, for example: http://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt..., seems like there's a lot of potential to shoot yourself in the foot/head/chest here?
I don't think it is hard to agree that git submodule it not a perfect tool, but which available alternative is perfect? I have the feeling it is because it is not as simple of a problem as it seems at first and it has taken a long time for the tools to mature to current level. Hopefully there are still potential for improvements. I have seen naive attempts to do what submodule attempts to do, "the right way", that has failed completely in improving the overall situation. Champions of such attempts often get too much invested interest in their solution to admit its failure. If I should suggest something it would be to use submodules but provide firm guidelines and/or scripts help the developers with simple ways to do it right and avoid the pitfalls. -- Bjørn
On Dec 19, 2013 3:01 PM, "Bjørn Roald" <bjorn@4roald.org> wrote:
On 12/19/2013 02:00 PM, John Maddock wrote:
OK.... so I do a
Git pull
at the top level (note: using TortoiseGit), and I see lots of messages in the log indicating which libraries have updates, and judging by the time taken they seem to be downloaded (?), but I don't actually see any changes in the libraries themselves.
BTW I have every library set explicitly to either "develop" or "master".
If I do a "git pull" on an individual library then the changes do come through OK.
So what's the right way to do this? I assume it's not a "submodule update" as that seems to leave everything in a detached head state which I take it is a bad idea?
I'm also seeing a lot of negative comments about Git submodules on the web, for example:
http://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt... ,
seems like there's a lot of potential to shoot yourself in the foot/head/chest here?
I don't think it is hard to agree that git submodule it not a perfect tool, but which available alternative is perfect?
I have the feeling it is because it is not as simple of a problem as it seems at first and it has taken a long time for the tools to mature to current level. Hopefully there are still potential for improvements.
I have seen naive attempts to do what submodule attempts to do, "the right way", that has failed completely in improving the overall situation. Champions of such attempts often get too much invested interest in their solution to admit its failure. If I should suggest something it would be to use submodules but provide firm guidelines and/or scripts help the developers with simple ways to do it right and avoid the pitfalls.
No amount of scripting is going yo help those of us not wanting to use the git cli. And this is something I mentioned early on. If something past basic git functionality is needed as a regular course of use the move to git will fail. I saw an article some time ago about a git feature that should be used instead of sub modules.. but I can't find it right now. Perhaps someone can find that alternative arrangement? Rene.
No amount of scripting is going yo help those of us not wanting to use the git cli. And this is something I mentioned early on. If something past basic git functionality is needed as a regular course of use the move to git will fail.
I saw an article some time ago about a git feature that should be used instead of sub modules.. but I can't find it right now. Perhaps someone can find that alternative arrangement?
There are git subtrees: http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree... I don't have any experience using them.
On 12/19/2013 11:14 PM, Rene Rivera wrote:
No amount of scripting is going yo help those of us not wanting to use the git cli. And this is something I mentioned early on. If something past basic git functionality is needed as a regular course of use the move to git will fail.
You have point, however I am not sure the GUI you choose know nothing of how to help you use submodule and avoid its pitfalls, In any case, since only a few will have to do commits in the super project that changes submodule commits, and that may even be more or less completely automated, I am not sure these advertised problems with submodules will actually manifest themselves in Boost.
I saw an article some time ago about a git feature that should be used instead of sub modules.. but I can't find it right now. Perhaps someone can find that alternative arrangement?
There was some talk on the list on git subtree which are now standard command in git, but I doubt it is a good alternative for Boost. -- Bjørn
On Thu, Dec 19, 2013 at 4:32 PM, Bjørn Roald <bjorn@4roald.org> wrote:
On 12/19/2013 11:14 PM, Rene Rivera wrote:
No amount of scripting is going yo help those of us not wanting to use the git cli. And this is something I mentioned early on. If something past basic git functionality is needed as a regular course of use the move to git will fail.
You have point, however I am not sure the GUI you choose know nothing of how to help you use submodule and avoid its pitfalls, In any case, since only a few will have to do commits in the super project that changes submodule commits, and that may even be more or less completely automated, I am not sure these advertised problems with submodules will actually manifest themselves in Boost.
I'm one of those that has to do commits to the super project :-\ As for the GUI.. Currently my preferred choice is Eclipse. And it fails at step #0. After asking twice on this list for help, I eventually figured out it is confused as to how the submodules are specified in the Boost superproject and refused to "init" the submodules (which I eventually had to do by hand/cli). In the git.py module I wrote for testing I deal with submodules for fetching mostly correctly.. But even it doesn't work for fetching Boost as the content itself confuses it into throwing exceptions. So now I'm faced with writing a wrapper around the git cli for testing.. And feeling like I don't have any idea what the proper way to fetch the correct stuff from github is. But I'll post about that in another thread. But git is what the community chose.. So I'll just have to deal with it :-\ -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On 20 December 2013 03:15, Rene Rivera <grafikrobot@gmail.com> wrote:
In the git.py module I wrote for testing I deal with submodules for fetching mostly correctly.. But even it doesn't work for fetching Boost as the content itself confuses it into throwing exceptions. So now I'm faced with writing a wrapper around the git cli for testing.. And feeling like I don't have any idea what the proper way to fetch the correct stuff from github is. But I'll post about that in another thread.
Wrapping the cli is probably the best strategy, other implementations never quite seem to match it. FWIW here's the script I quickly wrote to mirror the repos for the documentation build: https://github.com/danieljames/boost-build-docs/blob/master/git-mirror.py
[sidenote about guis] I've used TortoiseGit for some time but I don't like the fact that they keep trying to emulate TortoiseSVN. TortoiseHg does it (for mercurial) in a better way by just keeping the basic principles of TortoiseSVN but not keeping the SVN-induced interface of TortoiseSVN. It means that the best way to work with DSVC is often to have a separate interface to see the overall tree of commits and other repository informations, so they provide a "workbench". These days I only use SourceTree for both git and hg. It's cross platform, it's almost as useful as the TortoiseHg workbench and it manage as many repositories (and subrepos) as you want in only one interface. Other pros: it allowed me to understand git flow better, it provides pre-configured terminal in the context of a repository so that you can do recipes the hard way if you want, and it can (if you chose to do it this way) use an embedded hg/git version instead of the one installed on the OS. Cons: it's often slow to respond, but last versions have been improved a lot on this side. I also have some issues with some details of the ergonomy but from exchanges with the devs, I apparently have an alien way of using some of the features. Basically, if TortoiseGit don't feels right and you don't want to use command line all the time, I suggest trying SourceTree. I have the boost repo in SourceTree right now, but didn't tried forking etc. yet, so I have no idea if it will manage the load manipulating 150+ submodules. I'm studying/trying other tools too for use in cross-plateform contexts, so if you have other suggestiions of tools, I'm interested. [/sidenote]
On 12/20/2013 6:15 AM, Klaim - Joël Lamotte wrote:
[sidenote about guis] I've used TortoiseGit for some time but I don't like the fact that they keep trying to emulate TortoiseSVN. TortoiseHg does it (for mercurial) in a better way by just keeping the basic principles of TortoiseSVN but not keeping the SVN-induced interface of TortoiseSVN. It means that the best way to work with DSVC is often to have a separate interface to see the overall tree of commits and other repository informations, so they provide a "workbench".
These days I only use SourceTree for both git and hg. It's cross platform, it's almost as useful as the TortoiseHg workbench and it manage as many repositories (and subrepos) as you want in only one interface.
According to what I see it does not run on Linux. But it looks like a pretty nice Windows alternative.
Other pros: it allowed me to understand git flow better, it provides pre-configured terminal in the context of a repository so that you can do recipes the hard way if you want, and it can (if you chose to do it this way) use an embedded hg/git version instead of the one installed on the OS. Cons: it's often slow to respond, but last versions have been improved a lot on this side. I also have some issues with some details of the ergonomy but from exchanges with the devs, I apparently have an alien way of using some of the features.
Basically, if TortoiseGit don't feels right and you don't want to use command line all the time, I suggest trying SourceTree. I have the boost repo in SourceTree right now, but didn't tried forking etc. yet, so I have no idea if it will manage the load manipulating 150+ submodules.
I'm studying/trying other tools too for use in cross-plateform contexts, so if you have other suggestiions of tools, I'm interested.
There is also SmartGit ( http://www.syntevo.com/smartgithg ), which is free for non-commercial use. I think TortoiseGit works pretty well myself but it is a bit under-documented, with many GUI screens not providing an explanation of all the options. Also their online Google group forum is not nearly as active as the TortoiseSVN one.
[/sidenote]
On Fri, Dec 20, 2013 at 3:21 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
According to what I see it does not run on Linux. But it looks like a pretty nice Windows alternative.
Indeed, I tend to forget about that. There is also SmartGit ( http://www.syntevo.com/smartgithg ), which is free
for non-commercial use.
Didn't know this one, thanks, noted for review.
On Thu, Dec 19, 2013 at 5:14 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
No amount of scripting is going yo help those of us not wanting to use the git cli. And this is something I mentioned early on. If something past basic git functionality is needed as a regular course of use the move to git will fail.
TortoiseGit seems to work well in a submodule environment, although I've only used the "git submodule ..." equivalents a few times. I don't have any experience with the other Git GUI's, so can't speak for them. --Beman
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: Saturday, December 21, 2013 2:48 AM To: Boost Developers List Subject: Re: [boost] [git] How the blazes are you supposed to update all the submodules?
On Thu, Dec 19, 2013 at 5:14 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
No amount of scripting is going yo help those of us not wanting to use the git cli. And this is something I mentioned early on. If something past basic git functionality is needed as a regular course of use the move to git will fail.
TortoiseGit seems to work well in a submodule environment, although I've only used the "git submodule ..." equivalents a few times. I don't have any experience with the other Git GUI's, so can't speak for them.
As someone who has been hiding his head under a blanket up till now (half hoping it would all go away ;-) I too very, very much trust that it will be possible to do all the routine things using a GUI, and that it will be fully documented using at least one GUI. Tortoise GIT has worked for me locally, so I'd favour using that for a start, but guidance from those with more experience will of course continue be helpful. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On 12/22/2013 11:08 AM, Paul A. Bristow wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: Saturday, December 21, 2013 2:48 AM To: Boost Developers List Subject: Re: [boost] [git] How the blazes are you supposed to update all the submodules?
On Thu, Dec 19, 2013 at 5:14 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
No amount of scripting is going yo help those of us not wanting to use the git cli. And this is something I mentioned early on. If something past basic git functionality is needed as a regular course of use the move to git will fail.
TortoiseGit seems to work well in a submodule environment, although I've only used the "git submodule ..." equivalents a few times. I don't have any experience with the other Git GUI's, so can't speak for them.
As someone who has been hiding his head under a blanket up till now (half hoping it would all go away ;-)
I too very, very much trust that it will be possible to do all the routine things using a GUI, and that it will be fully documented using at least one GUI.
Tortoise GIT has worked for me locally, so I'd favour using that for a start, but guidance from those with more experience will of course continue be helpful.
A number of the Tortoise Git dialogs do not give an explanation in the help for some of the GUI options. This is sometimes supplemented in the help by suggesting that one look at the equivalent git command which the GUI dialog implements, but this is often a PITA if it is difficult to map the GUI option to a particular git command line option. TGIT is very decent and has been getting better with each release but it is not as polished as TSVN. One can always of course drop down to the git command line level. As I get better at git, from reading books and documents, this becomes easier.
On Thu, Dec 19, 2013 at 6:00 AM, John Maddock <john@johnmaddock.co.uk>wrote:
OK.... so I do a
Git pull
at the top level (note: using TortoiseGit), and I see lots of messages in the log indicating which libraries have updates, and judging by the time taken they seem to be downloaded (?), but I don't actually see any changes in the libraries themselves.
This might help Getting Started with Modular Boost Library Maintenance<https://svn.boost.org/trac/boost/wiki/StartModMaint>, although you'll have to translate it to TortoiseGit GUI clicks. As you can tell from this and other threads, there's a lot of debate about what is the best way to use git with Boost, so this link is subject to change. I verified I had the latest TortoiseGit (TG) on my Windows 8 and tried to do what you want to do. I don't know how TG works, but if it knows it's out of date, that probably means it's fetched all the changes into the remote branches, i.e. refs/remotes/origin/*. You just have to figure out how to get those into your working directory.
BTW I have every library set explicitly to either "develop" or "master".
If I do a "git pull" on an individual library then the changes do come through OK.
That should get changes in the refs/remotes/origin/* to refs/heads/* for a particular repository. I don't see how to pull the latest changes from a branch for all submodules in TG. It seems like they haven't implemented the "git submodule foreach" functionality in TG, e.g. the "Git Sync..." menu item dialog seems like it should have a "Recursive" checkbox for all the pull/push/submodule update buttons. I also tried the "TortoiseGit->Submodule Update...", but got an error dialog: Could not get submodule list. An error occurred in libgit2. but no message is available. If you click on OK, you get what looks like the "Submodule Update..." dialog, but it's in a screwy state. The dialog does have a "Recursive" checkbox and a "Remote tracking branch" checkbox that looks promising, but they'll have to fix whatever bug is occurring. So what's the right way to do this? I assume it's not a "submodule update"
as that seems to leave everything in a detached head state which I take it is a bad idea?
I'm also seeing a lot of negative comments about Git submodules on the web, for example: http://codingkilledthecat.wordpress.com/2012/04/28/why- your-company-shouldnt-use-git-submodules/, seems like there's a lot of potential to shoot yourself in the foot/head/chest here?
That's true of git in general :-), although I've never lost any data. Working in your own copy of the git repository frees you to experiment with it. You just have to worry when you push to a shared repository :-). And definitely think twice about using the -f/--force options on some of the git commands. I've learned the hard way that if you think you have to force it, you're probably wrong. You definitely have to grok git, but once you do, you'll never want to go back to Subversion or anything non-distributed. The way it handles branches is truly amazing. Michael
Thanks, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
participants (16)
-
Andrey Semashev -
Beman Dawes -
Bjørn Roald -
Cox, Michael -
Daniel James -
Edward Diener -
Erik Erlandson -
John Maddock -
Klaim - Joël Lamotte -
Mateusz Loskot -
Mostafa -
Paul A. Bristow -
Peter A. Bigot -
Peter Dimov -
Rene Rivera -
Sergey Cheban