Version control systems

[Isaac Dupree]

Iavor Diatchki wrote:
> I also don't think that the darcs model has much to offer over git, in
> fact I find that it lacks some useful features (not counting a
> reliable implementation).  Examples include good support for
> branching, and being able to easily determine the version of the
> software that is in a repository (git uses a hash of the content to
> identify the current state, so it is easy to check if we two
> developers have the same version of the content).

I think these things are possible in darcs's model, just not
its implementation.  For example, under _darcs it could have
enough info in various states to allow one to switch
branches within the same physical directory tree (and if
there aren't many changes between the two
branches/patchsets, the switch can be quick).  And if it
weren't for the varying ways the same patch can be stored,
hashes of history ought to work too (although that's
certainly very built in to the current implementation of
darcs; whether it's technically part of the model probably
depends whether you can provide the exact same interface,
semantics, and computational complexity with a different
representation).

And I wonder why (it sounds like) Git doesn't have tools to
do some kind of smart cherrypicking, using a heuristic to
decide which patches in a branch are definitely dependencies
of the cherry-picked patch.  In any case, I notice a few
times with ghc/darcs/Trac tickets, more than one commit has
to be listed explicitly to be merged into the stable branch.
  Maybe it's not very useful/reliable for these purposes anyway?

Since I've only ever used Darcs (besides read-only
CVS/SVN/etc.), I personally can't speak to what model is
better for me!

-Isaac
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Neil Mitchell]

Hi

> So I suggest we propose moving all the core packages to git, and we
> translate all those for which nobody objects to the change.  For the others,
> we'll keep them in darcs and live with the pain.

Does this mean my (now the communities) FilePath library is going to
get moved over to git?

I personally don't know Git, and while I'm sure I'll be learning at
some point, I'm always nervous about learning a VCS on something I
care about, as mistakes can go quite wrong. In addition, things like
the Yhc build scripts already check out the darcs version, so will
have to be modified*.

If it really makes the life easier for people who are having lots of
VCS pain at the moment, then its hard to object. But many of the
comments in this discussion, about how everyone is going to flock to
GHC just as soon as it switches to Git, seem overly optimistic. I
think GHC is a few years off becoming drive-by hacker friendly, for
many other reasons.

The halfway house of switching the compiler, and leaving the libraries
in darcs, seems desirable. If Git turns out to be wonderful, as people
claim, moving the whole way over is fairly easy and a simple choice.

Thanks

Neil

* Modifying the Yhc build scripts is much harder than modifying the
GHC build script, as they are 10,000 lines of Python (a language I
don't know) in a very complex framework (which I also don't know)! Of
course, this is something for the Yhc team to deal with...
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Manuel M T Chakravarty]

Neil Mitchell:
> If it really makes the life easier for people who are having lots of
> VCS pain at the moment, then its hard to object. But many of the
> comments in this discussion, about how everyone is going to flock to
> GHC just as soon as it switches to Git, seem overly optimistic. I
> think GHC is a few years off becoming drive-by hacker friendly, for
> many other reasons.

It's not about becoming "drive-by hacker friendly".  It is about not  
becoming even less friendly as it is right now.

Manuel

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Thomas Schilling-2]

Are you advocating for ease of use by new developers or for existing
developers? Current GHC hackers have to learn Git anyways and know
Darcs already. Library patches still have to be recorded separately,
so it would be a bit weird, but not much harder, really.

On Fri, Aug 15, 2008 at 1:59 AM, Manuel M T Chakravarty
<chak@...> wrote:

> Neil Mitchell:
>>
>> If it really makes the life easier for people who are having lots of
>> VCS pain at the moment, then its hard to object. But many of the
>> comments in this discussion, about how everyone is going to flock to
>> GHC just as soon as it switches to Git, seem overly optimistic. I
>> think GHC is a few years off becoming drive-by hacker friendly, for
>> many other reasons.
>
> It's not about becoming "drive-by hacker friendly".  It is about not
> becoming even less friendly as it is right now.
>
> Manuel
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@...
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Manuel M T Chakravarty]

Thomas Schilling:
> Are you advocating for ease of use by new developers or for existing
> developers? Current GHC hackers have to learn Git anyways and know
> Darcs already. Library patches still have to be recorded separately,
> so it would be a bit weird, but not much harder, really.

