Git email flow vs. GitHub flow

Re:Git email flow vs. GitHub flow by WorldMaker on Wednesday March 31, 2021 @12:26PM (#26649248)

It's an entirely different commit at that point. If work has already started in another branch based on the original commit (for whatever reason), it can cause merge problems down the road. Again, you are likely going to suggest that you can just rebase this other branch on top of the modified commit, but that's still sweeping possible merge commits under the rug, and again just because that rebase is usually automatic including that the tree references should be the same doesn't mean it is always automatic or doesn't have dangerous repercussions (including training junior devs to rebase often and giving them plenty of ammo for avoidable footguns).

[ Parent | on HN ]

Re:Git email flow vs. GitHub flow by u801e on Wednesday March 31, 2021 @02:38PM (#26651192)

I'm talking about a single commit PR in Github or Gitlab. If it's based on the latest version of the base branch, then amending it to include the PR number would allow Github to generate a link to the PR page associated with that commit. That would make the merge commit superfluous at that point.

So something like:

  git commit --amend

and editing the commit message. This doesn't introduce any further change to the tree associated with the commit.

[ Parent | on HN ]

Re:Git email flow vs. GitHub flow by rectang on Wednesday March 31, 2021 @05:26PM (#26653374)

But because the commit has different metadata after amending, it now has a different SHA and is a different commit.

For illustration, a minor inconvenience of amending the commit is that `git branch -d my-feature-branch` no longer succeeds for the original branch, because it looks for the actual commit SHA, not the tree.

You may not care about the effects of changing the commit, but those effects are real and other people care.

[ Parent | on HN ]

Re:Git email flow vs. GitHub flow by u801e on Wednesday March 31, 2021 @06:07PM (#26653767)

Assuming you were the one who amended the commit before pushing it up to the remote, there's no reason that you would not be able to delete the branch because your local working copy has already updated contents of .git/refs/heads/my-feature-branch.

For those who have cloned the repo for testing, they can simply run git checkout my-feature-branch; git fetch origin; git reset --hard @{u} to get their local repo in sync with the remote.

So there's no reason that amending the commit will affect anyone until they branch off of the repo to do their own work. But that's nothing that a rebase can't fix.

[ Parent | on HN ]

Re:Git email flow vs. GitHub flow by rectang on Thursday April 01, 2021 @02:12AM (#26657144)

Yes, of course there are workarounds; no matter what scenario you or I come up with, the other will be able to propose a different way of doing things. I chose a deliberately trivial example because I was illustrating a fundamental aspect of Git's design, not trying to stump you. But we're talking past each other.

[ Parent | on HN ]

Re:Git email flow vs. GitHub flow by u801e on Thursday April 01, 2021 @06:43AM (#26658747)

I don't think we're talking past each other because you weren't involved in this subthread until your comment about using git branch -d.

[ Parent | on HN ]

Re:Git email flow vs. GitHub flow by rectang on Thursday April 01, 2021 @10:55AM (#26661217)

But one of my comments (†) is the great-grandparent of your first comment on the subthread? (∆) And the concept of preserving commits precisely is fundamental to my comment two generations above that, the one about "nirvana" (‡) ?

    [article]
     properdine
      pabs3
       rectang (‡)
        pabs3
         rectang (†)
          pabs3
           WorldMaker
            u801e (∆)

Perhaps we would benefit from an `hn log` function which displays the linear parentage history for comments? (It would be easier to design that `git log` because every comment has exactly one parent, there are no `hn merge` comments.)

Or in your working copy has my authorship info been lost? That can happen if a committer uses plain old `patch -p1` to apply a diff from the mailing list rather than `hn am`. :D

[ Parent | on HN ]

Re:Git email flow vs. GitHub flow by u801e on Thursday April 01, 2021 @10:15PM (#26668476)

> Or in your working copy has my authorship info been lost?

Well, none of the text that you originally wrote in the comment you're referencing wasn't preserved on the working copy. And, unless it's quoted, and one could search for when it was introduced by running git log -S"a line from your comment", no one is going to search for it specifically. IOW, the thread moved on :).

[ Parent | on HN ]