I still wish people would give meaningful names to their merge commits. Together with `git log --first-parent` and the alligator [1] workflow, it can filter out the less interesting patch series to focus on the bigger picture (the fact that you added a functionality, not that it took you 53 commits changing very specific parts to do so).
I agree, I don't think "it's only a merge commit" is any excuse whatsoever. But I personally pretty aggressively squash my commits with "rebase -i" before merge, exactly in order for there to be not much of a "bigger picture". And I urge others to do the same as well, because no matter how many fixes there was during the development, later on everybody will ultimately care only about "what it was about in the essence?" I.e., added functionality this-and-that, or a fix, or refactoring, or maybe something new implemented (but not "active" as of yet). Small commits are nice when doing git bisect, but given your code is not a complete trash, it is properly tested and refactoring (which is usually the biggest code change anyway) is separated from the "meaningful" changes, there's no much use in them after a year.
So the best use I've seen for the merge commits are bugtracker task IDs and such.
I try to avoid horrible things like that at all costs. Sometimes it's easy, sometimes not so much. The rule of thumb is that all branches (unless there is a really, really good reason to do otherwise) are created from the master, and are rebased before the push (by the person, who did the development in this branch), and if there are conflicting changes, before the merge as well.
With the absolutely rarest exceptions all patch releases are done in the same manner as the regular ones, i.e. from the HEAD of master. History must be as linear, as possible.
So there are basically 2 general cases when you really need to share a commit. In the first, you find out in your branch there's something to be fixed, which you know I already fixed in mine, in the commit X. In this case it's better if I reorder commits in my branch so that X is the first one, create a new branch with X, which then is merged in a proper manner. You can rebase then.
Second case is when 2 people with different skill-sets or responsibilities must work on something that "from the above" looks like the same piece of functionality. Then, however hard you may try, it all turns up much messier and they will end up needing to share branches (so they cannot rebase them) with multiple commits. In this case I name one of them responsible for changes made within this task as a whole, so when the work is finished the second (3rd, 4th,...) person doesn't touch the branch(es) in question any more, and the first one might rebase and clean up it as needed.
I'm on a project and it's the opposite. Full releases every... 2 months give or take, but every... week or two, there's a round up of 'critical' issues, and you're expected to take just those issues from 'develop' (or somewhere) and get them over in to a 'release' branch of the current released code. I now tend to keep local branches of anything I worked on for months, because 4-6 weeks after it was approved/merged (and deleted) in to 'develop', I may have to also do a 'hot patch' on to a release branch, and cherry picking is the proscribed way of doing it.
I think it possibly did a few years ago. There's a lot of 'tribal knowledge' stuff, and none of these practices were explained when my team (another... 8ish people) were added to the current team months ago.
I think it could be done a lot differently, and better, but any change requires huge amount of political changes. There's probably ... 2 or 3 teams that would need to approve of any process change, and no one wants to be the one to push changes like this ahead. It's "good enough", even though... we often collectively lose a non-trivial amount of time every week or two or three. We log that "wasted time" in a spreadsheet to make a point of it, but... no one is motivated enough the shepherd the required change process. The devops team would have to change a bunch of their scripts, and the process would need to be coordinated among multiple teams of varying sizes and skills. It is kinda disorganized and nightmarish with... I'm trying to count - there's maybe 20+ devs touching this. I suspect this was 'fine' 10 years ago with, say, 5-6 devs who would have dealt with it.
YES! Not everyone has the luxury of evergreen continuous deployments onto their own infra. It is quite common for enterprise software that runs in clients data centers to splinter/branch in this way - since they usually want to manage the risk by staging specific versions of your software for testing before going live. They may consider some of your new features on the main branch as too risky, but still want you to backport fixes to their release branch
Git and Subversion even allowing single line “-m” commit messages was a mistake. You would see a lot better messages if they forced you to use the editor. I bet a lot of programmers don’t even know you could do multi line messages and assume there is some short-ish character limit. I know I did for a long time
Git and Subversion even allowing single line “-m” commit messages was a mistake.
That's a subjective preference. Maybe for some repos it's a good idea to allow or even require longer messages, but certainly not all.
For example, after seeing many different strategies for commit messages over the years, my own preference in many cases is now to permit only one-line commit messages, with a strict character limit, which include a reference to a suitable source such as a feature or bug ID where more details may be found. With git, this can be checked using a pre-commit hook.
The big advantage of this is that a `git log` or similar command with a single-line format can never then hide anything important. Assuming we're talking about an established project that does have things like a bug tracker and some sort of structured project documentation set up, I have found that any time I am tempted to write a longer commit message, there is usually a better place I could record that information, and if not then maybe it wasn't that important anyway.
YMMV, of course. As I said, it's a subjective preference, and no doubt there are many different ways a team might choose to use their tools.
I feel a huge pain of resignation when I am forced to use multiple lines to describe a single commit. There is almost no audience for any line of the commit message other than the first line. As far as line length goes, any practical means of displaying the messages, like gitk or git --oneline, is unfriendly to lengthy lines. Gerrit will display all the lines of the tip commit's commit message, so one can amend that commit to create a summary of the others, but then of course the other commits are not as visible.
The character limits are a real thing in git culture. One could start here, with a question posed by an apparent skeptic:
As someone who has had to dig deep with git blame, I tremendously value a good long multiline commit message. At the very least it can save the trouble of having to dig up some obscure mailing list discussion or bug report to figure out why a change was made, assuming that exists at all. If it doesn't, all you have is the git commits.
> There is almost no audience for any line of the commit message other than the first line.
git log would definitely show the entire commit message, so I don't see why there would be almost no audience. git blame along with git show or git log -n1 would also allow you to see the rest of the commit message for a particular line in the codebase.
git log would definitely show the entire commit message
git log could show the entire commit message, but I can't remember the last time I saw any developer whose default format wasn't a single-line one. Presumably there are some people who do prefer to see the whole message every time, and maybe that includes you, but IME that's quite rare.
One would actually have to make a change to their global git config to set the pretty setting to display oneline or add a bash alias to run git log --oneline.
By default, it shows the entire message, and, in my experience, most people aren't going to change the default behavior in one specific case.
One would actually have to make a change to their global git config to set the pretty setting to display oneline or add a bash alias to run git log --oneline.
That is true, but I literally can't think of any developer I've worked with in many years who had not done something like that. The typical display in every GUI for git repos that I've come across in recent times is also geared to single-line display, though some of them are marginally better with at least indicating the presence of additional lines than git's own one-line display formats in the CLI.
YMMV, and apparently it does, based on your second paragraph.
Just a bit, you can have multiple lines with -m, I do it frequently. You can also write single line messages in an editor, which I'm also frequently guilty of. They're orthogonal issues.
Yes, however, -m does encourage people to make single line messages.
He didn't raise good concerns, he got outraged after reading a HN comment and labeled "pathetic" something he knows nothing about, has no context in, and didn't even spend 5 minutes researching.
This is the correct answer. The difference between the messages I leave for myself in my local merges and my actual commits to the dev branch are night and day.
I'm not sure I'd classify what I read as "outraged" (different people express themselves in different ways, not everyone uses "pathetic" with the same vehemence or vitriol).
That said, that merge log is fairly useless. Whether it needs to be anything other than that, and who generally would see it and whether it's for the person writing it or someone else is something to be discussed, but even in the case it's mainly meant for the author to look back on, is it even succeeding in being useful in that job? I would agree that it appears pathetic, but probably pathetic in a low-cost doesn't really matter way.
