Git can be used to bridge to other VCS backends. In other words, I can run git locally and get it to sync up to an SVN server. On SVN, the convention is that trunk is the "main" branch, where on git, that's always been master. In both cases. there's no trivial way to "ask" what the "main" branch is -- GitHub's setting, for example, pertains to how others raise pull requests against your repo, not how git sees things.
This may sound silly (why bridge?), so I'll recount when I had to use git as a bridge:
I was doing work for a client who used TFS as their VCS. And not the "git-backed" TFS you may have heard of these days -- the older engine, which, like SVN, requires you to be able to connect to the server to commit. Which I couldn't always do. So in that case, I have two options: accumulate changes into one massive commit when I can finally connect and have (a) terrible history and (b) make it much harder to move incrementally forward (and, by extension, incrementally back, eg when experimenting on a new feature).
So, in this case, I would use the git-tfs bridge to run git locally (so I can use all of the distributed features and have small commits), and push to the TFS remote when I was able to connect (eg when I was on-site).
When tools which facilitate this kind of behavior break, that's bad for a lot of people involved.
Add to the conversation the fact that the author responsible for naming master as such has said that he intended it in the sense of master copy (as I've been suggesting the intent appeared to be from the source) and we have a massive movement to rename something which will take time and effort, has knock-on effects and doesn't even address what it sets out to, let alone the really big problems that are out there.
I still maintain: let's change the name if it makes a lot of people unhappy, but let's be honest about its origins and the fact that it's non-trivial to do so and will break systems which rely on established conventions.
Interesting. Thanks for telling me this. I've known a few people who've had to use both git and plastic (I have zero experience with plastic) for their work. Where git is either going to github/bitbucket or staying on their machine and plastic going to the server. It was a bit convoluted on their part but they had to for their sanity or policy (mostly for sanity).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I assume you're referring to the tools?
If so, here's some more info:
Git can be used to bridge to other VCS backends. In other words, I can run git locally and get it to sync up to an SVN server. On SVN, the convention is that
trunkis the "main" branch, where on git, that's always beenmaster. In both cases. there's no trivial way to "ask" what the "main" branch is -- GitHub's setting, for example, pertains to how others raise pull requests against your repo, not how git sees things.This may sound silly (why bridge?), so I'll recount when I had to use git as a bridge:
I was doing work for a client who used TFS as their VCS. And not the "git-backed" TFS you may have heard of these days -- the older engine, which, like SVN, requires you to be able to connect to the server to commit. Which I couldn't always do. So in that case, I have two options: accumulate changes into one massive commit when I can finally connect and have (a) terrible history and (b) make it much harder to move incrementally forward (and, by extension, incrementally back, eg when experimenting on a new feature).
So, in this case, I would use the git-tfs bridge to run git locally (so I can use all of the distributed features and have small commits), and push to the TFS remote when I was able to connect (eg when I was on-site).
When tools which facilitate this kind of behavior break, that's bad for a lot of people involved.
Add to the conversation the fact that the author responsible for naming
masteras such has said that he intended it in the sense ofmaster copy(as I've been suggesting the intent appeared to be from the source) and we have a massive movement to rename something which will take time and effort, has knock-on effects and doesn't even address what it sets out to, let alone the really big problems that are out there.I still maintain: let's change the name if it makes a lot of people unhappy, but let's be honest about its origins and the fact that it's non-trivial to do so and will break systems which rely on established conventions.
Interesting. Thanks for telling me this. I've known a few people who've had to use both git and plastic (I have zero experience with plastic) for their work. Where git is either going to github/bitbucket or staying on their machine and plastic going to the server. It was a bit convoluted on their part but they had to for their sanity or policy (mostly for sanity).