Comparing Git Workflows

Re:Comparing Git Workflows by herge on Thursday May 26, 2016 @11:10AM (#11778498)

I wonder if 'expandable commits' would be useful, where in the full history, a change (with all it's code review fixes, etc) would appear as one commit, but if you wanted to dig deeper, you could 'expand' that commit into all it's gory details of 'draft version before review', 'tried refactoring this part but gave up', etc.

[ Parent | on HN ]

Re:Comparing Git Workflows by tommyd on Thursday May 26, 2016 @11:19AM (#11778572)

I thought the very same thing, as I can see the benefits to both having a single atomic commit for ease of reading history, and to being able to see the individual commits that made it up to avoid losing valuable information about changes.

It turns out that the Github "Squash and Merge" option for Pull Requests does basically this – you review the PR as a bunch separate commits, when you click "Squash and Merge" a single commit is created in the target branch with all the commits squashed, but you can still go back to the original closed and merged PR (e.g. by following a link in the commit message) to view the individual commits.

Obviously this doesn't help if you want to bisect among more granular commits, but (without having actually used it), it sounds like a good middle ground to me. The previous workflow I was used to involved squashing and force pushing to your branch, therefore overwriting the individual commits in the PR for ever.

[ Parent | on HN ]

Re:Comparing Git Workflows by stormbrew on Thursday May 26, 2016 @10:45PM (#11783535)

Now your history is in two places and can't be inspected from a cli. If you ever stop paying github (for a private repo) or github goes out of business your data is lost.

Or you can use git to track this with merge commits and it comes along wherever you go.

[ Parent | on HN ]

Re:Comparing Git Workflows by icebraining on Thursday May 26, 2016 @11:16AM (#11778545)

I think you can do that if you merge with --no-ff, then use git log --first-parent. Only the merge commit will appear on the list, hiding the commits from the merged branch.

[ Parent | on HN ]

Re:Comparing Git Workflows by herge on Thursday May 26, 2016 @04:57PM (#11781533)

Does git blame let you see the same thing? I don't see --first-parent as an argument to it.

It's only helpful if the 'un-expanded' commit is used through the whole system, from git blame, to rebases, etc.

[ Parent | on HN ]

Re:Comparing Git Workflows by mglover on Thursday May 26, 2016 @08:48PM (#11783060)

I have used git blame with --first-parent to get the 'un-expanded' commit identifier in the blame view.

I'm rather new to the --first-parent flag myself but I think it works with anything that supports revision options.

Here's what I see in git 2.8.1:

  usage: git blame [<options>] [<rev-opts>] [<rev>] [--] <file>  
      <rev-opts> are documented in git-rev-list(1)

And --first-parent is listed as an option here: https://www.git-scm.com/docs/git-rev-list

[ Parent | on HN ]

Re:Comparing Git Workflows by stormbrew on Thursday May 26, 2016 @12:28PM (#11779248)

This is exactly what merge commits are.

[ Parent | on HN ]

Re:Comparing Git Workflows by superuser2 on Thursday May 26, 2016 @12:39PM (#11779353)

Phabricator does this, effectively. The Diff URL is in the commit message for the squashed commit to master; you can go there and see all its constituent commits in their gory detail.

[ Parent | on HN ]