Version control systems

[Johan Tibell-2]

On Sat, Aug 16, 2008 at 12:21 AM, Thomas Schilling
<nominolo@...> wrote:
> you don't use local branches?

I do. I like to keep a clean linear history on top of the upstream
repo. So I might do work in a topic branch, rebase it on my master
branch which is synced with upstream and then push.

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

[Duncan Coutts]

On Fri, 2008-08-15 at 15:12 +0100, 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.

That's probably because there entire world are probably only two T1/T2
machines that people are using to run ghc. :-)

One of them is at UNSW and the other was recently donated by Sun to the
community and is just about to go online at Chalmers.

>  What goes wrong? I'd expect darcs to build anywhere GHC does.

So would I usually, though I've had to turn down cc flags to get darcs
to build on ia64 before (SHA1.hs generates enormous register pressure).

Duncan

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

[Manuel M T Chakravarty]

Gregory Wright:

> 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.

Well, that "spinning endlessly" is the bug I am referring to.  I re-
checked my MacPorts darcs2 installation and, you are right, there was  
an update that removes the use of libcurl.  It seems to work *much*  
better now.

Thanks for the fix!

You may want to publicise this a bit further.  When I asked on #darcs  
about the problem a few days ago, nobody knew about this update to the  
port.

Manuel

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

[Manuel M T Chakravarty]

 From what you are saying, it seems that one "advantage" of git (in-
place branch switching) is not going to be useful to GHC in any case  
(because we use nested repositories).

Manuel

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

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

[Manuel M T Chakravarty]

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.

Sorry for being a git n00b, but does using merge mean that we need to  
use in-place branch switching (which you earlier said won't work well  
for ghc anyways)?

Manuel

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

[Ian Lynagh]

On Mon, Aug 18, 2008 at 12:21:47PM +1000, Manuel M T Chakravarty wrote:
> From what you are saying, it seems that one "advantage" of git (in-
> place branch switching) is not going to be useful to GHC in any case  

Yes.

> (because we use nested repositories).

That does make it harder, but the main problem is that switching between
branches changes the timestamp of files that differ, meaning the build
system thinks that recompilation needs to be done.

Also, if you have 2 in-place branches of GHC then only one of them can
be built at any one time, as they share a working directory.


Thanks
Ian

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

[Ian Lynagh]

On Mon, Aug 18, 2008 at 12:28:03PM +1000, Manuel M T Chakravarty wrote:
>
> does using merge mean that we need to use in-place branch switching

No; when you "git pull" (the equivalent of darcs pull -a) it will pull
and merge the changes (unless you ask it to rebase them instead of
merging them).


Thanks
Ian

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

[Simon Marlow-7]

Manuel M T Chakravarty wrote:
>  From what you are saying, it seems that one "advantage" of git
> (in-place branch switching) is not going to be useful to GHC in any case
> (because we use nested repositories).

As far as I can tell, in-place branches are not a lot of use to us compared
to just having separate checkouts for each local branch.  For one thing,
having separate source trees lets you keep multiple builds, whereas with
in-place branches you can only have one build at a time, and switching
branches probably requires a complete rebuild.

However, I think I am convinced that using in-place branches for the master
repo makes sense.  That way we don't need to publish the names of new
branches when we make them, and everyone can easily see which branches of
GHC are available from the main repo.

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

[Simon Marlow-7]

Duncan Coutts wrote:

> On Fri, 2008-08-15 at 15:12 +0100, 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.
>
> That's probably because there entire world are probably only two T1/T2
> machines that people are using to run ghc. :-)
>
> One of them is at UNSW and the other was recently donated by Sun to the
> community and is just about to go online at Chalmers.
>
>>  What goes wrong? I'd expect darcs to build anywhere GHC does.
>
> So would I usually, though I've had to turn down cc flags to get darcs
> to build on ia64 before (SHA1.hs generates enormous register pressure).

We should really use a C implementation of SHA1, the Haskell version isn't
buying us anything beyond being a stress test of the register allocator.

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

[Ben Lippmeier]

