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

391–400 of 416 posts

Re: The largest Git repo

#391

Post by pmontra »

hinkley wrote: post #311
pmontra wrote: post #263

Earlier quoted context omitted.

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.

Would you mind explaining about this lack of seamlessness?

I can imagine that part of it could be the need of a git clone --recursive, and everybody omits the --recursive if they don't know there are submodules inside the repository. There is another command to pull the submodules later but I admit it's far from ideal.

Re: The largest Git repo

#392

Post by contextfree »

nojvek wrote: post #321
ry_ry wrote: post #189

Earlier quoted context omitted.

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.

I also know many MS devs who hated Source Depot :)

Re: The largest Git repo

#393

Post by eridius »

Peaker wrote: post #390
eridius wrote: post #302

Earlier quoted context omitted.

Well, all it checks is that you modified the base case to look like one of the two other cases. That doesn't actually tell you if you resolved the conflict though, just that you copied one of the cases over the base case.

True, but if you follow a simple mechanical guideline: Apply the change 2 other versions (preferably the base one last) - then your conflict resolutions are going to be correct. From experience with many developers using this method, conflict resolution errors went down to virtually zero, and conflict resolution time has improved by 5x-10x.

There's a much simpler mechanical guideline that works without git-mediate: Apply the change to the other version. git-mediate requires you to apply the change twice, but normal conflict resolution only requires you to apply it once.

Re: The largest Git repo

#395

Post by mandeepj »

deepsun wrote: post #252
amag wrote: post #227

Earlier quoted context omitted.

It looks like git-mediate does one more important thing; it checks that the conflict is actually solved. In my experience it's very easy to miss something when manually resolving a conflict and often the choices the merge tools give you are not the ones you want.

IntelliJ IDEA default merger knows when all conflicts in a file are handled and shows you a handy notification on top "Save changes and finish merging".

TFS's conflict resolver also does this

Re: The largest Git repo

#396

Post by _asummers »

jjawssd wrote: post #307
seanp2k2 wrote: post #291

Earlier quoted context omitted.

Cherry picking hotfixes into maint branches is cool until you have stuff like diverging APIs or refactored modules between branches. I don't know of a better solution; it kind of requires understanding in detail what the fix does and how it does it, then knowing if that's directly applicable to every release which needs to be patched.

Use namespaces to separate API versions? POST /v4/whatever POST /v3/whatever

We version each of our individual resources. so a /v1/user might have many /v3/post . Seems to work for us as a smaller engineering team.

Re: The largest Git repo

#397

Post by therealdrag0 »

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 sense to have separate repos for things that don't interact. But when your modules or services do. Having them together cuts out some overhead.

Re: The largest Git repo

#398

Post by hueving »

taeric wrote: post #304
hueving wrote: post #285

Earlier quoted context omitted.

No it doesn't. I think you are thinking of the kernel, which is separate from all the distros. Linux by itself is just a kernel and won't do anything for you without the rest of the bits that make up an operating system.

Then I'll point to the wide success of monolithic utilities such as systemd as evidence that consolidating typically helps long term. Which is to say, not shockingly, it is typically a tradeoff debate where there is no toggle between good and bad. Just a curve that constantly jumps back and forth between good and bad based on many many variables.

systemd is also completely useless on its own. It still needs a bootloader, a kernel, and user-space programs to run.

When it comes to process managers, there is obviously disagreement about how complex they should be, but systemd is still a system to manage and collect info about processes.

Re: The largest Git repo

#399

Post by Peaker »

eridius wrote: post #393
Peaker wrote: post #390

Earlier quoted context omitted.

True, but if you follow a simple mechanical guideline: Apply the change 2 other versions (preferably the base one last) - then your conflict resolutions are going to be correct. From experience with many developers using this method, conflict resolution errors went down to virtually zero, and conflict resolution time has improved by 5x-10x.

There's a much simpler mechanical guideline that works without git-mediate: Apply the change to the other version. git-mediate requires you to apply the change twice, but normal conflict resolution only requires you to apply it once.

Except you don't really know if you actually applied the full change to the other version. That's what applying it to the base is all about.

You often take the apparent diff, apply it to the other version, and then git-mediate tells you "oops, you forgot to also apply this change". And this is one of the big sources of bugs that stem from conflict resolutions.

Another nice thing about git-mediate is that it lets you safely do the conflict resolution automatically, e.g: via applying a big rename as I showed in the example, and seeing how many conflicts disappear. This is much safer than manually resolving.

Re: The largest Git repo

#400

Post by eridius »

Peaker wrote: post #399
eridius wrote: post #393

Earlier quoted context omitted.

There's a much simpler mechanical guideline that works without git-mediate: Apply the change to the other version. git-mediate requires you to apply the change twice, but normal conflict resolution only requires you to apply it once.

Except you don't really know if you actually applied the full change to the other version. That's what applying it to the base is all about. You often take the apparent diff, apply it to the other version, and then git-mediate tells you "oops, you forgot to also apply this change". And this is one of the big sources of bugs that stem from conflict resolutions. Another nice thing about git-mediate is that it lets you…

Applying the change to the base doesn't prove that you applied the change to the other version. It only proves that you did the trivial thing of copying one version over the base. That's kinda the whole point of my complaint here, git-mediate is literally just having you do busy-work as a way of saying "I think I've applied this change", and that busy-work has literally no redeeming value because it's simply thrown away by git-mediate. Since git-mediate can't actually tell if you applied the change to the other version correctly, you're getting no real benefit compared to just deleting the conflict markers yourself.

The only scenario in which i can see git-mediate working is if you don't actually resolve conflicts at all but instead just do a project-wide search&replace, but that's only going to handle really trivial conflicts, and even then if you're not actually looking at the conflict you run the risk of having the search & replace not actually do what it's supposed to do (e.g. catching something it shouldn't).

Post reply on HN