[webkit-dev] Moving to Git?

[Joe Mason]

Well, not quite. The equivalent to "svn up" is "git pull --rebase origin/master" (which should be the default, as git merge is the bit that horribly confuses people - but I digress).  I'm not sure if it will fill in the origin/master part automatically.

What Ryosuke seems to be complaining about is that if you have changes to your working copy, "svn up" will automatically merge them, which could lead to conflicts you have to untangle, while "git pull --rebase" will give an error telling you you must commit or stash them first.  So the real equivalent to "svn up" is "git stash && git pull --rebase origin/master && git stash pop".  And "git stash pop" will start pretty much the same merging process as svn's if there are conflicts.

This is only slightly more complicated, and has the benefit that if something goes wrong, your changes remain explicitly in the git stash, where you can get at them with commands like "git stash show" or "git stash branch", whereas unless svn has features I don't know about, if "svn up" does unexpected things the only record of your changes is a series of conflict markers you'll need to resolve.

And you can always make a "git-up" script that does "git stash && git pull --rebase origin/master && git stash pop", so the command you type won't even be any longer than "svn up", but will give you more safety.
________________________________________
From: webkit-dev-bounces at lists.webkit.org [webkit-dev-bounces at lists.webkit.org] on behalf of Hugo Parente Lima [hugo.lima at openbossa.org]
Sent: Thursday, March 08, 2012 3:45 PM
To: webkit-dev at lists.webkit.org
Subject: Re: [webkit-dev] Moving to Git?

On Thursday 08 March 2012 17:12:47 Ryosuke Niwa wrote:
> On Thu, Mar 8, 2012 at 12:04 PM, Adam Treat <atreat at rim.com> wrote:
> > There is nothing about git that forces you to have multiple branches
> > locally.  Good practice, yes, but nothing forcing it.  As for the
> > difficulty of resolving conflicts between patches you've made locally and
> > changes made on the shared repository since you started making your local
> > patches... nothing about git makes this any harder.  Unless you have a
> > lock based source control system you'll have to resolve conflicts.
>
> On Thu, Mar 8, 2012 at 12:05 PM, Joe Mason <jmason at rim.com> wrote:
> > It seems to me that there's no need to use multiple local branches in git
> > if you find it confusing - it's an additional feature, but I don't see
> > anything that requires it.
> >
> > What workflow do you have that requires you to have multiple branches
> > locally in git, and how do you solve it in svn without using branches?
> >
> > What precisely do you find difficult about merging remote changes, and
> > how is the svn equivalent easier?
>
> The simplicity. In git, I have to worry about things like committing local
> changes before rebasing to master, or stashing, etc... In svn, all I have
> to do is to run "svn up".

"git pull" does the same (if no conflicts were found, but the same pain will
happen on svn in case of conflicts)

or "git fetch origin; git rebase origin/master"

I remember the days were I switched from svn to git, blaming git for force me
to type additional commands, today I'm just regrets for the blames and can't
think in another VCS than git :-).

> - Ryosuke

--
Hugo Parente Lima
INdT - Instituto Nokia de Tecnologia

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.