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

111–120 of 140 posts

Re: This is how I git

#111

Post by karyon »

ufo wrote: post #66
jgraham wrote: post #51

Earlier quoted context omitted.

If you have tooling to support it, rebase-and-ff-merge is perhaps an even better workflow. In this model every commit on the main branch has a first parent that's the previous merge, and a second parent that's a linear set of the commits that were landed together, with the parent of the first commit being the previous state of master. This has the following advantages: * It's clear which states master has actually be…

Does anyone know how to make this "cactus" workflow work better on github? We use it in our organization and between us we know to always manually rebase before merging. However, when we receive an external PR from someone else it's a pain. It's also easy to accidentally forget to rebase before merging.

I don't know a way to enforce this, but what may help is knowing that by default, you can push into the PR branch even if it is from someone else's fork: https://docs.github.com/en/free-pro-team@latest/github/colla...

Re: This is how I git

#112

Post by wutbrodo »

theamk wrote: post #88
MaulingMonkey wrote: post #48

Earlier quoted context omitted.

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

Yea, exactly. The author's git workflow is eerily like the one I've converged too over a decade, but "never stash" (without acknowledging the existence of the quick stash use-case) is wrong enough that it's enough to give me pause about his general competency with git (or more likely and more charitably, that he just didn't put too much effort into that section of the article).

The advantage of stash is that it's quicker and easier than creating and cleaning up branches. If you're naming stashes and keeping them longterm, then you're basically using them like branches and should consider what benefit you're getting from adding a separate workflow.

Re: This is how I git

#113

Post by wool_gather »

gtsteve wrote: post #23
yarcob wrote: post #8

Earlier quoted context omitted.

The problem with stash is that its easy to create a mess. Yes, it's useful to quickly stash your work, switch to a different branch, do some quick fix, then go back to your original branch. But in practice, what often happens is that your quick fix takes way longer than expected, and you don't immediately go back to your original branch. Then you pull in some changes, maybe someone else pushed something to the branch…

I personally only use stashes when I've given up on my current approach and want to reset but I might change my mind later (rarely happens). I don't think they're appropriate for stuff you want to keep across branches, there's no real visibility and they'd be easily forgotten.

I don't think there's anything wrong with stashes, but there's another interesting trick that you might want to try for this purpose: commit the dead-end, then immediately make a revert commit. You can even add a rationale in the revert commit message.

The technique is not applicable all the time, but for those instances when you really think it's valuable to preserve the knowledge that was gained in trying and abandoning a particular approach it's great.

Re: This is how I git

#114

Post by dreamcompiler »

hibbelig wrote: post #92
dreamcompiler wrote: post #67

I find stashes quite useful and intuitive. For me, rebasing is the root of all evil.

As soon as two people work on the same branch, rebasing becomes a problem. As long as you're the only one modifying the branch, rebasing works nicely.

I don't like rebase in solo code either; I want my personal history to be the truth, not some convenient fiction.

In a team environment, somebody always insists on using rebase and then invariably they push a rebase to master and hijinks ensue. I wish there was a fork of git with rebase disabled.

Re: This is how I git

#115

Post by Huggernaut »

barumi wrote: post #74
Cogito wrote: post #54

Earlier quoted context omitted.

I don't know what you think git-flow is, but a linear history it is not. Look at any post on git-flow (or even just the original [0]), and you will see a myriad of merges. Quoting the original git-flow post: > When the source code in the develop branch reaches a stable point and is ready to be released, all of the changes should be merged back into master somehow and then tagged with a release number. How this is don…

> I don't know what you think git-flow is, but a linear history it is not. Your statement makes no sense at all. Gitflow is a workflow. What do you believe it's supposed to be? It's irrelevant how you see commit histories, because with regards to the master/mainline branch it's always linear, isn't it? What do you personally believe gitflow is? > Quoting the original git-flow post: I don't know what you expected to s…

The person you are responding to is only making the point that the OP's rebase flow is a very different workflow from git-flow. The pros and cons of each approach are significantly different, and the commit history will demonstrate the two different approaches.

