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

New in Git: switch and restore

banterly.net

Post reply on HN
Print view View original

491–500 of 550 posts

Re: New in Git: switch and restore

#491

Post by ivanche »

mixmastamyk wrote: post #435
Shacklz wrote: post #131

Earlier quoted context omitted.

> Figuring out what "properly" means is the whole problem with git. I think you've missed OPs point by focusing too much on a single word ('properly'). Yes, there's no clear-cut way on how to use git, no silver bullet, but the main problem with git is that most devs simply panic when they have to do anything that goes beyond the bog-standard commit/pull/push/merge. Rebase? Squash? Reset? Rebase interactively? I think…

I've tried the "rebase into a feature branch" workflow, which I think you are alluding to. Unfortunately, it always results in scary conflicts. So I go back to merging the main branch into my feature branch workflow, which works every time. I then hit squash in gitlab for my merge request, and no one is the wiser. Should I be doing something different? As I said, rebase in that situation is disastrous. Many folks rec…

> I've tried the "rebase into a feature branch" workflow, which I think you are alluding to. Unfortunately, it always results in scary conflicts.

You never rebase something into something else, you rebase onto something. I suppose you meant you want to rebase feature branch onto master.

If you have conflicts, you'll have them anyway, regardless if you're merging feature branch into master, merging master into feature branch or rebasing feature branch onto master. Conflicts are not a consequence of rebasing.

Re: New in Git: switch and restore

#492

Post by rwallace »

sossles wrote: post #393
rwallace wrote: post #388

Earlier quoted context omitted.

Now I'm curious: why? Not that I don't believe you, but I'm wondering what is the reason? It's not intuitively clear why gloves would make it more dangerous, even knowing that it is.

If a glove comes into contact with a spinning blade, there is a good chance it will pull the rest of the glove, and the hand within it, right into the path of the blade.

Aha! That is one of those things that never crossed my mind, but makes perfect sense once explained.

Re: New in Git: switch and restore

#493

Post by Shacklz »

dotancohen wrote: post #482
mixmastamyk wrote: post #435

Earlier quoted context omitted.

I've tried the "rebase into a feature branch" workflow, which I think you are alluding to. Unfortunately, it always results in scary conflicts. So I go back to merging the main branch into my feature branch workflow, which works every time. I then hit squash in gitlab for my merge request, and no one is the wiser. Should I be doing something different? As I said, rebase in that situation is disastrous. Many folks rec…

I've never understood - or used - rebase as a standard part of a workflow. And I've been using git for nine years. What is wrong with a master branch whose history reads "Merged feature foo" after "Merged feature bar"? If you need more detail then check out the feature branch and git bisect to your heart's content. I do wish that we could "archive" branches from the output of `git branch -a` but really it's not a big…

I had this opinion for the longest of times as well, but me and all the other devs I know who started using a rebase-based approach just don't want to go back.

I think it's also a bit a question of team size. If your project has just a handful of devs working on it, merge-commits really don't matter all that much. If there are a few dozen with a good amount of juniors on the repo (a bit over 40 devs in my case), the commit-history becomes an absolutely unreadable spiderweb, that's at least my experience.

At work, we want to move towards trunk-based development (merge to master goes straight to prod), but whenever master was broken, a look at the commit-history didn't really all tell you that much about the who, how and why without checking it out and digging into it. So we've recently started to enforce linear history, in which case it is immediately obvious without the shred of a doubt who's responsible. Analyzing the build became an absolute breeze, at the cost of having a bit of a harder time at "insertion"-point (which is perfectly fine, given the fact that after merge, it should eventually go straight to prod).

It took a while to get everyone on board, but it was really worth the efforts and can only recommend it (I most definitely will prefer a workplace that is open to such practices in the future). In general, most devs were also quite happy to be guided through the process, as it is clear that git is probably one of the longer-lasting constants in our industry.

Also, I can't repeat it enough; speaking from experience, most devs severely overestimate the complexity of cherry-pick/rebase/reset/reflog etc. Whenever I had sessions explaining it or helping someone out with a problem, they had their first "aha!"-moments after a few minutes, and after that with some do-it-yourself-experience most of them get there rather fast. Obviously, there are always a few outliers who need a little bit of extra-nudging and extra-help to stay in line, but those are usually the ones who often also need that sort of assistance in other areas so that's okay.

Re: New in Git: switch and restore

#494

Post by filoeleven »

quietbritishjim wrote: post #378
filoeleven wrote: post #204

Earlier quoted context omitted.

SourceTree doesn’t give up. It tells you that you have conflicts to resolve. Once you do, “continue rebase” does what it says, either until the rebase completes or until it hits another conflict.

Does it show a GUI, analogous to [1], or tell me to sort it out myself on the command line? I'd it's the latter then that's very much giving up. On the other hand, it's possible I'm mixing it up with some other GUI I tried.

If a rebase encounters conflicts, it tells you as much, puts every piece of the commit that it could auto-merge into the index, and adds conflict markers to what it couldn’t in the working tree. Then it’s up to you to merge them in an IDE or Optionally (I think) choose yours / theirs for each hunk. Once everything is resolved and moved to the index, “continue rebase” goes on to the next commit.

