On Oct 9, 2007, at 12:35 AM, Brady Eidson wrote:


On Oct 8, 2007, at 11:30 PM, Oliver Hunt wrote:

The average user uses update-webkit + some manual work, svn-create- patch, svn-apply-patch Behind the scenes these do, svn up, svn diff + some magic, patch + magic

Yup

Under git they would be
git fetch && git rebase origin/master + unfortunately some manual work (described below)
git diff master + some magic
patch + magic

That "unfortuantely some manual work" is currently a huge wrench in my cog.
the unforunately some manual work is the same manual work as would be needed for an svn merge -- i had forgotten about merge conflicts in svn, because i primarily get conflicts in changelogs so they didn't register initially. I remember conflicts in git as i have spent a reasonable amount of the past few weeks dealing with merge conflicts from merging branches together.

The svn process is very linear, and a "one time" thing per update. I just went through the process of being asked to do multi-step merges on the same file spread out over multiple git commits, and having git-mergetool bring up a blank document in each half of the diff utility window.

This is not friendly.

Ah yes, I think you need to run git-mergetool from the root of your repository, that is definitely a bad thing though.

Although i'm not sure why would be ending up with multiple merges for a single patch.


What makes this simple, single branch development more tricky with git is that git has the idea of local history, so it is necessary to commit locally prior to updating, and then extra work is needed if you want to retain a single patch for the final commit. We would need to work out what the standard workflow should be in this mode.

Thats what I'm requesting we do - and make it as clear, simple, and "bulletproof" as our current svn process. (note - not claiming the current svn process *is* bulletproof, just that the git process be *as* bulletproof)
Agreed

So it is more difficult when doing simple single branch development, but not insurmountably so, it gets more copmlicated once you start dealing with many branches but that's not something you can do with svn even if you wanted to.

Watching Mark Rowe periodically struggle to get potential new developers up to speed with the current SVN procedure makes this statement worrisome to me. IMHO, making it "more difficult, but not insurmountably so" translates to "turn away even more people who are casually interested in the project but might end up being serious contributers if they're able to get their feet sufficiently wet"

That does worry me as well, otoh as i say the basics are not overly difficult, and with decent scripts backing everything i don't see it being too problematic, but then i've never had a problem with cvs or svn, but did have some issues with git. Although i would argue that was due to the mismatch in my knowledge of svns vs. git's behaviour.

--Oliver

~Brady


_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to