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

Darren New <dne### [at] sanrrcom> wrote:
> 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.

  Shouldn't different projects go into different branches?

-- 
                                                          - Warp

Post a reply to this message

On 13/04/2012 09:46 AM, Warp wrote:
> Darren New<dne### [at] sanrrcom>  wrote:
>> 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.
>
>    Shouldn't different projects go into different branches?

Depends on your SCM I suppose.

I know that, for example, GHC is managed as several interrelated 
projects. GHC is a Haskell compiler written in Haskell, and as such 
depends on the Haskell standard libraries, which are separate from the 
actual compiler. The test suite is also a separate project. But all of 
these projects live in the same source tree, so you can actually build 
the compiler...

What it means is that you can, for example, update the test suite, 
independent of any particular compiler version. Or if there's a 
performance improvement to one of the standard libraries, you can 
rebuild the compiler with that, without actually changing the compiler. 
Stuff like that.

Post a reply to this message

On 4/13/2012 1:36, Invisible wrote:
> 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.

Because you realized (say) that you've just made a change and a commit on 
the wrong repository? If it's not the behavior you want, don't use that 
option. :-)

> Except that every single time I look at the history tree, this dangling
> commit shows up,

That's kind of odd. I don't think commits with no pointers to them should be 
showing up. But if it bothers you, git gc it.  I suspect netbeans is what's 
at fault here, not git.

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

You made a simple mistake committing code changes to a repository 
potentially shared with the entire world. :-)  That's not a small mistake in 
the grand scheme of things, and certainly worthy of requiring two entire 
command lines to entirely eliminate.

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

So does git. Maybe it's netbeans screwing things up.

> Heck, I generally don't even worry about consistent states. Not, as in,
> whether the project is runnable.

Generally, one is expected to not commit broken code. That's like one of the 
fundamental no-no's of repositories. I guess you don't have coworkers tho. 
Just so you know.

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

Sure. But if logical change X can be broken into 4 separate steps, each of 
which leaves you with a working system, why not commit in even smaller 
steps?  Why not commit the code to add records to the database, *then* 
commit the UI that invokes that code? Then if you utterly screw up the UI, 
you don't have to revert the database code.

> No. This still requires you to manually edit the files to the right point.

No. Really. It doesn't. Heck, you can even do it from the command line.

http://book.git-scm.com/4_interactive_adding.html

If you prefer the GUI, try this:

http://nathanj.github.com/gitguide/images/11.png

See the "unstage hunk" and "unstage lines"? There's also "stage hunk" and 
"unstage hunk".

(Parent URL: http://nathanj.github.com/gitguide/tour.html )

Again, you're being borked by netbeans. Remember that git commits whatever 
is in staging, without looking at your working copy. And it's not 
remembering where diffs came from and such. So if this really was a feature 
you needed, it would be trivial to add at the client end, and thus likely 
would have been added already. Deciding what changes get committed and what 
don't isn't part of git per se. It's just part of the front end. If you 
wanted to write a program to commit any different lines with the letter X in 
them, you could write that code pretty trivially.

> It's not like you can edit the staging copy.

It really is.

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

No, it really isn't. It's harder than just git-via-netbeans by itself, 
apparently.

>> You're doing it wrong.
> Or rather, "Git isn't really supporting my workflow".

What workflow are you trying to do? Submit only some of the changed 
hunks/lines in a commit without submitting the others? Trust me - I do this 
all the time. It's trivial. When I've finished a feature, I go thru the 
git-gui to mark all the bugfixes, and commit them in separate commits, then 
mark each feature and commit them. I tend to get something working and then 
turn it into 5 or 6 commits.

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

So, there's no change, other than just this one change? Right, got it. ;-)

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

Given it's in Tk, I'm assuming you grab the bar and drag it down, like any 
other pane in Tk or Windows or X. :-)

-- 
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/13/2012 1:46, Warp wrote:
> Darren New<dne### [at] sanrrcom>  wrote:
>> 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.
>
>    Shouldn't different projects go into different branches?

You mean different repositories? Yes, you can do it that way, but then you 
have to deal with people checking out branches in different places.

