On: Git is too hard

[simiones]

As I said to the other commenter - I don't even know how to use git without the stash, since you need everytime when you have some local changes but want to pull from the remote - the only alternative I know of is committing your local changes instead of stashing them.

Also, git lfs and git submodules and their associated commands are necessary or not based on the project, not on your personal level of proficiency.

I also don't know of any workflow where you don't need to look at the log at least once every few days, even as a junior dev, to confirm if a bug is fixed in a build or not if for no other reason.

[bntyhntr → simiones]

At work I have 30 stashed things some of which go back 2 or 3 years. I got distracted when I pull and forget to pop sometimes, or I was working on something so trivial I never unstashed it.

That doesn't seem great... Usually these days I try to put my temporary work on a temp commit or branch at least so I don't lose it to the stash. I'm not saying I'm stashing properly, just that stash is easy to mess up.

Also probably half of these are things I popped but had merge conflicts or something. I fixed the merge conflict why is it still there? (I know the reason, but still).

[chokolad → simiones]

> As I said to the other commenter - I don't even know how to use git without the stash, since you need everytime when you have some local changes but want to pull from the remote - the only alternative I know of is committing your local changes instead of stashing them.

I usually do all the work in branches anyways, so I'll just create a quick branch and commit it there.

[JeremyNT → chokolad]

> I usually do all the work in branches anyways, so I'll just create a quick branch and commit it there.

I never work on a checked-out version of a branch that's currently being updated. I always check out a new branch for my work and rebase or merge off the branch others are working on.

I'm fully aware of stash, and every now and then I use it, but it's pretty infrequent. Seeing as you need to learn branching anyway it's not going to be important for every workflow.

[kubanczyk → JeremyNT]

Exactly. For some busy repos I tend to remove local master (and develop) branches altogether. It's less moving parts that way.

    git branch feature1 origin/master   # create
    ...
    git fetch --all
    git rebase -i origin/master feature1

Also, use emacs's magit as a better ui. Even if you don't use emacs, seriously. It's fantastically easy and fast.

[lhnz → simiones]

I've used both but generally don't use stash. I think it's more expressive to have a single commit like "wip: some simple description goes here" and then to `git commit --amend` this until we are happy with its contents.

As well as being more descriptive if you come back after a long weekend, this also means that you can swap branches without worrying that your stash relates to a particular branch but doesn't explicitly belong to this.

[wool_gather → lhnz]

Tip, instead of amending, it's also straightforward to "uncommit" a temporary commit when you come back to it. `git reset HEAD~` and the state of the commit becomes the state of your working tree instead.

[kelnos → simiones]

You can set `merge.autostash` and/or `rebase.autostash` to `true` in your global git config and then you can `git pull` with a dirty working tree.

Of course, to the point of this thread, that is yet another concept you have to understand to get a sane working environment. I assume autostash is disabled by default because the post-merge/rebase unstash could result merge conflicts and be a pain to unwind if you change your mind. If you just blindly set this option based on someone else's recommendation without knowing what the stash is, and things go wrong, you'll require a mental model of the steps involved to fix it, which you won't have.

[pdimitar → kelnos]

That's one more confusion vector. I for example use Git for like 10 years now and I didn't know about this option. It didn't even occur to me that it could exist.

So basically, I am proving the article's point.

[anotherNae → simiones]

It might help creating patches for the dirty state with something like `git diff > feature.patch` and then drop the current changes. After update, it's another `git apply feature.patch` to restore the changes. This helps with remembering what each change means since `git stash show` is rather awful. YMMV

[kernelbugs → simiones]

Could you not perhaps git fetch && git rebase origin/master (for instance, to pull remote changes into a local development branch)?

[simiones → kernelbugs]

git fetch && git rebase origin/master, which is equivalent to git pull --rebase origin master, requires your worktree to be clean, so you must either commit or stash if you have any local changes.

[simfoo → simiones]

    git config rebase.autoStash true

[renox → simfoo]

I think that's a very good way to have a long list of things stashed that you don't remember what they are. Commiting your changes is much better as you can add an explanation for your futur self.

[simfoo → renox]

Well it does auto-pop the stash as well if the rebase was successful. I've been using it for ages and never noticed a growing stash

[OJFord → simiones]

Autostash

[simiones → OJFord]

Ok, so you don't need to know git stash (good) but you need to know that autostash exists and how to configure it, so you still don't get away without an extra concept. I suppose the nice part about autostash is that it's easier for someone to just give you a .gitconfig with it, and not have to teach you how to use git stash.

[JoshTriplett → simiones]

You still need to know how to use git stash, in case the stash doesn't cleanly apply after the pull.

[OJFord → simiones]

The `.gitconfig` and also be 'given' to you by just being checked into the project. Someone has to know that you can have per-repo configs, but not everyone. ;)