Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git is too hard

changelog.com

Post reply on HN
Print view View original

721–730 of 821 posts

Re: Git is too hard

#721

Post by kubanczyk »

Spivak wrote: post #607
horsawlarway wrote: post #460

Earlier quoted context omitted.

I think you're twisting the problem statement a little here. Asking "How do I unsend an email" is just as unreasonable as asking "Hey, give me that gift I gave you back". The problem is that, regardless of your intent, you've given something to someone and they own it now. You can't undo that without involving the 3rd party (Or breaking the law and stealing it, digitally for the email). And I want to be clear upfront…

I think you're missing the forest for the trees here. The point of version control systems is to make developing software easier. It's a tool that exists for the convenience of its users. It's reasonable for people developing software to ask for the ability undo a change or restore a repository to the way it was a second ago. Telling a team of people using Git "it doesn't work like that" is unhelpful because it's not…

The trees are brutal here. Someone pushed the code a minute ago, but I've fetched it already and now I'm editing the same source file.

If you take it away from me, or make me later inadvertently push their code, you are inconveniencing an innocent person.

Re: Git is too hard

#722

Post by kubanczyk »

nicoburns wrote: post #245
whizzter wrote: post #209

Earlier quoted context omitted.

Oh hell no, Visual Studio has this behaviour by default (commit all changes if nothing staged) and what we end up with is that some people keep checking in various experiments and privately modified launch config files (that should not be in the repo anyhow but that's another story related to the tools) that end up causing a lot of unnecessary merge conflicts when you pull in their changes (where you were really only…

We deal with this via code review. Anything with such files is going to get instantly rejected. And people soon learn not to do it.

We prefer to automate everything that's automatable, and then a bit more, because reviewing is hard work.

Re: Git is too hard

#723

Post by dahart »

simiones wrote: post #704
dahart wrote: post #669

Earlier quoted context omitted.

It might be worth really picking apart why you think you need to stash instead of commit, and why stash feels easier. I honestly don’t think committing is any more work than stashing at all, not even more typing. It’s really not more difficult to commit what you have temporarily, go to another branch to work, then come back and continue working, compared to stash. But I don’t doubt that it feels more difficult for so…

I think it's primarily a question of focus: I want to pull or to switch a branch. The fact that I have to do something like committing or stashing is already an annoyance - having to come up with a commit message is even worse. Perhaps I will give this commit/reset workflow a try as well, to see how it feels. It may also be that committing still feels to much like "an event" for me, from my P4 days.

You can, if you want, git fetch without committing or stashing, and then checkout just the files you want to update in your work tree, as long as they’re not the files you’re working on.

Aside from that, I hear you, git’s model is fundamentally different from Perforce. There’s no choice about whether you need a clean work tree before pulling, that’s simply a git requirement. So the main thing to ask now is what workflow you want and what safety net you want underneath it. On one side, the best way to focus is to not pull anything while you’re working and have a dirty work tree. But things come up at work, that’s not always realistic, so the next question is how to make the workflow both safe and also instinctual so that it doesn’t have friction.

I do think there’s something to your notion that commit feels more serious and heavy than stash, and that is something I personally have tried to break down. In git, commits and branches can be so much more lightweight, fluid and flexible, but it takes practice and fluency in git to be able to actually feel that.

It might be worth considering some shell or git aliases to do common things. You could easily alias a command that commits your work in progress with a comment “WIP”, and never have to type it. You can do the same with a branch and even keep around a branch for work in progress that is always temporary and gets force reset to whatever you’re working on. (Remember a branch is just a pointer and nothing more, you can completely change what it points to without hurting anything, and the change is stored in the reflog, so there’s a undo button.) I think it is possible to make a branch & commit workflow that is both easier and safer than stash.

Re: Git is too hard

#724

Post by jcelerier »

ric2b wrote: post #561
jcelerier wrote: post #477

Earlier quoted context omitted.

> Obviously you can't undo that. I'd wager I press the "undo" button in gmail at least 3/4 times per week

That's because you have a 30s timer that doesn't actually send anything until it counts to 0. After it actually sends the e-mail, there's no going back.

sure, but that 30s timer is an incredibly useful feature, when you misclick, when your cat walks on your keyboard, when you remember that you forgot $RANDOM_THING, etc etc

Re: Git is too hard

#725

Post by sixstringtheory »

rossdavidh wrote: post #410

I've used git for ten years, at half a dozen organizations (I'm a consultant/contractor). I have accepted that it's what we use now, so I use it. But... Git is the bad boyfriend of the developer community. If anything bad happens it was your fault. If you ask it to do something and it does something else, it was your fault, and also you are stupid. If you ever make a mistake, you will be punished for it with a long d…

> Good software is not like that

You can't just say this without providing an example of what you think is good software, as, after all, good and bad are subjective and not agreed upon by all people for all things, as evidenced in this thread.

Re: Git is too hard

#727

Post by jcelerier »

atq2119 wrote: post #536
jcelerier wrote: post #477

Earlier quoted context omitted.

> Obviously you can't undo that. I'd wager I press the "undo" button in gmail at least 3/4 times per week

This only works because you can configure gmail to send email on a timer instead of immediately. Also, may I kindly suggest that you aren't putting enough thought into your emails? That may be fine for single-recipient emails (depending on your environment), but when your email is received by many people it's an unkind act that shows disregard for the recipient's time and attention.

> but when your email is received by many people it's an unkind act that shows disregard for the recipient's time and attention.

most of my e-mail are just chat conversations with a title

Re: Git is too hard

#728

Post by yencabulator »

MaxBarraclough wrote: post #694
cesarb wrote: post #502

Earlier quoted context omitted.

> You really believe that git stores -- in full -- every version of a tracked file? Yes, it does. > Every commit that deletes the whitespace from an otherwise empty line in a 30KB file is another 30KB of hard drive space Yes, it is. "It's worth repeating that git stores every revision of an object separately in the database, addressed by the SHA checksum of its contents. There is no obvious connection between two ver…

> "automatic GC" which combines these "loose objects" into a "pack file"; and within that "pack file", it uses a binary diff (a xdelta) between similar objects to reduce the total size Isn't it the case then that git doesn't store in full every version of a tracked file?

Deduplication and compression do not imply diffs.

Re: Git is too hard

#729

Post by yencabulator »

IAmNotAFix wrote: post #569
bollu wrote: post #192

Earlier quoted context omitted.

While the above is tecnobabble, there /is/ a simple way to state what git is. It's an API to interact with a torsor. We have files, which are inert objects and form a "file space". We have diffs. Diffs can "act" on a file to produce a new file or a conflict --- we call this as "applying a patch". Mathematicians would call it a "group(oid) action". Diffs are a groupoid because (1) there's an identity diff that does no…

All is well until you need merges, which is where the confusion happens and minds are lost. - You have a branch `master`. - You have a branch `feature` which contains commit C, which conflicts with `master`. - You merge `feature` into `master`, fixing conflicts. - You log the commits of `master`. * First is the merge commit, whose diff contains code added by commit C (including the conflict resolution). * Next you se…

The problem with that is thinking a directed acyclic graph is a flat sequential list. Try `git log --graph --oneline` or `gitk`.

Re: Git is too hard

#730

Post by sicariusnoctis »

sixstringtheory wrote: post #725
rossdavidh wrote: post #410

I've used git for ten years, at half a dozen organizations (I'm a consultant/contractor). I have accepted that it's what we use now, so I use it. But... Git is the bad boyfriend of the developer community. If anything bad happens it was your fault. If you ask it to do something and it does something else, it was your fault, and also you are stupid. If you ever make a mistake, you will be punished for it with a long d…

> Good software is not like that You can't just say this without providing an example of what you think is good software, as, after all, good and bad are subjective and not agreed upon by all people for all things, as evidenced in this thread.

Anu (successor of Pijul), of course. ;)

https://news.ycombinator.com/item?id=25001539

Post reply on HN