@MichaelHomer Oh my goodness gracious.

@Tim I don't know. Possibly. I think that paying people badly guarantees that they are always in a bad mood, unless they have unusually good temperaments.

And paying people better improves their mood, other things being equal.

Though I don't think paying people better makes them better teachers. But I haven't made a study of the subject, obviously.

@AndrasDeak No, I'm pretty sure that's not what he meant. I don't think he was referring to you at all. It was just a general comment.

Tim has, I gather, had some bad experiences with a couple of well-known institutions of higher education

@Wildcard That way lies madness. Probably.

@MichaelHomer So have I. So have a lot of people.

@AndrasDeak BTW, it's paid, not "payed". Just FYI.

Well, indeed

Being a foreign grad student in the United States is more or less a guarantee of abuse, unless you're a high flyer, or really lucky. Of course, some are better than others at keeping out of trouble.

Rumor has it that people in the experimental sciences are particularly hard hit. I wouldn't know - it's not my area.

Of course, being a grad student is a rough business at the best of times.

Yes, I can imagine that

@MichaelHomer Which part?

@FaheemMitha this part

@MichaelHomer Ah, ok.

@MichaelHomer no. I have had bad experiences with quite a few presumptuous academics on the Internet

and many self-appointed "trainers" on the Internet

and a few anti-intellectualism and discriminative "managers" at workplace, but fewer than those who are okay

and a few snobbish fawning backstabbing "coworkers" at workplace, but fewer than those who are okay

I am not the same as how I behave on the Internet.

But yes. I have been abused by some academics who feel they are superior and their tenure have exempted them from self-indulging.

I have also been physically assaulted by someone shouting Trump nonsense. My shoulder still hurts

I have to acknowledge that more people in academia are okay

at least I don't know some of them well enough to judge.

I have to clarify that I am against identity "politics": generalize from individual to a group

although I am sometimes under its influence subconsciously

@FaheemMitha ha, yeah

@FaheemMitha no. I've seen Tim communicate for long enough to be certain. He feigns naïveté to prevent accusations of being a troll. I'm sure he does have mental difficulties impeding on his learning and communication (so this is not his fault), but at the same time he often posts subtle digs at people that prove that he's willfully not playing ball (rather than just misspeaking).

I know the type very well. The jab we're talking about is one of many similar ones. The scheme is like this: amidst a lot of people telling the person not to do what they are doing, there is one who enables their behaviour. So the person says "Oh (enabling person X) thank you for your kindness and that you're not being an oppressive abuser [unlike some people *eyeroll*]" (the square brackets are always only implied to prevent accusations of being a jerk).

I've seen more than enough of Tim to be sure that his abrasive attitude here in chat is conscious, which is why I usually ignore him. Trolls thrive only as long as they are being fed and welcome.

I'd rather not go through his messages to pull up further examples, but it wouldn't be too hard (I've seen them even though I'm not even paying attention to them)

@AndrasDeak Well, ok. I don't pretend to be an expert on the topic, so will defer to your superior judgement.

The above was just my 2 cents.

For what it's worth neither am I :)

@AndrasDeak So, did you try Krita yet? Just opened it here. Strange color scheme for the buster version. White on black. Not necessarily complaining, but it's an unusual default choice.

@FaheemMitha is that some new street drug?

@jesse_b It's a drawing program.

not as cool

> Description-en: pixel-based image manipulation program>

@jesse_b Street drugs aren't cool.

Oh, it's a KDE thing.

> 28 Oct, 2020 14 commits

> 27 Oct, 2020 59 commits

That's one busy commit history.

sounds like they have poor release management

wow microsoft is terrible

I got my first ever iphone for my job and I'm not sure how to tell which one it is

@jesse_b Poor release management? Those are commits.

@FaheemMitha Yeah but generally you don't commit code willy nilly, it has to go through proper checks and testing before it is released (committed) and if that system is in place generally you would never see multiple commits in a single day

@jesse_b I have the feeling you're not very familiar with free software projects.

People typically commit whenever they feel like it. Often different people, independently. I guess they run a test suite on their local copies.

And a release isn't the same thing as a commit.

all free software projects I've seen still have someone or a committee in charge and they don't just allow anyone to commit, they have to be approved

and I work for a free/open source software company

github.com/torvalds/linux/graphs/commit-activity

@jesse_b Yes, some people are allowed to commit. Or others approve their pull requests, I guess.

I should clarify that I used to work for a free/open source software company

