Change to git?

[Samuel Ytterbrink]

Hi all!

I have a old proposal, but with this time a solution. Lets move to git.

Why git? well to be honest cause i think git is superior in many ways( speed to name one). but mostly cause i know the work flow of git and there is no good documentation on workflows i hg. I have tried to adapt my work flow to hg and found that its very hard to do so.

I still understand a no, cause one mans wish is not what you should use as an excuse to switch tools. How ever i found this: http://hg-git.github.com/

And bitbucket now supports git so what im actually are suggesting is to have(at least for some time) 2 repos, one git and one hg, on bit bucket hand have someone( me) merge the 2, and then have a evaluation at a later date.

The hg-git extension seams to have a problem dealing with named branches, and its old... 2009... but seams to be able to export in a okay format, and probably able to import it with out loosing any info( as they state).

Hope this was clear and are readable, im of to bed( need sleep).

--
//Samuel Ytterbrink

[Rafael Capucho]

Hello Samuel,

How're you Samuel? =)

So, When I stated to use one distributed revision control I saw a little bit of git, Mercurial and Bazaar.

I choose Mercurial and after that I start to learn Mercurial.

Some weeks ago, I did an voluntary course in the university about Mercurial.

I believe that Mercurial is amazing.

To be sure, I don't know what is the problem that you have with Mercurial.

And Mercurial is made in Python, If we that love Python don't use it, who will?

Best Regards.


--

Rafael Capucho

Acrescentar Consultoria & Planejamento

www.acrescentar.com

PGP-Public Key: 2048R/7389A96F pgp.mit.edu
FP: EDB5 CDEE 8442 99CC C92D 9173 6B32 A5C9 7389 A96F

[Samuel Ytterbrink]

2011/11/3 Rafael Capucho <rafael....@gmail.com>

Hello Samuel,

How're you Samuel? =)

I'm good, a little bit nervous since im waiting for a reply about a job opportunity.

 

So, When I stated to use one distributed revision control I saw a little bit of git, Mercurial and Bazaar.

I choose Mercurial and after that I start to learn Mercurial.

Some weeks ago, I did an voluntary course in the university about Mercurial.

I believe that Mercurial is amazing.

hg is amazing, it's just that git is even more amazing.

 

To be sure, I don't know what is the problem that you have with Mercurial.

And Mercurial is made in Python, If we that love Python don't use it, who will?

Well in my opinion this is a dangerous way to think. Don't get me wrong i love Python and recommend almost everyone to learn it. But i don't want to use something that i think is less useful then something else only because it is written in Python and the other is not. Besides you should pick the language that fits the problem the best, not only the one you like the most. And i have felt( not in this project) that hg is slow, and that i dont like there branching modle or there view on history management and... well the list can be made long but to be short read this.

http://whygitisbetterthanx.com/#cheap-local-branching

My typical work flow with git is:

 1) clone the main repo to a public repo

 2) clone that repo to a private

 3) create a new branch(dev)

 4) push dev to your public

 5) do the following:

   a) if changes have been found upstream:

     i. pull changes from main:master to public:master and private:master

     ii. rebase dev on master

     iii. rebase all others on dev

   b) if you need to implement anything create a new branch from dev

   c) if you are finished with something fast-forward with dev and rebase all other branches(except master)

   d) if you have something you want others tho actually fastforward dev on master and push

   e) if you have some code or other branched material push that branch to your public(and you can remove it later).

   g) if there are any branches that are unneeded you can delete them( hg only hides them).

the point is that master is totally synchronized and its history frozen if if you push any thing to it then every body should merge it to there own, and every ones master will have the same history. Dev branches however are your personal view of the project, still something not really that experimental, there is nothing in dev that you wouldn't want any one to try out or read. Dev history is however subject to change, by rebasing on a merged master. The other branches are your secrete progress, you can do what ever you like in them, they will never( if you dont want to) show up in any of the public branches history. 

If you can show me how to implement this with hg without any bigger trouble then i can understand that there is nothing wrong with hg, but i have tried this since the last time i brought up this discussion.

 

Also the documentation that can be found on the web for hg is horrible. So manny ways to do the same thing, or only maybe. Seams as hg have had a lots of work arounds in the pasts and there a re more documentation on them then how you really handel the problems to day.

