Skip to content
 
If you can read this, either the style sheet didn't load or you have an older browser that doesn't support style sheets. Try clearing your browser cache and refreshing the page.

(TechRadar)   Perpetually triggered Linux master Linus Torvalds is triggered once again, this time by concise, factually correct, but functionally useless GitHub merge messages that fail to specify what commits are being merged and why   (techradar.com) divider line
    More: Obvious, Linux, NTFS, Linus Torvalds, User interface, Unix, Linux creator Linus Torvalds, GitHub's web interface, Mergers and acquisitions  
•       •       •

822 clicks; posted to STEM » on 12 Sep 2021 at 11:35 PM (12 weeks ago)   |   Favorite    |   share:  Share on Twitter share via Email Share on Facebook



54 Comments     (+0 »)
View Voting Results: Smartest and Funniest


Oldest | « | 1 | 2 | » | Newest | Show all

 
2021-09-12 8:30:09 PM  
[triggeringintensifies.gif]
 
2021-09-12 8:35:29 PM  
What a prick, talking like he owns the goddamn thing.
 
2021-09-12 8:37:12 PM  
He was also one of the primary developers of git, so maybe he knows what he's talking about.  Or he's just opinionated and doesn't like new things (looking at you, systemd).
 
2021-09-12 9:13:31 PM  
What's the difference between being triggered and having opinions?

Sure, he expresses his opinions bluntly on occasion but I've never seen him need a safe space or anything.

Seems more like other people get triggered when he weighs in on something.
 
2021-09-12 9:28:58 PM  
I'm assuming this was greened so we can all laugh at subby.
 
2021-09-12 10:39:23 PM  

enry: He was also one of the primary developers of git, so maybe he knows what he's talking about.  Or he's just opinionated and doesn't like new things (looking at you, systemd).


Systemd is a steaming turd.
 
2021-09-12 11:10:40 PM  

Ivo Shandor: enry: He was also one of the primary developers of git, so maybe he knows what he's talking about.  Or he's just opinionated and doesn't like new things (looking at you, systemd).

Systemd is a steaming turd.


People keep trying to convince me otherwise and I don't believe them.  Then again, SELinux is newfangled to me.
 
2021-09-13 12:22:25 AM  
But I like merge commits.
 
2021-09-13 12:32:05 AM  
A. He's not wrong, and B. his outburst was pretty tame by his standards.

(I've managed to get my team to leave detailed, helpful messages in our commit logs mainly by setting the example myself.   That's with subversion, though.  Writing long commit messages for git seems misplaced.  But for a git merge, should be plenty detailed.)
 
2021-09-13 12:53:17 AM  
Screw GitHub. They don't even check the order before leaving the restaurant and when you add in the fees... nevermind
 
2021-09-13 1:16:08 AM  

Ivo Shandor: enry: He was also one of the primary developers of git, so maybe he knows what he's talking about.  Or he's just opinionated and doesn't like new things (looking at you, systemd).

Systemd is a steaming turd.


SystemD has too much going on (dns, text editor, .....). But it's a better init system than what came before it. I recently started writing some of my own Systemd start scripts, and I can say, SystemD isn't that bad.
 
2021-09-13 1:34:22 AM  

whither_apophis: Screw GitHub. They don't even check the order before leaving the restaurant and when you add in the fees... nevermind


I think you are mixing up pornhub with GitHub. It's cool. Common mistake.
 
2021-09-13 2:19:41 AM  

Ivo Shandor: Systemd is a steaming turd.


That's an unfair comparison.

For steaming turds.
 
2021-09-13 4:08:21 AM  

Get Rich or Try Dyin': whither_apophis: Screw GitHub. They don't even check the order before leaving the restaurant and when you add in the fees... nevermind

I think you are mixing up pornhub with GitHub. It's cool. Common mistake.


devhumor.comView Full Size
 
2021-09-13 4:12:45 AM  

aerojockey: A. He's not wrong, and B. his outburst was pretty tame by his standards.

(I've managed to get my team to leave detailed, helpful messages in our commit logs mainly by setting the example myself.   That's with subversion, though.  Writing long commit messages for git seems misplaced.  But for a git merge, should be plenty detailed.)


