My version control system of choice is Darcs. But obviously nobody 
actually uses that. I gather a number of people do use Git, however. And 
NetBeans has Git capabilities built-in.

I did look to see where it installs the Git binaries. It doesn't. It 
uses JGit, a complete reimplementation of Git in Java. (This makes me 
nervous... How do we know the two implementations work the same way?)

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

I had another look over "Understanding Git"

http://www.eecs.harvard.edu/~cduan/technical/git/

If I'm understanding this correctly, history is stored as commit 
objects, which one storing the complete state of the entire codebase, 
plus the IDs of its ancestor commit(s). The "branches" or "heads" 
themselves are merely bookmarks into this tree of commits. They let you 
conveniently get from place to place and label your stuff, but you can 
create new ones or destroy existing ones at will. The commits themselves 
are the actual history.

So far, that understanding hasn't caused me too many problems. And I 
quite like the way that a single repository holds multiple branches. 
Darcs follows an "every repository /is/ a branch" mentality. Which 
works, but makes it kinda long-winded to change branches. In NetBeans, I 
can click "switch branch" and all my code suddenly changes.

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.

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.

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

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.

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

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.

Conversely, with Darcs, if I edit file X to add a new function, and then 
edit file Y to /use/ that new function, then Darcs doesn't see any 
relationship, but there /is/ one, and Darcs' idea that the two changes 
are unrelated is flat-out wrong. Then again, shouldn't you be recording 
those two changes in the same commit?

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. To Darcs, this would just be adding in a few more 
changes. Still, it seems to /work/ just fine, so who's complaining?

All of this stuff gets /much/ easier to follow with gitk to show me WTF 
is actually happening. Unfortunately, Git seems to be a Unix 
application, meaning that you cannot install it without first installing 
a Unix emulator. The default installer binary seems to install MSYS, 
including Bash, Perl, Tk, and a whole bunch of other stuff. *sigh*

Post a reply to this message

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

Another irritating thing is that creating a new branch does not /switch 
to/ that branch. Just now I created a new branch, did a commit, and then 
realised it updated the old branch, not the new one.

Fortunately, since a "branch" is simply a bookmark, all I need to do is 
wind the new branch forward and wind the old one backwards. 
Unfortunately, NetBeans can wind a branch forward, but cannot easily 
wind backwards. Fortunately gitk can, but then NetBeans is confused, 
until I switch branches back and forth a few times.

Damn that was irritating! LOL.

Post a reply to this message

Le 10/04/2012 14:55, Invisible nous fit lire :
> 
> 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. 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!"
> 
> 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.

Trick learned from mercurial (hg): always work on a secondary repository
(not the "reference" one). Even better, a tertiary or deeper one.
If you did a wrong commit on the secondary, instead of pushing back
(well, its "git push" !)  to the parent, just delete it and start over
(you might keep your delta first with some patch-compatible commands, so
as to reply them automatically: "hg diff" is very useful, i guess there
is some version for git too)

Basic of distributed revision control: as long as you did not export
your commit, you can hide your fault by just deleting the whole issue.
Once exported, you're doomed.

(Well, there is a few extension in hg to move/rewrite commits (even
regroup a few one), but they work only as far as the repositories which
know the details are erased from existence in order to never provide the
original pieces of information again)

As they say: Mount a scrap monkey!

Post a reply to this message

>> 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.
>
> Trick learned from mercurial (hg): always work on a secondary repository
> (not the "reference" one). Even better, a tertiary or deeper one.
> If you did a wrong commit on the secondary, instead of pushing back
> (well, its "git push" !)  to the parent, just delete it and start over
> (you might keep your delta first with some patch-compatible commands, so
> as to reply them automatically: "hg diff" is very useful, i guess there
> is some version for git too)

Presumably you could just delete the .git subfolder and recopy... oh 
wait, you're supposed to do git clone, aren't you? I wonder if that does 
anything extra beyond just copying the files...

> Basic of distributed revision control: as long as you did not export
> your commit, you can hide your fault by just deleting the whole issue.
> Once exported, you're doomed.

Well, yes. Once it's public, it's part of history. And then if you want 
to change it, you must rewrite history. Which isn't easy...

Post a reply to this message

Invisible escreveu:
> I gather a number of people do use Git, however.

the understatement of the year!  well, since it's Andrew, perhaps just 
of the month, we'll see...

It's now all around us.  Plus, it's a cool word.  I hope Gimp uses Git. :)

> All of this stuff gets /much/ easier to follow with gitk to show me WTF 
> is actually happening. Unfortunately, Git seems to be a Unix 
> application, meaning that you cannot install it without first installing 
> a Unix emulator. The default installer binary seems to install MSYS, 
> including Bash, Perl, Tk, and a whole bunch of other stuff. *sigh*

way to go!

You know git was written as a reverse engineering of the proprietary cvs 
the Linux kernel project was using at some point, right?

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

Le 10/04/2012 20:52, Orchid Win7 v1 nous fit lire :
> Presumably you could just delete the .git subfolder and recopy... oh
> wait, you're supposed to do git clone, aren't you? I wonder if that does
> anything extra beyond just copying the files...

Lesson learned a long time ago: never try to be smarter by going in the
backstage. Just play fair, respect the rules.
(of course, as you become a wizard, the limit of the backstage moves)

Post a reply to this message

On 10/04/2012 08:38 PM, Le_Forgeron wrote:
> Le 10/04/2012 20:52, Orchid Win7 v1 nous fit lire :
>> Presumably you could just delete the .git subfolder and recopy... oh
>> wait, you're supposed to do git clone, aren't you? I wonder if that does
>> anything extra beyond just copying the files...
>
> Lesson learned a long time ago: never try to be smarter by going in the
> backstage. Just play fair, respect the rules.
> (of course, as you become a wizard, the limit of the backstage moves)

Indeed. This definitely works with Darcs. But I'm not sure if it works 
for Git. I don't see why it wouldn't, but you never know...

Post a reply to this message

On 10/04/2012 08:05 PM, nemesis wrote:
> Invisible escreveu:
>> I gather a number of people do use Git, however.
>
> the understatement of the year!

It's only April.

> It's now all around us. Plus, it's a cool word. I hope Gimp uses Git. :)

A number of people use Git. A number of others use RCS, CVS, Subversion, 
Mercurial, BitKeeper, Bazaar, Perforce, Visual Source Safe...

(Hell, there are even large projects which use Darcs. Though the main 
one, GHC, recently switched to Git. It is unclear to me whether this is 
because Darcs wasn't good enough, or just because all the would-be 
contributers use Git not Darcs.)

Post a reply to this message

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?

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

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