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

321–330 of 416 posts

Re: The largest Git repo

#321

Post by nojvek »

ry_ry wrote: post #189
quotemstr wrote: post #157

I have tremendous respect for Microsoft pulling itself together over the past few years.

Such a relevant point, and I don't think they get enough props for it. I don't believe for one second this was a quick turnaround for them either. I've spoken to MS dev evangelists at work stuff over the past few years and they've continually said "it's going to get better", usually with a wry smile. It bloody did too. They're nowhere near perfect, and the different product branches remain as disjointed as ever, but…

Moving entire code base from source Depot (invented at Microsoft) git (not ms) was a huge undertaking. I know many ms devs who hated git.

But this is seriously brave and well executed on their part.

Re: The largest Git repo

#322

Post by smitherfield »

sangnoir wrote: post #187
garyclarke27 wrote: post #45

Linus must be very proud - his favourite software Windows - now depends on GIT.

Linus ought to be proud - it wasn't too long ago when Microsoft was calling his other work "a cancer", and now Windows depends on Git.Younger me would not believe this. Linus definitely is a rare genius on design and execution - he made his mark not only on Kernels/OSes, but on version control systems as well. I salute you, Linus!

If I recall correctly, wasn't the "cancer" remark in reference to the GPL?

Re: The largest Git repo

#323

Post by MichaelMoser123 »

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.

also they do all the development in one branch / in the trunk https://arxiv.org/abs/1702.01715 ( I never understood the explanations as to why they do that )

Now the article says that with windows they do branches.

Re: The largest Git repo

#324

Post by cryptonector »

nerdponx wrote: post #312
srathi wrote: post #293

Earlier quoted context omitted.

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.

No no, you never force push to "published" branches, e.g., upstream master. What you're doing when you rebase onto the latest upstream is this: you're making your local history the _same_ as the upstream, plus your commits as the latest commits, which means if you push that, then you're NOT rewriting the upstream's history.

(In the Sun model one does rewrite project branch history, but one also leaves behind tags, and downstream developers use the equivalent of git rebase --onto. But the true upstream never rewrites its history.)

Re: The largest Git repo

#325

Post by BenjiWiebe »

tormeh wrote: post #224
qznc wrote: post #175

Earlier quoted context omitted.

I recently heard a story that someone tried to push a 1TB repo to our university Gitlab which then ran out of disk space. Sure, that might have been not be a usable repo but only an experiment. Still, I would bet against the claim that 300GB is the largest one.

1 TB of code ?

I'd sure like to run that as my operating system, browser, virtual assistant, car automation system, and overall do-everything-for-me system...

Re: The largest Git repo

#326

Post by cryptonector »

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…

Well, git rerere helps here, though, honestly, this never happens to me even when I have 20 commits. Also, this is what you want, as it makes your commits easier to understand by others. Otherwise, with thousands of developers your merge graph is going to be a pile of incomprehensible spaghetti, and good luck cherry-picking commits into old release patch branches!

Ah, right, that's another reason to rebase: because your history is clean, linear, and merge-free, it makes it easier to pick commits from the mainline into release maintenance branches.

The "fake history" argument is no good. Who wants to see your "fix typo" commits if you never pushed code that needed them in the first place? I truly don't care how you worked your commits. I only care about the end result. Besides, if you have thousands of developers, each on a branch, each merging, then the upstream history will have an incomprehensible (i.e., _useless_) merge graph. History needs to be useful to those who will need it. Keep it clean to make it easier on them.

Rebase _is_ the "more powerful merge abstraction", IMO.

Re: The largest Git repo

#327

Post by cryptonector »

ferdterguson wrote: post #318
rdubz wrote: post #308

Earlier quoted context omitted.

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.

And cherry-pick onto release maintenance branches.

Re: The largest Git repo

#328

Post by cryptonector »

ninkendo wrote: post #303
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?

This is why, in git workflows with rebases, it's a good idea to create merge commits anyway, even if the master branch can fast-forwarded. That way, looking at the history, you know what commits are stable/tested by looking at merge commits. Others that were brought in since the last merge commit can be considered intermediary commits that don't need to be individually tested. (Of course, there's also the rebase-and-…

I've toyed with the idea of using merge commits to record sets of commits as being... atoms.

Suppose you want to push regression tests first, then bug fixes, but both together: this is useful for showing that the test catches the bug and the bug fix fixes it. But now you need to document that they go together, in case they need to be reverted, or cherry-picked onto release maintenance branches.

I think branch push history is really something that should be a first-class feature. I could live with using merge commits (or otherwise empty-commits) to achieve this, but I'll be filtering them from history most of the time!

Re: The largest Git repo

#329

Post by cryptonector »

emmelaich wrote: post #298
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…

Are you saying that you use Git instead of Mercurial these days? Not necessarily implied by you; just checking.

Me personally? Yes, I use git whenever I can. I still have to use Mercurial for some things.

I don't know what Oracle does nowadays with the gates that make up Solaris. My guess is that they still have a hodge podge, with some gates using git, some Mercurial, and some Teamware still. But that's just a guess. For all I know they may have done what Microsoft did and gone with a single repo for the whole thing.

Re: The largest Git repo

#330

Post by BenjiWiebe »

nthcolumn wrote: post #226

Linus Torvalds rocks. Windows sucks. Subversion was crap so he just made git instead. git beat out svn, TFS and all that other crap legions of overpaid engineers came up with (or what they didn't get source control???) because unix design philosophy and therein lies the lesson still unlearned for they hath loaded all their bloat into one repo. Windows. It sucks and it will forever suck because it sucks by design. Bil…

Sadly we will have to quit blaming Bill Gates. I doubt he makes very many design decisions any more. :)
Post reply on HN