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

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

On 4/17/2012 2:03, Invisible wrote:> 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...)

OK. I don't know. I never really worried about it.

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

Only if having a dangling commit bothers you.

>> That's a bad way to do it.
> So... what do you suggest?

Don't break the old code before the new code works.

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

Welcome to working with lots of other people on the same project. Why do you 
think people complain about the problems of legacy code?

In practice, it's usually not that hard, because the likelihood that you 
need to break 25 separate classes is low if you've designed your code decently.

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

They are. But if you're going to break lots of code at once, yes, you don't 
have a lot of choice. I.e., if you only want to push big commits, you can do 
that, even if you do it with a bunch of small commits.

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

That's part of it, but you still have to merge it back in, which is going to 
be a mess of 25 people have been working on the 25 classes you've been changing.

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

It should, sure.

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

Did you already stage the entire file? You have to unstage the file as a 
whole, then stage it one hunk at a time. Or unstage the hunks on the bottom 
half?

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

Use ":q!" to exit vi. Then set your EDITOR variable for next time.

Really? You couldn't figure out google enough to figure out how to get out 
of VI?

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

Tk is still, in many ways, stuck in the 80's of X-Windows development.

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

>>> 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.
>
> Only if having a dangling commit bothers you.

Having stuff that's incorrectly labelled bothers me, yes. That's why I 
amended it in the first place. :-P

> Don't break the old code before the new code works.

>> Damn. Way to make a complex change that much more complex. o_O
>
> Welcome to working with lots of other people on the same project. Why do
> you think people complain about the problems of legacy code?
>
> In practice, it's usually not that hard, because the likelihood that you
> need to break 25 separate classes is low if you've designed your code
> decently.

Apparently having 25 token classes is "not designing your code decently" 
then...

>> Isn't that why you create a new branch for breaking changes?
>
> That's part of it, but you still have to merge it back in, which is
> going to be a mess of 25 people have been working on the 25 classes
> you've been changing.

Isn't that why you /talk to/ the other developers?

I'm pretty sure that without communication, any development effort is 
doomed to end in failure. Multiple people developing the same code, 
fixing the same bugs different ways, and generally getting in each 
other's way.

>> Sure. This still doesn't help me find a way out of Vi without
>> rebooting the VM.
>
> Use ":q!" to exit vi. Then set your EDITOR variable for next time.
>
> Really? You couldn't figure out google enough to figure out how to get
> out of VI?

Gotta work out that it's Vi first. :-P It's not like it says "Vi" on it.

> Tk is still, in many ways, stuck in the 80's of X-Windows development.

Yeah, I never did like Tk. :-P

Post a reply to this message

On 4/20/2012 1:14, Invisible wrote:
>> In practice, it's usually not that hard, because the likelihood that you
>> need to break 25 separate classes is low if you've designed your code
>> decently.
>
> Apparently having 25 token classes is "not designing your code decently"
> then...

Note that if what you're changing is mindless, then sure, make lots of 
changes. If you're (for example) renaming a routine inherited by 25 classes 
or something, sure.

If you have to spend an hour on each one thinking how to fix it, chances are 
you're either making too big a change, or your design was wrong to start 
with. (Of course, fixing that design implies breaking 25 classes, so...)

>> That's part of it, but you still have to merge it back in, which is
>> going to be a mess of 25 people have been working on the 25 classes
>> you've been changing.
>
> Isn't that why you /talk to/ the other developers?

Sure. If you can get people to stop development on those things for however 
long it takes you to fix them, that works. Sometimes that's not feasible. 
Especially if it's live production code.

> I'm pretty sure that without communication, any development effort is doomed
> to end in failure. Multiple people developing the same code, fixing the same
> bugs different ways, and generally getting in each other's way.

Sure. But if those 25 classes are in (say) 25 different projects run by 25 
different groups, you're going to get in their way. If you're changing the 
parser library, and you affect everyone in your 15,000-developer company 
that uses that parser library, you're going to have a world of trouble 
getting everyone to stop.

>> Tk is still, in many ways, stuck in the 80's of X-Windows development.
> Yeah, I never did like Tk. :-P

It has always been ugly, yes. :-)

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

>>> In practice, it's usually not that hard, because the likelihood that you
>>> need to break 25 separate classes is low if you've designed your code
>>> decently.
>>
>> Apparently having 25 token classes is "not designing your code decently"
>> then...
>
> Note that if what you're changing is mindless, then sure, make lots of
> changes. If you're (for example) renaming a routine inherited by 25
> classes or something, sure.
>
> If you have to spend an hour on each one thinking how to fix it, chances
> are you're either making too big a change, or your design was wrong to
> start with. (Of course, fixing that design implies breaking 25 classes,
> so...)

Actually, it took me about 20 minutes to fix all the changes. It's just 
that for those 20 minutes, the code is broken. And if anybody got some 
of the commits but not the rest, that'd have broken code.

>> Isn't that why you /talk to/ the other developers?
>
> Sure. If you can get people to stop development on those things for
> however long it takes you to fix them, that works. Sometimes that's not
> feasible. Especially if it's live production code.

