Re: [Openocd-development] git gui/cola doesn't push to review
FYI i have append i picture from what i can select in the gui. If i select review as remote the error message looks like this: # Pushing to ssh://hidden@openocd.zylin.com:29418/openocd.git # remote: Resolving deltas: 0% (0/2) # To ssh://hidden@openocd.zylin.com:29418/openocd.git # ! [remote rejected] master - master (prohibited by Gerrit) # error: failed to push some refs to 'ssh://hidden@openocd.zylin.com:29418/openocd.git' The git gui try to push it into the master branch directly. The right way to do it is to push it over the menu Remote-Push to-review. Regards, Mathias On 30.11.2011 01:46, Peter Stuge wrote: Mathias K. wrote: If i try to push i can choose the review as target but it will always pushed into the master and i got a error message. The console command git push review works. Any hints? Can you choose which local branch to push, and which branch on the remote that it should be pushed into? The key is to push into: refs/for/master One canonical command line for this would e.g. be: git push review HEAD:refs/for/master //Peter attachment: git_gui_push_review.png___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git gui/cola doesn't push to review
Mathias K. wrote: If i try to push i can choose the review as target but it will always pushed into the master and i got a error message. The console command git push review works. Any hints? Can you choose which local branch to push, and which branch on the remote that it should be pushed into? The key is to push into: refs/for/master One canonical command line for this would e.g. be: git push review HEAD:refs/for/master //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git gui
On 26/10/2011 01:52, jim norris wrote: For those using a git gui, what are you using? 'gitg' on Linux. Having a GUI for hunk selection and commit is by far fastest then jumping trough various shells when writing a meaningful changelog message for the changes you are committing. Otherwise, I'm fine with the command line. -- Luca Ottaviano - lottavi...@develer.com Develer S.r.l. - http://www.develer.com/ .hardware .software .innovation Tel.: +39 055 3986627 - ext.: 218 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git gui
Apologies to anyone for annoying this list again with what are mostly discussions about the libusb dysfunctionality. If you aren't interested in finding why projects become dysfunctional, and why people will take palliative action then, please ignore. On 2011.10.27 00:53, Peter Stuge wrote: It's not a good idea to use git as one sees fit if that ends up being unfit for others, Last time I checked, libusb-1.0 asked for patches to be submitted to the mailing list, thus I really fail to get why you should pay any attention to what goes on in -pbatard. Moreover I did create a specific integration branch some time ago off -pbatard, so that you could pick stuff directly from git if you wanted (more about this below). I have yet to hear anyone else but you complain about -pbatard, or find they couldn't work with it. If anyone really has anything to say about how atrocious it really is, please feel free to browse [1] and comment. If you want to pretend that my branch is unfit for others, then pray provide concrete examples of others complaining that it is unfit. and it's of course not a good idea to use anything in an inefficient way. As I explained, the way I use git is, after careful comparison, the way *I* found most efficient. If you believe there can only be one master way to be efficient for software development, I am starting to understand why libusb turned out so dysfunctional. I think it's difficult to find a setting where git doesn't offer some significant advantages over other common choices. You're misreading the point (as you've done over and over again when we debated this in libusb-devel). So, once again, this is not a statement about git vs X. This is a statement about git alone. Git does have limitations and areas where I personally find it is far from being intuitive. When I say that, I'm not comparing it with SVN or whatever. For the record, I like git a lot better than subversion, which I also use on regular basis. But I do find that a many aspects of git are unintuitive and could be improved on, even without looking at competitors. For instance, I explained how grid coordinates to designate commits to human users (while keeping hashes internally) would have been a better choice than simply reusing hashes, as it would offer an immediate way to also provide their chronological order when referenced. You can also read (and comment) on Indiana Git and the Intuitiveness of Doom [2], which is about setting a git remote repository or other annoyances like fast forward denying [3] (which, apparently means that some people believe that deleting public commits is a bad idea) to get an idea of my annoyances with git if you want more. Also don't try impose your views on others with regards to git usage, unless you really have something to say about the quality of the patches they submit to mainline. To clarify for those not following libusb, and to take a concrete example: Pete's public libusb repo isn't rebased on the main libusb repo merge queue, but is rather a fork of the main repo from when Pete started working on libusb. More or less (see below). That's because I couldn't possibly fathom that I'd have to keep maintaining that development branch for 2 years. I foolishly believed that libusb would start integrate my work quickly and wouldn't be as totally adverse to Release Early Release Often as it is (or, more exactly, as Peter is). Once they early patches were integrated, I could just produce the subsequent ones off mainline by rebasing, ensuring that I wouldn't have to waste too much time maintaining my own branch, and concentrate on development. My plan was always to wait for my patches to be integrated, drop -pbatard, as it WAS a personal development branch, and subsequently work off mainline. Yet, 2 years on and I'm still waiting for a single libusb release that integrates ANY of the Windows backend patches. If you want to kick somebody for Windows git development and integration not happening the way you'd like them to happen, you should really have a long hard look at yourself for doing everything you can to delay integration and release, and actually prevent people from using git the way it should be used. When a branch has to exist on its own, without any ties to mainline, because mainline keeps ignoring it for years, it does becomes a headache to use git as one should, because what you really end up with are 2 very independent branches. The only other alternative to not wasting my time would have been to stop all development until libusb caught up (which is pretty much what I am doing right now). Also, what you seem to miss, is that I do follow up with mainline by merging the changes that occur there, except I'm not using rebase, but I merge them in one big commit, since they don't matter for Windows development. So it's not a fork from when. It's just a fork. So, what really happens in -pbatard is that
Re: [Openocd-development] git gui
On 10/27/2011 06:43 AM, Luca Ottaviano wrote: Having a GUI for hunk selection and commit is by far fastest then jumping trough various shells when writing a meaningful changelog message for the changes you are committing. +1. I use magit from within emacs for this (among other things). The *magit-status* buffer has a nice diff display. With point in a hunk, 's' stages the hunk; if there's a region, 's' stages the region (useful for e.g. staging a single changed line). I'm aware of git add -p; I find this faster. http://www.emacswiki.org/emacs/Magit ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git gui
On 2011.10.26 06:07, Øyvind Harboe wrote: On Wed, Oct 26, 2011 at 2:12 AM, Peter Stugepe...@stuge.se wrote: jim norris wrote: For those using a git gui, what are you using? On which system? For Windows, there is Git Extensions and TortoiseGit. The Git Extensions looked less slick than TortoiseGit last time I looked, but TortoisGit on the other hand lacked fundamental functionality. I recommend Gerrit. Gerrit makes a lot of the nastier concepts, like interactive rebasing and communication easier. From my experience TortoiseGit is a step down the wrong path. It makes things easier than possible, i.e. it tosses hard concepts out of the window. Where is the interactive rebase functionality? You mean, this [1]? For the record, I have been using TortoiseGit pretty much on a daily basis, for almost two years now and from my personal experience, not only have I found it filling pretty much all of my git needs (besides, it's based on msys-git, so commandline git is only one click away), but also, unlike Peter, I found that if there's one tool that benefits greatly from having a solid GUI, it has to be git. Who'd want to go back to using commandline for diffs, log, or branch switching, when you have a GUI with *easy* navigation at your fingertips [2]?. Also, judging from the general praise for gerrit, which also provides a solid GUI frontend albeit web based (hence more complex for regular git users to setup on their own -- I wouldn't advocate it as a solution for a user who simply wants a GUI on their machine), I can only assume that many have come to share the view that some GUI ontop of git actually does wonders. Thus, do you guys, who seem to be opposed to the use of TortoiseGit, have better evidence to back up your claims? If not, I would advise Jim to take Øyvind and Peter's advice with a grain of salt, or at least also consider the advice of someone who, through nearly two years of continuous usage, has reason to believe that using TortoiseGit has actually increased their git productivity. Of course, just like Peter and Øyvind's, this is merely an opinion. Regards, /Pete [1] http://img689.imageshack.us/img689/697/tgitinteractiverebase.png [2] http://img190.imageshack.us/img190/3281/tgitdiff.png ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git gui
Hi Pete, thanks for the corrections about my prejudice against Tortoise. I guess my main problem has been that that I've found that those that use Tortoise have no patience for the complexities and necessity of interactive rebase, rather than Tortoise lack of support for this feature. Gerrit is a piece to the GUI puzzle that is completely independent of what Tortoise covers. Both are needed. I know some Windows users who might be willing and interested in trying out Tortoise. Much of the support I provide for git happens via email. Documenting procedures and explaining what to do is much easier with command line, than to try to explain how to use a web interface. I don't use Windows myself, so from that point of view TortoiseGit is a non-starter. I see that there is a tortoisehg for Linux. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git gui
Øyvind Harboe wrote: my main problem has been that that I've found that those that use Tortoise have no patience for the complexities and necessity of interactive rebase, rather than Tortoise lack of support for this feature. This might fit Pete. In another project I've learned that he prefers not to use many of the features offered by git, among others indeed interactive rebase and the quick and easy way to deal with branches - and in that case TortoiseGit can of course work fine. I've evaluated Tortoise together with multiple developers who use Windows and it never ended up as the prefered tool, simply because it didn't have wanted features. If it has all features *you* want then of course it's as good a pick as any other, but at the time we looked at it, it wasn't really useful for taking advantage of git, and everyone picked Git Extensions or git bash instead. Some of the guys especially like that Git Extensions integrates at all with Visual Studio. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git gui
I have a problems with a GUI that makes git easy to use at the cost of not enabling and teaching the user to use the more advanced concepts. Interactive rebasing is an absolute must when working with git. Anything that leaves the user with the impression that he doesn't have to get his head around interactive rebase is oversimplifying git(and DVCS in general). -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git gui
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Pete Batard Sent: Wednesday, October 26, 2011 6:26 AM To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] git gui On 2011.10.26 06:07, Øyvind Harboe wrote: On Wed, Oct 26, 2011 at 2:12 AM, Peter Stugepe...@stuge.se wrote: jim norris wrote: For those using a git gui, what are you using? On which system? For Windows, there is Git Extensions and TortoiseGit. The Git Extensions looked less slick than TortoiseGit last time I looked, but TortoisGit on the other hand lacked fundamental functionality. I recommend Gerrit. Gerrit makes a lot of the nastier concepts, like interactive rebasing and communication easier. From my experience TortoiseGit is a step down the wrong path. It makes things easier than possible, i.e. it tosses hard concepts out of the window. Where is the interactive rebase functionality? You mean, this [1]? For the record, I have been using TortoiseGit pretty much on a daily basis, for almost two years now and from my personal experience, not only have I found it filling pretty much all of my git needs (besides, it's based on msys-git, so commandline git is only one click away), but also, unlike Peter, I found that if there's one tool that benefits greatly from having a solid GUI, it has to be git. Who'd want to go back to using commandline for diffs, log, or branch switching, when you have a GUI with *easy* navigation at your fingertips [2]?. Also, judging from the general praise for gerrit, which also provides a solid GUI frontend albeit web based (hence more complex for regular git users to setup on their own -- I wouldn't advocate it as a solution for a user who simply wants a GUI on their machine), I can only assume that many have come to share the view that some GUI ontop of git actually does wonders. Thus, do you guys, who seem to be opposed to the use of TortoiseGit, have better evidence to back up your claims? If not, I would advise Jim to take Øyvind and Peter's advice with a grain of salt, or at least also consider the advice of someone who, through nearly two years of continuous usage, has reason to believe that using TortoiseGit has actually increased their git productivity. Of course, just like Peter and Øyvind's, this is merely an opinion. Regards, /Pete [1] http://img689.imageshack.us/img689/697/tgitinteractiverebase.png [2] http://img190.imageshack.us/img190/3281/tgitdiff.png ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development I guess TortoiseGit has come a long way since I last looked. I have seen it corrupt a repository[1], but that could be a known bug that's long- fixed. I've always used Git on the command line, and when trying to use Mercurial, I find it's command-line interface quite irritating in how much it doesn't do. I generally use the Git command-line interface alongside gitk, using gitk like a GPS navigator of the repo history; It shows me where I've been, where I am now, and gives me easy quick reference to where I want to be, making command line tools far more palatable. I do use the git gui blame tool. I also mentioned git gui before; It seems to lack functionality upon first look, but has excellent display and browsing ability. - Alex ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git gui
On 2011.10.26 16:29, Peter Stuge wrote: Øyvind Harboe wrote: my main problem has been that that I've found that those that use Tortoise have no patience for the complexities and necessity of interactive rebase, rather than Tortoise lack of support for this feature. This might fit Pete. In another project I've learned that he prefers not to use many of the features offered by git, among others indeed interactive rebase Well, what do you know. Apparently, and I must say much to my surprise as I have recently learned [1], it appears that I simply decided to hate git, which of course should make it impossible to discuss such matters. I can't help but wonder though how my usage of git, in my own branch, matters so much to Peter, when I don't remember that any of the patches I submitted to libusb-devel over the past 2 years to have been faulted on a git technicality, or from me apparently not using git the established way. This is even more true as I have a very verifiable track record of being able to produce patches very quickly, when requested, even for a major headaches like an implementation that has evolved on its own, at a very rapid pace, for about a year and that must now be integrated. If anything, it should mean that whatever method I use to produce them wasn't that detrimental after all... If you really want to disprove my approach, Peter, then please find some verifiable evidence that any part of what I have been doing so far for libusb has been detrimental to mainline (rather than try to impose your own *personal* views of what a good private branch should look like). Also, since I am always eager to experiment, and as, if anything, it might turn out to be the only useful thing generated from this idiotic accusation, please do provide a list of the many features offered by git which myself and others should know about. For the record, I did follow your last point about git grep and git blame on the tcl/slash issue. Right after you posted I actually tried to determine whether using git blame in this case might not have been an overkill. Turns out there were only 3 small commits in one year on that tcl file, which gitweb promptly returned. If anything then, I guess I'm still waiting for a better example of git blame and other commands which I don't use (regularly|at all) saving the day, just like I am waiting for a good example of how, on small projects such as libusb and OpenOCD, choosing to never revert anything, and splitting commits ad nauseam actually contributes to collectively reduce everybody's time in the long run, maintainers AND contributors included. As with any tool, after careful consideration (especially with regards to the fact that libusb is a small project, that sees very few commits, that are far in between) and experimentation, I have drawn my own conclusion, as I am entitled to, as to what was I consider the most effective way. As long as the patches I submitted met the expected quality level, and I believe they do, I fail to see why I should have to defend myself with regards to how I use git. But anyway, if you want the short version, after many months of submitting patches, I found out that I was a lot more effective almost never using rebase --of course this only pertains to libusb: can't really comment on what I'd do for OpenOCD-- or, lately not even merge, but simply slapping patch serials or files from one branch into another and hack away (which, having a GUI actually makes very enticing, and which maybe you guys should also consider as the possible reason why the new generation may not use git the exact same way as grandpa does). This is how the latest Windows integration patches were produced and I'm still waiting to hear from you about how poor quality they truly were... Should I infer then, that, when I voluntarily decided to contribute to libusb, not only did I unknowingly sign a contract that strips me from the right to use to use a tool exactly the way I see fit, and that I was instead supposed to adhere to the one true way to use git? I think I must have missed Git Indoctrination 101. What I did not miss however were some of the deplorable action of mindless git worshippers, such as Peter, that pretty much sent us back 6 months on libusb-devel, with regards to the obnoxious CRLF issue, with the oh-so-maintainer-commendable actions of: 1. Taking about 3 months to start looking into a patch that was clearly identified as possibly contentious with regards to git (but then again, having to wait months before any serious review started was the fate of most Windows patches). 2. Getting bitten from the git documentation when trying to prove a critical point (about how others must have simply misread the documentation) and ending up interpreting the documentation wrong. 3. When seeing their arguments disproved, resorting to a very unprofessional I just don't want CRLF in the git repo, to
Re: [Openocd-development] git gui
Pete Batard wrote: Git is just a tool, feel free to use it as you see fit, GUI or not. Yes and no. Git is a tool, and of course there are good and bad GUIs, but the point is that since it's common to work together with others, and since this is also the setting where git really shines, it's a good idea to make sure that one's use of git is a) useful for others and b) the most efficient for self. It's not a good idea to use git as one sees fit if that ends up being unfit for others, and it's of course not a good idea to use anything in an inefficient way. But please remember that, like all tools, it has its advantages and limitations. The only real limitation that I've come across after a few years is that git really sucks at dealing with a large number of refs (branches+tags). I think it's difficult to find a setting where git doesn't offer some significant advantages over other common choices. The flip side is that because of those advantages git can also be very different from said other choices, and that can in itself be enough of a problem to cancel out all advantages. It depends on the people involved. Also don't try impose your views on others with regards to git usage, unless you really have something to say about the quality of the patches they submit to mainline. To clarify for those not following libusb, and to take a concrete example: Pete's public libusb repo isn't rebased on the main libusb repo merge queue, but is rather a fork of the main repo from when Pete started working on libusb. Pete applies commits from the merge queue and also generates patches against the merge queue, no problem, except that the patches Pete generates aren't in his repo. The repository gap is big, which is a problem. It means that a) Pete has to do some work twice (first for own repo, then for main repo) and b) everyone else can't really relate Pete's ongoing work to the main repo using git, only using patches or in terms of git diff output between files or blobs; no fun. As with Gerrit, or when using git send-email (like Linux kernel development) or with git push to say github, where work is based on other work by someone else, git can be an integral part of the workflow. In those cases it *is* important how git is being used locally, because the output from local work is used as input by others, and a common view is not only reasonable and accurate but in fact neccessary. Normal rebase is fundamental for interacting with other efforts. Interactive rebase is fundamental for reworking patches based on feedback. Both tasks are common, so I agree with Øyvind that these git features need to be understood and practised for any sort of fun and profit with git, and the git UI of choice has to support them. We can blame git for bad situations that arise when people use it - Pete's public libusb repo is just one example, the same situation exists e.g. with Linux kernel ARM trees and within many corporations with organizational problems - but git doesn't create gaps and forks; people create gaps and forks, and it typically happens when people use git as they see fit instead of according to the view of others. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git gui
I actually use git gui. It's not quite as slick as some other options, but it has a lot of functionality in it. -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Peter Stuge Sent: Tuesday, October 25, 2011 7:13 PM To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] git gui jim norris wrote: For those using a git gui, what are you using? On which system? For Windows, there is Git Extensions and TortoiseGit. The Git Extensions looked less slick than TortoiseGit last time I looked, but TortoisGit on the other hand lacked fundamental functionality. For Mac, there is GitX which is kinda nice, but also did not have enough functionality last time I looked. There was some payware which looked nice, but I didn't try it and don't recall the name. I find that using the CLI is by far the easiest, and all features are available. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git gui
On Wed, Oct 26, 2011 at 2:12 AM, Peter Stuge pe...@stuge.se wrote: jim norris wrote: For those using a git gui, what are you using? On which system? For Windows, there is Git Extensions and TortoiseGit. The Git Extensions looked less slick than TortoiseGit last time I looked, but TortoisGit on the other hand lacked fundamental functionality. I recommend Gerrit. Gerrit makes a lot of the nastier concepts, like interactive rebasing and communication easier. From my experience TortoiseGit is a step down the wrong path. It makes things easier than possible, i.e. it tosses hard concepts out of the window. Where is the interactive rebase functionality? I find that Eclipse EGit is starting to become useful and there is a lot of development push on EGit. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
