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

Comparing Git Workflows

atlassian.com

Post reply on HN
Print view View original

91–100 of 104 posts

Re: Comparing Git Workflows

#91

Post by turaw »

sofal wrote: post #81
turaw wrote: post #50

Earlier quoted context omitted.

> ...this is solved by the named branches in Mercurial... I'm not super-familiar with Mercurial (and only somewhat-familiar with git), but couldn't you get the same effect as named branches by just not deleting fully merged branches in git? > ... how can you tell which one of the parents is the previous commit in the master ... You can use --first-parent [1] to disambiguate that. In a nutshell, the master branch in y…

The --first-parent history can be ruined pretty easily by an inexperienced Git user. They'll use their local master as their feature branch for days and then they'll try to push it. Git will unhelpfully tell them to first do a "git pull" before pushing. So they do, which leaves them with a bullshit "merged master into master" merge commit and then they push that shit, thereby guaranteeing that --first-history will al…

Yikes. Fair enough; that would definitely trip it up!

Re: Comparing Git Workflows

#92

Post by mikegerwitz »

cortesoft wrote: post #69
mikegerwitz wrote: post #28

Earlier quoted context omitted.

> the history is littered with utter garbage commits like the following: "commit this before I get on the plane" "whoops, make this compile" "WTF?" You have a problem with commits here, not the lack of squashing. A messy history is only messy if you make it so. > These add no benefit to history, and actually provide an impediment to bisecting (since a lot of these intermediate revisions will not even compile). This i…

I commit for lots of reasons, though. Sometimes, I am about to try something crazy with the code, and I want a save point to go back to. Sometimes, I want to switch computers in the middle of working on something (going from desktop to laptop, for example), so I commit and push to the other computer. Also, if I am working on something very complex, I might go hours or even days with code that can't compile. I don't w…

My argument was for not retaining those commits, or not committing them in the first place; drewg123 was complaining about the situation from others, meaning that their private branches were not cleaned up prior to pushing. You wouldn't push your WIP branch, I would assume.

I have also pushed for the purpose of pulling on another PC; that commit then gets `reset --soft`'d.

Re: Comparing Git Workflows

#93

Post by mikegerwitz »

stepanhruda wrote: post #80
mikegerwitz wrote: post #28

Earlier quoted context omitted.

> the history is littered with utter garbage commits like the following: "commit this before I get on the plane" "whoops, make this compile" "WTF?" You have a problem with commits here, not the lack of squashing. A messy history is only messy if you make it so. > These add no benefit to history, and actually provide an impediment to bisecting (since a lot of these intermediate revisions will not even compile). This i…

It'd pe perfect, if only we could take people out of the equation. Seriously, I think that the cost/benefit ratio of a perfect history is so terrible that there are very very few people that follow through with it. If one submits a PR and it has a messy history, what is the reviewer supposed to do? Make them go through the commits and clean them up? How will the reviewer verify that every commit compiles? Make them s…

> If one submits a PR and it has a messy history, what is the reviewer supposed to do? Make them go through the commits and clean them up?

That's up to the project. Some do, yes, for the reasons that I described---it's much easier to review a series of patches that can be comprehended, and has benefits later on (e.g. bisecting). If the patch is large from a contributor, and a bisect arrives at that commit, and the contributor is not the one doing the debugging, it can be a frustrating and inefficient experience. I've wasted many nights on something that could have otherwise been immediately obvious.

> If you only have squash commits from PRs and run CI on them, you are sure that every commit compiles.

It's not difficult to loop through commits and make sure they compile.

In fact, bisect can do it for you, if you aren't fond of command-line loops.

Re: Comparing Git Workflows

#95

Post by cortesoft »

mikegerwitz wrote: post #92
cortesoft wrote: post #69

Earlier quoted context omitted.

I commit for lots of reasons, though. Sometimes, I am about to try something crazy with the code, and I want a save point to go back to. Sometimes, I want to switch computers in the middle of working on something (going from desktop to laptop, for example), so I commit and push to the other computer. Also, if I am working on something very complex, I might go hours or even days with code that can't compile. I don't w…

My argument was for not retaining those commits, or not committing them in the first place; drewg123 was complaining about the situation from others, meaning that their private branches were not cleaned up prior to pushing. You wouldn't push your WIP branch, I would assume. I have also pushed for the purpose of pulling on another PC; that commit then gets `reset --soft`'d.

I usually want to push it somewhere, to maintain a backup in case of hardware failure.

Re: Comparing Git Workflows

#96

Post by stepanhruda »

mikegerwitz wrote: post #93
stepanhruda wrote: post #80