Which leads me back to "isn't that what branches are for?"

>> I'm pretty sure that without communication, any development effort is
>> doomed
>> to end in failure. Multiple people developing the same code, fixing
>> the same
>> bugs different ways, and generally getting in each other's way.
>
> Sure. But if those 25 classes are in (say) 25 different projects run by
> 25 different groups, you're going to get in their way. If you're
> changing the parser library, and you affect everyone in your
> 15,000-developer company that uses that parser library, you're going to
> have a world of trouble getting everyone to stop.

So create a new branch. Play around with the new design in your 
experimental branch. /When it's finished/, merge it back into the main 
trunk.

Isn't that how this game is supposed to work?

Post a reply to this message

On 4/21/2012 11:22, Orchid Win7 v1 wrote:
> Actually, it took me about 20 minutes to fix all the changes. It's just that
> for those 20 minutes, the code is broken. And if anybody got some of the
> commits but not the rest, that'd have broken code.

Then that's not a really big change. It should be all one commit.

>>> Isn't that why you /talk to/ the other developers?
>>
>> Sure. If you can get people to stop development on those things for
>> however long it takes you to fix them, that works. Sometimes that's not
>> feasible. Especially if it's live production code.
>
> Which leads me back to "isn't that what branches are for?"

Only if you like doing the merges. If you're talking about 20 minutes, sure, 
you don't even need a branch. If you're talking about a few weeks, you're 
going to have a mess of a merge.

> So create a new branch. Play around with the new design in your experimental
> branch. /When it's finished/, merge it back into the main trunk.
>
> Isn't that how this game is supposed to work?

Indeed, as long as the merge isn't too messy. Imagine if two people do the 
same sort of thing at once.

-- 
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 23/04/2012 04:22 AM, Darren New wrote:
> On 4/21/2012 11:22, Orchid Win7 v1 wrote:
>> Actually, it took me about 20 minutes to fix all the changes. It's
>> just that
>> for those 20 minutes, the code is broken. And if anybody got some of the
>> commits but not the rest, that'd have broken code.
>
> Then that's not a really big change. It should be all one commit.

The entire codebase is under 25KB. Arguably the project is too tiny for 
version control to actually matter. :-P

>> Which leads me back to "isn't that what branches are for?"
>
> Only if you like doing the merges. If you're talking about 20 minutes,
> sure, you don't even need a branch. If you're talking about a few weeks,
> you're going to have a mess of a merge.

OK, fair enough.

>> Isn't that how this game is supposed to work?
>
> Indeed, as long as the merge isn't too messy. Imagine if two people do
> the same sort of thing at once.

Which is why you need communication. If nothing else, having two people 
try to implement the same thing is a waste of effort.

Post a reply to this message

On 11 Apr 2012 05:57:16 -0400, Warp wrote:
> Copy an unversioned directory from somewhere else onto a
> versioned directory in your project? Svn breaks.

Actually that does not break Svn. Those are just files
that Svn does not track. But the other points you mentioned
are quite valid.

-- 
Joel Yliluoma - http://iki.fi/bisqwit/

Post a reply to this message

Joel Yliluoma <bis### [at] ikifi> wrote:
> On 11 Apr 2012 05:57:16 -0400, Warp wrote:
> > Copy an unversioned directory from somewhere else onto a
> > versioned directory in your project? Svn breaks.

> Actually that does not break Svn. Those are just files
> that Svn does not track. But the other points you mentioned
> are quite valid.

  I didn't express the situation clearly enough there.

  What I meant is that you have a directory in your project that *is*
versioned, and another with the same name somewhere else that isn't. If
you now copy that other, unversioned directory into your project (ie.
replacing the contents of the versioned directory), svn breaks.

  It breaks because it expects that directory you just replaced the contents
of to have .svn subdirectories inside (at each subdirectory level), but
they have disappeared. It will refuse to let you add this new subdirectory
structure to the project (because it's "already there" according to the
remote repository information), and it will likewise refuse to update to
the version that's at the remote repository (because it would overwrite
these "unversioned" files).

  The only way to fix the situation is to remove the offending directory
structure completely, then update (now it complies because no local
unversioned files are being overwritten) and then you have to copy the
individual files from that other directory here, one subdirectory at a
time.

  One could hastily think that why one would even do that. However, it can
be more common than one might think.

  For example, you may have some third-party library in your project, which
your project uses. This third-party library is in a directory structure.
Then you download a newer version of the library, unpack it, and then copy
or move this newer version into your project... And it breaks (because these
new directories do not have the proper .svn subdirectories inside them).

  (Of course this can be avoided eg. by copying the new version into a
directory with a different name, eg. a name with the library's version
in it, and then have a soft link that always points to the newest version
of said library. In my particular case this is not a very working solution
because Xcode doesn't support soft links very well, and it tends to break
if I try this. Nevertheless, a versioning system shouldn't break when doing
this kind of thing which isn't even all that uncommon.)

-- 
                                                          - Warp

Post a reply to this message