Version Control Questions Megathread (SVN / git / whatever else)

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Version Control Questions Megathread (SVN / git / whatever else)

«‹›100 »

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

What sequence of commands will make a git repo fully up to date and on a specific branch/tag/commit, regardless of what branch/tag/commit it is currently at?

Here's what I ended up with. It doesn't seem right since there is a rebase in there and I want to blow away any changes that may have occurred locally (there shouldn't be any).

code:

$ git fetch
$ git fetch --tags
$ git checkout <name>
$ git rebase

# ? Feb 19, 2014 01:41

Adbot: ADBOT LOVES YOU

# ? May 24, 2024 15:54

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

fletcher posted:

I want to blow away any changes that may have occurred locally

Maybe

code:

git fetch
git fetch --tags
git reset --hard @{u}

@{u} is short for @{upstream} and is defined in .git/config for each local branch as "where does this branch pull from". The hard reset will move your local copy of the branch to match the remote branch and discard all working tree local modifications.

# ? Feb 19, 2014 02:15

Hughlander: May 11, 2005

fletcher posted:

What sequence of commands will make a git repo fully up to date and on a specific branch/tag/commit, regardless of what branch/tag/commit it is currently at?

Here's what I ended up with. It doesn't seem right since there is a rebase in there and I want to blow away any changes that may have occurred locally (there shouldn't be any).
code:
$ git fetch
$ git fetch --tags
$ git checkout <name>
$ git rebase

code:

git fetch origin
git fetch origin --tags
git reset --hard
git clean -fdx
git checkout -f <name>
git submodule sync
git submodule foreach --recursive 'git fetch origin'
git checkout -- .
git clean -ffdx
git submodule update --init --recursive --force
git submodule foreach --recursive 'git clean -ffdx && git checkout -- .'
git status --porcelain | cut -f 1 -d ' ' | xargs rm -rf

# ? Feb 19, 2014 03:03

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

# ? Feb 19, 2014 03:12

Hughlander: May 11, 2005

fletcher posted:

You asked

I'm pretty sure I can put a repo in a bad state without each command (When I went over it there was one that was questionable and I'll have to check comments as to why it's there.)

# ? Feb 19, 2014 03:27

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

My repo is pretty small, I'm tempted to just rm -r it each time and just use git clone && git checkout again. Or does that still not achieve what I want?

And how come the nice simple looking solution from Lysidas wouldn't work? I haven't used git reset before.

# ? Feb 19, 2014 03:37

Hughlander: May 11, 2005

fletcher posted:

My repo is pretty small, I'm tempted to just rm -r it each time and just use git clone && git checkout again. Or does that still not achieve what I want?

And how come the nice simple looking solution from Lysidas wouldn't work? I haven't used git reset before.

Fails completely with submodules, leaves untracked files, doesn't check out an arbitrary sha/branch...

# ? Feb 19, 2014 03:49

baka kaba: Jul 19, 2003; PLEASE ASK ME, THE SELF-PROFESSED NO #1 PAUL CATTERMOLE FAN IN THE SOMETHING AWFUL S-CLUB 7 MEGATHREAD, TO NAME A SINGLE SONG BY HIS EXCELLENT NU-METAL SIDE PROJECT, SKUA, AND IF I CAN'T PLEASE TELL ME TO
EAT SHIT

Thanks for the diff/merge recommends, I forgot they're often two separate things...

# ? Feb 19, 2014 17:54

Megaman: May 8, 2004; I didn't read the thread BUT...

fletcher posted:

My repo is pretty small, I'm tempted to just rm -r it each time and just use git clone && git checkout again. Or does that still not achieve what I want?

And how come the nice simple looking solution from Lysidas wouldn't work? I haven't used git reset before.

The whole thing about git is that you never ever have to reclone a repo. Recloning means you're doing something really wrong, or you're missing git foo knowledge.

# ? Feb 19, 2014 20:35

Nippashish: Nov 2, 2005; Let me see you dance!

Megaman posted:

The whole thing about git is that you never ever have to reclone a repo.

I don't get it. What's wrong with re-cloning? Git can be pretty drat arcane, sometimes it's easier to just blow things away and start from scratch.

# ? Feb 19, 2014 21:58

Megaman: May 8, 2004; I didn't read the thread BUT...

Nippashish posted:

I don't get it. What's wrong with re-cloning? Git can be pretty drat arcane, sometimes it's easier to just blow things away and start from scratch.

What would be a single valid reason to reclone when you have everything already and can reset or pull from where you are? The reason people start from scratch is because they don't know enough about git to get to where they need to be in their repo.

Can you give me one reason how git arcane? And equally or more arcane than svn or cvs? One of the great things about git is that you can go to any point in history. There's really only like 3 things you need to know to get anywhere you need to go: pull, checkout, and reset sort/hard. That's a very small amount of commands.

# ? Feb 19, 2014 23:42

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Megaman posted:

Can you give me one reason how git arcane?

Hughlander posted:

code:

git fetch origin
git fetch origin --tags
git reset --hard
git clean -fdx
git checkout -f <name>
git submodule sync
git submodule foreach --recursive 'git fetch origin'
git checkout -- .
git clean -ffdx
git submodule update --init --recursive --force
git submodule foreach --recursive 'git clean -ffdx && git checkout -- .'
git status --porcelain | cut -f 1 -d ' ' | xargs rm -rf

# ? Feb 19, 2014 23:47

down with slavery: Dec 23, 2013; STOP QUOTING MY POSTS SO PEOPLE THAT AREN'T IDIOTS DON'T HAVE TO READ MY FUCKING TERRIBLE OPINIONS THANKS

Ithaqua posted:

Perhaps you'd like to share the technology where you can provide instructions for an operation of similar complexity out of context and seem not silly? Sure, he could break down and explain it all, but I don't know, it's quite specific what he's asking and it's a script that assumes submodules are being used which is not necessarily (even usually) true.

Also I'm pretty sure the git clean and git reset commands do the same thing, not sure why both would be required.

An easier way:

code:

git clone <repo>
git checkout <tag>

fletcher posted:

My repo is pretty small, I'm tempted to just rm -r it each time and just use git clone && git checkout again. Or does that still not achieve what I want?

This is exactly what you should do and anyone who tells you otherwise is a goddamn moron.

Megaman posted:

The whole thing about git is that you never ever have to reclone a repo. Recloning means you're doing something really wrong, or you're missing git foo knowledge.

Yes, and when you are working on a project that demands that level of complexity, you should definitely use those features. But considering most people aren't, maybe saying this as some kind of truism is kind of I don't know, stupid?

down with slavery fucked around with this message at 00:18 on Feb 20, 2014

# ? Feb 20, 2014 00:09

Megaman: May 8, 2004; I didn't read the thread BUT...

down with slavery posted:

Perhaps you'd like to share the technology where you can provide instructions for an operation of similar complexity out of context and seem not silly? Sure, he could break down and explain it all, but I don't know, it's quite specific what he's asking and it's a script that assumes submodules are being used which is not necessarily (even usually) true.

Also I'm pretty sure the git clean and git reset commands do the same thing, not sure why both would be required.

An easier way:
code:
git clone <repo>
git checkout <tag>

Exactly. This is exactly the problem with people who look at a scientific theory and say "that's stupid, that doesn't work and this is why". You are not allowed to say that UNLESS you have a complete alternative that covers all the grounds the one you are calling stupid does that works better somehow. In this case, if you can provide a better tool than git that will do exactly what git did with those commands more easily and more efficiently, provide it. Otherwise, git is the most proficient and easiest thing we have at the current time. Again, these are trivial commands and steps, the reason it may seem arcane or complicated is just because you don't know it. It just takes some reading and understanding of what's going on, and the realization that there's nothing better out there. Mysterious and complex thing are mysterious and complex until you become familiar with them, then they become trivial and familiar.

Megaman fucked around with this message at 00:22 on Feb 20, 2014

# ? Feb 20, 2014 00:18

Nippashish: Nov 2, 2005; Let me see you dance!

Megaman posted:

What would be a single valid reason to reclone when you have everything already and can reset or pull from where you are?

The ability to not start from scratch does not imply that starting from scratch is not the best option. Hughlander's post is an example of why starting from scratch is sometimes the best option even when it is not strictly necessary.

# ? Feb 20, 2014 00:19

down with slavery: Dec 23, 2013; STOP QUOTING MY POSTS SO PEOPLE THAT AREN'T IDIOTS DON'T HAVE TO READ MY FUCKING TERRIBLE OPINIONS THANKS

Git is meant to be used with a remote host. If you're not using something else to host your git repository, you really aren't the user git was intended for (sorry). Being able to "start from scratch" or in other words, "deploy any version of my source code quickly" is a benefit, not a signal that you lack some sort of knowledge regarding git. The submodule bullshit that half that script was is just absurd too, totally out of most use cases and again, if you're doing it the easy way, it's two more lines.

There are plenty of criticisms of git, but you basically posted some kind of reverse code golf that covers every use case when .0001% of users would ever have to do anything like that. If you ever have to type that sequence of commands into git for anything other than some sort of sick perverted pleasure, you have failed at using the tool.

Megaman posted:

In this case, if you can provide a better tool than git that will do exactly what git did with those commands more easily and more efficiently, provide it.

Bash

Megaman posted:

Again, these are trivial commands and steps, the reason it may seem arcane or complicated is just because you don't know it.

I'm actually quite experienced with git and know it quite well. Those commands are dumb and stupid and if you're typing them into your computer for any reason (especially to post them) you are an idiot.

The real problem is that you do not understand the purpose of version control.

down with slavery fucked around with this message at 00:27 on Feb 20, 2014

# ? Feb 20, 2014 00:21

Sir_Substance: Dec 13, 2013

down with slavery posted:

The real problem is that you do not understand the purpose of version control.

I have a deep and abiding hatred of git because I feel that the purpose of version control is to make managing my code versions and working with other people on the same codebase effortless. If there are two things git doesn't do, its those. It is arcane by the standard of commands set by every other VCS, and I've seen way more git repos hosed by an accidental but well meaning rookie command then any other system.

# ? Feb 20, 2014 01:43

down with slavery: Dec 23, 2013; STOP QUOTING MY POSTS SO PEOPLE THAT AREN'T IDIOTS DON'T HAVE TO READ MY FUCKING TERRIBLE OPINIONS THANKS

Sir_Substance posted:

If there are two things git doesn't do, its those. It is arcane by the standard of commands set by every other VCS.

What is something that is arcane in git that is not in another command line VCS? I'm not saying their aren't oddities, but that string of commands quoted above has no place in a criticism of git.

# ? Feb 20, 2014 01:48

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

Megaman posted:

What would be a single valid reason to reclone when you have everything already and can reset or pull from where you are?

- Getting it done already.
- Annoying strangers on the internet who believe everything has to be done just so.

# ? Feb 20, 2014 01:50

Deus Rex: Mar 5, 2005

sometimes it's nice to hold onto a repo-local exclude or config file, but it's easy enough to copy those things over if you need them on a re-clone.

# ? Feb 20, 2014 02:10

Hughlander: May 11, 2005

down with slavery posted:

Also I'm pretty sure the git clean and git reset commands do the same thing, not sure why both would be required.

bash posted:

sandbox : /data/oclint.git|master
17:15:00$ git status
# On branch master
nothing to commit, working directory clean
sandbox : /data/oclint.git|master
17:15:01$ touch watch-this-not-be-reset
sandbox : /data/oclint.git|master?
17:15:10$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# watch-this-not-be-reset
nothing added to commit but untracked files present (use "git add" to track)
sandbox : /data/oclint.git|master?
17:15:12$ git reset --hard
HEAD is now at 24ae82b Merge pull request #179 from lqi/add-oclint-version
sandbox : /data/oclint.git|master?
17:17:46$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# watch-this-not-be-reset
nothing added to commit but untracked files present (use "git add" to track)
sandbox : /data/oclint.git|master?

# ? Feb 20, 2014 02:18

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Sir_Substance posted:

I have a deep and abiding hatred of git because I feel that the purpose of version control is to make managing my code versions and working with other people on the same codebase effortless. If there are two things git doesn't do, its those. It is arcane by the standard of commands set by every other VCS, and I've seen way more git repos hosed by an accidental but well meaning rookie command then any other system.

I'm with you on this. I steer my clients away from using Git if they're not using it already. Source control should be simple and easy to use; Git is neither. Every SCM platform has its own set of challenges, but Git's challenge is "actually using it for day to day work productively".

# ? Feb 20, 2014 02:20

necrotic: Aug 2, 2005; I owe my brother big time for this!

Hughlander posted:

Yeah, reset only touches tracked files. Untracked files are handled with clean (although its not restricted to untracked files).

# ? Feb 20, 2014 02:27

shrughes: Oct 11, 2008; (call/cc call/cc)

This is just ridiculous, git is perfectly suitable for day-to-day use. Have you noticed all the people using it? It's not hard at all. All you need for basic use is git pull, git push, git checkout <branch>, git add <file>, git commit, and git merge <branch>. And occasionally, git checkout <commit>. You can't get more minimalist in a version control system than that. If you want more advanced use, there's some more :airquote:

advanced

things you could do that make your life easier. People who find this confusing are not qualified to be programmers.

# ? Feb 20, 2014 02:29

Smugdog Millionaire: Sep 14, 2002; 8) Blame Icefrog

Megaman posted:

What would be a single valid reason to reclone when you have everything already and can reset or pull from where you are? The reason people start from scratch is because they don't know enough about git to get to where they need to be in their repo.

Probably the most obvious valid reason to reclone would be because it's the easiest and most reliable method to accomplish what fletcher wanted.

Megaman posted:

This is exactly the problem with people who look at a scientific theory and say "that's stupid, that doesn't work and this is why". You are not allowed to say that UNLESS you have a complete alternative that covers all the grounds the one you are calling stupid does that works better somehow.

Actually, it's quite important to science for people to be able to poke holes in established theories without being required to provide their own complete Theory Of Everything. If people followed your advice we wouldn't have any scientific theories at all.

Megaman posted:

In this case, if you can provide a better tool than git that will do exactly what git did with those commands more easily and more efficiently, provide it. Otherwise, git is the most proficient and easiest thing we have at the current time.

It's true that git is the most proficient and easiest thing we have at our finger tips for manipulating the contents of our .git folders. Trying to make any further claims based on this point will result in nothing but circular reasoning.

Megaman posted:

It just takes some reading and understanding of what's going on, and the realization that there's nothing better out there.

It's fairly trivial to imagine use cases where git isn't the best thing out there.

# ? Feb 20, 2014 02:35

Megaman: May 8, 2004; I didn't read the thread BUT...

Smugdog Millionaire posted:

Probably the most obvious valid reason to reclone would be because it's the easiest and most reliable method to accomplish what fletcher wanted.

Actually, it's quite important to science for people to be able to poke holes in established theories without being required to provide their own complete Theory Of Everything. If people followed your advice we wouldn't have any scientific theories at all.

It's true that git is the most proficient and easiest thing we have at our finger tips for manipulating the contents of our .git folders. Trying to make any further claims based on this point will result in nothing but circular reasoning.

It's fairly trivial to imagine use cases where git isn't the best thing out there.

Again, can you provide a better source control tool than git/mercurial that has the power and ease of both? I have not heard any ideas yet, but I'm definitely willing to hear them. In my experience people who fight git and mercurial just refuse to learn the tools out of sheer stubbornness for no reason.

# ? Feb 20, 2014 03:57

Megaman: May 8, 2004; I didn't read the thread BUT...

shrughes posted:

This is just ridiculous, git is perfectly suitable for day-to-day use. Have you noticed all the people using it? It's not hard at all. All you need for basic use is git pull, git push, git checkout <branch>, git add <file>, git commit, and git merge <branch>. And occasionally, git checkout <commit>. You can't get more minimalist in a version control system than that. If you want more advanced use, there's some more advanced things you could do that make your life easier. People who find this confusing are not qualified to be programmers.

It seems like this is more of a gripe with the ability to memorize and basic linux commands. Do you work in the Linux terminal all day? If not, I don't recommend git. If you can't memorize several commands, I don't recommend git. Can you explain what other method you would use in some other better VCS to do the same types of things any easier way without add/commit/merge/checkout/clone/reset/etc.? I really want to know what better and more simple/pure method there is. Can you explain this to me?

# ? Feb 20, 2014 04:03

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Megaman posted:

In my experience people who fight git and mercurial just refuse to learn the tools out of sheer stubbornness for no reason.

I know how to use Git, I just dislike it. I work in the Microsoft world, though, so there are plenty of SCM tools that are much easier to use available. Now that Git is a first-class citizen in TFS2013, we actually had a company meeting to start figuring out when we should recommend Git to people over the default centralized version control option. We couldn't think of very many cases where the distributed nature of Git is a big enough win over centralized VC to warrant the additional complexity.

# ? Feb 20, 2014 04:51

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

I agree that git is created by hardcore unix hackers to be used in a unix shell for best results but you should accept that some people just aren't into it or into what you've deemed as the one true workflow.

# ? Feb 20, 2014 04:51

down with slavery: Dec 23, 2013; STOP QUOTING MY POSTS SO PEOPLE THAT AREN'T IDIOTS DON'T HAVE TO READ MY FUCKING TERRIBLE OPINIONS THANKS

Ithaqua posted:

plenty of SCM tools that are much easier to use available

Please share

You've posted a lot about TFS in this thread, but you haven't really convinced me that it's worth the thousands Microsoft is asking. What is so much easier in TFS than git?

Ithaqua posted:

Git's challenge is "actually using it for day to day work productively".

I thought this was the version control thread not the "confess your weaknesses" thread

down with slavery fucked around with this message at 04:57 on Feb 20, 2014

# ? Feb 20, 2014 04:53

Strong Sauce: Jul 2, 2003; You know I am not really your father.

Hrm, I don't know about submodules but deleting all the files (sans the .git directory) and then doing a `git reset --hard` is not enough?

# ? Feb 20, 2014 05:17

Sir_Substance: Dec 13, 2013

down with slavery posted:

I thought this was the version control thread not the "confess your weaknesses" thread

I have nothing but contempt for you, and all developers like you.

# ? Feb 20, 2014 05:37

down with slavery: Dec 23, 2013; STOP QUOTING MY POSTS SO PEOPLE THAT AREN'T IDIOTS DON'T HAVE TO READ MY FUCKING TERRIBLE OPINIONS THANKS

Sir_Substance posted:

I have nothing but contempt for you, and all developers like you.

I'm sorry but if you've been programming for 10+ years and you feel challenged in attempting to use git day to day productively I don't know what to tell you. There are plenty of gui clients that can work if you're super command line averse but he hasn't said anything in this thread other than "hey guys check out TFS" and "hey guys check out how you can now use GIT with TFS" I'm waiting for a legitimate criticism.

Tell me more about "all developers like you"

down with slavery fucked around with this message at 05:54 on Feb 20, 2014

# ? Feb 20, 2014 05:45

shrughes: Oct 11, 2008; (call/cc call/cc)

The only SCM better than git is monotone.

If somebody could rewrite the backend of monotone I'd be grateful.

# ? Feb 20, 2014 05:49

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

down with slavery posted:

You've posted a lot about TFS in this thread, but you haven't really convinced me that it's worth the thousands Microsoft is asking. What is so much easier in TFS than git?

Well, the full value of TFS in all of the things it does in addition to version control -- project management, build, deployment, etc. VC is really a small piece of TFS.

In any case, the workflow with centralized VC is more straightforward. You have a central code repository, you make a local copy of it, and then you make changes to it. A different branch in TFS is just a different set of files in your file system (it's smarter than that internally, but the internal representation of the files and change history is totally opaque and irrelevant to me as a developer). There's no need to check out a different branch to make sure you're working on the right code.

When you're done, merge your changes and check it back in. Changesets are sequential and can't be reordered. Cherry-picking changesets for merging between branches is considered a bad practice. If you need to store work in progress that's not ready to actually be checked back in, you can shelve it temporarily, then unshelve it later.

The Git interface in Visual Studio is actually really good for the basic operations, but you still have to drop to a command line for the trickier stuff like rebasing.

When I talk about Git being harder for your average developer to use, I'm not making poo poo up to prove a point. I've worked with several clients this year who recently started using Git, and most of them had productivity issues because their devs were devoting more time than they thought was acceptable to working through source control issues. The one client who had no problems with Git had put so much red tape and process in place that they were essentially using Git as a centralized version control system.

I'm not saying that no one should use Git. If you and your teams are having awesome success and no friction using it, more power to you. My experience so far has been the opposite, that's all. It does seem like there's a horrible elitist attitude in the Git community that if you don't like it, it means that you're a stupid lovely idiot who has no business being a professional developer.

down with slavery posted:

I thought this was the version control thread not the "confess your weaknesses" thread

I thought this was the version control thread not the "get oddly defensive over people who have differing opinions" thread.

# ? Feb 20, 2014 06:04

shrughes: Oct 11, 2008; (call/cc call/cc)

Ithaqua posted:

It does seem like there's a horrible elitist attitude in the Git community that if you don't like it, it means that you're a stupid lovely idiot who has no business being a professional developer.

There's nothing wrong with being elitist. It's not whether you like it, it's that if you find git to be too difficult to use productively, you are indeed a stupid idiot crap-for-brains. That's not some controversial opinion, it's simply true. Even if Mercurial is better.

# ? Feb 20, 2014 06:21

Deus Rex: Mar 5, 2005

You have to drop down to the CLI to do a git rebase in Visual Studio? I assume you mean interactive rebase, but really? The VS team couldn't just rip off what magit or Tower or any number of alternate git UIs provide for this task?

Microsoft's incompetence notwithstanding, interactive rebase is probably one of the trickier "day to day" things to do with CLI git and it's not even really hard. I'm pretty incompetent (no CS degree, young, Lisptard, terrible programmer, etc.) and I managed to learn it in a day or two.

# ? Feb 20, 2014 06:28

down with slavery: Dec 23, 2013; STOP QUOTING MY POSTS SO PEOPLE THAT AREN'T IDIOTS DON'T HAVE TO READ MY FUCKING TERRIBLE OPINIONS THANKS

Ithaqua posted:

Well, the full value of TFS in all of the things it does in addition to version control -- project management, build, deployment, etc. VC is really a small piece of TFS.

In any case, the workflow with centralized VC is more straightforward. You have a central code repository, you make a local copy of it, and then you make changes to it. A different branch in TFS is just a different set of files in your file system (it's smarter than that internally, but the internal representation of the files and change history is totally opaque and irrelevant to me as a developer). There's no need to check out a different branch to make sure you're working on the right code.

When you're done, merge your changes and check it back in. Changesets are sequential and can't be reordered. Cherry-picking changesets for merging between branches is considered a bad practice. If you need to store work in progress that's not ready to actually be checked back in, you can shelve it temporarily, then unshelve it later.

The Git interface in Visual Studio is actually really good for the basic operations, but you still have to drop to a command line for the trickier stuff like rebasing.

Yes, things are more streamlined in TFS and you lose flexibility because of that. The internal representation of files and change history is also opaque in git if you want it to be. Yes, changing branches is more difficult than file -> open -> browse to different folder but I mean, you're getting in to a linux vs. windows debate at this point. Three clicks versus three commands in the command line.

quote:

When I talk about Git being harder for your average developer to use, I'm not making poo poo up to prove a point. I've worked with several clients this year who recently started using Git, and most of them had productivity issues because their devs were devoting more time than they thought was acceptable to working through source control issues. The one client who had no problems with Git had put so much red tape and process in place that they were essentially using Git as a centralized version control system.

I'm not saying that no one should use Git. If you and your teams are having awesome success and no friction using it, more power to you. My experience so far has been the opposite, that's all. It does seem like there's a horrible elitist attitude in the Git community that if you don't like it, it means that you're a stupid lovely idiot who has no business being a professional developer.

I don't care if you don't like it, but being unable to use it productively day to day is not an acceptable reason for a senior software developer to give in any sort of discussion about version control. I'm not being an eltist, that code you quoted as an example of why git is arcane is stupid and never used in the real world outside of very specific use cases. If you want to criticise git, make it more intelligent. It's like criticisizing perl by posting perl golf and saying it's unintelligible.

quote:

I thought this was the version control thread not the "get oddly defensive over people who have differing opinions" thread.

It's not so much that your opinion is different as much as it is you're just shilling for MSFT products in this thread without offering any real criticism of git. Probably because you don't know it. Because anyone that does would be able to tell you that the script that guy posted is absurd.

# ? Feb 20, 2014 06:32

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

down with slavery posted:

It's not so much that your opinion is different as much as it is you're just shilling for MSFT products in this thread without offering any real criticism of git.

He posted words about TFS because you freaking asked him to.

# ? Feb 20, 2014 06:41

Adbot: ADBOT LOVES YOU

# ? May 24, 2024 15:54

down with slavery: Dec 23, 2013; STOP QUOTING MY POSTS SO PEOPLE THAT AREN'T IDIOTS DON'T HAVE TO READ MY FUCKING TERRIBLE OPINIONS THANKS

Gazpacho posted:

He posted words about TFS because you freaking asked him to.

Yes, and I have no problem with that. I was saying his earlier reason was a bullshit example of git being arcane. I'm not just blindly defending git here, I have used plenty of other version control and been able to be productive with them. If the best criticism of git you can come up with is that it's "arcane" and your example is that, don't post.

# ? Feb 20, 2014 06:45

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Version Control Questions Megathread (SVN / git / whatever else)

«‹›100 »