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

111–120 of 294 posts

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

#111

Post by majewsky »

ygra wrote: post #37
sharp11 wrote: post #20

Lots of food for thought in this article, but the part I find most interesting is his distinction between "soft" and "hard" forks. (Viz., are you "forking" in order to collaborate or in order to go your own way?) If collaborate, it would be nice to lower the barrier to participation ... more like Wikipedia. I know that I often don't bother to submit a PR for small changes bc of the overhead of setup. Whereas I fairly…

GitHub at least has a simple way of making small changes: You can simply click 'Edit' on any file, which will make a fork, commit and pull request in one operation. It's only good for single-file changes you're confident to make in a simple web text editor, though. I've only used it for typos.

I don't like that doing so frequently litters your personal repository list with forks. Would be nicer if they allowed arbitrary users to push to branches like `incoming//` in the original repo.

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

#112

Post by lucideer »

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

> UI (which is irrelevant part)

UI usability is irrelevant... ?!??

> isn't that how every programming tutorial works

Firstly, learning programming and learning to use a tool that is a component of your workflow are two independent things. The latter should generally (ideally) have a much lower (aiming towards zero) learning curve. Yes, this is possible, with good UI design.

Secondly, even programming language designers strive towards lowering this learning curve. There is, imo, a necessary complexity, or "table stakes" for any reasonably useful language, but its still very evident to any language designer that this is a trade-off. Usability is desirable.

For a tool as popular and essential as Git, usability should be a much more central goal than it seems to have been in the past.

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

#113

Post by qznc »

sharp11 wrote: post #20

Lots of food for thought in this article, but the part I find most interesting is his distinction between "soft" and "hard" forks. (Viz., are you "forking" in order to collaborate or in order to go your own way?) If collaborate, it would be nice to lower the barrier to participation ... more like Wikipedia. I know that I often don't bother to submit a PR for small changes bc of the overhead of setup. Whereas I fairly…

I don't know why Github does not make this easier. What I would like to do is:

    git clone https://github.com/mozilla/DeepSpeech
    [... edit & commit ...]
    git push # Github automatically creates and pushes to a branch called qznc/master
    [ one more click to open a pull request ]
All this assuming I have no write access to the repo and without creating a repo at https://github.com/qznc/DeepSpeech.

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

#114

Post by saltedmd5 »

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," and yet I see 'git rebase' but no 'git merge' in that list.

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

#115

Post by majewsky »

adrianN wrote: post #38
infogulch wrote: post #27

Earlier quoted context omitted.

Commit messages could just as easily be a policy requirement instead of a tool requirement. Maybe all the repos you interact with require a message for every commit, and that's fine. But maybe the default policy should be permissive. People might decide not to use any tool at all if this is the straw that broke the camel's back for them, and that's a worse outcome in my opinion. And, honestly, 90% of all commits I've…

"Change 357" could be a sufficient message if there is some other tool to track changes where I can look up what #357 is all about. I'd argue that for any piece of software where a failure requires a root cause investigation the VCS history is a critical artifact and a great deal of care should be taken to make it easy to understand for what reasons changes happened and how they interact.

> "Change 357" could be a sufficient message if there is some other tool to track changes where I can look up what #357 is all about.

Realistically, though, you won't be able to figure out to which task management system this issue number refers, out of the five that your team used in the last 3 years. We have been through two different JIRAs and two different Github trackers in the last 3 years. Sometimes multiple simultaenously.

Also, whenever you write /#\d+/ in a Git commit, GitHub will stubbornly assume that the number refers to Github issues and PRs, even if it doesn't. And some of our repos use both Github issues (for external input) and JIRA issues (for internal planning).

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

#116

Post by qznc »

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 a decade of using Mercurial

> I never really used git all that much

Does not sound like a fair comparison ;)

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

#117

Post by majewsky »

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... :)

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

#118

Post by ygra »

majewsky wrote: post #111
ygra wrote: post #37

Earlier quoted context omitted.

GitHub at least has a simple way of making small changes: You can simply click 'Edit' on any file, which will make a fork, commit and pull request in one operation. It's only good for single-file changes you're confident to make in a simple web text editor, though. I've only used it for typos.

I don't like that doing so frequently litters your personal repository list with forks. Would be nicer if they allowed arbitrary users to push to branches like `incoming/ / ` in the original repo.

Isn't that up to the repository maintainer whether they allow pushes from other people? And sure, it litters your list with forks, but you can remove them as soon as the PR is merged. And that's the case for pretty much anything you contribute to (unless you can push there, of course).

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

#119

Post by keeperofdakeys »

xyzzy_plugh wrote: post #39
cjhanks wrote: post #29

Earlier quoted context omitted.

Unfortunately this is simply the reality for many developers. I have worked with multiple people whose commit logs would look something like... > e96ddd0 update code > 65c3072 update code > dd9ccc1 update code > 7992ef8 update code > 6c536e6 update code > ... Over and over several dozen commits. Which is technically fine if they know how to rebase. The overwhelming majority of my commits are simply 'git commit -a -m…

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

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

#120

Post by MaxBarraclough »

icebraining wrote: post #97
jcranmer wrote: post #53

Earlier quoted context omitted.

In my experience, the benefit you get is from giving you an editor to edit the commit message, which has a list of files changed, and can be cancelled in some way to abort the commit. Both hg and git can do this, so it's not necessary to have a separate command and staging area just to do it.

List of files is not enough, I always do 'git add -p' to see the actual changes. And sometimes I detect an error, and I want to fix it and then keep going without having to re-evaluate the changes I had already seen.

My preference is for `git commit --verbose`, which shows all changes in a 'commented-out' section of the commit message file.
Post reply on HN