E.g., if I have a GUI for some code, and the back end, (or the kernel and a 
bunch of drivers,) I might want to have them both in the same tree because 
they make references to files via relative paths, but I might want to be 
able to compile the back end without compiling the GUI.

-- 
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/13/2012 1:07, Invisible wrote:
> 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.

Sure there is. Otherwise, if you update X and push it, git won't know what 
to push. Now, yes, if you copy just one file without actually copying the 
commit from A, then you're not going to know the file came from A. But 
that's the case if you stick the file on a USB stick and copy it that way 
too.  Answer: don't do that. Copy commits, not individual files.

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

> Answer: don't do that. Copy commits, not individual files.

How do you actually do that?

Post a reply to this message

>> Except that every single time I look at the history tree, this dangling
>> commit shows up,
>
> That's kind of odd. I don't think commits with no pointers to them
> should be showing up. But if it bothers you, git gc it. I suspect
> netbeans is what's at fault here, not git.

No, NetBeans won't show you a tree *at all*. It won't show you any 
remotely useful information about the state of your Git repo. All it 
shows is the names of the branches and the hash each one points to.

The dangling branch shows up in gitk though.

>> I made a trivial mistake. It just surprises me that it's this long and
>> complex to undo such a simple and common mistake.
>
> You made a simple mistake committing code changes to a repository
> potentially shared with the entire world. :-) That's not a small mistake
> in the grand scheme of things, and certainly worthy of requiring two
> entire command lines to entirely eliminate.

IF the change has already been shared with the world, then yes, that's 
not going to be easy to fix at all. But I haven't - that's the point. 
I'm used to it being trivial to fix mistakes that you haven't shared yet.

>> Heck, I generally don't even worry about consistent states. Not, as in,
>> whether the project is runnable.
>
> Generally, one is expected to not commit broken code. That's like one of
> the fundamental no-no's of repositories. I guess you don't have
> coworkers tho. Just so you know.

So if adding a new feature means performing a major refactor of the 
entire codebase, you're supposed to do that as one giant commit?

> Sure. But if logical change X can be broken into 4 separate steps, each
> of which leaves you with a working system, why not commit in even
> smaller steps?

More to the point, if what you need to do involves making a major 
breaking change in step 1, and not fixing the last of the things it 
breaks until step 25, are you really going to put all 25 steps into a 
single giant commit?

Like I said, I generally work in terms of points in time that I'm likely 
to want to go back to, rather than points in time where the code 
compiles. (If I did the latter, the entire project history would be, 
like, 3 giant commits with nothing inbetween!)

>> No. This still requires you to manually edit the files to the right
>> point.
>
> No. Really. It doesn't. Heck, you can even do it from the command line.
>
> http://book.git-scm.com/4_interactive_adding.html

Ah, so there *is* an interactive diff mode, it's just hidden?

> Again, you're being borked by netbeans.

Yeah, it's not the best. Then again, it appears to support Mercurial and 
Subversion as well, so maybe the problem is that it tries to handle them 
all the same way...

> Remember that git commits
> whatever is in staging, without looking at your working copy.

Sure. But if you want to record a particular version of that file, you 
still need to generate it somehow. Git only allows you to stage the 
current working copy of each file - or so I thought.

>> It's not like you can edit the staging copy.
>
> It really is.

Really? And how exactly do you do that? Does Git even store the staged 
copy as a flat file, or is it a compressed image somewhere?

>>> You're doing it wrong.
>> Or rather, "Git isn't really supporting my workflow".
>
> What workflow are you trying to do? Submit only some of the changed
> hunks/lines in a commit without submitting the others? Trust me - I do
> this all the time. It's trivial.

As in "so trivial that I can't figure out how to do it"? :-P

> So, there's no change, other than just this one change? Right, got it. ;-)

With Git, moving a change from one branch to another is itself a change. 
With Darcs, it is not.

>> (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...)
>
> Given it's in Tk, I'm assuming you grab the bar and drag it down, like
> any other pane in Tk or Windows or X. :-)

Yeah, you'd *think* that would work... but alas, no.

Post a reply to this message

On 4/16/2012 1:24, Invisible wrote:

> The dangling branch shows up in gitk though.

Are you sure it's dangling? There's no head pointing to it at all?

