[webkit-dev] Moving to Git?
Maciej Stachowiak
mjs at apple.com
Sat Mar 10 15:35:17 PST 2012
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-bounces at lists.webkit.org [webkit-dev-bounces at lists.webkit.org] on behalf of Ryosuke Niwa [rniwa at 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 <rniwa at webkit.org<mailto:rniwa at webkit.org>> wrote:
> On Thu, Mar 8, 2012 at 1:19 PM, Joe Mason <jmason at rim.com<mailto:jmason at 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 <ashodnakashian at yahoo.com<mailto:ashodnakashian at 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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
More information about the webkit-dev
mailing list