More stupid Git errors THIS TIME IN FIRST-PERSON!

JBert

Why @blakeyrat was running a script named git-rebase.sh, I have no idea.

Because he ran git rebase in some way or another and because that's the way git subcommands work?

When you run git parp, the git wrapper will actually look for a command git-parp in the git exec path or even your full $PATH. Adding stuff to git thus means that you don't need to modify the core git executable, you just make extra scripts and git will run them when it can find them.

References:

How to create a plugin (unoffical)
How to integrate new subcommands (official, technical details)

@Gaska said:

If you make any mistake, you can always git reset --hard $hash_of_commit_you_want_to_start_over_with.

Do keep in mind that it is a very unsafe command. --hard really is an "I know what I'm doing and won't regret it" parameter, it will happily blow away any local modifications you haven't committed yet as well as any recent commits. As you say you can recover the latter by looking through the reflog (basically a history table of what branch pointers you modified recently) but you can not recover something which was never committed in the first place.

If you need to give advice, please point to the flowchart in this article because it will at least try to assess the scope of the problem:
http://justinhileman.info/article/git-pretty/

I actually noticed it was already posted on these forums when looking it up.

Gąska

@JBert said:

Do keep in mind that it is a very unsafe command.

Not more unsafe than whatever you just did that requires hard reset. As long as you're resetting to a commit that belongs to the same branch, there shouldn't be any problems.

@JBert said:

you can not recover something which was never committed in the first place.

If you haven't commited/stashed it, it must have been not important.

ben_lubar

@ben_lubar said:

@blakeyrat was running a script named git-rebase.sh

@JBert said:

Because he ran git rebase

@blakeyrat said:

I wasn't.

Post can't be empty.

sloosecannon

@JBert said:

http://justinhileman.info/article/git-pretty/

+∞!

How have I not seen that before That is wonderful, glorious, and awesome

dse

We use git-flow here, this feature-branch model works fine with it, for clear-cut features or bugfixes. But the problem is most of the time there is no good and clear feature I am working on, but rather just everything from bugfix to new features and really exploration of ideas.
The nice thing about git-flow model is everyone pushes to develop (with unspoken policy of keeping is semi-working) but it is master that needs definitely working code.

hifi

git pull is one of those things that even git trainers try to tell people to avoid. Because it unconditionally does something destructive even with --rebase it's very dangerous/annoying to use when you are not in a clean state. It's one of the bad things you learn and makes you hate git even more because it fucks things up when you pull.

Instead I git fetch --all and actually review the situation by checking what changes others have done and decide after what to do. You can do that even if your working state isn't clean (uncommitted changes) and you can use git log and git show to start reading the commits you fetched while still being in whatever state you were to begin with.

Most of the time when I fetch others work it has nothing to do with what I'm doing (different sources files and stuff) so I can safely postpone rebasing/merging until my feature is complete and only at that point do it after fetching all of the latest changes. If the changes do affect possibly causing a merge conflict I might commit my working state and then rebase it to solve conflicts early on making the final rebase as easy as possible.

When working on your feature and you don't like to make 100 commits you can always git commit --amend after your first commit and your new changes can be piled up in the one big commit you want to push later on. Others make 100 commits and squash them later on with rebase. Pick your poison.

I don't think the behavior of for example Subversion is the best possible where svn up fucks up your working copy anyway and even requires that for you to collaborate with anyone in the same branch. It makes you postpone reviewing and fixing merge issues possibly so long it'll become really hard and annoying in the end when you need to deal with it.

It all comes down to what workflow suits you the best: solve problems early and keep your code up-to-date with others or ignore others until your work is done and do a big merge when you're finished.

xaade

@accalia said:

well at least it's being polite

"Existing rebase detected. Continue?"

Instead of

"Your mom called, she has your keys. Do you want me to call a taxi?"

Oh, and if you really like polite software, then you're doing it wrong.

Go learn this language.

INTERCAL - Wikipedia

EvanED

@Buddy said:

That just sounds like you're spending more time committing stuff to source control than I'd ever want to. I mean, I realize how half-ass that might make me sound, like I don't give a shit about my commit history, but I just haven't yet actually run into a scenario where that level of anal retention would have come in handy.

