>> Pretty sure. You want a screenshot?
>
> Not really. That wouldn't actually tell you anyway. :-) I don't remember
> if git's gui tools tell you about dangling commits or not or what.

gitk shows you a little tree, with a node for each commit object, and a 
square for each head. (And the current head is in bold.) There is no 
square pointing to the old commit, so presumably it's dangling. 
(Suddenly I feel like Neo...)

>> The whole point is, I've got a commit that's labelled as the wrong thing.
>
> So garbage collect it! The solution is trivial. Read the "git gc" page.

That's a pretty obscure thing to need to look up just to fix an obvious 
problem.

>> 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.
>
> That's a bad way to do it.

So... what do you suggest?

> So, basically, write the new code but don't use it. Commit. Make the old
> interface invoke the new code. Commit. Make the old code invoke the new
> interface. Commit commit commit. Throw away the old code. Commit.

Damn. Way to make a complex change that much more complex. o_O

>> ...which is why you don't push any changes until you've finished /all/
>> of them?
>
> If you're modifying code in a way that breaks lots of other code, then
> yes. If you're doing something that doesn't break other code, then yes.
> If you're committing broken code locally just so it doesn't get lost or
> something, then rebase your commit before you push it, or whatever it's
> called when you roll up a bunch of commits into one big one.

And here I thought big commits were a bad idea. :-P

> The point is that if you make changes to the code of 40 other people,
> and it takes you three or four weeks to finish it, then likely other
> people have used the old interface while you've been refactoring it, and
> you're screwed when you push it anwyay.

Isn't that why you create a new branch for breaking changes? Especially 
in an SCM that makes branching particularly easy...

>>> 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...)
>
> Not with that attitude, no. :)

I doubt any amount of attitude is going to change the fact that I'm 
useless at all the popular programming languages. :-P

>> 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.
>
> One hunk is one contiguous set of changed lines. Are you sure you didn't
> do something like add spaces to the end of each line or something? A
> "hunk" is a list of lines, and it's what diff outputs with line numbers
> at the top.

If I had, wouldn't the changed lines show up as part of the hunk?

I changed a header file. Added two lines at the top, and one at the 
bottom (25 lines away). It showed up as two separate changes, but 
clicking on the top and selecting "stage hunk" staged the entire file. I 
had to go through and stage it line by line to get it to work right.

> Read up the options on diff to see how to make your hunks smaller.

That's not going to work from the GUI. (And I can't make it work at all 
from the CLI. Like I said, Git's behaviour doesn't match the instructions.)

> I've never had a problem. It's like you're complaining you keep crashing
> into walls, and the only possible solution is to always drive in reverse
> or something. What *are* you doing wrong?

*shrugs*

>> (Oh, and I was trying this under Linux today. Unfortunately, hitting the
>> "edit" button trapped me inside Vi...)
>
> export EDITOR=nano
> or whatever editor you most approve. This has been a UNIX thing since
> long before emacs was invented.

Sure. This still doesn't help me find a way out of Vi without rebooting 
the VM.

>> I managed to figure it out. You can't grab the /edge/ of the divider;
>> that doesn't work.  In other words, the edges aren't
>> draggable, but some random pixel in the middle of the tangle of boxes and
>> buttons /is/. Obviously. I mean, why did't I think of that before? :-P
>
> Sounds poorly configured, yes. I'm pretty sure that's explicitly why
> there's a little box on the line. But yah, you have to wave the mouse
> around until the cursor changes into the "move a line" cursor. Kind of
> annoying sometimes.

Very random and annoying, yes... But hey, I fixed it now. I guess.

Post a reply to this message