From: Earnie B. <ea...@us...> - 2012-07-25 15:50:51
|
I've taken the liberty of turning on Git for our project. CVS will eventually go away, it isn't offered to any new projects, I haven't learned Mercurial, and I use git with other projects. Anyone have any huge heartaches about Git? I will begin to store some source in it by this time tomorrow. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Earnie B. <ea...@us...> - 2012-07-25 15:51:03
|
I've taken the liberty of turning on Git for our project. CVS will eventually go away, it isn't offered to any new projects, I haven't learned Mercurial, and I use git with other projects. Anyone have any huge heartaches about Git? I will begin to store some source in it by this time tomorrow. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Earnie B. <ea...@us...> - 2012-07-25 19:19:13
|
On Wed, Jul 25, 2012 at 11:50 AM, Earnie Boydwrote: > I've taken the liberty of turning on Git for our project. CVS will > eventually go away, it isn't offered to any new projects, I haven't > learned Mercurial, and I use git with other projects. Anyone have any > huge heartaches about Git? I will begin to store some source in it by > this time tomorrow. > I've just discovered how to store multiple repositories so when I convert the CVS data I can take each top level CVS directory and make it a separate Git repository so we don't have to deal with the whole enchilada at once. Should we ignore any of the top level directories? Obviously the obsoleted runtime and w32api ones but anything else? -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Cesar S. <ces...@gm...> - 2012-07-27 01:06:04
|
On 07/25/2012 04:19 PM, Earnie Boyd wrote: > I've just discovered how to store multiple repositories so when I > convert the CVS data I can take each top level CVS directory and make > it a separate Git repository so we don't have to deal with the whole > enchilada at once. Should we ignore any of the top level directories? > Obviously the obsoleted runtime and w32api ones but anything else? > I suggest splitting the msys directory into two separate repositories: msys/rt/src -> msys-runtime msys/dvlpr -> msys-base-files msys/packages is no longer useful, I think. msys/doc seems to be empty. Regards, Cesar |
From: Earnie B. <ea...@us...> - 2012-07-27 17:33:41
|
On Thu, Jul 26, 2012 at 9:05 PM, Cesar Strauss wrote: > On 07/25/2012 04:19 PM, Earnie Boyd wrote: > >> I've just discovered how to store multiple repositories so when I >> convert the CVS data I can take each top level CVS directory and make >> it a separate Git repository so we don't have to deal with the whole >> enchilada at once. Should we ignore any of the top level directories? >> Obviously the obsoleted runtime and w32api ones but anything else? >> > > I suggest splitting the msys directory into two separate repositories: > > msys/rt/src -> msys-runtime > msys/dvlpr -> msys-base-files I called it msys-dvlpr but I can rename it if you want (or you can). This one is done, I'll do the runtime by the end of Monday. I had to get the tools to do the conversion installed. > > msys/packages is no longer useful, I think. Come of them contain localized changes. I'll do it last if I do it at all. > msys/doc seems to be empty. Didn't I have the rtf files in it at one time? I don't remember. I write up a procedure for how to do the conversion. The repositories are stored in the shell at /home/scm_git/m/mi/mingw so renaming it is just a simple mv command. However, renaming is discouraged once people being pulling the data as it will cause them a WTF moment. To create a new repository you simply do the following. cd /home/scm_git/m/mi/mingw mkdir NEWREPO cd NEWREPO git init --bare We should come up with some common hooks to copy to the hooks directory. I need to add some to the mingw-dvlpr repo. We can add pre-receive to control $USER write access and post-receive to send email to mingw-cvs. I'll work on these before doing the msys-runtime repository and store them in the mingw/ repository. We can then git clone it from the mingw/ repository as needed. But I'll have to play with it to make sure. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Earnie B. <ea...@us...> - 2012-07-27 20:41:04
|
On Fri, Jul 27, 2012 at 1:33 PM, Earnie Boyd wrote: > To create a new repository you simply do the following. > > cd /home/scm_git/m/mi/mingw Actually /home/scm_git/mingw works as well. They've begun to do away with m/mi/mingw style directories but still exists for the legacy. > mkdir NEWREPO > cd NEWREPO > git init --bare > On the email notification for the push I've set the mailing list to mingw-cvs but should I use mingw-notify instead? Then we can deprecate mingw-cvs? -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Earnie B. <ea...@us...> - 2012-07-28 20:05:26
|
On Fri, Jul 27, 2012 at 4:40 PM, Earnie Boyd wrote: > On Fri, Jul 27, 2012 at 1:33 PM, Earnie Boyd wrote: >> To create a new repository you simply do the following. >> >> cd /home/scm_git/m/mi/mingw > > Actually /home/scm_git/mingw works as well. They've begun to do away > with m/mi/mingw style directories but still exists for the legacy. > >> mkdir NEWREPO >> cd NEWREPO >> git init --bare >> > > On the email notification for the push I've set the mailing list to > mingw-cvs but should I use mingw-notify instead? Then we can > deprecate mingw-cvs? The code repository move is completed except for actually removing CVS. I created a historical directory in the repository directory to move some of the repositories to after I converted them to git. There is no public reference to them but you can view the gitweb version if you know the directory path to modify the URI reference. You can also git clone them if you know they exist. That said, I converted all but three items. There was an old scripts repository in CVS which I didn't think worth converting, a home repository that contained some old Attic stuff when we were using SF's web space and the msys/doc directory. If we don't want to maintain any of the other repositories currently visible then we can simply move them to the historical directory. I left mingw-cvs as the list to announce the changes to for all repositories. If we want to change it we can modify the config file in each repository directory. We control who has write to a repository via the hooks/pre-receive script in each repository directory. We control the sending of announcements via the hooks/post-receive script which currently points to a SF supplied common script. Are there other hooks we should consider? http://www.kernel.org/pub/software/scm/git/docs/githooks.html How long should we keep CVS active? I'm thinking at least a couple of months. Should we also modify the avail config file to ensure that no one can write to it? -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Earnie B. <ea...@us...> - 2012-07-29 19:49:37
|
I've documented the process I used to convert CVS to Git at https://sourceforge.net/u/earnie/home/CVS%20to%20Git%20SF%20repository/ in case someone wants to know. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Hin-Tak L. <hin...@ya...> - 2012-07-29 20:29:22
|
--- On Sun, 29/7/12, Earnie Boyd <ea...@us...> wrote: > I've documented the process I used to > convert CVS to Git at > https://sourceforge.net/u/earnie/home/CVS%20to%20Git%20SF%20repository/ > in case someone wants to know. Hmm, I was looking for any clever tips on using git-cvsimport (built in to git) but instead found that you have gone about it totally differently. Is there any reason why you did not use git-cvsimport? |
From: Earnie B. <ea...@us...> - 2012-07-29 20:55:54
|
On Sun, Jul 29, 2012 at 4:29 PM, Hin-Tak Leung <hin...@ya...> wrote: > --- On Sun, 29/7/12, Earnie Boyd <ea...@us...> wrote: > >> I've documented the process I used to >> convert CVS to Git at >> https://sourceforge.net/u/earnie/home/CVS%20to%20Git%20SF%20repository/ >> in case someone wants to know. > > Hmm, I was looking for any clever tips on using git-cvsimport (built in to git) but instead found that you have gone about it totally differently. Is there any reason why you did not use git-cvsimport? I found someone else's tips and didn't know about git-cvsimport. The difference between the someone else's tips and mine is that I packaged it in a script. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Earnie B. <ea...@us...> - 2012-07-29 21:00:47
|
On Sun, Jul 29, 2012 at 3:49 PM, Earnie Boyd wrote: > I've documented the process I used to convert CVS to Git at > https://sourceforge.net/u/earnie/home/CVS%20to%20Git%20SF%20repository/ > in case someone wants to know. A todo item as a result of this conversion is to update http://www.mingw.org/wiki/Official_CVS_Repository if someone wants to do it. The URI and title should change as well to become Official_Repository and we need to look for backlinks using it. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Keith M. <kei...@us...> - 2012-07-30 21:28:35
|
On 29/07/12 20:49, Earnie Boyd wrote: > I've documented the process I used to convert CVS to Git at > https://sourceforge.net/u/earnie/home/CVS%20to%20Git%20SF%20repository/ > in case someone wants to know. I guess you lost the module relationships, which were mapped in CVS; I just did $ hg clone git+ssh://<repo-path>/mingw-get Neither the build-aux nor the m4 modules were pulled. -- Regards, Keith. |
From: Earnie B. <ea...@us...> - 2012-07-31 15:43:40
|
On Mon, Jul 30, 2012 at 5:28 PM, Keith Marshall wrote: > On 29/07/12 20:49, Earnie Boyd wrote: >> I've documented the process I used to convert CVS to Git at >> https://sourceforge.net/u/earnie/home/CVS%20to%20Git%20SF%20repository/ >> in case someone wants to know. > > I guess you lost the module relationships, which were mapped in CVS; I > just did > > $ hg clone git+ssh://<repo-path>/mingw-get > > Neither the build-aux nor the m4 modules were pulled. Yes, I missed it. We need a hooks/post-checkout script that will pull the other files. I'm trying to find examples now. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Hin-Tak L. <hin...@ya...> - 2012-07-31 19:52:51
|
--- On Tue, 31/7/12, Earnie Boyd <ea...@us...> wrote: > On Mon, Jul 30, 2012 at 5:28 PM, > Keith Marshall wrote: > > On 29/07/12 20:49, Earnie Boyd wrote: > >> I've documented the process I used to convert CVS > to Git at > >> https://sourceforge.net/u/earnie/home/CVS%20to%20Git%20SF%20repository/ > >> in case someone wants to know. > > > > I guess you lost the module relationships, which were > mapped in CVS; I > > just did > > > > $ hg clone > git+ssh://<repo-path>/mingw-get > > > > Neither the build-aux nor the m4 modules were pulled. > > Yes, I missed it. We need a hooks/post-checkout script > that will pull > the other files. I'm trying to find examples now. You need to add a .gitsubmodule file, and do 'git submodule add ...', I think? |
From: Earnie B. <ea...@us...> - 2012-07-31 20:07:26
|
On Tue, Jul 31, 2012 at 3:52 PM, Hin-Tak Leung wrote: > > You need to add a .gitsubmodule file, and do 'git submodule add ...', I think? Done already. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Earnie B. <ea...@us...> - 2012-07-31 16:36:04
|
On Tue, Jul 31, 2012 at 11:43 AM, Earnie Boyd wrote: > On Mon, Jul 30, 2012 at 5:28 PM, Keith Marshall wrote: >> On 29/07/12 20:49, Earnie Boyd wrote: >>> I've documented the process I used to convert CVS to Git at >>> https://sourceforge.net/u/earnie/home/CVS%20to%20Git%20SF%20repository/ >>> in case someone wants to know. >> >> I guess you lost the module relationships, which were mapped in CVS; I >> just did >> >> $ hg clone git+ssh://<repo-path>/mingw-get >> >> Neither the build-aux nor the m4 modules were pulled. > > Yes, I missed it. We need a hooks/post-checkout script that will pull > the other files. I'm trying to find examples now. Actually, it is a git submodule which will add the build-aux repository. I'll see if I can use the post-checkout hook to symlink/copy the m4 directory to the top layer. Autoconf doesn't have a way to give it some other directory structure, i.e. telling it were to find build-aux/m4? -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Earnie B. <ea...@us...> - 2012-07-31 16:43:14
|
On Tue, Jul 31, 2012 at 12:35 PM, Earnie Boyd wrote: > On Tue, Jul 31, 2012 at 11:43 AM, Earnie Boyd wrote: >> On Mon, Jul 30, 2012 at 5:28 PM, Keith Marshall wrote: >>> On 29/07/12 20:49, Earnie Boyd wrote: >>>> I've documented the process I used to convert CVS to Git at >>>> https://sourceforge.net/u/earnie/home/CVS%20to%20Git%20SF%20repository/ >>>> in case someone wants to know. >>> >>> I guess you lost the module relationships, which were mapped in CVS; I >>> just did >>> >>> $ hg clone git+ssh://<repo-path>/mingw-get >>> >>> Neither the build-aux nor the m4 modules were pulled. >> >> Yes, I missed it. We need a hooks/post-checkout script that will pull >> the other files. I'm trying to find examples now. > > Actually, it is a git submodule which will add the build-aux > repository. I'll see if I can use the post-checkout hook to > symlink/copy the m4 directory to the top layer. Autoconf doesn't have > a way to give it some other directory structure, i.e. telling it were > to find build-aux/m4? — Macro: AC_CONFIG_MACRO_DIR (dir) Specify dir as the location of additional local Autoconf macros. This macro is intended for use by future versions of commands like autoreconf that trace macro calls. It should be called directly from configure.ac so that tools that install macros for aclocal can find the macros' declarations. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Earnie B. <ea...@us...> - 2012-07-31 17:08:53
|
On Tue, Jul 31, 2012 at 12:43 PM, Earnie Boyd <ea...@us...> wrote: > On Tue, Jul 31, 2012 at 12:35 PM, Earnie Boyd wrote: >> On Tue, Jul 31, 2012 at 11:43 AM, Earnie Boyd wrote: >>> On Mon, Jul 30, 2012 at 5:28 PM, Keith Marshall wrote: >>>> On 29/07/12 20:49, Earnie Boyd wrote: >>>>> I've documented the process I used to convert CVS to Git at >>>>> https://sourceforge.net/u/earnie/home/CVS%20to%20Git%20SF%20repository/ >>>>> in case someone wants to know. >>>> >>>> I guess you lost the module relationships, which were mapped in CVS; I >>>> just did >>>> >>>> $ hg clone git+ssh://<repo-path>/mingw-get >>>> >>>> Neither the build-aux nor the m4 modules were pulled. >>> >>> Yes, I missed it. We need a hooks/post-checkout script that will pull >>> the other files. I'm trying to find examples now. >> >> Actually, it is a git submodule which will add the build-aux >> repository. I'll see if I can use the post-checkout hook to >> symlink/copy the m4 directory to the top layer. Autoconf doesn't have >> a way to give it some other directory structure, i.e. telling it were >> to find build-aux/m4? > > — Macro: AC_CONFIG_MACRO_DIR (dir) > Specify dir as the location of additional local Autoconf macros. This > macro is intended for use by future versions of commands like > autoreconf that trace macro calls. It should be called directly from > configure.ac so that tools that install macros for aclocal can find > the macros' declarations. No, that doesn't work but this change does, ok to commit? diff --git a/aclocal.m4 b/aclocal.m4 index 03f543b..ac2e37b 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -22,7 +22,7 @@ # MinGW Project, accept liability for any damages, however caused, # arising from the use of this software. # -m4_include([m4/missing.m4]) +m4_include([build-aux/m4/missing.m4]) # MINGW_AC_OUTPUT # --------------- -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Earnie B. <ea...@us...> - 2012-07-31 17:34:33
|
On Tue, Jul 31, 2012 at 12:35 PM, Earnie Boyd wrote: > On Tue, Jul 31, 2012 at 11:43 AM, Earnie Boyd wrote: >> On Mon, Jul 30, 2012 at 5:28 PM, Keith Marshall wrote: >>> On 29/07/12 20:49, Earnie Boyd wrote: >>>> I've documented the process I used to convert CVS to Git at >>>> https://sourceforge.net/u/earnie/home/CVS%20to%20Git%20SF%20repository/ >>>> in case someone wants to know. >>> >>> I guess you lost the module relationships, which were mapped in CVS; I >>> just did >>> >>> $ hg clone git+ssh://<repo-path>/mingw-get >>> >>> Neither the build-aux nor the m4 modules were pulled. >> >> Yes, I missed it. We need a hooks/post-checkout script that will pull >> the other files. I'm trying to find examples now. > > Actually, it is a git submodule which will add the build-aux > repository. I'll see if I can use the post-checkout hook to > symlink/copy the m4 directory to the top layer. Autoconf doesn't have > a way to give it some other directory structure, i.e. telling it were > to find build-aux/m4? BTW, I added the build-aux as a submodule but you need a local version of hooks/post-checkout. In my msysgit directory I modified the share/git-core/templates/hooks/ directory to add the post-checkout file. It needs to contain the following in order for the submodule data to be pulled. <file name="share/git-core/templates/hooks/post-checkout"> #!/bin/sh git submodule init git submodule update </file> -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Keith M. <kei...@us...> - 2012-08-02 20:24:31
|
On 31/07/12 18:08, Earnie Boyd wrote: > No, that doesn't work but this change does, ... > > diff --git a/aclocal.m4 b/aclocal.m4 > index 03f543b..ac2e37b 100644 > --- a/aclocal.m4 > +++ b/aclocal.m4 > @@ -22,7 +22,7 @@ > # MinGW Project, accept liability for any damages, however caused, > # arising from the use of this software. > # > -m4_include([m4/missing.m4]) > +m4_include([build-aux/m4/missing.m4]) > > # MINGW_AC_OUTPUT > # --------------- Looks reasonable to me. I used the sibling arrangement when I set it up originally, and testing the module configuration with a local CVS kept it that way; it seems to be pulled differently from SF's remote CVS service. > ok to commit? Please do. -- Regards, Keith. |
From: Earnie B. <ea...@us...> - 2012-08-02 20:42:42
|
On Thu, Aug 2, 2012 at 4:24 PM, Keith Marshall wrote: >> ok to commit? > > Please do. Done. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Keith M. <kei...@us...> - 2012-09-01 13:23:53
|
On 31/07/12 18:34, Earnie Boyd wrote: > On Tue, Jul 31, 2012 at 12:35 PM, Earnie Boyd wrote: >> On Tue, Jul 31, 2012 at 11:43 AM, Earnie Boyd wrote: >>> On Mon, Jul 30, 2012 at 5:28 PM, Keith Marshall wrote: >>>> On 29/07/12 20:49, Earnie Boyd wrote: >>>>> I've documented the process I used to convert CVS to Git at >>>>> https://sourceforge.net/u/earnie/home/CVS%20to%20Git%20SF%20repository/ >>>>> in case someone wants to know. >>>> >>>> I guess you lost the module relationships, which were mapped in CVS; I >>>> just did >>>> >>>> $ hg clone git+ssh://<repo-path>/mingw-get >>>> >>>> Neither the build-aux nor the m4 modules were pulled. >>> >>> Yes, I missed it. We need a hooks/post-checkout script that will pull >>> the other files. I'm trying to find examples now. >> >> Actually, it is a git submodule which will add the build-aux >> repository. I'll see if I can use the post-checkout hook to >> symlink/copy the m4 directory to the top layer. Autoconf doesn't have >> a way to give it some other directory structure, i.e. telling it were >> to find build-aux/m4? > > BTW, I added the build-aux as a submodule Arrrrrrrrgh! git: repulsive by name; repulsive by nature! As a solution, I'm finding this to be utterly unworkable. Did I mention that I utterly detest git? I want to manage mingw-get with Mercurial. I can do that, even though you've set up the git repository, because Mercurial normally just works with git repositories. The problem, in this case, is that submodule specification: I cannot push to git://mingw.git.sourceforge.net/gitroot/mingw/build-aux I need to push to git+ssh://me...@mi.../gitroot/mingw/build-aux but it's inappropriate to specify that within a file committed to the repository, (as a submodule reference must be); hence, any push aborts before anything is committed, (because Mercurial pushes submodules first). > but you need a local version > of hooks/post-checkout. In my msysgit directory I modified the > share/git-core/templates/hooks/ directory to add the post-checkout > file. It needs to contain the following in order for the submodule > data to be pulled. > > <file name="share/git-core/templates/hooks/post-checkout"> > #!/bin/sh > git submodule init > git submodule update > </file> This differs from the recommendation within git's documentation, (which advises that these commands simply be executed manually following a clone of a repository with submodules, and requires that the second of the pair be repeated following each subsequent pull). Furthermore, I discovered on cloning the parent, (using git clone), that executing these commands *didn't* pull the submodule, because the repository itself had lost the submodule reference, even though the .gitmodules file remained in place. I can only conclude that submodule support in git is flaky, at best. Mercurial *does* support submodules, (or subrepositories), and IME the feature does work well when there is no ssh authentication involved; (but breaks when ssh authentication is required to push to the subrepository, because the .hgsub file must be committed to the repository, and must specify the host repository path, including the ssh identification info, which means only one user can ever commit). Mercurial's support for subrepositories is fully documented, but it includes a recommendation that there is usually a better way to manage the requirement. In the case of mingw-get, I think it will be better to manage the build-aux repository independently, as an embedded checkout ignored by mingw-get itself, (but required for a working environment); requiring users to check it out manually is certainly no more troublesome that the shenanigans required in git, to support and maintain the submodule reference, and it will certainly create fewer hassles for pushing commits back to the origin repository. I propose reverting this failed experiment, in the mingw-get repo. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2012-09-01 18:23:15
|
On 9/1/2012 9:23 AM, Keith Marshall wrote: > I propose reverting this failed experiment, in the mingw-get repo. I don't care what VCS you use, submodules never work as expected. Hate 'em, hate 'em, hate 'em. IMO, the scripts in a project's build-aux are either (a) imported at autoreconf time by the user before building or (b) checked in to the dadgum repo as a first-class member of the project. Don't rely on a separate repo -- perhaps managed by some other person or team -- for something so fundamental to your own project's build. If the scripts are maintained elsewhere, check in the versions you need and have verified to work, and explicitly update as needed. My 2c. -- Chuck |
From: Hin-Tak L. <hin...@ya...> - 2012-09-04 07:59:10
|
--- On Sat, 1/9/12, Keith Marshall <kei...@us...> wrote: <snipped> > > BTW, I added the build-aux as a submodule > > Arrrrrrrrgh! git: repulsive by name; repulsive by > nature! As a > solution, I'm finding this to be utterly unworkable. > Did I mention that > I utterly detest git? I want to manage mingw-get with > Mercurial. I can > do that, even though you've set up the git repository, > because Mercurial > normally just works with git repositories. The > problem, in this case, > is that submodule specification: I cannot push to > > git://mingw.git.sourceforge.net/gitroot/mingw/build-aux > > I need to push to > > git+ssh://me...@mi.../gitroot/mingw/build-aux > > but it's inappropriate to specify that within a file > committed to the > repository, (as a submodule reference must be); hence, any > push aborts > before anything is committed, (because Mercurial pushes > submodules first). <snipped> I don't want to get into a 'git vs mercurial' flame war. Anyway, as far as I know, in a git workflow, the head commit of a submodule is recorded in the commit of the parent. This means it is possible to have a private commit of the parent referring to a private commit of a submodule (i.e. neither of them available in upstream). In normal usage of git, one would also push the submodule's private commit first, then push the parent's private commit; otherwise the public repository of the parent would end up having references referring to not-yet-public commits of a submodule, at least for a short moment of time. Whether that is happening automatically (i.e. git pushes private commits of submodule's first before pushing a parent), or git simply quits, saying you should push submodule first, I am not sure. OTOH IMHO, I wouldn't want git to do that automatically for me - submodules are there mainly in a read-only capacity, and they are meant to be separate components. If I have to make changes to a submodule, due to changing requirements of the parent, I would prefer those changes fed back in a deliberate and controlled manner, not automatically. Otherwise there is no point in having something as a separate module, if they are so strongly coupled. |
From: Earnie B. <ea...@us...> - 2012-09-01 17:08:25
|
On Sat, Sep 1, 2012 at 9:23 AM, Keith Marshall wrote: > On 31/07/12 18:34, Earnie Boyd wrote: >> On Tue, Jul 31, 2012 at 12:35 PM, Earnie Boyd wrote: >>> On Tue, Jul 31, 2012 at 11:43 AM, Earnie Boyd wrote: >>>> On Mon, Jul 30, 2012 at 5:28 PM, Keith Marshall wrote: >>>>> On 29/07/12 20:49, Earnie Boyd wrote: >>>>>> I've documented the process I used to convert CVS to Git at >>>>>> https://sourceforge.net/u/earnie/home/CVS%20to%20Git%20SF%20repository/ >>>>>> in case someone wants to know. >>>>> >>>>> I guess you lost the module relationships, which were mapped in CVS; I >>>>> just did >>>>> >>>>> $ hg clone git+ssh://<repo-path>/mingw-get >>>>> >>>>> Neither the build-aux nor the m4 modules were pulled. >>>> >>>> Yes, I missed it. We need a hooks/post-checkout script that will pull >>>> the other files. I'm trying to find examples now. >>> >>> Actually, it is a git submodule which will add the build-aux >>> repository. I'll see if I can use the post-checkout hook to >>> symlink/copy the m4 directory to the top layer. Autoconf doesn't have >>> a way to give it some other directory structure, i.e. telling it were >>> to find build-aux/m4? >> >> BTW, I added the build-aux as a submodule > > Arrrrrrrrgh! git: repulsive by name; repulsive by nature! As a > solution, I'm finding this to be utterly unworkable. Did I mention that > I utterly detest git? I want to manage mingw-get with Mercurial. I can > do that, even though you've set up the git repository, because Mercurial > normally just works with git repositories. The problem, in this case, > is that submodule specification: I cannot push to > > git://mingw.git.sourceforge.net/gitroot/mingw/build-aux > > I need to push to > > git+ssh://me...@mi.../gitroot/mingw/build-aux > > but it's inappropriate to specify that within a file committed to the > repository, (as a submodule reference must be); hence, any push aborts > before anything is committed, (because Mercurial pushes submodules first). > Can't you configure Mercurial to not push the submodule? The writable changes to build-aux requires you clone it into a separate repository. >> but you need a local version >> of hooks/post-checkout. In my msysgit directory I modified the >> share/git-core/templates/hooks/ directory to add the post-checkout >> file. It needs to contain the following in order for the submodule >> data to be pulled. >> >> <file name="share/git-core/templates/hooks/post-checkout"> >> #!/bin/sh >> git submodule init >> git submodule update >> </file> > > This differs from the recommendation within git's documentation, (which > advises that these commands simply be executed manually following a > clone of a repository with submodules, and requires that the second of > the pair be repeated following each subsequent pull). Furthermore, I > discovered on cloning the parent, (using git clone), that executing > these commands *didn't* pull the submodule, because the repository > itself had lost the submodule reference, even though the .gitmodules > file remained in place. I can only conclude that submodule support in > git is flaky, at best. > Uhm, I found the idea by real use users and I tested it. I pulled the repository into my /usr/local/src on my linux VM and issued the two commands with the correct results. > Mercurial *does* support submodules, (or subrepositories), and IME the > feature does work well when there is no ssh authentication involved; > (but breaks when ssh authentication is required to push to the > subrepository, because the .hgsub file must be committed to the > repository, and must specify the host repository path, including the ssh > identification info, which means only one user can ever commit). > Yes, we don't want to do that. > Mercurial's support for subrepositories is fully documented, but it > includes a recommendation that there is usually a better way to manage > the requirement. In the case of mingw-get, I think it will be better to > manage the build-aux repository independently, as an embedded checkout > ignored by mingw-get itself, (but required for a working environment); And we could do this too. > requiring users to check it out manually is certainly no more > troublesome that the shenanigans required in git, to support and > maintain the submodule reference, and it will certainly create fewer > hassles for pushing commits back to the origin repository. > > I propose reverting this failed experiment, in the mingw-get repo. That is fine for me. We just need to document the process for developers to use. It will be interesting to see how Cygwin manages it when it goes git. -- Earnie -- https://sites.google.com/site/earnieboyd |