On 18/08/2008, at 8:13 PM, Simon Marlow wrote:
>> So would I usually, though I've had to turn down cc flags to get  
>> darcs
>> to build on ia64 before (SHA1.hs generates enormous register  
>> pressure).
>
> We should really use a C implementation of SHA1, the Haskell version  
> isn't buying us anything beyond being a stress test of the register  
> allocator.
>

.. and perhaps a test case for too much code unfolding in GHC? Sounds  
like bugs to me. :)

If you turn down GHC flags the pressure also goes away.

Ian: Did this problem result in Intel CC / GCC register allocator  
freakouts?

Ben.


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

[Johan Tibell-2]

Git 1.6.0 was just released [1]. Might be of interest given the
current discussion.

I cherry picked some highlights that might matter to us:

* Source changes needed for porting to MinGW environment are now all in the
main git.git codebase.

* even more documentation pages are now accessible via "man" and "git help".

* "git-add -i" has a new action 'e/dit' to allow you edit the patch hunk
  manually.

1. http://lkml.org/lkml/2008/8/17/174

Cheers,

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

[Ian Lynagh]

On Mon, Aug 18, 2008 at 09:20:54PM +1000, Ben Lippmeier wrote:
>
> Ian: Did this problem result in Intel CC / GCC register allocator  
> freakouts?

Have you got me confused with someone else? I don't think I've ever used
Intel CC.


Thanks
Ian

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

[Ben Lippmeier]

On 19/08/2008, at 8:57 PM, Ian Lynagh wrote:

> On Mon, Aug 18, 2008 at 09:20:54PM +1000, Ben Lippmeier wrote:
>>
>> Ian: Did this problem result in Intel CC / GCC register allocator
>> freakouts?
>
> Have you got me confused with someone else? I don't think I've ever  
> used
> Intel CC.
>

Sorry, I couldn't find the rest of the preceding message. Someone  
wrote that they had to turn down cc flags to get SHA1.hs to compile on  
IA64.

What C compiler was being used, and what were the symptoms?

SHA1.hs creates vastly more register pressure than any other code I  
know of (or could find), but only when -O or -O2 is enabled in GHC. If  
-O and -prof are enabled then the linear allocator runs out of stack  
slots (last time I checked).

I'm wondering three things:

1) If the C compiler could not compile the C code emitted by GHC then  
maybe we should file a bug report with the CC people.

2) If the register pressure in SHA1.hs is more due to excessive code  
unfolding than the actual SHA algorithm, then maybe this should be  
treated as a bug in the simplifier(?) (sorry, I'm not familiar with  
the core level stuff)

3) Ticket #1993 says that the linear allocator runs out of stack  
slots, and the graph coloring allocator stack overflows when trying to  
compile SHA1.hs with -funfolding-use-threshold20. I'm a bit worried  
about the stack over-flow part.

The graph size is O(n^2) in the number of vreg conflicts, which isn't  
a problem for most code. However, if register pressure in SHA1.hs is  
proportional to the unfolding threshold (especially if more than  
linearly) then you could always blow up the graph allocator by setting  
the threshold arbitrarily high.

In this case maybe the allocator should give a warning when the  
pressure is high and suggest turning the threshold down. Then we could  
close this issue and prevent it from being re-opened.

Cheers,
        Ben.

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

[Duncan Coutts]

On Tue, 2008-08-19 at 23:55 +1000, Ben Lippmeier wrote:

> On 19/08/2008, at 8:57 PM, Ian Lynagh wrote:
>
> > On Mon, Aug 18, 2008 at 09:20:54PM +1000, Ben Lippmeier wrote:
> >>
> >> Ian: Did this problem result in Intel CC / GCC register allocator
> >> freakouts?
> >
> > Have you got me confused with someone else? I don't think I've ever  
> > used
> > Intel CC.
> >
>
> Sorry, I couldn't find the rest of the preceding message. Someone  
> wrote that they had to turn down cc flags to get SHA1.hs to compile on  
> IA64.

Yep.

