Live data from Hacker News

Understanding Git for real by exploring the .git directory

medium.com

71–80 of 92 posts

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

#71
post #10

I worked with someone whose approach was very interesting: he committed the .git directory of a newly initialized repo to a separate, newly initialized repo. And then watched what changed when he added a file, changed things, branched, etc, in the committed .git directory. It's always seemed worthwhile to me to dig into git's model more, but if you're already comfortable and productive with stuff like detached head/r…

I once had a filesystem watcher watching a git repository. It does not give you detailed information about what changed in the files, but shows in real time what files are changing while you do your regular work.

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

#72
post #60

Earlier quoted context omitted.

This is still my git workflow. Aside from the off times I have to rebase or revert a commit. I'm curious as what git commands you've found the most valuable or you've used the most since digging deeper into git.

* Using stash to store stuff when I want to pull a remote in that will overwrite things I'm not ready to commit * git add -p, git add -i are nicer ways to add files * git grep * git reset, revert, and checking out old commits - these commands I currently find tough to get right - this is mostly because I don't really get the HEAD~2 ^ and what the syntax is for accessing older stuff * git fetch and merge -i instead of…

> The biggest problem I have with git that I have yet to solve is that I will be working on something on my laptop and then want to switch to my desktop and pick up where I left off.

Could you use something like rsync or unison to sync the working directory (including the .git directory) between your desktop and laptop? I'm new to git myself, but after reading through the OP article I imagine this would work.

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

#74
post #60

Earlier quoted context omitted.

This is still my git workflow. Aside from the off times I have to rebase or revert a commit. I'm curious as what git commands you've found the most valuable or you've used the most since digging deeper into git.

* Using stash to store stuff when I want to pull a remote in that will overwrite things I'm not ready to commit * git add -p, git add -i are nicer ways to add files * git grep * git reset, revert, and checking out old commits - these commands I currently find tough to get right - this is mostly because I don't really get the HEAD~2 ^ and what the syntax is for accessing older stuff * git fetch and merge -i instead of…

Try

    git checkout -b wip-syncing
    git commit -m "wip means work in progress"
    git push  wip-syncing
on your laptop, then

    git fetch --all
    git checkout /wip-syncing -- .
    git push  :wip-syncing
on the desktop. of course, this "rewrites history", but only in a very localized way.

In general, you're going to be fighting against git if you take an absolutist stance against rewriting history. Which is fine! But a little bit of controlled rewriting can open up a lot of options.

Edit: and I'm typing this from memory on my phone so please don't copy and paste the commands without verifying that they work correctly first!

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

#75
post #69

Earlier quoted context omitted.

Ah yes, the "subversion" method of using git. ... I also do this. :|

Also the method that gets logging, debuggers and temp files committed by accident.

Or authentication tokens. How many ssh keys or database passwords have been lost like this?

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

#76
post #45

Earlier quoted context omitted.

This is still my git workflow. Aside from the off times I have to rebase or revert a commit. I'm curious as what git commands you've found the most valuable or you've used the most since digging deeper into git.

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 under review. - The verb used to commit to the trunk or other release series is 'merge --no-ff'.

Under that model, merges are very common, particularly merges from the trunk to the feature being developed. But that's OK, because its what actually happened. When most people perform a 'rebase', they are actually performing a merge, while dropping the metadata for that merge.

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

#77
post #72
post #60

Earlier quoted context omitted.

* Using stash to store stuff when I want to pull a remote in that will overwrite things I'm not ready to commit * git add -p, git add -i are nicer ways to add files * git grep * git reset, revert, and checking out old commits - these commands I currently find tough to get right - this is mostly because I don't really get the HEAD~2 ^ and what the syntax is for accessing older stuff * git fetch and merge -i instead of…

> The biggest problem I have with git that I have yet to solve is that I will be working on something on my laptop and then want to switch to my desktop and pick up where I left off. Could you use something like rsync or unison to sync the working directory (including the .git directory) between your desktop and laptop? I'm new to git myself, but after reading through the OP article I imagine this would work.

Yeah I've thought about rsync. It just seems like a half solution and I'm not really sure how well it would work when I'm off my home network. Sometimes I ssh into the desktop because my laptop is old and run into limitations with front end build tools.

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

#78
post #60

Earlier quoted context omitted.

* Using stash to store stuff when I want to pull a remote in that will overwrite things I'm not ready to commit * git add -p, git add -i are nicer ways to add files * git grep * git reset, revert, and checking out old commits - these commands I currently find tough to get right - this is mostly because I don't really get the HEAD~2 ^ and what the syntax is for accessing older stuff * git fetch and merge -i instead of…

Try git checkout -b wip-syncing git commit -m "wip means work in progress" git push wip-syncing on your laptop, then git fetch --all git checkout /wip-syncing -- . git push :wip-syncing on the desktop. of course, this "rewrites history", but only in a very localized way. In general, you're going to be fighting against git if you take an absolutist stance against rewriting history. Which is fine! But a little bit of c…

not a bad idea to keep a separate branch for doing that. I might try that out.

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

#79
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?

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

#80
post #6

Obligatory link to Charles Duan's most excellent git tutorial: > you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something. http://www.sbf5.com/~cduan/technical/git/ Somehow I do not see this mentioned often despite it is, in my opinion, hands down…

Is this article available as a PDF document?
Post reply on HN