[deleted]
The largest Git repo
271–280 of 416 posts
Re: The largest Git repo
#272Windows, because of the size of the team and the nature of the work, often has VERY large merges across branches (10,000’s of changes with 1,000’s of conflicts). At a former startup, our product was built on Chromium. As the build/release engineer, one of my daily responsibilities was merging Chromium's changes with ours. Just performing the merge and conflict resolution was anywhere from 5 minutes to an hour of my t…
When you have that many conflicts, it's often due to massive renames, or just code moves. If you use git-mediate[1], you can re-apply those massive changes on the conflicted state, run git-mediate - and the conflicts get resolved. For example: if you have 300 conflicts due to some massive rename, you can type in: git-search-replace.py[2] -f oldGlobalName///newGlobalName git-mediate -d Succcessfully resolved 377 confl…
Not sure why companies don't develop great merge tools, looks like there is a big market for them.
Re: The largest Git repo
#273Earlier quoted context omitted.
Yes! One of the most important advantages of a rebase workflow is that you can see immediately what upstream commits your conflict with, as opposed to some massive merge you have to go chasing branch history to figure out the semantics of the change in question. "Amazing" is right. Sun was doing rebases in the 90s, and it never looked back.
My exact experience (in the context of "merging upwards"). Large merges are a huge pain to do, and are basically impossible to review, too.
Yes! Reviewing huge merges is infeasible. Besides, most CR tools are awful at capturing history, especially in multi-repo systems. So rebasing and keeping history clean and linear is a huge win there.
Though, of course, rebasing is a win in general, even if you happen to have an awesome CR tool (a unicorn I've yet to run into).
Re: The largest Git repo
#274Rather than worry about getting `status` under 10 seconds, just focus on `diff --stat` and `diff --cached --stat`. Those two replace most uses for `status`.
Re: The largest Git repo
#275Earlier quoted context omitted.
Yes! One of the most important advantages of a rebase workflow is that you can see immediately what upstream commits your conflict with, as opposed to some massive merge you have to go chasing branch history to figure out the semantics of the change in question. "Amazing" is right. Sun was doing rebases in the 90s, and it never looked back.
My exact experience (in the context of "merging upwards"). Large merges are a huge pain to do, and are basically impossible to review, too.
Another thing is that keeping your unpushed commits "on top" is a great aid in general (e.g., it makes it trivial to answer what haven't I pushed here yet?"), but also is the source of rebasing's conflict resolution power.
Because you're unpushed commits are on top, it's easy to isolate each set of merge conflicts (since you're going commit by commit) and to find the source of the conflicts upstream (with log/blame tools, without having to chase branch and merge histories).
Re: The largest Git repo
#276I see that Windows engineering uses a merge workflow. I wonder why. See other comments in this thread about rebasing.
Re: The largest Git repo
#277Earlier quoted context omitted.
Different divisions have had different stances on open source code for a long time. Somewhere I still have the t-shirt from our first "Open Source Day" event back in 2008 (and it's not like that was the first time any MS employee had ever considered using open source). Things are a lot more standardized now, with a big push from both the top and the bottom to use open source wherever it makes sense. Why reinvent the…
> Why reinvent the wheel? Look who's talking :)! Wasn't WiX released and developed as an Open Source project by MS?
IIRC, it was the first open source project started by Microsoft / by a Microsoft employee.
As a German, I find the name super cringeworthy, but it makes me giggle every now and then.
Re: The largest Git repo
#278Earlier quoted context omitted.
No, it should be hard to make arbitrary changes. If you change the word "arbitrary" to "necessary" (implying a different bias than the one you went with) then all of a sudden this attitude sounds less helpful. Similarly "easy to limp along with a bad architecture" could be re-written as "easy to work with the existing architecture". At the end of the day, it's about getting work done, not making decisions that are th…
> At the end of the day, it's about getting work done, not making decisions that are the most "pure". This attitude will lead to a total breakdown of the development process over the long term. You are privileging Work Done At The End Of The Day over everything else. You need to consider work done at every relevant time scale. How much can you get done today? How much can you get done this month? How much can you get…
The linux codebase exists in stark contrast to your claim. Assuming your claim is that broken up repos is the better way.
Re: The largest Git repo
#279Windows, because of the size of the team and the nature of the work, often has VERY large merges across branches (10,000’s of changes with 1,000’s of conflicts). At a former startup, our product was built on Chromium. As the build/release engineer, one of my daily responsibilities was merging Chromium's changes with ours. Just performing the merge and conflict resolution was anywhere from 5 minutes to an hour of my t…
Generally, it's the responsibility of whoever made the changes to resolve conflicts (basically, git blame conflicting lines and the people who changed them get notified to resolve conflicts in that file). Distributing the work like this makes the merges more reasonable.
Yep, this is the way I work. Always rebase against master, and fix conflicts there, so branches merging into master should always be up-to-date and have zero conflicts.
Re: The largest Git repo
#280Earlier quoted context omitted.
This may be the thing that gets Google to switch. They like having every piece of code in a single repository which Git cannot handle. Now that it is somewhat proven, maybe Google will leverage GVFS on Windows and create a FUSE solution for Linux.
They use mercurial (or were), which is as good as git. In fact, I bet a lot of people at Google are happy to use mercurial instead of git, given git's bad reputation with its command line interface.
You're thinking of Facebook if I'm not mistaken.