Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Do you ever truly use your revision history?

news.ycombinator.com

Post reply on HN
Print view View original

281–287 of 287 posts

Re: Ask HN: Do you ever truly use your revision history?

#281

Post by JohnFen »

mandeepj wrote: post #268
bonestamp2 wrote: post #177

Earlier quoted context omitted.

> I am forever grateful to past engineers for outlining WHY they made their changes, and not WHAT the changes were per se. So true, we have this one senior developer who gets mad if someone's algorithm isn't as efficient as it could be (fair enough I suppose). But we can't get him to use commit messages that are more than 1-3 words and simply mention a word or three about the area of code that was changed. Years late…

"What was changed is easily seen in the commit itself, why needs to be in the commit message." Commit message is like subject of an email. Is n't it faster to look at commit message, and get an idea about change rather than go through commit and understand it?

The first line of the commit message should be the "subject line". The rest of the commit message should contain a summary of the high-level stuff such as the "why".

Re: Ask HN: Do you ever truly use your revision history?

#282

Post by jolmg »

I do. Most often I get that value when looking through the repeated blame output of a particular piece of code. I facilitated that through this tool I wrote:

https://github.com/jolmg/git-reblame

Last time I used it was last week to see how a particular piece of code was developed throughout the years. There was a comment that didn't explain some puzzling details, and it helped to make sense of it by seeing how the code changed from the time the comment was written.

Re: Ask HN: Do you ever truly use your revision history?

#283

Post by dang »

sjg007 wrote: post #70
DanielBMarkham wrote: post #59

Earlier quoted context omitted.

This is good. I'm stealing it. It's using git as sort of a super-brain, helping you remember stuff you wouldn't otherwise. It's how I use gmail. Instead of shooting for inbox zero, I just leave anything in there that I might want to remember later and delete the rest. Then, many times years later, I can search through looking for important correspondence. Both of these stories are good examples of how simple but flex…

I use gmail the same way. I do feel that the search functionality could be improved though which I find ironic.

I use gmail that way too! Never made the connection to the git thing though.

Re: Ask HN: Do you ever truly use your revision history?

#284

Post by dang »

teddyh wrote: post #239
dang wrote: post #19

Frequently. Just this evening I was looking in the HN repository for the last version of the code that pg wrote, to remind myself how he used to do something. One of my favorite tricks is to make a file out of all the changes in the history: git log -p > bigass and then grep through the file (edit: which I like to do in Emacs—hence the file) to see every appearance of some construct. There's a lot of knowledge in the…

> git log -p > bigass > and then grep through the file (edit: which I like to do in Emacs—hence the file) Since you already have Emacs, I would suggest you do M-& git log -p RET instead. No need to round-trip the data through a file.

I had a feeling someone would come up with a suggestion like this! Cunningham's Law and all that. Posting wrong or insufficient things on the internet is a great learning strategy.

However, I get:

  WARNING: terminal is not fully functional
  -  (press RETURN)
and on pressing return, I only get enough data to fill the buffer.

Re: Ask HN: Do you ever truly use your revision history?

#285

Post by dang »

granshaw wrote: post #248
dang wrote: post #19

Frequently. Just this evening I was looking in the HN repository for the last version of the code that pg wrote, to remind myself how he used to do something. One of my favorite tricks is to make a file out of all the changes in the history: git log -p > bigass and then grep through the file (edit: which I like to do in Emacs—hence the file) to see every appearance of some construct. There's a lot of knowledge in the…

I’m stealing this too! I often try to persist exploratory history as separate remote branches, but for some reason a lot of the devs I’ve worked with are very adamant about deleting any and all “unneeded” branches, and I end up appending such branch names with a “-dont-delete”, but that starts to get abit passive aggressive. Now I can just do this and nobody needs to know

Or at least by the time they know, it will be too late :)

There are some disadvantages. It can mess with git bisect, for example.

Re: Ask HN: Do you ever truly use your revision history?

#286

Post by kragen »

dang wrote: post #284
teddyh wrote: post #239

Earlier quoted context omitted.

> git log -p > bigass > and then grep through the file (edit: which I like to do in Emacs—hence the file) Since you already have Emacs, I would suggest you do M-& git log -p RET instead. No need to round-trip the data through a file.

I had a feeling someone would come up with a suggestion like this! Cunningham's Law and all that. Posting wrong or insufficient things on the internet is a great learning strategy. However, I get: WARNING: terminal is not fully functional - (press RETURN) and on pressing return, I only get enough data to fill the buffer.

I always set PAGER=cat in Emacs. If you're running a VT100 emulator in Emacs this may be bad, otherwise it avoids the problem your describe.

Re: Ask HN: Do you ever truly use your revision history?

#287

Post by zaccusl »

It's not too hard to migrate from SVN to Git.

I did this for a 15+ year old very large code base. I tried various recommended techniques but everything would fail at some point or another (usually after many, many hours) and I'd have to start over.

Finally I wrote a very simple program with logging where the logging also records the current state and on any failure I could start from any point in the log.

The idea was simple.

1. Check out SVN version N

2. Parse the changed files list for file between commit N and N - 1

3. Copy those files to the Git folder

4. Parse the commit log for version N to get the commit date, committer name, and commit message

5. Commit in Git using "[@] " (this preserving the original commit information)

6. Repeat with N + 1.

If it fails at anytime then simply reset both SVN and Git to the last successful commit and restart. I also did a binary compare of the entire directory tree every 100 commits to ensure the copies were identical.

The process took about two weeks running all day and night (since one commit at a time is very slow) but it was very robust and left a perfect version history.

To deal with the fact that the SVN repo was still live, I believe I mirrored (or something like that) the repo and would sync between my local mirror and the live repo every couple of days. When my program caught up with the live repo we just stopped commits for a few hours while I wrapped everything up and then archived the SVN repo.

Post reply on HN