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