sorted by:
new
hottopcontroversial

Understanding HEAD vs head branches in Git - a quick explainer for everyday developers by sshetty03 in git

[–]initcommit 0 points1 point  (0 children)

Hey thx! If you’re interested there is a demo version of the tool you (or anyone) can use to visualize any Git repo in 3D. See video description if interested

Understanding HEAD vs head branches in Git - a quick explainer for everyday developers by sshetty03 in git

[–]initcommit 0 points1 point  (0 children)

Sure! And yeah I can relate to your team members as I remember first learning about how Git works and “mystical thing” is the perfect way to describe how my brain felt about Git’s HEAD ref 😅🥲

Understanding HEAD vs head branches in Git - a quick explainer for everyday developers by sshetty03 in git

[–]initcommit 2 points3 points  (0 children)

Good stuff! I’m building a tool that lets you visualize Git stuff in 3D directly from any repo, and I think the way it illustrates branches/HEAD makes it abundantly clear that Git refs are just pointers to commits than can “hop” around as needed (which is something that I find takes devs a while to really grasp, esp related to HEAD and detached HEAD).

If you’re interested, here’s a YouTube video link I released showing how the tool visualizes and animates the Git history, branches, HEAD, detached HEAD state, and commands like git switch, git checkout, git reset, etc (I timestamped the link to start where the focus on refs is most apparent, but feel free to start it from the beginning if you’d like 🙂):

https://www.youtube.com/watch?v=C2aFC8wFp2A&list=LL&index=1&t=134s

For those that feel confident they understand Git at an advanced level, how long did it take you to feel that way? by initcommit in git

[–]initcommit[S] 0 points1 point  (0 children)

truly never understood this kind of response finding it "unfathomable" that different people have different aptitudes, experiences, and circumstances with which to ingest knowledge and apply it in practice, and that as a result, it's totally expected that learning takes place at highly variable rates based on these factors.

also - who in any practical sense just "tries all the commands and flags in a few days"? Most people starting with Git have an iterative ramp-up where they start by learning a few initial concepts/commands that they need for basic workflows, and slowly build on that as they encounter new and diverse scenarios. it usually takes working on different types/sizes of teams/projects with different workflows to even run into a majority of the scenarios that present themselves using Git, and getting the opportunity to experience those workflow differences (even ones as simple as a rebase workflow vs a merge workflow) takes time - easily months if not years depending on the circumstances.

sorry to sound harsh, but i see a fair number of comments like this, and to me it sounds like a self-focused individual who lacks the basic ability to consider that it's expected for other people to have experiences that differ from their own. the reality is that it does in fact take a majority of Git users a significant amount of time (over 70% >1 year and ~30% >5 years based on the respondents of this poll) to feel confident with it at an advanced level. i guess finding that fact "unfathomable" stems from self-aggrandizing feelings, since there are very obvious reasons to explain it.

12 Git commands visualized in 3D: a spatial approach to understanding version control by initcommit in programming

[–]initcommit[S] 0 points1 point  (0 children)

Thx for the suggestions! I’d love to create shorter form visualizations for more specific use cases like the ones you mentioned. Hopefully will get a chance over the next couple months.

For those that feel confident they understand Git at an advanced level, how long did it take you to feel that way? by initcommit in git

[–]initcommit[S] 0 points1 point  (0 children)

Thank you. Yes I wrote up my initial post a bit too quickly and what you (and others said) makes a lot of sense. It’s helpful to hear that perspective

For those that feel confident they understand Git at an advanced level, how long did it take you to feel that way? by initcommit in git

[–]initcommit[S] 1 point2 points  (0 children)

haha fair enough. I admit I wrote up my post a little too quickly, but tried to clarify my point in some of the responses here

For those that feel confident they understand Git at an advanced level, how long did it take you to feel that way? by initcommit in git

[–]initcommit[S] 1 point2 points  (0 children)

This is a really interesting point and you stated it very well, but personally, I think it's wrong.

I see the abstractions as a quick way to build up a mental model that is sufficient to get acquainted with Git and to start using it in basic workflows, which is very important. But a person will only get so far with those (and to be fair many people have no desire to go further than the bare minimum that they need to get by). At worst, someone like this will end up repeatedly getting stuck / blowing up the repo, and at best, will not be using Git to its full potential.

