High-Level Problems with Git and How to Fix Them • Hacker News Board

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

#101

Post by nordsieck » Tue, Dec 12, 2017, 9:10 AM UTC

jcranmer wrote: post #36

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.

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…

> But while I'm slowly hacking away at this commit, I talked with someone else and decided to try an idea which turns out to be a small commit. But I've already got this half-built-up commit that's staged, so I need to commit that to make the new commit, and then somehow reverse the patches and restage the commit (which is something that's well outside my git comfort level).

Git stash

> What hg has is a few different features that make it possible to build up not just a single commit but an entire commit sequence and do operations on that commit sequence (like reorder them). The git staging area is kind of a weak version of that...

The git way is to make a new branch and then use git rebase -i

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

#102

Post by majewsky » Tue, Dec 12, 2017, 9:14 AM UTC

__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…

You can do small temporary commits on a branch, and once you want to do an actual commit which will then be pushed, you go onto the master branch and `git merge --squash `.

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

#103

Post by majewsky » Tue, Dec 12, 2017, 9:15 AM UTC

popopopo wrote: post #83

lucideer wrote: post #80

Earlier quoted context omitted.

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 still, while people cry about UI (which is irrelevant part), other people just take time and learn git. by whatever measures. PS. throwing out things you test on. isn't that how every programming tutorial works? write code NOT in your main repository, test things out, throw it away (or keep it, whatever)?

With a programming language, if you open a new file A in the same repo and try out some stuff, and it doesn't turn out well, you can just delete the file and be reasonably sure that it doesn't fuck up files B, C and D in the same directory.

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

#104

Post by Sujan » Tue, Dec 12, 2017, 9:16 AM UTC

Workspaces please, now.

That would be so much nicer than the current need to fork.

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

#105

Post by emj » Tue, Dec 12, 2017, 9:16 AM UTC

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.

You are already using ammend and rebase, you can do plenty of complex and hairy stuff with that, especially as a team. I'm also guessing you use merge and log at times. FWIW this is my philosphy with git too, but have you not experienced the points he brings up? I was nodding my head at all of them; branches are time-consuming, staging is problematic and forks are a bad analogy.

The recent post and hype about the Facebook, Google and Microsoft monorepos should make us ask the question what our systems for source control is supposed to do really.

  save changes to a source code
  save changes to big binary assets
  annotate those changes
  annotate the files themselves
  tagging versions 
  signing of code
  code review
  handle regressions testing
  collaborating (ACL, DCVS, official monkey patching etc)
  merging
  search on the whole code base
  refactoring on large code bases

All these things have uses but they are not really supposed to be tied to one VCS, we have very basic needs when working with source code streamlining the UX for that workflow might be more important and in the same time opening up for easy access to the other stuff.

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

#106

Post by majewsky » Tue, Dec 12, 2017, 9:17 AM UTC

BlackFingolfin wrote: post #98

blux wrote: post #69

The Git staging area doesn't have to be this complicated. A re-branding away from index to staging area would go a long way. Adding an alias from git diff --staged to git diff --cached and removing references to the cache from common user commands would make a lot of sense and reduce end-user confusion. --staged is already an alias for --cached in the latest Git version.

And it has been for some time (years, I think)

Years, yes. At least since 2.0, though probably longer.

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

#107

Post by qznc » Tue, Dec 12, 2017, 9:18 AM UTC

OJFord wrote: post #50

gmueckl wrote: post #32

Earlier quoted context omitted.

90% of VCS commits are simple enough to not need staging in my experience. That you can stage your changes does not mean that you need to be forced to do that. This is the point the article tries to make: streamline the workflow, but do not remove the feature for power users (people like you).

I believe there's a flag to `commit` that effectively does `add .` first. I disagree with your statistic though - I can't tell you what the flag is precisely because it's almost never what I want; so I never use it and haven't learnt it. I think these things just vary with workflow.

I record my uses of each command and the current counts are the following (g is my shell alias for git):

    161 g cap      # commit --patch --amend
    170 g adu      # add -u
    205 g add -p   # add --patch
    277 g ci       # commit -a
    484 g cip      # commit --patch

At least, I use it a lot. ;)

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

#108

Post by qznc » Tue, Dec 12, 2017, 9:20 AM UTC

klodolph wrote: post #86

mikeyjk wrote: post #42

Earlier quoted context omitted.

- "submit your changes and go home" - "production" The merge should happen far before it hits production. Maybe I'm taking you too literally or something. Do you have a CI/CD pipeline?

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"?

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

#109

Post by rbehrends » Tue, Dec 12, 2017, 9:20 AM UTC

nhaehnle wrote: post #85

phillco wrote: post #19

Anecdotally, being able to commit anywhere, without needing a branch name, is one of the biggest conceptual differences when we teach new hires Mercurial at Facebook.

As a convinced Git user, this is the one aspect of the article that I found genuinely interesting. I mean, you can commit anywhere in Git, too (and I occasionally do for some advanced use cases), but it tends to not be well supported by Git. (And, I might add, probably not by Hg either if it requires enabling an extension...) Anyway, hg show work looks like an interesting thing. It's perhaps a bit more magic than Git…

> As a convinced Git user, this is the one aspect of the article that I found genuinely interesting. I mean, you can commit anywhere in Git, too (and I occasionally do for some advanced use cases), but it tends to not be well supported by Git.

"Not well supported" in this context means that you can lose data (as commits that are not reachable from a ref can be garbage collected). Mind you, you have to ignore warnings/errors to get there, but without ignoring them, you also won't be able to actually have anonymous branches.

> (And, I might add, probably not by Hg either if it requires enabling an extension...)

It does not require an extension. The `show` extension that Greg talks about is a smart log display, which shows a contextual log for your current work. Anonymous branches have been part of Mercurial from the beginning, long before the `show` extension existed.

For what it's worth, it's not so much that Mercurial supports it, but that Git doesn't. Git is rather unique in its setup in this regard. No other VCS that I know of uses garbage collection and in particular branches to prevent revisions from being garbage collected. (Some may require you to name branches for other reasons, but not so you don't lose commits.)

It's probably also worth noting that we have an implementation detail leaking into user space here. Git uses what is essentially purely functional data structures underneath to achieve atomicity in the absence of an actual database engine [1]; a different implementation, such as on top of SQLite, could avoid this.

[1] Atomicity here is not about locking, but about a transaction being interrupted by the user or an external event, such as a shutdown.

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

#110

Post by majewsky » Tue, Dec 12, 2017, 9:21 AM UTC

codegladiator wrote: post #28

Klathmon wrote: post #17

Earlier quoted context omitted.

> 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…

> I feel like a "language aware" VCS would be able to help a lot in this area. VCS would have to be much more than "language aware" to even begin to help in this area.

Yes, one would need an AGI for that.