4 ms·

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

by herge 10y ago

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.

icebraining 10y ago
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.
- herge 10y ago
  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.
  - mglover 10y ago
    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 https://www.git-scm.com/docs/git-rev-list
tommyd 10y ago
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.
- stormbrew 10y ago
  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.
stormbrew 10y ago
This is exactly what merge commits are.
superuser2 10y ago
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.

by herge 10y ago

icebraining 10y ago

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.

herge 10y ago
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.
- mglover 10y ago
  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 https://www.git-scm.com/docs/git-rev-list

tommyd 10y ago

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.

stormbrew 10y ago
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.

stormbrew 10y ago

This is exactly what merge commits are.

superuser2 10y ago

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.