Emoji request: :tiphat:

That is so intuitive. Like when you want to edit a Wikipedia article, so you download the entire Wikipedia database, edit that article, then ask Wikipedia to pull the changes from your computer.

Yamikuronue

@anonymous234 Github is really the wrong tool for this sort of thing, but it's the tool boomzilla is choosing to use so

izzion

@anonymous234
Well, technically, it would be more like downloading just the collection of articles that article is in.

boomzilla

@Yamikuronue said in Emoji request: :

@anonymous234 Github is really the wrong tool for this sort of thing, but it's the tool boomzilla is choosing to use so

I mean...it is and it isn't. I think it's partly due to how @ben_lubar has everything set up with docker, plus the nature of nodebb, where these things end up living inside a plugin, not as just a directory of images. It would be nicer if we could just upload these things in the admin panel, like discourse did, but that doesn't seem to work with the way the nodebb plugins work.

ben_lubar

@Yamikuronue said in Emoji request: :

@loopback0 said in Emoji request: :

I'll sort out a PR later when I'm at home.

For future reference:

Log into Github

Click the "~~Clone~~Fork" button on the original repo

Upload your file in your copy

Click the "Create Pull Request" button in your copy

Double-check that it's actually sending it to the upstream original version

Type a smart-ass comment and click "submit"

You can upload files to the web interface. No need to download anything. (Other than ically downloading webpages so you can view them.)

loopback0

@Yamikuronue said in Emoji request: :

For future reference:

Yeah, I know, just required not being at work.

Yamikuronue

@ben_lubar I didn't say to download anything, so there you go.

A fork is just a special type of clone, but ry accepted

masonwheeler

@Yamikuronue said in Emoji request: :

@anonymous234 Git~~hub~~ is really the wrong tool for ~~this sort of~~prety much anything, but it's the tool boomzilla is choosing to use so

FTFY

RaceProUK

@masonwheeler Not true: git's the right tool to use if you want a cryptic DVCS ;)

loopback0

@RaceProUK said in Emoji request: :

@masonwheeler Not true: git's the right tool to use if you want a cryptic DVCS ;)

Git is the right tool to use if, and only if, you want the software equivalent of punching yourself in the face repeatedly.

hungrier

@loopback0 said in Emoji request: :

punching yourself in the face

git reset --hard HEAD

anotherusername

I don't like . Can we have it be :hat_tip: instead? :hat_tip:

masonwheeler

@hungrier said in Emoji request: :

git reset --hard HEAD

Even worse is when you end up with a Disconnected Head. (Yes, this is a real git thing, from a VCS that acts like a real git.)

asdf

@masonwheeler said in Emoji request: :

