Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Upcoming OSR Seminars:

Writing WDF Drivers I: Core Concepts, Nashua, NH 15-19 May, 2017
Writing WDF Drivers II: Advanced Implementation Tech., Nashua, NH 23-26 May, 2017
Kernel Debugging and Crash Analysis, Dulles, VA 26-30 June, 2017
Windows Internals & Software Driver Development, Nashua, NH 24-28 July, 2017


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 17  
18 Mar 17 16:14
Jamey Kirby
xxxxxx@gmail.com
Join Date: 31 Dec 2014
Posts To This List: 158
Re: OT: git or hg? Why?

Git all the way. You can use GitHub, GitLab, or host your own GitLab. On Sat, Mar 18, 2017 at 3:16 PM <xxxxx@hollistech.com> wrote: > well that is actually a ridiculous question. mercurial is a dead end. It > has been superseded by git. hg would be an imposed legacy code base > requirement, like the awful p4, not a choice. > > In other words: use the git, luke. > > Oh and git is pretty fabulous, although it does take a while to git the > hang of it. Plus there are a wealth of resources out there for hosting your > repos in the cloud, for hosting them internally, of integrating your SCCS > with code review, bug tracking, agile development, automated building and <...excess quoted lines suppressed...> --
  Message 2 of 17  
19 Mar 17 15:03
Jamey Kirby
xxxxxx@gmail.com
Join Date: 31 Dec 2014
Posts To This List: 158
Re: OT: git or hg? Why?

I've used P4, and I must say, I liked it very much. But distributed is the new way. One of my clients uses SVN, and I despise using it. Even with the shell add-ons, it still sucks. Git has a learning curve; no doubt. It requires you to think about things a little differently. But, it is the global standard now, and knowing, and using it is probably a good idea. -- Jamey On Sun, Mar 19, 2017 at 1:52 PM <xxxxx@fastmail.fm> wrote: > >I just read a quote that called hg "the Betamax of DVCSs" which I liked... > > > >P > > From what I remember... Mercurial was started as a backup plan in case > things will go awry with git. People were once scared by the GPL. Managers > believed that GPL can jump out of the git, infect all their dear > proprietary software, and crazy things would break out. > > The world has changed a lot since then, crazy things indeed broke out - <...excess quoted lines suppressed...> --
  Message 3 of 17  
19 Mar 17 15:21
Prokash Sinha
xxxxxx@garlic.com
Join Date: 23 Feb 2000
Posts To This List: 1063
Re: OT: git or hg? Why?

I???ve used quite a few like many others. Perforce at command line is not intuitive, so is clear case. For GIT, it could be difficult to use from command line. Yeah it is distributed and the background was open source developers are distributed, and keeping track of changes was difficult from single point server when a change in comment could create a transaction that needs server???s attention. Also when some shops customized for having review process before checked in code ( the process has definite merits ) but the workflow gets in your way w/o warnings. So that leads to command line interference to coerce GIT/Perforce etc. In the past when I started using SVN switching from CVS I had at the same feeling - I GUESS, developers don???t want to be bothered too much about innards of these systems, and that is at least my mindset. BitKeeper was not distributed, and was on its way to commercialize. that is when GIT effort started. It is not a brand new idea though. Someone in NZ had it chalked out the plan and a prototype before GIT was born. If a source control systems have hundreds of commands, it is not for me. GUI based intuitive clients are all I depend on. GIT has few flavors like P4. But distributed management helps the repository it makes the merging quite bit more difficult if some one stays on her local cloned repository. -pro > On Mar 19, 2017, at 12:03 PM, Jamey Kirby <xxxxx@gmail.com> wrote: > > I've used P4, and I must say, I liked it very much. But distributed is the new way. One of my clients uses SVN, and I despise using it. Even with the shell add-ons, it still sucks. > > Git has a learning curve; no doubt. It requires you to think about things a little differently. But, it is the global standard now, and knowing, and using it is probably a good idea. > > -- Jamey > > > On Sun, Mar 19, 2017 at 1:52 PM <xxxxx@fastmail.fm <mailto:xxxxx@fastmail.fm>> wrote: <...excess quoted lines suppressed...> --
  Message 4 of 17  
19 Mar 17 19:39
Jamey Kirby
xxxxxx@gmail.com
Join Date: 31 Dec 2014
Posts To This List: 158
Re: OT: git or hg? Why?

