You can use amend to break a commit into multiple ones the extra step is that you have to unstage changes first. What it can't do is combine multiple commits into one or reorder existing commits. An interactive rebase interface would be useful.
Don't bother with my fork it's a bit outdated. All of the forks that have a sidebar are based on it though. --Nathan http://brotherbard.com/ On Jan 23, 2013, at 8:40 AM, Prakash Nadar wrote: > Yes it is correct, dragging the head around is not particularly the best > thing to do, I have been using it for a while and I can't have gitx without > this feature, changing-amending the last commit is also one of the feature I > use. > > One of the easy thing I can do with this GitX feature is splitting a commit > into different commits. I bet amend can't do that or can't do it easily. > > i tried to get brotherbard GitX, I am not able to find a link to the binary. > > -prakash > > On Wednesday, January 23, 2013 at 1:11 AM, Nathan Kinsinger wrote: > >> The problem is you have to be careful where you move the branch. >> >> For historical reference here is the discussion I had with Pieter about it: >> https://groups.google.com/forum/#!topic/gitx/HwP-toGQAn0 >> >> And here is the commit where I blocked moving the head branch: >> https://github.com/brotherbard/gitx/commit/986f49f70a7890128c0c250a4d1cacbb04f700d1 >> >> If you are just changing the previous commit use the Amend checkbox under >> the commit message and you can then stage new changes or discard existing >> ones. >> >> >> --Nathan >> >> http://brotherbard.com/ >> >> >> >> >> >> On Jan 22, 2013, at 12:19 PM, Prakash Nadar wrote: >> >>> exactly! it should not change the working copy and thats what GitX does… >>> the diff changes are put in the staging area and you can upstage and >>> discard any change that you don't want to go or modify it. Think of it as >>> interactive rebase. >>> >>> -prakash >>> >>> On Tuesday, January 22, 2013 at 11:16 AM, Edward Rudd wrote: >>> >>>> I simply checkout a new branch (temp) then move the master. >>>> >>>> Otherwise just moving the branch point is kinda "icky" as you working copy >>>> wouldn't be updated. >>>> >>>> On Jan 22, 2013, at 14:11 , Prakash Nadar wrote: >>>> >>>>> Original Gitx Supports moving the branch on checkout branch as well… >>>>> Since I have to correct history/change then I would be doing it for the >>>>> current checkout branch only. So yeah, not moving to rowanj-Gitx as well. >>>>> :) >>>>> >>>>> -prakash >>>>> >>>>> On Tuesday, January 22, 2013 at 11:07 AM, Edward Rudd wrote: >>>>> >>>>>> I'm using RowanJ's fork and it supports the ability to drag and drop >>>>>> branches still. Though only when they are not checked out. This one >>>>>> seems to be the most active fork too.. ( http://rowanj.github.com/gitx/ >>>>>> ) And it seems the gitx.org website is not listing that fork. >>>>>> >>>>>> And AFAIK every other fork I tried still had that ability on non-checked >>>>>> out branches. A feature I really like as well, and with gitg >>>>>> supported.. ( gitg is a linux/gnome GUI program "inspired" by GitX ) >>>>>> >>>>>> >>>>>> On Jan 22, 2013, at 13:55 , Prakash wrote: >>>>>> >>>>>>> Let me throw in a couple of bit... I have been using GitX (the original >>>>>>> one) for a while and I like it the way it is, it is simple to use for >>>>>>> day-today activity in combination with command line git. If I have to >>>>>>> do something serious, repo management etc, I use sourcetree which is >>>>>>> free and native as well. >>>>>>> >>>>>>> One of the nice feature that GitX (original) has is ability to drag and >>>>>>> drop the branch-name to point to a new commit and make put the changes >>>>>>> of the newer commit into staging area (hope my description makes sense) >>>>>>> >>>>>>> This has allowed me many many time so correct my change easily without >>>>>>> using git rebase -i command. With many forks that I tried with the >>>>>>> sidebars ext seems to have removed or disabled this feature... >>>>>>> >>>>>>> So I strongly vote against Original GitX point to anything else unless >>>>>>> this problem is address. I don't want to accidentally update a newer >>>>>>> version of Gitx-redirect that removes this very important feature for >>>>>>> me. >>>>>>> >>>>>>> IMO, let gitx be gitx and the forks be forks (yes all the disadvantages >>>>>>> of contribution going to the wrong place is understandable but not at >>>>>>> he cost of feature I like) >>>>>>> >>>>>>> There is a gitx.org that points to some of the gitx forks and to the >>>>>>> original... maybe Gitx can link to this page and give the new >>>>>>> users/contributors/ an idea where to go and put some effort or create a >>>>>>> page a similar page at original gitx site. >>>>>>> >>>>>>> -prakash >>>>>>> >>>>>>> On Tuesday, January 22, 2013 1:51:25 AM UTC-8, Pieter de Bie wrote: >>>>>>>> >>>>>>>> Hey guys, >>>>>>>> >>>>>>>> On Mon, Jan 14, 2013 at 9:04 PM, Johannes Gilger <[email protected]> >>>>>>>> wrote: >>>>>>>> > On 14/01/13 10:41, Josh Bleecher Snyder wrote: >>>>>>>> >> Or Pieter could ask the community for volunteers to officially take >>>>>>>> >> over >>>>>>>> >> GitX, pick one, and make a public announcement, backed up by a >>>>>>>> >> statement at >>>>>>>> >> the top of his repo's README. >>>>>>>> > >>>>>>>> > Yeah, that would be a quick reference. >>>>>>>> >>>>>>>> I'm willing to update my github repo with a reference to another >>>>>>>> repository, or even push a final update using the built-in updater of >>>>>>>> GitX to download another fork. At this point, I'm not really >>>>>>>> interested in resurrecting GitX myself (though I still use it daliy), >>>>>>>> but might contribute once in a while if an active fork is created. >>>>>>>> >>>>>>>> >> > As to being "blessed", this is mostly a question of >>>>>>>> >> > version-number and >>>>>>>> >> > Google PageRank, isn't it? >>>>>>>> >> >>>>>>>> >> Bluntly: No, I don't think it is. >>>>>>>> >> >>>>>>>> >> Open source projects thrive under conditions that make for good >>>>>>>> >> coordination. That's easiest when there's an official preferred >>>>>>>> >> version, >>>>>>>> >> with someone who is actively maintaining it -- even if >>>>>>>> >> that maintenance consists of nothing more than having an opinion >>>>>>>> >> about >>>>>>>> >> direction and handling pull requests. >>>>>>>> >> >>>>>>>> >> Letting a thousand forks bloom, for a long time, each wandering >>>>>>>> >> their own >>>>>>>> >> way, is not good for anyone, users or contributors. >>>>>>>> >>>>>>>> I agree with this, the current situation is kinda confusing and nobody >>>>>>>> is profiting from it. >>>>>>>> >>>>>>>> > Yeah, I'm always open. Disagreements are what mailing lists are good >>>>>>>> > for. Let's wait if Pieter voices an oppinion. >>>>>>>> >>>>>>>> I've looked before into 'blessing' an alternate repository by >>>>>>>> redirecting to it; however, in the past I haven't found a fork that >>>>>>>> has been active enough for a long enough time to do this. I wanted to >>>>>>>> make sure that when I hand over control, it will continue living for a >>>>>>>> while instead of dying after a few weeks / months without me being >>>>>>>> able to do anything about it. >>>>>>>> >>>>>>>> That might not be logical -- I guess any progress is better than the >>>>>>>> complete absence of me for the past few years. The repo from rowanj >>>>>>>> looks like it's active, so it might be best to just redirect to there. >>>>>>>> >>>>>>>> - Pieter >>>>>> >>>>>> Edward Rudd >>>>>> OutOfOrder.cc >>>>>> Skype: outoforder_cc >>>>>> 317-674-3296 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> Edward Rudd >>>> OutOfOrder.cc >>>> Skype: outoforder_cc >>>> 317-674-3296 >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >
