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 dismiss all
alternative views.
4. Dismissing the idea that git could harbour a major bug (which really
was the root of the issue), by blindingly asserting that the problem was
purely misuse of git by its users.
5. Finally, when shown that such a major flaw actually existed, and
asked for opinion/advice, simply keeping dead silent (which is
unfortunately, and ironically, see below, a very common mode of action
from Peter)
Do you also have a comment on why, as demonstrated by Michael, it is
apparently possible to trick git into producing different data for the
same commit ID, depending on the path one takes in git to reach that commit?
For anybody who wants an appraisal of Peter's actions when it comes to
exerting critical judgement with regards to git, and the reason why some
of us are taking his advice with a grain of salt, instead judging for
ourselves, it's all there in the libusb-devel mailing list ([2], in the
99 posts thread, which unfortunately marc.info seems to have a trouble
with today). This could be used as a cautionary tale against blindingly
trusting git as well as git-worshippers.
By the way, Peter, feel free to dropping by libusb-devel anytime to
answer some very basic maintainer questions such as, now that the RCs
have been out for more than a month, your ETA on the actual 1.0.9
release. Or should we assume that, as you have repeatedly demonstrated
by failing to replying to any of the repeated requests from libusb
users, it is impossible to discuss with you once you have decided you
hate something as simple such as providing some form of ETA.
TL;DR: Git is just a tool, feel free to use it as you see fit, GUI or
not. But please remember that, like all tools, it has its advantages and
limitations. 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.
Regards,
/Pete
[1]
https://lists.berlios.de/pipermail/openocd-development/2011-October/021211.html
[2] http://marc.info/?l=libusb-devel&r=3&b=201012&w=2
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
