pcorey / delete-occurrences-of-an-element-if-it-occurs-more-than-n-times

2 stars 0 forks source link

Question - extracting like a tutorial #1

Open santios opened 7 years ago

santios commented 7 years ago

Hello,

Thanks for this. I read the tutorial in your blog. How did you extracted the history and created the blog post?

Thanks!

pcorey commented 7 years ago

Thanks! Do you like that style of post? I'm not sure if people would find it confusing or helpful.

Basically, I have a vimscript that converts a full log of Git diffs into the style of markdown used by my blog.

Running git log --reverse --full-diff --unified=1 -p . will give you the entire Git log (including diffs) in reverse chronological order. You can also diff between commits if you just want a subsection of commits (git log <from-1>..<to> --reverse --full-diff --unified=1 -p .).

I pipe the output of that git log command into a file, and then run this vimscript on it. That does a bunch of edits that outputs the markdown/html output I need to generate a blog post.

santios commented 7 years ago

Hey, sorry for the late response. Thanks for your answer. I think there is a lot to be explored in this area. I'm checking online what people have done related to this. Have you checked this two projects before?

https://github.com/bennorth/literate-git https://github.com/bennorth/git-dendrify/ And, an example of the result using the tools: http://www.redfrontdoor.org/20160813-literate-git-demo/index.html

The challenge I have found is that building the code, and building the tutorial, are completely different dimensions. Your approach is cool and simple, but it requires to tight your git commit history with the tutorial prose. This is ok if you are working alone, but if you have a normal repo history you can't do much.

Do you have other examples of your technique besides this example?

Thank you!

pcorey commented 7 years ago

I agree. I've found that I'll often do a rough pass of implementing the code with rough outlines for what I want to talk about with the commits. If your Git-foo is strong enough, you can go back and polish the history of the repo as much as you want, including splitting/adding/removing/modifying commits to your heart's content.

I'd agree that it would be very difficult for a team, and impossible on a "normal" project. Your Git history is essentially the deliverable you care about, not the code. That's incompatible with normal software development.

I've done quite a few posts like this. Here are a couple that outline the general idea and how I work with the repo.

http://www.east5th.co/blog/2016/07/11/literate-commits/ http://www.east5th.co/blog/2016/09/12/rewriting-history/

And here are a few one-off literate commit style posts:

http://www.east5th.co/blog/2016/07/11/delete-occurrences-of-an-element/ http://www.east5th.co/blog/2016/07/20/point-in-polygon/ http://www.east5th.co/blog/2016/07/27/molecule-to-atoms/ http://www.east5th.co/blog/2016/08/03/nesting-structure-comparison/ http://www.east5th.co/blog/2016/08/10/the-captains-distance-request/ http://www.east5th.co/blog/2016/08/17/advent-of-code-not-quite-lisp/

I also did a large scale project in this style, to see how it would carry over past simple katas:

http://www.east5th.co/blog/2016/08/31/phoenix-todos-part-1/ http://www.east5th.co/blog/2016/09/07/phoenix-todos-part-2/ http://www.east5th.co/blog/2016/09/14/phoenix-todos-part-3/ http://www.east5th.co/blog/2016/09/21/phoenix-todos-part-4/ http://www.east5th.co/blog/2016/09/28/phoenix-todos-part-5/ http://www.east5th.co/blog/2016/10/05/phoenix-todos-part-6/ http://www.east5th.co/blog/2016/10/12/phoenix-todos-part-7/ http://www.east5th.co/blog/2016/10/19/phoenix-todos-part-8/ http://www.east5th.co/blog/2016/10/26/phoenix-todos-part-9/ http://www.east5th.co/blog/2016/11/09/phoenix-todos-part-10/ http://www.east5th.co/blog/2016/11/16/phoenix-todos-part-11/

santios commented 7 years ago

Thanks, Pete. Will check this out.