News:

Want to get involved in developing SMF, then why not lend a hand on our github!

Main Menu

2.1 - Easy CSS crud reduction, if anyone can be bothered.

Started by Antechinus, September 27, 2019, 09:30:53 PM

Previous topic - Next topic

SychO

Well yes, you can at least use it well enough to be able to contribute to other repositories by posting pull requests, anything more complex than a pull push, I turn to the CLI.

It's enough for me because it saves me a lot of time on the repetitive git add, git commit, git push, git pull, git branch -b...etc
Checkout My Themes:
-

Potato  •  Ackerman  •  SunRise  •  NightBreeze

Illori

Quote from: Antechinus on October 07, 2019, 02:22:57 PM
QuoteYou might want to just pull the branch where I pushed all changes and take a look, pulling branches is a lot easier than manually applying changes, it helps in the review process.

Bleh. :P GitHub. :P Me hatez GitHub. :P

I was thinking of doing that the other day. Turns out I'd have to go and register Sourcetree (trial period expired ages ago, around the last time I used GitHub). I couldn't be bothered at the time. Might be bothered soon.

you actually dont need sourcetree or git anything to pull down the branch and test out the code... to make it easier for you as of when you click the link you can download all the files in branch from here

https://github.com/SychO9/SMF2.1/archive/antechinus.zip

you can then install and test it out.

Gwenwyfar

#62
Quote from: Arantor on October 08, 2019, 04:25:56 AM
I just looked at the newer version of the app (built in Electron), and honestly it looks more confusing to me than someone who deals in SourceTree frequently.

If you're explicitly following the GitHub expected workflows (either you're the main collaborator and can push to your own repo, or you're forking and making a pull request), you're probably fine. Anything more exotic and it doesn't look like it'd handle it.

I also don't expect it to handle anything like a stash, let alone interactive rebasing (which SourceTree can do both)... but I'd be concerned that an app has to reach 2.0 to be 'usable'.
Pretty much. And with two people in it, you already get conflicts, which, if it can't solve by itself, it will toss you the command line for.

Anything more complex than pull and push was through the command line when I used it.

Quote from: Antechinus on October 08, 2019, 02:51:27 AM
Ok. So maybe I won't bother registering my copy. Is Gitkraken nice and simple? I want to do everything with 3 buttons and no CLI.
You can do everything in Gitkraken (except fix conflicts in a PR, which is a bummer, or I didn't figure out how it works yet, because their conflicts interface is neat) through a nice interface. I like it. The flow of which thing goes where when you're doing something between two branches can be confusing at first but other than that I think it's fairly simple to use. If you're only doing master then you don't even have to worry about it.

QuoteBeen reading up about Gitkraken. Apparently you can't use the free version without being logged in to their servers, which is unacceptable anyway.
Well you'd be logged to GitHub anyway. I think they do that through their servers? I'm not sure. I don't recall having to create any account/connection just to use it locally, just using your email/key to link it with GitHub...

QuoteSee, I just use the repo directly on my machine as the folder inside XAMPP so I don't have a second copy of anything and can commit whenever I like directly from whatever I'm working on, but that has its own issues.
That's what I'm trying to do now. It's much simpler without the constant checking online files against offline ones.
- Get everything installed: check <3 Now only need to use it as a repo. And now with the sass source files outside and compiling to inside the repo so I don't need to keep track of .gitignore and missive files.

Arantor

I think we're going a little off topic, but to sum up some of the things:

* fixing conflicts is always hard and why none of the Git tools themselves ever try because it's 1) out of scope and 2) needs a human input as to what should be the final resolution anyway

* GitKraken doesn't just have you logged into GitHub (or, more accurately, the underlying Git implementation has you logged into GitHub when you need to be) but I think it also mandates being logged into GitKraken's servers too because it's not actually a free product

* using SMF or similar as a repo is easy enough, wherever your webserver is (be it /var/www/html or similar), "git clone https://github.com/SimpleMachines/SMF2.1.git smf" (or use the clone to make a folder in that place), and you're done, you can then go to localhost/smf or whatever and the files are already just there

Bloc

I have 100% changed from doing uploads of new files to my various sites(especially all the different Themes folders)to *just* using pulls from Github. Github Desktop is used to push things on my local test-sites and if any files should -not- be pushed, I use .gitignore. The program works fine for me, even when changing branches. I think its *way* you use branches that can cause trouble, its no set rules afaik, it can be used in different ways, even working with forks instead of branches could work.

Advantages from the old way of compare/change/upload for me is less hassle in making sure everything is updated(one pull call now) and I can keep stricter access to files on the server - my regular ftp user cannot upload new or overwrite files wihout it belonging to it(which none do), but when logged in with ssh I can sudo git pull/push changes making it more secure.


Great summary, Arantor :) Just my 5 cents here.

