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

What comes after Git

matt-rickard.com

Post reply on HN
Print view View original

81–90 of 430 posts

Re: What comes after Git

#81

Post by alexchamberlain »

torginus wrote: post #51
roganartu wrote: post #21

Earlier quoted context omitted.

Perhaps this is a byproduct of the UI (which I totally agree is bad), but this is not true. `git reflog` contains a full history of all refs you’ve been on in chronological order. Unless you explicitly delete them, dangling refs are not cleaned up immediately. If you rewrite history and realise you made a mistake, you can likely recover by simply resetting the mutated branch to something from the reflog, even days or…

You learn something every day!

Another super simple technique is to create a branch where you start to go back to if you need to; ie if you are rebasing `foo`, start by running `git branch foo-back` and you can always reset back there if needed.

Re: What comes after Git

#82

Post by irrational »

> Will a new version control system (or something that solves similar problems) spring up?

Of course. There is no way Git is the be all and end all of version control. Anyone who has been around long enough has seen lots of version control systems and knows that we will see lots more as time goes on.

Re: What comes after Git

#84

Post by vaughan »

enasterosophes wrote: post #58
lloydatkinson wrote: post #46

Earlier quoted context omitted.

What’s wrong with the author?

Well, you can look at the author's past HN submissions to see what was meant. It's basically click-bait for hackers. "How to do X technology better" with a few paragraphs of ideas, and taking no responsibility for actually doing something about it, aside from hoping that their vision might inspire someone else to put in the hard work.

Why do they have to take responsibility? I can point to so many oss projects where someone else’s vision was implemented.

Re: What comes after Git

#85

Post by bmitc »

alexchamberlain wrote: post #76
madmax108 wrote: post #37

I personally believe that making diffs more human friendly is the next step of evolution we need. I work with a team on a NodeJS+React project and nearly every other PR shows up as "Something changed in package.json, something changed in package-lock.json, some static assets added/modified, some JSON changed" etc and it makes reviewing code quite unwieldy (esp. since it forces folks to use Github UI interface to even…

I feel like you may be blaming the tool for a social problem there. We have a simple rule: no changes to package* in a feature PR. Adding a dependency? Cool, upgrade everything first, then add it fresh. (Be reasonable there- the idea is that the add should be clean, so if that can be done without doing a major upgrade, that is of course fine.)

It sounds like you're just working around the limitations of the tools.

Edit: I think it's possible that I misunderstood, given the downvotes. I thought they meant that a dependency should be added in one PR, and then the feature needing that dependency in a separate PR. What I think they actually meant is that if adding a dependency requires upgrades of other dependencies, then upgrade the existing dependencies in one PR and then add the new dependency and feature in another single PR. That seems to make sense but not be necessarily a hard rule.

As I said below though, I still think the tooling in this space is terrible. Even for dependencies, I don't want line and text changes in config and lock files. I want something that summarizes what dependencies were added or upgraded.

Re: What comes after Git

#86

Post by oivey »

CuriousCosmic wrote: post #53
oivey wrote: post #44

Earlier quoted context omitted.

Rebasing other’s stuff feels gross since it is altering externally visible history. Rebasing your own stuff before you push can make commits more clear, understandable, and meaningful. git pull —rebase is pretty unobjectionable. How does rebasing break bisect?

Presumably they are referring to how the `--first-parent` flag works as it only uses the head of the branch from a given merge instead of including each commit from the merge. Some projects prefer rebasing onto master instead of merging onto master or squashing onto master. If you rebase onto master but don't clean up the commits at the end of the PR, this litters master with a bunch of "top level" commits that don't…

Makes sense. I guess I just implicitly assumed the workflow of rebasing personal stuff and usually merging externally visible stuff.

Re: What comes after Git

#87

Post by hackernewds »

irrational wrote: post #82

> Will a new version control system (or something that solves similar problems) spring up? Of course. There is no way Git is the be all and end all of version control. Anyone who has been around long enough has seen lots of version control systems and knows that we will see lots more as time goes on.

Especially given how primitive git still seems. I, for one, can't wait

Re: What comes after Git

#88

Post by alexchamberlain »

bmitc wrote: post #85
alexchamberlain wrote: post #76

Earlier quoted context omitted.

I feel like you may be blaming the tool for a social problem there. We have a simple rule: no changes to package* in a feature PR. Adding a dependency? Cool, upgrade everything first, then add it fresh. (Be reasonable there- the idea is that the add should be clean, so if that can be done without doing a major upgrade, that is of course fine.)

It sounds like you're just working around the limitations of the tools. Edit: I think it's possible that I misunderstood, given the downvotes. I thought they meant that a dependency should be added in one PR, and then the feature needing that dependency in a separate PR. What I think they actually meant is that if adding a dependency requires upgrades of other dependencies, then upgrade the existing dependencies in o…

Simply separating concerns so that each PR/commit focuses on 1 thing.

Re: What comes after Git

#90

Post by nathants »

git is like cpp, you have to use a subset:

- push

- pull

- checkout

- checkout -b

- merge —ff-only

- stash

- stash pop

- reset —hard origin/master

- reset —soft $hash

- commit -m

Post reply on HN