Back when we were using subversion, I wrote a pre commit hook that refused commits with an empty message because one coworker just wouldn't learn ...
 
2021-09-13 4:34:18 AM  

Ivo Shandor: enry: He was also one of the primary developers of git, so maybe he knows what he's talking about.  Or he's just opinionated and doesn't like new things (looking at you, systemd).

Systemd is a steaming turd.


There's a whole lot of "____ always USED to Just Work until systemd".

My favorite: I always USED to be able to trust that my network would be up before entering runlevel 3...
 
2021-09-13 5:21:17 AM  

VisualiseThis: But I like merge commits.


You - get out

Rebase and squash for life
 
2021-09-13 5:28:32 AM  
Fark user imageView Full Size
 
2021-09-13 5:30:00 AM  
$7 from Bea Arthur
 
2021-09-13 6:01:17 AM  

qorkfiend: VisualiseThis: But I like merge commits.

You - get out

Rebase and squash for life


The very fact that you have arguments about the best way to merge shows what a vile POS git is.  The revision control system is something that you should think about as little as possible.  What you should be thinking about is, you know, your actual work.  Git is a clingy attention hog that forces you think about git all the farking time.

Eff that.  SVN FTW.  Or, at least, not-git FTW.  The people who work in my project (svn based) almost never have to think about revision control, apart from committing and updating, and the occasional branch, and I don't want them to.  My #1 goal in life is never to have to explain to an engineer what a detached head is.
 
2021-09-13 6:19:01 AM  

aerojockey: My #1 goal in life is never to have to explain to an engineer what a detached head is.


When I want to explain a detached head, I take them to a topless bar.
 
2021-09-13 6:28:54 AM  
Gallant describes his commits with references to project tasks :

$ git commit -m "[RFE 1789] adding oauth module, interface and authentication hook and modifying login process"

Goofus commits his code with the same message over and over and over:

$ git commit -m "fixing one or two things"
Adding 3 new files and modifying 1050+ lines of code ...


When one gets an oil change on their car, the work bill should reflect maybe 1) oil, 2) filter, and 3) labor. You'd expect they would only drain your old oil and pour new oil in. But if you look behind your car and you see your car parts and boxes laying everywhere, you'd want a breakdown on what they changed and if they touched something they shouldn't have. You don't want to open the hood and double check every connection.

And so it is with git commit messages.
 
2021-09-13 6:31:10 AM  
get thiss fuk outta here
 
2021-09-13 6:35:45 AM  
Fark user imageView Full Size


never approach the repo without it
 
2021-09-13 7:04:04 AM  

Tom Marvolo Bombadil: [Fark user image image 600x787]

never approach the repo without it


wip
wip
wip
still wip
 
2021-09-13 7:07:46 AM  
Once they port VI over to SystemD it'll have a decent text editor like EMACs did. Wait... are they same thing? Is SysetemD the EMACs of init systems???? History is repeating itself! *MIND BLOWN*
 
2021-09-13 8:04:23 AM  

aerojockey: The revision control system is something that you should think about as little as possible.


Here's the counter-argument to that: the ways in which your code changes constitute valuable documentation. What changed, when, and why, and how it impacts future changes, is valuable. And whether you use Git or not, you can't get that without thinking about how you manage your version control system.

Git is definitely overcomplicated, because it's solving a big problem that most people don't actually have: distributed versioning. You can, theoretically, use git without there being a single repo that's the source of truth, and everyone can just push/pull from everybody else's computers via SSH. And the CLI is... idosyncratic.

But to say, "oh, you shouldn't think about revision control any more than you absolutely have to," is a stupid thing to say, even if you're using SVN. You still need to be planning your check-ins, you still need to be ensuring that what changes as part of a unit of work is clearly attached to that unit of work, and that takes planning and thinking. I've worked in non-Git source control, and nothing is more terrible than somebody doing a dozen check-ins as part of an effort, scattered in the history in no particular order. Which happens in Git too, when people don't think about how they use their revision control system.

(True fact: I'm a source control history slob, to this is absolute hypocrisy coming from me, but I'm usually the only developer, soooo)
 
2021-09-13 8:26:56 AM  

t3knomanser: aerojockey: The revision control system is something that you should think about as little as possible.

Here's the counter-argument to that: the ways in which your code changes constitute valuable documentation. What changed, when, and why, and how it impacts future changes, is valuable.


Yeah, it's called, "you run a small test suite and enter a reasonably detailed commit message".  Which is enough for all but the most complex projects, and is what I consider as little as possible.  The RCS keeps track of all the other stuff for you.

BTW, none of what you wrote is a counter-argument to what I said.  You were arguing with a ghost who claimed you should never think about your RCS.  I said you should think about it as little as possible.  Which, to be fair, is a bit of a shortcut to saying your RCS should not be something you have to think about more than you have to, but I think it should've got point across.
 
2021-09-13 8:34:56 AM  

t3knomanser: aerojockey: The revision control system is something that you should think about as little as possible.

Here's the counter-argument to that: the ways in which your code changes constitute valuable documentation. What changed, when, and why, and how it impacts future changes, is valuable. And whether you use Git or not, you can't get that without thinking about how you manage your version control system.

Git is definitely overcomplicated, because it's solving a big problem that most people don't actually have: distributed versioning. You can, theoretically, use git without there being a single repo that's the source of truth, and everyone can just push/pull from everybody else's computers via SSH. And the CLI is... idosyncratic.

But to say, "oh, you shouldn't think about revision control any more than you absolutely have to," is a stupid thing to say, even if you're using SVN. You still need to be planning your check-ins, you still need to be ensuring that what changes as part of a unit of work is clearly attached to that unit of work, and that takes planning and thinking. I've worked in non-Git source control, and nothing is more terrible than somebody doing a dozen check-ins as part of an effort, scattered in the history in no particular order. Which happens in Git too, when people don't think about how they use their revision control system.

(True fact: I'm a source control history slob, to this is absolute hypocrisy coming from me, but I'm usually the only developer, soooo)


Always write/document/commit your code as if someone else will have to pick it up in the morning. Even if nobody else ever does, you'll still be glad when you have to revisit today's code in a couple of months or years.

I demanded that our entire subversion history be ported to git when we switched. And sure enough, this year I've had to go all the way back to a commit from 2008 to figure out the rationale behind some code.
 
2021-09-13 9:07:02 AM  

aerojockey: t3knomanser: aerojockey: The revision control system is something that you should think about as little as possible.

Here's the counter-argument to that: the ways in which your code changes constitute valuable documentation. What changed, when, and why, and how it impacts future changes, is valuable.

Yeah, it's called, "you run a small test suite and enter a reasonably detailed commit message".  Which is enough for all but the most complex projects, and is what I consider as little as possible.  The RCS keeps track of all the other stuff for you.

BTW, none of what you wrote is a counter-argument to what I said.  You were arguing with a ghost who claimed you should never think about your RCS.  I said you should think about it as little as possible.  Which, to be fair, is a bit of a shortcut to saying your RCS should not be something you have to think about more than you have to, but I think it should've got point across.


This might be suitable for a solo dev or a small team but anything larger than that and you need a bit more rigor
 
2021-09-13 9:22:06 AM  

aerojockey: Yeah, it's called, "you run a small test suite and enter a reasonably detailed commit message".  Which is enough for all but the most complex projects, and is what I consider as little as possible.


So, I'm detecting a trend of weaselwords here. And sure, we're talking in the abstract, so it's hard to be concrete, but "as little as possible" is something I'd potentially agree with, if we could agree on the definition of "little". And "reasonably detailed commit message", I might agree with, depending on the definition of "reasonably detailed".

When I'm planning out a complex feature, an "epic" or whatever the buzzword is, I tend to be thinking several commits ahead, which if you ask me, is as little as possible. Since I'm often working in an environment where I have lots of microcommits because that's the quickest way to get experimental code changes onto the hardware that needs to run them (because I do embedded stuff), I'm thinking about how I'm going to go back and squash them into one single, clean commit. When I'm being disciplined (which again, isn't often enough), I might spend an hour or two going back through the commit history and trying to condense a bunch of microexperiments into one cohesive coherent commit that encapsulates the narrative and everything I learned by experimenting.

If you ask me, that's as "little as possible", and "reasonably detailed".
 
2021-09-13 9:31:27 AM  
Because I got into Software development so that I could write the same damn things multiple times : 

1. Write how to break down the feature and achieve it in Jira / feature tracking software
2. Write comments in the code relating how the design of the feature works
3. write a description of the feature in the commit message
4. Write a description and justification of the feature in the merge?

oh... and ...
5. Write the code for the feature.

And if any of these are inconsistent (they will be) or use different language (they will) you get dinged for it.

Linus : 

Frack off and refactor the git command line interface, you pompous shiatehead.
 
2021-09-13 9:45:49 AM  

rubi_con_man: 1. Write how to break down the feature and achieve it in Jira / feature tracking software


Ideally, the developer doesn't do this. That's more of a product owner/analyst task.

rubi_con_man: 2. Write comments in the code relating how the design of the feature works


Sparingly- I think the important thing for code comments is that they need to provide insight into why the code exists, and it's useful to have at least some of that in line with the code itself. Not so much "why" from a feature standpoint, but "why I made this specific implementation choice right here on this line".

rubi_con_man: 3. write a description of the feature in the commit message


This is your main explanation of "why" this code exists. What it does, how it connects to existing code, what other developers (and potentially users) could expect to see differently.

rubi_con_man: 4. Write a description and justification of the feature in the merge?


Again, not a thing you should do. There shouldn't be merges, as a general rule. Just rebase branches on each other. This means your release branch is a purely linear series of commits, with no merge commits.

rubi_con_man: Frack off and refactor the git command line interface, you pompous shiatehead.


It is a really shiatty and confusing CLI interface.
 
2021-09-13 10:24:44 AM  

EnzoTheCoder: What a prick, talking like he owns the goddamn thing.


POS Microsoft owns it.

Which explains alot
 
2021-09-13 10:36:41 AM  

SoupGuru: What's the difference between being triggered and having opinions?

Sure, he expresses his opinions bluntly on occasion but I've never seen him need a safe space or anything.

Seems more like other people get triggered when he weighs in on something.


Because those more people are more disgenuine and not open minded enough to admit that others might be honest and know more abt the subject than them.

Murca
 
2021-09-13 10:40:20 AM  
what fi we elbuod tequnseed evri 2nt ligot pf /_/
 
2021-09-13 10:41:08 AM  

erik-k: Ivo Shandor: enry: He was also one of the primary developers of git, so maybe he knows what he's talking about.  Or he's just opinionated and doesn't like new things (looking at you, systemd).

Systemd is a steaming turd.

There's a whole lot of "____ always USED to Just Work until systemd".

My favorite: I always USED to be able to trust that my network would be up before entering runlevel 3...


Yea

SystemDuh violates the KISS Method .

Wants to do everything under one roof.

UNIX admins cry
 
2021-09-13 10:42:48 AM  

aerojockey: qorkfiend: VisualiseThis: But I like merge commits.

You - get out

Rebase and squash for life

The very fact that you have arguments about the best way to merge shows what a vile POS git is.  The revision control system is something that you should think about as little as possible.  What you should be thinking about is, you know, your actual work.  Git is a clingy attention hog that forces you think about git all the farking time.

Eff that.  SVN FTW.  Or, at least, not-git FTW.  The people who work in my project (svn based) almost never have to think about revision control, apart from committing and updating, and the occasional branch, and I don't want them to.  My #1 goal in life is never to have to explain to an engineer what a detached head is.


Otherwise known as a head job
 
2021-09-13 10:44:34 AM  

turboke: t3knomanser: aerojockey: The revision control system is something that you should think about as little as possible.

Here's the counter-argument to that: the ways in which your code changes constitute valuable documentation. What changed, when, and why, and how it impacts future changes, is valuable. And whether you use Git or not, you can't get that without thinking about how you manage your version control system.

Git is definitely overcomplicated, because it's solving a big problem that most people don't actually have: distributed versioning. You can, theoretically, use git without there being a single repo that's the source of truth, and everyone can just push/pull from everybody else's computers via SSH. And the CLI is... idosyncratic.

But to say, "oh, you shouldn't think about revision control any more than you absolutely have to," is a stupid thing to say, even if you're using SVN. You still need to be planning your check-ins, you still need to be ensuring that what changes as part of a unit of work is clearly attached to that unit of work, and that takes planning and thinking. I've worked in non-Git source control, and nothing is more terrible than somebody doing a dozen check-ins as part of an effort, scattered in the history in no particular order. Which happens in Git too, when people don't think about how they use their revision control system.

(True fact: I'm a source control history slob, to this is absolute hypocrisy coming from me, but I'm usually the only developer, soooo)

Always write/document/commit your code as if someone else will have to pick it up in the morning. Even if nobody else ever does, you'll still be glad when you have to revisit today's code in a couple of months or years.

I demanded that our entire subversion history be ported to git when we switched. And sure enough, this year I've had to go all the way back to a commit from 2008 to figure out the rationale behind some code.


Code the wet sprocket
 
2021-09-13 11:25:17 AM  

rubi_con_man: Because I got into Software development so that I could write the same damn things multiple times : 

1. Write how to break down the feature and achieve it in Jira / feature tracking software
2. Write comments in the code relating how the design of the feature works
3. write a description of the feature in the commit message
4. Write a description and justification of the feature in the merge?

oh... and ...
5. Write the code for the feature.

And if any of these are inconsistent (they will be) or use different language (they will) you get dinged for it.

Linus : 

Frack off and refactor the git command line interface, you pompous shiatehead.


Settle down Bill
 
2021-09-13 11:28:57 AM  

Wine Sipping Elitist: Gallant describes his commits with references to project tasks :

$ git commit -m "[RFE 1789] adding oauth module, interface and authentication hook and modifying login process"

Goofus commits his code with the same message over and over and over:

$ git commit -m "fixing one or two things"
Adding 3 new files and modifying 1050+ lines of code ...


When one gets an oil change on their car, the work bill should reflect maybe 1) oil, 2) filter, and 3) labor. You'd expect they would only drain your old oil and pour new oil in. But if you look behind your car and you see your car parts and boxes laying everywhere, you'd want a breakdown on what they changed and if they touched something they shouldn't have. You don't want to open the hood and double check every connection.

