tl:dr; agreed
Also, something not mentioned elsewhere and which I didn't know where to
put: a large appeal of git in mingw-w64 is coherency with other source
repositories. One less tool to master.
On Sun, May 04, 2014, NightStrike wrote:
> Responding to both of you inline... sort it out :P
> >> any developer with write access can
> >> simply push their changes since, by definition they do actually have
> >> write access, although sending for review highly recommended. Git does
> >> open an avenue to "pull" style reviews, so even the authors without
> >> write access have the chance to publicly host their code (eg github)
> >> before it is pulled into mingw-w64. The vista headers was more of a
> >> miscommunication, I really thought you gave the green light to commit.
>
> > It is also possible to have users changes on a branch on the SF
> > repository and have someone merge them in the master branch.
> > For instance at work we have branches named
> > "users/${user}/${branch_name}", i.e. users/adrien/break-everything.
> > It was possible to finetune the rights to such branches and to the
> > master branch independently. While this was enforced by the software,
> > I'm confident it could also be a process enforced through the ancestral
> > method of hitting with a baseball bat people who do things wrong (in the
> > event SF does not allow restriction through software).
> >
> > I'm happy with restricting the rights to the main branch because there
> > is a strong guarantee the commits have been reviewed.
>
> This idea of Adrien's is a good one. It is common in many projects,
> and usually works well. However, am I understanding it correctly this
> workflow?
>
> A) Alice has a change, works in a branch, finishes.
> B) Alice posts the change for reviewing somehow (patch to ML, link to
> git repo, etc)
> C) Someone with expertise approves
> D1) Someone with super rights does a git pull into master
> D2) Alice does a git push into master
>
> D1 or D2?
>
> If it's D1, you get the security, but that's going to get old real
> fast for the few people allowed to do a pull. D2 opens the door for
> irrevocably butchering the whole repo (As I said, I've done this --
> it's not hard.) It also means that everyone is going to be merging
> and resolving conflicts differently, based on their own style. This
> is probably the worse of two evils.
>
> If you look at Linux, it uses D1. There are people who pull changes
> into modules, and Linus pulls changes from them into the Real Deal.
> This is very different than working in svn, where after a green light
> on the ML, Alice would just "svn ci".
>
> Actually, there are parallels to svn. In svn, Alice should do:
> svn copy ^/trunk ^/branches/Alice // Create branch
> ...work in branch...
> svn merge ^trunk // Keep branch up to date
> svn co ^trunk // Checkout trunk to merge back
> svn merge ^/branches/Alice --reintegrate (or not reintegrate for cherry
> picking)
> svn ci
>
> Instead, what usually happens is:
> svn co ^/trunk
> svn ci
>
> The nature of my August 2011 email was basically this -- we currently
> as a project do not branch and merge correctly, or often at all. Svn
> has superb branch/merge capabilities, but they just aren't used. Now,
> what that means is that if you change the VCS to git, you have to
> REALLY spell out how to change that workflow, or else you'll be stuck
> in an even worse spot. That means writing down in the wiki a set of
> procedures that all developers have to follow:
>
> 0) This list is just off the top of my head, surely not exhaustive
> 1) how you expect changes to propagate
> 2) who is in charge of what branch
> 3) how and when is the right time to rebaseline
> 4) how to keep a branch commit history clean
> 5) how to branch << This is a big one. I'm not talking about the
> syntax of the command.. I'm talking about what things to consider when
> making a new branch. Just grabbing HEAD is a **baaaaaaaaad** idea.
> This is a somewhat decent reference that you should understand:
> http://www.kdgregory.com/index.php?page=scm.git Specifically the
> sections "Master is for Integration, not Development", and "Have an
> Integration Czar".
>
> That last one is paramount. What I see currently happening is the following:
>
> A) Jon gets a spur of the moment idea to change everything to git
> B) Everyone goes gaga because git's cool
> C) Now we're in git, and everyone knows how to use it..... differently
> D) 3 weeks later, the repo is a mess, and you've lost any gain you
> might've had (try doing git-bisect now)
>
> You've done the technical work -- put up test repos, asked people to
> try them, raved about the speed. But I've not seen any administrative
> work that documents the mingw-w64 way of doing git business. That's
> not something you're going to throw together in ten minutes using a
> script. You really need to think about the implications of the
> workflow that's right for THIS project.
>
> This is an issue that you *NEED* to work out before you make this
> thing live, as doing this wrong in git is a LOT harder to clean up
> than doing it wrong in svn. >>> If you don't understand how
> important this is, then you are not qualified to be doing this
> conversion. <<<
Each time I answer after that many long quotes on this list I have a
thought for bottom-posting on mingw-users. :P
In one word: agreed.
It's difficult to expand on that without using many words and adding
only a few things here and there.
The workflow I am used to is:
- Bob does his development in a branch
- When the branch is ready for merging, Bob rebases his branch on master
and asks for review plus merge
- Alice reviews and, if happy, merges to master
Extra points:
- master is fast-forward only, meaning it's not possible to rewrite the
history, even when trying to force it (the only possibility is to ssh
by hand, change the configuration, do the rewrite; but then 'rm' on
the server works just as well if you want to break everything)
- Not everyone has rights to push in every branch (but we need to make
sure sourceforge allows to seutp that; should be fine since
sourceforge users have actual unix accounts)
- This applies even if Bob has the rights to push on master (the main
difference being maybe that then he can do the final push himself but
that's very minor)
- The history of master is linear unless when really really not possible
A major difference with how this is done in the Linus kernel is the
rebase before merging. I prefer doing it when possible since it makes
history easier to read and helps a lot with bisects (otherwise branches
might have been created a loooooong time ago with a vastly different
tree).
I think this is not done in the Linux kernel because branches are
long-lived, with a large audience and are not simply one or two commits
but usually dozens (making the situation slightly better).
So that's my proposal. Hope it made sense.
You also mention what to branch from. I think this will derive from how
branches are used. Master is always stable and before doing a release,
git tag the corresponding commit and create the corresponding
bugfix-only branch.
It is expected that most bugfixes apply to the latest code and at least
one stable branch. Meaning the commit happens on "master" or on "stable"
and needs to be put onto the other branch too.
Cherry-picking works. I've also experimented with bugfixes going to the
stable branch which is then merged to the development one, ensuring no
bugfix is forgotten for the next version; this works too but gets
increasingly annoying as the codebases diverge (and it seems Murphy's
Law applies: it gets annoying as quickly as possible).
Since Ozkan handles the stable branches, I think he gets a very heavy
opinion on this aspect.
> >> > 3) svn history is impossible to change. git history is purposely
> >> > malleable, usually so that a user can merge a clean branch without all
> >> > the false starts that come from development. How will you stop users
> >> > from (possibly inadvertently) changing the history of whatever "trunk"
> >> > becomes in an undesirable way? Maybe it's a non-issue? I don't
> >> > expect malice, but I could easily see a user accidentally doing that.
> >> > I've done it myself, actually, on two occasions, the first of which
> >> > required a restore-from-backup (oops..).
> >> >
> >>
> >> git would reject the push if the commit checksum before it did not
> >> match. As with SVN, it will block if your changes if it is not based on
> >> the latest revision.
>
> My experience differs. I've corrupted master history before by trying
> to clean up my branch.
As stated above: forbid this in the configuration of the master (and
release) branches. Actually, everything that is meant to be used by
non-devs as opposed to branches for development purposes.
> > Moreover, git has the ability to allow forcing such operations and to
> > deny forcing them. The master branch should never allow them and the
> > rage from users who have to endure such changes is most often enough to
> > deter anyone from doing so anyway (and I'm ready to send a snail-mail
> > handwritten letter to anyone doing so).
>
> You need to expand on this, and not talk in the theoretical. How do
> you set that up? What are the implications of doing so? What does SF
> support?
This is a simple change in vim's configuration file (in the case SF
doesn't changing that in some Web UI). I don't think I can check on
jon_y's repo (seems I don't have the rights to access it through ssh).
There are no drawbacks besides the inability to easily do crap. In the
unlikely case history rewrite is needed (let's say legal order), this is
as easily changed again for the time to do the rewrite.
> >> > 6) Is there any way to do a partial checkout with git? Right now,
> >> > someone can check out just a small piece of the whole repo, whatever
> >> > is interesting. How do you do that in git? I have only ever been
> >> > able to figure out how to do the whole thing. On one project that I'm
> >> > on, the svn repo is a few terabytes. That's a blocker for that
> >> > project switching to git -- it doesn't scale well at all. If you know
> >> > how to deal with that, I'd be interested. The only answer we've ever
> >> > found was "split it into many repos", which obviously isn't a viable
> >> > solution or we would have done it already.
> >> >
> >>
> >> Actually, git cloning the entire repo turns out to be faster than SVN
> >> doing partial checkouts, I don't see this as much of a hurdle.
>
> I wasn't asking about mingw-w64. I was asking in general. For
> instance, cloning binutils takes FOREVER.
I had witnessed the slowness before so I did a clone on two machines.
Below are the results (for curiosity).
One is residential DSL, the other is 100Mbps in a datacenter.
210MB to download, bandwidth of the DSL was maxed (was at most 600KB/s),
bandwidth of the DC'ed machine wasn't maxed either but was around 5MB/s.
This is heavily influenced by internet connectivity. I guess
sourceware's connection isn't incredible and my paths to it weren't
great either.
Binutils is a large repositoy. There are many large files for the
testsuites. History in git goes back to 1988. Probably the other reasons
it is such a big download.
And as said earlier this is not avoidable with git and shallow clones
don't save that much space either. This is unfortunate and I'm not aware
of work on that aspect (not sure it's possible to improve).
> > More precisely, git is fast to clone by batching files: it packs them
> > and transfers the packs. When I tried JonY's read-only git repo, I ended
> > up cloning at 2MB/s (max of the line) and was done in 10 seconds.
> > The download was a bit more than 20MB. I had previously mentionned 67MB
> > or so but that was a "git-svn" clone which most often produces bigger
> > files than a regular git repository. So 20MB or so and 10 seconds it is
> > for me.
>
> The mingw-w64 repo is tiny. I've worked with terabyte repos. with a T.
I know Microsoft has a lot of dead bodies hidden but I doubt there's
_that_ _much_. :P
More seriously, I don't think git scales to huge repositories, at least
yet. It scales well to lots of contributors however. Mingw-w64's
codebase and history would have to grow a hundred times for git's memory
requirements to start being an issue for machines which are already
considered as fairly old today. I think we're safe on this aspect.
Regards,
Adrien Nader
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
