jwiegley / git-from-the-bottom-up Goto Github PK

Thanks for the great book!

Having read the book, I find my understanding of trees still quite fuzzy. It might be helpful to have an entry in the first page glossary describing what they are. Specifically, I wonder:

• Do git trees hold anything other than blobs?
• If not, how do trees interconnect, as illustrated at the bottom of "The beauty of commits"? Do they inherit their connections from the owning commit?
• My understanding is that a commit contains exactly one tree which contains one or more blobs (otherwise the commit would be empty?) If that is the case, then why does the tree pointed to by the first commit in the digram at the bottom of "The beauty of commits" not point to any blobs?
• Why are they called trees? The seem to just be buckets of blobs. I see that they can be arranged in a tree, but nothing here demonstrates tree-like behaviour.

2-The-Index/2-taking-the-index-farther.md should be further in both the name and the title. You've got the right spelling in "Further reading" :)

Here’s how I’d commit two different patches into my working tree using plain Git:

$ git add -i # select first set of changes
$ git commit -m "First commit message"
$ git add -i # select second set of changes
$ git commit -m "Second commit message"

My understanding is that history is like this

       C0 <-- C1 <-- C2  [master]

On branch master, from C0, you make 2 commits. C1(first commit) contains patch A, while C2(second commit) contains patch A+B. You want to have a commit with patch B only.
However your operations below cannot achieve that.

git log # find the hash id of the first commit
$ git checkout -b work <first commit’s hash id>
$ git cherry-pick <second commit’s hash id>
<... run tests ...>
$ git checkout master # go back to the master "branch"
$ git branch -D work # remove my temporary branch

       C2' [work]
       |
C0 <-- C1 <-- C2 [master]

Creating a new branch work at C1 and cherry-pick C2 on top of C1 makes C2' the same as C2 with patch A+B. Running test from C2' is no better than creating branch workat C2 itself and runing test from there.

Even if you go back to C0 and cherry-pick C2 on C0, C2 still contains patch A+B not patch B alone.

There's a suggestion to add git stash && git stash apply to cron in https://jwiegley.github.io/git-from-the-bottom-up/4-Stashing-and-the-reflog.html

That's probably not a great idea. It'll trigger "files have changed" prompts in editors, fill your stash list with garbage. and might hit races is you're writing or compiling code while the cron job hits.

If you really wanted to do something like this, you probably want to make your own copy of the index in order to commit the changes to a local branch or something.

But I'd suggest just dropping the final line of that section.

