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…
Understanding Git for real by exploring the .git directory
71–80 of 92 posts
Re: Understanding Git for real by exploring the .git directory
#72Earlier 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…
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
#73 info/exclude
you can put the files you don’t want git to deal with in your .gitignore file.
Since .gitignore is committed itself this is very useful.Re: Understanding Git for real by exploring the .git directory
#74Earlier 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…
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
#75Re: Understanding Git for real by exploring the .git directory
#76Earlier 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.
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
#77Earlier 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.
Re: Understanding Git for real by exploring the .git directory
#78Earlier 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…
Re: Understanding Git for real by exploring the .git directory
#79The 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.
Re: Understanding Git for real by exploring the .git directory
#80Obligatory 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…