=(

I still technically work there but we don't make anything anymore

Well functioning free software projects are typically quite decentralized. In order to not have a single point of failure. And often are quite informally run. If problems exist, then can usually be corrected easily. And we aren't talking about nuclear launch codes here. Proprietary projects are often run in a tighter fashion. And they may not use distributed version control at all, because they don't want complete copies of their source code history all over the place.

@jesse_b perhaps 14 merged PRs in a day

Or they don't squash on merge

@AndrasDeak At any rate, they seem to be quite busy.

@FaheemMitha not yet. I've been crazy busy with my lecture, got to bed a bit before 4 AM...

@AndrasDeak Ooh, that sucks.

Well it's partly terrible time management on my part

To me it seems like they are committing bugs and then quickly realizing it and patching them, most of which would be alleviated by not committing so quickly and spending more time checking the code

I guess the main question is whether there's a comprehensive test suite and CI.

@AndrasDeak Welcome to my world.

@AndrasDeak Difficult for a graphics program, I would have thought.

But they must have something, otherwise the program would fall apart.

@jesse_b Looks like lots of small changes to me. Quite common.

@FaheemMitha could be the case :)

I wonder what the GIMP does.

@FaheemMitha That's how I commit to my repositories and people definitely shouldn't do things the way I do them :p

@AndrasDeak looks like they have a combination of testing approaches, about what you'd expect: docs.krita.org/en/untranslatable_pages/testing_strategy.html

@jesse_b I'm wondering if you looked over the code to make that assessment, or you're just guessing based on the number of commits? From a quick look at the commit graph and their merge strategy it looks like they're rebasing onto master (but not squashing) before doing a fast-forward merge.

Just based on the frequency that Faheem mentioned. Sounds a little ADHD. Although to be fair the tight regulations generally put a huge damper on innovation

@Wildcard I'm not familiar with Git terminology, so why does not squashing mean?

@jesse_b yeah, merging in 59 separate changes in a day to one project could be a bit much, I guess. But it's not really that, it's 59 commits which were authored that day and then merged in via a handful of merge requests (looks like around 6-10), some of which were actually merged the day after.

@Wildcard I wonder how they handle visual issues, because they are hard to automate.

For a lot of things, one can create a software object representing the canvas, or whatever, and then proceed. But how can one be sure the real thing will still look ok?

@FaheemMitha means that the original branch structure is preserved, so if a developer submitted a change consisting of a dozen commits and the change were accepted, that would add a dozen commits to the master branch. Squashing would mean those dozen development commits would be added to the master branch as a single commit.

@Wildcard I see. That's what I thought. But if those commits were logically distinct, it wouldn't make sense to merge them into one commit.

@FaheemMitha eh, different projects use different approaches. Just from the commit graph, I see a lot of yesterday's changes pertain to rendering stuff on high DPI displays and it's broken down into individual commits, "render this in high dpi, render that in high dpi." Some projects would squash it all into "render all the stuff in high dpi."

@Wildcard More granularity is generally better, but grouping related changes together is also reasonable. As long as the changes belong together.

@FaheemMitha I expect that's why they don't only use automated testing.

Doing it only to reduce the number of commits is a poor reason.

@FaheemMitha yup, exactly.

I do a fair amount of grouping myself. Otherwise with too many commits, it gets hard to keep track.

The key is whether you can write a single log message which adequately covers all the changes.

@FaheemMitha it all depends on your workflow. If you have lots of automated test suites, you're going to have rules that every individual commit must function, so you can use git bisect later (e.g. after adding a new test). Or you may want to keep the branch structures, i.e. no fast-forward merges, so you can see where stuff got merged in.

If you have a linear history then yes, it's hard to understand a ton of tiny commits. But if they're grouped by the fact of being merged in (i.e. a non-linear history) then it's not so important to group them by squashing into a single commit.

@FaheemMitha not necessarily. As far as the project goes, the real history is "feature X was implemented" / "bug Y was fixed". How many commits that took locally for the contributor is mostly irrelevant. Ideally each such unit of development should be contained in a pull request, which contains all high-level information about the changes.

@AndrasDeak That's debatable. In general, that would probably contain too much stuff per commit.

@AndrasDeak that's why my personal preference is a single high-level summary in the merge commit (which in GitLab comes automatically from the merge request description), with all the technical detail and steps along the way in the individual commits on that merge request (which are retained in history).

Fewer commits make looking for changes and introduction of bugs easier. Also if you squash commits before merge it doesn't matter if the contributor merged master a dozen times into their local repo, which would show up as dreadful knots in the history

There's nothing wrong with having a group of related commits corresponding to a single feature, which belong together.

@AndrasDeak I have typically used rebase (but no squash) before merge into master.

@FaheemMitha huge projects with thousands of contributors shouldn't want to look at minuscule commits

