> Even though git could be used in the same way as svn, why migrate just to > re-create the current workflow? Doesn't make too much sense to me. A > migration to git would have to include some other benefit, not just be > change for the sake of it.I think our routine workflow suffers quite a bit from the svn emphasis. Sending text patches is all very well from a portability point, but it makes applying someone else's commits rather annoying (particularly for commit, but even for testing): 1. Download the patch. 2. Remember where you put it (~/Downloads, ~, ~/Documents -- depends on exactly what program downloaded it) and what the name of the file was. 3. Either look or randomly guess what -pN you need to apply it. 4. Check things. 5. Open the blasted file again to recover the commit message (frequently weirdly indented because that's what "git show" produces). Or make one up. 6. Commit with that via copy/paste. 7. Hope you didn't forget to "git/svn add" the new test before committing. This is all you can do in svn (as far as I'm aware), but it's something git has solutions for. Some unified "git fetch" available for this would be very useful for example, even if we do decide a world without monotonic numbers is too scary for us. Tim.
> On Jan 16, 2015, at 6:31 PM, Tim Northover <t.p.northover at gmail.com> wrote: > >> Even though git could be used in the same way as svn, why migrate just to >> re-create the current workflow? Doesn't make too much sense to me. A >> migration to git would have to include some other benefit, not just be >> change for the sake of it. > > I think our routine workflow suffers quite a bit from the svn > emphasis. Sending text patches is all very well from a portability > point, but it makes applying someone else's commits rather annoying > (particularly for commit, but even for testing): > > 1. Download the patch. > 2. Remember where you put it (~/Downloads, ~, ~/Documents -- depends > on exactly what program downloaded it) and what the name of the file > was. > 3. Either look or randomly guess what -pN you need to apply it. > 4. Check things. > 5. Open the blasted file again to recover the commit message > (frequently weirdly indented because that's what "git show" produces). > Or make one up. > 6. Commit with that via copy/paste. > 7. Hope you didn't forget to "git/svn add" the new test before committing. > > This is all you can do in svn (as far as I'm aware), but it's > something git has solutions for. Some unified "git fetch" available > for this would be very useful for example, even if we do decide a > world without monotonic numbers is too scary for us.Most of this is solved by importing the patch with git am. But it works only if the patch was generated from git format-patch. If you want to save also the “download and find the patch file”, any review coming from Phabricator can be committed in a single command, for example: $ arc patch D7003 Mehdi
Once you enforce a linear master branch by requiring only "git merge --no-ff", it's easy enough for a commit hook to add a monotonic tag to each commit. They're very lightweight. Yes, someone needs to write the five lines of code to do that, but that's what you get when you use a SCM construction kit instead of a one-size-fits-all solution. Incidentally, about splitting submodules out. NOOOOOOOOOO! I checked out out the all in one https://github.com/chapuni/llvm-project.git repository. It took 2 minutes (to New Zealand) and the resulting .git directory is 581 MB. For the entire history of everything! That's utterly trivial. Less than a dollar worth of fast SSD, or maybe three cents of spinning rust. Why would you want to split that up and lose atomic commits and bisect across different parts? On Sat, Jan 17, 2015 at 3:31 PM, Tim Northover <t.p.northover at gmail.com> wrote:> > Even though git could be used in the same way as svn, why migrate just to > > re-create the current workflow? Doesn't make too much sense to me. A > > migration to git would have to include some other benefit, not just be > > change for the sake of it. > > I think our routine workflow suffers quite a bit from the svn > emphasis. Sending text patches is all very well from a portability > point, but it makes applying someone else's commits rather annoying > (particularly for commit, but even for testing): > > 1. Download the patch. > 2. Remember where you put it (~/Downloads, ~, ~/Documents -- depends > on exactly what program downloaded it) and what the name of the file > was. > 3. Either look or randomly guess what -pN you need to apply it. > 4. Check things. > 5. Open the blasted file again to recover the commit message > (frequently weirdly indented because that's what "git show" produces). > Or make one up. > 6. Commit with that via copy/paste. > 7. Hope you didn't forget to "git/svn add" the new test before committing. > > This is all you can do in svn (as far as I'm aware), but it's > something git has solutions for. Some unified "git fetch" available > for this would be very useful for example, even if we do decide a > world without monotonic numbers is too scary for us. > > Tim. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150117/cb31bf3d/attachment.html>
> Most of this is solved by importing the patch with git am. But it works only if the patch was generated from git format-patch.Trouble is, that's not what we get, or at least nowhere near often enough to even bother learning that tool.> If you want to save also the “download and find the patch file”, any review coming from Phabricator can be committed in a single command, for example: > > $ arc patch D7003Yeah, I'm not installing PHP locally just for a non-standard arc tool. I'm quite happy with what Phabricator does on the web, but it should present standard interfaces for clients (like a git branch/tag). Tim.
On Sat, Jan 17, 2015 at 2:31 AM, Tim Northover <t.p.northover at gmail.com> wrote:> > Even though git could be used in the same way as svn, why migrate just to > > re-create the current workflow? Doesn't make too much sense to me. A > > migration to git would have to include some other benefit, not just be > > change for the sake of it. > > I think our routine workflow suffers quite a bit from the svn > emphasis. Sending text patches is all very well from a portability > point, but it makes applying someone else's commits rather annoying > (particularly for commit, but even for testing): > > 1. Download the patch. > 2. Remember where you put it (~/Downloads, ~, ~/Documents -- depends > on exactly what program downloaded it) and what the name of the file > was. > 3. Either look or randomly guess what -pN you need to apply it. > 4. Check things. > 5. Open the blasted file again to recover the commit message > (frequently weirdly indented because that's what "git show" produces). > Or make one up. > 6. Commit with that via copy/paste. > 7. Hope you didn't forget to "git/svn add" the new test before committing. > > This is all you can do in svn (as far as I'm aware), but it's > something git has solutions for. Some unified "git fetch" available > for this would be very useful for example, even if we do decide a > world without monotonic numbers is too scary for us. >Personally one of the things I really like about LLVM is precisely this "human" aspect of applying patches from the mailing list for people without commit access. It adds some extra human redundancy around all-important new-contributor patches where almost by definition you will need to provide some human feedback to the contributor in order to help their next patch be better (and determining what feedback to give and cogently formulating it is much more work than copypasting some stuff or guessing a -pN). Having patch application fully automated only matters IMO if this this form of patch application is the primary way work gets integrated into the mainline; but that is not the case, since the primary way work gets committed on the mainline in the LLVM project is by trusted contributors with post-commit review (compare to e.g. Linux where patch application *is* the primary way that work gets integrated into the mainline, so it makes sense to have the process highly automated). -- Sean Silva> > Tim. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150120/04326b3d/attachment.html>