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

This is how I git

daniel.haxx.se

Post reply on HN
Print view View original

81–90 of 140 posts

Re: This is how I git

#81

Post by mplanchard »

adimitrov wrote: post #30
formerly_proven wrote: post #20

> I use git almost exclusively from the command line in a terminal. Is certainly key. Most git frontends seem to be really quite bad for many reasons. Though "Push failed, want to pull, merge and push again? [Yes]" => constant "merged ssh://upstream.server/foo/bar/repo.git merged into branch master" commits being added to the history certainly irks my OCD the most. These frontends also seem to try and hide what git d…

I would like to say that not all git front ends are like that. I used to be a CLI only user, but now you can pry magit from my cold, dead hands. It's very close to the command line in what it does, it's very easy to see what exactly it does, and where it abstracts from git commands, it does so while following Git's mental model very well. It has great discoverability while at the same time being an amazingly streamli…

I’ll second this and note that the discoverability of magit has helped me learn about features of git I didn’t even know existed, while simultaneously making them super easy to work with. Worktrees is the particular example that springs to mind.

It also helps to provide sane defaults, for example -f being force-push-with-lease instead of a regular force push when pushing.

Re: This is how I git

#82

Post by bradstewart »

stinos wrote: post #76
smokey_circles wrote: post #3

>Never stash Er, no. Right tool for the right job. Whilst I agree that the idea of putting differing lines of work into different branches is great, that's not what stash is for. That's what checkout is for. Stash is used to record the current state of the working directory and index while also returning to a clean working state. I guess for the author, stash is used to preserve changes when pulling in upstream chang…

>Never stash Er, no. Right tool for the right job. Yup. pull --rebase --autostash for example. Technically also stashing, and would be insane not to use it :) More serious note: agreed. I use stashing multiple times a day and never have problems with things being messy. Though I admit I usually look t stashed in a gui, not from the terminal.

And another episode of "how did I not know git did this". Thanks for this.

Re: This is how I git

#83

Post by cjfd »

linuxftw wrote: post #78
cjfd wrote: post #35

The ease of branching has people treat branches as if they were cookies. You cannot possibly have too many of them. But, actually, branches make refactoring more difficult. What if one person just added a parameter to a function while another person is adding new calls to that same function. The automated merge cannot fix this conflict. The KISS principle that is the corner stone of all software development would dic…

> What if one person just added a parameter to a function while another person is adding new calls to that same function. The automated merge cannot fix this conflict. If you're working in a large codebase and the function in question is part of your API, don't mutate it, add another function and deprecate the older function. In any case, either developer A or developer B has to pay the cost of mutating the function…

The point is that the problem is the smallest if the times between the point where A and Bs changes get into the mainline is the smallest. If A adds his parameter on Monday and B adds that same day three new calls and on Tuesday both merge their changes three calls need to be adjusted. If they merge on Friday and B has added three more calls on every day before Friday they have to adjust 12 function calls. Also, when B does not agree that the addition of a parameter is a good idea they can discuss this on Tuesday but otherwise they may wait doing this until Friday. It is also good to get this discussion out of the way as soon as possible. What if they decide that indeed the parameter that B added was good as such but actually needs to be of a different type? In the meantime B also has perhaps also added 12 calls to the function. These 12 calls now also have to be adjusted alongside with the 12 calls in the code of A. The general idea is that one wants to diverge from mainline for the shortest amount of time possible. I think the optimal amount of time for diverging from the main line is one day. If it becomes shorter the problem becomes that one would also need code reviews more then once a day and that becomes a bit burdensome too but code review every day generally sounds like a good idea. Preferably one should also pick a fixed time of the day for the code review. At my previous job I would do this and produce perhaps 10 small commits a day that would all get into the main line the next morning. If everybody does that one minimizes the size of possible conflicts.

Re: This is how I git

#84

Post by berkes »

lifthrasiir wrote: post #28

> The downside with not using the merge button is that the message in the PR says “closed by [hash]” instead of “merged in…” which causes confusion to a fair amount of users who don’t realize it means that it actually means the same thing! I consider this is a (long-standing) GitHub UX flaw. This is so true, if the automatic detection of the PR merger vs. closure is hard (and I can see some reasons why) there should…

Does anyone know if there is a issue-tracker where this is reported? I'd love to +1 that.

This UX-flaw is why I'm currently "forced" by my coworkers to use the buttons on GH. My git merge-scripts have some "cleanup" which I now need do manually (and thus get forgotten) for example.

Re: This is how I git

#85

Post by celeritascelery »

adimitrov wrote: post #30
formerly_proven wrote: post #20

> I use git almost exclusively from the command line in a terminal. Is certainly key. Most git frontends seem to be really quite bad for many reasons. Though "Push failed, want to pull, merge and push again? [Yes]" => constant "merged ssh://upstream.server/foo/bar/repo.git merged into branch master" commits being added to the history certainly irks my OCD the most. These frontends also seem to try and hide what git d…

