In which Mott555 gets confused by Github
-
And we have some repos with a very WTF structure...tags within trunk within branches within other projects in the same repo within tags done by people who don't quite think like software devs....
Tags are not a problem, because they are not something you are trying to do something with. But if you mess up branches, and then need to merge them, Subversion will pretty much loose track of what's going on.
-
@Linus Torvalds said:
Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started[…]
Linus clearly never worked with the Rational® ClearCase®. Subversion got at least one thing right: that a commit saves the whole project in one atomic operation. ClearCrap went in the other direction, adding features to the per-file versioning concept, until it ended up with ungodly mess that is slow as molasses and fails at any reasonable reproducibility.
-
You are saying most tutorials start the wrong way, but what about "git concepts simplified"?
-
That looks pretty good if it was a presentation with narrative. The slides alone seem somewhat terse though. And the slide 20 shows a merge that would in practice be fast forward (second parent is accessible via first parent already), which I think should have been introduced; I consider symmetry an important property of merges.
Edit: it does introduce multiple refs to a revision later when talking about remotes. But I still think it's a bit terse to be understood without the talk part.
-
The worst thing about Java is still the vast amount of incompetent developers who think they can use that language.
Haskell doesn't have that problem. Incompetent developers (and really developers in general) don't think they can use it.
-
Don't make me get out my parentheses again!
-
Anything that makes commits to your local git repo -including yourself- can set the attribution of a commit to whatever it wants.
Yet another example of why us corporate-types aren't DVCS fans. I don't care that it's more convenient to use on an airplane, or in some backwater city with horrible Internet connectivity. I'm much more concerned that I only allow the right people to perform the right tasks and that my audit trail is meaningful.
-
You can always enforce that people can only push commits attributed to them to the central server, or you can record who pushed which commits to the server. Which is basically the same thing you can do with the centralized systems, because the users can still commit changes actually made by somebody else in them.
-
You can always enforce
Is that a thing already built into git, or is this a thing I have to hack together in shell scripts and pray it works?
-
It is not built into git itself, but it is implemented in some server management software built on top of it like gitolite (you need to define the exact checks you want to do, but I believe this one is listed in examples).
-
is this a thing I have to hack together in shell scripts and pray it works
POST_NOT_EMPTY
-
Due to a change in employment I've had to start using SVN again after 5 years of previously using Git.
It's like replacing your star employee with a slow, forgetful, error prone version of the former one. It can't even handle basic branching strategies properly.
Seriously, take the time to learn Git properly, and you won't look back.
I miss Git.
-
Why do I keep hearing that SVN can't do branches? We do branches all the time and seldom have issues.
It's like Git users have to make crap up to defend Git against SVN.
-
We hired a die-hard git guy at my last job, where we used SVN. He had this laundry list of things that git could do but SVN couldn't. We were doing everything on his list of "SVN can't do this". He finally settled on "git does merging better" as the gun that he would stick to. We never got more detail or an example from him.
To be fair, SVN is not good at renames and tree conflicts. However, I've had that come up like four times in the past ten years.
-
To be fair, SVN is not good at renames and tree conflicts. However, I've had that come up like four times in the past ten years.
Same. It happens, but it's too rare to justify switching to something that might do it better.
-
99% of the time spent swearing at revision control systems is done because a file maintained by a tool (for example, a project file) gets mangled during a merge. No version control system handles this any better or worse than any other.
-
Why do I keep hearing that SVN can't do branches?
This. Just today I was told "SVN doesn't have branches. It has sort of a hacked-together workaround version of branches, but not real branches."
Here's an idea: let's redefine source control as distributed source control. Now SVN doesn't even have source control! Lol newbs.
-
Why do I keep hearing that SVN can't do branches? We do branches all the time and seldom have issues.
Svn finally can do basic cases of branches. It took awfully long. It only started to do any merge tracking in version 1.5 after almost 10 years of development or something like that. Then in 1.6 and (IIRC) 1.7 it still needed the
--reintegrateoption to tell it on which branch to look for the most recent common ancestor, because it couldn't decide whether to look for the most recent common ancestor on the source or target branch. It can decide now, but it still does not look on any other branch than the source and target. That is if you create two feature branches and want to merge them together without integrating back to the master, you are still down to manual handling. Git can handle this just fine and can even handle “criss-cross” where there are multiple most recent ancestors.And then there is all the confusion about project roots. Branches are just directories in Subversion and there is nothing that would distinguish subdirectories that are branches from subdirectories within the project, so it is possible to merge just a subtree. Which looks nice until makes utter mess of your history.
Subversion does have one feature that git does not too, though. It tracks cherry-picks and has a special strategy for merging from branch from which cherry-picks were already done. Git relies on the same change on both sides being simply that change, but when it is covered with later modifications, it leads to unnecessary conflicts that can be avoided by the better Subversion strategy (the strategy could be implemented for Git as well, using detection similarly to what Git does for renames, but so far nobody did).
-
It's like Git users have to make crap up to defend Git against SVN.
I'm not a git user and I loathe svn branching. Granted, we're on an older version. I've heard it's improved a bit.
-
We're on an older version too, 1.6 I think. It only causes problems when someone tries to do stuff with a 1.7 or 1.8 client, if the versions don't match half the features don't work.
-
Here's an idea: let's redefine source control as distributed source control. Now SVN doesn't even have source control! Lol newbs.
Actually, it still does. Or at least, can be used as base for it¹ as SVK demonstrated. Development ceased as the people involved now consider the distributed systems to be better than the kludge that SVK always was, but SVK was quite reliable and did decent job of branches back in 2005 when Subversion did not yet have a clue and Git was just a proof of concept.
I'm not a git user and I loathe svn branching. Granted, we're on an older version. I've heard it's improved a bit.
It fixed the need for
--reintegratesomewhere in 1.8 or so, but otherwise I'm not so sure. I learned to avoid the cases where it had trouble when I was handling most merging in our team until I managed to switch us to Git about a year ago.
¹ Pedantically, SVK was according to definition of “distributed system” I learnt SVK was not one, but was merely a “decentralized system”. That definition requires that in a distributed system objects have identity independent of the node they are currently located on, which is true of the real DVCS, but in SVK the revision had different revision number in each repository and there were just some properties linking them together.
-
Eh...basically, it means that merging is a manual thing. I can't just merge stuff around like I could with hg and let it figure out what needs to be merged and just do it. I have to figure out which revisions need to go and specify manually.
It fixed the need for --reintegrate somewhere in 1.8 or so, but otherwise I'm not so sure.
I just checked. I use a 1.8.8 client and the server is 1.6.11.
-
I just checked. I use a 1.8.8 client and the server is 1.6.11.
That's probably your problem. Here, we always have to tell new guys to get a 1.6 client and then things work. Ideally we'd update the server to 1.8 but those in charge don't want to.
-
That's probably your problem.
The problem isn't my later client. It's the server. It's just completely incompetent in terms of dealing with merges without me holding its hand the whole way.
-
That's what I thought, until I finally downgraded my client to 1.6 and now I can magically do branches and merges. The protocol must have changed post 1.6 and they didn't bother with back-compatibility.
-
That's probably your problem. Here, we always have to tell new guys to get a 1.6 client and then things work.
The problem isn't my later client. It's the server. It's just completely incompetent in terms of dealing with merges without me holding its hand the whole way.
I don't believe this. Merging is implemented completely in the client. The server only stores the metadata using generic property mechanism. So as long as everybody uses 1.8 client, leaving the server at 1.6 should not be a big problem. Having a mix of client versions, however, might be a problem.
And of course if the merge metadata are incomplete or broken from previous merges done in the older client, the new client won't be able to do much about it. All it can do is write the metadata for new branches correctly.
AFAIR we didn't upgrade our server either, we just updated our clients mostly in sync. And didn't seem to have much problems with that.
-
Well, I just merge stuff as soon as I put it in one branch (assuming it needs merging), so it's not a huge issue so long as I stay on top of stuff. And I wrote a program to compare branches so we can make sure we did the needful merges.
-
I've never seen an SVN repository get messed up.
I have.
Over the four or so years that I worked in a Windows-only shop, it felt like every month or so (but was probably every three or six months) our sysadmin had to do something or other to rescue an SVN repo that would refuse commits, or refuse to create a branch, or whatever. "Sounds like flaky hardware.", I know, except that it wasn't. The server kit and associated networking gear was solid.
Now, it was about every other month that someone's SVN working copy would get into an irrecoverable state and need to be blown away. With several multi-gigabyte repos, this meant an extended, unexpected coffee break. Everyone in that division was far more familiar with the use of the diff and patch tools than you would ever expect a group of SVN-using Windows developers to be.
-
I'm much more concerned that I only allow the right people to perform the right tasks and that my audit trail is meaningful.
Then use gitolite or something similar as a central repository. It authenticates using SSH keys and lets you assign read/write/create privs to each repo based on the key presented.
But, frankly, if you don't trust your goddamn programmers, then you've seriously hired the wrong people. :)
-
@Linus Torvalds said:
>Being distributed very much means that you do not have one central location that keeps track of your data.
Which is probably why every single place that uses Git has a centralized server that keeps track of your data.
Or GitHub, a.k.a. a centralized server that keeps track of everyone's data.
-
[I was told] ... SVN doesn't have branches.
Whoever told you this is clearly a wanker, and should maybe be fired.
Git's merge handling is magical when compared to SVN's. Change something in a file in master, but that file has moved around in dev? That'll merge no problem. Rename a file, but wanna merge? Again, no problem.
When last I checked (It's been a while... SVN ~1.7.x, right around the time of the goddamn SQLite WC rewrite), to get something approaching 10% of the power of git's merging required a ton of roundtrips to and grinding of the SVN server to reconcile all of the mergeinfo metadata.
Unless the SVN folks have done a lot of work in this area (and they very well may have!), git kicks the shit out of SVN when it comes time to do a complicated merge.
-
Which is probably why every single place that uses Git has a centralized server that keeps track of your data.
Nah. That's a convenient common source for that data. Everyone who has checked out a copy of that repo is also now a source of that data.
If Github dies today, the only things lost are a bunch of now-broken links and Github Issues. If -say- SourceForge decides to take their SVN servers offline, the two people who still have active projects there will lose all of their history.
Apples and oranges, man.
-
Change something in a file in master, but that file has moved around in dev? That'll merge no problem. Rename a file, but wanna merge? Again, no problem.
How often does that actually happen? I can't remember a single case where I moved a source code file but wanted it to be considered the same file. Renames happen, but usually early in the development cycle and not very often.
I see this as in the same category as: "I like to make a ton of changes and then go back and commit them in tiny batches with appropriate commit messages". Sure git allows this, but I have never in my life wanted to do it.
-
But it had better be before you leave for the day, or else you're an idiot...
If I promise to
- Be the only one working on my branch
- Religiously rebase my branch twice daily against dev and report any real issues immediately
- Rsync my local git repos to backed-up storage
may I please work in my cozy dev cave until my work is ready for public consumption, Buildmistress?
-
If Github dies today, the only things lost are a bunch of now-broken links and Github Issues.
Also a place to which everybody agreed to push their data.
Yep, you do have a local copy of the repo, but the overall Git workflow is still centralized for everyone who's not Linus Torvalds.
-
But it had better be before you leave for the day, or else you're an idiot who misunderstands the fundamental concepts of git.
I'm trying to understand what you're saying here. The best I can come up with is making fun of one of:
- @blakeyrat when he confuses git with backups
- the people who make fun of him for confusing git for backup software
-
may I please work in my cozy dev cave until my work is ready for public consumption
No. The only way that works is if your work is so isolated that no one else cares. In my projects, people's stuff interacts with each other. If don't merge until "you're done", then we can't start assessing the impact of you work until we are uncomfortably close to the finish line.
-
That's what rebase twice a day means......
-
the overall Git workflow is still centralized for everyone who's not Linus Torvalds.
Fuck me! I guess the ID cards of me and my friends have been misprinted. I must alert the authorities immediately!
Here's the use case to consider.
Say you have your multi-gigabyte, hundred-thousand-commit SVN repos hosted with a third party that doesn't grant you shell access, but does provide you with a web page to create new repos and do user management for each one.
You want to move your repos to a new third party. What do you have to do, and how much time does it take to do it?
With git, it's trivial, as everyone has a copy of the repo already.
With SVN, not so much. Not at all, in fact. You pretty much have to either have shell access of some kind to do a dump of the repo in order to move it, or have had the forethought to set up a postcommit hook to email the commit details to you. (But I'm not sure how well email backup would preserve SVN metadata.) It's been a very long time since I've had to think about any of that shit.
-
The only way that works is if your work is so isolated that no one else cares.
Just as @sloosecannon said, when I say "rebase twice a day", that means when I roll in to work in the $MORNING, I merge in the latest changes from the dev branch into my own, resolve any merge conflicts, run the test suite, then keep working. Then in the $EVENING, I do the same thing.
It works really well, actually; the process doesn't need much modification for the case where you have multiple devs working on a single branch.
If it makes you feel better, you can think of it as working on a feature branch that's destined for eventual merge into the dev branch.
-
You want to move your repos to a new third party.
Is that in your usual workflow? Man your workplace sucks.
The point is, in Torvald's utopia, there's no third party, and people throw patches around to each other. That's the point he's making, and that's the insane thing. For normal people like me well, for the purposes of this discussion, working with Git is working with a centralized server, except you have a local repository and sync that instead of syncing the code directly.
Which is nice, but as we've argued a while ago, doesn't really make it decentralized.
-
Is that in your usual workflow? Man your workplace sucks.
Nope.
The fact that you can move a git repo from one host to another without doing much more than a "git init" on the remote host and a "git push" on the local host is what makes git decentralized, regardless of how "most" people use it.
For example, just because almost noone makes use X11's -or OpenGL's- network transparency, doesn't mean that they're not network-transparent protocols.
-
Just as @sloosecannon said, when I say "rebase twice a day", that means when I roll in to work in the $MORNING, I merge in the latest changes from the dev branch into my own, resolve any merge conflicts, run the test suite, then keep working. Then in the $EVENING, I do the same thing.
I see where you pull everyone else's changes, but not where you push yours. If everyone does the same thing you do, no changes will ever be in the dev branch to merge.
In every group, there's always one guy who goes into his cave for a month at a time and sucks up everyone else's code, while never committing anything. Then, three minutes before the end of the development phase, he commits ten thousands lines of code. That guy is a huge pain in the ass to work with. This antipattern can exist with any source control technology (or even with no source control at all).
-
Rewriting history (via "git rebase --interactive") is super useful if you're like me and you make a billion little "checkpoint" commits throughout the day
And, of course, other than the reason why he's doing it, this is exactly Blakey's use case.
-
How often does that actually happen?
This particular case? Not often.
Look. I went from using SVN for four years, to using git for two. I knew nothing about git going in, but -after I learned the basics and played around with it for a week or so- I found that I no longer had to refrain from making the otherwise-perfectly-reasonable changes I would avoid because I knew that SVN would choke on them, and leave me with a mess to manually clean up (at best), or roll back and start over (at worst).
I can't give specific examples, as this shit has been lost to the winds of time (and drink). Just know that I'm not a software zealot, and that git made software development with a VCS as close to a hassle-free experience as I think is possible.
-
That page reads like Star Trek technobabble to me...it's just words strung together...
You, ah, did see the red bar at the page top, right? You've actually described what that page actually is.
-
Still, what does that say about Git that fake documentation was indistinguishable from real documentation to a newbie?
It says that writing software to be the antithesis of something else is a bad idea.
Clean living is it's own reward, or something.
-
For example, just because almost noone makes use X11's -or OpenGL's- network transparency, doesn't mean that they're not network-transparent protocols.
We actually find X11 network transparency kinda handy around here, although it is a bandwidth pig compared to VNC. Once we don't have to fight with the VPN pipe any longer, though...
-
In every group, there's always one guy who goes into his cave for a month at a time and sucks up everyone else's code, while never committing anything.
Holy Christ, dude. I hate that guy, too. I pull the drive out of his PC to get his code.
All I'm looking for is to not be forced to commit WIP code that breaks the test suite. Some features take more than eight hours to build, you know? Some features take more than a week, too. It's nice to not worry about scrutiny when you've a long, difficult heads-down project ahead of you.
-
That mindset is so alien to me...SVN is easy to set up, easy to use, easy to configure, and most of the time Just Works. So Torvalds set out to do the exact opposite of that? And apparently succeeded.
$ mkdir git-repo ; cd git-repo ; git init . ; touch hello ; git add hello ; git commit -m "Hello world"
If you can read bash, then you can see that it's substantially easier to get your first git repo up and running with its first commit than to stand up an SVN server. (This is a red herring, I know, but it was a red herring in a barrel!)
When I think back to the time before I knew anything about SVN, I can honestly say that basic proficiency in git was no harder to achieve than basic proficiency with SVN.
I just used Github's tutorials, which are apparently inadequate and/or not quite correct.
Github's tutorials are actually quite adequate and correct.
I'm still standing by the assertion that the Spigot tutorial that you haven't acknowledged that you read changed your git Name and Email address. The git log from earlier in the conversation strongly suggests that this is what happened.
You can't blame a tool for attributing a commit to the Name and Email address that you had -at the time- told it to attribute the commit to. (Well, I mean you can, but then you're no better than blakeyrat, and he's a troll.)
