I still use the brother bard fork as it does everything that I want and efficiently. Anything complicated I prefer to drop to the command line anyway. In fact I host a binary with the fix by Ole Zorn for lion and later on my site:
http://www-users.york.ac.uk/~rfle500/resources/GitX-Lion.zip Richard. On 23 Jan 2013, at 15:40, Prakash Nadar <[email protected]> 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 >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >
