On 4/13/2012 1:36, Invisible wrote:
> That's what I'm saying - option #1 deletes the commit AND REVERTS THE
> WORKING COPY. I can't fathom why you'd want to revert your working copy.

Because you realized (say) that you've just made a change and a commit on 
the wrong repository? If it's not the behavior you want, don't use that 
option. :-)

> Except that every single time I look at the history tree, this dangling
> commit shows up,

That's kind of odd. I don't think commits with no pointers to them should be 
showing up. But if it bothers you, git gc it.  I suspect netbeans is what's 
at fault here, not git.

> I made a trivial mistake. It just surprises me that it's this long and
> complex to undo such a simple and common mistake.

You made a simple mistake committing code changes to a repository 
potentially shared with the entire world. :-)  That's not a small mistake in 
the grand scheme of things, and certainly worthy of requiring two entire 
command lines to entirely eliminate.

> Darcs also names changes after their hash. The Darcs amend command also
> changes the commit name. It's just that Darcs automatically deletes the old,
> incorrect commit, and keeps only the new, corrected one. Isn't that what
> "amending" something would be expected to mean?

So does git. Maybe it's netbeans screwing things up.

> Heck, I generally don't even worry about consistent states. Not, as in,
> whether the project is runnable.

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.

> I work in whole logical changes. Like, I
> group all the changes to do with X together, all the changes to do with Y
> together, and so on. It might be that you need to apply X, Y and Z to get
> back to a runnable state again. But it's more that if I'm in the middle of
> editing and I screw it up, I want to be able to back out just the thing I'm
> trying to edit, not the whole of X, Y and Z and start over.

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?  Why not commit the code to add records to the database, *then* 
commit the UI that invokes that code? Then if you utterly screw up the UI, 
you don't have to revert the database code.

> No. This still requires you to manually edit the files to the right point.

No. Really. It doesn't. Heck, you can even do it from the command line.

http://book.git-scm.com/4_interactive_adding.html

If you prefer the GUI, try this:

http://nathanj.github.com/gitguide/images/11.png

See the "unstage hunk" and "unstage lines"? There's also "stage hunk" and 
"unstage hunk".

(Parent URL: http://nathanj.github.com/gitguide/tour.html )

Again, you're being borked by netbeans. Remember that git commits whatever 
is in staging, without looking at your working copy. And it's not 
remembering where diffs came from and such. So if this really was a feature 
you needed, it would be trivial to add at the client end, and thus likely 
would have been added already. Deciding what changes get committed and what 
don't isn't part of git per se. It's just part of the front end. If you 
wanted to write a program to commit any different lines with the letter X in 
them, you could write that code pretty trivially.

> It's not like you can edit the staging copy.

It really is.

> Actually, NetBeans seems to have its own internal history tracking, so in a
> sense, it /can/. You can find the lines you changed, hit "revert change", do
> your commit, and then jab Undo a few times to redo the changes. It's klunky
> and hard, but it's better than just Git by itself.

No, it really isn't. It's harder than just git-via-netbeans by itself, 
apparently.

>> 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. When I've finished a feature, I go thru the 
git-gui to mark all the bugfixes, and commit them in separate commits, then 
mark each feature and commit them. I tend to get something working and then 
turn it into 5 or 6 commits.

>> You never made the change before where both pieces of code are in the
>> same file.
>
> I meant more that of you change one file on one branch, and an unrelated
> file on another branch, to get those changes together, you need to record a
> new commit. Even through there's no new changes, another than both files
> being in the same branch now.

So, there's no change, other than just this one change? Right, got it. ;-)

> (I'm still trying to figure out how to get gitk to resize so I can see the
> whole history tree. There doesn't seem to be a way to enlarge the tiny tree
> view at the top and shrink the enormous commit viewer at the bottom which I
> don't care about...)

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

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