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

Is Git Irreplaceable? (2019)

fossil-scm.org

Post reply on HN
Print view View original

431–440 of 559 posts

Re: Is Git Irreplaceable? (2019)

#431

Post by wasdfff »

metabagel wrote: post #420
munmaek wrote: post #387

Earlier quoted context omitted.

With the amount of information available, there is no excuse: * https://rogerdudler.github.io/git-guide/ * https://git-scm.com/book/en/v2 Also see stackoverflow. Git is a complex tool because it’s tackling a complex problem. I don’t see a way of making it “easier” without massively reducing what it can do. It’s like saying we should reduce a formula one car so people can use it without reading up on it, etc. If somet…

Git isn’t something which you can generally be successful using in a shallow way. Most developers will need to devote significant time and energy to mastering it. There really needs to be a better layer on top of it in order to make it easier for developers to figure out how to do what they want to do. Some of the commands and switches don’t seem to be orthogonal and/or intuitive.

A lot of people get by just staging and pushing/pulling commits, myself included. That’s 3 commands, 4 if you count git status. You do not need to dig deep to get a lot of use out of git as a basic remote sync.

Re: Is Git Irreplaceable? (2019)

#432

Post by jnurmine »

alkonaut wrote: post #228
tasuki wrote: post #199

> I worry that Git might be the last mass-market DVCS within my lifetime. The possibility of git being the last mass-market DVCS within my lifetime leaves me with warm fuzzy feelings. Git is simple and elegant, though its interface might not be.

I think it's simple and elegant as a data structure, when what people need and want is something that is (at least also) simple and elegant in its UX and most importantly VERY simple and elegant for the 80/20 use cases. For example a typical question on Stackoverflow is "How do I answer which branch this branch was created from", always has 10 smug answers saying "You can't because git doesn't really track that, bran…

Maybe for your particular problem it's worthwhile to setup a CM policy for the (topic) branch naming. For example in your case something like: topic/alkonaut/version-1.0/foo or topic/alkonaut/master/bar.

Or use something like: git log --all --graph --oneline

One tip for "zigzag spiderweb" is to always rebase your topic branch to the target branch prior to a fast-forward merge to the target branch (e.g. master). To clarify: while in your branch topic/foobar: "git rebase master", "git checkout master", "git merge --ff-only topic/foobar".

(There's surely a clever shorthand for the above procedure but when it comes to the command line, I like to combine small things instead of complicated memorized things, it's some kind of Lego syndrome)

Re: Is Git Irreplaceable? (2019)

#433

Post by bytematic »

tzury wrote: post #397

Bazaar and Mercurial are dying... Bazaar is dead, and Mercurial is near death. Linus wrote the Linux kernel and it became the "de-facto standard" for web application stack servers (and phones, and watches, and Chroemcast and all sort of `Internet things`) Linus wrote git and it became the "de-facto standard" for version control. If a world had 23 more Linuses, we would have full control over our SaaS and "Clouds" and…

It's likely that there are many Linus's but they are not in positions (third-world, poverty, poor parenting, dictatorships) to achieve the same. That's why I think the biggest progress in tech/innovation will come with lifting as many people as possible out of those situations

Re: Is Git Irreplaceable? (2019)

#434

Post by mannykannot »

jerf wrote: post #396
jorvi wrote: post #382

Earlier quoted context omitted.

> make sure you commit This is not absolute gospel. If you screw up a rebase and commit, whatever you removed in the rebase is simply gone.

