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

More Productive Git

increment.com

Post reply on HN
Print view View original

71–80 of 147 posts

Re: More Productive Git

#71

Post by tom_ »

jordigh wrote: post #39
ChrisSD wrote: post #8

Earlier quoted context omitted.

I find the staging area useful. It especially helps when you only want to commit a change in part of a file or just generally reviewing a commit before it's a real commit. And also to double check I'm not going to be uploading any secret keys (which seems to happen to people more often than it should).

The staging area is incidental. It's yet another place in which your code can be, and it confuses users. This is why Gitless has removed it. https://gitless.com/#vs You don't need the staging area to select hunks into a commit. The selected hunks could go straight into a commit. Selecting hunks is a different thing than putting the selection into an extra intermediate area between working directory and commit. You do…

I always assumed it was there as an analogue of the state tracked by a UI such as TortoiseSVN's Commit dialog, or (though it's a lot longer since I lasted used it...) Perforce's changelists view. It's a list of files you've got checked out or modified: you tick the ones you want in the commit, right click to delete files or revert, double click to get a diff, that kind of thing. Between each deletion/reversion/diff/etc., the state of the tickboxes is retained, so you can sort of just fool about until you've got what you want.

But this sort of multi-step thing is often a pain to do from the command line, I find: unless you have some way of tracking the state between commands, it's no fun working through this list of items, building up a to do list that you then have to get done at the end with one uber command. And the staging area is this way of tracking the state when it comes to putting together your commit.

The gitless examples look to have many common possibilities licked, though, and perhaps that will suffice for most cases?

Re: More Productive Git

#72

Post by saagarjha »

no_gravity wrote: post #28

Put this in your bashrc: source /usr/share/bash-completion/completions/git And you can type "git br " to write "git branch", "git checkout fun " to write "git checkout funky-feature", "git log --na " to write "git log --name-only" etc. Pretty much every time you press somewhere while writing a git command, it does the right type of completion. And hitting multiple times lets you toggle through the options. So you lea…

If you're on macOS, update your bash and install bash-completions and git. The path above is likely wrong if you're using a package manager: for MacPorts you want to source /opt/local/etc/profile.d/bash_completion.sh, and for Homebrew it's $(brew --prefix)/share/bash-completion/bash_completion (the install process will tell you what to use).

Re: More Productive Git

#73

Post by chiefalchemist »

alkonaut wrote: post #51
F-0X wrote: post #42

Earlier quoted context omitted.

On the other hand, I don't know who these articles are really for. I have _never_ met a developer who struggles with git. Not many claim to understand it deeply, but all can rebase, cherry-pick, use the reflog, etc. and almost never do they run into issues. It mystifies me. Git isn't hard, nor complicated. "Checkout" has a few too many meanings, and thats the singular gripe I have with it.

I’m about to roll out git to a team of 30 windows devs of the kind that do NOT like using command line (which is a perfectly sensible thing on Windows I should add, it’s rarely needed there and most command line tools including the shell itself sucks). I assure you they will find it complicated. I’ll insist we switch to git but it’s still going to be an uphill battle. Some will surely struggle also a year from now.

Windows user here, tho' I don't think that has much to do with my analysis/opinion. Ultimately, to me, the dev via Git is doing something that is best explained visually. It seems counter-intuitive to type commands for what is visual, at the very leaat it's unnerving (as if we don't have enough friction and stress in our day already).

To me, Git via the command line, constitutes industry "jargon". It's used - wrongly - to help exclude certain people within the broader culture. Git + CL === elitist.

It's also anti-dog food'ing. But perhaps this helps explain why so many UIs and UXs are so subpar? That is, the less you use something (i.e., a proper UI) the less you learn about them?

p.s. What about SourceTree?

https://www.sourcetreeapp.com/

Re: More Productive Git

#74

Post by gwright »

crimsonalucard wrote: post #16

