Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding Git for real by exploring the .git directory

medium.com

Post reply on HN
Print view View original

81–90 of 92 posts

Re: Understanding Git for real by exploring the .git directory

#81

Post by the4dpatrick »

brandmeyer wrote: post #76
fla wrote: post #45

Earlier quoted context omitted.

For some time now, we use the rebase workflow. (create your branch, do some work, rebase on master, push). It is a great way to have a clean linear history. But it makes git pull 'illegal' because it does a merge implicitely. That's tipically something I didn't think about the first times I used git.

> It is a great way to have a clean linear history. Why is this considered by so many people to be a Good Thing? Engineering is an inherently messy human process, and the repository history should reflect what actually happened. To that end, I've been advocating a merge-based workflow instead: - The fundamental unit of code review is a branch. - Review feedback is incorporated as additional commits to the branch unde…

Before reading more about rebasing, I wouldn't have an opinion here, but like most things in programming I think it's a matter of philosophy. Do we want the history to be "record of what actually happened" or "story of how your project was made." [0]

I see merits in both approaches: Rebase seems to be good when you want to focus on the project minus the process, while merging seems to be good when you want to know the process behind the project. For larger projects with multiple contributors, I think the merging approach is better because of the process visibility. For smaller projects with one or two developers, a rebase approach could be "cleaner" when looking through the logs later on.

I'm interested to hear what other's opinion on the topic as well.

[0] - https://git-scm.com/book/en/v2/Git-Branching-Rebasing#Rebase...

Re: Understanding Git for real by exploring the .git directory

#82

Post by barrkel »

matt4077 wrote: post #68
Kaotique wrote: post #67

The CLI is a complete mystery and that makes it hard to explain to people. Most of the commands and arguments differ so much that it makes little sense. Delete a branch, commit or tag in a similar way; the commands to do this are totally different. How Git works can be easily drawn out on paper to explain it to someone. The branches, commits and merges is simple to draw. When we lose sense of our state we always take…

Yeah, I used to race through svn workflows without a second thought. With svn, I still don't understand how to (just one example) throw away all the local changes. (No, not git reset --hard. At least that didn't work when I last tried). It came to the point where I thought about spending a week just learning git to defend my berd creds. Instead, I just use a gui for anything beyond add/comit/push. I still don't like…

I found I had to build a whole parallel patch management system to rationally deal with svn. Applying the same patch in multiple branches was a royal PITA in svn; in git, it's trivial.

git status will tell you how to throw away local changes, btw. Depending on the kinds of changes (e.g. edit/delete added, staged or not) need different commands.

Re: Understanding Git for real by exploring the .git directory

#83

Post by novel »

matt4077 wrote: post #68
Kaotique wrote: post #67

The CLI is a complete mystery and that makes it hard to explain to people. Most of the commands and arguments differ so much that it makes little sense. Delete a branch, commit or tag in a similar way; the commands to do this are totally different. How Git works can be easily drawn out on paper to explain it to someone. The branches, commits and merges is simple to draw. When we lose sense of our state we always take…

Yeah, I used to race through svn workflows without a second thought. With svn, I still don't understand how to (just one example) throw away all the local changes. (No, not git reset --hard. At least that didn't work when I last tried). It came to the point where I thought about spending a week just learning git to defend my berd creds. Instead, I just use a gui for anything beyond add/comit/push. I still don't like…

Beware, once you learn some of the git useful patterns and features, most likely you'll start feeling very uncomfortable when you have to go back to svn ;)

Re: Understanding Git for real by exploring the .git directory

#84

Post by fla »

the4dpatrick wrote: post #81
brandmeyer wrote: post #76

Earlier quoted context omitted.

> It is a great way to have a clean linear history. Why is this considered by so many people to be a Good Thing? Engineering is an inherently messy human process, and the repository history should reflect what actually happened. To that end, I've been advocating a merge-based workflow instead: - The fundamental unit of code review is a branch. - Review feedback is incorporated as additional commits to the branch unde…

Before reading more about rebasing, I wouldn't have an opinion here, but like most things in programming I think it's a matter of philosophy. Do we want the history to be "record of what actually happened" or "story of how your project was made." [0] I see merits in both approaches: Rebase seems to be good when you want to focus on the project minus the process, while merging seems to be good when you want to know th…

It is an interessting analysis. I think you're right saying that its a matter of philosophy after all.

