Comparing Git Workflows • Hacker News Board

Re: Comparing Git Workflows

#101

Post by apparentlymart » Sat, May 28, 2016, 3:31 PM UTC

adamc wrote: post #90

drewg123 wrote: post #4

One of the things I hate about the traditional git workflows describe there is that there is no squashing and the history is basically unusable. We have developers where I work that use our repo as a backup, then when things are merged to master, the history is littered with utter garbage commits like the following: "commit this before I get on the plane" "whoops, make this compile" "WTF?" These add no benefit to his…

For those of us working in domains where auditors might care what has happened, there's a constraint: Auditors want the commit history to reflect what really happened, not the sanitized version of same. One of the nice things about git is that you can have a fork with a clean commit history and an "official" repo that reflects the real history of its merges.

That would seem to suggest that you commit either after every keypress or at least before using the backspace or delete keys, right?

It feels to me that "what really happened" only really applies to "what did we release?" rather than "how did we get to what we released?". Completely agreed that every release should be tracked in version control without modifications, but I'm skeptical that auditors care that you forgot to run the linter before committing and then you did a follow-up commit to add a semicolon where one was missed, but all of that happened between releases.

Re: Comparing Git Workflows

#102

Post by apparentlymart » Sat, May 28, 2016, 3:33 PM UTC

harperlee wrote: post #48

jasode wrote: post #43

Earlier quoted context omitted.

>--every commit should compile, No, that advice is wrong and not relevant to a git private branch. That strict & disciplined attitude about commits was relevant for older centralized source control tools with lock/checkout/checkin/unlock such as CVS and SVN. In that previous scenario, your colleagues depended on the shared repo to properly compile and therefore, you shouldn't "break the build" and derail the team. >e…

But if I commit on a whim, e.g. before jumping on the plane, how can I then patch to separate some changes in two commits?

git rebase -i master

Re: Comparing Git Workflows

#103

Post by jimbobimbo » Mon, May 30, 2016, 9:59 PM UTC

dpc_pw wrote: post #66

zmmmmm wrote: post #65

It amazes me how the entire software industry seems to be adapting its workflows around the necessity of making Git usable. While there are certainly other positive attributes about some of these workflows, the main reason people use them in my experience is because "if you don't use workflow X you get undesirable problem Y with Git". Most of these problems simply didn't exist or were not nearly as severe with previo…

"Most of these problems simply didn't exist or were not nearly as severe with previous revision control systems" Are you kidding? :) CVS, Subversion, Perforce, and some propriety revisioning systems were HUGE PITA. People used to lock files, so noone else could change them when they were working with them. Merging different feature branches was like locking whole repository with huge lock, so noone else could touch a…

In Subversion you'd need to explicitly lock the file, it doesn't require it. Merge the is also not as bad as you're describing. I actually had more headaches with merges in Git than in Subversion.

Re: Comparing Git Workflows

#104

Post by adamc » Wed, Jun 08, 2016, 3:17 AM UTC

apparentlymart wrote: post #101

adamc wrote: post #90

Earlier quoted context omitted.

For those of us working in domains where auditors might care what has happened, there's a constraint: Auditors want the commit history to reflect what really happened, not the sanitized version of same. One of the nice things about git is that you can have a fork with a clean commit history and an "official" repo that reflects the real history of its merges.

That would seem to suggest that you commit either after every keypress or at least before using the backspace or delete keys, right? It feels to me that "what really happened" only really applies to "what did we release?" rather than "how did we get to what we released?". Completely agreed that every release should be tracked in version control without modifications, but I'm skeptical that auditors care that you forg…

It really doesn't matter why you (or I) think. It matters what the auditors will accept.