> What C compiler was being used, and what were the symptoms?

GCC.

As I recall the symptoms were that gcc used more than 32 registers and
then the mangler balked. The reason is that a registerised ia64 build
expects to only use the first 32 registers but does not take any
precautions to make sure that this is the case. It just relies on the
fact that most code coming out of the ghc backend cannot make use of
more than a handful of registers. If gcc does actually use more then the
mangler catches this. We tried some flags to make gcc restrict itself to
a subset of the registers but could not get it to obey.

Duncan

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

[Marc Weber]

On Tue, Aug 12, 2008 at 03:17:59PM -0400, Isaac Dupree wrote:

>  Thomas Schilling wrote:
> > I encourage everyone to add useful tips and examples both from users who
> > already use Git and later on, once we have gathered more experience.  I
> > believe that Git has some features which can improve our productivity and
> > I'd like this page to also collect tips how to do so.
>
>  what about `darcs send --dry-run`?  It's not perfect, but I use it in my old
>  repos in conjunction with `darcs wh [-l]` to find out what of value I'd lose
>  by deleting an old checkout.  (e.g., patches merged into HEAD aren't of
>  value.  But they still aren't of value even if they've been amend-recorded,
>  rewritten, or equivalent by simon/ian/etc., but Darcs can't tell this,
>  unfortunately.)
>
>  -Isaac

Hi Isaac,

git rebase can do this partially. See this example
that's what I know about (make sure you don't have important
data in /tmp/xx) How intelligent git behaves on partially applied /
cherry picked commits I don't know.

#!/bin/sh
echO(){ echo;  echo " >>>>   $@"; echo 'return to continue'; read; }
evaL(){ echo; echo "cmd: $@"; eval "$@"; }
cd /tmp/xx || exit 1
rm -fr * .*
set -e
git init
addfile(){
  echo $1 > $1
  git add $1
  git commit -m $1 -a
}
evaL 'addfile a'
evaL 'addfile b'
evaL 'addfile c'
evaL 'addfile d'
echO 'a,b,c,d recorded succesfully'
evaL 'git checkout HEAD~2'
echO 'gone back two commits'
evaL 'git checkout -b mutate'
echO 'branch mutate created'
evaL 'addfile new'
echO 'new file new added which would be lost'
evaL 'git cherry-pick master'
evaL 'git cherry-pick master^'
echO 'cherry picked d c in reverse order, look at popping up gitk now (you may want to keep it open)'
evaL 'gitk --all &'
echO 'continue after gitk has popped up, you should see one branch'
evaL 'git checkout -b rebased'
evaL 'git rebase master rebased'
echO 'tried rebasing, data which would be lost should be ahead of master now'
echO 'opening second gitk showing current repo state'
evaL 'gitk --all'
echO 'if this is not enough, you can always use git-diff:'
evaL 'git diff mutate master'
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@...
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Marc Weber]

Isaac see third

>  FWIW, I started a wiki page that tries a direct comparison between Darcs and
>  Git:
>
>    http://hackage.haskell.org/trac/ghc/wiki/GitForDarcsUsers
>
>  Some mappings are simple, some are more complicated and will require
>  adopting a different workflow.  I still recommend reading a tutorial, but
>  this cheat sheet should be a good start if you don't want to spend much time
>  to learn Git just yet.  Where no directly corresponding command exists or
>  emulating it would be too messy, I try to hint towards other work flows.
>
>  I encourage everyone to add useful tips and examples both from users who
>  already use Git and later on, once we have gathered more experience.  I
>  believe that Git has some features which can improve our productivity and
>  I'd like this page to also collect tips how to do so.

Hi Thomas: Great work! There is not much I could add (although I've used
git during the last weeks quite often..)

However I'm missing four small tips:

