I think one factor that makes many people stick with SVN is that emulating the
SVN-style workflow in Git is pretty complicated. Let's consider a typical SVN
user's process:
1) Develop one patch at a time.
2) During development, often update his sources to match the repository.
3) When done, create a patch and get it reviewed.
4) When the patch is reviewed, commit it.
The interaction with the version-control system for each of these steps is an
obvious single step with SVN. With git, for at least some of these, you will
end up needing multiple non-obvious (to an SVN user anyway) commands. All of
your examples below for step 2 are complicated and have surprising side effects.
The usual responses to this concern are either "you can write a script to wrap
that" or "you should just change your workflow to get the full power of git".
But neither of these answers is very persuasive to a person happy with the
above workflow. When we had to do the CVS to SVN transition, there was no
hesitation because everyone could still use the exact same workflow, but now it
was also possible to do more stuff.
I do think that with the right project-wide scripts we could abstract away from
the VCS a little and make the transition less painful. I do most of my patch
creation and committing with webkit-patch(*) these days, because it actually
saves steps over the raw tools. However, update-webkit, which handles the
remaining SVN-like workflow step, doesn't follow any of the approaches, instead
it does this:
sub runGitUpdate()
{
# Doing a git fetch first allows setups with svn-remote.svn.fetch =
trunk:refs/remotes/origin/master
# to perform the rebase much much faster.
system("git", "fetch") == 0 or die;
if (isGitSVN()) {
system("git", "svn", "rebase") == 0 or die;
} else {
# This will die if branch.$BRANCHNAME.merge isn't set, which is
# almost certainly what we want.
system("git", "pull") == 0 or die;
}
}
Perhaps improving runGitUpdate() would be one way to make it easier for more
people to try Git.
Regards,
Maciej
(*) I'm not sure offhand if webkit-patch land will take care of all three of
the steps of adding, committing and pushing/dcommiting which the SVN-like
workflow treats as a single step.
On Mar 10, 2012, at 2:58 PM, Joe Mason wrote:
> Well, the more git-idiomatic usage is to "git commit" your work in progress
> often, in particular before updating. This wouldn't touch Node.h at all, it
> just upates the index (in the .git hidden subdir). Then the rebase also
> wouldn't touch Node.h, unless there were changes to it upstream.
>
> I just recommended the stash/update/pop sequence because it more closely
> matched the SVN workflow which you like, and I'm trying to figure out how
> hard it would be to support this workflow with git. I hadn't thought about
> the issue of extra file touches, though - good catch.
>
> Here's a better alternative:
>
> git commit -a -c "temp commit" && git pull --rebase origin/master
> (fix any conflicts and finish the rebase with git rebase --continue if
> necessary)
> git reset HEAD^
>
> Instead of using the stash, that puts all your working copy changes into a
> commit, fetches, and then gets rid of the commit (leaving the changes still
> in the working copy). There might be some weirdness if there are new
> files/subdirs instead of just changes to existing files - I'd need to check
> how that gets handled and possibly tweak some commandline parameters.
> ________________________________
> From: webkit-dev-boun...@lists.webkit.org
> [webkit-dev-boun...@lists.webkit.org] on behalf of Ryosuke Niwa
> [rn...@webkit.org]
> Sent: Friday, March 09, 2012 7:01 PM
> To: Ashod Nakashian
> Cc: WebKit Development
> Subject: Re: [webkit-dev] Moving to Git?
>
> First, a follow up on my old post since my message was cut off in the middle:
> On Thu, Mar 8, 2012 at 1:25 PM, Ryosuke Niwa
> <rn...@webkit.org<mailto:rn...@webkit.org>> wrote:
> On Thu, Mar 8, 2012 at 1:19 PM, Joe Mason
> <jma...@rim.com<mailto:jma...@rim.com>> wrote:
> This is only slightly more complicated
>
> I'd say astoundingly more complicated because of
>
> the fact that you're unapplying changes, updating the checkout, and
> reapplying changes. This seemingly innocent sequence of operations have an
> annoying side-effects of touching all files you've modified locally and
> haven't committed.
>
> So for example if you have any changes to Node.h and run this set of
> operations, then git will touch Node.h twice by stashing and applying. This
> would mean that I would be rebuilding the world even if all changes I get
> from masters were in webkitpy or LayoutTests.
>
> Are there an easy way to work around this issue as well? (other than
> committing changes, of course)
>
> On Fri, Mar 9, 2012 at 3:54 PM, Ashod Nakashian
> <ashodnakash...@yahoo.com<mailto:ashodnakash...@yahoo.com>> wrote:
> After all, what prompted me to raise this issue is because some svn scripts
> are outdated and before fixing them I thought may be there wasn't much use
> for them in the first place (otherwise, someone with a bigger contribution
> volume would certainly have noticed and fixed them sooner than me).
>
> I suspect the only reason the particular bug hadn't been fixed is that we
> have very few contributors who develop on Windows.
>
> - Ryosuke
>
>
> ---------------------------------------------------------------------
> 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.
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
