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

801–810 of 821 posts

Re: Git is too hard

#801

Post by Bjartr »

_ikke_ wrote: post #677
thaumasiotes wrote: post #357

Earlier quoted context omitted.

> See https://stackoverflow.com/a/25028688/8272371 for detailed explanation. There is a disconnect somewhere. The linked answer says: > Now, git is different. Git stores references to complete blobs and this means that with git, only one commit is sufficient to recreate the codebase at that point in time . Git does not need to look up information from past revisions to create a snapshot. > So if that is the case, the…

What you are missing is the difference between gits object model (with loose objects) and packfiles. The delta compression happens when you run `git gc` (git does this automatically as well on occasion), and packfiles is how git fetches and pushes history. But when you create a new commit, that commit object is stored as a loose object, with any new file blobs and tree objects. This represents a complete snapshot of…

Everyone here is arguing past each other because one side defines "what git does" as the literal implementation details of git, and the other side defines "what git does" as the model it presents to the end user. I suspect the reason for this disconnect is partly due to the emphasis on understanding the "internals" of git and the fact that this is about between the internal implementation as it exists in code and the internal model/interface.

Re: Git is too hard

#802

Post by renox »

simfoo wrote: post #591
simiones wrote: post #532

Earlier quoted context omitted.

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.

git config rebase.autoStash true

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.

Re: Git is too hard

#803

Post by etripe »

grey-area wrote: post #674
etripe wrote: post #587

Earlier quoted context omitted.

Excellent ideas! I agree with you on all fronts, exception git add --all && git commit. I don't believe those should be joined at the hip, because staging and committing should be two distinct actions/decisions. Defaulting to including everything would lead to too many human errors and would therefore be dangerous in my opinion. A distinct flag like git commit --all -m "foo" might be OK in my book. Possibly even addi…

Yes I don’t think they can change the default now but many many people operate this way (commit everything not ignored), so most of the time don’t need to separate stage and commit (I agree there needs to be a way to do it, but I use it rarely). My preference would be a command like git save, but a flag would be fine I guess. This is a concept that most beginners don’t really want or need. Ideally git should evolve s…

I'd personally also love a config flag (enabled by default, perhaps) that offers more explanation about what the commands actually do as you run them. In other words, "explain like I'm five" logging or "tutorial mode".

Re: Git is too hard

#804

Post by anotherNae »

simiones wrote: post #447
masonhensley wrote: post #443

Earlier quoted context omitted.

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.

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…

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

Re: Git is too hard

#805

Post by ric2b »

jcelerier wrote: post #724
ric2b wrote: post #561

Earlier quoted context omitted.

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

Sure, and git could have an option to add a timer as well, but I don't think people notice git push mistakes as quickly as they do with e-mails.

Re: Git is too hard

#806

Post by jobigoud »

ajuc wrote: post #793
jobigoud wrote: post #778

Earlier quoted context omitted.

> stuff like removing one change from staging I click on the file and click on "unstage". I don't know why people insist on using the command line for their dvcs. Is it even possible to selectively unstage or reset only a part of a file without a GUI?

> I don't know why people insist on using the command line for their dvcs. I use both. More complicated stuff I usually do from the command line because I do them rarely enough, and I change IDEs often enough - that I just don't know how to do them in IDEs. I used git regularly for last 6 years and in that time I've been using eclipse, netbeans, kdevelop, qtcreator, visual studio and intelliJ. And a few fringe IDEs a…

You don't have to learn 7 IDEs, I've never used git commands in my IDEs. Just use one git client.

And you don't have to remember the menus because they are contextual. Select a portion of text: unstage selected lines, reset selected lines, etc. Select a commit: checkout, create tag, revert, etc.

Things that are complicated on the CLI become routine and that changes the way you work.

Re: Git is too hard

#807

Post by tweetle_beetle »

peterangular wrote: post #573
tweetle_beetle wrote: post #548

Earlier quoted context omitted.

The whole point of the article is that not everyone is a [professional] "dev/SWE", or in other words: > ...a bunch of people who are already really comfortable with their terminals, and they’re reading the email from mailing lists in their terminals already, and unpacking patches by typing out a tar command in a single go. But even if you consider the case of "lazy" devs, I think the conclusion holds true: > I guess…

> Imagine if git was lost and it had to be recreated, would it make sense to rebuild it exactly as it is now? I find your argument to be "if things were different, wouldn't they be different?" which I don't find to be of much substance... but let me fancy your thought experiment: Assuming the remembrance of the features/API was not lost there would be a worldwide effort to recreate it as soon as humanly possible due…

You're right, but I think you've taken my hypotethical scenario more literally than it was intended. I was more imagining if we lost git and everything that went with it and were free from the real-life concerns like backward compatibility - an opportunity for a completely fresh start.

I think that's a fair scenario for evaluating whether or not a tool designed for a small number of people for a specific purpose has successfully transitioned into one used by many people for many purposes.

Re: Git is too hard

#808

Post by simfoo »

renox wrote: post #802
simfoo wrote: post #591

Earlier quoted context omitted.

git config rebase.autoStash true

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.

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

Re: Git is too hard

#809

Post by refset »

yencabulator wrote: post #754
tremon wrote: post #521

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Temporal_database

You're still imagining a centralized solution with a single source of truth and less power than Git. Git history is a directed acyclic graph, not a single linear timeline.

"less power" definitely depends on what you value when comparing Git against real databases, e.g. https://stackoverflow.com/questions/984707/what-are-the-file...

There is at least one database that exists which does support a Git-like DAG for transaction-time temporality: https://terminusdb.com/

It should also be pointed out that "temporal databases" usually offer a lot more besides a linear transaction-time history. Although I've not seen anything that offers a DAG for valid-time histories yet :)

Re: Git is too hard

#810

Post by wpietri »

horsawlarway wrote: post #788
wpietri wrote: post #760

Earlier quoted context omitted.

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…

Yes, I am indeed accusing you of a strawman. You seem very much in the discussion to win it, whatever that means to you. I can only hope that, having decided you are victorious, you'll now leave me alone, because none of your comments seem particularly productive to me.
Post reply on HN