Electronics > FPGA
Arrow DECA MAX 10 board for $37
SiliconWizard:
I'm glad your design is so good that it doesn't need any improvement and wouldn't benefit from any outside contribution. ;D
asmi:
--- Quote from: SiliconWizard on November 06, 2021, 05:38:39 pm ---At this point, I'll certainly report back in Brian's github project rather than start my own fork.
--- End quote ---
And when you will do that, you will realize that you have to fork to do anything because that's how git works ;D
SiliconWizard:
--- Quote from: asmi on November 11, 2021, 03:53:23 am ---
--- Quote from: SiliconWizard on November 06, 2021, 05:38:39 pm ---At this point, I'll certainly report back in Brian's github project rather than start my own fork.
--- End quote ---
And when you will do that, you will realize that you have to fork to do anything because that's how git works ;D
--- End quote ---
Absolutely not. Not only it's not the way git works, but git itself has no concept of a fork.
You could have said "that's how github works", which would have been already a little less wrong, because that's github that actually introduced forking as a collaborative model, which it never was before, since "forking" was definitely not about collaborating per se, but creating, you guessed it... forks. Derivatives of projects going in different directions, essentially.
But even if github has "promoted" this fork model, it's not even the only way of using github, and as I explained, I find this model has more drawbacks than benefits, and gave reasons why.
Just for starters: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models
As already discussed, I favor asking to be a collaborator if you have anything interesting to contribute - and then of course if the maintainer refuses or doesn't respond, forking as a second intention would make sense. Not as a first. Otherwise if it's just for personal use, just clone the repo locally and play with it.
Now I get it that many people have been first exposed to git - and even more generally to VCS - using github, but github is not git. And github, IMO, gives bad habits, including this frantic forking and using a VCS as a backup. The fact it's now owned by MS hasn't helped me having a better impression of it either, but that was just icing on the cake.
asmi:
--- Quote from: SiliconWizard on November 12, 2021, 05:12:07 pm ---Absolutely not. Not only it's not the way git works, but git itself has no concept of a fork.
You could have said "that's how github works", which would have been already a little less wrong, because that's github that actually introduced forking as a collaborative model, which it never was before, since "forking" was definitely not about collaborating per se, but creating, you guessed it... forks. Derivatives of projects going in different directions, essentially.
But even if github has "promoted" this fork model, it's not even the only way of using github, and as I explained, I find this model has more drawbacks than benefits, and gave reasons why.
Just for starters: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models
As already discussed, I favor asking to be a collaborator if you have anything interesting to contribute - and then of course if the maintainer refuses or doesn't respond, forking as a second intention would make sense. Not as a first. Otherwise if it's just for personal use, just clone the repo locally and play with it.
Now I get it that many people have been first exposed to git - and even more generally to VCS - using github, but github is not git. And github, IMO, gives bad habits, including this frantic forking and using a VCS as a backup. The fact it's now owned by MS hasn't helped me having a better impression of it either, but that was just icing on the cake.
--- End quote ---
You just don't understand how git works. The entire point of git (and one of it's chief advantages over legacy SC like SVN et al) is that forks are very easy and lightweight. So the way you are supposed to work with it is as follows: you have a single master branch which contains a stable version, and for each change you create a separate fork, implement the change in fork, test it, and once it's ready, you merge it back into the master branch. Advantages of this approach are that 1) every developer always have a stable codebase when he/she begins working on a change, and if that change will turn out to be the dead end, you just leave it as is and don't merge it back, 2) each developer can work independently of each other (because of distributed nature of git), and 3) you can cherrypick which changes are going to be released (this is typically implemented by having additional "release" branch which devops people use for actual deployment).
This is how git is designed to be used, and so this is how it SHOULD be used. If you don't use it this way - you are doing it WRONG. This has absolutely nothing to do with Github (or BitBucket, or others) - they merely implemented a GUI around git (and it's actually pretty thin layer above it - most of functionality you see on Github et al is provided by the git itself.
Incidentally, lightweight forks is exactly why git has been so wildly successful in huge projects like Linux kernel with thousands of developers working on it.
SiliconWizard:
Sure, lecture me on how DVCS work, it was obvious I didn't know.
The workflow you implement on top of DVCS, including how you manage branches, is completely context-dependent. No two organizations have the same approaches. You are probably confusing forking, branching and clones. Interestingly, excessive branching itself now tends to be considered less than ideal, but it again all depends on a team's specific workflow. There isn't just one.
The github link I gave shortly explains the two approaches you can use, and I explained numerous times why I favor the collaborator approach to the fork approach UNLESS you have a good reason to do it with forks. I have given my main reasons, which seem to be consistently ignored. Good, I just hope at least a few people have gotten my points. For the others, I don't care. And I have used DVCS for years, thank you. Using the collaborator model doesn't mean that you're not using git as a distributed system either. DVCS have a number of benefits over centralized systems even when not "forking". But I think the term "fork" has been largely abused here.
Again, while forking can be alright if you're actually working on say a feature that is far from being ready, that may not get accepted in the mainline for months, and, most of all, that several developers may work on in parallel, if it's just a convenience as a personal backup or even just as a sort of bookmark (as we said earlier), this just dilutes projects. The more forks, and the more the dilution - this point has nothing subjective about it, it's not opinion, it's just mechanically inevitable. And unfortunately, those cases seem to be the norm rather than the exception on github. This goes hand in hand with the excessive use, IMHO, of "cloud" storage as well. I haven't seen recent figures, but the ones I saw from a couple years ago showed a lot more forks than pull requests, and even fewer merges. That may raise a few questions about the efficiency of it all. And yes, it's probably obvious by now that I don't like github much. And that yes, you can absolutely use git or other DCVS on your own organization's terms, on your own servers, without breaking the spirit of DVCS.
Oh and a final thought related to this discussion. The most successful open-source projects have pretty much all used a form of vertical organization - the Linux kernel being a prime example - which is likely how they could become successful in the end. As Linux shows, the use of a DVCS is absolutely not contradictory to having some amount of vertical project management, and is still quite useful in this setting. Github, while promoting, whether they want it or not, the dilution of open-source projects, hinders vertical project management. Not saying it prevents it, but it makes it unnecessarily harder. Now, what happens, to be honest, is that many of the successful projects, even when they have a github repo, are primarily managed outside of github. And to get back to Brian here, even if it's a small project, what I've seen so far is that it's what he does. (IIRC, he has even stated on his github page to use this forum for any communication... ;D )
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version