I am arguing for both.  It would be more than weird.  For example, if  
you branch ghc, you usually need to branch the core libraries, too.  
Doing that in two different vcs sounds like a mess to me.

Moreover, as I wrote a few times before, some reasons for switching in  
the first place are invalidated by not having the core libraries in  
git, too.  For example, one complaint about darcs is that it either  
doesn't build (on the Sun Solaris T1 and T2 machines) or is buggy (on  
Mac OS with MacPorts), and hence people have trouble getting the  
sources out of darcs in the first place.  How is that going to be  
addressed if some crucial code still needs to be obtained using darcs?

Manuel

> On Fri, Aug 15, 2008 at 1:59 AM, Manuel M T Chakravarty
> <chak@...> wrote:
>> Neil Mitchell:
>>>
>>> If it really makes the life easier for people who are having lots of
>>> VCS pain at the moment, then its hard to object. But many of the
>>> comments in this discussion, about how everyone is going to flock to
>>> GHC just as soon as it switches to Git, seem overly optimistic. I
>>> think GHC is a few years off becoming drive-by hacker friendly, for
>>> many other reasons.
>>
>> It's not about becoming "drive-by hacker friendly".  It is about not
>> becoming even less friendly as it is right now.

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Gregory Wright-2]

Hi Manuel,

On Aug 14, 2008, at 9:12 PM, Manuel M T Chakravarty wrote:

> Moreover, as I wrote a few times before, some reasons for switching  
> in the first place are invalidated by not having the core libraries  
> in git, too.  For example, one complaint about darcs is that it  
> either doesn't build (on the Sun Solaris T1 and T2 machines) or is  
> buggy (on Mac OS with MacPorts), and hence people have trouble  
> getting the sources out of darcs in the first place.  How is that  
> going to be addressed if some crucial code still needs to be  
> obtained using darcs?
>

Regarding darcs on OS X from MacPorts, I am not aware (or have been  
sent any bug reports) that there
are problems with the latest darcs-2.0.0 port.  Is there something  
that I should know (and try to fix)?

The latest port defaults to wget instead of libcurl since I have  
noticed darcs spinning endlessly when
using libcurl.  I haven't had time to dtrace what is going on but I'm  
guessing the underlying problem is likely
some misunderstanding of the signal handling API or some corner case  
of blocking/nonblocking IO.

-Greg

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Isaac Dupree]

Manuel M T Chakravarty wrote:
> Thomas Schilling:
>> Are you advocating for ease of use by new developers or for existing
>> developers? Current GHC hackers have to learn Git anyways and know
>> Darcs already. Library patches still have to be recorded separately,
>> so it would be a bit weird, but not much harder, really.
>
> I am arguing for both.  It would be more than weird.  For example, if
> you branch ghc, you usually need to branch the core libraries, too.  
> Doing that in two different vcs sounds like a mess to me.

So let's figure out how it would work (I have doubts too!)
So, within the directory that's a git repo (ghc), we have
some other repos, git (testsuite) and darcs (some
libraries).  Does anyone know how git handles nested repos
even natively?  Then, adding complexity, git branches are
normally done by switching in-place.  So how does this
interact with VCS like darcs that doesn't have a concept of
in-place switching of branches?  (Now, I wouldn't be
surprised if git, the monstrosity that it is, has already
invented answers for these sort of questions :-) But we need
to figure out the answers for whatever situation we choose
for the 6.11 development cycle, and probably document them
somewhere on the wiki (that I lazily didn't bother to check
again before writing this message).

-Isaac
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Max Bolingbroke-2]

2008/8/15 Isaac Dupree <isaacdupree@...>:
> So let's figure out how it would work (I have doubts too!) So, within the
> directory that's a git repo (ghc), we have some other repos, git (testsuite)
> and darcs (some libraries).  Does anyone know how git handles nested repos
> even natively?

You can explicitly tell Git about nested Git repos using
http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html.
This essentially associates a particular version of each subrepo with
every version of the repo that contains them, so e.g. checking out GHC
from 2 weeks ago could check out the libraries from the same point in
time.

AFAIK, nothing in Git caters for subrepos of a different VCS.

