You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Everyone complaining about Microsoft buying GitHub needs to offer a better solution
- Thread starter JournalBot
- Start date
Cloudgazer
Ars Legatus Legionis
Never said I can't handle merging in Git. The issue I'm pointing to is that Git is very complicated, and most developers I know don't really know how to use it. (Which is why I'm usually the one fixing everyone else's Git errors. I do this because I have put the time in to learn it.) Maybe that makes them bad developers.Which was so horrible at merging? Git or Subversion? I hope you mean Git. Because in my experience, other developers don't merge using Git, because it's too confusing. Instead, they simply "resolve conflict using mine" ("mine" being the branch the developer was working on). These are often senior devs.You should be using Subversion anyway. And the only reason you're using Git is that using Subversion in 2018 is so uncool.
It certainly doesn't help that it was so horrible at merging for so long, but even today there are technical reasons for some users to prefer Git - and I say that as somebody who prefers a centralized approach to distributed.
No - I mean subversion. Up until what, 1.5 it didn't remember previous merges, so when you merged from the trunk onto your development branch you had to specify exactly which versions you were merging, if somebody didn't record which version had been used you were completely up the creek.
Even today I understand it can only determine common ancestor if that common ancestor lies on one of the two branches being merged. If you can't imagine a case where that wouldn't be the case then you've spent too long working with subversion.
If your devs can't handle merges in git then they're bad developers. If you can't handle merging in git then you're a bad developer. Sucks to be you either way.
But the complication in Git isn't in merging is it? What makes Git complicated is the distributed stuff and that's a completely different bit. So if your developers can't figure out how to handle a conflicted merge in Git then lord help them if they hit a conflicted merge in subversion. And they'd be fucked to a fare thee well if they were forced to use subversion 1.4 (as I was last year), on any kind of long running project.
Horrible really doesn't do it justice.
Upvote
-1
(1
/
-2)
Merging and rebasing are probably the most difficult things that a dev deals with regularly. There are other more difficult things, but they're pretty rare by comparison.
Upvote
2
(2
/
0)
Merging and rebasing are probably the most difficult things that a dev deals with regularly. There are other more difficult things, but they're pretty rare by comparison.
The solution is well defined interfaces and partitioned work. It's the height of folly having even 2 coders working on the same classes at the same time. If someone is working on a model class, let him finish it before someone else picks up the next backlog item to modify it. My experience is mega-merges are the results of engineering management failures.
Upvote
0
(0
/
0)
Cloudgazer
Ars Legatus Legionis
Merging and rebasing are probably the most difficult things that a dev deals with regularly. There are other more difficult things, but they're pretty rare by comparison.
The solution is well defined interfaces and partitioned work. It's the height of folly having even 2 coders working on the same classes at the same time. If someone is working on a model class, let him finish it before someone else picks up the next backlog item to modify it. My experience is mega-merges are the results of engineering management failures.
That's a lovely idea - it is also completely unworkable in many development environments.
For example doing things your way it's impossible to have a branch intended for release next year and still release bug fixes now.
Mega merges are the result of the need to deliver things at different times, and pieces of work that may be done many months before they are ready for release, but which nonetheless affect production code.
Upvote
2
(2
/
0)
For example doing things your way it's impossible to have a branch intended for release next year and still release bug fixes now.
Mega merges are the result of the need to deliver things at different times, and pieces of work that may be done many months before they are ready for release, but which nonetheless affect production code.
You see the result in iOS/Windows/Android from that kind of branched-to-hell environment. Mountains of bugs, ever poorer quality. That's because management has convinced itself that branching to hell was the way to go when it wasn't.
Upvote
-1
(0
/
-1)
Cloudgazer
Ars Legatus Legionis
For example doing things your way it's impossible to have a branch intended for release next year and still release bug fixes now.
Mega merges are the result of the need to deliver things at different times, and pieces of work that may be done many months before they are ready for release, but which nonetheless affect production code.
You see the result in iOS/Windows/Android from that kind of branched-to-hell environment. Mountains of bugs, ever poorer quality. That's because management has convinced itself that branching to hell was the way to go when it wasn't.
RIght - because what would be so much better is if critical bugs went unpatched for a year until the next big release because that would avoid branching - bad luck to you if you get hacked.
Upvote
1
(1
/
0)
Do you have any proof for your assertion that Windows a) uses that branching strategy you claim they do and b) actually has higher bug count as a result?For example doing things your way it's impossible to have a branch intended for release next year and still release bug fixes now.
Mega merges are the result of the need to deliver things at different times, and pieces of work that may be done many months before they are ready for release, but which nonetheless affect production code.
You see the result in iOS/Windows/Android from that kind of branched-to-hell environment. Mountains of bugs, ever poorer quality. That's because management has convinced itself that branching to hell was the way to go when it wasn't.
I guess not.
Just out of curiosity, what's the largest project in with regards to the number of engineers and actively supported releases you've worked on? Neither of those two metrics can be particularly high with your "nobody ever work on anything that someone else is working on somewhere!"
Upvote
4
(4
/
0)
Upvote
-7
(0
/
-7)
BlackMan614
Seniorius Lurkius
Hey Peter... just checking in. How is that 11 year old working out? Yours truly... FBI.
Upvote
-8
(0
/
-8)
- Status
- Not open for further replies.