251–260 of 281 posts
Earlier quoted context omitted.
There must be something you do terribly wrong if you believe it happened to you in normal use.
The poster is talking about when you do something like this: `git checkout .` That wipes out all unstaged changes on tracked files in the current directory
Lately I’ve wanted branches (heads) to have a corresponding tail which points to the base commit that the branch sits on top of (like the commit on `main` when you created the branch).[1] Because branches get rebased all the time and eventually you have six commits out in the Æther somewhere and you have to think twice about where it even starts. And yeah you can probably think for a few seconds and recall that you h…
It looks like this is what git merge-base --fork-point is supposed to do, although according to the docs it is not 100% reliable.
Earlier quoted context omitted.
aka Git is the simplest crappiest implementation that can work. Then they tacked a terrible UX onto it and shipped it. Chaos ensued and we as devs have spent the last almost 20 years fighting over trying to understand the chaos, we would have been way better off staying with SVN or Mercurial or Fossil(or pretty much any other VCS), but that ship has sailed and now we are stuck in the chaos. Now nobody understands the…
With all due respect, what a load of crap! SVN, branching that takes forever instead of a simple file with a commit hash in it? Are you serious? Mercurial, when I had to use it for almost 2 years? The single thing I missed the most is the fact that "everything is just a label" (or pointer if you will). Fossil I can't comment on with certainty, as I never really used it. This is probably gonna get voted into oblivion,…
Your entire hate for SVN was branching takes a while(because it requires a round-trip to the server). SVN was easy to reason about, you didn't have entire conference talks trying to explain how SVN works, so people don't have to rm -rf their entire tree and re-check out every week.
And even you, who claim to understand git seem to not understand git reflog. I think that clearly sums up my argument perfectly fine :)
Git is NOT easy to reason about, and I've never seen a website or blog post or conference talk about git that wasn't factually inaccurate in some way, and yet they still continue to proliferate. If we don't come up with a better git, the next decade will still be spent trying to teach git to people that will never understand it.
Earlier quoted context omitted.
aka Git is the simplest crappiest implementation that can work. Then they tacked a terrible UX onto it and shipped it. Chaos ensued and we as devs have spent the last almost 20 years fighting over trying to understand the chaos, we would have been way better off staying with SVN or Mercurial or Fossil(or pretty much any other VCS), but that ship has sailed and now we are stuck in the chaos. Now nobody understands the…
With all due respect, what a load of crap! SVN, branching that takes forever instead of a simple file with a commit hash in it? Are you serious? Mercurial, when I had to use it for almost 2 years? The single thing I missed the most is the fact that "everything is just a label" (or pointer if you will). Fossil I can't comment on with certainty, as I never really used it. This is probably gonna get voted into oblivion,…
I do remember merges being horrible in svn. Just branching off trunk, doing some work and merging back is fine, but if you try to merge from trunk to your branch to "catch up" you're in for some pain when you later want to merge to trunk.
Also svn treats adding and deleting file as different from just editing, more so than git does.
Earlier quoted context omitted.
Yup. “Storing moves” is the kind of thing that might sound intuitively obvious but then gets gnarly and non-obvious when you think about it for five minutes. And so something that might be “obvious” to do then turns out to be so non-obvious—how to catch all file moves (intent) outside of simple identitical content cases, and how do you represent them internally?—that you realize that just using snapshots is really th…
It’s completely trivial. The obvious and correct place is in the commit object just like author and date and such, since renaming is semantically part of the commit, not the tree: commit 0123456789abcdef0123456789abcdef01234567 parent fedcba9876543210fedcba9876543210fedcba98 author Nemo 1234567890 +0000 committer Nemo 1234567890 +0000 rename-from path1.old rename-to path1.new rename-from path2.old rename-to path2.new…
Like I implicitly said: how to do it beyond the “simple identical content cases”?
But if the solution is for the user to explicitly order renames (i.e., this renamed Java class is a file move) then the solution is indeed simple.
I see the point that Linus was making that you may want to be able to see “function moves” and so on. But in practice I am very often interested in file moves since you can inspect the file history easily in Git—except when you hit some wall because someone renamed the file. Then you need to re-run the command with `--follow`. Contrast all of that with a function move... I almost never can summon the will to fish out the incantation (like a regex or a robust line range) which will give me the history of a function across intra- or inter-file moves and so on.
Earlier quoted context omitted.
It’s completely trivial. The obvious and correct place is in the commit object just like author and date and such, since renaming is semantically part of the commit, not the tree: commit 0123456789abcdef0123456789abcdef01234567 parent fedcba9876543210fedcba9876543210fedcba98 author Nemo 1234567890 +0000 committer Nemo 1234567890 +0000 rename-from path1.old rename-to path1.new rename-from path2.old rename-to path2.new…
The problem with that scenario is that usually it doesn't support a real-world-scenario where you do a rename in the tool (like some IDE) and it doesn't do the corresponding git operation. (yes, some IDE might have git integration, but personally I don't like my IDE messing with git, except read-only (annotate, diff))
Earlier quoted context omitted.
The poster is talking about when you do something like this: `git checkout .` That wipes out all unstaged changes on tracked files in the current directory
That's as unfortunate as 'rm *' (and good to be aware of BTW), but doing this deliberately doesn't qualify as "normal use" for me.
There are many ways this can happen accidentally. You could be trying to checkout a branch and tab complete your way into a folder name instead. You could be typing alt/esc + . with the intent of getting last argument of previous bash command, keyboard glitches and you end up with . instead.
Just because it hasn’t happened to you yet, you shouldn’t discount the experience of others. That’s like saying you have never messed up dd yet, so there are no problems with dd’s design.
Earlier quoted context omitted.
With all due respect, what a load of crap! SVN, branching that takes forever instead of a simple file with a commit hash in it? Are you serious? Mercurial, when I had to use it for almost 2 years? The single thing I missed the most is the fact that "everything is just a label" (or pointer if you will). Fossil I can't comment on with certainty, as I never really used it. This is probably gonna get voted into oblivion,…
I used svn only a few years ago and don't remember branching taking very long. Maybe it was csv that had to copy the all files. I do remember merges being horrible in svn. Just branching off trunk, doing some work and merging back is fine, but if you try to merge from trunk to your branch to "catch up" you're in for some pain when you later want to merge to trunk. Also svn treats adding and deleting file as different…
Earlier quoted context omitted.
I keep repeating this every time someone talks about git and finds something weird or doesn't get branches, so I'm really glad your parent mentioned it as well and I know there's someone else out there that "gets" that: In git it's all just labels/pointers It's not useful at all to think about branches as the user sees them as "things" of their own. Branches don't "have" anything. Branches in that sense are just conv…
To make things more complicated, the word "tag" is also overloaded. It can either be just a reference (in git lingo, a "ref") to a commit - just like a branch, only differing from it in how the tools treat it; but they can also be "annotated tags" which are pointing to a special tag object which contains some metadata and only then points to a specific commit (or other kind of object...) :)
Or labels and annotations.
Or something else.
Earlier quoted context omitted.
With all due respect, what a load of crap! SVN, branching that takes forever instead of a simple file with a commit hash in it? Are you serious? Mercurial, when I had to use it for almost 2 years? The single thing I missed the most is the fact that "everything is just a label" (or pointer if you will). Fossil I can't comment on with certainty, as I never really used it. This is probably gonna get voted into oblivion,…
Look, we have spent the last ~ 20 years across HN and conferences and what not trying to teach git to people with basically nothing to show for it. Most developers still can't do much more than occasionally commit stuff. They still rm -rf their tree whenever something goes wrong. Your entire hate for SVN was branching takes a while(because it requires a round-trip to the server). SVN was easy to reason about, you did…
Maybe we have different experiences, but mine is that back in my SVN days, most devs were not able to reason about branching at all. And every time they needed to check something in another branch they would `cp -a` their SVN tree to another directory and people would have like four or five copies of each of their projects with various names hanging around.
My entire "hate" for SVN is not just branching. I can add more things if you like. For example, trying to merge or commit you have to be 100% certain that you won't have conflicts or that you can solve the conflicts in one go. I have seen many many people work on something, trying to commit it and getting hopelessly stuck during the conflict resolution and destroying their work. They then redid their entire piece of work (well the files that they effed up) and sometimes started creating said `cp -a` copies of the entire tree before committing. These are the same kinds of people that `rm -rf` their tree when they run into something in git that they don't understand.
In git an easy rule to never loose work (save for actual bugs) is to: always commit first. I.e. before you try anything, just commit. Whatever goes wrong, you can always go back to your commit. I don't have conflicts often but sometimes in the middle of a conflict resolution I will just reset back to the original commit I made and try again with the knowledge I gained during the first round of resolution. Sometimes the solution is to actually just squash your own commits first and the conflict goes away for example. But I don't know that in advance coz I wasn't even expecting a conflict to begin with.