5 ms·

Oh hey, that's my post! Glad someone found it interesting enough to submit. Don't expect this to hit critical mass by now, but happy to answer questions on th

Oh hey, that's my post! Glad someone found it interesting enough to submit. Don't expect this to hit critical mass by now, but happy to answer questions on the rewriting thing if anyone has any.

funkattack 7y ago
Slide #39 seems to use a graph from https://marklodato.github.io/visual-git-guide/index-en.html#reset https://marklodato.github.io/visual-git-guide/index-en.html#... , that is published under "Attribution-NonCommercial-ShareAlike 3.0 United States (CC BY-NC-SA 3.0 US)". This should be credited appropriately and your content should be shared alike.
- acemarke 7y ago
  Yeah, I grabbed a bunch of images from various sources for the slides. Unfortunately, I was in a hurry and didn't record all the places I got them originally. I'll try to find time to go through and attribute things. Thanks for the heads-up!
  - funkattack 7y ago
    In my book "credited appropriately" reads like, put the site down till you have done your homework!
    - acemarke 7y ago
      Look, I'm at work. I agree that it needs to be updated, and will do it as soon as I have time.
jeanmichelx 7y ago
Cool post, i wish I could do something similar at work. I'm wondering why you went through the pain of making an HTTP server to process JS files, instead of say putting the temporary file over a ramdisk and running the formatters in parallel over multiple files. Plus, even if it's slow, you only have to run it a few times right?
- acemarke 7y ago
  A RAM disk never even crossed my mind :) I know they exist and have used one in the past, but it didn't occur to me as a possible tool. Also, I was doing this on Windows, and I don't even know if you _can_ set up a RAM disk on Windows. (edit and of course as I say that, someone literally just linked a Windows RAM disk FS driver upthread.) And no, I was re-running this _dozens_ of times to get it right, especially when I was in the "run -> transform fails on broken JS code -> debug -> write regex -> rerun" portion.
  - jeanmichelx 7y ago
    Ah makes sense you want to be fast then! Thanks for your answer
dahart 7y ago
Reading the approach you took for reformatting code, I was curious whether after you’d done it, it still seemed worth using the python+libgit2 approach? Do you know how long the shell approach would have taken without using libgit2? Did it save time overall to use the lower level approach, including the presumably extra coding time? The code formatter was probably the limiting run-time factor, no? When I’ve used filter-branch and BFG in the past, I had to run the whole batch multiple times before I got it correct, and before I was sure the result was safe... did you have to do that, run the filter multiple times? Would you take the same approach if you had to do it again from scratch? I’m curious if I should invest in this approach next time it comes up for me.
- acemarke 7y ago
  Yes, it was definitely worth it, for multiple reasons: - I'm a lot more comfortable with Python than I am with shell scripting - The Python+libgit2 approach _absolutely_ saved time. Being able to iterate through commits in 4-ish hours vs 24 hours for a complete run was huge, and yes, I did a lot of partial runs to test how the process was going. - Yes, the code rewriting portion ended up as the bulk of the time. I could do a no-op iteration of the commit history in about 30 minutes, and the final processing was about 4.5 hours. If I ever needed to do this again, yes, I'd use basically the same approach, just with the advantage of applying the knowledge I learned right away.
deleted 7y ago
[deleted]

Oh hey, that's my post! Glad someone found it interesting enough to submit. Don't expect this to hit critical mass by now, but happy to answer questions on the rewriting thing if anyone has any.

funkattack 7y ago

Slide #39 seems to use a graph from https://marklodato.github.io/visual-git-guide/index-en.html#reset https://marklodato.github.io/visual-git-guide/index-en.html#... , that is published under "Attribution-NonCommercial-ShareAlike 3.0 United States (CC BY-NC-SA 3.0 US)". This should be credited appropriately and your content should be shared alike.

acemarke 7y ago
Yeah, I grabbed a bunch of images from various sources for the slides. Unfortunately, I was in a hurry and didn't record all the places I got them originally. I'll try to find time to go through and attribute things. Thanks for the heads-up!
- funkattack 7y ago
  In my book "credited appropriately" reads like, put the site down till you have done your homework!
  - acemarke 7y ago
    Look, I'm at work. I agree that it needs to be updated, and will do it as soon as I have time.

jeanmichelx 7y ago

Cool post, i wish I could do something similar at work. I'm wondering why you went through the pain of making an HTTP server to process JS files, instead of say putting the temporary file over a ramdisk and running the formatters in parallel over multiple files. Plus, even if it's slow, you only have to run it a few times right?

acemarke 7y ago
A RAM disk never even crossed my mind :) I know they exist and have used one in the past, but it didn't occur to me as a possible tool. Also, I was doing this on Windows, and I don't even know if you _can_ set up a RAM disk on Windows. (edit and of course as I say that, someone literally just linked a Windows RAM disk FS driver upthread.) And no, I was re-running this _dozens_ of times to get it right, especially when I was in the "run -> transform fails on broken JS code -> debug -> write regex -> rerun" portion.
- jeanmichelx 7y ago
  Ah makes sense you want to be fast then! Thanks for your answer

dahart 7y ago

Reading the approach you took for reformatting code, I was curious whether after you’d done it, it still seemed worth using the python+libgit2 approach? Do you know how long the shell approach would have taken without using libgit2? Did it save time overall to use the lower level approach, including the presumably extra coding time? The code formatter was probably the limiting run-time factor, no? When I’ve used filter-branch and BFG in the past, I had to run the whole batch multiple times before I got it correct, and before I was sure the result was safe... did you have to do that, run the filter multiple times? Would you take the same approach if you had to do it again from scratch? I’m curious if I should invest in this approach next time it comes up for me.

acemarke 7y ago
Yes, it was definitely worth it, for multiple reasons: - I'm a lot more comfortable with Python than I am with shell scripting - The Python+libgit2 approach _absolutely_ saved time. Being able to iterate through commits in 4-ish hours vs 24 hours for a complete run was huge, and yes, I did a lot of partial runs to test how the process was going. - Yes, the code rewriting portion ended up as the bulk of the time. I could do a no-op iteration of the commit history in about 30 minutes, and the final processing was about 4.5 hours. If I ever needed to do this again, yes, I'd use basically the same approach, just with the advantage of applying the knowledge I learned right away.

deleted 7y ago

[deleted]