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

High-Level Problems with Git and How to Fix Them

gregoryszorc.com

Post reply on HN
Print view View original

181–190 of 294 posts

Re: High-Level Problems with Git and How to Fix Them

#181

Post by rbehrends »

dboreham wrote: post #177
rbehrends wrote: post #173

Earlier quoted context omitted.

I very much doubt that this is a Git issue, but suspect that it is instead a file system/OS/hardware issue. The problem is that operating systems generally offer only very limited guarantees about the atomicity of the bits actually being physically stored on a device (at least guarantees that can be used with reasonable efficiency). It should not normally be a problem, but a power failure just at the wrong time seems…

Um..a mission critical data store shouldn't be affected by a "power failure at just the wrong time".

Sure, but the same things could happen to (say) a relational database under the same circumstances. There's nothing that you can do if (say) the hardware lies to you about having written bits to disk or reorders writes. I was citing the SQLite page for a reason. You can only work with the tools that the OS gives you.

Re: High-Level Problems with Git and How to Fix Them

#182

Post by fuhrysteve »

slavik81 wrote: post #60
jcranmer wrote: post #52

One personal anecdote: In a decade of using Mercurial, I've managed to get a repository in such a confused state that I had to blow it up and start from scratch just once. In the same time, I've had to do the same for git repositories at least 5 or 6 times--and I never really used git all that much. Even nowadays, where I'm more or less forcing myself to use git [1], I'm incredibly hesitant to try any sort of complex…

> I'm never really sure what could cause me to lose unpushed commits... Effectively nothing. By default, old, unreferenced data is only garbage collected after a month. If you screw up a rebase, the old commits are still there with the same hash they always had. You just need to point the branch at them again. > ...or uncommitted working files That's fair. If I'm unsure, I just stash or commit first. Anything that's…

> If you screw up a rebase, the old commits are still there with the same hash they always had.

Disclaimer, if you're compelled for none other than neurotic reasons to run `git gc` periodically like me, these old commits will get thrown out. I found this out the hard way :(

Re: High-Level Problems with Git and How to Fix Them

#183

Post by TorKlingberg »

bluetwo wrote: post #2

I've just never found a reason to move on from SVN, to be honest. I use GIT when I am forced to, but for everything under my control, SVN works the best. I was unaware you could get rid of the staging area in GIT. I may need to look more into that.

I have do work with svn quite a lot. It's simpler that git in some ways, but things like merging branches just does not work at all.

Re: High-Level Problems with Git and How to Fix Them

#184

Post by dbdr »

globuous wrote: post #145
Philipp__ wrote: post #143

I was holding to that famous UNIX mentality for many years, since I started programming almost... Use many programs that do one single thing, pipe the data, print it on the main output etc etc. That’s how I used git too, writing 160 chars wide commands... I tried playing with Emacs year and a half ago, and it was big cultural shock, for first year of using it I still couldn’t adopt kitchensink philosophy. But after b…

TD;DR: Magit is a lesson of UX. +1 for Magit. When I discovered it is when I discovered git. I assume tig must be similar although I've never looked into it but... With magit, from my editor, I can easily check: my git status, choose which hunks to stage or unstage, commit easily. I can switch branches with less than 10 keystrokes. etc. But to me, what's coolest about it is that I can easily see commit histories and…

I definitely recommend trying tig if you want a nice curses TUI on top of git.

Re: High-Level Problems with Git and How to Fix Them

#185

Post by chrisweekly »

__david__ wrote: post #68
slavik81 wrote: post #60

Earlier quoted context omitted.

> I'm never really sure what could cause me to lose unpushed commits... Effectively nothing. By default, old, unreferenced data is only garbage collected after a month. If you screw up a rebase, the old commits are still there with the same hash they always had. You just need to point the branch at them again. > ...or uncommitted working files That's fair. If I'm unsure, I just stash or commit first. Anything that's…