Gwenwyfar

Quote* fixing conflicts is always hard and why none of the Git tools themselves ever try because it's 1) out of scope and 2) needs a human input as to what should be the final resolution anyway
Yep, which is why Gitkraken's interface for it is neat. It just shows you both sides and lets you add per line or per chunk of both while viewing the end result. The problem with PR conflicts is that github doesn't recognize it as such, it submits as a new commit rather than a conflict fix, which doesn't seem to work.

Arantor

Technically that's what goes on under the hood anyway; you have a commit that represents the point at which two branches are merged (the "merge commit"), and the conflict resolution step is an amended version of that commit.

It's also why you might sometimes do merges via rebase rather than with actual merges depending on what you're trying to do and how much you care about your history being clean; if you're me and you deal in managing massively complex codebases with core changes, you might want to minimise the cruft in your branches so that when it comes to upgrade time, you can filter out the core commits and keep just your changes in their own little branch ready to replay over the updated codebase later. But that's getting into funky territory.

d3vcho

Y'all remind me of my uni teachers. Refusing to use modern stuff (in general talking, Git is the particular case now) instead of adapting to the new times. That's why I'm still coding in C, and that's why people in Biotechnology degree are using Pascal for programming in 2019.
"Greeting Death as an old friend, they departed this life as equals"

Arantor