Best Regards.


--

Rafael Capucho

Acrescentar Consultoria & Planejamento

www.acrescentar.com

PGP-Public Key: 2048R/7389A96F pgp.mit.edu
FP: EDB5 CDEE 8442 99CC C92D 9173 6B32 A5C9 7389 A96F

On Wed, Nov 2, 2011 at 9:45 PM, Samuel Ytterbrink <nep...@gmail.com> wrote:

Hi all!

I have a old proposal, but with this time a solution. Lets move to git.

Why git? well to be honest cause i think git is superior in many ways( speed to name one). but mostly cause i know the work flow of git and there is no good documentation on workflows i hg. I have tried to adapt my work flow to hg and found that its very hard to do so.

I still understand a no, cause one mans wish is not what you should use as an excuse to switch tools. How ever i found this: http://hg-git.github.com/

And bitbucket now supports git so what im actually are suggesting is to have(at least for some time) 2 repos, one git and one hg, on bit bucket hand have someone( me) merge the 2, and then have a evaluation at a later date.

The hg-git extension seams to have a problem dealing with named branches, and its old... 2009... but seams to be able to export in a okay format, and probably able to import it with out loosing any info( as they state).

Hope this was clear and are readable, im of to bed( need sleep).

--
//Samuel Ytterbrink

--
//Samuel Ytterbrink

[Olof Bjarnason]

2011/11/3 Samuel Ytterbrink <nep...@gmail.com>:

Have you tried the built-in rebase extension of hg?

http://mercurial.selenic.com/wiki/RebaseExtension

[Samuel Ytterbrink]

2011/11/3 Olof Bjarnason <olof.bj...@gmail.com>

I have looked at it a little bit, but its not a full featured rebase compared to git. And the most importent thing is how hg handels branches from the beginning. Still i guess il just need to stick with hg.... a little bit longer. At least this conversation was enlightening.

--
//Samuel Ytterbrink

[Olof Bjarnason]

I know that git is technically superior to hg in many ways -
performance, model, community - but that does not mean it is right for
pytddmon.

Note that pytddmon already has made a move in the past - from
launchpad/bzr to bitbucket/hg. It is not the funniest of things to do,
and on this mailing list, Samuel seems to be the only one really
advocating making the move.

I do see the point of doing rebases - merging patches "in the past"
should generally be much simpler than doing merges on the front. It
does encourage "large refactorings" like Samuel has done the last
week(s), which I'm kind of ambivalent about, but from a pragmatic
viewpoint I see the value of it.

So Samuel - if you could try out rebase on your current branch(es),
and come back to the mailing list to tell us how it went, it would be
great.

[Olof Bjarnason]

2011/11/3 Olof Bjarnason <olof.bj...@gmail.com>:

> I know that git is technically superior to hg in many ways -
> performance, model, community - but that does not mean it is right for
> pytddmon.
>
> Note that pytddmon already has made a move in the past - from
> launchpad/bzr to bitbucket/hg. It is not the funniest of things to do,
> and on this mailing list, Samuel seems to be the only one really
> advocating making the move.
>
> I do see the point of doing rebases - merging patches "in the past"
> should generally be much simpler than doing merges on the front. It
> does encourage "large refactorings" like Samuel has done the last
> week(s), which I'm kind of ambivalent about, but from a pragmatic
> viewpoint I see the value of it.

Note: what I am ambivalent about, is large refactorings in general,
not Samuels refactorings the last few weeks. What Samuel has done
(separating GUI from logic, multiprocess support, etc.) is great!

[Samuel Ytterbrink]

Well thanks, i still need to make those tests, but im right now fixing a chair ^^. Can be good to have something to sitt on when coding ^^.

Thx again for all support and opinions in the small but good pytddmon community.

--
//Samuel Ytterbrink

[Samuel Ytterbrink]

wow, while trying to get raound hg rebasing and stuff i needed to read more on there named branches and found this:

http://mercurial.selenic.com/wiki/NamedBranches

Read the second last section about Undoing a Bad Merge.

Sounds realy bad that you cant undo a merge.

2011/11/3 Samuel Ytterbrink <nep...@gmail.com>

--
//Samuel Ytterbrink