Disconnected Head. (Yes, this is a real git thing

No, it's not. Detached HEADs, however, are a git thing.

Also, there's nothing bad about a detached HEAD. The only problem with that state is that git doesn't explain what it means.

Jaloopa

@asdf said in Emoji request: :

git doesn't explain what it means

How does that differ from anything else in git?

asdf

@Jaloopa said in Emoji request: :

How does that differ from anything else in git?

It doesn't. Just wanted to clarify that the concept itself is sane, it's just named weirdly. Despite claims to the contrary, git is actually pretty well-designed, it's just not user-friendly.

Jaloopa

@asdf so what is a detached head, and what would be a similar concept in, say, TFS?

asdf

@Jaloopa
I don't know TFS, but "detached HEAD" simply means that you checked out an old commit which is not the latest commit in its branch. You're looking at historical information, so you have to either create a new branch from there or go back to the latest commit before you can check in new code.

"History mode" might have been a better name for that state.

Edit: In case you want a more lengthy explanation:

What's a "detached HEAD" in Git?

NedFodder

@anotherusername said in Emoji request: :

I don't like . Can we have it be :hat_tip: instead? :hat_tip:

TRWTF would be having both and :hat_tip: with different glyphs.

Zecc

@jaloopa1

A git repo is a soup of blobs identified and retrievable by their SHA-1. Among these are your commits (aka revisions).

A branch is a pointer to a revision inside this soup. It is literally a file inside .git/refs/heads/ named after your branch name and containing the hash of the branch's latest commit.

The current, checked out head is also a file, .git/HEAD.

Normally you have a branch checked out and .git/HEAD contains something like ref: refs/heads/mybranchname. Your head is not detached.
In this situation git knows which branch you're in and what its latest commit is. When you add a new commit, .git/HEAD remains the same and .git/refs/heads/mybranchname is updated with the latest hash.

But sometimes, either directly or indirectly git can be told to check out a certain revision rather than a branch. In this case .git/HEAD will instead contain the SHA-1 of the revision you've checked out. Your head in now detached. There is no corresponding file in .git/refs/heads/.

With a detached head, you can still commit more revisions to your heart's content, they will be added to the repo and git/HEADwill be updated accordingly. But your detached head is only working like a temporary branch of sorts. There is no backing branch. If you check out anything else your commits are lost. Not "gone" lost, but "lost" lost. They're still in there somewhere, assuming the repo hasn't been GCed yet, you just don't know how to find them.
If you can still remember the hash of the latest commit (psst! "git reflog"!) you can still check it out again or create a branch pointing at it.

Edit: I've used the nouns "commit" and "revision" interchangeably. Blame it on git terminology.

RaceProUK

@Zecc said in Emoji request: :

git reflog

TIL git likes to indulge in a bit of S&M.

What? What do you mean, it's actually for the reference log?

Jaloopa

@RaceProUK said in Emoji request: :

What do you mean, it's actually for the reference log?

TIL. I've always read it as "flog again" and just assumed it was another weird Gitism that I'll hopefully never have to learn if I can stay with TFS/SVN etc.

asdf

@Jaloopa said in Emoji request: :

another weird Gitism that I'll hopefully never have to learn if I can stay with TFS/SVN etc.

Here, you forgot something:

Zecc

@Jaloopa I keep wanting to try Fossil, but I never do.

RaceProUK

@Zecc I must admit, I'm a little curious why they named it after something really old.

masonwheeler

@asdf said in Emoji request: :

Despite claims to the contrary, git is actually pretty well-designed, it's just not user-friendly.

Yeah, that's where we have a problem. The way I see it, that's inherently a contradiction.

asdf

@masonwheeler said in Emoji request: :

@asdf said in Emoji request: :

Despite claims to the contrary, git is actually pretty well-designed, it's just not user-friendly.

Yeah, that's where we have a problem. The way I see it, that's inherently a contradiction.

Let's not get into an argument about terminology and definitions. You know what I was trying to say.

Yamikuronue

@masonwheeler Functional Suitability and Usability are two separate aspects of Quality. They are not the only two, but they are actually distinct from each other.

masonwheeler

@Yamikuronue I disagree. If people can't figure out how to make it work, it's not suitable for the function they're trying (and failing) to use it for.

One of the more dramatic illustrations:

Ronco Spray-On Usability

Eric Raymond figures out that desktop Linux software sucks.

Yamikuronue

@masonwheeler I don't disagree with anything in the article. But they are separate. Open source linux devs love to crow about how much "better" their tools are because they're more performant (another aspect of quality), or do more things (functional suitability), or are more reliable (yet another aspect). But they're crap to use, and that ends up having more weight in the overall summation of quality.

For example, vi.

asdf

@masonwheeler said in Emoji request: :

If people can't figure out how to make it work, it's not suitable for the function they're trying (and failing) to use it for.

You're arguing against a straw man. Nobody claimed that usability is not important. You can still judge functionality and usability independently.

All I was arguing was that the core functionality of git is well-designed, but not exposed in a usable manner.

Yamikuronue

@asdf Which is usually better than having both be crap, because you can come along and fix it ^_^

I'm enjoying using SourceTree lately, it seems much easier for beginners than the command line (protip: NEVER send new users to the command line. It's never going to be easier to teach the concepts with pure text than it is with text and graphics. Once they understand the software, they may choose to go to the command line, but everyone's new at some point.)

masonwheeler

@asdf said in Emoji request: :

All I was arguing was that the core functionality of git is well-designed, but not exposed in a usable manner.

I don't particularly agree on that either. It makes the classic design mistake of making the most common operations extra difficult in order to make far less common operations easier. And that's just dumb no matter which way you slice it.

masonwheeler

@Yamikuronue said in Emoji request: :

protip: NEVER send new users to the command line.

I'd go one step further, in fact. If the user needs to know that a command line exists in order to manually do anything in your software, it's broken.

( note: Please read that exactly as written, and don't interpret it as me having said anything about command lines that I did not actually say.)

Yamikuronue

@masonwheeler I agree ^_^ The command line should be an option for people who like it, not a necessity.

asdf

@masonwheeler said in Emoji request: :

It makes the classic design mistake of making the most common operations extra difficult in order to make far less common operations easier.

I disagree. Nothing about the git internals requires that. IMO, guiding the user to the most likely/common operations would be the UI's job. Which, as we all agree, sucks.

masonwheeler

@asdf OK. To you, what are the two most common, most fundamental operations in source control?

asdf

@Yamikuronue said in Emoji request: :

I'm enjoying using SourceTree lately,

IntelliJ also does a great job at exposing git's functionality in a usable manner. I still don't know how to quickly open a certain revision of a file on the command line, but doing that via IntelliJ requires two clicks.