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
>
Hi all!
Let me announce a definite date for our JIRA/FishEye upgrade:
Wednesday, March 8, around 9:00 UTC
Expect downtimes of several hours at https://code.reactos.org and
https://jira.reactos.org around this time.
I can say for sure that I will have enough time on this day and the
following to deal with all possible incidents that could happen during
the complex upgrade.
This also allows me to get direct in-person feedback from all the devs
attending CLT on the weekend after that :)
The upgrade to JIRA 7.x is a major one, and Atlassian recommends
everyone to have a look at the new features:
https://confluence.atlassian.com/migration/jira-7/server_jira_product-chang…
Best regards,
Colin
Hi folks!
We just got the good news: ReactOS has been accepted and will be
participating in Google Summer of Code 2017!! :)
Next step is finishing the Ideas list. Our current version is at
https://reactos.org/wiki/Google_Summer_of_Code_2017_Ideas
More information will also follow shortly on our website.
Cheers,
Colin
These are so much more useful to read now we have a changelog to explain the patch.
Thanks Amine :)
-----Original Message-----
From: Ros-diffs [mailto:ros-diffs-bounces@reactos.org] On Behalf Of akhaldi(a)svn.reactos.org
Sent: 26 February 2017 16:01
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [akhaldi] 73929: [CABINET] Sync with Wine Staging 2.2. CORE-12823 a663fe94 cabinet: Set index of folder in FDICopy callback. 1f7d144 cabinet: Make Extract fail on read-only files. af86bdc cabinet: ...
Author: akhaldi
Date: Sun Feb 26 16:00:58 2017
New Revision: 73929
URL: http://svn.reactos.org/svn/reactos?rev=73929&view=rev
Log:
[CABINET] Sync with Wine Staging 2.2. CORE-12823
a663fe94 cabinet: Set index of folder in FDICopy callback.
1f7d144 cabinet: Make Extract fail on read-only files.
af86bdc cabinet: Make Extract overwrite existing files.
3273dff cabinet: Properly initialize internal fci structure (Valgrind).
Modified:
trunk/reactos/dll/win32/cabinet/cabinet_main.c
trunk/reactos/dll/win32/cabinet/fci.c
trunk/reactos/media/doc/README.WINE
I think I'm going to upload two PDF files to prove my point.
On Thu, Feb 16, 2017 at 11:25 PM Hermès BÉLUSCA-MAÏTO <hermes.belusca(a)sfr.fr>
wrote:
> Hi ! Here are some thoughts as an answer to Ziliang's mail:
>
> > De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Zachary
> Gorden
> > Envoyé : jeudi 16 février 2017 23:03
> > À : ReactOS Development List
> > Objet : Re: [ros-dev] Microsoft switched to Git
>
> > The fact that git has problems maintain a large history is ONE of the
> limitations that prompted them to develop GVFS. There are several comments
> on the first page in the discussion of the ars technica article on GVFS
> that talk about git's issues with long histories:
> >
> https://arstechnica.com/information-technology/2017/02/microsoft-hosts-the-…
> > I can't link directly to the comments, but if you search by user name
> you jump right to them. Two especially relevant ones are by smengler and
> zaqzlea. The one by zaqzlea is also rather interesting if Linux itself has
> truncated its own commit history, which is more than a bit disturbing from
> > my perspective.
>
> I guess that this 'truncated history' story happened when Linus switched
> to his newly-created Git the 16. April, 2005 :
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=…
> because, if one believes what's written inside
> https://git.wiki.kernel.org/index.php/GraftPoint , "When Linus started
> using git for maintaining his kernel tree there didn't exist any tools to
> convert the old kernel history." Later on, when new features have been
> added to Git, people were able to create Git repositories of Linux' code
> before the 16/04/2005 Git transition, and then, to be able to see the whole
> Linux history, you need to use the so-called graft points. Examples are
> given here:
>
> http://stackoverflow.com/questions/3264283/linux-kernel-historical-git-repo…
> https://archive.org/details/git-history-of-linux
>
>
> > We also see a few remarks by a guy calling himself scuttle22 who claims
> that truncating history and dropping it is "common practice" and
> acceptable. His original posts have all been downvoted to oblivion,
> presumably because others take a less lackadaisical perspective
> > on preserving history for purposes of documentation and accountability.
>
> This is possibly "common practice", maybe in order to reduce the git
> repos... In there:
> http://stackoverflow.com/questions/4515580/how-do-i-remove-the-old-history-…
> , someone ask for example how to trim the history before a certain date,
> while the complete copy of history is kept in an archive repository....
>
>
> I also take the occasion to mention the peculiar possibility, with Git, to
> have a repository having multiple roots ("initial commits"): for example,
> someone did the error once in the linux kernel repo:
> http://lkml.iu.edu/hypermail/linux/kernel/1603.2/01926.html .
>
> Best,
> Hermès
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
--
Best regards,
Alex Ionescu
Hello,
Let me invite you to the monthly status meeting taking place tomorrow,
23rd of February, 19:00 UTC.
IRC service will only be started shortly before the meeting. Your
participation passwords and server address will be emailed to you
shortly before the meeting starts, and they are going to be different
once again as they are not stored in any database. Hopefully it's not
much of inconvenience.
Alternatively we'll do it in #reactos-meeting on Freenode, depending on
our admins mood.
Please send agenda proposals to me before the meeting so we don't waste
time trying to setup the agenda directly during the meeting.
Regards,
Aleksey Bragin
Hello everyone,
Today I was finally able to finish the installation of Office 2010 in
ReactOS, using as a temporary measure the Wines NTLM layer that calls into
the ntlm_auth utility of Samba. This was done while Samuel is completing his
NTLM implementation.
As this wine layer is here running on ReactOS, few modifications were
needed, and I also needed to find a Windows build of Samba. Ive found one,
by chance, at http://smithii.com/samba . Then, using ReactOS revision 73868
(or later), and using this version of Samba, the Office installation
finishes (reminder: the problem was due to the fact the installer needed
NTLM to communicate with the Office Software Platform Service,
OSPPSVC.EXE). We are now able to use Excel, Word, on ReactOS, as shown in
this picture:
http://i.imgur.com/fLEwoVI.png
There are now 2 main problems:
- NTLM should be correctly implemented;
- There are an awful lot of drawing problems with Office 2010 applications
(similar to those of Office 2007 apps): for example, dragging the graph
downwards shows his frame going upwards; there are many black regions that
show up, etc...: It seems we have problems in coordinate frames. And other
problems too. Also, we have some mouse capture problems: if you try to
redimension the windows the normal way (bring mouse cursor on top of the
border, left-click-maintained, move mouse, release left button), and then
move the mouse inside the window, it continues to be redimensioned...
As a result, I took ~=15 minutes to make this simple trivial picture above,
almost all the time taken to fight against window dimensioning & the drawing
problems.
But anyways, enjoy !
This will be part of my next blog report.
Cheers,
Hermès
Added:
trunk/reactos/dll/win32/comctl32/button.c
- copied, changed from r73835,
trunk/reactos/win32ss/user/user32/controls/button.c
O---M---G!!!!! My head just exploded!