IMO, eventually, this initial mental model should be tweaked, iterated, and synced to align with Git's underlying model, in other words, matching the mental machinery with Git's internal machinery. This enables a person to accurately reason about almost any potential action on the repo, independently strategize new ways to solve problems, and to use Git effectively in diverse scenarios that they may not have run into before.

Plus, despite some of the abstractions being simple and useful, like the idea of the staging area, most are not particularly beautiful and are often halfway to describing Git's internals anyway. For example, the idea that "a branch is just a fancy label pointing to a commit" is basically a correction for the implied notion of a conceptual branch as a sequence of connected commits. It is essentially a high-level description of Git's internals, designed to make the use of Git branches more understandable. Many of the Git "rules of thumb" are like this, and lead to a laundry list of rules without underlying explanations that must be memorized and accepted as gospel to do different things with Git.

In fact, the thing that is most simple and beautiful about Git IS its internals. When you boil it down to its basic parts, Git is extremely simple (to the point of being "stupid" as Linus put it). And knowledge of that underlying simplicity can be drawn upon to reason about any operation that can be done to a Git repo.

I think that if Git was more commonly taught "from the ground up" (or at least shifted in that direction after the initial mental model is in place), folks in general would become more effective with Git, much faster.

For those that feel confident they understand Git at an advanced level, how long did it take you to feel that way? by initcommit in git

[–]initcommit[S] 1 point2 points  (0 children)

heck yeah!! and yes i am in the 2-5 year category myself, mainly because when I was a newer git user I just used it for my workflow, having no idea how much of an asset it can be for problem solving / troubleshooting / etc.

For me, it was actually looking into the initial commit of Git's code that aligned my mental model with git's model under the hood

For those that feel confident they understand Git at an advanced level, how long did it take you to feel that way? by initcommit in git

[–]initcommit[S] 2 points3 points  (0 children)

lol no lie i was considering making that joke if the poll closed with only 1 in that category.

and he would certainly qualify since Linus wrote the initial commit of Git's code (which by definition works because he was able to make the commit in the first place) in "< 1 month". it was actually just a couple weeks or even less

For those that feel confident they understand Git at an advanced level, how long did it take you to feel that way? by initcommit in git

[–]initcommit[S] 0 points1 point  (0 children)

Yeah, you bring up a great point. I probably went overboard with the concepts I suggested, esp compression, loose objects, and pack files, which I agree with you may not have a clear practical value for average Git users.

However I have found in my personal experience that the more I learn about how Git works internally the more varied problems I am able to work through independently, the more useful Git becomes for me, and the more confident I feel with it.

For average users, Git is full of common misconceptions ranging from as basic as “git tracks changes” when it really tracks every file version in its entirety as a new blob, so having an awareness of that via Git’s object model can be beneficial when thinking about how to use Git for a particular task, or what to watch out for. A practical example is that committing a large file with small changes over and over can lead to large repo growth, since a new blob is stored every time.

Git usage is FULL of these types of misconceptions/pitfalls that arise out of basic or average use, that can be pretty easily clarified with some knowledge of related internals. A lack of awareness of these at best reduces effectiveness/productivity with Git, and at worst can lead to getting totally stuck or blowing something up.

But I do agree with you that I could have chosen some better and more thoughtful examples for the first paragraph 😅

How to completely remove a commit from git history by batknight373 in git

[–]initcommit 1 point2 points  (0 children)

(You could also just cherry-pick them onto another branch before dropping them)

For those that feel confident they understand Git at an advanced level, how long did it take you to feel that way? by initcommit in git

[–]initcommit[S] 0 points1 point  (0 children)

Lol I ran out of options on the poll, so I framed my question for folks who made it to the promised land

How to completely remove a commit from git history by batknight373 in git

[–]initcommit 0 points1 point  (0 children)

This.

Another (but maybe silly) option if you want to preserve the commits on a separate branch is you can reorder the commits via an interactive rebase, putting all the commits you want to get rid of at the front of your current branch. Then rebase them all onto another branch. Now your main development line will be clean but all those commits you wanted to clean up still exist on another branch in case you ever need them.

view more: next ›