Re: This is how I git

#116

Post by darekkay »

dreamcompiler wrote: post #114
hibbelig wrote: post #92

Earlier quoted context omitted.

As soon as two people work on the same branch, rebasing becomes a problem. As long as you're the only one modifying the branch, rebasing works nicely.

I don't like rebase in solo code either; I want my personal history to be the truth, not some convenient fiction. In a team environment, somebody always insists on using rebase and then invariably they push a rebase to master and hijinks ensue. I wish there was a fork of git with rebase disabled.

> I want my personal history to be the truth, not some convenient fiction.

I am mostly using the Git history when going through past changes. Why does this line do X? I just git blame this line and see exactly what happened. This is the time I really hate all those "oops, fixed mistake" and "forgot this change" commits. I don't care about those things, even if it's the "truth". They're just useless and distracting. Doing an amend/rebase/squash would have been perfectly fine in such a scenario. I have written more about rewriting Git history here [1].

> In a team environment, somebody always insists on using rebase and then invariably they push a rebase to master and hijinks ensue. I wish there was a fork of git with rebase disabled.

That's why shared branches like master are usually protected, so you cannot push an alternative history.

[1] https://darekkay.com/blog/git-rewriting-history/

Re: This is how I git

#117

Post by darekkay »

greggman3 wrote: post #50

only related by "git" but while I believe i'm fairly proficient in git I'm not sure how to go about explaining to an inexperienced person how to fix a merge conflict. It feels like not a simple thing to explain. As an example someone sent me a PR with 15 commits. github claims only 1 file has changed and it's a new file so no conflicts (which AFAIK is correct) but git complains that somewhere around commit 4 there's…

I can relate, and I don't think there's a way around learning Git properly. Here's a quote from a post of mine:

> Version control is an underrated skill. Most software engineers use it daily, and yet, many are not willing to invest more than necessary to learn it. That’s fine, but knowing more than commit/push/pull will at least make you more efficient. It will also help you solve issues you (and your colleagues) may encounter.

I've had this issue a lot in the past, but mostly at work. So yes, I will spend the time to help my colleague debugging their issue. Eventually, they will get fewer issues, but the time I have to spend for their "learning by doing" would have been better invested in learning Git fundamentals.

I've also had some open source contributions during Hacktoberfest, and I went with the easy way out of doing the clean-up work myself. But as you've stated, people might not learn from this, so that's not optimal.

Re: This is how I git

#118

Post by acoard »

lastofthemojito wrote: post #87

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

I decided to explore this a bit. In reality, it's not that the git commands are spaced out equidistantly, it's that you have a flurry of git activity then go back to coding.

So, an individual commit can easily hit 5 commands. I always do a `git status` before and after (2), plus maybe a few git adds (2), the commit (1), then potentially a push (1). That's already 6 commands for each commit. In a day I usually do approx 15 commits(±10), as well as re-bases. That's around 90 git commands just for committing. Through in a few rebases, a fetch, and an amend, and you're easily over 100.

The quoted OP said "several hundred" commands. Just with commits on a pretty typical workflow, I'm at over a hundred. It doesn't surprise me that someone could double it.

I often wear the hat of the "git expert" on a project, and there are some days I'm doing significantly more than just commiting and pushing code too. I have a lot of extra commands I'll run like `git log HEAD..@{u}` which shows the diff in the logs between my current branch and the upstream. And I use `git diff --cached` pretty heavily. Git blame is also invaluable when debugging. These tools don't take a way from actually writing software, they enhance it.

Re: This is how I git

#119

Post by l0b0 »

I suspect OP meant `PS1='\u@\h:\w\$(brname)\$ '` rather than `PS1="\u@\h:\w\$(brname)$ "`:

- double quoting the command expansion would lead to `brname` being executed once at shell startup (unless this assignment is happening in a `PROMPT_COMMAND` function or something[1]).

- A literal backslash before the dollar sign gives a "#" at the end of the prompt for root.

[1] https://gitlab.com/victor-engmark/tilde/-/blob/4dc4077a19250...

Post reply on HN