I would like to say that not all git front ends are like that. I used to be a CLI only user, but now you can pry magit from my cold, dead hands. It's very close to the command line in what it does, it's very easy to see what exactly it does, and where it abstracts from git commands, it does so while following Git's mental model very well. It has great discoverability while at the same time being an amazingly streamli…

The thing I love about magit is that it teaches you how git works instead of trying to hide it from you.

Re: This is how I git

#86

Post by hibbelig »

brmgb wrote: post #16
smokey_circles wrote: post #3

>Never stash Er, no. Right tool for the right job. Whilst I agree that the idea of putting differing lines of work into different branches is great, that's not what stash is for. That's what checkout is for. Stash is used to record the current state of the working directory and index while also returning to a clean working state. I guess for the author, stash is used to preserve changes when pulling in upstream chang…

I don't understand your comment about tools. Checkout is a git command (with an admittedly terrible ux). It is not part of git data model. Like the article writer, I never myself use stash. I personally don't understand why they were added to the git ux. I think they needlessly make git more complex. Under the hood, a stash is just a commit anyway. You might retort that this is an implementation detail but as usual w…

I use stashes via the autostash feature. For unspeakable reasons, I have to have locally modified files in my repo to run the software and the tests. (Of course, it shouldn't be like this.)

So I can `git pull --rebase --autostash` and this works even with local modifications.

Re: This is how I git

#87

Post by lastofthemojito »

> Ordinary days, I issue git commands several hundred times.

I wonder if this is an exaggeration, or if the author truly has that git-heavy of a workload?

Assuming you're working an 8-hour day, that's 480 minutes. If you're issuing "several hundred" git commands, I'd take that to mean a minimum of 300. So that's a git command every 96 seconds. When do you have the time to write the actual software in between all of those git commands?!

Re: This is how I git

#88

Post by theamk »

MaulingMonkey wrote: post #48
smokey_circles wrote: post #3

>Never stash Er, no. Right tool for the right job. Whilst I agree that the idea of putting differing lines of work into different branches is great, that's not what stash is for. That's what checkout is for. Stash is used to record the current state of the working directory and index while also returning to a clean working state. I guess for the author, stash is used to preserve changes when pulling in upstream chang…

> You could commit and rebase and all sorts of clever mangling of the history. > OR you could use the right tool for the job Stashes are just another form of DAG node with their own special syntax and commands and quirks. I've already learned one set of commands for all that, why learn a second, less general set of commands? I have started using stashes in one very specific case: 1. I realize I'm on the wrong branch…

stash is supposed to be a short term thing, if you are doing the whole "apply/verify/list/drop" cycle, named branches are a superior approach.

I find the power of the stash in "stash pop", which applies, and drops if there were no conflicts:

    git stash push
    git checkout -b newbranch upstream/right
    git stash pop
and yeah, if your keep your branches long-term stash is not a good solution for this.

Re: This is how I git

#89

Post by smokey_circles »

smokey_circles wrote: post #3

>Never stash Er, no. Right tool for the right job. Whilst I agree that the idea of putting differing lines of work into different branches is great, that's not what stash is for. That's what checkout is for. Stash is used to record the current state of the working directory and index while also returning to a clean working state. I guess for the author, stash is used to preserve changes when pulling in upstream chang…

Well this blew up and lots of you missed the point

> right tool for the right job

I'll give you that this is (slightly) ambigious. But here's the gist

>you can safely ignore the opinion of anyone who says "never do X"

There are lots of alternative tools listed in this comment tree.

Stash has a purpose. You should know what that purpose is. A tool is only as good as its user

Re: This is how I git

#90

Post by smokey_circles »

MaulingMonkey wrote: post #48
smokey_circles wrote: post #3

>Never stash Er, no. Right tool for the right job. Whilst I agree that the idea of putting differing lines of work into different branches is great, that's not what stash is for. That's what checkout is for. Stash is used to record the current state of the working directory and index while also returning to a clean working state. I guess for the author, stash is used to preserve changes when pulling in upstream chang…

> You could commit and rebase and all sorts of clever mangling of the history. > OR you could use the right tool for the job Stashes are just another form of DAG node with their own special syntax and commands and quirks. I've already learned one set of commands for all that, why learn a second, less general set of commands? I have started using stashes in one very specific case: 1. I realize I'm on the wrong branch…

Good points all round.

But what I'm not doing is saying "you should always use stash". I'm providing use cases, for me personally, where stash is the correct approach.

"Ah", but you might be inclined to argue, "such and such a reason". Yes, but also no.

Right tool for the right job is also an argument for competency and context. Sometimes a hammer is useful for more than just hammering, but very rarely.

The point is there is usually more than just 1 approach, and niche/edge cases can be real nasty if approached with the attitude that everything is a nail

Post reply on HN