- Ros-dev - ReactOS.org

Re: [ros-dev] New ideas added to GSoC Ideas list
by Can Tasan 17 Mar '17

17 Mar '17

I also have some ideas here, not fully sure about their feasibility. Tried to be wise as much as I can. -Continuing USB work that vardanm started. Yes, I know a developer is working on that. Another joining student would be great and speed up things. -Continuing TCP/IP stack work if noone is working on rewrite. -Working on DirectX support: bringing new features, fixing bugs, optimising, if possible fixing some driver issues... -Fixing driver unloading/fallback problem (CORE-8294) I think it's a hurdle on our hardware compatibility, but not sure its priority. -Would some kind of Win32 subsystem work be too hard? -Implementing some missing things in shell. -Implementing more user mode stuff, or is it enough for now? -Extending printing support. -Fixing current audio support, if our devs don't want to tinker with it. -Implementing WoW16 support. I suppose that'll draw attention. And as said before, proper application compatibility database. :) By the way, I'm too pleased to join and see you here all! With my best regards, Can Taşan

7 9

Definite Decision about ISO lifetimes at iso.reactos.org
by Colin Finck 16 Mar '17

16 Mar '17

Hi all! We used to remove any ISOs at https://iso.reactos.org that were older than 2 years. Then some devs wanted access for a little longer and we stopped deleting any. Now we recently ran out of space on that server... Even though we are about to double our storage capacity, I want a definite decision about the lifetime of ISOs at iso.reactos.org. Something that serves us well over the next few years. Otherwise, we will just run into the same problem again in the near future. My proposal =========== bootcd-dbg: 5 years bootcd-dbg-msvc: 5 years bootcd-rel: 0.5 years bootcdregtest: 1 week livecd-dbg: 0.5 years livecd-dbg-msvc: 0.5 years livecd-rel: 0.5 years Having the DBG Boot-CDs up for 5 years should cover all reasonable regression testing in my opinion. I'm not that much into testing as you though, so if any of these lifetimes are too short for you, please speak up now. Otherwise, I'm going to implement this by next Wednesday, March 22. Cheers, Colin

2 2

Re: [ros-dev] New ideas added to GSoC Ideas list
by Ștefan Fulea 15 Mar '17

15 Mar '17

Marți, 14 martie 2017 12:00:02 +0000, Mark Jansen <learn0more+ros(a)gmail.com> a scris: > How about a better way to translate ros? > For example integrating .po files with our rc files (possibly needs a > preprocess step or something tho), > Or creating a resource editor that allows multiple files to be edited > at once? > Please don't push for .po resources, for these are not better. As for improving the process, I doubt it'd repay the investment. After the initial translation effort, the further maintenance requires very little.

5 6

Regarding Smart Commits
by Colin Finck 15 Mar '17

15 Mar '17

Hi all! Some people have noticed that Smart Commits (#resolve, #comment, etc.) have stopped working after the JIRA/FishEye upgrade. This is due to the new per-user OAuth authentication between both systems, which means that every committer needs to authorize FishEye once to impersonate as your JIRA account. FishEye only tells you this and the URL to fix it after the first failed Smart Commit, but here it is: https://code.reactos.org/plugins/servlet/applinks/oauth/login-dance/authori… Click that, confirm and all subsequent Smart Commits should work. Make sure you are logged into JIRA and FishEye before. Cheers, Colin

1 0

Re: [ros-dev] New ideas added to GSoC Ideas list
by Alex Ionescu 13 Mar '17

13 Mar '17

I would like to see support for GPT partititioning :) Best regards, Alex Ionescu On Sun, Mar 12, 2017 at 3:51 PM, Javier Agustìn Fernàndez Arroyo < elhoir(a)gmail.com> wrote: > i dont think anyone has any problems on downloading a 100MB ISO file.... > but... what about any kind of minimal network install ISO file support? > > On Sun, Mar 12, 2017 at 11:34 PM, Thomas Mueller <mueller6723(a)twc.com> > wrote: > >> > Victor thought also about adding registry hive healing. >> > Hermès. >> >> > -----Message d'origine----- >> > De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Colin >> Finck >> > Envoyé : dimanche 12 mars 2017 17:27 >> > À : 'ReactOS Development List' >> > Objet : [ros-dev] New ideas added to GSoC Ideas list >> >> > Hi all! >> >> > Daniel and me collected some additional ideas for GSoC today, which >> I've added to our Wiki Ideas list: >> > https://reactos.org/wiki/Google_Summer_of_Code_2017_Ideas >> >> > In particular: >> > * Fundamental WiFi components >> > * USBXHCI driver for supporting USB 3.x controllers >> > * Bluetooth Stack >> > * WebKit-based MSHTML implementation >> >> > I'm open for comments and suggestions! >> > We can still add ideas until March 20, so let's give students a large >> pool to draw from. >> >> > Cheers, >> >> > Colin >> >> Would GPT partitioning support for ReactOS be appropriate for GSoC? >> >> Also, the ability to build or cross-build ReactOS and install directory >> to a FAT32 partition, mounted on a directory, without having to burn to CD >> and boot/install from there: would that be appropriate? >> >> Tom >> >> >> >> >> _______________________________________________ >> 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 > >

