301–310 of 318 posts
Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej
In section 5.7: > But in this section we’re going to be talking about a specific kind of merge: the fast-forward. This occurs when the branch you’re merging from is a direct ancestor of the branch you’re merging into. Looks like "from" and "into" are swapped: "main" is "into" there, "newbranch" is "from", and "main" is a direct ancestor of "newbranch".
Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej
Not wrong, but one thing I did not spot in all the great explanations related to HEAD is that @ is an alias for HEAD that is a lot easier to type.
Earlier quoted context omitted.
Mercurial is simpler than git. It is (or was) just too damn slow
For some people. Back when I only knew how to use subversion, I tried out both git and mercurial, and found mercurial confusing while git clicked immediately. Unfortunately it's been long enough I don't remember details why, just that it was something with how it handled branches.
So really you can choose whatever suits your needs.
Personally the things I love about mercurial are:
more consistent commandline (that's the simple part others bring up)
revsets (awesome query language for revisions, there's also filesets, but I don't use that as much)
absorb (I think someone added a git extension that does something similar a few months ago)
fa --deleted
grep --all
phases ♥Earlier quoted context omitted.
I've been using Jujutsu a little and over the weekend lost a bunch of files. I'd been working happily in an anonymous branch. I had a bunch of content in a thirdparty folder that was hidden by .gitignore. I couldn't figure out how to merge my anonymous branch into master. Somehow wound up on the old master and it deleted all of my gitignored files. Then jj status got totally fubar and couldn't complete in under 5 min…
While I understand your predicament, consider not giving up on jj just yet because of this. It is _exceedingly_ hard to lose files in jj, it's actually emotionally frustrating reading the line "most important thing [..] is to never ever delete file" because that's the whole shtick in jj with the oplog and whatnot - so something like nuking secrets completely from a jj repo is a bit of a chore. Can you file a bug at l…
Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej
So in figure 5.4 you say we merge 2 commits into a new one and somehow both branches point to new commit. This will definitely confuse people new to git.
I'd say it's better to write we merge anotherBranch into someBranch and leave the former where it is. Same for the next merge.
Just a suggestion
Earlier quoted context omitted.
My sense, bluntly, is that if people spent half the effort learning git that they do whining about it, no one would bother making a 30+ part guide just explaining stuff you could find in a man page. Commits are snapshots of a tree. They have a list of ancestors (usually, but not always, just one). Tags are named pointers to a commit that don't change. Branches are named pointers to a commit that do change. The index…
Sigh. Another git thread, another pile of posts telling me that if I would _just do the work_ to understand the underlying data structure I could finally allow myself to be swept up in the _overwhelming beauty_ of the something something something. The evidence that the git UI is awful is _overwhelming_. Yes, yes, I’m sure the people that defend it are very very very very smart, and don’t own a TV, and only listen to…
yes, to understand an application, you must also understand the underlying data structures, architectures, models, use cases -- i am not sure what there's to roll eyes at. but there's no requirement that says that understanding has to be deep in order to work on it, or use it.
i think if you treat it like cleaning a large room, by picking out one corner at time and focusing on cleaning that before moving on, you'll find that the room is cleaned in no time, and git isn't anywhere nearly as complicated as it may feel.
there is absolutely no reason to digest a guide this dense for use-cases in every day production settings, bc those usages only make up about 10% of what this guide covers.
yes, learning things can be overwhelming, challenging, full of darkness and terrors, but that's what learning is, until you've learned.
but here is the catch imo: once you've learned, you don't stop learning and the challenges don't go away. you just become better at navigating the darkness, bc you get better at learning and managing feelings of overwhelm and confusion which are by products of complexity -- real or perceived or both.
jump in. it ain't that scary, even if it feels scary. i promise. i've been there, and you can overcome it.
Earlier quoted context omitted.
Out of curiosity, what are the most common foot guns, in your opinion?
How do switch to a branch? (Note that you need to fetch before you switch. Also switch is experimental but it’s not really) How do I undo a change and get it to other people on the team? - follow up, What happens if someone has made an unrelaydx change since? - someone has committed an enormous change and I want the commit immediately after it but the enormous change doesn’t affect me. How do I get that single file w…
in my 8 years of using git as a primary tool for vc, i have not once run into confusion on how to switch branches, create branches, prune branches, sync remotes with locals, and other common workflows.
does that mean i have only dealt with simple merges or haven't fucked something up bc i did not understand something and made things way harder than necessary (merging/replaying 50 commits vs squash rebase workflows, for example).
and no, you don't need to 'fetch' before you switch, fetching is only relevant if you're needing to bring in remotes or you're preparing for merges etc.
someone committing bunk to a main branch or something considered a production branch is not a git problem -- that's just bad development practices, and the onus is on the developer there to not do that and to understand why it is bad.
as for your other complaints, these are much more easily managed when the developers are not just arbitrarily commiting to branches without any strategic thought, but to point out, a lot of those problems are solved via working with commit hashes and branching, assuming you have already plugged the leak that is committing breaking changes to a main branch.
why are breaking changes that are mega changes even making it through to main?
Earlier quoted context omitted.
> You shouldn’t ever need to go to the reflog unless you’re in an exceptional case If "loosing your work and it's not in the git log" isn't an exceptional case, what exactly is a "exceptional case"?
> If "loosing your work and it's not in the git log" isn't an exceptional case, what exactly is a "exceptional case"? Losing your work should be exceptional. It's very, very easy to fuck a rebase up, and rebasing is (like it or lump it) a common operation. You shouldn't one step away from an exceptional case from a daily operation.
you don't have to treat rebases or merges as this black hole of "i have no recourse for not getting it perfect the first time".
Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej
In 9.4 there's no way reallinux/master points to same commit as master after the merge. It will still be where it was, one commit behind.
Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej
Hey great work beej! I've read pro git and your guide is very good. So in figure 5.4 you say we merge 2 commits into a new one and somehow both branches point to new commit. This will definitely confuse people new to git. I'd say it's better to write we merge anotherBranch into someBranch and leave the former where it is. Same for the next merge. Just a suggestion
Let me see if I can do that and save the clarity.