On 11/04/2012 02:19 PM, Invisible wrote:
> On 10/04/2012 01:55 PM, Invisible wrote:
>
>> 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.
>
> It also means that you can fairly easily copy a file from one branch to
> another, as I just discovered...

OTOH, if you do this with Darcs, you keep the file history, since Darcs 
tracks individual files, not entire repositories. But on the first hand 
again, you can't copy a history if it involves files you don't want to 
copy...

Post a reply to this message

On 4/11/2012 2:23, Invisible wrote:
> 1. Delete the last commit /and the changes it contained/. (Why would you
> ever want to do this?)

Changes aren't stored in git, so naturally deleting a commit deletes the 
changes. Delete the commit without deleting the changes in your working 
copy, and then create a new commit based on those changes.

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

If nothing points to the commit, it's effectively deleted.

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

There you go.

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

I'm not sure what you're trying to say. #3 does what you want, if you follow 
it up with "delete commits that no heads or other commits point to."

It's like you're complaining "there's no one option that both deletes the 
directory element *and* removes the file's data."

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

That would be the "appropriate options" to modify. Tell it to use zero days.

Why are you hell-bent on getting rid of that commit? Do you zero out all the 
sectors of your hard drive every time you delete a file?

> 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 pointed you to it. Plus, there's the man pages, which you often complain 
you don't like because it's not tutorial enough. :-)

> If your commit is wrong, you don't /want/ to keep it. :-P

And in git, you don't. You just have the option of undeleting it for a week 
or two.

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

Files are named after their contents. If you want to make a change, by 
definition, you have to give it a new name.

 > The Darcs "amend" command actually
> deletes the amended commit - you know, like what you'd expect an amendment
> to consist of. :-P

So your concern is that there's a commit out in the git data store that 
nothing points to, that will get gc'ed in a couple of weeks, and which you 
don't want to manually have to run an extra step to get rid of it before then?

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

You can. That's exactly what the -amend option does. It creates a new commit 
because you changed the content and it has to be given a new name.

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

Right. And you can remove commits from git by deleting them. You're just 
unhappy that git asks you to take two steps (or wait a while) to remove a 
commit irrevocably.

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

No. You should group the minimum number of changes that gives you a 
consistent state.  What if you find the implementation of the routine is 
right, but the code calling it is all screwed up?

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

Sure it can. That's the coolest thing about git. Indeed, that's exactly the 
point of the staging area being different from the working directory. You 
copy the changes you want to commit into the staging area, then commit it.

What you mean is "netbeans interface to git doesn't do that."

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

You're doing it wrong. Don't blame git for netbeans not being git.

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

You never made the change before where both pieces of code are in the same file.

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

Again, you're looking at a bad interface to git, and then complaining git 
doesn't work. It's like looking at command.com and complaining "there's no 
way to automate access to excel spreadsheets!"  Nothing you're complaining 
about is true of the git tools, only netbeans.

-- 
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/11/2012 2:57, Warp wrote:
>    Who thought this would be a good idea?

On the other hand, it prevents you from having to check out the entire 
repository just to get one project.

-- 
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/11/2012 3:33, Le_Forgeron wrote:
> (ok, give me a usage of a hammer for a gardener ?)

Snails.  Wheeee!

-- 
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/11/2012 3:27, Invisible wrote:
> 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!

Had the same problem with Eclipse. Turns out that it's picking up half the 
configuration from its own files, the other half from the "system colors", 
and assuming the system colors are (for example) that windows of certain 
types are light colored instead of dark colored.

-- 
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/11/2012 6:37, Invisible wrote:
> OTOH, if you do this with Darcs, you keep the file history, since Darcs
> tracks individual files, not entire repositories.

Git deduces this, which is the right way to do it, methinks. Darcs can't 
*really* tell if this file came from that file. It can only record what you 
told it.

-- 
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 12/04/2012 05:20 PM, Darren New wrote:
> On 4/11/2012 3:33, Le_Forgeron wrote:
>> (ok, give me a usage of a hammer for a gardener ?)
>
> Snails. Wheeee!

CANNOT UNSEE. >_<

Post a reply to this message

On 12/04/2012 05:21 PM, Darren New wrote:
> On 4/11/2012 3:27, Invisible wrote:
>> 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!
>
> Had the same problem with Eclipse. Turns out that it's picking up half
> the configuration from its own files, the other half from the "system
> colors", and assuming the system colors are (for example) that windows
> of certain types are light colored instead of dark colored.

Hmm. Well, under Windows XP, the window title colour /is/ navy blue... I 
notice that when I ran it under GNOME, it looked fine. So yeah, maybe 
that's it.

Post a reply to this message

On 12/04/2012 05:22 PM, Darren New wrote:
> On 4/11/2012 6:37, Invisible wrote:
>> OTOH, if you do this with Darcs, you keep the file history, since Darcs
>> tracks individual files, not entire repositories.
>
> Git deduces this, which is the right way to do it, methinks. Darcs can't
> *really* tell if this file came from that file. It can only record what
> you told it.

