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

221–230 of 294 posts

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

#221

Post by camgunz »

I find the Git UI discussion the least interesting part of Git discussions. Git's UI isn't great, but it usually doesn't matter because 90% of what you're doing is what you always did with Subversion and Hg. The commands are a little more obtuse but that doesn't matter either.

I really like Gregory's discussion about nameless workflows. For small side projects I use Git on a personal server and I don't care to name every change or even use branches. I essentially just want my work sync'd remotely and maybe -- maybe -- I'll look at the history, but almost never. I used to use tar/scp for this before I got worried about overwriting local/remote changes.

I use Git for this now and guess what, my commits are all '.'. I blatantly don't care, and some commits I'm rewriting the entire source tree in a day (like I said, small side projects) so the message would be "Old version sucked, rewrote" and there would be 20 of them.

Mostly this is because I don't care to waste my brain power on managing my changes. That's what I'm using a VCS for. They don't need summaries -- that's what diffs are for -- and they certainly don't need names.

Gregory's argument against forks makes sense to me too. Semantically a fork doesn't really sync back up with the main branch; if it does it's pretty rare -- or just look at the terminology here: branch, root, trunk... FORK. Fork doesn't really go there.

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

#222

Post by phasmantistes »

While I appreciate and agree with the last section regarding replacing GitHub's "fork" model with something lighter-weight, it amuses and saddens me that the author puts a lot of effort into describing something that they feel is wholly novel... but is actually just the model already implemented by Gerrit (https://www.gerritcodereview.com/). There are alternatives to GitHub already! Some do things better than GitHub already! Give it a shot.

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

#223

Post by hinkley »

Dylan16807 wrote: post #92
hinkley wrote: post #58

Earlier quoted context omitted.

I would rather go the other way. Commit messages should be modifiable by themselves. The idea that commit messages will be gotten right on the first try predates CVS and it’s just wrong. Who hasn’t put the wrong bug number on a commit? You’re stuck with that. Who hasn’t confidently remarked that they have solved a problem and then discovered they haven’t? Commentary about a block of code needs to be a living document…

How do you like git-notes?

For a second I thought you found something I didn’t know about git but then I realized I dismissed notes out of hand. They’re not managed automatically so it’s pointless for me to try to sell a large team on using them. We already work with multiple repos and doubling the workflow won’t be appreciated.

And if I recall isn’t it a pain to add additional notes?

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

#224

Post by maw »

Klathmon wrote: post #17
klodolph wrote: post #11

It's clear that there will be a successor to Git some day, in the sense that Git is a successor to SVN (yes, I know Linus's viewpoints on SVN). But the successor won't be a "better Git" just like Git isn't a "better SVN". The driving features of Git's successor will be unrelated to Git UI gripes. If Git's UI gripes were important enough, people would just be using Mercurial (which has it's own quirks). The biggest pr…

> A better VCS isn't going to solve that! It might! I feel like a "language aware" VCS would be able to help a lot in this area. I know there are 3rd party tools that can do this, but if a VCS came along that natively knew about some languages it could unlock some really cool features. Imagine instead of your VCS storing the text source, it stores the AST! Language aware means it can also integrate tightly with langu…

but if a VCS came along that natively knew about some languages it could unlock some really cool features

Absolutely, although hopefully it'll be implemented using langserver or similar.

Conversely, I think programming languages (and code- and configuration-generators) of the future will be judged in part on how VCS-friendly they are. A few smart decisions when designing syntax could make diffs smaller and conflicts easier to resolve. (This kind of change would, I am convinced, also make experimental changes to code easier--think rewriting SQL queries to make them faster.)

For now, I've been adapting my own coding style over time to be more VCS friendly. It's made my life easier and has indeed made making experimental changes easier to boot.

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

#225

Post by wutbrodo »

maccam94 wrote: post #125
jcranmer wrote: post #36

Earlier quoted context omitted.

Coming from someone who learned hg well before git, and who's now being more or less forced to use git long after developing comfortable hg workflows, the staging area feels like a half-baked implementation of what it's supposed to be doing. I'm used to thinking of commits as atomic commits--roughly, each commit is the smallest change that atomically makes sense. So you should be able to use the staging area to build…

Some useful commands I'd use in scenarios like this are: git add -p # select what to add to the staging area git reset -p # deselect chunks that I decided I don't want anymore git stash # saves your working state in a temporary commit (not in your branch) git stash pop # restores the working state from the last git stash command and drops the temporary commit git rebase -i $start_point # where $start_point is either…

> I do wish git had some notion of sub-commits with their own messages, and a better UX for cleaning up a set of commits before merging them.

Does rebase -i handle this adequately or am I misunderstanding what you're describing here? My workflow sounds like exactly what you're saying here, where "subcommits" are my development commits and the UX is the rebase -i editor.

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

#226

Post by xyzzy_plugh »

keeperofdakeys wrote: post #119
xyzzy_plugh wrote: post #39

Earlier quoted context omitted.

> And when I have to work with them, I really would prefer if git had something like `git save`. Which in the backend kept doing something like `git commit -a --amend`. This works fine, but it encourages squashing all your changes into a single commit, rater than providing you the opportunity to build a series of commits. Instead of `git commit -a` I have gotten into the habit of `git add -p` followed by `git commit`…

If you use `git commit --fixup= `, then the new commit will be automatically moved, and given the "fixup" action when doing an interactive rebase. (Same for --squash). This means you only need to match the fixups to commits once, when you're initially creating them.

Yes, but I rarely use this as I often haven't made up my mind regarding how the series should be structured.

If instead I could fixup using a tag or theme identifier, which would be used to reorder and group commits, then I would spend less time in my rebase.

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

#227

Post by yeukhon »

saltedmd5 wrote: post #144
zegl wrote: post #129

Earlier quoted context omitted.

`rebase` is simpler than `merge` in larger teams/projects, as the history will be much cleaner.

Rebase is not simpler in any context - rebase rewrites history, which, if branches have been pushed to remotes, then necessitates force pushes, which in turn breaks any other instances of the same branch. By using rebase to "keep history clean" you are largely undermining git's power as a DVCS. Rebase as a tool is not inherently bad but it is definitely not simpler than merge - it introduces additional considerations…

Simple or not, it's a subjective. As you said it:

> > it introduces additional considerations, requires a deeper understanding of git for effective use and is a dangerous tool in the hands of people who do not understand what it is doing

I am taught git with rebase (though merge when I use hg) so I am already too used to it. Branching then rebase is not that difficult if you keep your workflow consistent and quick iteration. You should be up to date whenever possible. Amending and rewriting history/comment also requires using rebase.

YMMV.

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

#228

Post by tokenizerrr »

fuhrysteve wrote: post #182
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…

> 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 :(

Yeah, don't do that

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

#229

Post by GordonS »

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…

I seem to recall that Visual Studio Could has an option to immediately push all your commits to remote, bypassing staging. I kind of like staging tho; I find it helps keep me focused on small, self-contained pieces of work, instead of working on several pieces at once.

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

#230

Post by GordonS »

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 do like SVN, and have used it for more than 10 years. It's simple, and I like simple.

But... I do seem to get a lot of annoying conflicts that require resolution though. Git just works, though does having a bigger learning curve

Post reply on HN