On 4/16/2012 11:26, Orchid Win7 v1 wrote:
> 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.

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

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

OK.

> 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... /how/ do I do this without making the project not compile while I'm
> fixing all these dozens of broken classes?

Make B() and C() do the right thing w.r.t. X() and Z(), and make the version 
of A() with the old arguments invoke the correct version of A() with the new 
arguments.

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.

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

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.

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.

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

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

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

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

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

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?

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

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

I had zero problems figuring out gitk's interface.

> 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

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.

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