That's actually not unreasonable; I have on occasion spent way too much time getting a nice history. But, a nice history also means a nice thing to show your reviewer. Instead of dumping a bunch of somewhat half-assed patches on a reviewer, you can give them actual, high-quality, self-contained patches that do one thing, even if you didn't come to the final solution in a way that would have led you directly there.

All in all it somewhat comes down to how much you view your VCS as being an artifact in and of itself rather than just a container of the code. The more you see it the former way, the more Git and Mercurial stand head and shoulders above just about anything else. And having a nice history is nice -- it makes figuring out why things are as they are easier, it makes tracking how the code changes over time easier, it makes reviewing easier, etc. Is it worth the extra time? Usually I think so, though sometimes I have doubts...

EvanED

@tar said:

What conventions?

Git devs don't say "what conventions?"

They pay very careful attention to the conventions, both used by other VCS tools and Git itself. Otherwise they wouldn't be able to disregard them!

EvanED

@tar said:

I mean, that's how every source control I've used has worked.

To be fair, almost every other source control's update operation is broken. Git makes the common case a little more annoying (is git stash; git pull; git stash pop really that hard?) in exchange for removing the following failure mode, which is extremely obnoxious to deal with on the rare occasion it arises:

svn up
Get a conflict
Get another conflict
Decide that you don't want to deal with these conflicts at this exact moment and want to go back to the state of your working copy before you did the update
Punch your computer monitor in annoyance (or complain on TDWTF) because there's no way to do this in Subversion unless you know the revision you're coming from (which, because it is really easy to wind up with different files with different revisions just by committing, is basically impossible), in which case it's merely really really annoying

Under Git, step 4 is trivial to do because the thing that is being merged has a name and you can just go to it.

tar

@hifi said:

git pull is one of those things that even git trainers try to tell people to avoid.

...and guess what I've been using to keep my repos in sync across 2-3 local PCs and github. Is it because I'm the only committer that this hasn't blown up in my face?

Off to read about git fetch, I guess...

Filed under: Harry Git and the Night of a Thousand Verbs

lightsoff

Fetch is what you're supposed to do.

git gui even offers fetch in the menu.

Note that fetch only copies all remote changes into your local repo, it doesn't change any of your files or even branches, so you will then need to choose how far to go forward - if at all.

hifi

@tar said:

Is it because I'm the only committer that this hasn't blown up in my face?

Pretty much.

When you know the state of your remote and you always push your commits and you always pull before you start working on something in one of the clones you will always have a situation where git will fast-forward your commits from remote on top of your local branch and nothing will break.

If you forget to push some commits or your working directory is dirty when you pull you can cause the same problems. Of course they are not problems if your workflow is adapted to that.

The "problem" of working with other people is that you don't know the state of your remotes until you pull/fetch so it's safer to always fetch and figure out what to do after that rather than pull and let git fuck up something. For most cases git pull --rebase is the better choice than plain pulling if you don't want to just fetch.

Gąska

@hifi said:

If you forget to push some commits or your working directory is dirty when you pull you can cause the same problems. Of course they are not problems if your workflow is adapted to that.

AFAIK it's impossible to pull with dirty working directory?

hifi

@Gaska said:

@hifi said:
If you forget to push some commits or your working directory is dirty when you pull you can cause the same problems. Of course they are not problems if your workflow is adapted to that.

AFAIK it's impossible to pull with dirty working directory?

It still does fetch though but aborts rebase or merge IIRC. I don't do that so I can't say for sure but it's still not very wise to even attempt.

Gąska

Sorry, but I can't see how it can fuck you up in this case. Conflicts with unpushed commits - yes (though you have to deal with them anyway at some point); but dirty working dir will never break a pull because it won't be completed, right?

JBert

@hifi said:

Instead I git fetch --all and actually review the situation by checking what changes others have done and decide after what to do. You can do that even if your working state isn't clean (uncommitted changes) and you can use git log and git show to start reading the commits you fetched while still being in whatever state you were to begin with.

