ghc-compete, a repository of fingerprints, and continuous integration

[Simon Marlow]

On 15/10/2013 16:29, Herbert Valerio Riedel wrote:
> Hello Simon,
>
> On 2013-10-15 at 14:45:05 +0200, Simon Marlow wrote:
>
> [...]
>
>> If we can get the tooling right I would probably have no objections to
>> submodules.  Right now it's a bit of a pain though.
>>
>>   - extra steps in the workflow for modifying a library (git checkout
>>     master, etc.)
>
> Ok, this is the item that requires actual non-trivial scripting to
> support; I'll need to think about how to best address this issue
>
> How many extra steps in the workflow would be tolerable?

One extra step is inevitable; the step where you commit an update to the 
submodule hash in the GHC repo.  This will sometimes happen at the same 
time as corresponding change to GHC, which is fine.  It would be nice if 
this was the only extra step.

>>   - possibility of losing local changes by git submodule update, if you
>>     have made local changes in your copy of the library.
>>     Perhaps what I want here is for "sync-all --rebase" to do "git
>>     submodule update --rebase".
>
> Fwiw, local uncommitted changes are warned about by recent Git versions:

Yes, I'm aware of this.  It is committed changes that are more problematic.

> As for committed changes, with "git config
> submodule.<SUBMODULENAME>.update rebase" the --rebase flag can be made
> the default setting; this could be configured up by 'sync-all' on
> initial checkouts; so if 'git submodule update --rebase' is what you
> want, this can be made the default mode easily even when not using
> 'sync-all'.

I think what we want is the following:

  - "sync-all pull" does a "git submodule update --merge"
  - "sync-all pull --rebase" does a "git submodule update --rebase"

This is close to the behaviour we have for non-submodule repos, so it 
should be less surprising for people, and crucially if there are any 
local committed changes in the submodule they will be either merged or 
rebased, and not just "lost" (yes I know they're in the reflog).

 > For this, Git itself already provides various commands:
>
> 1.) git submodule status
[..]
> 2.) git submodule summary
[..]
> 3.) git submodule foreach git status

Yes, I'm aware there are ways to do this.  The point I'm making is that 
it would be nice to have a single command that shows the unpushed 
patches in all repos, including the GHC repo itself.  This is not a big 
deal at all.  If it is two commands, that's not a disaster, so long as 
we document the workflow carefully on the wiki.

>>   - Difficulties with having a local mirror of the GHC repos.  Does
>>     "sync-all -r <root> remove update-url" work with submodules now?
>>     Does "./sync-all get" get the submodules from the same place as the
>>     GHC repo?
>
> btw, the command I assume you meant to write is probably
>
>    sync-all -r <root> remote set-url
>
> and there's been a commit some time ago for improving its behaviour on
> submodules:
>
>    http://git.haskell.org/ghc.git/commitdiff/0481e076f3cb4010894324cac71e947c6637805a
>
> but it might not be perfect yet (I use the feature myself rather seldom,
> so I don't know how well it works right now); however it's definitely
> possible to make this work, and 'git submodule' does support rewriting
> the urls between 'git submodule init' and 'git submodule update' via
> per-submodule config variables, as well as after 'git submodule update'
> has run via 'git remote set-url [--push]' -- so basically, I know what
> needs to be done for this item in case it doesn't work already the way
> it should.

Great - I'll test it and create a ticket if it doesn't work.

Cheers,
Simon