I think it’s had a rebase GUI since I first started using it in 2013. It may not have had one back then for interactive rebase, or else it didn’t work for me, but it does now.

Re: New in Git: switch and restore

#495

Post by filoeleven »

quietbritishjim wrote: post #480
quietbritishjim wrote: post #378

Earlier quoted context omitted.

Does it show a GUI, analogous to [1], or tell me to sort it out myself on the command line? I'd it's the latter then that's very much giving up. On the other hand, it's possible I'm mixing it up with some other GUI I tried.

[1] was meant to be this, which is the TortoiseHg merge conflicts window: https://i.stack.imgur.com/kaFNz.png

It’s not as nice as that one. I described it in my other comment. The workflow is okay, but that visual context of to/from branches in your screenshot is something I wish SourceTree had.

Re: New in Git: switch and restore

#496

Post by void_mint »

ivanbakel wrote: post #455
_6pvr wrote: post #428

Earlier quoted context omitted.

I've always found it interesting that Git gets a pass for its horrible UX by so many devs. The programming community wants to provide too many options for _everything_. If there's a tool you don't like, there are probably 10 other versions that do similar enough things that you can just switch. Devs are harshly critical of tools. And yet, with Git, the response just seems to be "if you don't like it you must just not…

>And yet, with Git, the response just seems to be "if you don't like it you must just not _get it_." Which, I guess is fair, but I don't particularly understand why everyone has to "get it"? Why can't we expect a tool that's used by so many be intuitive? There are lots of UIs for git - many people on this forum will advocate for using one. My personal experience is that a UI manages to over-simplify the git workflow.…

> And that's a problem with lots of technical teaching, not just git. Since the focus is on getting immediate observable results, and not on conceptual understanding, users tend to learn how to use tools instead of how they work. That creates a culture of "I don't know what this is doing, and I'm too scared to mess with it" - basically the anti-hacker mentality.

yeah I guess I don't really align with the "Developers must learn the internals of all of the technology they are required to touch", and I don't really agree with the sentiment that that decision disqualifies one from "hacker mentality".

Re: New in Git: switch and restore

#497

Post by sharken »

nbjoerg wrote: post #456
sharken wrote: post #335

Earlier quoted context omitted.

As someone about to migrate from Mercurial to Git i absolutely agree that Git is the superior tool. Pull Requests were never going to happen with Mercurial and it's also not possible to delete a branch without some black magic server-side. And with Git hopefully it will be possible to move to Trunk-based development, although that requires a lot more than just switching to Git.

There are at least two different commercial hosting sites that implement a pull request model. If you want ephemeral branches like in git, hg branches are indeed not the right choice. But that doesn't mean that they don't have their place. Try topic or bookmarks if you want gitish behavior.I have absolutely no clue what you mean with trunk-based development...

We might have been able to do pull requests in Mercurial, but were using a special tool to manage multiple Mercurial repos.

Trunk-based development is where you use a single branch for development, instead of multiple branches that you have to merge between.

More info at:

https://trunkbaseddevelopment.com/

Re: New in Git: switch and restore

#498

Post by cerved »

schlupa wrote: post #424
jen20 wrote: post #149

Earlier quoted context omitted.

I’d add another reason to that: we’re using Git because BitKeeper wasn’t free (as in beer) at the time for general purpose use. Had it been, we’d all be using BitKeeper instead.

Probably not. The free (as in speech) part of git is what made it usable for entities like google, Microsoft, github etc. If git had been released with the same license model of BitKeepr it NEVER would have taken off.

perhaps they were referring to the fact the kernel used to run bitkeeper as VCS but the licensing prohibited development

Re: New in Git: switch and restore

#499

Post by CRConrad »

pdimitar wrote: post #439
web007 wrote: post #416

Earlier quoted context omitted.

Don't use it blindly. Learn it enough that you understand those mystical incantations and aren't summoning Cthulhu by accident, only on purpose Don't cookbook it, understand what the thing you're typing means. Don't use a GUI to abstract it away, be familiar with the CLI and what it's doing. Don't default to rm-rf when you get stuck, check git reflog and see if you can unfuck yourself first. Ask someone who doesn't h…

In my eyes all you did with this comment is join the people your parent poster is arguing against; you kind of just reiterated the stance they don't like. Not sure how constructive such a comment is. > it's the people familiar with "what does pull --rebase really do?" that don't get into trouble and/or can get themselves back out of trouble Absolutely not my experience. No small amount of people who seem to be doing…

What's with the weird capitalisation; is git suddenly an acronym or something?

Re: New in Git: switch and restore

#500

Post by pdimitar »

CRConrad wrote: post #499
pdimitar wrote: post #439

Earlier quoted context omitted.

In my eyes all you did with this comment is join the people your parent poster is arguing against; you kind of just reiterated the stance they don't like. Not sure how constructive such a comment is. > it's the people familiar with "what does pull --rebase really do?" that don't get into trouble and/or can get themselves back out of trouble Absolutely not my experience. No small amount of people who seem to be doing…

What's with the weird capitalisation; is git suddenly an acronym or something?

Nope, just my way of making sure it's recognized in a sentence.
Post reply on HN