> Then, adding complexity, git branches are normally done by
> switching in-place.  So how does this interact with VCS like darcs that
> doesn't have a concept of in-place switching of branches?

Since we will set up Git to ignore the contents of the Darcs repos, it
will simply leave them unmodified. This is exactly like the current
situation, where rolling back / patching the GHC repo does not affect
the others. If you want Darcs-like behaviour (one branch per repo) you
are free to do this in Git as well, in which case since you never
switch branches the nested Darcs repos should never be inappropriate
for your branch.

Personally, since I only ever hack GHC and tend to leave the libraries
alone, I could still use the in-place branching without difficulty.

> (Now, I wouldn't
> be surprised if git, the monstrosity that it is, has already invented
> answers for these sort of questions :-) But we need to figure out the
> answers for whatever situation we choose for the 6.11 development cycle, and
> probably document them somewhere on the wiki (that I lazily didn't bother to
> check again before writing this message).

The situation above is pretty much the whole story, if we are taking
the route where we just convert the GHC+testsuite repo to Git. I don't
think it's particularly confusing, but maybe that's because I've spent
too long thinking about VCSs :-).

This thread has got quite large, and doesn't appear to have made much
progress towards a resolution. Let me try and sum up the discussion so
far.

There seem to be four stakeholders in this switch:
a) Current GHC developers
b) Future GHC developers
c) People who just contribute to the libaries
d) Maintainers of other compilers GHC shares repos with

And there are at least 5 options for how to proceed:
1) Convert just GHC and Testsuite to Git, leave everything else in Darcs
  Pros:
  - No change in habits required for stakeholders c, d
  - Resolves all Darcs issues discussed at length before, pleasing
stakeholders a, b

  Cons:
  - Requires two VCSs to be installed and learnt (more points of
failure, makes source tree less accessible, doesn't solve any Darcs'
build+install problems), affecting stakeholders a and b
  - Difficult to check out a consistent version of the source tree (no
submodules), affecting stakeholders a and b

2) Wait for Darcs2 to get better
  Pros:
    - No change in habits required for any stakeholders (though we
still have one-off switching cost)
    - Potentially resolves all Darcs issues, pleasing stakeholders a, b
    - Only option that will not require a workflow change for GHC
developers (more topic branches rather than "spontaneous branches" and
cherry-picking), pleasing stakeholders a

  Cons:
    - Darcs will probably continue to be less popular and well
supported than Git (see Debian popcon graphs for the trend
difference). Reduced popularity will affect the ability of
stakeholders b to contribute (learning barrier), and less support/real
world use may potentially lead to a higher incidence of bugs
encountered, affecting stakeholders a-d. This point is certainly
debatable.
    - Apparently somewhat vaporware at the moment

3) Convert all repos to Git
  Pros:
    - Native Git submodule integration, makes life easier for stakeholders a-b
    - Single (popular) command set to learn, single thing to install:
makes life better for stakeholder b at least

  Cons:
    - Significant inconvenience for stakeholders c-d as they have to
change their own projects

4) Branch all repos into Git but leave the Darcs repos alone and push
Darcs patches into the Git repos automatically. Never push to these
Git repos in any other way, similar to Cabal repo currently
  Pros:
    - As option 3
    - Stakeholders c-d do not need to do anything

  Cons:
    - Makes it harder to hack on the libraries within a GHC checkout,
affecting a, b
    - Automatic synchronisation will require occasional maintenance by someone

5) Branch all repos into Git and then set up a manual merging / sync
process that tries to turn Git commits into Darcs patches and
vice-versa
  Pros:
    - As option 3
    - Hack on the libraries in a GHC checkout with ease, pleasing a, b
    - Stakeholders c-d do not need to do anything

  Cons:
     - Synchronisation much more fragile than 4), will likely require
constant maintenance

This summary is probably incomplete and inaccurate. However, if people
find it useful for organising the various lines of discussion on this
issue, perhaps someone could Wikify it so we can get a complete, clear
picture?

My personal preference is for 3), but that's because I'm a stakeholder
"a" who isn't a great fan of spontaneous branches!