(That avoids the tangled history.)

@Wildcard yeah, but it rewrites history on the feature branch, which can also be seen as problematic

@AndrasDeak The commits don't necessarily have to be miniscule. Just granular.

@Wildcard with strict adherence to feature branches, I bet

Obviously, it depends on the project. For my individual stuff, I can please myself, so I generally keep commit size small, and log messages details. Occasionally it comes in useful.

@FaheemMitha for individual stuff, absolutely

That's what I do. Forgot a comma? Just commit and push.

@AndrasDeak depends if the feature branch is shared prior to merge. In the Linux kernel that would be an issue for sure because a whole bunch of people can work on a feature branch for a long time before it's merged. But if only one or maybe two developers are working on the feature branch, you don't much care about rewriting that history so long as it happens prior to merge.

I find I tend to forget what I've done quite quickly, so I find the log messages help to remind me.

but in a major project's master branch you (almost? who knows) never need that kind of information

@AndrasDeak yes, if by that you mean "never commit directly to master; all commits on master must be merge commits incorporating feature branches."

Generally I complete some stuff, then split it up into commits after the event.

@Wildcard yeah, I tend to ask maintainers on PRs whether they prefer rebases or merges, and the answer I usually get is "doesn't matter (and we'll squash anyway)"

@Wildcard yup

Depending on how the changes are structured.

@AndrasDeak What kinds of projects?

@FaheemMitha see, I like to make a bajillion commits as I go, and then squash them down to a reasonably linear/granular/atomic history with an interactive rebase before I submit for a merge request.

Most PRs are not about huge refactors or huge new features. So a lot of commits in a PR will tend to be changes on the same fewer lines (I don't have evidence, just my gut feeling)

@FaheemMitha python libraries, usually

@AndrasDeak agreed, in which case squashing to a single commit can absolutely make sense. You don't need all the broken attempts along the way.

@AndrasDeak A bunch of closely related stuff in the same place should be one commit.

@FaheemMitha arguably a single PR is a bunch of closely related stuff in the same place ;)

@FaheemMitha yeah, the rule of thumb is, "could it make sense to revert a single one of these commits individually?" If not then they should probably be squashed.

@Wildcard No, of course scratch commits should not stay in history. That's just useless clutter.

@AndrasDeak slightly horrifying. Commit and push a broken comma? Surely that should be, amend and force push to your private branch to fix a broken comma. :)

@AndrasDeak It might be a few somewhat different things spread across different files. Obviously, there is some judgement required and subjectivity involved here.

@Wildcard if I find it instantly, sure. I mean a comma in a docstring or something.

I usually reread commit messages before pushing

@Wildcard Sure. Sounds like a good rule of thumb. Though I do tend to split things up a bit more than that to avoid lengthy changelog messages.

@FaheemMitha yep, so like I said, it really depends on your workflow. :)

I use Mercurial, so things are a bit different. And better. For example, I think people have explained to me what a fast forward merge is, but I can never remember.

It's just a merge that doesn't need you to merge anything, just relocate a pointer to a branch (I think. From Wildcard's message I'm less sure now.)

@Wildcard Do you live in the US? I can't remember.

@AndrasDeak Not an automatically solved merge, just a merge which doesn't have files in common? Or just no overlap within a file?

I don't know what any of those mean

@AndrasDeak Well, an automatically solved merge means that a merge is needed, but your preferred tool can merge it without your manual intervention.

if the branch you want to merge in is a direct linear descendant of your branch then you can just move your branch to the tip of the branch to be merged. This is the "fast forward" scenario I'm familiar with.

Doesn't have files in common means that commit 1 and 2 don't have files in common. So there is no possibility of conflict. And no overlap just means that the changes might have files in common, but happen in different places, so no collision.

@AndrasDeak That's a rebase.

You can do that even if you need to do a merge as well.

Rebasing and merging are both no-ops when the source is your descendant.

But perhaps we are using different terminology for the same things.

rebasing and merging are the same thing except for history...

@AndrasDeak Oh, so you're just talking about rearranging the order of commits?

Probably would be clearer with examples, but I can't be bothered, and I'm sure you can't be either.

@FaheemMitha no, that's an interactive rebase

@AndrasDeak Ok.

@FaheemMitha I'm annoyed enough that I've actually been thinking about doing that :P

@AndrasDeak You don't want to do that. And it would make your terrible time management even more terrible.

Oh, I'm free for a few days :D Although I'm busy with other work...