Excellent writeup Jan. I'll buy one. Can I get two? On Sun, Mar 19, 2017, 6:54 PM Jan Bottorff <xxxxx@pmatrix.com> wrote: > I use a git friend, SourceTree. It???s free, it???s awesome, and if you need > to integrate to a real project management system you can purchase Jira. > > An incredibly better architectural feature of git (and friends) is file > identity is tracked based on content (a hash) not a filename. This means > you can take a tree of files, move them around, rename them, and do a > commit, and git perfectly keeps the history of each file. Lots of version > control systems handle file renames/directory structure changes poorly. In > git, the directory structure is more an attribute of a commit. This also > means you get almost perfect deduplication of identical files. <...excess quoted lines suppressed...> --
  Message 5 of 17  
20 Mar 17 08:36
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 3928
Re: OT: git or hg? Why?

That is because you are confusing commits to your local repo with commits to origin. If you use one of the well thought out git workflows, all of your development is in feature branches on local developer repos, the commit history of those feature branches is generally of interest only to the developer, and the developer should be free to amend or squash those commits as appropriate. What is of interest to everyone else beside the developer is the merge request for that feature branch into one of the mainline branches on origin (typically master or develop depending on which workflow you are using.) That merge request should be as clean as possible. Nobody else really cares about the detours and missteps in the commit history of your local repo's feature branch that got you to the point where you are ready to push your changes, they care about the diffs between your feature branch and its target branch. If you are mucking with the commit history of origin branches you are doing something dreadfully wrong. Mark Roddy On Sun, Mar 19, 2017 at 11:49 PM, <xxxxx@osr.com> wrote: > Love your write-up, Jan. Thanks. > > About this, though: > > <quote> > It?s sometimes a little annoying that I can?t fix a typo in a previous > commit > comment, but that?s just part of the architecture than assures repository > integrity, so I have accepted it > </quite> <...excess quoted lines suppressed...> --
  Message 6 of 17  
20 Mar 17 14:29
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11354
Re: OT: git or hg? Why?

Mark Roddy wrote: > That is because you are confusing commits to your local repo with > commits to origin. If you use one of the well thought out git > workflows, all of your development is in feature branches on local > developer repos, the commit history of those feature branches is > generally of interest only to the developer, and the developer should > be free to amend or squash those commits as appropriate. What is of > interest to everyone else beside the developer is the merge request > for that feature branch into one of the mainline branches on origin > (typically master or develop depending on which workflow you are > using.) That merge request should be as clean as possible. Nobody else <...excess quoted lines suppressed...> That, sir, is a matter of opinion on which developers most certainly do not agree. There is incredibly valuable historical information contained in the "detours and missteps in the commit history", and the philosophy that those detours do not belong in the global history is, in my opinion, misguided. A year from now, when an unrelated developer asks "why did you do that?" and the original developer is gone, there may be no way to answer that question. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 7 of 17  
20 Mar 17 16:49
Alex Grig
xxxxxx@broadcom.com
Join Date: 14 Apr 2008
Posts To This List: 3164
Re: OT: git or hg? Why?

"There is incredibly valuable historical information contained in the "detours and missteps in the commit history", and the philosophy that those detours do not belong in the global history is, in my opinion, misguided. A year from now, when an unrelated developer asks "why did you do that?" and the original developer is gone, there may be no way to answer that question." This statement will be only supported for those programmers who supplement version control with #ifdefs. Why delete dead code when we can #ifdef it out? Or have two versions of a function "before" and "after", and to hell with diff.
  Message 8 of 17  
20 Mar 17 19:13
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 3928
Re: OT: git or hg? Why?