Are you saying that with knowledge of what "git reflog" is? I suspect not. I'd really need to see a sequence of commands that removes committed state from the repo to buy this. If you try to produce it, bear in mind the first thing I'm going to do is run "git reflog" on the result, so if you find your committed state is still there, then I'm going to say it's still saved. (That's not a git thing. I don't really even…

As I am not familiar with the details of reflog (I don't recall ever using it) I took a look at the article. I wasn't long until I reached what looks like a caveat: "This command has to be executed in the repository that had the lost branch. If you consider the remote repository situation, then you have to execute the reflog command on the developer’s machine who had the branch." Joe, who works on another continent, quit last week and his computer was a VM...

OK, so we have backups of his VM and we can recreate a clone of it, but will that be satisfactory? Are there any issues with hardware MAC addresses or CPU ids? How far down the rabbit hole of git minutiae do you have to go before you are confident that you can do all basic source-control operations safely?

Re: Is Git Irreplaceable? (2019)

#435

Post by RichardCA »

jorvi wrote: post #382
jerf wrote: post #358

Earlier quoted context omitted.

It's called "git reflog": https://www.edureka.co/blog/git-reflog/ Though you do have to have committed. One of the things I hammer on in my tutorials for work is that if you get confused in git, make sure you commit. If you commit, you can take your problem to the other engineers and we can almost certainly get you straightened away. Fail to commit, though, and you really may lose something. Also, metapoint about git…

> make sure you commit This is not absolute gospel. If you screw up a rebase and commit, whatever you removed in the rebase is simply gone.

The main thing that people fail to understand is that commits are immutable and the overall commit graph is immutable (with the caveat that pathways in the graph that don't end in a branch head are subject to garbage collection).

A rebase does not destroy information. It creates new commits and moves the branch head to a different spot on the graph.

The reason git is seen as painful is because you can't claim expertise until you develop the ability to form a mental map of the graph. But once you do this the lights turn on and everything starts to make sense.

This is why the mantra "commit early and often" still holds. The more experienced git user will tell the newer people this, so when they come with a mess it will always be recoverable.

Re: Is Git Irreplaceable? (2019)

#436

Post by wyoung2 »

smt88 wrote: post #351
mathw wrote: post #204

Earlier quoted context omitted.

I tend to think that it's fine, because I remember what it used to be like... what we have now is the "easy" UI! And they do occasionally put some new stuff in that helps. Like the recent version which adds new commands to split out the two completely different uses for `git checkout` (making/switching branches and reverting files).

Between CVS and git, Canonical releases an excellent DVCS called Bazaar that I loved. I think we all ended up with git because of GitHub.

There is zero doubt in my mind that it's Github that "made" Git. Without it, it would be just another one of many DVCSes. Git's value isn't inherent, it's all down to network effects.

Re: Is Git Irreplaceable? (2019)

#437

Post by breck »

rgardaphe wrote: post #426
breck wrote: post #319

Earlier quoted context omitted.

> Today, if I want to store data for my application, I have a choice between good support for rich object types and connections (e.g., Postgres), or good support for history and merging (e.g., Git). There's no one system that provides both. I like the way you put this. In case anyone's interested in brainstorming I'm dabbling in this problem with a thing called TreeBase ( https://jtree.treenotation.org/treeBase/ ). I…

Have you looked at Qri? ( https://github.com/qri-io ) - free & open source dataset versioning. Also: https://qri.io

AFAIK I've never seen that one. Thank you very much for the link. Looks very interesting and related to the stuff I'm working on. Thanks!

Re: Is Git Irreplaceable? (2019)

#438

Post by wyoung2 »

ben509 wrote: post #429
james_s_tayler wrote: post #117

Earlier quoted context omitted.

No VCS will be merge conflict-less without locking files. I'd rather not lock files.

I'd rather lock files, but be able to unlock them, to be able to coordinate with others and proactively reduce merge conflicts.

The only way to make that simple is to centralize the version control system so that you can have a single arbiter of who has what locked. To add easy locking to Git, you'd have to turn it back into a non-distributed VCS.

I don't think I need to sell the value of DVCS over VCS, but what seems to get lost is that buys you a certain amount of essential complexity, expressed in the CAP theorem and its consequences.

We discussed this deeply on the Fossil forum: https://www.fossil-scm.org/forum/forumpost/2afc32b1ab

We came to no easy answers, because there aren't any. You only get a choice of which problems to accept.

Re: Is Git Irreplaceable? (2019)

#439

Post by wyoung2 »

munmaek wrote: post #387
Ntrails wrote: post #332

Earlier quoted context omitted.

As a very basic git user, about once a month my local git repository will get into a state I cannot fix. I cannot revert, cannot reset, cannot make it just fucking be the same as origin/master. Usually I accidentally committed to local master and then did a couple other things and it's just easier to blat and re-clone than work out how to resolve. Git is hard for idiots imo, and there are a lot of us

With the amount of information available, there is no excuse: * https://rogerdudler.github.io/git-guide/ * https://git-scm.com/book/en/v2 Also see stackoverflow. Git is a complex tool because it’s tackling a complex problem. I don’t see a way of making it “easier” without massively reducing what it can do. It’s like saying we should reduce a formula one car so people can use it without reading up on it, etc. If somet…

> Git is a complex tool because it’s tackling a complex problem.

Fossil tackles much the same sort of problem, yet it's far simpler to use.

Most of Git's problems are due to purposeful choices, but they're design choices, not inherent aspects of how a DVCS must behave.

We've laid out our case for the differences here: https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik...

Re: Is Git Irreplaceable? (2019)

#440

Post by dev_north_east »

jerf wrote: post #376
dev_north_east wrote: post #368

Earlier quoted context omitted.

> that is a feature! You don't know how I miss that! Yep, handiest way to perform a first pass on narrowing down an introduced bug between a few commits.

Have you used "git bisect"?

Just reading up on it now. Seems interesting, might give it a shot next time.
Post reply on HN