2 1

Work on dxg.sys
by Sebastian Gąsiorek 10 Mar '17

10 Mar '17

Hi, Couple of days ago I have started dxg.sys functions implementation. There is some progress but it would be good to write tests for this api. Dxg mostly is just wrapper between driver and win32k, so win32k api tests should be enough. I saw some tests in rostests\dxtest\win32kdxtest but can't figure out how to enable them in build. Could some help me with this and add proper cmake files? :) Best regards, Sebastian

4 4

CLT, one seat left
by Daniel Reimer 09 Mar '17

09 Mar '17

After some strike related problems we lost one of our supporters @ Chemnitzer Linux Tage (https://chemnitzer.linux-tage.de/2017/de) SO if someone wants to join. Here we are, waiting for ya. Start is on THIS saturday and ending is THIS sunday evening. Yes, quite a bit early I ask here, but... sadly the problems showed up today. We might even have a hotel room left if our hotel does not cancel it that close to booking date. Otherwise we find a way, too. So, first come first served. Sell your soul/come to us ^^

1 0

Re: [ros-dev] [ros-diffs] [mjansen] 74063: [NTDLL] Fix RtlDecodeSystemPointer for usage inside ntdll. CORE-10368
by Michael Fritscher 06 Mar '17

06 Mar '17

Hi, I don't know - but this looks somehow ... surprising. Best regards, Michael > /* > * @implemented > + */ > +PVOID > +NTAPI > +RtlDecodeSystemPointer(IN PVOID Pointer) > +{ > + return RtlEncodeSystemPointer(Pointer); > +} > + > +/* > + * @implemented

2 2

Buildslave disk space problems fixed
by Colin Finck 05 Mar '17

05 Mar '17

Hi all! We have run out of space on our temporary universal Build and ISO machine HotelLux today. This is why TestCD creation has been failing. I'm currently moving files away from the main disk to a temporary storage. You should already be able to redo the failed builds. Within this month, Aleksey and me will move the ISO storage back to our actual storage server, upgraded with larger disks. This one should be sufficient for quite some time. Sorry for the inconveniences! Cheers, Colin

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 74068: [WS2_32] - Fix pointers verification in WSALookupServiceNextW and WSALookupServiceNextA; - In WSALookupServiceNextA: Perform extra checks to see whether we failed the first local ...
by Thomas Faber 05 Mar '17

05 Mar '17

On 2017-03-05 01:40, hbelusca(a)svn.reactos.org wrote: > + > + /* > + * Check whether we actually just retrieved the needed buffer size > + * because our previous local allocation did fail. If so, allocate > + * a new buffer and retry again. > + */ > + if ( (!UnicodeQuerySet) && (*lpdwBufferLength >= sizeof(WSAQUERYSETW)) && > + (ErrorCode == SOCKET_ERROR) && (GetLastError() == WSAEFAULT) ) Seems like you'd want to check WSAGetLastError when looking for WSA* error codes. > + { > + /* Allocate the buffer we'll use */ > + UnicodeQuerySet = HeapAlloc(WsSockHeap, 0, UnicodeQuerySetSize); > + if (UnicodeQuerySet) > + { > + /* Call the Unicode Function */ > + ErrorCode = WSALookupServiceNextW(hLookup, > + dwControlFlags, > + &UnicodeQuerySetSize, > + UnicodeQuerySet); > + } > + /* > + * Otherwise the allocation failed and we > + * fall back into the error checks below. > + */ > + } > + > if (ErrorCode == ERROR_SUCCESS) > { > - /* Not convert to ANSI */ > + /* Now convert back to ANSI */ > ErrorCode = MapUnicodeQuerySetToAnsi(UnicodeQuerySet, > lpdwBufferLength, > lpqsResults); > - if (ErrorCode != ERROR_SUCCESS) SetLastError(ErrorCode); > + if (ErrorCode != ERROR_SUCCESS) > + SetLastError(ErrorCode); > } > else > { > @@ -499,10 +542,11 @@ > } > > /* If we had a local buffer, free it */ > - if (UnicodeQuerySet) HeapFree(WsSockHeap, 0, UnicodeQuerySet); > + if (UnicodeQuerySet) > + HeapFree(WsSockHeap, 0, UnicodeQuerySet); HeapFree(NULL) is fine by the way. > > /* Return to caller */ > - return ErrorCode == ERROR_SUCCESS ? ErrorCode : SOCKET_ERROR; > + return (ErrorCode == ERROR_SUCCESS) ? ErrorCode : SOCKET_ERROR; > }

