Git is too hard • Hacker News Board

Re: Git is too hard

#781

Post by account42 » Wed, Nov 18, 2020, 11:30 AM UTC

simiones wrote: post #637

0xffff2 wrote: post #630

Earlier quoted context omitted.

I think I've used `reflog` maybe... twice in a decade of daily git use. It's crazy to me that anyone would think that it's a daily use command. I don't even know what bisect is off the top of my head.

Bisect is a debugging utility - it helps you do a binary search for the commit which introduced a bug by checking out code at certain commits, having you compile and run it, and tell git if the bug was there or not, and then going back or forward in history until you can identify the 1 commit that caused the bug to appear. I've never used it, but it sounds like a nice tool of last resort.

> it sounds like a nice tool of last resort

It is actually a great first debugging tool for regressions (unless you already have a hunch where the problem is). It's usefulness is greatly enhanced if you keep your commits small.

Re: Git is too hard

#782

Post by 9HZZRfNlpR » Wed, Nov 18, 2020, 12:21 PM UTC

gpderetta wrote: post #342

skohan wrote: post #243

Earlier quoted context omitted.

> Resisting GUI's is not a good idea. I disagree. In my personal experience, learning git took a lot of trial and error, but now whatever terminal I sit down in front of, I know exactly which commands I have to run to do what I want in git. When using a GUI, it's fine for the easy/common stuff, but if I want to do something more complex I have to figure out how to dig through the options provided by the tool to get t…

Agree with you. A GUI is fine (and a good thing) as long as it is just for convenience and discoverability, and it doesn't abstract git away, hide its power or try to impose its own workflow. IMHO, a good git GUI would show exactly what commands are being run (so it is useful as a learning tool) and their result and allow it being used along side the cli. I use magit extensively and it has all these properties.

As well as smartgit, I only use it for squashing and merging stuff but it shows nice output so I guess you can learn the commands from there doing other stuff as well when you're starting to learn git.

Re: Git is too hard

#783

Post by HelloNurse » Wed, Nov 18, 2020, 12:59 PM UTC

simiones wrote: post #554

harrisonjackson wrote: post #496

Earlier quoted context omitted.

Small frequent commits will limit the need for stash. That's a good practice anyway. The others I'd say could be completely excluded from daily/weekly/yearly use. If you are using cherry or blame daily then there is probably something wrong :D

Why is small frequent commits a good practice? What is to be gained from committing a change to a file, then a commit to undo the previous one if you decide the change wasn't useful/needed? Also, cherry is often needed daily in short bursts around releases. Blame is rarer, absolutely, but I don't think you're using your version control to anywhere near its full potential if you don't use blame (and log) while investi…

> What is to be gained from committing a change to a file, then a commit to undo the previous one if you decide the change wasn't useful/needed? "Undo" commits make sense, occasionally, to fix recent incorrect or improper changes that have been already pushed.

But the more appropriate way to discard changes is leaving them to rot in the commits of a dead experimental branch, avoiding to merge them into the important branches from which releases are made.

Re: Git is too hard

#784

Post by robaato » Wed, Nov 18, 2020, 1:04 PM UTC

bch wrote: post #621

skulk wrote: post #614

Earlier quoted context omitted.

> You have to understand a lot of things before you can somewhat comfortably use git, much more than something like P4. And conversely (at least in my experience), being very familiar with git makes it _really_ hard to work with something like p4.

In my experience, P4 is simply hard. Maybe my introductions were rubbish, but I’ve found it difficult in its own right.