Well of course you could insist that no developer ever amend or squash any commits on their feature branches. You could also insist that they commit every change they make to their feature branch, no matter how trivial, stupid, misguided or irrelevant, on the off chance that searching the entrails of their development efforts might contained this alleged buried treasure. Or you could consider feature branch merge requests as what is of interest. Those merge requests should of course be code reviewed and if it is a complete f'ing mystery how the developer got to the particular solution they came up with, an explanation should be recorded in the review. Since you are using git with all of its quite nice server side enhancements from gitlab or bitbucket or other vendors for automated and integrated code review and issue tracking, all of that information will be recorded with the merge request. I think there is a lot of historical baggage in the words "commit" and "branch" and "merge" that confuse people when they first start using git. It certainly confused me for a while. In the central repo model all commits were sacred, branches were rare and merges were nightmares. In git branching and merging are commonplace. Commits are always local not global, until they are pushed upstream. If you are pushing commits directly to your main branches, you are doing it wrong. You should be using feature branches. Feature branches are short lived - days not weeks or months, they encapsulate a single bug fix, or work for one story in an iteration. The interesting history is in the merge of that feature branch back into the development main branch, not in the edits the developer made along the way. Mark Roddy On Mon, Mar 20, 2017 at 2:28 PM, Tim Roberts <xxxxx@probo.com> wrote: > Mark Roddy wrote: > > That is because you are confusing commits to your local repo with > > commits to origin. If you use one of the well thought out git > > workflows, all of your development is in feature branches on local > > developer repos, the commit history of those feature branches is > > generally of interest only to the developer, and the developer should > > be free to amend or squash those commits as appropriate. What is of > > interest to everyone else beside the developer is the merge request > > for that feature branch into one of the mainline branches on origin > > (typically master or develop depending on which workflow you are <...excess quoted lines suppressed...> --
  Message 9 of 17  
20 Mar 17 20:35
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5803
List Moderator
Re: OT: git or hg? Why?

<quote> The interesting history is in the merge of that feature branch back into the development main branch, not in the edits the developer made along the way. </quote> You've made a very well-reasoned case. This case even makes "rebase" sound like something that's not inherently evil. I appreciate the time you put into those two replies. I'm not saying I'm convinced. I'm just saying I find your argument strangely enlightening. Peter OSR @OSRDrivers
  Message 10 of 17  
20 Mar 17 20:54
M M
xxxxxx@hotmail.com
Join Date: 21 Oct 2010
Posts To This List: 684
Re: OT: git or hg? Why?

Thinking in the paradigm is key to successful use of any of these tools. I?m note sure that I like the git paradigm, but it seems inevitable that it will be a fact of life in the same way that G3 OO languages are a fact of life regardless of what one thinks about their design principals. Agreement as to which method is the best will be as elusive as in the C vs C++ debates I think Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: Mark Roddy<mailto:xxxxx@hollistech.com> Sent: March 20, 2017 7:13 PM To: Windows System Software Devs Interest List<mailto:xxxxx@lists.osr.com> Subject: Re: [ntdev] OT: git or hg? Why? Well of course you could insist that no developer ever amend or squash any commits on their feature branches. You could also insist that they commit every change they make to their feature branch, no matter how trivial, stupid, misguided or irrelevant, on the off chance that searching the entrails of their development efforts might contained this alleged buried treasure. Or you could consider feature branch merge requests as what is of interest. Those merge requests should of course be code reviewed and if it is a complete f'ing mystery how the developer got to the particular solution they came up with, an explanation should be recorded in the review. Since you are using git with all of its quite nice server side enhancements from gitlab or bitbucket or other vendors for automated and integrated code review and issue tracking, all of that information will be recorded with the merge request. I think there is a lot of historical baggage in the words "commit" and "branch" and "merge" that confuse people when they first start using git. It certainly confused me for a while. In the central repo model all commits were sacred, branches were rare and merges were nightmares. In git branching and merging are commonplace. Commits are always local not global, until they are pushed upstream. If you are pushing commits directly to your main branches, you are doing it wrong. You should be using feature branches. Feature branches are short lived - days not weeks or months, they encapsulate a single bug fix, or work for one story in an iteration. The interesting history is in the merge of that feature branch back into the development main branch, not in the edits the developer made along the way. Mark Roddy On Mon, Mar 20, 2017 at 2:28 PM, Tim Roberts <xxxxx@probo.com<mailto:xxxxx@probo.com>> wrote: Mark Roddy wrote: > That is because you are confusing commits to your local repo with > commits to origin. If you use one of the well thought out git > workflows, all of your development is in feature branches on local > developer repos, the commit history of those feature branches is > generally of interest only to the developer, and the developer should > be free to amend or squash those commits as appropriate. What is of > interest to everyone else beside the developer is the merge request > for that feature branch into one of the mainline branches on origin > (typically master or develop depending on which workflow you are > using.) That merge request should be as clean as possible. Nobody else <...excess quoted lines suppressed...> That, sir, is a matter of opinion on which developers most certainly do not agree. There is incredibly valuable historical information contained in the "detours and missteps in the commit history", and the philosophy that those detours do not belong in the global history is, in my opinion, misguided. A year from now, when an unrelated developer asks "why did you do that?" and the original developer is gone, there may be no way to answer that question. -- Tim Roberts, xxxxx@probo.com<mailto:xxxxx@probo.com> Providenza & Boekelheide, Inc. --- NTDEV is sponsored by OSR Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer> --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at --
  Message 11 of 17  
