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

Le 11/04/2012 03:15, Darren New nous fit lire :
> On 4/10/2012 12:05, nemesis wrote:
>> You know git was written as a reverse engineering of the proprietary
>> cvs the
>> Linux kernel project was using at some point, right?
> 
> Are you sure? I thought it was written to replace the reverse
> engineering of the proprietary cvs?
> 
CVS is a version control system (a real one, like rcs and svn).
You should reword "proprietary cvs" as "proprietary SCM"

Git was written to get away from a license issue with BitKeeper.

Post a reply to this message

On 11/04/2012 10:27 AM, Le_Forgeron wrote:
> You should reword "proprietary cvs" as "proprietary SCM"

Serial Copy Management? No, wait... >_<

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I gather a number of people do use Git, however.

  At least git is much better than another extremely popular versioning
system, namely svn, which is a real PITA.

  Git has this marvelous idea of keeping all of its versioning files in
one single directory in the root of the project. Seems rather self-evident,
one would think.

  Svn, on the other hand, has this completely braindead idea of having a
versioning directory in each single subdirectory of the project. Which
means that it breaks badly if you do *anything* to *any* directory in
your project. Copy a directory from one place to another? Svn breaks.
Rename a directory? Svn breaks. Copy an unversioned directory from
somewhere else onto a versioned directory in your project? Svn breaks.
Copy a directory from one project to another? Svn breaks.

  And "svn breaks" means that it will refuse to commit, update, fix or
do anything to the directory. (Fixing the problem usually involves
either removing the .svn subdirectories manually, or removing the
entire offending directory hierarchy, updating, and then copying the
files inside the directories (rather than entire directory structures)
from one place to another, which can be really annoying if you have
subdirectories inside subdirectories...)

  This can be *extremely* annoying when you have a complex directory
structure that you would want to copy from one place to another. With
git it isn't a problem: Just copy it and that's it. With svn you will
be breaking your project.

  Who thought this would be a good idea?

-- 
                                                          - Warp

Post a reply to this message

On 11/04/2012 10:57 AM, Warp wrote:
>    At least git is much better than another extremely popular versioning
> system, namely svn, which is a real PITA.
>
>    Git has this marvelous idea of keeping all of its versioning files in
> one single directory in the root of the project. Seems rather self-evident,
> one would think.
>
>    Svn, on the other hand, has this completely braindead idea of having a
> versioning directory in each single subdirectory of the project. Which
> means that it breaks badly if you do *anything* to *any* directory in
> your project.
>
>    Who thought this would be a good idea?

That's pretty screwed up, man...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> That's pretty screwed up, man...

  It's not fun trying to fix a coworker's local copy of the project using
skype as a communication interface, when he once again accidentally broke
the versioning system via a very simple file operation (such as copying
the contents of a directory to the project). And he didn't even do anything
stupid; it's usually just a simple and normal file operation you would do
as a matter of course, and in fact I have broken the project several times
in the same way as well. It's svn that's the stupid one.

-- 
                                                          - Warp

Post a reply to this message

On 11/04/2012 11:23 AM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> That's pretty screwed up, man...
>
>    It's not fun trying to fix a coworker's local copy of the project using
> skype as a communication interface, when he once again accidentally broke
> the versioning system via a very simple file operation (such as copying
> the contents of a directory to the project). And he didn't even do anything
> stupid; it's usually just a simple and normal file operation you would do
> as a matter of course, and in fact I have broken the project several times
> in the same way as well. It's svn that's the stupid one.

Isn't an SCM supposed to /help you/, not constantly get in your way?

Post a reply to this message

On 10/04/2012 01:55 PM, Invisible wrote:

> So anyway, I downloaded the /real/ Git implementation, which comes with
> some visualisation tools. (NetBeans does a really useless job of showing
> you the current state of your repository. It shows you the ID of the
> current commit and that's about it.)

> All of this stuff gets /much/ easier to follow with gitk to show me WTF
> is actually happening.

Question: Who designed gitk to default to using black text on a navy 
blue background? That's frigging *absurd*! Fortunately, you can change 
it - because it's utterly illegible!

Post a reply to this message

Le 11/04/2012 12:25, Invisible nous fit lire :

> Isn't an SCM supposed to /help you/, not constantly get in your way?

Yep, but not all SCM fit all the people.

The same way a hammer is a helpful tool for a carpenter, but in the way
of a gardener. (ok, give me a usage of a hammer for a gardener ?)

The choice of a SCM must be made in perspective of the usage of the work
place. A good choice for a carpenter might be a poor choice for a
gardener, copying your neighbor is not always the best move. (but might
be ok if you're a mason and you're next a carpenter).

As usual, there is no universal best solution (otherwise, it would
dominate the place and you wouldn't have a choice).

Post a reply to this message

On 11/04/2012 11:33 AM, Le_Forgeron wrote:
> Le 11/04/2012 12:25, Invisible nous fit lire :
>
>> Isn't an SCM supposed to /help you/, not constantly get in your way?
>
> Yep, but not all SCM fit all the people.

Well, that's true, but a tool that breaks if you do something very 
simple and common strikes me as being a bad tool. At a minimum, it ought 
to provide an easy way to fix the problem...

Post a reply to this message