Source code repository discussion

In this forum you can write about anything that does not fit in other forums.
This includes generic Oric talkings and things that are totaly unrelated but want to share with people here :)
User avatar
ibisum
Wing Commander
Posts: 1645
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Source code repository discussion

Post by ibisum »

[EDIT: Split the part about Source Control changes into its own discussion]

Since I love git and use it for everything, every day, I could assist with the svn->git migration if needed...
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Changed of hosting strategy

Post by Dbug »

ibisum wrote: Mon Jun 29, 2020 9:24 am Since I love git and use it for everything, every day, I could assist with the svn->git migration if needed...
Since you seem to know git, what is the equivalent of a file history/log, where I can select ONE file, and see the entire file history, diff between two versions, etc... and by file, I mean that: ONE specific file, not the change list it came from with all the other files it was submitted with.

With github I was not able to do that, that drove me crazy.

With SVN I generally use Tortoise SVN, what would be the best/simplest/streamlined Windows user interface/tool for git? (I refuse to use the command line when I use source control, command line is for scripting, user errors when using command lines are way too easy to do).
User avatar
ibisum
Wing Commander
Posts: 1645
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Changed of hosting strategy

Post by ibisum »

I'm a 40 year veteran Unix developer, so I don't have any such quandary with the command line, and am competent either at the command line or at the GUI, although I despise Windows the way you seem to despise BASH, so maybe it evens out a bit ... But anyway, I do understand your requirement... I'm on MacOS, and when I use a Git GUI (not often, because I'm far more productive on the command line), its Fork, which is also out there for Windows as well. It is pretty feature-rich, and can show you changes on a file over multiple commits, as you need.

https://git-fork.com

I think its pretty decent and worth the effort to learn how to use it.

If you want to overcome your fear of the command line, I can help with that as well - but honestly, its probably best you stay the hell away from command-line git. ;p

BTW, to do it on the command line:

Code: Select all

$ git log --follow -p path/to/some/file/you/want/to/study.txt
.. will show you all changes to a single file over time, including diffs ..
User avatar
jbperin
Flight Lieutenant
Posts: 480
Joined: Wed Nov 06, 2019 11:00 am
Location: Valence, France

Re: Changed of hosting strategy

Post by jbperin »

The best git user manual I've ever found: Image

If you don't want to use git command line you can use git extensions. So that you will realize that it's not just a problem of command line. Git manages to turn even graphical interface obscur.
User avatar
jbperin
Flight Lieutenant
Posts: 480
Joined: Wed Nov 06, 2019 11:00 am
Location: Valence, France

Re: Changed of hosting strategy

Post by jbperin »

Otherwise. . In Visual Studio Code, the git stuff works well. You can get the timeline of a file which gives you the history of a single file.
User avatar
iss
Wing Commander
Posts: 1641
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Changed of hosting strategy

Post by iss »

jbperin wrote: Mon Jun 29, 2020 1:08 pmThe best git user manual I've ever found...
This is actually very true! In most cases with merge conflicts this the best practice to resolve them quickly. :)
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Changed of hosting strategy

Post by Chema »

Tortoise, the shell extension I used with SVN, has a git version... just for the record (I always struggled to use it too, anyway).

https://tortoisegit.org

Cheers
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Changed of hosting strategy

Post by Dbug »

I am competent with command line, that's not the actual problem: I just know that when I am tired, stressed, or in a hurry; just missing a ., being in the wrong working directory, forgetting some switch, can lead to catastrophic failure, which almost never happen when using a UI.

Good UI show in the log the actual command line used, so you can copy-paste that and make a script out of it.

My problem with git is that it's ultra technical at the core.

I've used Visual Source Safe, CVS, SVN, Perforce, a bit of Hg, and Git.

Git is the most powerful of them all, but it's also the one where I've seen the most people having issues, destroying history by using the wrong command which cannot be undone without surgeon level experience: This is not what I want to have to deal with for my hobby projects.

Regarding suggestions, we have git-fork and tortoise-git, I can add "Sourcetree" to the list.

So let say we move/import the repository to a hosted git repository, I supposed that means people who want to work on it "fork it", work on their own version, and then send "pull requests"? How does that work concretely when using these tools?

(My only git experience was to work directly a repository, not interacting with others)
User avatar
jbperin
Flight Lieutenant
Posts: 480
Joined: Wed Nov 06, 2019 11:00 am
Location: Valence, France

Re: Changed of hosting strategy

Post by jbperin »

Dbug wrote: Mon Jun 29, 2020 4:40 pm Regarding suggestions, we have git-fork and tortoise-git, I can add "Sourcetree" to the list.
And git extensions.
User avatar
ibisum
Wing Commander
Posts: 1645
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Changed of hosting strategy

Post by ibisum »

Dbug wrote: So let say we move/import the repository to a hosted git repository, I supposed that means people who want to work on it "fork it", work on their own version, and then send "pull requests"?
Yes, this is the general flow that would be used. There'd be a main repository, and one or two folks responsible for it, who are the leaders of the project. They can do whatever they want - make commits, push them to the repo, etc. - without requiring any other involvement. Repo owners themselves do not have to do pull requests, although it is good standard practice as a habit to have your own personal fork of the public repo's you maintain, so that there's a buffer in case you screw something up - it happens.