I sincerely hope I'm not included in that 'y'all', on the nature that my day job literally couldn't be done in Git with any GUI I've ever seen (since none of them seem to support git push origin HEAD:refs/for/branch syntax by default which makes life complicated since that's how Gerrit works), and that at any given time I have literal dozens of branches within my repos including feature branches of feature branches, and some hefty infrastructure for soft-merging feature branches for the purposes of deploying test environments with multiple feature branches at once.

And let's not forget the dozens of submodules I have floating around.

That's another curse that people rarely remember (and even SMF has a submodule in its repo last I checked)

d3vcho

It's obvious that what can't be done, can't be done. What I'm saying here is that the common arguments of Git(Hub) are like "Git bad. GitHub bad. Everything bad".
"Greeting Death as an old friend, they departed this life as equals"

Gwenwyfar

Quote from: Arantor on October 08, 2019, 08:31:55 AM
Technically that's what goes on under the hood anyway; you have a commit that represents the point at which two branches are merged (the "merge commit"), and the conflict resolution step is an amended version of that commit.

It's also why you might sometimes do merges via rebase rather than with actual merges depending on what you're trying to do and how much you care about your history being clean; if you're me and you deal in managing massively complex codebases with core changes, you might want to minimise the cruft in your branches so that when it comes to upgrade time, you can filter out the core commits and keep just your changes in their own little branch ready to replay over the updated codebase later. But that's getting into funky territory.
That's what I thought when I tried, but the result wasn't what I expected and it still said there were conflicts. Maybe I didn't do it right.

Rebases are a bit trickier to work with at that level, aren't they?

Arantor

@d3vcho();
To be fair, for non-technical people, Git is fundamentally a disaster. It's obtuse and hard to use and a fundamental barrier to entry. I have yet to understand how GitHub actually got popular, because I have learned very firmly that while this stuff is trivial for me to deal with, it's really not trivial for others. I'm usually the one doing merge conflict resolution at work because it's *hard* and just casually dismissing the complaints of others because it's things we don't find difficult is a huge problem because we're delegitimising the concerns of others. It's the intellectual equivalent of 'works on my machine' - it works for me therefore I don't see why you have a problem. I'm trying to be less obnoxious about it with other people, but it's not entirely successful.

What we should probably be teaching people that, instead of making them deal with all the logical overheads that Git mandates, they could probably actually use an SVN client which for many people is an order of magnitude simpler to actually work with. (And yes, GitHub does actually support SVN clients as a front end)

Let me know the next time you explain Git, from scratch, to someone who has been developing for years without it and see how difficult you actually find getting them to understand it. Why make them have to understand it when they just want to get on and write code?


@Gwen rebases are... interesting. Essentially what you're saying is 'ok, I have a list of commits, each of which represents adding-some-lines, changing-some-lines, now I want to change the order of commits, and I want to make those two commits into one commit, and so on. You can do an awful lot with rebases, including merging branches by just including the commits from both branches in the right order, but doing it manually is effort, though if you have a good reason to keep your repo tidy, and you do it regularly, it's not so bad.

Gwenwyfar


Antechinus

Quote from: Illori on October 08, 2019, 05:08:05 AMyou actually dont need sourcetree or git anything to pull down the branch and test out the code... to make it easier for you as of when you click the link you can download all the files in branch from here

https://github.com/SychO9/SMF2.1/archive/antechinus.zip

you can then install and test it out.

Really? Damn. You mean there are files and stuff in the repo? With code n stuff in them? And a nice little folder full of things like intsall.php? I'd never realised. :P

Antechinus

Quote from: Arantor on October 08, 2019, 08:47:23 AMWhat we should probably be teaching people that, instead of making them deal with all the logical overheads that Git mandates, they could probably actually use an SVN client which for many people is an order of magnitude simpler to actually work with. (And yes, GitHub does actually support SVN clients as a front end)

Yep. The old Tortoise/svn/Mantis system was a piece of cake.

QuoteLet me know the next time you explain Git, from scratch, to someone who has been developing for years without it and see how difficult you actually find getting them to understand it. Why make them have to understand it when they just want to get on and write code?

Double yep. As some people may have noticed, I don't have a problem writing code. I just object to people who want to make it more difficult than it needs to be, given that I do it in my free time basically just because I like writing code sometimes.

GitHub was supposed to speed up development. Call me thick, but I haven't actually noticed that SMF dev is now a blazing fast process compared to how it used to be.

Diego Andrés

I'm digging the git terminal on visual studio right now it seems very responsive, and I use GitHub desktop too sometimes cuz been using it since it had a bad UI and always worked for me

SMF Tricks - Free & Premium Responsive Themes for SMF.

Bloc

Quote from: Antechinus on October 08, 2019, 02:19:53 PM
Quote from: Arantor on October 08, 2019, 08:47:23 AMWhat we should probably be teaching people that, instead of making them deal with all the logical overheads that Git mandates, they could probably actually use an SVN client which for many people is an order of magnitude simpler to actually work with. (And yes, GitHub does actually support SVN clients as a front end)

Yep. The old Tortoise/svn/Mantis system was a piece of cake.

QuoteLet me know the next time you explain Git, from scratch, to someone who has been developing for years without it and see how difficult you actually find getting them to understand it. Why make them have to understand it when they just want to get on and write code?

Double yep. As some people may have noticed, I don't have a problem writing code. I just object to people who want to make it more difficult than it needs to be, given that I do it in my free time basically just because I like writing code sometimes.

GitHub was supposed to speed up development. Call me thick, but I haven't actually noticed that SMF dev is now a blazing fast process compared to how it used to be.

Speed up development? Not so sure about that..but there are other advantages. I like the history thing, even branching though I don't use it that much. Being able to pluck out a time in history and use code from that..but still keep the most recent things, thats worth gold to me. :D

d3vcho

Quote from: Antechinus on October 08, 2019, 02:19:53 PM
GitHub was supposed to speed up development. Call me thick, but I haven't actually noticed that SMF dev is now a blazing fast process compared to how it used to be.

Of course not, but also the size of the team is not the same as it used to be. And apart for the speed, I believe that the quality of the code has improved since we use GitHub. Take 2.1 for example.
"Greeting Death as an old friend, they departed this life as equals"

Antechinus

Quote from: d3vcho(); on October 08, 2019, 02:43:54 PM
Quote from: Antechinus on October 08, 2019, 02:19:53 PM
GitHub was supposed to speed up development. Call me thick, but I haven't actually noticed that SMF dev is now a blazing fast process compared to how it used to be.

Of course not, but also the size of the team is not the same as it used to be. And apart for the speed, I believe that the quality of the code has improved since we use GitHub. Take 2.1 for example.

Well, the code has the benefit of an extra decade of development around the web as a whole, which is always going to be a significant factor. You would expect 2.1 to be more advanced.

Antechinus

Quote from: Bloc on October 08, 2019, 02:41:53 PMSpeed up development? Not so sure about that..but there are other advantages. I like the history thing, even branching though I don't use it that much. Being able to pluck out a time in history and use code from that..but still keep the most recent things, thats worth gold to me. :D

That was the original claim. Moving to GitHub was going to open up a new golden era of oodles of happy bunnies contributing megabytes of awesome code, thereby speeding up development to levels previously undreamt of. Hasn't exactly turned out that way. Which is not the fault of anyone contributing now, but is still an amusing contrast to the original claims (which I remember, having been there at the time).

Advertisement: