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

281–290 of 559 posts

Re: Is Git Irreplaceable? (2019)

#281

Post by rumanator »

adrianmsmith wrote: post #210
rileymat2 wrote: post #171

Earlier quoted context omitted.

I actually prefer SVN and HG style branches where you keep the branch history as a known formal branch, then have one merge back to Trunk. It is unclear to me how far back you are saying SVN did not have branching.

I don't remember a time when Subversion didn't support branches. I'm sure Subversion 1.0 supported branches (although I can't find evidence of that right now, but I also can't find any release notes for Subversion 1.n containing "now we support branches!") One can argue about what a branch is, for sure. Subversion branches, Mercurial branches and Git branches all have very different implementations. But the main work…

> I don't remember a time when Subversion didn't support branches.

SVN's official response to branching and tagging was to copy directories around in the repository. Arguably that means it does not support branching, at least according to the concept that has been in place for the last decade.

Re: Is Git Irreplaceable? (2019)

#282

Post by matsemann »

rimliu wrote: post #259
matsemann wrote: post #216

Earlier quoted context omitted.

People have probably been happy with their tools for centuries. Just because one cannot imagine something better doesn't mean there's no possibility for it to exist. If anything, this defeatist attitude may prove the author right.

I remember what was the go-to tool before git. It was Subversion. And CVS before that. I would not say people were happy with those tools.

I was happy copying my files back in the days for versioning (final_draft, final_draft01, final_draft_absolute_final, final_draft_use_this_one), but that was because I didn't know of anything better. What I'm saying is that even though we don't see it now, there's probably something better out there waiting to be discovered.

Re: Is Git Irreplaceable? (2019)

#283

Post by chrisseaton »

james_s_tayler wrote: post #137
roca wrote: post #91

Earlier quoted context omitted.

Git's UI is unbelievably bad. However, it's practically impossible to avoid learning how to use it these days, so "much better UI than git" will never be a compelling selling point for an alternative VCS: almost its entire target market has already paid the cost of learning git. That problem could be gotten around if there was some enormous pool of potential VCS users who aren't using VCS currently but would if there…

It doesn't have a UI. Its just a program that takes instructions and does what you tell it. If you want a nice fancy GUI for Git there are plenty of reasonable options. Fork is the one my coworkers seem to be enamoured with at this point in time. I myself don't see the need to use any sort of GUI for Git the vast majority of the time.

> that takes instructions

That’s a UI!

Re: Is Git Irreplaceable? (2019)

#284

Post by bhaak »

jerf wrote: post #60
ken wrote: post #29

Earlier quoted context omitted.

But did you think that RCS, CVS, or SVN were also good enough? Or is this new?

Speaking personally, definitely no. Even before I heard of git, I did not like SVN. In particular, it made an error I don't hear many other people mention where directories were checked out to revisions, rather than entire repositories. Consequently it was very easy to accidentally update just a subset of your repository, and have your whole repository in a state that didn't exist in the version control system at all…

None of the other big VCS had fatal flaws. If they had fatal flaws, they wouldn't have been used.

Sure, not being able to rename a file easily in CVS was quite an annoyance but nothing that made it completely useless.

There were always workarounds. But exactly those areas were workarounds or better tooling patches over stuff Git doesn't do are the areas that a possible successor will address.

Re: Is Git Irreplaceable? (2019)

#285

Post by reagent_finder »

tomesch1982 wrote: post #237
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.

Git is neither easy not is it really elegant. It is useful for projects like Linux™ but for the vast majority of projects way better tools like mercurial or fossil would be a much better fit.

What?

To use git you need to know clone, pull, commit, push. For larger projects branch and merge. Those fall into a lot of boxes that say "easy" or "elegant," and I really wouldn't hesitate to recommend git to a lot of projects, big or small, discounting specific needs, but I guess you've got some specific concerns that really don't translate well into simple statements.

I've used mercurial only to get some external requirements or tools going, and never used fossil. Could you elaborate a bit on why git is worse than either of them and why I should consider switching ?

Re: Is Git Irreplaceable? (2019)

#286

Post by squiggleblaz »

shakna wrote: post #159
HALtheWise wrote: post #110

Earlier quoted context omitted.

However, in some cases (like non-mergeable binary files), it is actually better to have a system that allows one user to take a lock on a file and have exclusive editing abilities. The git protocol has no support for those workflows, and so people end up using a Google Doc or something to track who is modifying what file. Definately a place for improvement.

