On 2/11/15 9:52 AM, Dicebot wrote:
> On Wednesday, 11 February 2015 at 17:23:36 UTC, Jacob Carlborg wrote:
>> On 2015-02-11 17:51, Dicebot wrote:
>>
>>> Small added effort for release manager to update submodules in meta-repo
>>> upon new releases. Can't really imagine anything else right now.
>>
>> You're thinking the meta repository is only update on each release? Or
>> would an automated approach be a good idea?
>
> Yes. Updating it all the time to master creates a lot of noise in
> history for little practical benefit (updating to latest master is one
> command). For matching different repository history Vladimir maintains
> special repo in bitbucket with commits populated by a bot - but it is a
> different thing.

What does "update" mean in this context? I was expecting the projects to be more or less up to date. -- Andrei

On Wednesday, 11 February 2015 at 18:05:56 UTC, Andrei Alexandrescu wrote:
> What does "update" mean in this context? I was expecting the projects to be more or less up to date. -- Andrei

$ git clone --recursive git@github.com:D-Programming-Language/dlang

This will clone all submodules set to latest released version tag (v2.066.1 right now)

$ cd dlang; ./dlang.d update

This will update all submodules to latest git master heads.

git submodules are designed to track exact commit hash of remote repository - it is impossible to define those to always be cloned as most recent version of some branch. One can keep updating submodule references with some daemon service (Vladimir does exactly that in https://bitbucket.org/cybershadow/d) but that will pollute history of meta-repo with dozens of trivial commits every day making it hard to use it for any real code (and also relying on well-being of that daemon service).

On Wed, Feb 11, 2015 at 06:17:35PM +0000, Dicebot via Digitalmars-d wrote:
> On Wednesday, 11 February 2015 at 18:05:56 UTC, Andrei Alexandrescu wrote:
> >What does "update" mean in this context? I was expecting the projects to be more or less up to date. -- Andrei
> 
> $ git clone --recursive git@github.com:D-Programming-Language/dlang
> 
> This will clone all submodules set to latest released version tag
> (v2.066.1 right now)
> 
> $ cd dlang; ./dlang.d update
> 
> This will update all submodules to latest git master heads.
> 
> git submodules are designed to track exact commit hash of remote repository - it is impossible to define those to always be cloned as most recent version of some branch. One can keep updating submodule references with some daemon service (Vladimir does exactly that in https://bitbucket.org/cybershadow/d) but that will pollute history of meta-repo with dozens of trivial commits every day making it hard to use it for any real code (and also relying on well-being of that daemon service).

I thought somebody mentioned that the latest version of git submodules now allows tracking branch heads instead of specific commits?


T

-- 
"I suspect the best way to deal with procrastination is to put off the procrastination itself until later. I've been meaning to try this, but haven't gotten around to it yet. " -- swr

On Wednesday, 11 February 2015 at 18:23:23 UTC, H. S. Teoh wrote:
> I thought somebody mentioned that the latest version of git submodules
> now allows tracking branch heads instead of specific commits?

And I have replied several times already that it doesn't work the way those people expect it to work. Do you honestly think I have not tried that feature before proposing anything?

It simply sets remote tracking branch for submodules allowing to update them all with simple one-liner `git submodule update --remote`. It still stores exact commit hash in history which gets cloned initially.

On Wednesday, 11 February 2015 at 18:23:23 UTC, H. S. Teoh wrote:
> I thought somebody mentioned that the latest version of git submodules
> now allows tracking branch heads instead of specific commits?

Yeah, it turns out it doesn't work quite like you'd expect. They still track specific commits, but they also remember a ref (branch) that a commit can be on. Then, you can run "git submodule update --remote" to make it point to the latest commit on that branch.

On Wed, Feb 11, 2015 at 06:27:44PM +0000, Vladimir Panteleev via Digitalmars-d wrote:
> On Wednesday, 11 February 2015 at 18:23:23 UTC, H. S. Teoh wrote:
> >I thought somebody mentioned that the latest version of git submodules now allows tracking branch heads instead of specific commits?
> 
> Yeah, it turns out it doesn't work quite like you'd expect. They still track specific commits, but they also remember a ref (branch) that a commit can be on. Then, you can run "git submodule update --remote" to make it point to the latest commit on that branch.

Ah I see. Carry on, then. :-P


T

-- 
A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived. -- Michael B. Allen

On 2015-02-11 19:04, Andrei Alexandrescu wrote:

> In that case wouldn't "d" be best? -- Andrei

I don't think that is specific enough. I store all D related projects in a directory called "d".

-- 
/Jacob Carlborg

On 2015-02-11 19:17, Dicebot wrote:

> $ git clone --recursive git@github.com:D-Programming-Language/dlang
>
> This will clone all submodules set to latest released version tag
> (v2.066.1 right now)

What I don't like about this is that you don't get the latest code. Maybe this will cause more problems for new developers than it will fix.

> $ cd dlang; ./dlang.d update
>
> This will update all submodules to latest git master heads.

And when you do have the latest code, you will also have a "dirty" working directory.

> git submodules are designed to track exact commit hash of remote
> repository - it is impossible to define those to always be cloned as
> most recent version of some branch. One can keep updating submodule
> references with some daemon service (Vladimir does exactly that in
> https://bitbucket.org/cybershadow/d)

I was thinking of using git hooks that updates the submodules. That is, each repository that is a submodule would have a git hook that is run after each commit. The hook would update the submodule in the meta repository.

> but that will pollute history of
> meta-repo with dozens of trivial commits every day making it hard to use
> it for any real code (and also relying on well-being of that daemon
> service).

Will there be much "real" code in the meta repository? Are you thinking about shared build scripts?

-- 
/Jacob Carlborg

On Thursday, 12 February 2015 at 07:35:07 UTC, Jacob Carlborg wrote:
>> but that will pollute history of
>> meta-repo with dozens of trivial commits every day making it hard to use
>> it for any real code (and also relying on well-being of that daemon
>> service).
>
> Will there be much "real" code in the meta repository? Are you thinking about shared build scripts?

Yes, I'd like all build scripts and makefiles that work on multiple repos at time to be placed in meta repo to get rid of awkward "works if you follow convention" situation we have now. Also stuff from "installer" repo,

> And when you do have the latest code, you will also have a "dirty"
working directory.

Is it a problem? Root working dir will be dirty, correct, but not working dirs for each of submodules.

On 2015-02-12 09:07, Dicebot wrote:

> Is it a problem? Root working dir will be dirty, correct, but not
> working dirs for each of submodules.

I don't. It would be nice to have the latest code just by cloning.

-- 
/Jacob Carlborg