>> 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.

Well, you know, HTML is quite extensively documented. And yet, different 
implementations don't interoperate too well...

>> 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. :-)

It looks like "git reset" will do it, though I'm not completely sure on 
the syntax. It doesn't really matter; NetBeans is still going to force 
me to follow a 3-stage process.

>> One extremely irritating issue is that it's apparently impossible to
>> create a commit object of a completely empty repository.
>
> Your commit has to point to a tree (aka directory). But you can start a
> repository with an empty directory.

Mmm, OK.

>> Rather /more/ irritating is this: I made a commit, and then realised the
>> description was wrong.
>> 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.

I'm used to Darcs, where you can almost arbitrarily add, remove and 
reorder changes. In particular, if you commit something, and then do "oh 
bugger, I didn't mean to do that", it's one command to delete the 
commit, which then makes all the changes it contained appear as "new" again.

> But that doesn't mean you need to see it.
>
> http://stackoverflow.com/questions/927358/git-undo-last-commit

Right... so... my options are:

1. Delete the last commit /and the changes it contained/. (Why would you 
ever want to do this?)

2. Move the head back one commit, but not actually delete the commit.

3. Move the head back one commit, but not actually delete the commit, 
and leave the changes in the staging area.

Nowhere is there an option that says "perform the exact inverse of what 
I just told you to do".

>> 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."

...which lists the three options above, none of which undo the commit.

It seems the best you can do is create a /new/ commit - which isn't much 
help when the whole problem is that you have a commit that's labelled as 
something it isn't, which is misleading and bound to cause confusion later.

> "git gc" with the appropriate options to prune.

That at least might work. (Somebody somewhere says prune only removes 
dangling branches older than 2 weeks.) It's really quite frustrating how 
all this documentation seems to be tutorials, blog posts and SO 
questions. Isn't there a /reference manual/ somewhere??

>> (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? ;-)

If your commit is wrong, you don't /want/ to keep it. :-P But seriously, 
if I want to change something, why shouldn't I be able to change it? Git 
has an "amend" command, it's just that it doesn't /amend/ the commit - 
it creates a new one, but leaves the old one in place. The Darcs "amend" 
command actually deletes the amended commit - you know, like what you'd 
expect an amendment to consist of. :-P

I agree it's not a good idea to go back and start changing history from 
2 years ago. But I don't see why you can't edit the last committed 
change. That just seems like a silly limitation.

In a sense, Darcs /isn't/ that worried about losing commits. In Darcs, a 
branch is a repository, and so to remove changes from a branch, you have 
to delete commits. That's just how it works.

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

You shouldn't group related changes together, no?

That's the other thing. With Darcs, I edit some files for a while, and 
then say "commit this". It shows me each and every change, and asks if I 
want to include that. And even though I've only got one set of changed 
files, I can syphon off the changes and ground them into several 
logically separate commits. Git can't seem to do that. If I want to 
record some but not all changes, I have to manually construct the file 
contents that I want committed. (And obviously NetBeans does nothing to 
help with this.)

What I end up doing is just committing /everything/, because it's less 
hassle. But then if I ever need to go back, I'd have to go in big giant 
steps rather than small logical increments.

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

How about /not/ having to make a commit that records changes that I've 
already committed? :-P

Actually, it would probably be easier if NetBeans would actually show 
me, you know, /a history/, so I can see what's actually /happening/, 
rather than just having to try to guess from the hashes which branches 
contain what...

Post a reply to this message