• Forum
  • Lounge
  • We should use different names for Git br

 
We should use different names for Git branches

"Main" implies there's a hierarchy and that some branches are better than others. We need to eliminate branchism from language. I instead propose names with no intrinsic hierarchy or connotation: vertical, horizontal, lateral, diagonal, etc. Projects that need lots of branches may use a software I will design that will deterministically translate a bit string into a textual description of a monkey wearing any selection of a variety of facial expressions, hats, glasses, and miscellaneous accessories.

Of course, since we aim to eliminate hierarchy, the branches themselves should also be meaningless. Ideally each commit should create a new branch always. We can merge branches, but we should always fast-forward both branches to the latest commit on the DAG, otherwise we're implying a hierarchy between the branch that isn't fast-forwarded and the one that is, and we wouldn't want to offend any branches.

You will finally be able to say
I've pushed the snafucator to 'monkey with a van dyke and liberty spikes, sticking out tongue and winking left eye, wearing pink lipstick, geordie visor, a black t-shirt, and rainbow bow tie'. When you get the chance merge it with 'monkey with cornrows, biting upper lip, wearing blue lipstick that ran onto its right cheek, a monocle, a green shirt, and a parachute'.
secure in the knowledge that no one could possibly be offended.







Alternatively let's just go with "slavemaster" and "actual-slave-being-actually-whipped-development", "actual-slave-being-actually-whipped-v1.2.3", and so on. Also, any time branches are merged, someone has to suck someone off. No more pussy-footing around, let's give people actual reasons to get offended.
I'm still learning how to use git so my repos on github are "factory default".

I'd like to create repos that have released sections, etc, as I see with other repos by more experienced git users.

For that matter I'd like to get more comfortable about using git as a version control setup. I know it can, I just haven't delved that deep into what git can (and can't do.) I still haven't really stuck my nose and brain into the "Pro Git, 2nd Edition" eBook as I know I should.

https://git-scm.com/book/en/v2

Learning git commands for me is almost as intimidating and daunting as learning a programming language such as C++ or WinAPI.

I guess I'm just plain lazy.

I can't recommend Git Extensions enough. It makes Git actually usable without having to learn its nonsensical console UI, as long as you understand the underlying data model. Ultimately pretty much any complex operation on Git is going to be some directed acyclic graph walk between two nodes. Excluding commits, I'd say 99% of what I do with Git is just resets, rebases, merges, cherry picks, and stashes. If you understand what each does to the DAG, your position on it, and to your current working copy, you can do anything.
I'll have to bookmark Git Extensions for looking at later, thanks for the recommendations.

I use Git For Windows, it has a Bash console interface and a GUI. I use the Bash interface to clone a repo not my own and pull any updates. I use the GUI to push changes I make locally on my HD to my few github repos.

Sure, not all I could be doing, but at this point it works for me.
Topic archived. No new replies allowed.