Hit with the stupid branch...



  • The project I am working on at the moment has about 5 developers, and one of them, and our technical lead has decided that he needs to make massive changes throughout the codebase for something he is working on. He has therefore checked out vast swathes of code, exclusively, preventing the rest of us for about two hours from going about our daily business of developing stuff.

    I suggest (remember, this is the tech lead) that he might like to think about branching the project (we're working with TFS) and then merging his changes when he's happy - but no. Apparently, in his eyes at least, we have no-one in this office capable of branching and merging correctly. This struck me as rather odd, because I personally have nearly 15 years experience in writing software, and I don't look on simple repository actions like this as being beyond my wit...

    It should also be pointed out of course that, not believing in branching in the first place, he has never asked anyone in here to work with branches. In other words, he hasn't the slightest bloody clue what people know on the topic - and we ALL KNOW THAT.

    The man never fails to shock me - and is the main reason I have decided to take an account here. I'll be needing it to let of steam.

    Anyway, back to the coalface...



  • I'm always blown away by senior developers who say, "Oh, our team couldn't understand branching and merging."

    WHAT? It's not rocket surgery. Anyone capable of programming is capable of managing branches and merges, especially if you set policies to define who merges what and when.

    I worked with a guy who did understand it, but he deeply believed that no one else was ready to handle that. He came up with increasingly baroque solutions to keep people from using branching. Eventually, he went to a different team, I inherited the TFS responsibilities, and immediately started teaching people about branching.



  • Trust me, don't under estimate people's ability to mess up branching.  I have had to deal with some seriously messed up branching.



  • @DumbByAssociation said:

    The man never fails to shock me - and is the main reason I have decided to take an account here. I'll be needing it to let of steam.

    Anyway, back to the coalface...

    Welcome to TDWTF. I don't think I could go on without my daily fix :-)

    I once worked at a place, where we needed to do branching and merging for a specific project (this was cvs as far as I remember). Turned out nobody had ever really tried it the way we did it, and we ended up having at least two devs working closely together on merging the different branches. It took some time, but surprisingly we succeeded without too many bugs.

     



  • Wow locking checkouts? TRWTF.

    Even SourceSafe uses the "merge on conflict" idea.



  • @MiffTheFox said:

    Wow locking checkouts? TRWTF.

    Even SourceSafe uses the "merge on conflict" idea.

    Locking checkouts indeed...



  • @DumbByAssociation said:

    Apparently, in his eyes at least, we have no-one in this office capable of branching and merging correctly.

    Which simply means that he doesn't understand it.



  • @DumbByAssociation said:

    @MiffTheFox said:

    Wow locking checkouts? TRWTF.

    Even SourceSafe uses the "merge on conflict" idea.

    Locking checkouts indeed...

     

     Just remember, every SCCM support that, and sometimes it is good [think editing images - merging *really* doesn't work...

     And that lock on checkout is NOT the default for TFS either...

     Purely a WTF on the part of the person.



  • @MiffTheFox said:

    Wow locking checkouts? TRWTF.

    Even SourceSafe uses the "merge on conflict" idea.

    Not by default it doesn't, apparently.  Still at least the steaming great heap of shit has finally been EOL'd.  Good riddance!

     



  • One of our 'Senior Developers' refused to do anything but locking checkouts, and flat out refused to do anything with branches. It was always fun watching him manually move things from one branch to another, he'd just get the entire branch into a different directory then manually determine what files needed to be copied around. Took hours! There were lots of fights about the locked checkouts too, especially after he checked out a big swath of code and then went on vacation for a week.

    Yeah, that went over real well

    He's a Systems Engineer now. Basically not allowed to touch code, just comes up with requirements documentation. He's much happier, as are we. Sure, he doesn't actually produce good requirements, but neither do most of our other Systems Engineers, so it's something we're used too (also, our requirements change up to and including 'code complete' day).



  • This is one of the topics which I was never taught in college, which struck me as a rather very bad thing. At least things are starting to improve since many people are getting early hands on with github being so popular.



  • @DaveK said:

    @MiffTheFox said:

    Wow locking checkouts? TRWTF.

    Even SourceSafe uses the "merge on conflict" idea.

    Not by default it doesn't, apparently.  Still at least the steaming great heap of shit has finally been EOL'd.  Good riddance!

     

    Just because a tool doesn't adequately do the job its supposed to, teaches bad practices, is universally derided, often destroys that which it was meant to construct, and has been publicly denounced and abandoned by its creator doesn't mean that it'll stop being used.

     Because "branching just causes more problems than it solves, and merging is too difficult". So if you'll excuse me, I have to go twitch in the corner for a bit, then ask another developer to "check in" a file because I need to make changes.

     

     



  • @DumbByAssociation said:

    Apparently, in his eyes at least, we have no-one in this office capable of branching and merging correctly.
     

    Including him?

    Not much of a lead if his attitude to lacking capability is prevention of processes over improving capability.

    @Remy Porter said:

    I worked with a guy who did understand it, but he deeply believed that
    no one else was ready to handle that. He came up with increasingly
    baroque solutions to keep people from using branching. Eventually, he became DumbByAssociation's tech lead

    FTFY....

     



  • @ubersoldat said:

    This is one of the topics which I was never taught in college, which struck me as a rather very bad thing.
     

    Ditto, but I think my college days preceeded code versioning systems.

    I've since been shown how to branch (but not told why and when I should do so) and how to lock for checkout plus unlock when committing... but not how to merge.

    Then again, I'm the only user of the CVS I currently use, so that's less of an issue.



  • This fear of branching and merging seems like a manifestation of preemptive superstition, like they are trying to avoid some cataclysmic merging event wherein the source control data base, all the servers and the entire office get sucked into a vortex, leaving only a vacant lot occupied by a few confused survivors! As if the lost code problem of pre-source control days can be summoned by improper merging.



  • @esoterik said:

    This fear of branching and merging seems like a manifestation of preemptive superstition

    I think part of it (not necessarily in the OP's case) is also bad experiences with VCSes that do a poor job of branching and merging. I haven't used CVS enough, but svn is (or was, I've heard it's gotten better, but it was a major PITA last time I did any serious branching / merging with it) pretty awful compared to other systems.



  • @boomzilla said:

    @esoterik said:
    This fear of branching and merging seems like a manifestation of preemptive superstition

    I think part of it (not necessarily in the OP's case) is also bad experiences with VCSes that do a poor job of branching and merging. I haven't used CVS enough, but svn is (or was, I've heard it's gotten better, but it was a major PITA last time I did any serious branching / merging with it) pretty awful compared to other systems.

     

    Fear of the unknown (or distrust of technology) and/or prior bad experiences do tend to form many mental barriers to takeup.

    But that's not a reason why it shouldn't be used, just a reason why someone's currently unwilling to engage with it. I've been won over by challenging someone to perform a demo and once they'd proven how easy it was and I saw the benefits they had my buy-in.



  • @Lorne Kates said:

    Just because a tool doesn't adequately do the job its supposed to, teaches bad practices, is universally derided, often destroys that which it was meant to construct, and has been publicly denounced and abandoned by its creator doesn't mean that it'll stop being used.
    Ha! I know of (and have used and installed for customers) commercial products that use VSS as a back end!



  • @esoterik said:

    This fear of branching and merging seems like a manifestation of preemptive superstition, like they are trying to avoid some cataclysmic merging event wherein the source control data base, all the servers and the entire office get sucked into a vortex, leaving only a vacant lot occupied by a few confused survivors! As if the lost code problem of pre-source control days can be summoned by improper merging.

    This is a matter of policy and habits. If you do a lot of (small) commits and updates/pulls/whatever-term-is-appropriate-for-your flavour-VCS during a short period of time (e.g. one day), then you can keep the merges very small and overseeable.
    Well, of course having a policy on branching and the like is reassuring to begin with...

    [shameless plug]
    Look at [url=http://nvie.com/posts/a-successful-git-branching-model/]this[/url] for an example.
    [/shameless plug]



  • @OzPeter said:

    @Lorne Kates said:
    Just because a tool doesn't adequately do the job its supposed to, teaches bad practices, is universally derided, often destroys that which it was meant to construct, and has been publicly denounced and abandoned by its creator doesn't mean that it'll stop being used.
    Ha! I know of (and have used and installed for customers) commercial products that use VSS as a back end!

    One of my recent gripes about VSS arose from my department splitting up our VSS database (our codebase was on the verge of exceeding the 4GB limit.) Now instead of one problem<!-- Read: Shitty source control -->, we have five - one for each of our projects. Additionally: Backing up select portions of a VSS database, then restoring them to another VSS database: Not fun (and probably more work than upgrading to TFS.)

    Also: WTF? <!--Also: Also: WTF?!?!-->



  • The problem (I'm the OP) isn't helped by the closed minded nature if the tech lead in question - he doesn't react well to input, constructive or otherwise...

    One of his most famous utterances was asking myself and a colleague what "protected" does in C#. That was a bit of a "wind your jaw back up" moment for me.



  • Ugh. As others have said, source control is one of those topics that never really gets taught anywhere, it just gets absorbed. Got to plug Alex's page on the topic: http://thedailywtf.com/Articles/Source-Control-Done-Right.aspx Since I found that to be really helpful.



  • @ubersoldat said:

    This is one of the topics which I was never taught in college, which struck me as a rather very bad thing. At least things are starting to improve since many people are getting early hands on with github being so popular.

    Using Git/Github to learn the basics of source control = ok.

    Using Git/Github as a template for what a good program looks like = incredifail.

    As long as they're doing the former and not the latter, maybe we can look forward to the practice of software development improving over the next 20 years instead of reverting back to 1975-style. But I'm not optimistic.



  • @ubersoldat said:

    At least things are starting to improve since many people are getting early hands on with github being so popular.

    By "popular" - do you mean widespread usage (possibly because of the Torvalds connection) or is it genuinely liked?

    @blakeyrat said:

    Using Git/Github as a template for what a good program looks like = incredifail.
     

    I'm guessing at least their processes work. What's utterly wrong with it, then? And what alternative could it learn from?

    Disclaimer: I've only ever used TortiseSVN client to talk to Subversion/Trac (and I still don't think I used it properly) so am curious as to experiences of good/bad CVS, including benefits of a distributed model versus central repo.

     



  • @Cassidy said:

    I'm guessing at least their processes work.

    It's not bad source control (i.e. it seems to do what it claims to do quickly and reliably), it's bad software.

    It's unusably complex. The UI is completely arcane and practically unlearnable. The error messages that aren't incredibly vague are not only useless, they're anti-useful (they'll lead you in the exact opposite direction from solving the problem). It assumes knowledge of terminology that the user won't have unless they actually sit down and spend hours doing nothing but reading about Git. (There's no learning curve; it's a learning cliff you have to scale before you can even touch it.)

    The Github GUI (for Windows; I can't speak for other platforms) is merely a poor wrapper around the CLI client, meaning all of those above problems propagate to the GUI along with all of the GUI's own issues. (For example, it can't resolve conflicts-- yet somehow it has a version number greater than one? BTW: Microsoft's VS2013 plugin to do Git is far below version 1.0 and already handles conflicts.) The Github website has tons of issues too. You can embed images in bug tracker issues but not any other type of file-- want to store that .css file in a handy location? Too bad you use Github. All of the site and tools around it assume you're doing public open source software development, which is why it (for example) nags the fuck out of you to add a name and email address to your check-ins even though nobody outside your company will ever see them (and it's too fucking stupid to use the Github username/email and fill it in automatically.)

    Now I do have a philosophical beef with Git's design, I think it's a terrible idea to record conflicts *in* the actual conflicting file-- making the file unparseable until the conflict is resolved. I also think it badly needs a mode where you can, for a particular repository, force it to work online (work offline is a great FEATURE, but it shouldn't be the default). But that's relatively minor, and if a decent GUI were available it'd be a non-issue because (since the GUI wouldn't be beholden to the quirks of the CLI client) it wouldn't have to work the same way.

    All told, if Git/Github is the teaching the next generation of programmers, we're in for some shitty-ass programs.



  • @Cassidy said:

    @ubersoldat said:
    This is one of the topics which I was never taught in college, which struck me as a rather very bad thing.
     

    Ditto, but I think my college days preceeded code versioning systems.

    I've since been shown how to branch (but not told why and when I should do so) and how to lock for checkout plus unlock when committing... but not how to merge.

    Then again, I'm the only user of the CVS I currently use, so that's less of an issue.

    I was not taught anything in college about version control, bug tracking, or any other CM related area.  Luckily for me my first program was a rather mature program that taught me all these things.  This university also had database classes as optional and not required for a CS degree.



  • The lack of branching knowledge is a common wtf everywhere. I suspect no one knows how to branch correctly. Even I don't think I'm doing it right.

    I recently pushed a "branching process" to my team. The process consists of working from a development branch and then merging it with head/trunk before release. I am relatively new to branching, so I hoped the much more senior devs on my team could share their wisdom. I assumed the reason no one was branching before was not due to lack of knowledge, but due to laziness or other behavioral reasons. It turns out no one even knew what branching was.

    I insisted on the branching process in hopes everyone would learn how to branch properly. No one cared to learn, but instead blamed the process whenever a merging issue occurred. Now, I'm considering reverting my source control back to having no branches, since it seems to cause more headache than productivity for my team.

    I was once told, "Enable smart people to do good work, and they will figure out the implementation details themselves." Either the statement is wrong, or my assumptions about my team are wrong.



  • @blakeyrat said:

    All told, if Git/Github is the teaching the next generation of programmers, we're in for some shitty-ass programs.
     

    okay.. well... that's kinda frightened me off the idea of trying it - at least until the UI improves, since it'll probably be frustrating to a noob. I'll stick to this SVN thing I'm (currently) familar with for the time being.

    But prewarned and all that, thanks.

     



  • I was in uni ~4 years ago. At my Uni, second year, first group project, the first thing we were taught was source control, via TortoiseSVN.

    The next year the Uni introduced Git to us (CLI, not GUI), but I (same with most of the class) didn't bother. We had a perfect grasp of how to check out/check in and deal with conflicts. Throwing a CLI into things just served to complicate the experience for no extra gain at the time. Obviously the Linux devouts switched over to GIT, but the rest just stayed with Tortoise.

    Maybe times are changin' (Concerning the education of Source Control programs. Not trying to say Tortoise is better then GIT, just easier to learn).



  • @Lorne Kates said:

    @DaveK said:

    @MiffTheFox said:

    Wow locking checkouts? TRWTF.

    Even SourceSafe uses the "merge on conflict" idea.

    Not by default it doesn't, apparently.  Still at least the steaming great heap of shit has finally been EOL'd.  Good riddance!

     

    Just because a tool doesn't adequately do the job its supposed to, teaches bad practices, is universally derided, often destroys that which it was meant to construct, and has been publicly denounced and abandoned by its creator doesn't mean that it'll stop being used.

    No, but just because it's not on sale any more does mean that the number of sites using it will now start to decay like a heap of radioactive waste.

    Of course, the half-life might turn out to be millions of years... 



  • @blakeyrat said:

    Now I do have a philosophical beef with Git's design, I think it's a terrible idea to record conflicts in the actual conflicting file-- making the file unparseable until the conflict is resolved.

    Do you have a preferred method of dealing with this sort of thing that exists somewhere, or is this just raging against reality? I honestly can't see why one wouldn't want this to be right there in the file, so I'm interested if there's some "better way" that might make me change my mind.

    @blakeyrat said:

    All of the site and tools around it assume you're doing public open source software development, which is why it (for example) nags the fuck out of you to add a name and email address to your check-ins even though nobody outside your company will ever see them (and it's too fucking stupid to use the Github username/email and fill it in automatically.)

    I must say, putting proprietary stuff like this out on a site like github gives me the willies, but it seems like your company is all about outsourcing various bits and pieces of IT.



  • Whoa I almost started replying to Boomzilla-- got like two sentences in before I caught myself.

    Thank God.



  •  @boomzilla said:

    I honestly can't see why one wouldn't want this to be right there in
    the file, so I'm interested if there's some "better way" that might make
    me change my mind.

    I don't see a 'better' way but but a reason why you may not want it is: from personal experience I know it scares the noob I was back then. Thinking "why isn't my code working anymore" and then "WTF I did not put that in there" (being the only person using the repository on my machine; trying to merge it to the main one at the server). Took me some time figuring out what happend and how to resolve conflicts.



  • @Cassidy said:

    okay.. well... that's kinda frightened me off the idea of trying it - at least until the UI improves

    If you've already figured out that working directly with a centralised source tree is horrible compared to working with your own local source tree(s) and committing successful changes to a central VCS repo, you should have no particular trouble with the idea of inserting another layer - your own local VCS repo - between your source trees and the team repo. That's essentially all a DVCS is. What it gives you is everything you could already do with SVN, but on your own workstation's drive so it's fast and so nothing you do to it can screw things up for the rest of your team, plus the ability to collaborate by sharing stuff across repos. You can run your distributed repos as a star, where everybody pushes revisions back to a central team repo, or a mesh where everybody just pulls stuff from each other willy-nilly, or anything in between. Do whatever suits your team.

    What you really can't do, though, is ignore the existence of your local repo and treat a DVCS as if it were a 100% no-brainer drop-in replacement for your old centralised VCS; the workflow does have extra steps and you do need to understand the relationships between the various parts. Checkout is not the same as pull, and checkin is not the same as push. You do need to formulate policy for where your releases come from and who is in charge of what. But none of that should be beyond the wit of anybody capable of writing a computer program, and the speed and robustness benefits are real and worthwhile.

    Blakey got badly surprised at some point by seeing merge conflict markers pop up inside some of his source files, rendering them non-compilable. I'm still not sure he fully understands that (a) untouched, pre-merge versions of all the files in question should still be available in his local git repo and (b) files containing unexamined merge conflicts should fail compilation.

    Also bear in mind that Blakey has some language processing issues that profoundly affect his experience of and attitude toward command line interfaces in general. If you don't share those, I would expect you to find git no more frustrating than any other CLI tool. Certainly couldn't hurt to sit down with the book and have a play.



  • @boomzilla said:

    @blakeyrat said:
    Now I do have a philosophical beef with Git's design, I think it's a terrible idea to record conflicts in the actual conflicting file-- making the file unparseable until the conflict is resolved.

    Do you have a preferred method of dealing with this sort of thing that exists somewhere, or is this just raging against reality?

     

    Can't find it to hand at the moment, but there was a Blakeyrant some time back about corrupting his source code with the conflict report (rather than having it segregated as a popup or written out to a separate file elsewhere) which then caused defenders to jump in with "ur doin it rong" including examples of how theirs worked - I didn;t pay it a great deal of attention since I didn't have (and still don't) a good working knowledge of CVS so couldn't contribute much.

    (but the thread did take a predictable turn)


  • Discourse touched me in a no-no place

    @Cassidy said:

    Can't find it to hand at the moment, but there was a Blakeyrant some time back about corrupting his source code with the conflict report (rather than having it segregated as a popup or written out to a separate file elsewhere) which then caused defenders to jump in with "ur doin it rong"
    The GitHub one?



  • @Adanine said:

    Throwing a CLI into things just served to complicate the experience for no extra gain at the time. Obviously the Linux devouts switched over to GIT, but the rest just stayed with Tortoise.
     

    The CLI just means it's possible to alias the command(s) or easily automate updates and the like.

    I'd have liked there to have been some scripting front-end to TortoiseSVN client to provide an alternative to pointy-clicky.

    Just different routes to the same outcome.



  • @flabdablet said:

    That's essentially all a DVCS is. What it gives you is everything you could already do with SVN, but on your own workstation's drive so it's fast
     

    Oh, okay. Makes sense, ta.@flabdablet said:

    I would expect you to find git no more frustrating than any other CLI tool. Certainly couldn't hurt to sit down with the book and have a play.

    Hmm.. okay, given I'm a *nix geek and feel more comfortable in the CLI I may dabble just to compare. Ta for the link.

    However, I think I need to read up on CVS in general before plumping towards how particular software does it.

     



  • My main gripe about Git is that it's too easy for a branch (same project, you can merge them) to become a fork (different project, git doesn't know what to do). All it takes is missing one git pull before git commit....



  • @Cassidy said:

    @boomzilla said:
    @blakeyrat said:
    Now I do have a philosophical beef with Git's design, I think it's a terrible idea to record conflicts in the actual conflicting file-- making the file unparseable until the conflict is resolved.

    Do you have a preferred method of dealing with this sort of thing that exists somewhere, or is this just raging against reality?

    Can't find it to hand at the moment, but there was a Blakeyrant some time back about corrupting his source code with the conflict report (rather than having it segregated as a popup or written out to a separate file elsewhere) which then caused defenders to jump in with "ur doin it rong" including examples of how theirs worked - I didn;t pay it a great deal of attention since I didn't have (and still don't) a good working knowledge of CVS so couldn't contribute much.

    Yes. Of course, he'll use his predictable method of preventing embarrassment when he's been called out and doesn't have an answer. I mean, I get that he's surprised or whatever, and he says that some other tool (TFS?) handles conflicts better, but it's apparently too much to tell us what that means. Of course, he's also ignorant enough to not understand that this is the standard way of handling these things. It's sad that he's not mature enough to discuss the tradeoffs of whatever method he thinks is better, but that's blakeyrat for you.



  • @Cassidy said:

    I think I need to read up on CVS in general before plumping towards how particular software does it.

    I see where you're coming from; there is a natural tendency to imprint, duckling-like, on the first tool we learn and then act as if everything even vaguely like it is just some broken variant of it. But DVCS arose as a response to frustration with the limitations imposed by centralised VCS, and is objectively better than a central VCS in almost any scenario, so if you have no existing attachment to an existing VCS you might as well make a DVCS the first kind you get serious about using.

    If git feels like overkill for your team, or if your personal preference is monoliths rather than building blocks, you might want to look at fossil. Here's a third-party comparison.



  • @PJH said:

    The GitHub one?
     

    Erm.. yeah.. that kinda looks like the fellah. May re-read it now in light of newer info.

    @boomzilla said:

    It's sad that he's not mature enough to
    discuss the tradeoffs of whatever method he thinks is better, but that's
    blakeyrat for you.

    Well, he voiced his opinion on GitHub - I was hoping to collect opinions from others also. I know I can fire up joogle but I thought hearing experiences direct from devs would be more enlightening.

     



  • @Cassidy said:

    @boomzilla said:
    It's sad that he's not mature enough to
    discuss the tradeoffs of whatever method he thinks is better, but that's
    blakeyrat for you.

    Well, he voiced his opinion on GitHub - I was hoping to collect opinions from others also. I know I can fire up joogle but I thought hearing experiences direct from devs would be more enlightening.

    I understand his issues with github, though I've never used it (or git) for anything more than cloning a repo to get the source for something.

    His complaint about how to handle conflicts reminds me of some of his criticisms of things like bash, and how people aren't very interested in finding better ways and getting rid of the worse old ways. I think there's some merit there (not as much as he does, obviously). Several people (including me) have brought up positive reasons about why you'd want to have conflict information right there in the files. I haven't really heard anything from blakeyrat about why this isn't a good idea, except that he didn't expect it, or something roughly equivalent to that. He certainly hasn't addressed the positives.

    For completeness (at least as far as I can get off the top of my head): Getting a compile error forces you to resolve the issue before continuing (fail fast!). Having the information right there in the files is more flexible, since you can use different tools, including a simple text editor, to resolve conflicts.



  • @boomzilla said:

    For completeness (at least as far as I can get off the top of my head): Getting a compile error forces you to resolve the issue before continuing (fail fast!)
    Agreed - although I thought Blakey objected to the error message populating his source.

    You a git, then?



  • @Cassidy said:

    @boomzilla said:
    For completeness (at least as far as I can get off the top of my head): Getting a compile error forces you to resolve the issue before continuing (fail fast!)
    Agreed - although I thought Blakey objected to the error message populating his source.

    Yes, but...why?! Consider what's happening. You have two changesets that say some lines should be changed to two different things. What should it show? What are the workflow implications? I mean, no one likes conflicts, but you have to deal with them somehow when they arise. My guess is that blakey wants to get some sort of a GUI merge tool pop up that forces him to resolve all of the conflicts before the merge is finalized and the new files updated in his working copy. That sounds horrible to me, but it's just a strawman, since he won't say what he actually wants.

    @Cassidy said:

    You a git, then?

    I use Mercurial when it's up to me (it could probably be reasonably described as git-lite). I'm occasionally compelled to use Subversion these days. Is there a VCS that doesn't leave some sort of conflict information when you get a conflict in a merge? I guess TFS doesn't (based on previous blakeyrantings). Maybe some other proprietary systems? What do they do in case of conflicts?



  • I once worked at a company in early 2007 that was entirely SourceSafe and Classic ASP.  They pointed out on the first day that they HAD to use locking checkouts because they had so many files they could not risk two people working on the same file, for fear of it breaking something. 



  • @OhNoDevelopment said:

    I recently pushed a "branching process" to my team. The process consists of working from a development branch and then merging it with head/trunk before release. I am relatively new to branching, so I hoped the much more senior devs on my team could share their wisdom. I assumed the reason no one was branching before was not due to lack of knowledge, but due to laziness or other behavioral reasons. It turns out no one even knew what branching was.

    I insisted on the branching process in hopes everyone would learn how to branch properly. No one cared to learn, but instead blamed the process whenever a merging issue occurred. Now, I'm considering reverting my source control back to having no branches, since it seems to cause more headache than productivity for my team.

    I'm going through something similar right now. As an added bonus, I'm trying to teach ~50 offshore devs that I'm forbidden to speak to directly.



  • @flabdablet said:

    I'm still not sure he fully understands that (a) untouched, pre-merge versions of all the files in question should still be available in his local git repo

    I understand that, the problem was that the GUI for Git is so fucking awful that the only way to get at them is to literally copy your (scm mangled) file elsewhere on the disk, then do a sync to pull in the untouched files, then compare the two manually. Maybe there's some sort of handy diff tool in the CLI bullshit (although I don't see how its even POSSIBLE to write a handy diff tool without a GUI, but I'll give the benefit of the doubt) but Git hasn't fucking bothered making that work yet. Because it's terrible software.

    @flabdablet said:

    and (b) files containing unexamined merge conflicts should fail compilation.

    I disagree. Don't state opinions as if they are fact.

    Look the merge conflicts aren't something that's IN the file, conceptually. The merge conflicts are places where my file differs from another file-- my file is still a 100% intact working code file, and so is the other one. A scm tool that shits all over my 100% intact working code file only to show me where merge conflicts are is fucking stupid. My code shouldn't stop working just because I attempted to merge it. The act of "attempted merge" should not edit the files-- why should it? Have you ever even heard of the "principle of least surprise?" It's doubly stupid because I might need to actually run (or at least build) the code to determine what the correct resolution to a conflict is, and in Git-world that option is lost to me.

    What should happen is during the merge process I should get a handy-dandy diff window with one file on one side and another file on the other side, and it should let me resolve my conflicts quickly and efficiently-- you know, like how ALMOST ALL SCM TOOLS ALREADY FUCKING WORKED BEFORE GIT CAME ALONG AND SERVED US UP DIARRHEA WHILE TELLING US IT WAS GOLD.

    @flabdablet said:

    Also bear in mind that Blakey has some language processing issues that profoundly affect his experience of and attitude toward command line interfaces in general.

    I don't know how you can sit down and say, "oh BTW Git didn't bother making their tool usable for people with any kind of disability no matter how minor" without being FUCKING OUTRAGED AT HOW HORRIBLE THAT FUCKING IS. "Oh you're missing a hand? Can't use my program!" "Oh you speak French? Fuck you go away!" "Oh you're colorblind? Sorry fuck you." No. NO. NOOOO. NOT ACCEPTABLE. And a big part of why I say Git is terrible software. Because it is.



  • @Cassidy said:

    @Adanine said:

    Throwing a CLI into things just served to complicate the experience for no extra gain at the time. Obviously the Linux devouts switched over to GIT, but the rest just stayed with Tortoise.
     

    The CLI just means it's possible to alias the command(s) or easily automate updates and the like.

    I'd have liked there to have been some scripting front-end to TortoiseSVN client to provide an alternative to pointy-clicky.

    Just different routes to the same outcome.

     

     

    So you want a "scripting front end" to a gui front end that sits on top of a command line based (scriptable) baseline....next you will want a GUI for your new front end, and then scripting for that gui...and then...

     


  • Discourse touched me in a no-no place

    @blakeyrat said:

    @flabdablet said:
    and (b) files containing unexamined merge conflicts should fail compilation.

    I disagree. Don't state opinions as if they are fact.

    Pot/kettle.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.