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

511–520 of 550 posts

Re: New in Git: switch and restore

#511

Post by ekster »

wizzwizz4 wrote: post #273
foepys wrote: post #212

Earlier quoted context omitted.

This is only true until the first merge conflict or when you want to know when a bug was introduced to even find its location.

All things I know are possible. I understand Git's architecture , just like I know what an inode is. I could re-implement my own (bad) version control system, if I wanted to, just like I could make my own (bad) filesystem. But that doesn't mean I need to have memorised the CLI invocations. There's a button in Git GUI for all the things I need to do (including the things you've listed), and in the rare case where I ne…

Thats a quite different statement from vcs not being a tool you use. At least how I read it.

Re: New in Git: switch and restore

#512

Post by WorldMaker »

Shacklz wrote: post #493
dotancohen wrote: post #482

Earlier quoted context omitted.

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…

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

git log --first-parent gives you a nice linear history of (generally) your top level merge commits. If you follow a PR workflow, it's PR-by-PR breakdown of activity. The DAG gives you the power to "explore the spiderweb" if want/need to, but also pull back and say "give me the high level over" (--first-parent). I still think a lot of the emphasis on rebase-only workflows would disappear if more of the graphic UI tools (including and especially GitHub) had a better --first-parent experience by default. With the GitHub PR flow it has always surprised me that the main commit log isn't just a --first-parent view with an optional drilldown experience.

Re: New in Git: switch and restore

#513

Post by CRConrad »

IgorPartola wrote: post #487
CrazyPyroLinux wrote: post #229

Earlier quoted context omitted.

Yup - Every darn time. Reminds me of "How it feels to learn JavaScript in 2016" https://news.ycombinator.com/item?id=12628921

Nothing has changed in 5 years, has it?

Let's hope not, then I can use it as a template.

Re: New in Git: switch and restore

#514

Post by CRConrad »

jjnoakes wrote: post #244
voakbasda wrote: post #136

Earlier quoted context omitted.

Any developer demonstrating that level of daily incompetence with their basic tools of the trade should never be allowed to write code. The fact that this level of incompetence seems the rule rather than the exception speaks to the rather terrifyingly pathetic state of software, where badly engineered systems end up killing people. Source: firmware engineering consultant that cleans up messes like these for some of t…

In my opinion this is way too much gate keeping. Who defines which tools are "basic tools of the trade" and which are just bland infrastructure? And who decides how much of each tool one should know to move beyond "daily incompetence"? If I'm getting the job done and produce more net value than my peers for my salary, why should there be requirements on how well I know some specific tool? I'm willing to bet a ton of…

> In my opinion this is way too much gate keeping.

> Who defines which tools are "basic tools of the trade" and which are just bland infrastructure?

Well, if so many people routinely have so much difficulty with it as these comments witness, it can hardly be called "bland."

Re: New in Git: switch and restore

#515

Post by nbjoerg »

sharken wrote: post #497
nbjoerg wrote: post #456

Earlier quoted context omitted.

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/

Funny, I rarely use branches (or topics) in Mercurial unless it is a complicated long-term project. Modern "everything on a branch" was invented by git users because the UI forces naming things. Mercurial allows sharing code and still linearizing history with rebase safely, so much less need for merges. I've always found pull requests to be only useful for the passing-by contribution. They are a pretty awful interface for anything else driven by GitHub internals more than anything else...

Re: New in Git: switch and restore

#516

Post by CRConrad »

sharken wrote: post #335
eloisant wrote: post #306

Earlier quoted context omitted.

No, we use it because it's superior to the competition. It's much better than Subversion that was the standard before git arrived. And it's much better than Mercurial that was competing to become the source control system to replace SVN.

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.

> Pull Requests were never going to happen with Mercurial

TBF, AIUI they're not, strictly speaking, happening with git either: They're an external addition, invented by GitHub or some such, and not actually part of git itself.

Re: New in Git: switch and restore

#517

Post by CRConrad »

jonwinstanley wrote: post #215
akx wrote: post #206

These features were introduced in 2019 (and have been featured in git's help texts since). Serious question - Why is it that they're called new two years later? Is it that no one cares to read git's prompts or release notes?

The author did say that had only recently discovered these commands. Unsure why they said they were new, maybe they were kidding?

"New" as in new to them, I'd guess.

Re: New in Git: switch and restore

#518

Post by CRConrad »

biryani_chicken wrote: post #407

I remember learning `git checkout` checked out files from a specific branch and the default behavior was to checkout all the files of the current branch and it made sense except for one thing. If I check out one file from another branch, HEAD is still pointing to my current branch, if I check out all but one file from another branch it's the same, but if I check out all files, then HEAD points to the other branch and…

But in your terms, a branch is the files it contains. Or rather: Changes gathered in a commit can be changes to several files. A branch is just a chain of commits, each based on the previous ones. So what a branch "is", is a bunch of (bunches of) changes to one or more files. Therefore, "checking out a branch" is checking out (a bunch of changes to) one or more files. And now you want to "check out one file from another branch"... Is it really any wonder that doesn't make much sense?

I think your doing yourself a disservice by even thinking in terms of "checking out a file" as separate from checking out a branch. The units git deals in are commits and branches, not really individual files as such. If you want to use it, better get used to thinking in the same units it does.

Re: New in Git: switch and restore

#519

Post by CRConrad »

hsn915 wrote: post #53
thecupisblue wrote: post #38

Earlier quoted context omitted.

Doesn't seem overloaded, seems quite fitting. Checkout a hash or a file from a hash. Switch kinda seems "underloaded" in this way.

Yea it never bothered me and I never understood why people kept complaining about it online. It seemed very superficial complaint. The way you use git is by first understanding its model. If you understand the git model, everything makes sense. If you come to it expecting it to be a tool that magically does what you want, I guess you will be very disappointed.

> Yea it never bothered me and I never understood why people kept complaining about it online. It seemed very superficial complaint.

Consistency may be superficial to you, but that's a personal preference that not everyone shares.

> The way you use git is by first understanding its model. If you understand the git model, everything makes sense

Doesn't follow. I think I've got at least an acceptable handle on git's model, but I can't see how that should mean I'd have to accept that wildly inconsistent command switches "make sense". Care to explain how one leads to the other?

Post reply on HN