How do you lock a file in a distributed system? Many people won't be online. Many people won't be on the exact same head.

> Many people won't be on the exact same head.

This consideration is actually irrelevant to locking non-mergeable binary files. It doesn't matter what branch we're on or where the file is located, only that you and I both want to edit the logo. Eventually, either your version must be based on mine, or mine based on yours, since they will be merged.

So it's probably better not to have that file in Git, since it doesn't support the workflow around which Git is based.

It's actually right to store your design documents in Google Docs or a wiki and your code in Git, rather than everything in Git.

It is easy to have one filestore to rule them all and in the darkness bind them, but if you want to do different things with them, you have to do different things with them. I'm not sure that it's possible to unify text file and binary doc based workflows, but it seems we don't have to worry because users automatically use the best tool for the job and it's only hackers who tie themselves in knots trying to make git do everything.

Re: Is Git Irreplaceable? (2019)

#287

Post by bhaak »

lmm wrote: post #112
rhabarba wrote: post #26

Earlier quoted context omitted.

> unfortunately still Subversion Which is a better choice than Git for most projects, to be honest.

Disagree. SVN was always a pain. Committing is really slow and merging is bad (particularly for things like directory renames).

If all you had before was CVS then SVN wasn't a pain.

Atomic commits and file renames.

Re: Is Git Irreplaceable? (2019)

#288

Post by mcv »

romwell wrote: post #58

When people talk about killer features missing in Git, there is more beyond the UX and mono/poly repo. One thing is code review. There is no code review in Git. What I expect in 2020 is that I should be able to specify reviewers for the commit (which I pick out of a list of people who can approve it). These people should be able to leave comments on the commit. I should be able to both respond to comments and modify…

> "There is no code review in Git."

Yes there is. You can block pushing directly to a branch of the repository and demand that things can only be merged through pull requests. You code review the pull requests.

This is very well supported by Atlassian's git tooling, for example. It does everything you mention. It's true that the comments don't become part of the git repository itself, but I'm not convinced they should be.

Re: Is Git Irreplaceable? (2019)

#289

Post by bhaak »

l0b0 wrote: post #22

It is necessary but not sufficient for any new contender to do at least the following to have any chance of taking over: - Interoperate with the major player(s), currently Git and in many places unfortunately still Subversion. svn2git probably did more for Git adoption than any other feature or tool, because it allowed a fairly painless transition without losing information. - Solve at least one big problem with the…

I've seen nobody complain about the commit messages.

Commit messages are not versioned.

I can't go back and change the commit message to fix a typo or add something that was missed without changing the history.

This always bothered me somewhat but now that I have non native and native people on the team that can't spell, I feel the pain everyday.

Re: Is Git Irreplaceable? (2019)

#290

Post by adrianmsmith »

rumanator wrote: post #281
adrianmsmith wrote: post #210

Earlier quoted context omitted.

I don't remember a time when Subversion didn't support branches. I'm sure Subversion 1.0 supported branches (although I can't find evidence of that right now, but I also can't find any release notes for Subversion 1.n containing "now we support branches!") One can argue about what a branch is, for sure. Subversion branches, Mercurial branches and Git branches all have very different implementations. But the main work…

> I don't remember a time when Subversion didn't support branches. SVN's official response to branching and tagging was to copy directories around in the repository. Arguably that means it does not support branching, at least according to the concept that has been in place for the last decade.

That's true that there was no command "svn branch", there was only the command "svn copy". It's true that command could have been better named, like many Git commands could have been better named.

However, don't let that confuse you. The "svn copy" command creates a new place where you can do independent development, and where afterwards merging back can occur. So it's the same as a branch by that definition.

An "svn copy" is a lightweight copy, with a reference back to the place the copy was made from.

- "svn merge" does its merge by looking at what commits have been made at the original location (since the copy), and the commits to the copy.

- "git merge" does its merge by looking at what commits have been made on the original branch (since the new branch was created) and the commits on the new branch.

So "svn merge" and "git merge" act in the same manner. (Of course there are differences in the algorithm, but I wish to refute the point that Subversion "does not support branching [at all]".)

And if you never use "svn merge" or "git merge", then a branch is just a copy, in either system.

Post reply on HN