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

Git email flow vs. GitHub flow

blog.brixit.nl

Post reply on HN
Print view View original

171–177 of 177 posts

Re: Git email flow vs. GitHub flow

#171

Post by u801e »

rectang wrote: post #170
u801e wrote: post #168

Earlier quoted context omitted.

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

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

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.

Re: Git email flow vs. GitHub flow

#172

Post by rectang »

u801e wrote: post #171
rectang wrote: post #170

Earlier quoted context omitted.

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

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

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.

Re: Git email flow vs. GitHub flow

#173

Post by u801e »

rectang wrote: post #172
u801e wrote: post #171

Earlier quoted context omitted.

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

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.

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.

Re: Git email flow vs. GitHub flow

#174

Post by rectang »

u801e wrote: post #173
rectang wrote: post #172

Earlier quoted context omitted.

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.

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.

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

Re: Git email flow vs. GitHub flow

#175

Post by u801e »

rectang wrote: post #174
u801e wrote: post #173

Earlier quoted context omitted.

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.

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

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

Re: Git email flow vs. GitHub flow

#176

Post by da39a3ee »

sreevisakh wrote: post #114
da39a3ee wrote: post #101

If a patch is in an email then how do you know which parent commit it should be applied to? A patch is not a thing in its own right in isolation; it should come with a specified parent thus identifying a unique code context in which it is correct. Just because it applies cleanly on a branch does not mean it is correct there.

I have wondered the same too for a long time. But I have never seen the branching commit mentioned. Instead, most of the contributor documentation just ask you to rebase your feature branch on the latest master (or whatever it is called now) and send in those patches. I believe that patchset application is treated the same way as rebasing. It should be possible to apply patches to the master without conflicts as long…

Thanks, so yours and the sibling reply by @worldmaker seem more argument against the email workflow. I honestly think it's just smart people being stubborn; men over 50 finding it hard to relinquish what were core tenets of internet-based development in the 90s.

Re: Git email flow vs. GitHub flow

#177

Post by hashkb »

mehdix wrote: post #40
hashkb wrote: post #27

Earlier quoted context omitted.

And it's free; and the web interface has no JS, if you're into that sort of thing.

I assume you mean free software? Since sourcehut is intentionally a paid service for hosting content, albeit free during beta and for contributors.

Sourcehut.org vs the product itself. Nobody is forcing you to use the cloud product. No features are paywalled. The community will support you on their own time on the mailing list. And if you can't afford to pay for the cloud version, you can email Drew and he will help you.
Post reply on HN