Earlier quoted context omitted.

It'd pe perfect, if only we could take people out of the equation. Seriously, I think that the cost/benefit ratio of a perfect history is so terrible that there are very very few people that follow through with it. If one submits a PR and it has a messy history, what is the reviewer supposed to do? Make them go through the commits and clean them up? How will the reviewer verify that every commit compiles? Make them s…

> If one submits a PR and it has a messy history, what is the reviewer supposed to do? Make them go through the commits and clean them up? That's up to the project. Some do, yes, for the reasons that I described---it's much easier to review a series of patches that can be comprehended, and has benefits later on (e.g. bisecting). If the patch is large from a contributor, and a bisect arrives at that commit, and the co…

For larger projects this takes literally hours

Re: Comparing Git Workflows

#97

Post by seanp2k2 »

cyphar wrote: post #83
nhaehnle wrote: post #82

Earlier quoted context omitted.

I find it mildly amusing what you're calling "traditional git workflows". It seems pretty clear to me that the traditional git workflow is the one used by the Linux kernel, which is after all the reason why git exists in the first place. The traditional git workflow strikes the correct balance between locally rebasing to create a logical sequence of meaningful commits without squashing everything when your work gets…

I completely agree. The Linux kernel workflow is the only way to use git effectively and the history is always useful and each commit is nice and self-contained. Some people apparently don't understand that "no squashing of patchsets" means that the merger shouldn't squash a patchset (not that the developer can't make the patchset clean) and that "no rewriting history" refers to master once things have been merged in…

Is there some ~concise guidelines or post about how the Linux kernel developers use git?

Re: Comparing Git Workflows

#98

Post by mikegerwitz »

stepanhruda wrote: post #96
mikegerwitz wrote: post #93

Earlier quoted context omitted.

> If one submits a PR and it has a messy history, what is the reviewer supposed to do? Make them go through the commits and clean them up? That's up to the project. Some do, yes, for the reasons that I described---it's much easier to review a series of patches that can be comprehended, and has benefits later on (e.g. bisecting). If the patch is large from a contributor, and a bisect arrives at that commit, and the co…

For larger projects this takes literally hours

It's not a one-size-fits-all type of thing; if it doesn't work for your project, then you need to try something else.

Where I work, we don't enforce that each commit build---it's known to be a good practice, and they're going to have someone flip out on them if they're trying to debug something and they have to skip a dozen commits when bisecting (incidentally, I had that problem today).

In that case, it's a cultural thing. If someone consistently commits code that doesn't build, then they should be addressed.

If it's a random contributor to a project, more care should probably be taken. If building each commit isn't feasible, then maybe only building modified files (that is, a normal `make` for example rather than a fresh workspace) is better than nothing. If that's too long, maybe build a few sample commits. Etc.

In any case, even if you don't build each commit, the history is still useful.

Re: Comparing Git Workflows

#99

Post by juped »

cyphar wrote: post #83
nhaehnle wrote: post #82

Earlier quoted context omitted.

I find it mildly amusing what you're calling "traditional git workflows". It seems pretty clear to me that the traditional git workflow is the one used by the Linux kernel, which is after all the reason why git exists in the first place. The traditional git workflow strikes the correct balance between locally rebasing to create a logical sequence of meaningful commits without squashing everything when your work gets…

I completely agree. The Linux kernel workflow is the only way to use git effectively and the history is always useful and each commit is nice and self-contained. Some people apparently don't understand that "no squashing of patchsets" means that the merger shouldn't squash a patchset (not that the developer can't make the patchset clean) and that "no rewriting history" refers to master once things have been merged in…

It's not the only way to use git effectively, but it's definitely the canonical one. I think a Chesterton's fence rule should apply to git: if you're doing something different from LKML, you should be able to clearly explain exactly why. No linking to some blog post you found, either, unless it's by Junio Hamano (and you still have to explain, you can't just link).

Re: Comparing Git Workflows

#100

Post by liveoneggs »

seanp2k2 wrote: post #97
cyphar wrote: post #83

Earlier quoted context omitted.

I completely agree. The Linux kernel workflow is the only way to use git effectively and the history is always useful and each commit is nice and self-contained. Some people apparently don't understand that "no squashing of patchsets" means that the merger shouldn't squash a patchset (not that the developer can't make the patchset clean) and that "no rewriting history" refers to master once things have been merged in…

Is there some ~concise guidelines or post about how the Linux kernel developers use git?

read these three man pages for the original "pull request": https://git-scm.com/docs/git-format-patch https://git-scm.com/docs/git-send-email https://git-scm.com/docs/git-am
Post reply on HN