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

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