first man git-rev-parse (or git rev-parse help)

        HEAD HEAD^ HEAD^^ ..
        is equal to
        HEAD HEAD~1 HEAD~2 ..>

        So to drop one of the last ten commits (don't remember which one)
        git rebase -i HEAD~10 ...

second : you forgot to mention gitk. It helps you getting an overview
        about when which branches have been created

        You can use google pictures search to see how it looks like or just play
        around (try the script in my other post)..
        You can have a look at the history and branches easily.. You can even
        highlight commits by changes made to filepath (must be relative to repo
        path!) or by adding/ removing strings etc..
        And it's a nice tool to just keep all hashes in memory in case you mess
        up your repo by accident :-)

        But recent gitk can do more. When getting some conflicts on git
        merge or git rebase gitk --merge will show you all commits
        causing this conflict.

third: #git on freenode.. I bet you'll get help there as well..
        I got the last tip there as well
        < doener> MarcWeber: you could, for example, do "git log or git rev-list or gitk --left-right --cherry-pick A...B"
        lists all commits beeing present on the one or the other branch,
        but not in both

4th:   You should know one thing about git history
        There used to be no difference between
        git-log (now depreceated, does no longer work in the git git version)
        and
        git log

        Thus
          git log --help
        = git-log --help
        = man git-log (more convinient to type)

        The only execption: git-clone doesn't work in all cases, git clone does (?)
        (Don't ask me why)

maybe
git show commit-id:file is of interest as well (you told about git show)

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

[Marc Weber]

> 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.
If I can lend you (or someone else) a hand don't hesitate to contact me.
(I'm not a git guru though..)
With git you can't get too much wrong because it's very cheap to create
additional pointerns / branches.. So if you clone a branch before taking
any action you can always reset the messed up branch to the "backup" by
git reset --{soft or hard} backupbranchname
Or you could write a two line sh script writing all hashes to a
temp file etc..
If you just start gitk it will keep all hashes in memory.. so you can
recover from those as well (unless using the update menu item or running
the garbage collector)

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

[Marc Weber]

> 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.
Timestamps will be preserved so not all information is lost..

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

[Marc Weber]

>  Sorry for being a git n00b, but does using merge mean that we need to use
>  in-place branch switching (which you earlier said won't work well for ghc
>  anyways)?

You have to kind of "branches" : local ones and remote ones.
remote ones represent the state of remote ones. The only way I know of
to change them is by using git-fetch (which is called by git pull as
well) or by editing the files manually

On the other hand you normally push your local ones.

So if you have
/tmp/a/.git (heads master and mybranch)
than do cd /tmp git clone a b
git will setup
.git/refs/remotes/{master,mybranch}
.git/refs/heads/master

Now you can make mybranch local as well by
git branch mybranch remotes/mybranch
(indeed you have 4 branches, 2 tracking the remote repo and two you are
working with)

Now you can do
git checktout master;
git merge mybranch  # merge in place within the same repo
or  
git merge remotes/mybranch  # merge with remote branch which is what you'll do when using darcs branch style
etc..

After comitting to mybrach git push will change the head of the remote
repository.

You can setup each local head branch to "track" a remote oone
automaticaly so that git pull will rebase or merge depending on your
settings (AFAIK)

So if you have an active project you end up having dozens of remote
branches but only some "heads" you are working on or you want to backup
(in case someone else rewrits history or such)

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

[Marc Weber]

On Mon, Aug 18, 2008 at 12:21:47PM +1000, Manuel M T Chakravarty wrote:
>  From what you are saying, it seems that one "advantage" of git (in-place
>  branch switching) is not going to be useful to GHC in any case (because we
>  use nested repositories).
>  Manuel
I don't agree. I feel it's convinient. But I make full copies as well
because switching the shell with my window manager is faster than
checking out another branch.. But this depends on what I want to do.
>
>  Ian Lynagh:
> > 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.
Which is the fault of make not of git.. Why can't we configure make to
use checksum based recompilations (that's possile using scons)
Maybe it's possible to hack this in some way?
I'd recommend having one working clone and one for browsing.
Than you need two clones, but not n (you would have to mantain with
darcs..)
Why do you want to switch for a minute? There are tools such as gitk/
qgit letting you browse the repository (and all file contents) without
switching. I don't think that recompilation is a real issue.

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