In my experience, the clean linear history can be important when you build a product which is going to be certified since the developement process is key to obtain the certification.

Also, I like the fact you can always reorganize your commits before rebasing, making them more atomic / cleaner.

Re: Understanding Git for real by exploring the .git directory

#85

Post by blacksmith_tb »

chmaynard wrote: post #79
jrbancel wrote: post #2

The most enlightening introduction to git internal model (graph of commits) and how the main commands alter it I have read so far: https://jwiegley.github.io/git-from-the-bottom-up/ I think it is slightly more relevant to understand the model than the .git/ structure since the .git/ folder is just an implementation detail.

Could someone please post a link to a PDF version of this article?

For offline use? But git is a dvcs... ahem, anyhow, wkhtmltopdf[1] is a reasonable choice for converting arbitary urls to pdfs, and can be installed via apt, homebrew cask etc.

[1] http://wkhtmltopdf.org/

Re: Understanding Git for real by exploring the .git directory

#86

Post by sethrin »

recursive wrote: post #38
sethrin wrote: post #14

Earlier quoted context omitted.

That's the thing, there is almost no reason to ever have to delete and redownload. Moreover, the reason that git is dominant is (network effects, and) because it is solving the right problem with the right internal abstractions. It has even managed to become popular in spite of its user interface.

There is a reason to re-clone. It fixes every weird git state. And you don't even need to learn a bunch of theory to do it.

We are all ignorant in most respects; there is an opportunity cost in knowing anything. If you use git daily, I submit that it does not make sense to be ignorant of how it works. Yes, you will take no physical harm from misusing this tool, but you're setting yourself up for failure. Reading about how git works will prevent you from making the mistakes that lead to an unworkable state, and allow you to resolve any unexpected situations or errant keystrokes. To make something of an analogy, git has the most powerful and flexible form of "undo" that has been conceived to date, and you are discarding this because you can always re-download an old copy and redo your work. If it is something that you use only rarely, there is nothing wrong with choosing to study other things. If you are employed as a software developer then I would consider you to have very little excuse for ignorance.

Re: Understanding Git for real by exploring the .git directory

#87

Post by pimlottc »

icebraining wrote: post #61
EvanPlaice wrote: post #55

Earlier quoted context omitted.

It's much easier when you can see all of the staged/unstaged files and drill down to staging/unstaging individual lines within those files. It also highlights whitespace nastiness (ie trailing spaces, missing newline at end of file, inconsistent newline chars, etc). The CLI is the ideal too for a lot of things. Preparing commits is not one of them.

You can see all the files and drill down with "git add -i". Git also highlights whitespace problems.

I was excited when I first heard about git add iteractive mode but I find the interface to be quite unintuitive and idiosyncratic. I just stick to using "git add -p" to stage hunks selectively in a much more straightforward manner.

Having said that, I stage all my commits on command line, and generally go to a GUI rarely for certain visualization tasks.

Re: Understanding Git for real by exploring the .git directory

#88

Post by NicoJuicy »

My entire git workflow is based on these tutorials (don't seem to need much else): https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching... and http://nvie.com/posts/a-successful-git-branching-model/

Anyone knows what would be most usefull outside the scope of the tutorials above?

Re: Understanding Git for real by exploring the .git directory

#89

Post by recursive »

sethrin wrote: post #86
recursive wrote: post #38

Earlier quoted context omitted.

There is a reason to re-clone. It fixes every weird git state. And you don't even need to learn a bunch of theory to do it.

We are all ignorant in most respects; there is an opportunity cost in knowing anything. If you use git daily, I submit that it does not make sense to be ignorant of how it works. Yes, you will take no physical harm from misusing this tool, but you're setting yourself up for failure. Reading about how git works will prevent you from making the mistakes that lead to an unworkable state, and allow you to resolve any une…

I have never had to resort to this technique. However, there's a lot in git I don't understand. I've spent multiple days learning git, and at some point, the diminishing returns of further investment don't justify themselves. If I broke my repo in such a way that caused me to consider re-cloning to "get out of jail", I probably would only do it if I didn't lose a significant amount of work. (e.g. copy in-progress files to a safe location before recloning)

You say I have very little excuse for my ignorance, but I would also say that I have very little excuse to spend any more time learning a tool with as many dark corners as git.

Post reply on HN