Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The largest Git repo

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

311–320 of 416 posts

Re: The largest Git repo

#311

Post by hinkley »

pmontra wrote: post #263
hinkley wrote: post #210

Earlier quoted context omitted.

This is the main thing I miss about subversion. You could check out any arbitrary subdirectory of a repository. On two projects the leads and full stack people had the whole thing checked out, everybody else just had the one submodule they were responsible for. Worked fairly well.

Git has submodules too and teams usually have access control on the main server used for sharing commits.

git submodules aren't seemless. None of the alternatives appear to be any better. A halfassed solution is no solution at all.

Re: The largest Git repo

#312

Post by nerdponx »

srathi wrote: post #293
tokenizerrr wrote: post #245

Earlier quoted context omitted.

How does that work?

You first rebase against the master locally and push the merged feature branch after resolving all the conflicts yourself. Afterwards, you go to the master and merge it against the updated feature branch. The 2nd merge should not result in any conflicts.

This model can be annoying on running feature branches. Once you rebase, you have to force-push to the remote feature branch. It's not so bad if you use --force-with-lease to prevent blowing away work on the remote, but it still means a lot of rewriting history on anything other than one-off branches.

Re: The largest Git repo

#313

Post by lsaferite »

cryptonector wrote: post #270
nikital wrote: post #254

Earlier quoted context omitted.

A pain I have with rebase workflow is that it creates untested commits (because diffs were blindly applied to a new version of the code). If I rebase 100 commits, some of the commits will be subtly broken. How do you deal with that?

With git rebase you can in fact build and test each commit. That's what the 'exec' directive is for (among other things) in rebase scripts! Basically, if you pick a commit, and in the next line exec make && make check (or whatever) then that build & test command will run with the workspace HEAD at that commit. Add such an exec after every pick/squash/fixup and you'll build and test every commit.

Or you could use the "-x" parameter to execute something between every rebase.

Re: The largest Git repo

#314

Post by mkj »

bitJericho wrote: post #138
TylerE wrote: post #72

Earlier quoted context omitted.

It makes total sense when the expectation is that any engineer in the company can build any part of the stack at any time with a minimum of drama.

This just blew my mind. I'm gonna go home and see about combining all my projects. That seems very useful!

It makes things tricky if you want to opensource just one of your projects.

Re: The largest Git repo

#315

Post by nine_k »

paulddraper wrote: post #196
ericfrederich wrote: post #168

Earlier 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.

Google used to have a Perforce frankenstein, but now they have their own VCS.

Piper is their perforce-like server. You check out certain files, as you'd with p4, work on the tree using git, with reviews, tests, etc. You periodically do a sync which is like pull - - rebase. Then you push your changes back into the perforce-like monorepo.

Re: The largest Git repo

#316

Post by taspeotis »

graycat wrote: post #260

Sounds like a lot of good work. But, in "Git repo", what the heck is a "repo"? A repossession as in repossessing a car? In the OP with "Everything you want to know about Visual Studio ALM and Farming", what is ALM -- air launched missile? What do air launched missiles and "farming" have to do with Visual Studio? To Bill Gates and Microsoft: For my startup, I downloaded, read, indexed, and abstracted 5000+ Web pages f…

Repository.

Application Lifecycle Management.

It's Brian Harry's blog, he has a farm, sometimes he posts about the (mis)adventures of his animals.

Re: The largest Git repo

#317

Post by nxc18 »

caf wrote: post #301
nxc18 wrote: post #159

Earlier quoted context omitted.

The NT kernel is surprisingly small and well-factored to begin with - it is a lot closer to a 'pure' philosophy (e.g. Microkernel) than something like Linux to begin with. If you have a problem with Windows being overcomplicated or in need of refactor it is almost certainly something to do with not-the-kernel. If you look at something like the Linux kernel its actually much larger than Windows. It needs to have every…

Small and well-factored the core kernel may be, but if you're parsing fonts in kernel mode, you ain't a microkernel. ( https://googleprojectzero.blogspot.com.au/2015/07/one-font-v... )

For sure, and Windows is not a microkernel, but it does have separated kernel-in-kernel and executive layers; it would approach being a microkernel architecture if the executive was moved into userland. This is similar to how macOS would be a microkernel, if everything wasn't run in kernel mode (mach, on which it is partially based, is a microkernel).

Of course the issue here is that after NT 4, GDI has been in kernel mode; this is necessary for performance reasons. Prior to that it was a part of the user mode Windows subsystem.

I'd be curious to see if GDI moved back to userland would be acceptable with modern hardware, but I suspect MS is not interested in that level of churn for minimal gain.

Re: The largest Git repo

#318

Post by ferdterguson »

rdubz wrote: post #308
cryptonector wrote: post #194

At Sun Microsystems, Inc., (RIP) we have many "gates" (repos) that made up Solaris. Cross-gate development was somewhat more involved, but still not bad. Basically: you installed the latest build of all of Solaris, then updated the bits from your clones of the gates in question. Still, a single repo is great if it can scale, and GVFS sounds great! But that's not what I came in to say. I came in to describe the rebase…

A problem with rebase workflows that I don't see addressed (here or in the replies) is: if I have, say, 20 local commits and am rebasing them on top of some upstream, I have to fix conflicts up to 20 times; in general I will have to stop to fix conflicts at least as many times as I would have to while merging (namely 0 or 1 times). Moreover, resolution work during a rebase creates​ a fake history that does not reflec…

IMO, VC comes down not to tracking what was actually done, but to creating snapshots of logical steps that are reasonable to roll back to and git bisect with.

Re: The largest Git repo

#319

Post by lmitchell »

dom0 wrote: post #205
Peaker wrote: post #167

Earlier quoted context omitted.

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…

Also git rerere When maintaining multiple release lines and moving fixes between them: Don't use a bad branching model. Things like "merging upwards" (=committing fixes to the oldest branch requiring the fix, then merging the oldest branch into the next older branch etc.), which seems to be somewhat popular, just don't scale, don't work very well, and produce near-unreadable histories. They also incentivise developin…

I don't understand the hate for merging up. I've worked with the 'cherry-pick into release branches' model, and also with an automated merge-upwards model, and I found the automerge to be WAY easier to deal with. If you make sure your automerge is integrated into your build system, so a failing automerge is a red build that sends emails to the responsible engineers, I found that doing it this way removed a ton of the work that was necessary for cherry-picking. I can understand not liking the slightly-messier history you get, but IMO it was vastly better. Do you have other problems with it, or just 'unreadable' histories and work happening on release branches? Seems like a good trade to me.

Re: The largest Git repo

#320

Post by rak00n »

jasonkostempski wrote: post #198
daxfohl wrote: post #197

Earlier quoted context omitted.

I'd rather see google open up their monorepo as a platform, and compete with github. git is fine, but there's something compelling about a monorepo. Whether they do it one-monorepo-per-account, or one-global-monorepo, or some mix of the two, would be interesting to see how it shapes up.

"one-global-monorepo" caused me to envision a beautiful/horrifying Borg-like future where all code in the universe was in a single place and worked together.

I felt like that when I first saw golang and how you can effortlessly use any repo from anywhere.
Post reply on HN