20 Mar 17 21:05
mm
xxxxxx@gmail.com
Join Date: 24 May 2010
Posts To This List: 965
Re: OT: git or hg? Why?

Rebase is all what you make of it, git's greatest strength or weakness, depending on what you do with it. I agree with Mark about the distributed model making some traditional practices around branches et c. not important at best and problematic at worst. At least I think that's what he's saying. Nobody except the dev who wrote the commits in a feature branch will ever care or likely even understand them once they're pushed - squash them before you push. If you use git like a centralized source control system, the flexibility it provides will seem pointless and overly complicated, IMO. The two things I would suggest anyone considering git do before they run with it (aside from consider integration & plug-ins, which will always favor git these days) is reverting a complicated merge, after you push it, then make some more changes and remerge; and understand the problems with rebasing work others have consumed. Those are the two git issues that most people encounter, IMO. Neither is complicated, just different. mm On Mar 20, 2017 5:36 PM, <xxxxx@osr.com> wrote: > <quote> > The interesting history is in the merge of that feature branch back into > the > development main branch, not in the edits the developer made along the way. > </quote> > > You've made a very well-reasoned case. This case even makes "rebase" sound > like something that's not inherently evil. > > I appreciate the time you put into those two replies. <...excess quoted lines suppressed...> --
  Message 12 of 17  
21 Mar 17 06:49
David Boyce
xxxxxx@becrypt.com
Join Date: 19 Mar 2015
Posts To This List: 60
Re: OT: git or hg? Why?

xxxxx@broadcom.com wrote: > Why delete dead code when we can #ifdef it out? Sometimes there is no option but to delete it. Code evaluators hate dead code, and regard "#if 0" and "#ifdef NEVER_DEFINED" as terminal code damage.=20 --
  Message 13 of 17  
21 Mar 17 08:17
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5803
List Moderator
Re: OT: git or hg? Why?

<quote> Sometimes there is no option but to delete it. </quote> Seems that Mr. Boyce missed the implied <sarcasm> tag around Mr Grig's description of some programmer's approach. <aside> The whole "#if it out until we know it works" thing, is the mark of sloppy engineering, when this code is pushed up to mainline. We had (past tense) an engineer here who loved this model... and his code was rife with it. It's demonstrates a lack of confidence and lack of knowledge. Maybe you do it while you're testing a dramatic change packed along with other changes, in something that can only be fully tested with a ton of other components, and thus you HAVE to push it into the mainline. But for goodness sakes, get it out of the checked-in code as soon as possible. Better, test the code with the change before the push. Wait... I think I just saw a good reason for rebase: #if out old code on my dev machine in my branch, write new function, check-in locally... test new function and decide old dead code can be removed, remove the #if'ed out code, check-in new code... rebase to remove the intermediate check-in which provides no useful historical info. "Think different" </aside> Peter OSR OSRDrivers
  Message 14 of 17  
21 Mar 17 22:00
Alex Grig
xxxxxx@broadcom.com
Join Date: 14 Apr 2008
Posts To This List: 3164
Re: OT: git or hg? Why?

Rebase is the greatest thing since sliced bread. When I do a feature or a fix, it may require long time to finish, and during that time the codebase may advance a lot. A fix is usually a single commit, anyway. A feature could include multiple commits. Before I push the result, I rebase it on current top. Any merge conflicts are fixed for each commit in the chain. Each commit compiles. Also, if I encounter any drive-by fixes and/or improvements, each goes to a separate commit. "git add -p <file>" command is a great tool to separate chaffs from wheats. Do you know you can selectively apply a diff from another version of a file to the working copy by "checkout -p" command?
  Message 15 of 17  
Yesterday 12:53
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 3928
Re: OT: git or hg? Why?