Anyway, there are good arguments on every side, so I don't want to
advocate a particular position (and indeed, my opinions quite rightly
do not carry any weight! :-). However I'd really like for us to work
out what is going on so we have a clear plan for moving away from
Darcs 1, which is an inadequate VCS for GHC for reasons that have been
discussed to death. I hope (perhaps naively) that this email can
provide a framework for reaching a consensus agreeable to all parties.

All the best,
Max
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Ian Lynagh]

On Fri, Aug 15, 2008 at 11:12:20AM +1000, Manuel M T Chakravarty wrote:
>
> Moreover, as I wrote a few times before, some reasons for switching in  
> the first place are invalidated by not having the core libraries in  
> git, too.  For example, one complaint about darcs is that it either  
> doesn't build (on the Sun Solaris T1 and T2 machines)

I don't remember seeing this mentioned before, and googling for
    "Solaris T1" darcs
doesn't find anything. What goes wrong? I'd expect darcs to build
anywhere GHC does.


Thanks
Ian

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Ian Lynagh]

On Fri, Aug 15, 2008 at 01:01:08PM +0100, Max Bolingbroke wrote:

> 2008/8/15 Isaac Dupree <isaacdupree@...>:
> > So let's figure out how it would work (I have doubts too!) So, within the
> > directory that's a git repo (ghc), we have some other repos, git (testsuite)
> > and darcs (some libraries).  Does anyone know how git handles nested repos
> > even natively?
>
> You can explicitly tell Git about nested Git repos using
> http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html.
> This essentially associates a particular version of each subrepo with
> every version of the repo that contains them, so e.g. checking out GHC
> from 2 weeks ago could check out the libraries from the same point in
> time.

We were talking about this last night on #ghc, and AIUI this doesn't
play well with the in-tree branching style that is advocated, e.g. if
you want to branch ghc and base then as you change between ghc branch X
and Y, git won't automatically change base between branches X' and Y'.

> > Then, adding complexity, git branches are normally done by
> > switching in-place.  So how does this interact with VCS like darcs that
> > doesn't have a concept of in-place switching of branches?

The in-tree branching style also sounds like it won't work well with
trees you are working in: If you have a tree built with branch X, and
then you swap to branch Y for a minute and then back to branch X, then
the timestamps on any source files that differ between the branches will
have changed, so the build won't think it is up-to-date any more and you
will get needless recompilation.

Working only in the "master" branch, and using different repos for
branches (i.e. doing what we do with darcs), is an option, although git
users seem to think it is a worse way to work; I'm not really clear on
the main reasons why.

One way that it is worse is that you will get a lot more "automatic
merge" commits when you pull changes from the central repo into a repo
in which you have local commits. I don't think that there is anything
bad about these, as such; they're just noise in the history. (I'm not
sure if it's possible to automatically rebase these away, or
something?).

Hopefully a git person will correct me if I've got something wrong!


Thanks
Ian

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Thomas Schilling-2]

On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh <igloo@...> wrote:
> One way that it is worse is that you will get a lot more "automatic
> merge" commits when you pull changes from the central repo into a repo
> in which you have local commits. I don't think that there is anything
> bad about these, as such; they're just noise in the history. (I'm not
> sure if it's possible to automatically rebase these away, or
> something?).

This is the use case for "git pull --rebase".  Instead of creating an
automatic merge commit, it rebases your local changes on top of the
newly pulled changes (ignoring patches already present, which could
happen if you had sent one change as a patch via mail.)

The timestamp issue seems tricky, though.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Ian Lynagh]

On Fri, Aug 15, 2008 at 05:09:55PM +0200, Thomas Schilling wrote:

> On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh <igloo@...> wrote:
> > One way that it is worse is that you will get a lot more "automatic
> > merge" commits when you pull changes from the central repo into a repo
> > in which you have local commits. I don't think that there is anything
> > bad about these, as such; they're just noise in the history. (I'm not
> > sure if it's possible to automatically rebase these away, or
> > something?).
>
> This is the use case for "git pull --rebase".  Instead of creating an
> automatic merge commit, it rebases your local changes on top of the
> newly pulled changes

Hmm, last night the conversation went:

< nominolo> malcolmw: so i'm advocating "git pull --rebase" for
            that use case
< glguy_> rebasing can be less successful than merging when
          dealing with big changes
< glguy_> since the rebase happens one commit
          at a time

so I'm confused as to what the best practice is.


Thanks
Ian

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Roman Leshchinskiy]

On 16/08/2008, at 00:12, Ian Lynagh wrote:

> On Fri, Aug 15, 2008 at 11:12:20AM +1000, Manuel M T Chakravarty  
> wrote:
>>
>> Moreover, as I wrote a few times before, some reasons for switching  
>> in
>> the first place are invalidated by not having the core libraries in
>> git, too.  For example, one complaint about darcs is that it either
>> doesn't build (on the Sun Solaris T1 and T2 machines)
>
> I don't remember seeing this mentioned before, and googling for
>    "Solaris T1" darcs
> doesn't find anything. What goes wrong? I'd expect darcs to build
> anywhere GHC does.

I only vaguely remember what was wrong but IIRC, the problem was that  
darcs 1.0.? didn't build with GHC 6.8.? because of some  
incompatibility in the libs and darcs 2 built ok but didn't work,  
probably because of libcurl issues. At that point I gave up.

Roman


_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Ian Lynagh]

On Fri, Aug 15, 2008 at 04:24:12PM +0100, Ian Lynagh wrote:

> On Fri, Aug 15, 2008 at 05:09:55PM +0200, Thomas Schilling wrote:
> > On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh <igloo@...> wrote:
> > > One way that it is worse is that you will get a lot more "automatic
> > > merge" commits when you pull changes from the central repo into a repo
> > > in which you have local commits. I don't think that there is anything
> > > bad about these, as such; they're just noise in the history. (I'm not
> > > sure if it's possible to automatically rebase these away, or
> > > something?).
> >
> > This is the use case for "git pull --rebase".  Instead of creating an
> > automatic merge commit, it rebases your local changes on top of the
> > newly pulled changes
>
> Hmm, last night the conversation went:
>
> < nominolo> malcolmw: so i'm advocating "git pull --rebase" for
>             that use case
> < glguy_> rebasing can be less successful than merging when
>           dealing with big changes
> < glguy_> since the rebase happens one commit
>           at a time
>
> so I'm confused as to what the best practice is.

We discussed this in #ghc, and the conclusion seems to be:

If you have lots of local changes (e.g. the sorts of long-running branch
that gives darcs 1 problems), then you need to use merge. If you use
rebase then you might end up with lots of conflicts to manually resolve.

Using merge gives you automatic merge commits, If you think these are
ugly (opinion is divided on that amongst git people; I guess for GHC
we'd want to make a global decision about that) then you can use rebase
when you have few local changes, and thus you are unlikely to get many
conflicts.

Using merge you also get a more accurate reflection of the project
history, i.e. you can see that the two branches were being developed
independently.


Thanks
Ian

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Thomas Schilling-2]

> If you have lots of local changes (e.g. the sorts of long-running branch
> that gives darcs 1 problems), then you need to use merge. If you use
> rebase then you might end up with lots of conflicts to manually resolve.
>
> Using merge gives you automatic merge commits, If you think these are
> ugly (opinion is divided on that amongst git people; I guess for GHC
> we'd want to make a global decision about that) then you can use rebase
> when you have few local changes, and thus you are unlikely to get many
> conflicts.
>
> Using merge you also get a more accurate reflection of the project
> history, i.e. you can see that the two branches were being developed
> independently.

That's not quite accurate: If you have conflicts, you have conflicts
and have to resolve them manually.  In case of a branch, however, you
only have to resolve them once you do the merge, so when _you_ decide,
not whenever some upstream change breaks things.

Some projects encourage to have one development branch and
periodically update the master branch and rebase the development
branch on top of it.  I think it's a matter of taste and we should
probably advocate one usage.  I think rebase should only be used for
smaller changes.

The automatic usefulness of the automatic merge message is varying.  I
think it makes sense if it contains public repos, like, e.g. "Merge
'master' from git://github.com/chak/ghc", but less useful for pulls
from local repos like, e.g. "Merge 'master' from
'/home/igloo/tmp/trash/ghc/fix-stupid-osx-bug/'".  However, if we
prefer merges we get those pretty git history graphs:
http://www.flickr.com/photos/malcolmtredinnick/1516857444/
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Bryan Donlan]

On Thu, Aug 14, 2008 at 12:10 PM, Isaac Dupree <isaacdupree@...> wrote:

