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

21–30 of 80 posts

Re: Git Reflow

#21

Post by 0x0 »

maxxxxx wrote: post #19
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.

I like this a lot! Maybe way to add some metadata for a "commit collection" in git that is collapsed into a pseudo-commit by default (for browsing, bisect, blame, etc) but with the option to drill down/expand into sub-commits.

Re: Git Reflow

#22

Post by Kiro »

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…

> 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.

I'm the complete opposite. When I do a blame I want to see a direct link to the feature. I couldn't care less about the specific commit that changed the line.

Re: Git Reflow

#23

Post by aeontech »

throwanem wrote: post #9
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!

Where is information lost? Delivered branches aren't deleted, so full history information is available - it just doesn't clutter trunk by merging in every commit.

This workflow explicitly deletes delivered branches.

  If your workflow looks like this:
  - Create a feature branch
  - Write great code
  - Create a pull request against master
  - Get 'lgtm' through a code review
  - Squash merge to master
  - *Delete the feature branch*
As far as I'm concerned, commits should be rebased and squashed into logical units on the feature branch before merge, that's the responsibility of the dev. Squashing them all into one monster commit feels like a terrible idea.

Re: Git Reflow

#24

Post by Dru89 »

I'm unhappy with the approval process being a simple search for "LGTM". I wish GitHub pull requests had actual support for a review process, e.g.:

* open issues to address

* review state, such as "changes requested" or "approved" (along with users that are in each state).

We've been using Phabricator's[1] Differential tool for code reviews and it feels superior to this process, but it would certainly be nice to have an all-encompassing solution for this.

[1] http://phabricator.org

Re: Git Reflow

#25

Post by throwanem »

aeontech wrote: post #23
throwanem wrote: post #9

Earlier quoted context omitted.

Where is information lost? Delivered branches aren't deleted, so full history information is available - it just doesn't clutter trunk by merging in every commit.

This workflow explicitly deletes delivered branches. If your workflow looks like this: - Create a feature branch - Write great code - Create a pull request against master - Get 'lgtm' through a code review - Squash merge to master - *Delete the feature branch* As far as I'm concerned, commits should be rebased and squashed into logical units on the feature branch before merge, that's the responsibility of the dev. Sq…

Whoops, yeah, you're right. I was looking at the screencast and didn't see an explicit deletion, and mistook that for there not being one at all.

Re: Git Reflow

#26

Post by alkonaut »

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)…

I think people are talking about different things. No one wants to see any "oops typo" coomits. Those are squashed/amended in the feature branch in all sane workflows. The question is only if you represent each feature with ten commits in the feature branch as one commit in master or as 2 or 3.

If a typical feature starts with some cleanup/refactoring, I don't mind seeing that work separated from the new implementation in master. Some would consider a pure refactoring noise that shouldn't be in master.

There seems to be an argument too that unless you have a policy of squashing completely then the outcome will be noise and not enough squashing. That depends on the people of course.

Re: Git Reflow

#27

Post by zwily »

0x0 wrote: post #21
maxxxxx wrote: post #19

Earlier quoted context omitted.

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.

I like this a lot! Maybe way to add some metadata for a "commit collection" in git that is collapsed into a pseudo-commit by default (for browsing, bisect, blame, etc) but with the option to drill down/expand into sub-commits.

git already does this. The message for the merge commit contains the overview of what's happening in the commits in the merge, and use `git log --first-parent` to only include the merge commit when one is encountered.

That said, I still prefer squash/merge myself.

Re: Git Reflow

#28

Post by aeontech »

npsimons wrote: post #20
kiallmacinnes wrote: post #17

Earlier quoted context omitted.

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.

Why does everyone seem to insist that there's only two options?

option A) SQUASH ALL THE THINGS option B) HISTORY IS SACRED AND HOLY

We just make sure that the developer rebases and squashes the meandering micro-commits into parent logical units before merging. This gives us both sensible logical commits, and avoids monster commits.

I spend enough time spelunking through history that I dread seeing something like this when I need to track down the context for a particular change

   client/something.js   | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 critical/something.rb            |  41 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------
 gulpfile.js |   7 +++++++
 lib/stats.erl            |  24 ++++++++++++------------
 api/somethingelse.js   | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 critical_api/another_thing.rb            |  41 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------
 webpack.js |   7 +++++--
 lib/mapreduce.exs            |  24 ++++++++++++------------
 client/user.js   | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 critical/security.rb            |  41 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------

Re: Git Reflow

#29

Post by infogulch »

maxxxxx wrote: post #19
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.

This!

There's value in both use cases: 1. Scrolling through the log to see an overview of the direction of the project on the level of complete features. 2. Being able to see exactly when, who, and why any single specific line was changed.

Squashing gives you 1, but throws out 2 on the way.

Re: Git Reflow

#30

Post by codenamev »

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.

From the README: "On your first install, you'll need to setup your Github credentials. These are used only to get an oauth token that's stored in your global git config. We use the Github credentials so we can create pull requests from the command line."
Post reply on HN