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

451–460 of 559 posts

Re: Is Git Irreplaceable? (2019)

#451

Post by hinkley »

jldugger wrote: post #162
hinkley wrote: post #144

Earlier quoted context omitted.

I’ve read a couple descriptions of the internals of git that don’t disagree with the design of SVN, so I’m not unsure why you can’t theoretically check out a single subtree. Either the documentation is too hand wavy or some implementation details have blocked that possibility.

Are you aware of git-subtree?

Git sub tree is the exact opposite of what I’m talking about.

Also: > The responsibility of not mixing super and sub-project code in commits lies with you.

Is a lie. The responsibility of not mixing code lies with every member of the team. Does the author work alone?

Re: Is Git Irreplaceable? (2019)

#452

Post by tsimionescu »

reagent_finder wrote: post #285
tomesch1982 wrote: post #237

Earlier quoted context omitted.

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…

You need to know much more to use git in anything involving more than one branch. You need to know git checkout, git stash, you need to know how to fix conflicts, you need to know rebase vs merge and how to understand git log when you use merge, you need git reset, you probably need git cherry pick occasionally.

One of the major day to day annoyances is the fact that (by default) I can't work on multiple branches without committing or stashing all the time, since switching branches, instead of being a simple 'cd' like in other VCSs is instead a destructive operation on my entire repo (also causing re-indexing for all content-aware tools...). And if I want the normal behavior? I need to learn some other commands to set that up, and learn their filesystem restrictions...

Re: Is Git Irreplaceable? (2019)

#453

Post by MaulingMonkey »

icebraining wrote: post #299
MaulingMonkey wrote: post #246

Earlier quoted context omitted.

The whole reason git lfs exists is to workaround git scalability problems. Its raison d'etre is problems with git. That one of - if not the - most popular tool to solve said git scalability problems, also has scalability problems in practice, is both ironic - and absolutely a problem with the git ecosystem. To be pithy - "Even the workarounds don't work." "Technically", you might say, "that specific symptom with git…

Not waiting to provide you with free storage is not a "scalability problem". I can't spend company money on Perforce either, is that a Perforce problem?

I pay for a github subscription. I set out to pay more for a github quota bump, but found I was limited by upstream's LFS quota rather than my fork's LFS quota.

Re: Is Git Irreplaceable? (2019)

#454

Post by jerf »

mannykannot wrote: post #434
jerf wrote: post #396

Earlier quoted context omitted.

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,…

No source control system can solve the problem of not having things it was never given.

Re: Is Git Irreplaceable? (2019)

#455

Post by jerf »

dev_north_east wrote: post #440
jerf wrote: post #376

Earlier quoted context omitted.

Have you used "git bisect"?

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

In the case you mentioned of "just a few commits" it's of marginal utility, because you can do that manually almost as quickly, but it's a killer when it comes to "I don't really know when we introduced this" and you have to sift over thousands of commits. Unfortunately, it requires that you have the discipline to keep every commit on the relevant branches buildable (enough so to find the bugs), which is something you can do going forward but can't retroactively apply to a code base very well.

Re: Is Git Irreplaceable? (2019)

#456

Post by matt-attack »

vnorilo wrote: post #330
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.

After using darcs, I can never see Git as elegant, no matter how clearly it is a more pragmatic choice these days.

I agree. I’m always embarrassed to say that I still use darcs but it’s just entirely obvious how to use it. There is no mystery. The choice to prompt the user for thing makes usability insanely high.

Yes it’s slow for large projects but honestly I just deal with that.

Re: Is Git Irreplaceable? (2019)

#457

Post by vvillena »

raducu wrote: post #421
vvillena wrote: post #355

Earlier quoted context omitted.

> Usually I accidentally committed to local master and then did a couple other things Create a new branch and check it out while you are on the last commit (git checkout -b my-branch), delete the master branch (git branch -D master), and pull it again (git pull -u origin master). You'll end up with a local branch with a bunch of commits that you can merge, rebase or cherrypick, depending on what you want. If you want…

Is there a reason for -D and not -d? Wouldn't -D also delete the remote branch if you accidentally pushed your changes?

"git branch -d" doesn't remove a branch if that means losing track of some local commits. "-D" doesn't check that. The "git branch" commands only operate on your local repo, they don't push any changes to remote repos and they don't pull commits from anywhere.

Re: Is Git Irreplaceable? (2019)

#458

Post by [deleted] »

jerf wrote: post #454
mannykannot wrote: post #434

Earlier quoted context omitted.

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,…

No source control system can solve the problem of not having things it was never given.

[deleted]

Re: Is Git Irreplaceable? (2019)

#459

Post by vvillena »

brigandish wrote: post #379
vvillena wrote: post #355

Earlier quoted context omitted.

> Usually I accidentally committed to local master and then did a couple other things Create a new branch and check it out while you are on the last commit (git checkout -b my-branch), delete the master branch (git branch -D master), and pull it again (git pull -u origin master). You'll end up with a local branch with a bunch of commits that you can merge, rebase or cherrypick, depending on what you want. If you want…

That is not easier than "blat and re-clone" so I think you're proving their point.

Recloning means redoing your work on top of a potentially different codebase. The approach I described is how you "blat and reclone" using git instead of the filesystem, and it has the clear advantage of keeping everything in the same repo. You can then mix all the code together in whatever way you prefer.

Git is a very flexible tool that allows for individual local workflows independent of how teams collaborate. Finding a personal workflow that works for you is a little investment that pays huge dividends for a long time. Git is a 15 year old tool that is expected to live for 10-30 years more at the very least. I encourage everyone to learn enough Git to not be afraid of it.

Re: Is Git Irreplaceable? (2019)

#460

Post by gallier2 »

DaiPlusPlus wrote: post #356
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

I wish git had a “metahistory” feature to allow everyone to undo anything. A `git revert` isn’t of any help when you’ve already merged and pushed.

You have a branch named you do your operation that fouls up your branch. If you check with

git log --reflog --all

you will see with this magical command that git DOESN'T REMOVE any commit. Your old tree is still there, only normally hidden. The commit that was there before you fouled up your branch is still there.

You now only need to set your branch to the old commit. A branch is nothing else than a pointer in the tree.

You have 2 possiblities to change the commit a branch points to

1. git branch --force SHA1 (works only if is not the current checked-out branch. Simply checking out with the SHA1 works also as it deteches the HEAD).

2. replace the SHA1 in the text file in .git/refs/heads/ by the SHA1 where you want the branch to point to.

With that, your repo is in the same state it was before your error.

Post reply on HN