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

201–210 of 294 posts

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

#201

Post by jononor »

yoodenvranx wrote: post #146

In the beginning I tried to use git exclusively through command line because I thought that's how real men do it. But after using gitkraken (or similar products) I will never go back to using git through its command line interface. Being able to see the whole repo structure is just so much more convenient and it helps to resolve most merging problems much faster. git guis all have their own problems, but overall usin…

Yeah being able to see what you do is critical for understanding and feeling comfortable. I do everything via "git", but always have "gitk" open for that visual overview. gitk is very basic and not that great, but does the trick.

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

#202

Post by xinsight »

nicoburns wrote: post #128
sigjuice wrote: post #89

Earlier quoted context omitted.

No. This does not safeguard any uncommitted files.

Leaving any files uncommitted before a complex operation in git is a really bad idea (make a temporary commit if necessary). It's almost impossible to completely lose committed data, but pretty easy to destroy uncommitted data.

This. I also do a `git diff > save.patch` if there is something uncommmited that i don't want to commit at the moment. A patch file feels more comfortable to me than git stash, as i can easily view the patch files, and reapply them with `patch -p1 < save.patch`

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

#203

Post by jononor »

nurettin wrote: post #10

>> And the Git staging area should be an opt-in feature. Thousands of yes! `git commit -a` just doesn't add the untracked files it is the most annoying misfeature of any version control system. Oh, I added unwanted project directories? I would then just remove them and put them to `.gitignore`, or create a `.gitignore` prior to `init`. Of course I could just alias `add -A . && commit -m` on every machine I ever conne…

Automatically adding untracked files would make it extremely easy to commit (and without other safeguards, push) unwanted changes. Annoying things like node_modules or binary screenshots that now bloats the repo history forever (unless one rewrites the history), or potential security breaches like passwords/keys or logs/configs with confidential information.

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

#204

Post by sunny256 »

xenomachina wrote: post #63
gumby wrote: post #12

I'm surprisedly the staging-area hate. Does it really violate peoples' assumptions? I like the ability to make a big, complex change and checkpoint stable portions (subsets) of the work as I go.

How do you test the thing you're actually committing without everything else in your working tree contaminating your test? There are ways to do this using stash but if you stash before you commit, you get merge conflicts when you pop the stash. The workaround I've seen is to commit before you stash, but that means you're also committing before you've actually tested that change, which seems pretty broken, IMHO.

I've created a script for this, it applies the staged changes to a fresh clone and executes the command you specify. To quote from --help:

If you have lots of unrelated uncommitted changes in the current repository and want to split up the commit, how can you easily check if the changes passes the test suite? With all the other unrelated changes it can be hard to make sure that only relevant changes becomes part of the commit, and that they don't result in regressions. This script clones the repository to the directory ".testadd.tmp" in the current directory and applies the staged changes there (unless -u/--unmodified or -p/--pristine is specified), chdirs to the same relative directory in the clone and executes the command specified on the command line there.

It's available from

https://github.com/sunny256/utils/blob/master/git-testadd

and the test suite (place it in a subdirectory below the script) is at

https://github.com/sunny256/utils/blob/master/tests/git-test...

It's stable, and I've been using it almost every day for 1.5 years. It also works with binary files.

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

#205

Post by ngoldbaum »

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…

In response to [2], these days MQ is deprecated and there's a big push to get people to use evolve, which avoids this mess and is much safer.

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

#206

Post by nhaehnle »

rbehrends wrote: post #180
nhaehnle wrote: post #175

Earlier quoted context omitted.

> I'm honestly not sure why you think you'd even need a GC for `hg commit --amend` or `hg rebase` (or similar operations in other VCSes). Maybe you don't call it GC, but doing a rebase in Git leaves the old, pre-rebase version around. That is a feature: over the years, it has happened to me more than once that I'd missed something when resolving complex conflicts during the rebase. Being able to refer back to the sta…

> If Mercurial throws the old version away unconditionally, that would suck very much indeed. Which is why it isn't done. In core Mercurial, the old revisions are stored in a backup bundle in a separate backup directory. Note that bundles can transparently be used as read-only repositories, so you can view their logs as though they were still part of the parent repo, diff against them, pull from them, etc. With the e…

Thanks for the explanation.

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

#207

Post by bluGill »

giomasce wrote: post #140

The thing I love of git is that its internal structure is very simple and transparent, so for any given repository it is possible (although not necessarily easy, if things are well messed-up) to understand what is going on. It is true that the interface is often messy and inconsistent, sometimes annoyingly so, but if I can understand what things are, I can somehow work out how to do things with them (in extremal situ…

As a long time mercurial user being forced to switch to git I find that I know more about git internals than mercurial. Mercurial provides a nice abstraction so I don't have to care. In face I've seen a few hints that mercurial has actually changed their internals over the years, but since everything still "just works" I don't think about it. By contrast git is forcing me to care even though I have better things to do with my time.

Sadly github and CI systems provide community tools around git not mercurial (mercurial is an afterthought at best in most CI systems). Those community tools are compelling enough that I'm switching to an inferior system just to get them.

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

#208

Post by tarnacious_ »

majewsky wrote: post #117
yeukhon wrote: post #79

Here are the commands I use: git init git clone git checkout git commit git commit -m git commit —amend git rebase git add/rm/diff [—cached] git push git branch and a few more I can’t remember exactly. I try to keep my git workflow simple. The most complex is probably checkout abd rebase with several different branches.

> I try to keep my git workflow simple. > git rebase Yeah... :)

I often rebase my local commits on a remote branch to keep my branch up to date with changes in the remote branch.

I find this simpler and cleaner than introducing a series of merge commits in my local branch.

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

#209

Post by eternalban »

taeric wrote: post #22

If you requested save in your favorite GUI application, text editor, etc and it popped open a select the changes you would like to save dialog, you would rightly think just save all my changes already, dammit I'm sympathetic to what this is asking, but I have to feel that this would lead to much better practices for many people. I'd wager a ton of folks would be more "why in the world does it think I changed that?" t…

I parted company with the OP at that point. If he considers staging a "power user" feature then we're on two different planets.

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

#210

Post by mercutio2 »

inimino wrote: post #51
gumby wrote: post #12

I'm surprisedly the staging-area hate. Does it really violate peoples' assumptions? I like the ability to make a big, complex change and checkpoint stable portions (subsets) of the work as I go.

As the author points out, it is an unnecessary primitive, once you learn about things like commit —amend, which you will inevitably eventually learn about anyway. Adding redundant ways to do the same thing is not the way to make a tool approachable. The basic problem is that git was designed to solve Linus’s problems, and Linus’s problems are not your problems. However, because of network effects, most of us end up u…

How does commit --amend in any way solve the same problem as the staging area?

If I’ve got a big change which I want to split into three small internally consistent changes, with each change overlapping in many files, how in the world would --amend help?

Post reply on HN