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?

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

>> Generally, one is expected to not commit broken code. That's like one of
>> the fundamental no-no's of repositories. I guess you don't have
>> coworkers tho. Just so you know.
>
> 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.

>> Sure. But if logical change X can be broken into 4 separate steps, each
>> of which leaves you with a working system, why not commit in even
>> smaller steps?
>
> More to the point, if what you need to do involves making a major breaking
> change in step 1, and not fixing the last of the things it breaks until step
> 25, 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.

It's not really 25 steps if it doesn't compile in the middle, is it?

> Like I said, I generally work in terms of points in time that I'm likely to
> want to go back to, rather than points in time where the code compiles. (If
> I did the latter, the entire project history would be, like, 3 giant commits
> with nothing inbetween!)

Like *I* said, this doesn't fly when you're actually working on a team.

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

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

>> Remember that git commits
>> whatever is in staging, without looking at your working copy.
>
> Sure. But if you want to record a particular version of that file, you still
> need to generate it somehow. Git only allows you to stage the current
> working copy of each file - or so I thought.

It lets you stage whatever you want. You can put files into the repository 
that don't exist anywhere outside the repository.

>>> It's not like you can edit the staging copy.
>>
>> It really is.
>
> Really? And how exactly do you do that? Does Git even store the staged copy
> as a flat file, or is it a compressed image somewhere?

It's a file in the repository. The "staging" directory is essentially a 
head. If you look at the lowest level commands, the way git works is it 
creates a blob for each file as you stage it, then creates the appropriate 
trees, then when you commit, all it's really doing is creating the commit 
blob. A commit doesn't actually add any files per se to the repository.

>>>> You're doing it wrong.
>>> 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.

>> So, there's no change, other than just this one change? Right, got it. ;-)
>
> 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?

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

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