But if third parties come along and want to say, submit a bug fix for something they found, they would indeed fork the repository (if they have an account on Github/Gitlab), make changes to their version of the repository, push those changes to their own repo, and then use the Github/Gitlab interface to submit a pull request, which essentially is a big diff file that has the deltas required to bring the origin repo into the same state as the forked repo. This is pretty smooth and painless once you've drilled it a few times.

Key thing to know is that you do have professional git users around to help you, if you deviate from good standard practices and end up with something messy somehow. There are very few git catastrophe scenarios that can't be resolved with a bit of standard practices - where most people go wrong is that they decide to do things 'their own way' over a misunderstanding of how things work, and end up painting themselves into a corner.

That said, we don't HAVE to go to git - just that it is a more modern source control system, with pretty great tools from one end of the spectrum to the other. I'd be in favour of it. But I'm also cool with SVN, even though it also has quirks that sometimes get in the way of production ..
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Changed of hosting strategy

Post by Dbug »

and then use the Github/Gitlab interface to submit a pull request, which essentially is a big diff file that has the deltas required to bring the origin repo into the same state as the forked repo. This is pretty smooth and painless once you've drilled it a few times.
Does that has to be done on the web interface of github/gitlab, or can that be done with proper tools, from a computer?

As far as I'm concerned, both Github and Gitlab interfaces are bad, when you've used tools like Perforce for two decades, things like the integrated File History / Folder History / Time Lapse View / Revision Graph, etc... going back to Github to track changes is like taking a time capsule back in time in term of usability and performance.
User avatar
ibisum
Wing Commander
Posts: 1645
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Changed of hosting strategy

Post by ibisum »

My advice: use a local client (git-Fork) to manage your own local repository, just like usual, do proper commits, push your changes to your own fork of the repo, push it upstream to GH/Gitlab when its really ready, and then use the GH/Gitlab interface to make the PR. If you don't want to do a web-based submission of the PR, you can also use the 'hub' tool, although this is more command-line voodoo ..

https://stackoverflow.com/questions/403 ... -on-github

But always remember: its your local repo, you don't have to do anything until you're ready to share with others. You can do all the branching and commits and whatnot you want, locally, push your own changes to your own fork of the repo - and only when it comes time to share with the rest of us, do the Pull Request.


Another thing you could consider is that, if you make the core group of devs admins of the origin repo, none of us would have to do pull requests. ;)

Also: remember that GIT != Github/Gitlab. Those services exist to make using Git easier - that is, getting a repository set up on a server - but if you don't want to use them you can also set up a git server on your own machine (git.defence-force.org?) and ignore all the web fluff you don't like ..
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Source code repository discussion

Post by Dbug »

Yes I know that GIT is not the same thing as github/lab/etc... these things exist because git is hard to use. It's not that I don't like web stuff, it's just that this webstuff is inadequate. Like seriously lame. It's like GIMP vs PhotoShop.

Regarding having everybody work on their own local repository, it's an heresy: The whole point of having source control is to have revisions, but also to safely work on things knowing that you have your work duplicated on other machines.

I can see why a central repository does not work well for something like the Linux Kernel, but having a central repository with branches where you can see what people do, which is backuped, etc... is so worthwhile.

Obviously the people who had commit rights on SVN would have commit rights on the new depot, but as usual it's meritocratic: It's something people earn by showing they can provide contributions that are approved.
User avatar
jbperin
Flight Lieutenant
Posts: 480
Joined: Wed Nov 06, 2019 11:00 am
Location: Valence, France

Re: Source code repository discussion

Post by jbperin »

Dbug wrote: Tue Jun 30, 2020 4:56 pm Obviously the people who had commit rights on SVN would have commit rights on the new depot, but as usual it's meritocratic: It's something people earn by showing they can provide contributions that are approved.
OK but what about the people who had no commit rights on SVN and who are working on ass kicking routines that shock the community in the hope to be granted the commit right ?

How can they know what triggers the approval ? Whose approbation do they have to get ? What are the criteria ?

I'm asking for a friend of mine who intends to enter the Oric's history by providing the community with stunning performance routines. :twisted:
User avatar
ibisum
Wing Commander
Posts: 1645
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Source code repository discussion

Post by ibisum »

Git is flexible enough to cover all cases, from heresy to sainthood. If you want a central repository that a core team, as well as the occasional stranger, can contribute to - then set it up on gitlab (better than GitHub), give one or two trusted Wing Commander's access, and accept Pull Requests when they come in .. if you want to keep things local and privileged, no worries, you can still do that on your own local copy of the repository, exclusive branch, etc. Just don't push your branches to the central repo, or maintain a separate fork - as many do - that has your bleeding edge stuff in it, and then when its ready push to master on the main repo.

I think the thing to understand is that Git will fill your use case, pretty well.
Post Reply