Sometimes I find myself doing "git stash; git stash apply" just so I have a checkpoint of what I'm working on. That plus "git stash list -p" lets me go back through tons of non-checked in junk to find (say) that one line of debugging code that turned out to be pretty useful…

yeah, I do this too.

psa: `git reflog show stash` shows the stash list along w/ with their shorthashes for easy reference

Re: High-Level Problems with Git and How to Fix Them

#186

Post by maxxxxx »

spiznnx wrote: post #65
maxxxxx wrote: post #31

Earlier quoted context omitted.

To me staging is the best part of git. I don't want to commit all the time so I slowly stage changes that I think are OK. Once the feature is done I can do a full commit. Perfect!

The author purports that this can be achieved without staging. For example, you could slowly commit small changes that you think are ok on a work-in-progress feature branch with `git commit -p --allow-empty-message`. When you are done you could squash rebase + message rewrite. While currently this workflow is clunky, it could be made to work with the same nice semantics of your workflow, and not have a staging area a…

Sure. I can get the same result I can get with simple staging with a complicated squash workflow. But why would I do that?

I have seen people get in trouble with rebasing and generally while manipulating history but never with the staging area.

Re: High-Level Problems with Git and How to Fix Them

#187

Post by maxxxxx »

kylemuir wrote: post #46
maxxxxx wrote: post #33

Earlier quoted context omitted.

I used to work with TFS but after working with git I can't stand it anymore. But it shows that people have different tastes.

Strongly echo this sentiment. Last time I used TFS was probably in 2011 so things might have changed significantly since then but off the top of my head things I use to hate but now don't need to worry about since using git over TFS: - Offline? Looks like you'll have to wait to make that change or any other change for that matter since you can't check out files if you're offline. When doing remote work this use to do…

Add to that detection of new files or deletions outside of visual studio. This is so easy in git and a real problem in TFS.

Re: High-Level Problems with Git and How to Fix Them

#188

Post by notzorbo3 »

lucideer wrote: post #80
popopopo wrote: post #64

Earlier quoted context omitted.

wow. > I'm incredibly hesitant to try any sort of complex git operation because of the risk that I might lose my in-progress commits. correct way of learning git is every time you want to use a "complex"/dangerous commands in git, you `cd /tmp` and create a git repository there. then create some commits, branches and experiment. you will NOT lose anything, but you will learn a lot. I did and do this every time I have…

If this is the "correct" way to learn, the problems are not with the user. A well designed ui should be learnable while being used - creating a fresh learning repo for dedicated learning for fear of losing data while using the tool in your "real" repo is the ultimate red flag in terms of usability.

> A well designed ui should be learnable while being used

Strongly disagree with that one. A UI that lets you work in the most efficient way (e.g. vi) can also be well designed, even if it's incredibly difficult to learn.

> creating a fresh learning repo for dedicated learning for fear of losing data while using the tool in your "real" repo is the ultimate red flag in terms of usability.

Again, strongly disagree. Git is a powertool. You don't let loose a powertool if you don't understand how it works. Creating a fresh learning repo is merely acknowledging that you don't know the tool well enough yet. There's nothing wrong with that.

There's a big difference between being noob-friendly and being user-friendly. Personally, I hate noob-friendly tools, because they tend to just get in the way.

Re: High-Level Problems with Git and How to Fix Them

#190

Post by klodolph »

qznc wrote: post #108
klodolph wrote: post #86

Earlier quoted context omitted.

Workflow for the team I’m on right now: * Make changes * Run tests * Code review * Submit changes CI pipeline will run larger integration tests, make releases, and deploy to production. We can cherry pick commits to fix bugs at this point. The pipeline will roll out releases to the development environment on a nightly schedule and to production on a weekly using canaries. You can’t submit if your changes don’t merge…

Submit means "pushing to master" or "pushing feature branch"?

Pushing to master. We don't really use feature branches here. New features are generally hidden behind flags, eventually enabled by default, and then the competing / legacy code paths are deleted.
Post reply on HN