I have repository A, which contains file X. I have repository B, which 
does not contain file X. I pull all the changes relating to file X from 
repository A into repository B. Now B contains X, and all its history.

If I do this with Git branches, then on branch B, a file named X 
suddenly shows up, but there's no record that it was actually copied 
from branch A. It just records what's /in/ the file.

Post a reply to this message

On 12/04/2012 05:16 PM, Darren New wrote:
> On 4/11/2012 2:23, Invisible wrote:
>> 1. Delete the last commit /and the changes it contained/. (Why would you
>> ever want to do this?)
>
> Changes aren't stored in git, so naturally deleting a commit deletes the
> changes. Delete the commit without deleting the changes in your working
> copy, and then create a new commit based on those changes.

That's what I'm saying - option #1 deletes the commit AND REVERTS THE 
WORKING COPY. I can't fathom why you'd want to revert your working copy. 
That means that anything that was in the commit is now /gone forever/. 
Which is no help if you actually want to redo the commit.

>> 2. Move the head back one commit, but not actually delete the commit.
>
> If nothing points to the commit, it's effectively deleted.

Except that every single time I look at the history tree, this dangling 
commit shows up, with a description which doesn't match what's actually 
in it. Which is the problem I was trying to sort out in the first place.

>> Nowhere is there an option that says "perform the exact inverse of what I
>> just told you to do".
>
> I'm not sure what you're trying to say. #3 does what you want, if you
> follow it up with "delete commits that no heads or other commits point to."

> That would be the "appropriate options" to modify. Tell it to use zero
> days.
>
> Why are you hell-bent on getting rid of that commit? Do you zero out all
> the sectors of your hard drive every time you delete a file?

I made a trivial mistake. It just surprises me that it's this long and 
complex to undo such a simple and common mistake.

[Although it would be much /less/ common if NetBeans wasn't being so 
retarded. :-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.
>
> Files are named after their contents. If you want to make a change, by
> definition, you have to give it a new name.

Darcs also names changes after their hash. The Darcs amend command also 
changes the commit name. It's just that Darcs automatically deletes the 
old, incorrect commit, and keeps only the new, corrected one. Isn't that 
what "amending" something would be expected to mean?

>> In a sense, Darcs /isn't/ that worried about losing commits.
>
> Right. And you can remove commits from git by deleting them. You're just
> unhappy that git asks you to take two steps (or wait a while) to remove
> a commit irrevocably.

It would just be nice if there was a way to actually mark unwanted 
commits as "deleted", rather than them still showing up as part of the 
valid history of the project.

>>> Heavens no!
>>
>> You shouldn't group related changes together, no?
>
> No. You should group the minimum number of changes that gives you a
> consistent state. What if you find the implementation of the routine is
> right, but the code calling it is all screwed up?

Heck, I generally don't even worry about consistent states. Not, as in, 
whether the project is runnable. I work in whole logical changes. Like, 
I group all the changes to do with X together, all the changes to do 
with Y together, and so on. It might be that you need to apply X, Y and 
Z to get back to a runnable state again. But it's more that if I'm in 
the middle of editing and I screw it up, I want to be able to back out 
just the thing I'm trying to edit, not the whole of X, Y and Z and start 
over.

>> 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.
>
> Sure it can. That's the coolest thing about git. Indeed, that's exactly
> the point of the staging area being different from the working
> directory. You copy the changes you want to commit into the staging
> area, then commit it.

No. This still requires you to manually edit the files to the right 
point. Like, if I edit a file and change X, Y and Z, then when I decide 
I want to commit it, I have to go through the file, undo Y and Z (but 
not forget how to redo them), commit the file with just X changed, then 
redo Y, and commit that, and finally redo Z and commit that. The fact 
that there are two copies of the file is no help at all here. It's not 
like you can edit the staging copy.

> What you mean is "netbeans interface to git doesn't do that."

Actually, NetBeans seems to have its own internal history tracking, so 
in a sense, it /can/. You can find the lines you changed, hit "revert 
change", do your commit, and then jab Undo a few times to redo the 
changes. It's klunky and hard, but it's better than just Git by itself.

> You're doing it wrong.

Or rather, "Git isn't really supporting my workflow".

> Don't blame git for netbeans not being git.

Oh, /some/ of the problems I've had are definitely to do with NetBeans 
being lame. I won't blame Git for that.

>> How about /not/ having to make a commit that records changes that I've
>> already committed? :-P
>
> You never made the change before where both pieces of code are in the
> same file.

I meant more that of you change one file on one branch, and an unrelated 
file on another branch, to get those changes together, you need to 
record a new commit. Even through there's no new changes, another than 
both files being in the same branch now.

>> 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...
>
> Again, you're looking at a bad interface to git, and then complaining
> git doesn't work.

No. With /this/ point, I'm complaining squarely about NetBeans. If you 
install the actual Git binary, it comes with some passable tools for 
visualising what's actually going on. It's not pretty, but it works.

(I'm still trying to figure out how to get gitk to resize so I can see 
the whole history tree. There doesn't seem to be a way to enlarge the 
tiny tree view at the top and shrink the enormous commit viewer at the 
bottom which I don't care about...)

Post a reply to this message