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

Git Reflow

github.com

Post reply on HN
Print view View original

11–20 of 80 posts

Re: Git Reflow

#11

Post by andrewchilds »

32bitkid wrote: post #5

The "squash and merge" trend with git bothers me, and perhaps I'm "doing it wrong" but it just doesn't capture what I need a commit history/git-blame for. Usually, I don't care what feature a line code was for. I want to know why a developer thought that was the right change. And to get that visibility I tend to make lots of commits, treating commits almost as out-of-band comments that don't clutter the file/repo. Wh…

Agreed, I'd much rather have the context of the commit message than the context of an entire PR, which could be a combination of 20 discrete changes, each with their own reason for existing which is explained by the commit message. If I need more context, which almost never happens, I'll just go check out the PR on GitHub.

Re: Git Reflow

#12

Post by CJefferson »

32bitkid wrote: post #5

The "squash and merge" trend with git bothers me, and perhaps I'm "doing it wrong" but it just doesn't capture what I need a commit history/git-blame for. Usually, I don't care what feature a line code was for. I want to know why a developer thought that was the right change. And to get that visibility I tend to make lots of commits, treating commits almost as out-of-band comments that don't clutter the file/repo. Wh…

I agree, I wish some VCS would figure out how to do a "history of history". I hate every time in git I destroy history (delete a branch, do a force push / update), but it is almost impossible to use git without doing these things, particularly when committing to another project.

Re: Git Reflow

#13

Post by pcl »

sergiosgc wrote: post #10
pcl wrote: post #6

Earlier quoted context omitted.

I'm with you. History is mostly useful after the fact to understand the details, not the big picture. I wish git had a first-class model of a milestone-ish block of commits, so that the detailed commits and the feature milestones are disambiguated. I try to do this with merge points, but it doesn't seem to always work out, and since it's not native, it depends entirely on convention.

I get close to the milestone-ish commit by opening feature branches and then merging with no fast forward. All commits in the main branch are merges, and all of those are features. The feature incremental commits go in the branch. It's ok, I'd just like to be able to apply this structure to stuff like bisect or blame.

Yeah exactly -- if git knew about a milestone point, then "git bisect" could tie into it. That in and of itself would be fantastic.

Re: Git Reflow

#14

Post by bennofs »

andrewchilds wrote: post #7

From the README: $ git reflow setup Please enter your GitHub username: nhance Please enter your GitHub password (we do NOT store this): Your GitHub account was successfully setup! That implies that the username is actually stored somewhere. Is it stored locally or on some reenhanced.com server? The README should be very clear about what exactly gitreflow stores and where.

Perhaps they only use the password to retrieve an OAuth access token which they store? At least that's how the `hub` command line tool handles it afaik.

Re: Git Reflow

#15

Post by npsimons »

32bitkid wrote: post #5

The "squash and merge" trend with git bothers me, and perhaps I'm "doing it wrong" but it just doesn't capture what I need a commit history/git-blame for. Usually, I don't care what feature a line code was for. I want to know why a developer thought that was the right change. And to get that visibility I tend to make lots of commits, treating commits almost as out-of-band comments that don't clutter the file/repo. Wh…

> But there are so many people into it, that I feel I must be missing something obvious and it bothers me.

As someone in favor of squashing, I can say that I don't want to see things like "oops, reverting last commit" popup in my git history, especially if I'm browsing history or bisecting a bug. That's noise - useless data. OTOH, commits should be the Minimum Necessary Change to accomplish a well-defined goal. The code itself should always be clear on what it is doing, otherwise it's badly written. If it's "deep magic", then comment it in the code as such.

That being said, I do think that reasoning for why a change was made, at every level, should be in the commit message. I'm also not a fan of merge, but prefer squash+rebase.

In all cases/workflows, it can be abused, and people writing bad code, bad comments or bad commit messages will do so until you can make them care to do it better. There's no silver bullet.

Re: Git Reflow

#16

Post by bennofs »

sergiosgc wrote: post #10
pcl wrote: post #6

Earlier quoted context omitted.

I'm with you. History is mostly useful after the fact to understand the details, not the big picture. I wish git had a first-class model of a milestone-ish block of commits, so that the detailed commits and the feature milestones are disambiguated. I try to do this with merge points, but it doesn't seem to always work out, and since it's not native, it depends entirely on convention.

I get close to the milestone-ish commit by opening feature branches and then merging with no fast forward. All commits in the main branch are merges, and all of those are features. The feature incremental commits go in the branch. It's ok, I'd just like to be able to apply this structure to stuff like bisect or blame.

Doesn't `git blame --first-parent` work for that? From my quick tests, it seems like it shows the merge commit if you have such a structure (`--first-parent` also works for `git log` etc)

Re: Git Reflow

#17

Post by kiallmacinnes »

juped wrote: post #3

Another "I like to deliberately lose information to no benefit because I'm bad at git" 'workflow' hits Hacker News. Something is deeply wrong with the ecosystem when people want to do things like this!

Some information is worth loosing. Personally, I get exactly zero value from "Fixed a typo", "Fixed that errant semicolon", "fixed tests broken 3 commits ago" commit messages that come hand in hand with a hard and fast "never rewrite history" policy.

If that information is valuable to you, great! This is why we have several ways to do things. The trend you're seeing simply seems to indicate (mildly indicate, at best) that a larger percentage of HN readers prefer to squash and merge.

Each to their own.

Re: Git Reflow

#18

Post by zimbatm »

andrewchilds wrote: post #7

From the README: $ git reflow setup Please enter your GitHub username: nhance Please enter your GitHub password (we do NOT store this): Your GitHub account was successfully setup! That implies that the username is actually stored somewhere. Is it stored locally or on some reenhanced.com server? The README should be very clear about what exactly gitreflow stores and where.

It probably uses the password to create a token. The token is then stored on your computer. This allows the app to get access to github but also makes it easy for you to revoke the token. See https://github.com/settings/tokens

Re: Git Reflow

#19

Post by maxxxxx »

32bitkid wrote: post #5

The "squash and merge" trend with git bothers me, and perhaps I'm "doing it wrong" but it just doesn't capture what I need a commit history/git-blame for. Usually, I don't care what feature a line code was for. I want to know why a developer thought that was the right change. And to get that visibility I tend to make lots of commits, treating commits almost as out-of-band comments that don't clutter the file/repo. Wh…

I don't think history should ever be changed but there should be a way to view history as if a "squash and merge" or whatever you like had happened.

Re: Git Reflow

#20

Post by npsimons »

kiallmacinnes wrote: post #17
juped wrote: post #3

Another "I like to deliberately lose information to no benefit because I'm bad at git" 'workflow' hits Hacker News. Something is deeply wrong with the ecosystem when people want to do things like this!

Some information is worth loosing. Personally, I get exactly zero value from "Fixed a typo", "Fixed that errant semicolon", "fixed tests broken 3 commits ago" commit messages that come hand in hand with a hard and fast "never rewrite history" policy. If that information is valuable to you, great! This is why we have several ways to do things. The trend you're seeing simply seems to indicate (mildly indicate, at best)…

Very much this. I keep saying: I. Don't. Care. About. Every. Little. Sneeze. A. Developer. Had. On. The. Way. To. Closing. A. Ticket.

See how annoying that is? That's what it feels like to me to read non-squashed commits.

Post reply on HN