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
