Simon Marlow:
> On 09/05/2011 21:04, Roman Leshchinskiy wrote:
>> As usual, I'm too stupid
>> to understand the git docs. This all *is* quite complicated.
>
> I am also too stupid to understand the git docs. We should start a club!
> What I know about git I've mostly discovered by experimentati
On 10/05/2011 11:11, Roman Leshchinskiy wrote:
Simon Marlow wrote:
I'm not sure exactly what it means to rebase two branches "in sync". I
know that if you rebase a branch and the target of the rebase already has
(some of) the patches that you are rebasing, then git will drop them
during the re
Simon Marlow wrote:
>
> I'm not sure exactly what it means to rebase two branches "in sync". I
> know that if you rebase a branch and the target of the rebase already has
> (some of) the patches that you are rebasing, then git will drop them
> during the rebase.
Ah, that's good to know. Thanks! S
On 09/05/2011 21:04, Roman Leshchinskiy wrote:
On 09/05/2011, at 12:34, Manuel M T Chakravarty wrote:
Simon Marlow:
- you develop in your working tree and commit patches there. At
this point it's completely safe to rebase - the patches are only
in one place.
- you pull the patches into the
On 09/05/2011, at 12:34, Manuel M T Chakravarty wrote:
> Simon Marlow:
>>
>> - you develop in your working tree and commit patches there. At
>> this point it's completely safe to rebase - the patches are only
>> in one place.
>>
>> - you pull the patches into the validate tree (you just rebas
Simon Marlow:
> Some of us are using rebase to avoid merge commits where possible, but it is
> quite easy to get into a mess so I hesitate to suggest rebase as our
> recommended workflow. Ordinary merging works fine modulo the noisy merge
> commits, so I'm happy for people to just do 'git pull'
On 09/05/2011 05:48, Manuel M T Chakravarty wrote:
Simon Peyton-Jones:
It's a long message and I don't understand it.
Suppose we have * A branch * Shared between several people *
Long-lived (weeks not day) how should we manage it?
It *must* be possible to merge fixes from the master into the
b
Simon Peyton-Jones:
> It's a long message and I don't understand it.
>
> Suppose we have
> * A branch
> * Shared between several people
> * Long-lived (weeks not day)
> how should we manage it?
>
> It *must* be possible to merge fixes from the master into the branch. Doing
> so, and then valida
On Fri, May 06, 2011 at 01:50:29PM -0700, David Terei wrote:
> The way I work which I think works well is:
This seems to me like a lot of effort, and a lot of potential for people
to get in a muddle, just to avoid some harmless merge commits.
Thanks
Ian
The way I work which I think works well is:
1) While developing, do whatever you feel like in your branch. So lots
of merge commits are fine since as pointed out, rebasing can make
multi party collaboration a little difficult at times.
2) When a point is reached where you want to push some work u
On 05/06/11 05:15, Simon Peyton-Jones wrote:
So I think merging the master onto the branch must be done regularly not as a
big bang at the end.
If someone would like to write a duffers guide describing how to do that, I'm
happy to follow it. But the only way I understand is to merge master on
Simon Marlow:
> On 06/05/11 02:05, Manuel M T Chakravarty wrote:
>> There seems to be quite a bit of merging from master into branches
>> going on in the GHC repos at the moment. This isn't necessarily a
>> good way of using Git as Linus explains in this message:
>>
>> http://www.mail-archive.com
see
the disadvantage of this approach. Yet.
Simon
| -Original Message-
| From: cvs-ghc-boun...@haskell.org [mailto:cvs-ghc-boun...@haskell.org] On
Behalf Of
| Manuel M T Chakravarty
| Sent: 06 May 2011 02:06
| To: GHC
| Subject: Git, merging and rebasing
|
| There seems to be qu
On 06/05/11 02:05, Manuel M T Chakravarty wrote:
There seems to be quite a bit of merging from master into branches
going on in the GHC repos at the moment. This isn't necessarily a
good way of using Git as Linus explains in this message:
http://www.mail-archive.com/dri-devel@lists.sourceforge.
Hi Manuel,
What is then the right way to do things? It is not clear to me from Linus's
email. Consider the ghc-generics branch scenario:
- A couple of repos are branched (compiler, ghc-prim, and others), but not
all. These other repos are just using the "master" branch;
- Two people work on it sep
There seems to be quite a bit of merging from master into branches going on in
the GHC repos at the moment. This isn't necessarily a good way of using Git as
Linus explains in this message:
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html
The way I understand it is t
16 matches
Mail list logo