2 1

Re: [ros-dev] [ros-diffs] [ekohl] 74054: [NTOS:OB] Create a custom security descriptor for the global DosDevices directory.
by Thomas Faber 04 Mar '17

04 Mar '17

On 2017-03-04 17:02, ekohl(a)svn.reactos.org wrote: > + Dacl = ExAllocatePool(PagedPool, AclLength); Would you mind using ExAllocatePoolWithTag for new code please, with no exceptions? (I want to #define ExAllocatePool do_not_use_this_function at some point) Thanks! -Thomas

2 1

Re: [ros-dev] [ros-diffs] [hbelusca] 73895: [NTGDI]: Few fixes & hacks for NtGdiGetGlyphIndicesW, see CORE-12825: - (Fix) Check for integer count overflow (per Thomas suggestion), - (Hack#1) Signal the particular calling ca...
by Thomas Faber 03 Mar '17

03 Mar '17

On 2017-02-24 02:52, hbelusca(a)svn.reactos.org wrote: > @@ -4419,12 +4422,31 @@ > LPCWSTR UnSafepwc = pwc; > LPWORD UnSafepgi = pgi; > > - if ((!UnSafepwc) && (!UnSafepgi)) return cwc; > - > - if ((UnSafepwc == NULL) || (UnSafepgi == NULL)) > + /* Check for integer overflow */ > + if (cwc & 0x80000000) // (INT_MAX + 1) == INT_MIN > + return GDI_ERROR; > + > + if (!UnSafepwc && !UnSafepgi) > + return cwc; > + > + if (!UnSafepwc || !UnSafepgi) > { > DPRINT1("UnSafepwc == %p, UnSafepgi = %p\n", UnSafepwc, UnSafepgi); > - return -1; > + return GDI_ERROR; > + } > + > + // TODO: Special undocumented case! > + if (!pwc && !pgi && (cwc == 0)) Why the sudden switch away from using the Unsafe version? > + { > + DPRINT1("ERR: NtGdiGetGlyphIndicesW with (!pwc && !pgi && (cwc == 0)) is UNIMPLEMENTED!\n"); > + return 0; > + } > + > + // FIXME: This is a hack!! (triggered by e.g. Word 2010). See CORE-12825 > + if (cwc == 0) > + { > + DPRINT1("ERR: NtGdiGetGlyphIndicesW with (cwc == 0) is UNIMPLEMENTED!\n"); > + return GDI_ERROR; > } > > dc = DC_LockDc(hdc); > >

3 2

Retiring rapps
by Mark Jansen 02 Mar '17

02 Mar '17

Hello, Soon (tm) we will be retiring rapps in favor of rapps_new. If you have any local patches in these regions, now is the time to step forward (and convert them to rapps_new!). regards, Mark Jansen

1 0

ReactOS is participating in Google Summer of Code 2017
by Colin Finck 27 Feb '17

27 Feb '17

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

5 4

Re: [ros-dev] [ros-diffs] [akhaldi] 73929: [CABINET] Sync with Wine Staging 2.2. CORE-12823 a663fe94 cabinet:
by Ged Murphy 26 Feb '17

26 Feb '17

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

1 0

Re: [ros-dev] Microsoft switched to Git
by Alex Ionescu 25 Feb '17

25 Feb '17

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

2 1

freetype.c related
by katahiromz . 24 Feb '17

24 Feb '17

That patched result has "OUT OF PAGED POOL" errors. Is the cache too large? Or are there any leaks?

1 0

Status Meeting (February 2017)
by Aleksey Bragin 23 Feb '17

23 Feb '17

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

2 1

Office (Excel, Word...) 2010 on ReactOS
by Hermès BÉLUSCA-MAÏTO 22 Feb '17

22 Feb '17

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

7 15

[ros-diffs] [gadamopoulos] 73871: [COMCTL32]: Copy button.c from user32, make the needed changes to make it compile and register it. This is the beginning of the v6 button. Remove the subclassing of the builti...
by James Tabor 22 Feb '17

22 Feb '17

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!

2 2

JIRA/FishEye upgrade this weekend
by Colin Finck 19 Feb '17

19 Feb '17

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

4 5

Re: [ros-dev] Microsoft switched to Git
by Alex Ionescu 16 Feb '17

16 Feb '17

.... 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 >

3 2

CLT 2017, we will join ^^
by Daniel Reimer 16 Feb '17

16 Feb '17

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

1 0

Re: [ros-dev] Microsoft switched to Git
by Alex Ionescu 16 Feb '17

16 Feb '17

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

4 3

Re: [ros-dev] Microsoft switched to Git
by Alex Ionescu 16 Feb '17

16 Feb '17

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 >

6 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev