POV-Ray : Newsgroups : povray.off-topic : Git : Re: Git Server Time
29 Jul 2024 04:21:22 EDT (-0400)
  Re: Git  
From: Darren New
Date: 10 Apr 2012 21:26:57
Message: <4f84dde1@news.povray.org>
On 4/10/2012 5:55, Invisible wrote:
> How do we know the two implementations work the same way?)

Given thatall objects in the repository are looked up by the cryptographic 
hash of their contents, the whole thing would fall apart if they weren't.

That said, the git book extensively documents the format of the repository, 
which is completely trivial in practice. So... it's not hard.

> If I'm understanding this correctly, history is stored as commit objects,

Basically, yes.

Try this: http://book.git-scm.com/
It's excellent. (If it's the one I remember, which I think it is.)

> OTOH, it's irritating to have to switch branches, click "merge revision...",
> select the branch I was just on, and then switch back again every single
> time I want to update one branch to match another. I imagine this is a
> limitation of the NetBeans, and if I used Git directly there would be a
> command to immediately update a branch without actually switching to it.

Yes. Or you'd write a shell script. :-)

> One extremely irritating issue is that it's apparently impossible to create
> a commit object of a completely empty repository. So there can never be a
> branch where you start again from scratch. Every branch must always start
> out with /something/ in it. I suppose I could just create a dummy file to
> create commit 0, and then delete it again. But it's irritating.

Your commit has to point to a tree (aka directory). But you can start a 
repository with an empty directory.  If you manipulate things with the 
lower-level commands, you can stick stuff in the repository without any 
commits at all. (Which is how "commit" creates a commit - it puts the things 
in the repository, then points a commit at them.)

> Rather /more/ irritating is this: I made a commit, and then realised the
> description was wrong. (NetBeans defaults to using the exact same
> description as the previous commit - because that's SO USEFUL, right?) So I
> looked for the command to undo the last commit. Apparently there isn't one.

You can only add to the repository, unless you prune it. But that doesn't 
mean you need to see it.

http://stackoverflow.com/questions/927358/git-undo-last-commit

> I even found a question on Stack Overflow about it. Lots of people
> suggesting various complex workarounds to try to solve it, but nothing that
> says "just delete the last commit object!"

Uh, pretty much the first hit on google for "git revert commit."

> Using the GUI, I was able to create a /new/ commit object identical to the
> old one but with a different description. The old commit object is still
> there though, showing up is a dangling branch. And I cannot find any way to
> get rid of it. It's all very annoying.

"git gc" with the appropriate options to prune.

> (I could mutter something about how in Darcs this problem takes about 15
> seconds to fix... But what would that prove?)

It proves that Darcs isn't too worried about losing commits? ;-)

> One mildly niggling thing is that Git imposes an artificial order on things.
> Like, with Darcs, if I edit file X, and then make some completely unrelated
> change to file Y, then as far as Darcs is concerned, there is no ordering
> relation between these unrelated changes. But to Git, one commit is
> descended from the other, even though there's no logical relationship.

Git doesn't store changes. It stores snapshots. The order isn't so much 
artificial as irrelevant to what you happen to be doing right now.

> Then again, shouldn't you be recording those
> two changes in the same commit?

Heavens no!

> The way Git does things does have the advantage that a situation like this
> just never happens. On the other hand, if I change file X on one branch and
> file Y on another branch (so the changes are /definitely/ unrelated), you
> still have to "merge" the changes to get back to a single branch.

Which makes sense. Commits are the fundamental unit of atomic change in git. 
Now you have a snapshot with X changed, a different snapshot with Y changed, 
and a snapshot with the two changes together. What could be easier?

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.