Hacker News new | ask | show | jobs
by tharkun__ 168 days ago
My branch is mine. Don't tell me what I can or can't do. I push WIP stuff all the time, to share code with others for discussion, to get the build to run in parallel while I keep working or just at the end of the day. I freely amend and will squashed before merging (we only allow a single commit per branch to go to master).

If I or someone else bases something off anything but master that's on them to rebased and keep up to date.
1 comments
jghn 168 days ago
My philosophy is that once a PR is open, that's the point at which people should no longer feel free to treat their branch as their own. Even in groups that squash commits, it should still preserve the aggregate commit messages.

But until that PR is open? Totally with you. There is no obligation to "preserve history" up until that point.

link
andrewaylett 166 days ago
Strong disagree: until the branch is merged, it's mine.

I'm in a camp that prefers single rebased commits as units of change, "stacked diffs" style.

GitHub in particular was annoying with this style but is definitely getting better. It's still not great at dealing with actual stacks of diffs, but I can (and do) work around that by keeping the stack locally and only pushing commits that apply directly to the main branch.

link
johnisgood 168 days ago
Not to disagree, but this is so GitHub-centric. What is up with "diffs", "patches", and "submissions"? :D
link
jghn 168 days ago
Not to disagree, but calling it Github-centric is a bit over specific :)

I regularly work with Github, Bitbucket, and Gitlab. Everything I said applies except for the fact that I said "PR" instead of "MR". But yes, you're right. I'm highlighting a specific, albeit extremely popular, workflow.

link
johnisgood 168 days ago
I know, I know, I was going to edit it to "Git{Hub,Lab}" in the beginning but oh well.

In any case, my comment just reflects on the fact that you had a series of patches that you could not squash or rebase. It stuck.

And the fact that I see many people use the abbreviation "PR" for something that is merely a patch or diff. For example you might send a diff to the tech@ mailing list, but you should not refer to it as a PR.

link
QuercusMax 168 days ago
Git{Hu,La}b
link
patmorgan23 167 days ago
GitPub
link