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 it sees itself as an
independent branch, with mainline as a development branch, off which it
integrates commits on regular basis (but not using rebase, which is a
minor point as the end result is the same).
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.
Excuse me? You seem to forget that I created an integration branch off
my repo to hold my patches ([4], [5] - I actually had to create two,
because they are off the ever annoying -stuge even, a public branch that
sees commits deleted and rearranged whenever you see fit, which is a
major PITA to follow for anybody else), and that I plan to have a formal
integration branch off mainline when 1.0.9 is released. So the patches I
generate against mainline are in fact my repo, albeit in a dedicated
branch (though I didn't bother create one for the last set of patches,
because, as proven here, you seem to overlook/not use these branches anyway)
As I repeatedly stated, and which you keep forgetting (well, it's only
be been months since I last re-explained that), once my patches have
been integrated, I am planning to keep a unique integration branch off
mainline, for the Windows development, updated on regular basis (but
I'll probably have to keep the original -pbatard for development,
because it would be impractical to simply drop it now). As long as
mainline hasn't closed the gap, which is the actual issue here, that
can't happen. Once you release, you may be surprised to see how much
happier you may be with the whole process, so perhaps you want to try
that, once in your life...
The repository gap is big, which is a problem.
Indeed, and 2 years of integration being delayed for no good reason has
been a major factor to that. Or do you also want to blame the gap on me
using git as I see fit? I'd be very interested in hearing the reasoning
behind that.
It means that a) Pete has to do some work twice (first
for own repo, then for main repo)
Which doesn't really change anything for me, since I need to reformat
stuff to present it to mainline regardless. Even if I was rebasing off
mainline, I'd have to reformat my stuff and resolve conflicts, which I
personally found git was unhelpful with, and which is the main reason I
switched to a more direct approach when doing that work, because I found
it saved me time.
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.
Again, what about the integration branch(es)? Once mainline has closed
the gap, integration will be the main referral for people wanting to
bridge mainline and Windows. Thus I really fail to see what your beef is
against -pbatard. You do NOT have to do anything with -pbatard, and you
shouldn't have to. Or are you telling us that the current guidelines for
libusb patch submission have changed, and that you should have the right
to pick whatever you want for whatever libusb branch you see fit? What
happened to cleaning up and officially presenting patches for review and
integration? None of what I do in -pbatard is aimed at being presented
as to mainline without post processing because, to me, that's what a
*development* branch is for.
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.
And it can. Unless you mysteriously insist on wanting to exert control
on the -pbatard branch by *choosing* not to use the integration branch
that is provided to you.
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.
I feel like I'm starting to repeat myself. You have/will have an
integration branch off -pbatard that you can use, which:
1. lets me free to use git during development as I see fit
2. lets ANYBODY use git to integrate nicely formatted Windows
development changes off mainline, as they see fit.
Once the Windows backend is actually integrated and released, the
integration branch will be kept up to date against mainline with commits
that you can pick at your leisure. And of course, it will be rebased off
mainline at regular intervals (unless you also take years to integrate
commits, in which case it will only be rebased when I feel like it).
Thus, once again, what I decide to do in -pbatard is irrelevant for
mainline, until officially presented. And people wanting to do
derivative work for Windows, and somehow bothered about -pbatard, will
be able to use the integration branch.
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.
Yes, in a normal workflow, one would indeed use (interactive) rebase
(which again is provided by Tortoise). The root of the matter however,
is that libusb is dysfunctional, because it:
1. Only pushes commits to mainline every 6 months or so
2. Has a separate branch, that sees commits dropped and reorganized on a
whim in -stuge (and that only sees work occurring about once every 3 months)
3. Removes features against general advice.
4. Pushes new development out for years (and then complains that they
evolved on their own - I hope to be able to present a hotplug patch
somdeay, which has been sitting for more than a year in its own branch)
So the matter is not people deciding they don't want to use git feature
X or Y. The matter is with a project not allowing people to get any
benefit from using feature X or Y because it is essentially dysfunctional.
If you want people to use git in a more realistic manner, then please
fix the libusb release and integration process (by for instance,
*allowing* other maintainers than yourself, as we do have people willing
to help there). You may be surprised to find out that people will see
rebasing as a viable option again.
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
Exactly.
and it typically happens when people
use git as they see fit instead of according to the view of others.
No, it typically happens when people believe that Release Early Release
Often is a fallacy (or equate it to rushed), thus NEVER release and
force others to take palliative action by having to maintain a branch
that was only intended to be temporary, to compensate. Then they get on
their high horses, conveniently ignore facts, such as their ability to
use a dedicated integration branch, and inaccurately blame others for
their own failings.
The -pbatard branch is not responsible for the problems we have in
libusb (it is not, and was never meant to be under your control). Either
stop pretending it is, or, once again, provide concrete examples to
prove your point.
Regards,
/Pete
[1] http://git.libusb.org/?p=libusb-pbatard.git;a=summary;js=1
[2] http://pete.akeo.ie/2011/07/git-remote-repository.html
[3] http://pete.akeo.ie/2011/02/denying-non-fast-forward-and.html
[4]
http://git.libusb.org/?p=libusb-pbatard.git;a=shortlog;h=refs/heads/integration_temp;js=1
[5]
http://git.libusb.org/?p=libusb-pbatard.git;a=shortlog;h=refs/heads/integration_temp2;js=1
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
