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