Any interface that forces you to manually visualize a complex internal structure rather than show you the internal structure itself is a design smell. Any interface that forces me to manipulate such a complex structure with obscure textual commands rather than a drag and drop interface is a design smell. The git graph structure is not amenable to command line. When I do "git log" it lies to me. I see a linked list fo…

You are seeing a path through the graph. If you want the entire graph:

    git log --all --graph --oneline

Re: More Productive Git

#76

Post by agapon »

pjc50 wrote: post #50
house9-2 wrote: post #40

Earlier quoted context omitted.

> The staging area is totally unnecessary IMO. I think git would be easier if we didn't have it. Staging area / Index is one of the best features of Git for me. If I end up having a bunch of semi related changes in-progress; being able to easily group those into individual commits is great. > The term `checkout` is multiplexed to do more things than I would've guessed. Agree

You can do that in svn too with the "changelist".

svn cannot do partial file commits

Re: More Productive Git

#77

Post by bmalehorn »

alkonaut wrote: post #51
F-0X wrote: post #42

Earlier quoted context omitted.

On the other hand, I don't know who these articles are really for. I have _never_ met a developer who struggles with git. Not many claim to understand it deeply, but all can rebase, cherry-pick, use the reflog, etc. and almost never do they run into issues. It mystifies me. Git isn't hard, nor complicated. "Checkout" has a few too many meanings, and thats the singular gripe I have with it.

I’m about to roll out git to a team of 30 windows devs of the kind that do NOT like using command line (which is a perfectly sensible thing on Windows I should add, it’s rarely needed there and most command line tools including the shell itself sucks). I assure you they will find it complicated. I’ll insist we switch to git but it’s still going to be an uphill battle. Some will surely struggle also a year from now.

I think the right approach here is to figure out how to use git in the company IDE. Then, have a presentation / workshop about how to use git in the IDE.

Personally I prefer the command line, but I imagine your coworkers will be a lot more receptive to using version control tools the way they're used to.

If you're concerned about command line complexity, you can try out gitless: https://gitless.com

It's a simplified command line interface to git, designed by looking at how users actually use git.

Re: More Productive Git

#78

Post by chiefalchemist »

jtms wrote: post #43
chiefalchemist wrote: post #31

There's one of these articles at least once per week that makes it to top of HN. When are we collective going to come to the realization that Git is a corded drill in a battery-powered drill world? Don't get me wrong, version control is necessary. Obviously. But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got…

It’s not obvious to me that a battery powered drill is the best tool for the job. If you are a professional doing non-trivial work sometimes the corded drill, with all its benefits, is exactly what is needed.

True. Agreed. A cord is not a battery. But we're not even entertaining that idea of having that choice. We have a corded tool. That's it. Remind yourself of using that next time you're standing in a couple inches of water :)

Re: More Productive Git

#79

Post by dmh2000 »

thanks for telling me about 'git amend'. I frequently screw up and fail to add the files I want or as soon as I commit I remember I needed to change something else. So my projects all have strings of commits that are a few seconds apart.

Re: More Productive Git

#80

Post by brobinson »

chucksmash wrote: post #69
jordigh wrote: post #30

Earlier quoted context omitted.

The proliferation of articles like this is a very very good indication, that, yes, git is that hard, especially if you have to collaborate with other people. Everyone has a different idea of what git does, what things are called, and different interpretations of the vast git vocabulary. What is a rebase? What is a branch? What is a reset? People have different mental models for all of these things. Git would be easie…

I got a lot of mileage out of git with "do work on my own individual branch, never use `--force anything` even if a blog post on the internet says to, and don't rewrite history." Reading just enough of the git-scm book to get a basic mental model of staging, branches, and pushing/pulling from a single remote (aka the things new people actually probably trying to do with git) can serve you well enough. I've since work…

Specifying the remote and branch name again when doing a `git pull` is not necessary after you've set it as the upstream branch (which the `-u` option in `git push` did in your example).
Post reply on HN