Im not a native English speaker but I think something is wrong about the sentence below (it's from this chapter https://github.com/jwiegley/git-from-the-bottom-up/blob/master/2-The-Index/2-taking-the-index-further.md)

What you’d need to do something like this is an index which allows for greater depth than one commit at a time.

Hi there. I'm working through your book, and I notice that the last commit was a few years ago. My first question is what version is the last covered in this book. The second is, for someone who is trying to move from git dilettante to a working knowledge of git, are there any major changes in the last few years that are important for this level of understanding?

Thanks for all the work that has clearly gone into this guide- and for open sourcing it.

Hi!
This tutorial was great! Thank you for the wonderful read.

At the end, I somehow felt I wanted a like button or a counter so you could see how many people your text has helped so far.

Thank you again for this. I really enjoyed it.

I swear this has to be me, but I've following the tutorial three times on different machines and I get a different SHA1 value for "Hello, world!" than the tutorial.

Tutorial says it should be

$ git hash-object greeting
af5626b4a114abcb82d63db7c8082c3c4756e51b

I'm getting

C:\Users\Craig\Desktop\Git-Bottom-up\repo>git hash-object greeting
5dd01c177f5d7d1be5346a5bc18a569a7410c2ef

Also weird, when I type "Hello, world!" into this SHA1 generator: https://passwordsgenerator.net/sha1-hash-generator/, it gives "943A702D06F34599AEE1F8DA8EF9F7296031D699" which is different from both our values! I didn't look into why this is.

We're on Windows 10, using git version 2.18.0.windows.1.

Thanks!

On https://jwiegley.github.io/git-from-the-bottom-up/2-The-Index/2-taking-the-index-further.html Quilt and Stacked Git are mentioned without explanations of what they are or links to learn more about them. Based on context, I assume that stg is Stacked Git, but this is also a bit unclear.

Hi!

I thought of translating your document into Russian, but then I discovered that you have explicitly restricted derivative works by the license you've chosen. Translation into another language is surely a derivative work, so

• Is there a good reason to use a license of ND-kind?
• Is there anything I can do to translate the text in a lawful way?

http://ftp.newartisans.com/pub/git.from.bottom.up.pdf

It looks amazing.

The max-width: 620px; is the CSS looks kind of bad on a 1080p screen and above. Might I suggest something like max(calc(50%), 620px)?

https://jwiegley.github.io/git-from-the-bottom-up/2-The-Index/2-taking-the-index-further.html

The section is showing its age. I doubt many are going "Quilt!" while reading these days. Also, stg doesn't really offer much afaict on top of just git stash push.

Would a PR for dropping the section be accepted?

There's an issue with how paragraph indents are styled on https://jwiegley.github.io/git-from-the-bottom-up/. There's no CSS in this repo, so I don't know if this is the right place to raise this issue, but there isn't a link anywhere to the repo for the hamilton.css stylesheet either.

The default stylesheet indents every paragraph and then removes the indent from the first paragraph child of the parent element, like so:

.main-content p {
    text-indent: 1.5em;
}

.main-content p:first-of-type {
    text-indent: 0;
}

The trouble with this is that paragraphs end up being indented after non-paragraph sibling elements, like <pre></pre>:

The fix is to set none of the paragraphs as being indented, and then indent all paragraphs that follow a previous sibling paragraph:

.main-content p {
    text-indent: 0;
}

.main-content p + p {
    text-indent: 1.5 em;
}

Which renders like this:

In the further reading section, the link for 'git for the confused' no longer works.

One solution is to replace the link with one archived by the Wayback Machine -
https://web.archive.org/web/20200205094035/http://www.gelato.unsw.edu.au/archives/git/0512/13748.html

After the last example of rebasing in this page there is an image showing the new rebased repository.

The first commit after Z, states that I'equals B+C+, I'm not sure but that would not be C+Xinstead?

I assume that current https://jwiegley.github.io/git-from-the-bottom-up currently is generated from current master of https://github.com/jwiegley/git-from-the-bottom-up.

Let reach X be the set of commits reachable from X.

Subissue 1

name1..name2 — This and the following aliases indicate commit ranges, which are supremely useful with commands like log for seeing what’s happened during a particular span of time. The syntax to the left refers to all the commits reachable from name2 back to, but not including, name1. If either name1 or name2 is omitted, HEAD is used in its place.

As far as I know (and at least with the command git rev-list) X..Y means: reach Y \ reach X. However, the above means something like:

if X not in reach Y
then ???
else reach Y \ reach X

But that clearly is not the case.

Subissue 2

master.. — This usage is equivalent to master..HEAD. I’m adding it here, even though it’s been implied above, because I use this kind of alias constantly when reviewing changes made to the current branch.

..master — This, too, is especially useful after you’ve done a fetch and you want to see what changes have occurred since your last rebase or merge.

Until here the book seems to be written with the intention that it works for people who are completely new to Git. If this is the case, then it may not be clear enough at this point what a merge is and certainly not what a rebase is. It also may not be clear enough, that current HEAD is meant to be a reference to, e.g., a topic branch.

If the reader already knows some Git, then he knows that a fetch does not update master but something like origin/master. This probably makes the description for ..master especially confusing.

I think something like the following would be good: Before the bullets describing the .. construct, insert an image of a commit graph with something like

         o---o---o---B
        /
---o---1---o---o---o---A

(taken from man 1 git-merge-base) and additionally: a reference master pointing to A, a reference topic pointing to B, a symbolic reference HEAD pointing to topic. Then use the example as the central device for explanation.

If something like this is in fact already meant here, then with subissue 1 we reach ??? here.

Subissue 3

name1…name2 — A “triple-dot” range is quite different from the two-dot version above. For commands like log, it refers to all the commits referenced by name1 or name2, but not by both. The result is then a list of all the unique commits in both branches. For commands like diff, the range expressed is between name2 and the common ancestor of name1 and name2. This differs from the log case in that changes introduced by name1 are not shown.

"the common ancestor of name1 and name2" does not necessarily exist (at all, or uniquely). No idea what happens then.

It would be really nice if the book had a whole section on all relevant-to-git topological notions of the commit graph before. :-)