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