> And I wonder why (it sounds like) Git doesn't have tools to do some kind of
> smart cherrypicking, using a heuristic to decide which patches in a branch
> are definitely dependencies of the cherry-picked patch.  In any case, I
> notice a few times with ghc/darcs/Trac tickets, more than one commit has to
> be listed explicitly to be merged into the stable branch.  Maybe it's not
> very useful/reliable for these purposes anyway?

The intent with git is that you would do such cherrypicks at the
branch level, not at the individual commit level - ie, if you have
dependent patches that also need to be backported or whatever, you
really ought to have developed the feature as a branch in the first
place. You could then rebase such a branch to a prior version, and
merge it into both old and new; or you could just rebase it on top of
wherever you're backporting to, if you don't intend to do big merges
much between the two (as the commit IDs would be different in this
case).

You can of course just use git cherry-pick, but this doesn't have any
intelligence at all when it comes to avoiding duplicate patches - it
basically just diffs from the old commit and applies it somewhere
else. The git merging logic does have some heuristics to detect
duplicate patches and do the right thing, however.

The limitations come from git's relatively simple history model, in
which commits have parent commits but no 'sideways' relationships. In
practice I don't think it will be a problem - how often will there be
branches which will receive cherry picks and then later have a merge
from or to the same source?
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Max Bolingbroke-2]

2008/8/15 Ian Lynagh <igloo@...>:

>> You can explicitly tell Git about nested Git repos using
>> http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html.
>> This essentially associates a particular version of each subrepo with
>> every version of the repo that contains them, so e.g. checking out GHC
>> from 2 weeks ago could check out the libraries from the same point in
>> time.
>
> We were talking about this last night on #ghc, and AIUI this doesn't
> play well with the in-tree branching style that is advocated, e.g. if
> you want to branch ghc and base then as you change between ghc branch X
> and Y, git won't automatically change base between branches X' and Y'.

If you change the submodules in branch X to point to the X' commit in
base, and do the corresponding thing for Y and Y', I believe you
/would/ get this behaviour (though you might have to remember to do
"git submodule update" when switching.. this can probably be
automated).

Provisio: I'm also not a Git expert, but this is my understanding of
how it works.

Cheers,
Max
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Johan Tibell-2]

On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh <igloo@...> wrote:
> One way that it is worse is that you will get a lot more "automatic
> merge" commits when you pull changes from the central repo into a repo
> in which you have local commits. I don't think that there is anything
> bad about these, as such; they're just noise in the history. (I'm not
> sure if it's possible to automatically rebase these away, or
> something?).

I'm not sure if this is what you want but I always use git pull
--rebase when I'm pulling to have my local commits lie on top of the
one in the published repo.

-- Johan
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Thomas Schilling-2]

you don't use local branches?

On Sat, Aug 16, 2008 at 12:04 AM, Johan Tibell <johan.tibell@...> wrote:

> On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh <igloo@...> wrote:
>> One way that it is worse is that you will get a lot more "automatic
>> merge" commits when you pull changes from the central repo into a repo
>> in which you have local commits. I don't think that there is anything
>> bad about these, as such; they're just noise in the history. (I'm not
>> sure if it's possible to automatically rebase these away, or
>> something?).
>
> I'm not sure if this is what you want but I always use git pull
> --rebase when I'm pulling to have my local commits lie on top of the
> one in the published repo.
>
> -- Johan
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@...
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Manuel M T Chakravarty]

Max Bolingbroke:

>> Then, adding complexity, git branches are normally done by
>> switching in-place.  So how does this interact with VCS like darcs  
>> that
>> doesn't have a concept of in-place switching of branches?
>
> Since we will set up Git to ignore the contents of the Darcs repos, it
> will simply leave them unmodified. This is exactly like the current
> situation, where rolling back / patching the GHC repo does not affect
> the others. If you want Darcs-like behaviour (one branch per repo) you
> are free to do this in Git as well, in which case since you never
> switch branches the nested Darcs repos should never be inappropriate
> for your branch.

This ignores that the ability to have branches, switch between them,  
and merge has been cited as one of the reasons for switching to git.  
Embedded darcs library repos would hence nullify, or at least reduce,  
one of the advantages.

Manuel

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users