Talk:Using Git

Latest revision as of 11:52, 31 May 2024

Anyone use Git Extensions for Windows? Supposedly integrates with Windows Explorer. Haven't used it myself, though, but thought I'd mention it for anyone seeking alternatives. --DaveCoyle 02:03, 5 August 2009 (UTC)

[edit] Not working with my login?

I'm trying an initial git clone (want to try and compile with bulletsim) - but can't login with windows git. Keeps asking for the password and then invallidating the password - problem?

Ray

I think you are using the methid for core developers. Look under Using_Git#Cloning_the_Repositry_.28for_Non_Core_Developers.29, this should work without asking for a password.

--Fritigern 10:35, 10 August 2011 (UTC)

Almost - I was using the non-core, but I hadn't noticed the copy-paste had changed the "git://" header to "ssh://" - changed this back and now pulling ok.

I do think that this article could do with a good rewrite to restructure it, so that stuff for non-developers are grouped together, and the stuff for developers are grouped together.

I will look into this.

--Fritigern 18:07, 11 August 2011 (UTC)

Definitely worth including Git Extensions for gui on Windows. By far the best option I have found, although only before the .net update happened, cause developers love their dark mode :) https://github.com/gitextensions/gitextensions/releases/tag/v3.5.4 -Tampa

[edit] Git Roadmap

Hi all,

I'm aware that the transition to a self-hosted Git repository has occurred over a decade ago, and I seriously omment you guys for doing so.

However, I admit that I'm spoiled by the functionality of modern, open, public repositories (GitHub comes to mind, but there are obviously more). Not to mention that with such tools it would be far easier to do issue tracking + code submission + CI, all in the same platform... but anyway! That's an issue for the Core Devs to discuss! Do you want to enter the modern age of collaborative coding of the 2020s, or should we remain stuck with something from the generation before, which does work well, and has served te community for so long? You decide!

My point was actually something funny that I only noticed yesterday.

I saw somewhere that Ubit had been submitting *more* code, so, as usually, since I *love* to live dangerously on my "bleeding edge" OpenSim grid (the theory being: if things break, I'll be the first to know!). I did the usual git pull, and, as it has been the case for several months, Git told me that the repo was Already up to date, which it has been fond of saying.

I was going to dismiss the issue further — if it's up to date, it's up to date, Git knows what it's doing, right? — until I noticed a slight discrepancy in the versions, when doing some Hypergrid jumps. Why was "my" grid running on 0.9.2.2 while the destination grid was on Nessie, 0.9.3? That was weird! I wondered — was there an even-more-bleeding-edge version I didn't know about?

As it happens, I got too excited with Microsoft's Rosalyn compiler for non-Windows platforms, and once Ubit released an "experimental" release that does not rely upon Mono any longer (hooray!), I immediately switched to it — branch dotnet6. Things worked exemplarily well for a while. Then, as said, there were no more updates, and I was fine with "no news is good news".

While compiling a new version of a LibreMetaverse project I'm doing (very very slowly), I noticed, however, that .NET 6 was, for all purposes, deprecated. Current version (at the time of writing!) is 8, not 6, and 9 is out in Preview. So I was seriously behind the latest & greatest technologies — even though I thought I had switched to the bleeding edge-iest branch?...

Well, that *was* true a couple years ago or so. Then non-Mono .NET compilation became, in fact, the official main branch. And, as expected, *that* was getting the latest updates — not an "experimental" branch from ages ago.

Which makes a lot of sense. I was just ignorant, I should have checked all the branches, to see which ones are being kept up to date... but wait... how many branches are there?!

As it turns out... there are dozens and dozens and dozens! Most have obscure names from the developers who created the branch, and with next-to-zero information about what that specific branch is supposed to do. Which is not surprising: in many scenarios, these are just Pull Requests, which have been discussed on the Mantis, and then the branches were merged, after due testing. To keep track of them all... you have to keep track of all issues on Mantis. Which, obviously, I don't, so I totally missed this...

That's "not a problem" — Git is designed to deal with dozens, hundreds of branches, and I understand that this is exactly what Linus Torvalds does for the Linux kernel development. But, alas, I'm no Linus :) and I lack the ability to figure out what branch does what — because, well, the official repository doesn't have a nice, cool Web interface!

Now, I don't want to enter into the "repository wars" — they're a waste of time — and I think that we can live with what we have (after all, it's what has kept the code up to date!). Nevertheless, please consider pruning the branch tree to something more manageable. I'm not saying that we only need a "main" branch and a "dev" branch; OpenSimulator is probably too complex for such a simplistic organisation. I'm just saying that "old" branches — which have been merged or abandoned eons ago — should be pruned from the active tree. It's possible to consider having an archive facility for historic purposes (although, technically spaking, the main branch has all the history already...). But the branches receiving ongoing contributions — experimental or final! — should be the only ones "active", so to speak.

Needless to say, that this is the whole reason why sites such as GitHub exist. Visually it's very easy to see everything at a glance, and even drop some notes here and there in order to know what each branch was supposed to be for, and which ones are being actively pursued. GitHub/GitLab/Bitbucket/Gogs/Gitea and many, many other platforms have been designed to make all that housekeeping work *easy*.

That said...

After switching from the dotnet6 branch to the main one, I had zero issues in compiling everything under .NET 8 — it worked almost flawlessly (I had to delete some deprecated DLLs which were still around for some stupid reason and which were "confusing" the OpenSim executable when loading all existing modules...) and I'm closely watching our mini-grid for performance issues. So far, everything looks awesome :)

Cheers and thanks in advance,

— Gwyneth Llewelyn (talk) 11:52, 31 May 2024 (PDT)