$ touch foo
$ git add foo
$ git commit -m 'foo'
[master (root-commit) c123f04] foo
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 foo
$ git branch stuck_on_foo
$ touch bar
$ git add bar
$ git commit -m 'bar'
[master 430d59a] bar
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 bar
$ git checkout stuck_on_foo
Switched to branch 'stuck_on_foo'
$ gittree
* 430d59a (master) bar
* c123f04 (HEAD -> stuck_on_foo) foo
$ git merge master
Updating c123f04..430d59a

@AndrasDeak Does your institution really only pay you $650 a month? I realise that may be a sore point, so maybe I shouldn't bring it up. But it's really quite shocking if correct.

@AndrasDeak It actually says "Fast-forward"? How... chatty.

Normally a merge gives you two parents for a commit: the tip of the branch before merge and the tip of the other branch before merge. But if the two branches are on the same linear history then a merge just has to replace one of the branches (which is only a pointer!) to the other branch's position, without having to create new commits. This is what I know by "fast forward"

If I'm not careful, I might actually learn something about Git. Now, that's a terrifying prospect.

@FaheemMitha not a sore point, if it bothered me enough I'd leave academia. I'm on a national postdoc grant. Let's just say that academia in Hungary is a bit of a hobby ;)

But yeah, my net wage is roughly there. But it's a bit tricky because our currency is in record lows these days, and the price of life here is very low (by Western standards; no idea about India)

@AndrasDeak If the branches are in the same linear history, then why do they need to get merged in the first place?

Does your example illustrate that?

If so, could I have just a shell script that I could run?

@FaheemMitha for instance because your local repo is on an older version of upstream and you want to update the repo before you start working on a feature. People often just git pull upstream but I prefer to fetch and separately merge on my own when I need to.

@FaheemMitha not sure what you mean

@AndrasDeak That's a hell of a hobby.

@FaheemMitha hehe, yeah :)

@AndrasDeak Just the commands. Nothing else. With no $ either.

Our government is working hard to make academia even less enticing. They interfere with grant referee processes, change the legal status of researchers to make them more vulnerable etc.

Or I could just paste and cut your example.

@FaheemMitha oh, yeah, sure. I can do that for you

@AndrasDeak Wonderful. Destroying research always leads to great things.

@AndrasDeak You could gist it. Then I can just clone it.

Copying from chat is a bit clumsy.

Need to go to sleep, actually. I'll catch up on it in the morning... Have a good night.

good night

@FaheemMitha absolutely...

@FaheemMitha you can find it at gist.github.com/adeak/53879d58c084b85e4bb1c5bcfdb8a5f9, if you run it it will attempt to create the new git repo in the current directory

But I know you're not going to just run whatever someone gives you. Just making sure.

@AndrasDeak Thanks, I'll look at it tomorrow. Really late now.

The numbering tag is currently showing the curious case of a few users that share their gravatar and a passion for counting things.

I can't see anything flag-worthy in it, but it doesn't feel completely OK either.

@fra-san same gravatar hash. So same e-mail address. User probably doesn't want to bother finding earlier registrations...

looking at the quality of the questions I'm not terribly surprised

I mean the other option is perennial ban evasion, but one question per user makes that less likely

smells like homework dumps

@fra-san Oh, I was going to report that, glad to see it covered already.

@Quasímodo I see you also met the same gravatar on vi.SE.

You mean textcalculator.SE?

@fra-san Actually I didn't even notice, thanks for calling my attention, I will alert Vim guys too.

@AndrasDeak I'm not even a spectator in that arena ;-)

@FaheemMitha yes I do.

@AndrasDeak that's right.

@FaheemMitha big thing to note is that a "branch" in Git is purely and only a pointer to a commit. They're called "bookmarks" in the Mercurial world.

@FaheemMitha so a fast-forward merge is something that can be done when merging a line of development into the line of development (e.g. master branch) from which it was originally started, IF the latter hasn't been changed at all in the meantime.

Then you just have a linear sequence of commits with the feature branch (remember, a pointer) pointing to the latest commit, and the master branch pointing to an earlier commit. And then "merging into master" could consist of two different things:

(1) Creating a new merge commit (commit with 2+ parents) with the parents being the commit pointed to by master, and the commit pointed to by the feature branch, and then update master to point to the new merge commit (this is called a "normal merge"), OR:

(2) Just move the master branch pointer to point to the same commit that the feature branch currently points to, without making any new commits at all. This is called a "fast-forward merge" and is only possible if the current location (position; commit) of the master branch is a direct ancestor of the feature branch.

That's a little long-winded of an explanation because I avoided the more concise terminology like "branch head", "tip (of a branch)", etc.

"ancestor", that's the word that eluded me :)

It's a good word. 9/10 easily.