I actually put these aliases in my .bashrc (there are more, but they're mostly shortcuts):

alias "gitff=git pull --ff-only"
alias "gitfa=git fetch --all"

At worst gitff does a git fetch and fails once it tries to execute git merge --ff-only, at best it actually forwards my branch to the latest version.

Footnote: for those who love git aliases, please go read a git hacker koan and then it's explanation.

hifi

@Gaska said:

Sorry, but I can't see how it can fuck you up in this case. Conflicts with unpushed commits - yes (though you have to deal with them anyway at some point); but dirty working dir will never break a pull because it won't be completed, right?

In that particular case it might not, but if you have committed changes then the merge and possible conflict can cause you headache if you didn't want that to happen just yet. My point was to mostly use fetching instead of pulling if you want to avoid any immediate mess.

JBert

@ben_lubar said:

@ben_lubar said:
@blakeyrat was running a script named git-rebase.sh

@JBert said:
Because he ran git rebase

@blakeyrat said:
I wasn't.

Post can't be empty.

You've quoted selectively. I said "he ran git rebase in some way or another".

It's shown here:
@blakeyrat said:

More rebasing fun and joy:

git -c diff.mnemonicprefix=false -c core.quotepath=false -c "sequence.editor='C:\Program Files (x86)\Atlassian\SourceTree\stree_gri'" -c "core.editor='C:\Program Files (x86)\Atlassian\SourceTree\stree_gri'" rebase -i --autosquash XRebasing (1/3)

I don't know where you were going with this, so have fun.

Gąska

...I just realized that this git-rebase.sh is actually part of official git client. Also, that significant part of git is written in shell scripts. Huh.

hifi

@Gaska said:

...I just realized that this git-rebase.sh is actually part of official git client. Also, that significant part of git is written in shell scripts. Huh.

Some of the more complex parts are in Perl, hence the dependency on it.

At least Microsoft is doing the right thing and using libgit2 while also contributing to it. You just don't wrap a GUI around the CLI...

Buddy

git-up(1) - fetch and rebase all locally-tracked remote branches

Buddy

Git isn't hard, it's just obscure and poorly documented. Finding out how to do something with git means going on a magical treasure hunt through a thousand poorly written man pages. Even if you are able to articulate your problem well enough to get a relevant stackoverflow hit, you're going to be taking advice from the type of people who would tell you to do a reset --hard when a checkout . or a clean would have sufficed. Because when you get right down to it, even the supposed experts don't know half of what there is to know about git; the only feasible way to use it the cargo cult way, unless you're willing to let checking shit into repos become your entire life.

Gąska

@Buddy said:

thousand poorly written man pages

Still better than sudoers.

Buddy

Sudo - ArchWiki

Looks clear enough to me.

gleemonk

@Buddy said:

GIT stash is pretty great, though.

Yeah, I use it to get rid of changes I'm uncommitted about. Whenever I have a dirty repo with changes I thought might be 'useful', I just go git stash when I can't get myself to get rid of them outright. Then at some point I delete all the stashed shit. Saves me from having to admit right away that the current diff must have been the work of a lunatic.

Other than that I haven't kept anything in a stash for extended periods of time.

@blakeyrat said:

In TFS, your stash is on the server and you can pull it down from anywhere. Git's feature is a piece of shit by comparison.

Can't say I'd ever wished to access form another host my grab-bag of random stupid shit. If I think that some change could possibly have merit, I put it into a branch then push that. I'd welcome a more lightweight way of branch management in Git though. I mean the push/pull part, not the local operations.

Gąska

@Buddy said:

Looks clear enough to me.

Now, enter man sudoers in terminal and try to make sense of it.

blakeyrat

@EvanED said:

The more you see it the former way, the more Git and Mercurial stand head and shoulders above just about anything else.

Is that because they're horrible mutilated Frankenstein monsters?

blakeyrat

@EvanED said:

Git makes the common case a little more annoying (is git stash; git pull; git stash pop really that hard?)

Yes.

blakeyrat

Look this whole discussion here? This is why Git sucks.

If Git were any good, there would be no need for this discussion because 1) it would be self-explanatory, and 2) it would do the right thing BY DEFAULT.

If you have to write 4374623 paragraphs on how to bring in changes from the server, it's a shitty SCM.

blakeyrat

@hifi said:

You just don't wrap a GUI around the CLI...

People who write Git tools do!

Because people who write open source software are always shitty at software! Actually I don't think SourceTree is even open source, so as an added bonus you get the shittiness without the source! Exclamation marks!