> IF the change has already been shared with the world, then yes, that's not
> going to be easy to fix at all. But I haven't - that's the point. I'm used
> to it being trivial to fix mistakes that you haven't shared yet.

So, it's two command lines instead of one. Not exactly "trivial" but far 
from "difficult". And of course it'll go away on its own if you just leave 
it, so yeah, pretty trivial I'd say. Certainly "trivial" for anyone writing 
a sufficiently complex system that git is helpful.

>> Generally, one is expected to not commit broken code. That's like one of
>> the fundamental no-no's of repositories. I guess you don't have
>> coworkers tho. Just so you know.
>
> So if adding a new feature means performing a major refactor of the entire
> codebase, you're supposed to do that as one giant commit?

Nope. First, you refactor, bit by bit, with a commit for each refactor. Then 
you add the new feature. Give an example, and I'd tell you where I'd split 
it up.

>> Sure. But if logical change X can be broken into 4 separate steps, each
>> of which leaves you with a working system, why not commit in even
>> smaller steps?
>
> More to the point, if what you need to do involves making a major breaking
> change in step 1, and not fixing the last of the things it breaks until step
> 25, are you really going to put all 25 steps into a single giant commit?

Yes. If the system doesn't compile, you don't commit it. Otherwise, you've 
broken everyone who is supposed to be working on the code except yourself.

It's not really 25 steps if it doesn't compile in the middle, is it?

> Like I said, I generally work in terms of points in time that I'm likely to
> want to go back to, rather than points in time where the code compiles. (If
> I did the latter, the entire project history would be, like, 3 giant commits
> with nothing inbetween!)

Like *I* said, this doesn't fly when you're actually working on a team.

>> http://book.git-scm.com/4_interactive_adding.html
> Ah, so there *is* an interactive diff mode, it's just hidden?

If by "hidden" you mean "interactive commit" in google taking you to the 
official documentation telling you how to do it, yes.

>> Again, you're being borked by netbeans.
>
> Yeah, it's not the best. Then again, it appears to support Mercurial and
> Subversion as well, so maybe the problem is that it tries to handle them all
> the same way...

That's my suspicion.

>> Remember that git commits
>> whatever is in staging, without looking at your working copy.
>
> Sure. But if you want to record a particular version of that file, you still
> need to generate it somehow. Git only allows you to stage the current
> working copy of each file - or so I thought.

It lets you stage whatever you want. You can put files into the repository 
that don't exist anywhere outside the repository.

>>> It's not like you can edit the staging copy.
>>
>> It really is.
>
> Really? And how exactly do you do that? Does Git even store the staged copy
> as a flat file, or is it a compressed image somewhere?

It's a file in the repository. The "staging" directory is essentially a 
head. If you look at the lowest level commands, the way git works is it 
creates a blob for each file as you stage it, then creates the appropriate 
trees, then when you commit, all it's really doing is creating the commit 
blob. A commit doesn't actually add any files per se to the repository.

>>>> You're doing it wrong.
>>> Or rather, "Git isn't really supporting my workflow".
>>
>> What workflow are you trying to do? Submit only some of the changed
>> hunks/lines in a commit without submitting the others? Trust me - I do
>> this all the time. It's trivial.
>
> As in "so trivial that I can't figure out how to do it"? :-P

If you use the right interface, it's trivial. If you go through an interface 
that also works with svn (which doesn't let you commit files not in the 
working directory), then it'll be less trivial.

>> So, there's no change, other than just this one change? Right, got it. ;-)
>
> With Git, moving a change from one branch to another is itself a change.
> With Darcs, it is not.

Darcs only has one branch per repository anyway, yes?

>> Given it's in Tk, I'm assuming you grab the bar and drag it down, like
>> any other pane in Tk or Windows or X. :-)
>
> Yeah, you'd *think* that would work... but alas, no.

Huh. Maybe grab it on the little square? I don't remember.

-- 
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/16/2012 1:18, Invisible wrote:
>> Answer: don't do that. Copy commits, not individual files.
>
> How do you actually do that?

The commands are "pull" and "push" I believe. Look for something talking 
about say "origin/head" in the book. Or, even better, read that book. It'll 
take you about 20 minutes, and then you'll know how git works.

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