Hi all!
Due to the current unstable situation with FishEye, which also badly
affects JIRA, I will attempt an upgrade of both applications on a new
server this weekend.
As always I will do my best to keep the downtime low. But keep in mind
that this involves migrating databases from one machine to another, so
downtime may be longer than for a usual upgrade.
In the end, you can expect/hope for a much better performing setup with
all the new features that got added to JIRA and FishEye over time :)
Cheers,
Colin
.... which have nothing to do with history. And which have now been
publically made available/fixed.
Best regards,
Alex Ionescu
On Thu, Feb 16, 2017 at 12:14 PM, Zachary Gorden
<drakekaizer666(a)gmail.com> wrote:
> It was not zero problems. Their entire creation of the git virtual file
> system was to overcome git's limitations.
>
> On Thu, Feb 16, 2017 at 2:07 PM, Alex Ionescu <ionucu(a)videotron.ca> wrote:
>>
>> Sounds like a bug in their migration/etc tool. MS has history going
>> back to 1984 and migrated everything to Git with zero problems.
>>
>> At some point you should apply Ionescu's Razor: "Hmmm, a company of
>> 150,000 developers and the most complicated and oldest series of
>> repositories in the world, was able to move to Git, including while
>> employing people who have been there for 30 years and used to other,
>> older systems.... but 30 open source developers can't make that change
>> because X". It follows from this that X is bullshit.
>>
>> On the polluting history, again, just read commits that have [FOOBAR]
>> in them, and ignore others. Write a post-commit hook to rewrite/squash
>> them.
>> Best regards,
>> Alex Ionescu
>>
>>
>> On Thu, Feb 16, 2017 at 9:41 AM, Zachary Gorden
>> <drakekaizer666(a)gmail.com> wrote:
>> > The project that I worked with using git has history going back to 1988.
>> > They certainly didn't start with git, nor did they necessarily start
>> > with
>> > any revision control at the beginning, but after they migrated to it
>> > they
>> > discovered the history problem.
>> >
>> > On Thu, Feb 16, 2017 at 10:42 AM, Colin Finck <colin(a)reactos.org> wrote:
>> >>
>> >> Am 16.02.2017 um 14:40 schrieb Alex Ionescu:
>> >> > That being said, that type of "dirty history" only happens if you
>> >> > heavily work with branches. That's not how reactos developers work --
>> >> > we
>> >> > don't open PRs and separate branches for every checkin.
>> >> >
>> >> > These ALL sound like manufactured problems or poor/strange use of
>> >> > git.
>> >>
>> >> That merge hell is easily reproducible using my default Git setup:
>> >>
>> >> 1) Change something in your clone of master and do a "git commit".
>> >> 2) Let someone else change something in his clone of master and let him
>> >> "git commit" and "git push" it.
>> >> 3) Try to "git push" your commit, won't work because of the commit of
>> >> the other person.
>> >> 4) Do a "git pull" to fix the problem in 3) -> Bam! Git will do an
>> >> automatic merge of both masters and pollute your history.
>> >>
>> >> You see, not a single extra branch is involved and yet we get two
>> >> parallel streams of history.
>> >>
>> >> Rafal's mentioned "pull.rebase" option sounds promising, but can we
>> >> enforce that somehow?
>> >>
>> >>
>> >> - Colin
>> >>
>> >> _______________________________________________
>> >> Ros-dev mailing list
>> >> Ros-dev(a)reactos.org
>> >> http://www.reactos.org/mailman/listinfo/ros-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > Ros-dev mailing list
>> > Ros-dev(a)reactos.org
>> > http://www.reactos.org/mailman/listinfo/ros-dev
>> >
>>
>> _______________________________________________
>> Ros-dev mailing list
>> Ros-dev(a)reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
Haaaay guys,
so, we will join the guys @ CLT that year, too.
Booth will be maintained by Colin, Mr. [TheFlash] aka Mr. CrystalMath,
Mr. Adamopoulos and me ^^
Hotel planning will be done by me, CDs too I guess (meeeeh).
One thing is still missing. Do we need any stuff?
https://www.thomas-krenn.com/de/unternehmen/kampagnen/thomas-krenn-award.ht…
Seems like we can win some stuff and for that we have to send em
shopping cart IDs for 1st 2nd and 3rd price limit. Winners will be
informed @ CLT Any ideas?
Greetings
Daniel
I too have no idea where this "history limit" comes into play. I work on
and have repos spaning 50-100 developers working on dozens of thousands of
branches over two dozen repos with almost 8 years of history. Some people
rebase, but most people don't.
It is extremely easy to have a clean history due to the fact we enforce the
"[COMPONENT] Description" commit message (and can use a git hook to make
sure it looks this way). It is then trivial to write a script that only
looks for those commits. Heck you can even auto-squash/rebase anything that
doesn't match.
That being said, that type of "dirty history" only happens if you heavily
work with branches. That's not how reactos developers work -- we don't open
PRs and separate branches for every checkin.
These ALL sound like manufactured problems or poor/strange use of git.
On Thu, Feb 16, 2017 at 12:02 AM David Quintana (gigaherz) <
gigaherz(a)gmail.com> wrote:
> If git has an upper limit on history, it's the first time I hear about it,
> and it would be an issue I was simply not aware of. So far as I was aware,
> git just keeps a parent hash on each commit, and the GC just deletes
> commits without any reference. In fact, we use Git at my current job, and
> the history goes back many years, and it seems perfectly capable of
> tracking it. And no, we don't rebase or squash, ever. We are not allowed to
> do any operation that changes commit history. So it's quite a mess of merge
> commits, but even then it's manageable.
>
> I disagree on needing a single person responsible for merges. The the PR
> workflow we have at my current job is that the developer submits a PR for
> review, and adds to the PR two other developers, who have to approve the
> changes or request fixes. Once it's approved, the original developer can
> click the merge button themselves. For external PRs done by contributors,
> then one of the reviewers is the responsible for clicking the merge button.
>
> And even if you do choose to require a commit-master, with the way
> github's merge button works, you can choose to have a merge commit, or to
> squash & rebase implicitly, and the history ends up with one single commit
> attributed to all the developers that were involved in the merge. As an
> example, I have a hobby writing Minecraft mods, and they use Forge to work:
> https://github.com/MinecraftForge/MinecraftForge/commits/1.11.x -- you'll
> see many "<someone> commited with LexManos". That's because there's an
> author, and a commiter, in the git info.
>
> I do agree, git history can get messy, and ugly, and hard to track -- if
> you abuse merge commits. I, unlike Alex, am a fan of manual rebases, and
> leaving a clean history before you submit the changes for review. But I
> understand that constantly rewriting history means you end up with a
> fabricated history at the end. So the policy choices should probably either
> be no merges at all, or no rebasing at all. But that's where "git blame"
> comes in. With a proper tool, you can see exactly who changed a file, and
> when, and you can use it to track back the history of that file, or that
> specific line of code.
>
>
>
> On 16 February 2017 at 03:45, Zachary Gorden <drakekaizer666(a)gmail.com>
> wrote:
>
> I've used both git and svn in work environments. If all you do is git pull
> and git push, you end up with lots of noise in the commit log with git
> tracking every single merge because you don't rebase. Combined with the
> fact that git has an upper limit on how much history it can track and the
> solution literally being to purge history, I'm not exactly sure why all of
> you are so enthused about it. Unless the team wants to adopt having a
> single person being responsible for all commits going into the canonical
> master repo to avoid all of the problems with how git tracks history, the
> commit log is going to be next to useless for actual tracking of history.
> If you don't care about the commit history, then sure, go ahead, but I
> personally would like to be able to easily track changes back cleanly. We
> get that basically for free with svn right now. With git, the usage
> patterns that those of you pushing for git are promoting actively works
> against keeping a clean history.
>
> On Wed, Feb 15, 2017 at 7:32 PM, Alex Ionescu <ionucu(a)videotron.ca> wrote:
>
> Sure, I didn't count git add because you can do it with git commit -a.
> git status/log are the same as the svn equivalents. just like git
> diff/svn diff. I was mainly referring to regular workflow.
>
> In fact, I think outside of stash (which is an optional, but awesome,
> feature) fetch and rebase (which I refuse to learn), all commands map
> 1:1 with svn. That's why I don't get this whole "it takes way more
> commands/steps in git".
>
> git commit -a -m "[BOOTLIB] Fix yet another bug]"
> git push
>
> Done.
>
> Best regards,
> Alex Ionescu
>
>
> On Wed, Feb 15, 2017 at 3:48 PM, David Quintana (gigaherz)
> <gigaherz(a)gmail.com> wrote:
> > My command set is a bit more extended:
> >
> > git clone -- similar to svn checkout into a new folder
> > git checkout -- for changing the current branch
> > git pull -- effectively the same as "svn update", xcept it gets the
> entire
> > change history, not just the latest commit data
> > git push [--force] -- for sending changes into the repository
> > git fetch -- downloads stuff but doesn't apply it to the checkout copy
> > git merge -- can be used to merge the remote data (in which case it's
> like
> > svn update), or to merge from another branch
> > git branch
> > git add
> > git commit
> > git stash save/pop -- can be used to temporarily undo some changes, and
> be
> > able to recover them afterward
> > git status, git log, ... -- for getting info about the state of the
> > repository and the uncommited changes
> > ... and more I that I use less often
> >
> > I do agree that it is a bit annoying that git has so much trouble pulling
> > with local changes, and that is the one area where svn just simply works
> > better. In every other aspect, I have come to like the "git way" more.
> >
> > That said, I avoid commandline git as much as possible. I prefer to use
> > TortoiseGit (in Windows, at home), or SourceTree (at work, where I use a
> > mac, and SourceTree is probably the least shitty frontend for git).
> >
> > I like to say, that for someone who knows Subversion, learning git
> starts by
> > realizing that all the usual svn concepts, apply to git, just NOT with
> the
> > remote repository. The svn-like commands work with the local repository
> > clone, and then it has a separate command set for interacting with
> remotes.
> > Of course it's not a 1:1 match, but it's a good starting point. If you
> are
> > able to "catch" that, then learning how to work with git becomes a LOT
> > easier.
> >
> >
> >
> > On 16 February 2017 at 00:31, Alex Ionescu <ionucu(a)videotron.ca> wrote:
> >>
> >> On Wed, Feb 15, 2017 at 9:01 AM, Zachary Gorden
> >> <drakekaizer666(a)gmail.com> wrote:
> >> > Why is there a need for anything beyond "git commit" or "git push" or
> >> > "git
> >> > pull" to do anything?
> >>
> >> Good question. I've never used any other git command other than those
> >> (except git checkout). Oh, that's lie, I've also used "git branch",
> >> just like on svn, to create a branch.
> >>
> >> Sounds like you've never actually used git? I've never rebased in my
> >> life, and I don't know what other commands even exist.
> >>
> >> Best regards,
> >> Alex Ionescu
> >>
> >> _______________________________________________
> >> Ros-dev mailing list
> >> Ros-dev(a)reactos.org
> >> http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >
> >
> > _______________________________________________
> > Ros-dev mailing list
> > Ros-dev(a)reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
--
Best regards,
Alex Ionescu
Sure, I didn't count git add because you can do it with git commit -a.
git status/log are the same as the svn equivalents. just like git
diff/svn diff. I was mainly referring to regular workflow.
In fact, I think outside of stash (which is an optional, but awesome,
feature) fetch and rebase (which I refuse to learn), all commands map
1:1 with svn. That's why I don't get this whole "it takes way more
commands/steps in git".
git commit -a -m "[BOOTLIB] Fix yet another bug]"
git push
Done.
Best regards,
Alex Ionescu
On Wed, Feb 15, 2017 at 3:48 PM, David Quintana (gigaherz)
<gigaherz(a)gmail.com> wrote:
> My command set is a bit more extended:
>
> git clone -- similar to svn checkout into a new folder
> git checkout -- for changing the current branch
> git pull -- effectively the same as "svn update", xcept it gets the entire
> change history, not just the latest commit data
> git push [--force] -- for sending changes into the repository
> git fetch -- downloads stuff but doesn't apply it to the checkout copy
> git merge -- can be used to merge the remote data (in which case it's like
> svn update), or to merge from another branch
> git branch
> git add
> git commit
> git stash save/pop -- can be used to temporarily undo some changes, and be
> able to recover them afterward
> git status, git log, ... -- for getting info about the state of the
> repository and the uncommited changes
> ... and more I that I use less often
>
> I do agree that it is a bit annoying that git has so much trouble pulling
> with local changes, and that is the one area where svn just simply works
> better. In every other aspect, I have come to like the "git way" more.
>
> That said, I avoid commandline git as much as possible. I prefer to use
> TortoiseGit (in Windows, at home), or SourceTree (at work, where I use a
> mac, and SourceTree is probably the least shitty frontend for git).
>
> I like to say, that for someone who knows Subversion, learning git starts by
> realizing that all the usual svn concepts, apply to git, just NOT with the
> remote repository. The svn-like commands work with the local repository
> clone, and then it has a separate command set for interacting with remotes.
> Of course it's not a 1:1 match, but it's a good starting point. If you are
> able to "catch" that, then learning how to work with git becomes a LOT
> easier.
>
>
>
> On 16 February 2017 at 00:31, Alex Ionescu <ionucu(a)videotron.ca> wrote:
>>
>> On Wed, Feb 15, 2017 at 9:01 AM, Zachary Gorden
>> <drakekaizer666(a)gmail.com> wrote:
>> > Why is there a need for anything beyond "git commit" or "git push" or
>> > "git
>> > pull" to do anything?
>>
>> Good question. I've never used any other git command other than those
>> (except git checkout). Oh, that's lie, I've also used "git branch",
>> just like on svn, to create a branch.
>>
>> Sounds like you've never actually used git? I've never rebased in my
>> life, and I don't know what other commands even exist.
>>
>> Best regards,
>> Alex Ionescu
>>
>> _______________________________________________
>> Ros-dev mailing list
>> Ros-dev(a)reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
On Wed, Feb 15, 2017 at 9:01 AM, Zachary Gorden
<drakekaizer666(a)gmail.com> wrote:
> Why is there a need for anything beyond "git commit" or "git push" or "git
> pull" to do anything?
Good question. I've never used any other git command other than those
(except git checkout). Oh, that's lie, I've also used "git branch",
just like on svn, to create a branch.
Sounds like you've never actually used git? I've never rebased in my
life, and I don't know what other commands even exist.
Best regards,
Alex Ionescu
Just move everything to GitHub:
https://github.com/blog/966-improved-subversion-client-support
-brandin
> On Feb 15, 2017, at 06:32, ros-dev-request(a)reactos.org wrote:
>
> Send Ros-dev mailing list submissions to
> ros-dev(a)reactos.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.reactos.org/mailman/listinfo/ros-dev
> or, via email, send a message with subject or body 'help' to
> ros-dev-request(a)reactos.org
>
> You can reach the person managing the list at
> ros-dev-owner(a)reactos.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ros-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Microsoft switched to Git (Ged Murphy)
> 2. Re: Microsoft switched to Git (David Quintana (gigaherz))
> 3. Re: Microsoft switched to Git (Colin Finck)
> 4. Re: Microsoft switched to Git (David Quintana (gigaherz))
> 5. Re: Microsoft switched to Git (Colin Finck)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 15 Feb 2017 11:04:52 -0000
> From: "Ged Murphy" <gedmurphy.maillists(a)gmail.com>
> To: "'ReactOS Development List'" <ros-dev(a)reactos.org>
> Subject: Re: [ros-dev] Microsoft switched to Git
> Message-ID: <004701d2877b$55983010$00c89030$(a)gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I think the easiest path is to switch to a centralized style model using git.
> That is, we have a master copy (aka trunk) that gives the feel of our existing model. That would allow devs that prefer SVN to mostly continue working as before, and give the devs who want to use git in a more traditional way the ability to branch off and work in a git style manner, then sync their changes back into 'trunk'.
>
>
> -----Original Message-----
> From: Ros-dev [mailto:ros-dev-bounces@reactos.org] On Behalf Of Colin Finck
> Sent: 15 February 2017 10:53
> To: ros-dev(a)reactos.org
> Subject: Re: [ros-dev] Microsoft switched to Git
>
>> Am 15.02.2017 um 11:35 schrieb David Quintana (gigaherz):
>> The number doesn't matter. The ReactOS project can't afford to lost
>> any long-time members. Git would be a benefit for all of us, but it
>> has to be a benefit for ALL of us.
>
> Let's not forget:
>
> - Part of the reasons developers had against Git may have been resolved by now.
> - Part of the problem may be that "Git is so different" to some devs, but I think this can be resolved by a detailed Wiki article showing how to do the same thing in SVN and Git. We already wrote such articles for TortoiseSVN after all!
> - And finally, we first need a plan for a Git move that doesn't suck. We tried SubGit and it failed for us. Then there is the "Merge workflow", which is supported very well by all tools, but creates a lot of parallel history. The "Rebase workflow" is more like what SVN does (keeping a linear history), but no idea how to enforce that with TortoiseGit.
>
> I think if a team could look after these things and help moving each and every developer towards Git, it may even be doable for us.
>
> Cheers,
>
> Colin
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 15 Feb 2017 12:18:40 +0100
> From: "David Quintana (gigaherz)" <gigaherz(a)gmail.com>
> To: ReactOS Development List <ros-dev(a)reactos.org>
> Subject: Re: [ros-dev] Microsoft switched to Git
> Message-ID:
> <CADD3+ruo18pQos1QO+jCHg5V2-hyrrjSZ7Va1pfgm+tprDbDZw(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> My belief is that the best path would be:
>
> Phase 0: This is how we are now. We have SVN master (trunk), and a
> read-only git mirror, and a semi-updated github mirror for when a
> contributor really wants to submit git PRs.
>
> Phase 1: Switch to using Git with PRs for submitting patches (Github's PR
> system is really really nice these days, but other solutions exist). Setup
> a SVN mirror "bot" that creates one svn commit for each push/merge detected
> in the master branch, and allows the buildbots to continue working as they
> do now.
>
> This would allow the existing svn-patch workflow to continue working, but
> commits on svn wouldn't be allowed anymore. Developers are expected to at
> least TRY to learn to use git (it's not that hard! I promise!).
>
> Phase 2: We switch the buildbots and testbots to pull from git, enable
> testbot access for git PRs (such as with a github bot that responds to
> "@rosbot runtest" or similar). The SVN mirror remains, for archival
> purposes, but git commits aren't merged so regularly. Release tags/branches
> can still be published through SVN, for ease of access.
>
> Phase 3: Everyone ends up agreeing that maintaining the svn mirror is no
> longer worth the effort.
>
> Of course, anything like this will only happen if the entire team agrees to
> it.
>
> On 15 February 2017 at 12:04, Ged Murphy <gedmurphy.maillists(a)gmail.com>
> wrote:
>
>> I think the easiest path is to switch to a centralized style model using
>> git.
>> That is, we have a master copy (aka trunk) that gives the feel of our
>> existing model. That would allow devs that prefer SVN to mostly continue
>> working as before, and give the devs who want to use git in a more
>> traditional way the ability to branch off and work in a git style manner,
>> then sync their changes back into 'trunk'.
>>
>>
>> -----Original Message-----
>> From: Ros-dev [mailto:ros-dev-bounces@reactos.org] On Behalf Of Colin
>> Finck
>> Sent: 15 February 2017 10:53
>> To: ros-dev(a)reactos.org
>> Subject: Re: [ros-dev] Microsoft switched to Git
>>
>>> Am 15.02.2017 um 11:35 schrieb David Quintana (gigaherz):
>>> The number doesn't matter. The ReactOS project can't afford to lost
>>> any long-time members. Git would be a benefit for all of us, but it
>>> has to be a benefit for ALL of us.
>>
>> Let's not forget:
>>
>> - Part of the reasons developers had against Git may have been resolved by
>> now.
>> - Part of the problem may be that "Git is so different" to some devs, but
>> I think this can be resolved by a detailed Wiki article showing how to do
>> the same thing in SVN and Git. We already wrote such articles for
>> TortoiseSVN after all!
>> - And finally, we first need a plan for a Git move that doesn't suck. We
>> tried SubGit and it failed for us. Then there is the "Merge workflow",
>> which is supported very well by all tools, but creates a lot of parallel
>> history. The "Rebase workflow" is more like what SVN does (keeping a linear
>> history), but no idea how to enforce that with TortoiseGit.
>>
>> I think if a team could look after these things and help moving each and
>> every developer towards Git, it may even be doable for us.
>>
>> Cheers,
>>
>> Colin
>>
>> _______________________________________________
>> Ros-dev mailing list
>> Ros-dev(a)reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>>
>> _______________________________________________
>> Ros-dev mailing list
>> Ros-dev(a)reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
How about I leave if we DON'T switch to Git? I fucking hate SVN now
(read my e-mail from 8 years ago on this topic, lol!).
Best regards,
Alex Ionescu
On Wed, Feb 15, 2017 at 3:32 AM, Colin Finck <colin(a)reactos.org> wrote:
> Am 15.02.2017 um 12:18 schrieb David Quintana (gigaherz):
>> Setup a SVN mirror "bot" that creates one svn commit for each push/merge
>> detected in the master branch, and allows the buildbots to continue
>> working as they do now.
>
> Let's not have a Git repository with a parallel SVN mirror again. SubGit
> tried to accomplish this as a professional solution and it failed for us.
>
> There is no reason to take extra care of the Buildslaves at all.
> The same infra people, who would do the switch to Git, could also change
> the Buildslaves to use Git instead of SVN in the course of that.
>
>
> - Colin
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