blakeyrat

@Buddy said:

Git isn't hard, it's just obscure and poorly documented.

"Git isn't hard, it's just {property that makes it hard} and {other property that makes it hard}."

@Buddy said:

Finding out how to do something with git means going on a magical treasure hunt through a thousand poorly written man pages.

Gee, it's almost as if that's hard to do.

@Buddy said:

Because when you get right down to it, even the supposed experts don't know half of what there is to know about git;

I wonder if that's because it's hard? Nah, you said it's not hard in your first sentence. You wouldn't write a post that instantly contradicts its first sentence. That would be ridiculous.

ChrisH

@Buddy said:

Ok, VS also has a git client baked in, so I'm not sure what the problem is there.

It does? Bloody hell.

More importantly, are you saying you not only disregard the people who work for you's preferences for how they collaborate with each other

What? Yes, of course I disregard "the preferences how they collaborate" if said preferences would violate our written policies. Anybody who wouldn't is a fucking liar or only writes unimportant toy applications.

but you actually go in and set rules about what they can and can't do on their own machines?

Umm... yes? They are not "their own machines" to start with.

Did you know that the most common complaint about team fortress is that the main people who like it are micromanaging fucktards who want to lock down everyone's access to everything?

No, I didn't. What the fuck are you talking about?

hifi

@blakeyrat said:

If Git were any good, there would be no need for this discussion because 1) it would be self-explanatory, and 2) it would do the right thing BY DEFAULT.

Definitely. Now go learn the quirks and workflows so you can do your job as you've been forced to use git.

blakeyrat

@ChrisH said:

It does? Bloody hell.

Hey the timepod's back! Welcome from 4 years ago.

@hifi said:

Definitely. Now go learn the quirks and workflows so you can do your job as you've been forced to use git.

No. Fuck it and fuck you.

I use Git well enough to stay employed and better than half my co-workers. I also complain about it being shitty. THESE TWO THINGS ARE NOT MUTUALLY-EXCLUSIVE.

hifi

@blakeyrat said:

@hifi said:
You just don't wrap a GUI around the CLI...

People who write Git tools do!

They are stupid. We can agree on that, right?

@blakeyrat said:

Because people who write open source software are always shitty at software! Actually I don't think SourceTree is even open source, so as an added bonus you get the shittiness without the source! Exclamation marks!

Open source user interfaces are usually utter shit. Git CLI goes in that category.

Gąska

@blakeyrat said:

"Git isn't hard, it's just {property that makes it hard} and {other property that makes it hard}."

Define "hard".

blakeyrat

Buddy's the one who said it, ask him.

blakeyrat

@hifi said:

Open source user interfaces are usually utter shit.

But open source is so awesome and great and will solve all software problems and bring along world peace and OMG it's like angels singing to use an open source project!

hifi

@blakeyrat said:

No. Fuck it and fuck you.

I think we'd get along just fine. Now go read Pro Git.

@blakeyrat said:

I use Git well enough to stay employed and better than half my co-workers. I also complain about it being shitty. THESE TWO THINGS ARE NOT MUTUALLY-EXCLUSIVE.

Oh god, there are WORSE git users than you?

blakeyrat

@hifi said:

I think we'd get along just fine. Now go read Pro Git.

No.

If I need to read a book to use a piece of software, that software it horribly flawed. That's the software's problem, not the user's.

@hifi said:

Oh god, there are WORSE git users than you?

The only difference is that I retain the self-awareness of how shitty everything in this tool is.

Most people (at least: Linux users) get used to the shittiness, start considering that "the new normal" and stop complaining. The worst of those get used to the shittiness, get some form of Stockholm Syndrome, and start actually promoting the product as good!

Fuck that noise. If I have to use shitty software, I'm going to criticize it.

Gąska

@blakeyrat said:

Buddy's the one who said it, ask him.

You're the one disagreeing on git's hardness. I just want for everyone to be on the same page, otherwise the discussion doesn't make the least lick of sense.

@blakeyrat said:

But open source is so awesome and great and will solve all software problems and bring along world peace and OMG it's like angels singing to use an open source project!

Said no one ever. At least on this forum.

@blakeyrat said:

