On 16/04/2012 06:07 PM, Darren New wrote:
> 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?

Pretty sure. You want a screenshot?

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

The whole point is, I've got a commit that's labelled as the wrong 
thing. That's confusing. Making even /more/ commits just makes things 
more confusing. Now I've got two commits containing the same stuff but 
with different names and labels. I was trying to make it /less/ 
confusing, not /more/...

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

OK. So suppose that I have a class, and to use it you're supposed to 
call the methods A(), B() and C(), in that order. And then I decide 
"hey, actually that doesn't work so great", and I change it to that you 
have to call A(), then X(), and then Z(), and the type signature for A() 
is now different.

I've now broken all 16 subclasses, which I'll now have to refactor to 
juggle the existing code into the new locations. In some cases, I'll 
have to actually change the fundamental way the logic works. (That's the 
entire point of the refactor, after all.) And I've also broken all 25 
clients of these classes, which will also need to be rearranged if not 
completely rewritten.

So... /how/ do I do this without making the project not compile while 
I'm fixing all these dozens of broken classes?

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

...which is why you don't push any changes until you've finished /all/ 
of them?

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

Well, obviously I'm never going to be in that situation, am I? (Let's 
face it, nobody's going to hire /me/ to write code...)

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

I did spend some time playing with this. I couldn't figure out for the 
life of me how to make it work. Git doesn't appear to behave the way the 
examples say it does. (E.g., selecting a menu item doesn't change the 
command prompt.)

Fortunately, the Git GUI seems to work. For reasons I don't comprehend, 
if you change any file, by default /all/ the changes in that file are 
considered to be "one hunk", so you have to select line-by-line which 
changes you want. Which is kind of tedious if you want to select the 25 
consecutive lines in the middle of the files without the 2 lines you 
changed right at the bottom. But hey, it works.

I guess the real solution is to never make more than one edit at once.

(Oh, and I was trying this under Linux today. Unfortunately, hitting the 
"edit" button trapped me inside Vi...)

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

I gather a few people use Mercurial too. Maybe I'll have a look at that 
sometime... Don't think I'll bother with Subversion though. Warp's sold 
it to me.

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

Even talking to Git directly from the command line, it's very far from 
trivial.

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

Yeah. So to move a change from one "branch" to another, really you're 
just copying a changeset from one repository to another.

I will admit, having multiple branches per repository is much more 
convenient.

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

I managed to figure it out. You can't grab the /edge/ of the divider; 
that doesn't work. But if you point at the gab between the text box in 
the left and the bottom below it, you can drag that. In other words, the 
edges aren't draggable, but some random pixel in the middle of the 
tangle of boxes and buttons /is/, and it drags the whole lot with it. 
Obviously. I mean, why did't I think of that before? :-P

Post a reply to this message