small medium large xlarge

Generic-user-small
20 Aug 2009, 12:39
Hugh Sasse (4 posts)

The book has been a big help in getting my head around what is going on with git, and I appreciate that writing something of this size is a large effort. There are a few things I’d like to see that I’ve not found in the book. Having the information available in the git docs online is not really the point :-).

Like some others, I’m still not clear about what rebase is doing and why it is needed. Maybe an explanation of the origins of its name would help. Yes, for modifying the history, but normally you don’t want to get into time travel paradoxes. In the section on tags, in chapter 3 about page 34, you introduce rebase, but I fail to see why merge is not appropriate there.

On page 5 when talking about what to put into git repositories, you mention images. There seems to be no mention that I have found about how Git handles binary data. If you do a git diff, will it splurge the binary changes to your terminal, or can it detect non-textual data like Perl can (-B), and not do that? Such output tends to do horrible things to terminals. This also raises questions about how the data is stored in the repository, at a conceptual level at least. diff itself isn’t geared up for binary files. I’m thinking about more manageable version control of MS Word documents, for one thing.

Trying to find out the answer to the above, binary doesn’t appear in the index. I think the index could be more comprehensive, including the commands directly, for example “branches” is there, but no entry in “B” for just “branch”, “rebasing” but no “rebase”. “HEAD” is not in the index. The commands are under git, admittedly.

Does git mv move the file, or just declare that it has been moved to git, like add declares a file has changed? The online docs suggest the former, but it didn’t seem clear to me from the text. Perhaps showing ls output would help? Yes, ls is not applicable to Windows, but…

Git archive seems to save some branch to a zip or tar file, ready for release. I’m not clear as to whether this includes the .git directory or not, i.e. the repository itself.

Earlier messages in the forum speak of a recipes appendix or a workflow chapter. On the whole, the topics organisation of the book does reflect tasks, but not always. I think this would be useful. I think moving repositories about, Eg, from a university machine to a pen drive to a home machine, and back would be a useful workflow to discuss. How do you do separate development when the repository is only local but group writeable, such that you can’t treat it as remote? This would be a similar situation to fixing code at a customer site and trying to get it back into a company repository behind the firewall. Can you push to a file, copy that over and update from it in such a way that it merges properly with the modifications of others?

How are cross-platform issues handled? (If you pull from a Unix repository, and then make changes on Windows, how do you ensure line endings don’t get munged? Git coming from a Unix background probably doesn’t handle line endings specially.)

Given that you want to keep tests in the repository, and the relevant one may already be there, is there a way to get git bisect run to checkout the test it needs from a branch? My reading of the online docs suggests not, but maybe there’s a way to do this which I’ve not figured out yet.

I hope this is useful feedback. Thank you.

Generic-user-small
15 Jun 2010, 16:28
Lally Singh (1 post)

Yeah, and anything at all on ‘git stash’, which is pretty useful from what I’ve been able to use so far.

Generic-user-small
13 May 2016, 18:46
Derek Hofmann (1 post)

A discussion of the pros and cons of submodules versus subtrees would be useful in a second edition.

You must be logged in to comment