If I need to read a book to use a piece of software, that software it horribly flawed.

I have no words for this.

hifi

@blakeyrat said:

Most people (at least: Linux users) get used to the shittiness, start considering that "the new normal" and stop complaining. The worst of those get used to the shittiness, get some form of Stockholm Syndrome, and start actually promoting the product as good!

I've heard people defend the Modern UI of Windows 8 or whatever it was finally called.

@blakeyrat said:

Fuck that noise. If I have to use shitty software, I'm going to criticize it.

Criticize it for the right reasons and I'm with you. Criticizing git because SourceTree is crap is the wrong reasons. Criticizing it because you don't know how to use it goes right in the same category.

I can do this too: "If I need to read a book to use a programming language, that language is horribly flawed.".

charlieda

"If I need to read a book on how to use this hammer, the hammer is horribly flawed" is different from "If I need to read a book about building a house, the process of building houses is flawed". For a start, one of them is sensible, and one is insanity.

It's like the original thread about the introduction of Dropbox - tonnes of people saying how it could already be done. Yes, it could already be done, but dropbox makes it easy, and that's why it's better. The same applies here - git is so difficult to start off with, and continues to demonstrate flaw after flaw. Yes, it does work, but it could work in a way that's much more easy to use.

Are people in this thread genuinely trying to say that git is a well rounded, easy to use product?

Gąska

I had to read a manual for my car to know how to replace lightbulb. Does it mean my car is horribly flawed?

Yamikuronue

Yes. Cars are intentionally hard for the casual consumer to maintain so they'll pay the dealerships for service.

gleemonk

@blakeyrat said:

If I need to read a book to use a piece of software, that software it horribly flawed. That's the software's problem, not the user's.

I know this is an alien perspective to you, but to me you sound like a tourist complaining about the natives not responding to your pictograms as you think they should. They're not adapting to you, and they're using a strange way of communicating with letters you shouldn't be suffered to learn, and the pictograms the tourist guide gave you are shitty.

No wonder you get irritated when Git strikes a conversational tone. When I work with Git, it is a dialogue.

Hey git, what am I doing?
Well you're in the process of committing (file1) with some changes not yet ready, and you have something in (file2).

What's not ready in (file1)?
(some diff)

Trash that
And what about file2?
(some diff)

Lemme selectively add some stuff
You wanna add (some diff)?
No
You wanna add (some other diff)?
Yes
You wanna add (that diff)?
Yes

Just let me peruse all the changes I'm intent on recording
(long diff)

Record these changes as "broken shit now wors"
No wait "broken shit now works"
What's left?
(some diff)
Trash that

Now I didn't add all the instances where Git was being an obtuse idiot. Wouldn't make a good example, would it? At some point I might just start swearing at the git. Of course sometimes I have to concentrate to say the right things, even look it up.

But it's all dialogue, and I like that because when my mind has wandered I can always look at the last things that were said, and I'm right back. Sometimes I replay my last changes in the editor just to recover the thought process where I got stuck. Then this guy comes along and asks, "how do I buttons?" and I can't imagine how he even works when he can't talk to things.

Gąska

@Yamikuronue said:

Yes. Cars are intentionally hard for the casual consumer to maintain so they'll pay the dealerships for service.

It wasn't actually that hard - but without reading the manual, I wouldn't know how to do it anyway.

My point is, not everything should be braindead simple, because in some situation we can safely assume the user has some specialist knowledge about the subject. Git is one of those things - like every other piece of software used by programmers.

tarunik

@blakeyrat said:

If I need to read a book to use a piece of software, that software it horribly flawed. That's the software's problem, not the user's.

throws @blakeyrat at the computer-aided dispatching console for a track warrant territory Have fun!

No amount of UI will help you if you aren't willing to understand the concepts of what you're working with. I'm not sure what it is about you and certain systems -- but your expectation that everything should fit into the same concept-set that you already know isn't a good one. (I'd love to see you spend a few thousand hours flying fixed-wing aircraft and then go off and get some helicopter lessons...)

sloosecannon

@tarunik said:

I'd love to see you spend a few thousand hours flying fixed-wing aircraft and then go off and get some helicopter lessons...

Not only would that not help, it would probably make it worse. Yikes. Flying rotorcraft is funky...