Thread overview
D.git
Dec 25, 2013
Vladimir Panteleev
Dec 25, 2013
Ali Çehreli
Dec 25, 2013
Vladimir Panteleev
Dec 25, 2013
Vladimir Panteleev
Dec 26, 2013
Vladimir Panteleev
Dec 27, 2013
Martin Nowak
May 16, 2017
Vladimir Panteleev
May 16, 2017
Vladimir Panteleev
December 25, 2013
I wrote a tool which generates a git repository containing the D components as submodules:

https://github.com/CyberShadow-D/D

This repository has a linear history, and contains only updates to its submodules. The submodule updates are mainly pull request merge commits, obtained by traversing each repository's commit tree, starting with the master branch, through each commit's first parent. These commits are interwoven in a chronological order, so that all pull requests merged within the same week/day/hour are always neighbored together, regardless of the D component.

The result is a repository which should be much easier to regression-test than individual D components, as there are often D changes which require simultaneous changes to several components. Using this repository with "git bisect run" allows easily pinpointing the pull request which introduced a regression.

The repository updates hourly. The tool itself can be found here:

https://github.com/CyberShadow/D-dot-git

TODO: support branches other than master. This will expose release tags currently hidden on release branches (however, I'm not sure how useful that would be to git bisect in this particular case).
December 25, 2013
On 12/24/2013 06:19 PM, Vladimir Panteleev wrote:
> I wrote a tool which generates a git repository containing the D
> components as submodules:
>
> https://github.com/CyberShadow-D/D
>
> This repository has a linear history, and contains only updates to its
> submodules. The submodule updates are mainly pull request merge commits,
> obtained by traversing each repository's commit tree, starting with the
> master branch, through each commit's first parent. These commits are
> interwoven in a chronological order, so that all pull requests merged
> within the same week/day/hour are always neighbored together, regardless
> of the D component.
>
> The result is a repository which should be much easier to
> regression-test than individual D components, as there are often D
> changes which require simultaneous changes to several components. Using
> this repository with "git bisect run" allows easily pinpointing the pull
> request which introduced a regression.
>
> The repository updates hourly. The tool itself can be found here:
>
> https://github.com/CyberShadow/D-dot-git
>
> TODO: support branches other than master. This will expose release tags
> currently hidden on release branches (however, I'm not sure how useful
> that would be to git bisect in this particular case).

I've been using the following repository to build the most recent dmd, druntime, and phobos:

  https://github.com/carlor/dlang-workspace

Are they similar?

Ali

December 25, 2013
On Wednesday, 25 December 2013 at 02:59:46 UTC, Ali Çehreli wrote:
> I've been using the following repository to build the most recent dmd, druntime, and phobos:
>
>   https://github.com/carlor/dlang-workspace
>
> Are they similar?

Not quite, but perhaps you could use them together. I haven't
considered D.git's utility in making it easier to get the
bleeding-edge D version - I suppose it might help a bit, but
that's not really its primary purpose, which is to aid regression
testing. What's missing from D.git is a way to build a working
compiler from any point in time (any commit in D.git), but I
think this job is better left to projects such as the one you
mentioned, Martin Nowak's create_dmd_release, or the "compile"
action Nick Sabalausky added to Jacob Carlborg's dvm tool.
December 25, 2013
On Wednesday, 25 December 2013 at 02:19:24 UTC, Vladimir Panteleev wrote:
> https://github.com/CyberShadow-D/D

Hmm, looks like it's spamming the D repositories because of the hyperlinks :(

https://github.com/D-Programming-Language/dmd/pull/3016

Sorry about that. I disabled updating until I get a reply from GitHub tech support.
December 26, 2013
On Wednesday, 25 December 2013 at 13:16:20 UTC, Vladimir Panteleev wrote:
> On Wednesday, 25 December 2013 at 02:19:24 UTC, Vladimir Panteleev wrote:
>> https://github.com/CyberShadow-D/D
>
> Hmm, looks like it's spamming the D repositories because of the hyperlinks :(
>
> https://github.com/D-Programming-Language/dmd/pull/3016
>
> Sorry about that. I disabled updating until I get a reply from GitHub tech support.

Ugh. Even though I deleted the repository and GitHub account, there's still "ghost" comments scattered across all recent D pull requests. GitHub support can't remove them either. Sorry about this.

I moved the repository itself to BitBucket:

https://bitbucket.org/cybershadow/d/commits
December 27, 2013
On 12/25/2013 02:16 PM, Vladimir Panteleev wrote:
>
> Hmm, looks like it's spamming the D repositories because of the
> hyperlinks :(
>
> https://github.com/D-Programming-Language/dmd/pull/3016
>
> Sorry about that. I disabled updating until I get a reply from GitHub
> tech support.

Yikes, I remember writing a short script that listed all unmerged but closed pull requests. Luckily the github scripts died before adding +500 commit references when I pushed this to github.
May 16, 2017
On Wednesday, 25 December 2013 at 02:19:24 UTC, Vladimir Panteleev wrote:
> I wrote a tool which generates a git repository containing the D components as submodules:

2017 update:

I've pushed some improvements[1] to D-dot-git and updated the D.git repo. These greatly improve the tracking accuracy of branches, particularly the stable branch.

If you've previously attempted to bisect a D regression with Digger and got an unhelpful result such as "Merge remote-tracking branch 'upstream/master' into stable", this should now be fixed. (If the regression was caused by a PR on the stable branch, you will still need to ask Digger to bisect on the stable branch, e.g. by using "stable @ date-here" for the bad and good values.

  [1]: https://github.com/CyberShadow/D-dot-git/commits?author=CyberShadow&since=2017-05-01T00:00:00Z&until=2017-05-17T00:00:00Z

May 16, 2017
On Tuesday, 16 May 2017 at 05:47:52 UTC, Vladimir Panteleev wrote:
> (If the regression was caused by a PR on the stable branch, you will still need to ask Digger to bisect on the stable branch, e.g. by using "stable @ date-here" for the bad and good values.

)