And so it is with git commit messages.


GitHub: commit at your and others own risk.
 
2021-09-13 2:09:05 PM  

enry: He was also one of the primary developers of git, so maybe he knows what he's talking about.  Or he's just opinionated and doesn't like new things (looking at you, systemd).


New Trojan Horse things, you mean, courtesy of RedHat.
 
2021-09-13 5:01:54 PM  

t3knomanser: aerojockey: Yeah, it's called, "you run a small test suite and enter a reasonably detailed commit message".  Which is enough for all but the most complex projects, and is what I consider as little as possible.

So, I'm detecting a trend of weaselwords here. And sure, we're talking in the abstract, so it's hard to be concrete, but "as little as possible" is something I'd potentially agree with, if we could agree on the definition of "little". And "reasonably detailed commit message", I might agree with, depending on the definition of "reasonably detailed".

When I'm planning out a complex feature, an "epic" or whatever the buzzword is, I tend to be thinking several commits ahead, which if you ask me, is as little as possible. Since I'm often working in an environment where I have lots of microcommits because that's the quickest way to get experimental code changes onto the hardware that needs to run them (because I do embedded stuff), I'm thinking about how I'm going to go back and squash them into one single, clean commit. When I'm being disciplined (which again, isn't often enough), I might spend an hour or two going back through the commit history and trying to condense a bunch of microexperiments into one cohesive coherent commit that encapsulates the narrative and everything I learned by experimenting.

If you ask me, that's as "little as possible", and "reasonably detailed".


All right, fine.  So, back to the original point.  How do detached heads help you achieve this?  How is it that four variations on merging, branching, etc., and all this other wonderful freedom git gives you, help you achieve this?  You have to think about this stuff, and a whole bunch of other crap that doesn't help you, if you use git.

OTOH, the only thing you mentioned that's beyond Subversion is the squashing, and that's probably not needed.  If you're doing something experimental you should already be in a branch, and you can pick and choose commits to merge back without squashing first, and give them that nice commit message you worked an hour on.  And, unlike git, you'll still have record of the original experiment by default.

It's sounds like Subversion is the RCS that lets you think as little about the RCS as possible, for what you consider as little as possible.
 
2021-09-13 5:29:19 PM  

aerojockey: t3knomanser: aerojockey: Yeah, it's called, "you run a small test suite and enter a reasonably detailed commit message".  Which is enough for all but the most complex projects, and is what I consider as little as possible.

So, I'm detecting a trend of weaselwords here. And sure, we're talking in the abstract, so it's hard to be concrete, but "as little as possible" is something I'd potentially agree with, if we could agree on the definition of "little". And "reasonably detailed commit message", I might agree with, depending on the definition of "reasonably detailed".

When I'm planning out a complex feature, an "epic" or whatever the buzzword is, I tend to be thinking several commits ahead, which if you ask me, is as little as possible. Since I'm often working in an environment where I have lots of microcommits because that's the quickest way to get experimental code changes onto the hardware that needs to run them (because I do embedded stuff), I'm thinking about how I'm going to go back and squash them into one single, clean commit. When I'm being disciplined (which again, isn't often enough), I might spend an hour or two going back through the commit history and trying to condense a bunch of microexperiments into one cohesive coherent commit that encapsulates the narrative and everything I learned by experimenting.

If you ask me, that's as "little as possible", and "reasonably detailed".

All right, fine.  So, back to the original point.  How do detached heads help you achieve this?  How is it that four variations on merging, branching, etc., and all this other wonderful freedom git gives you, help you achieve this?  You have to think about this stuff, and a whole bunch of other crap that doesn't help you, if you use git.

OTOH, the only thing you mentioned that's beyond Subversion is the squashing, and that's probably not needed.  If you're doing something experimental you should already be in a branch, and you can pick and choose commits to merge back without squashing first, and give them that nice commit message you worked an hour on.  And, unlike git, you'll still have record of the original experiment by default.

It's sounds like Subversion is the RCS that lets you think as little about the RCS as possible, for what you consider as little as possible.


Needing an hour to write a decent commit message sounds like a "you" problem.
 
2021-09-13 5:35:03 PM  
Have Biden ban Linux, and mandate windows nation wide.

Problem solved.
 
2021-09-13 5:40:59 PM  

qorkfiend: Needing an hour to write a decent commit message sounds like a "you" problem.


Not mine.  t3knomanser's was the one who wanted to spend upwards of an hour digesting little commits into a single big commit.
 
2021-09-13 9:24:53 PM  

aerojockey: How do detached heads help you achieve this?


How does being able to checkout a historical check-in in SVN help you? It's the same thing.

aerojockey: How is it that four variations on merging, branching, etc


There aren't four. Like, I want to preface this, so I'm not misunderstood: git is farking terrible. Specifically it overcomplicates a bunch of shiat because of its distributed-first approach. This means that dealing with conflicting histories is a giant shiatpile, because well, everybody has their own local history. But that has nothing to do with the basic operations of merging, or branching.

Branches are the most simple thing possible in Git: they're just pointers to any arbitrary commit. If anything, that's the best feature of Git. Pick a point in history, and branch from there. Fun. And while merging and rebasing are similar, they're not the same thing and while more traditional version systems don't give a shiat, git's recognition of the difference is actually quite useful.

The specific distinction is that traditional source control thinks in terms of checkin/checkout, and thus every change is located in time. Whereas git tracks changes in terms of its previous change and subsequent changes. That's a huge innovation which is actually in git's favor, and helps describe the difference between merges and rebases (and if you have two other variations or merges, let me know, because I can't think of any others to get up to four).

Where git shiats the bed isn't on these basic mechanics- it's on how it deals with conflicts between different commits. Which, if you're very careful about how you use rebases and merges is avoidable- but again, you have to be git-savvy enough to understand why you're being careful. Again, don't take this to be a git-fan thing, git is terrible, but it comes from a specific set of design decisions that make sense and scale to very specific use cases that most of us don't have.
 
2021-09-13 10:11:18 PM  

t3knomanser: aerojockey: How do detached heads help you achieve this?

How does being able to checkout a historical check-in in SVN help you? It's the same thing.

aerojockey: How is it that four variations on merging, branching, etc

There aren't four. Like, I want to preface this, so I'm not misunderstood: git is farking terrible. Specifically it overcomplicates a bunch of shiat because of its distributed-first approach. This means that dealing with conflicting histories is a giant shiatpile, because well, everybody has their own local history. But that has nothing to do with the basic operations of merging, or branching.

Branches are the most simple thing possible in Git: they're just pointers to any arbitrary commit. If anything, that's the best feature of Git. Pick a point in history, and branch from there. Fun. And while merging and rebasing are similar, they're not the same thing and while more traditional version systems don't give a shiat, git's recognition of the difference is actually quite useful.

The specific distinction is that traditional source control thinks in terms of checkin/checkout, and thus every change is located in time. Whereas git tracks changes in terms of its previous change and subsequent changes. That's a huge innovation which is actually in git's favor, and helps describe the difference between merges and rebases (and if you have two other variations or merges, let me know, because I can't think of any others to get up to four).

Where git shiats the bed isn't on these basic mechanics- it's on how it deals with conflicts between different commits. Which, if you're very careful about how you use rebases and merges is avoidable- but again, you have to be git-savvy enough to understand why you're being careful. Again, don't take this to be a git-fan thing, git is terrible, but it comes from a specific set of design decisions that make sense and scale to very specific use cases that most of us don't have.


Linus did write git so that he could effectively manage kernel contributions after losing the free BitKeeper license. So the distributed development model was a hard requirement. I'm not quite sure why git caught on and beat out other systems like mercurial. I'd guess that it was the easy offline branching and the popularity of Linux itself. At the time that it was introduced it was also very fast compared to other systems, which definitely helped.

The CLI is somewhat obnoxious, but has been getting more sane over time with more obvious switches and better behavior. Really you just need to train someone for a day or two on how it works (both the commands themselves and the internal design) and then it makes much more sense. Far too often devs get a bare minimum of: clone, commit, push, and pull without any real understanding of what's happening and that leads to people freaking out about conflicts and detached heads.
 
2021-09-14 12:03:46 AM  
Lillyhammer u knoe teh dril
 
2021-09-14 2:48:26 AM  

t3knomanser: aerojockey: How do detached heads help you achieve this?

How does being able to checkout a historical check-in in SVN help you? It's the same thing.


Not really.  Subversion doesn't put your working copy in a state where anything you do has different implications than what you'd do normally, and it does something relatively sane if you try to commit without creating a branch.  Git?  Just another thing you can't not think about.

t3knomanser: Which, if you're very careful about how you use rebases and merges is avoidable- but again, you have to be git-savvy enough to understand why you're being careful.


Therein lies the whole crux of what I'm saying.  You're absolutely right about this, but RCS users shouldn't need to be savvy to do a simple merge, and there's no reason they have to be.  And with git it's not just merges.  It's been pointed out that noobs need better training than just learning the basic clone/pull/commit/push cycle.  But they really shouldn't.  git does the diametric opposite of what a good RCS should do.

And that's just issues with the representation.  And we haven't even got to the part where git shjts the bed.

All I'm saying is, people who are good at writing operating systems shouldn't be making user interface tools.
 
Displayed 50 of 54 comments


Oldest | « | 1 | 2 | » | Newest | Show all


View Voting Results: Smartest and Funniest

This thread is closed to new comments.

Continue Farking




On Twitter


  1. Links are submitted by members of the Fark community.

  2. When community members submit a link, they also write a custom headline for the story.

  3. Other Farkers comment on the links. This is the number of comments. Click here to read them.

  4. Click here to submit a link.