indeed - you own your local commits. They are for your use. You own your local branches too, they have no existence on the server until you push that branch up to the server. It becomes of interest when you choose to make it available on your server. I could go on. What makes all of this git shit very interesting is what has happened in terms of CI tools on the server side. By using feature branch workflows (and there are of course many) you can plug your development processes directly into the CI pipelines tools now available from both bitbucket and gitlab/hub. (bitbucket seems to be the me-too here, gitlab innovates, bitbucket adopts.) For example, what we did with our projects on our gitlab server is to plug feature branches into a pipeline that performs automated validation testing on every push, and that requires that to pass and for code review to be complete before that branch can be merged into one of the main branches. The main branches themselves are of course running automated and comprehensive build testing on every new commit. Mark Roddy On Tue, Mar 21, 2017 at 8:18 AM, <xxxxx@osr.com> wrote: > <quote> > Sometimes there is no option but to delete it. > </quote> > > Seems that Mr. Boyce missed the implied <sarcasm> tag around Mr Grig's > description of some programmer's approach. > > <aside> > The whole "#if it out until we know it works" thing, is the mark of sloppy > engineering, when this code is pushed up to mainline. We had (past tense) <...excess quoted lines suppressed...> --
  Message 16 of 17  
Yesterday 14:42
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5803
List Moderator
Re: OT: git or hg? Why?

<quote> bitbucket and gitlab/hub </quote> Ugh. This could easily and quickly turn into a debate of the cost/benefit of particular hosting services. Which would by necessity, in turn become a debate about bug tracking software. Which would rapidly devolve into a debate about agile methodology, kanban boards, HipChat, and other forms of foolishness (he said, choosing the nicest possible word he could think of). Which would very quickly result in me filling my posts with curse words and locking the thread. So, I'm not going there. <quote> What makes all of this git shit very interesting is what has happened in terms of CI tools on the server side. </quote> OK... On a more positive note: Let's hear it for Jenkins! The actual logistics depends on your workflow. Right now, we're looking at pushing to a build server that'll trigger the build, CA, and tests... including pushing tests off onto target hardware platforms. Then, assuming tests all pass, have the build server push the results to our origin. We are, ahem, "quite far" from making that happen. As in "we don't have the build server provisioned yet." But, let's ignore the details. What would be helpful to the community as a whole would be for somebody to provision a Windows VM with Jenkins and the EWDK, and some tools to allow the basic driver tests to run (like, for example, devfund) and make this work available to the community. Too many people in this space work in their own little worlds and never share. It's always been that way in the world of drivers. I've never understood it. Perhaps the community is has the same percentage of "people who share" as other communities, but suffers because it's factors of magnitude smaller. Peter OSR @OSRDrivers
  Message 17 of 17  
Yesterday 20:51
M M
xxxxxx@hotmail.com
Join Date: 21 Oct 2010
Posts To This List: 684
Re: OT: git or hg? Why?

You are worried about people who never share in the driver community? Welcome to the financial industry where each firm generally believes that they have specific and compelling unique knowledge. This belief is not generally based on any fact, and certainly not on any education, buy usually based on the need to eat by scraping pennies off of someone else?s boots Re your specific problem, if you contact me offline, I can probably arrange something that might work for al of us. I must put it on record that I abhor the kaban board and all the foolishness that goes with it Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: xxxxx@osr.com<mailto:xxxxx@osr.com> Sent: March 22, 2017 2:42 PM To: Windows System Software Devs Interest List<mailto:xxxxx@lists.osr.com> Subject: RE:[ntdev] Re: OT: git or hg? Why? <quote> bitbucket and gitlab/hub </quote> Ugh. This could easily and quickly turn into a debate of the cost/benefit of particular hosting services. Which would by necessity, in turn become a debate about bug tracking software. Which would rapidly devolve into a debate about agile methodology, kanban boards, HipChat, and other forms of foolishness (he said, choosing the nicest possible word he could think of). Which would very quickly result in me filling my posts with curse words and locking the thread. So, I'm not going there. <quote> What makes all of this git shit very interesting is what has happened in terms of CI tools on the server side. </quote> OK... On a more positive note: Let's hear it for Jenkins! The actual logistics depends on your workflow. Right now, we're looking at pushing to a build server that'll trigger the build, CA, and tests... including pushing tests off onto target hardware platforms. Then, assuming tests all pass, have the build server push the results to our origin. We are, ahem, "quite far" from making that happen. As in "we don't have the build server provisioned yet." But, let's ignore the details. What would be helpful to the community as a whole would be for somebody to provision a Windows VM with Jenkins and the EWDK, and some tools to allow the basic driver tests to run (like, for example, devfund) and make this work available to the community. Too many people in this space work in their own little worlds and never share. It's always been that way in the world of drivers. I've never understood it. Perhaps the community is has the same percentage of "people who share" as other communities, but suffers because it's factors of magnitude smaller. Peter OSR @OSRDrivers --- NTDEV is sponsored by OSR Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer> --
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 00:25.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license