From CLI, p4 is pretty consistent - rather more so than git (which I suppose isn't a high bar!). But of course there are some inconsistencies - as with any tool, particularly if its been around a few years.

Re: Git is too hard

#785

Post by robaato » Wed, Nov 18, 2020, 1:07 PM UTC

dijit wrote: post #233

eloisius wrote: post #225

Earlier quoted context omitted.

I’ve had to use perforce before and was not a fan. Granted, I didn’t have to use it full time and can’t claim to be an expert, but I hated the notion of locking files, change lists, yuck. All of it felt so clunky compared to git.

I’m not sure locking files is as important as all that. You “check out” files, but nothing prevents anyone else “checking them out” (which is perforce parlance for: “make editable”) - conflicts can be resolved. There is locking but it’s seldom used- handy in the gaming industry for code which depends on data.

As cecilpl2 commented - it's the typically the binary art assets (occasionally other files) which are unmergeable which need the exclusive lock turned on. And of course you want to avoid branching those too in many cases.

Re: Git is too hard

#786

Post by studius » Wed, Nov 18, 2020, 1:14 PM UTC

masonhensley wrote: post #443

simiones wrote: post #419

Earlier quoted context omitted.

You forgot log, cherry, stash, blame, which are also daily use commands. You also have to learn a lot of concepts to even understand the help and error messages for these commands - the worktree, the index, the stash, HEAD, ours vs theirs, conflicts, remotes, tracking branches, when it is safe to push -F, etc. Depending on the project you joined, you may also have to immediately learn about git LFS, submodules, squas…

Based on my experience - most teams will get by with ivanhoe's list. You additional items are definitely helpful - but the typical team member's workflow won't cross those bridges. Team leads perhaps. There's definitely levels of proficiency, but for a junior or even mid-level dev doing feature work, I think there red flags if they are needing to jump into stash, cherry, etc on a daily basis.

> I think there red flags if they are needing to jump into stash, cherry, etc on a daily basis.

Without stash, things can be nasty. Some alternatives:

1. Commit frequently, one tested piece of code at a time.

I'm sure this is what you meant. Not every environment and process allows this and not every change is small.

If you can though and have time, do this. If needed perhaps you can combine things and rebase later into larger commits. This is the reliable and clean process of development that everyone would love to have as a base, and then to do whatever they feel with it and it always stay like this with hard work and dedication.

Let's move on because that isn't always going to be the case.

2. Commit unfinished/non-working code.

The best analogy of this is like leaving unfinished crap all over the place that might look finished to some. At some point, it may go wrong. If you do this, you might name the branch with something standard indicating it's unfinished.

This always seems to happen when a developer leaves for a holiday/vacation or leaves permanently. Then some other developer tries to build/test it, it works, they smooth some rough edges and commit it. In my experience, it is was truly unfinished, the quality may end up being somewhere between a point on a line anywhere below the initial committer's typically code quality and anywhere below the fixer's code quality. There are exceptions, but as a general rule, be more careful with such commits if the personal investment and sense of ownership is not strong in that code.

3. Multiple copies of the repo.

It's likely going to be less efficient to have multiple copies of the repo from a storage standpoint.

Showing the stashes may be more efficient than searching through different versions of the files in copies of the repo or having to recursively diff repo copies.

Using multiple copies of the repo may also increase the chance of things going wrong or history being lost.

I still would recommend having a backup of anything really important in the repo at times, if you're not feeling confident or are worried about losing anything.

4. Throw away code changes.

Every time you switch priorities, you could throw away all of the work you had locally. If it was crap, this might be best. Be careful; you could lose something important.

5. Manually copy changed files to another area outside of the repo to ensure it doesn't get stomped accidentally.

This can be messy, but with tools to make it easier, it might be "ok". Compared to git stash though, it's likely less efficient, because whole files are being copied instead of just the changes.

6. Manually backup only the diff/patch files of changes.

Well, now you're just recreating git stash functionality, but sure, you could do that. People did this before git stash and still do. Create patch files. It doesn't sound as easy or clean, and you've got to put those patch files somewhere. Will that be consistent between developers? If a developer leaves or is unavailable, where would you find them?

Re: Git is too hard

#787

Post by simiones » Wed, Nov 18, 2020, 1:20 PM UTC

bch wrote: post #621

skulk wrote: post #614

Earlier quoted context omitted.

> You have to understand a lot of things before you can somewhat comfortably use git, much more than something like P4. And conversely (at least in my experience), being very familiar with git makes it _really_ hard to work with something like p4.

In my experience, P4 is simply hard. Maybe my introductions were rubbish, but I’ve found it difficult in its own right.

P4 definitely has its own rough sides, but I find the model is overall much simpler.

In essence, P4 is a file tracker - you have remote files and local files kept in sync (git clone, git fetch, git pull). The basic workflow is to modify, add, copy or delete one or more files (git add), group the changes into a changelist (git stage), give it a description (git commit), and submit that change list to the remote (git push). Of course, if someone else modified the same files between your last sync and your submit, you will also have to resolve conflicts.

Of course, you can sync all or part of your files to some specific older CL (git checkout). You can revert a change on the remote as well (git reset). When you look at a file or directory, you can see the log of all changes that happened to it (git log).

The biggest difference from Git is in the branching area - branches in P4 are simply copies of one or more files, together with some metadata to tell P4 that this is an intentional branch. Working with branches is simply working with different copies of a file. When you want to bring changes from one branch back into the other, you can merge (integrate in P4's parlance) one or more changes between the branches. At that time, it does a 3-way merge just like Git - last common ancestor, changes in branch A, changes in branch B => result. The most common way of creating branches is to have each branch be a copy of the entire project dir (so you would see on your local system ~/p4/root/proj1/main,~/p4/root/proj1/dev,~/p4/root/proj1/feature1 etc.).

One limitation of P4 branching is that you can't really revert a merge in P4. You can of course revert the changes, but the merge is forever considered the new common base for the two branches. So if you integrate branch A into branch B, then revert the change on branch B, and then try to integrate again, P4 will tell you that all of the changes have already been integrated. If you try to integrate B into A now, it will try to integrate the revert into branch A.

And this is essentially it. P4 scales much better than Git, so most companies have a single P4 repo, and everyone syncs only the parts that they need.

All of these things can be done from either the command line (p4 sync, p4 edit, p4 reconcile, p4 submit, cp + p4 branch, p4 integrate) or from the very simple first party GUI, P4V.

Re: Git is too hard

#788

Post by horsawlarway » Wed, Nov 18, 2020, 2:17 PM UTC

wpietri wrote: post #760

horsawlarway wrote: post #741

Earlier quoted context omitted.

I think your comments are coming from ignorance, though. Without trying to be snarky - All your comments directly ignore that what you're proposing values one stakeholder more highly than another. People keep pointing out that there are two users involved in this exchange, and they both weigh equally, and you dismiss them and talk about running mail servers 25 years ago (who cares?). You keep saying "I should be able…

I have in fact never said "I should be able to unsend my email". Once. In my life. Please try to argue with my actual points; I don't have time for straw men.

wpietri:

>Asking to unsend an email is a reasonable request. The answer could be yes or no given the circumstances, but it's only an absurd question to people who have taken a 1980s technological choice and treat it as some sort of unalterable gospel.

---

We're here answering affirmatively that "No" is the right answer for a LOT more reasons than an appeal to authority and history, and you accuse me of a strawman?

I wish you the best in life. Have a good day.

Re: Git is too hard

#789

Post by simiones » Wed, Nov 18, 2020, 2:28 PM UTC

account42 wrote: post #781

simiones wrote: post #637

Earlier quoted context omitted.

Bisect is a debugging utility - it helps you do a binary search for the commit which introduced a bug by checking out code at certain commits, having you compile and run it, and tell git if the bug was there or not, and then going back or forward in history until you can identify the 1 commit that caused the bug to appear. I've never used it, but it sounds like a nice tool of last resort.

> it sounds like a nice tool of last resort It is actually a great first debugging tool for regressions (unless you already have a hunch where the problem is). It's usefulness is greatly enhanced if you keep your commits small.

Usually, I prefer to investigate a bug starting from the code rather than the history, if it's possible. In my experience, most bugs have taken longer to reproduce repeatedly than to understand from code. Besides, there's no guarantee that a bisect will land at the right commit if the bug is not reliably reproducible.

But I have been in situations where I had to manually bisect the code because I just couldn't understand how the code could reproduce the problem, and having git bisect would have been a significant help.

Re: Git is too hard

#790

Post by SAI_Peregrinus » Wed, Nov 18, 2020, 2:53 PM UTC

zzbzq wrote: post #398

thaumasiotes wrote: post #320

Earlier quoted context omitted.

Fair enough. The blob stores a diff. The commit stores a reference to... the diff. This is a division between the concept of the object and the implementation. But it's not an example of a diff-storing model failing to model git as it is; git as it is is storing diffs. If a commit references a "blob", and the "blob" that it references is, in fact, a diff, why would we say that the commit "does not reference a diff"?

Each commit consists of a structured collection of hash IDs for every file in the entire repo. The hash ID is generated by hashing the contents of the entire file. Not the diff. The "diff" you're referring to is an implementation detail of the compression. It's not even always there; it depends on which commits are present in your clone. It's also not even the same "diff" you work with when you use git to generate or…

And that's part of the problem with git! It requires you to get a mental model of how it works internally, but only part of how it works internally is important, and there are terminology conflicts. So people get incorrect ideas about how it works, then get surprised when something unexpected happens.