Electronics > FPGA

Arrow DECA MAX 10 board for $37

<< < (36/39) > >>

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 )

asmi:

--- Quote from: SiliconWizard on November 12, 2021, 11:56:34 pm ---Sure, lecture me on how DVCS work, it was obvious I didn't know.
--- End quote ---
Yes, that much was obvious...


--- Quote from: SiliconWizard on November 12, 2021, 11:56:34 pm ---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.
--- End quote ---
...and so is the fact that you don't use it properly. When using git you stick to a "single branch/fork - single developer" approach, or you going to have massive headaches when several devs will constantly step on each other's toes.


--- Quote from: SiliconWizard on November 12, 2021, 11:56:34 pm ---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 )

--- End quote ---
Git was designed by Linus precisely for Linux, and each kernel dev always works in his own branch, and once a feature is implemented, there is a pull request (PR) to merge it back into the mainline, primary job of maintainers do is pick-and-choose which PRs to include into the release. And the exact same mechanism is used for accepting code from external entities for inclusion into the mainline (for example, this is how RISC-V and ARM support was added into the mainline).

So yeah, forks are the norm in git, not exception nor any sort of insult or whatever other nonsense you fantasized. With that, I think this discussion is over.

SiliconWizard:
So yes, it's obvious I don't know. Sure. Looks impossible to have a different view on some topics, in particular anything related to software development, the discussions of which often end up very badly. I'm not surprised. You can absolutely disagree with me and find my concerns invalid or at least largely exxagerated, no problem. Claiming I don't know how a DVCS work is something else. Thanks for the smile =)

It's also obvious you didn't address most of the points I made, nor cared to understand them. That's possibly actually mainly due to how the term "fork" is abused here, although I tried explaining what my concerns were, and how making forked projects *public*, as with github, was NOT quite the same thing as each developer working on their own repo, because it precisely promotes project dilution - diluting the number of potential users and contributors to several instances of the same project, which is a concern that I'm far from being the only one to have expressed, and while you can indeed perfectly do so using DVCSs, there are myriads of ways to use them with different workflows. Not to talk about closed-source projects for which DVCSs are also used a lot these days. There are a ton of different workflows, very few of them including each developer in a team having their own forked *repo* on a (or several) shared server(s). A branch is not a complete forked repo. Dunno - I get the impression you absolutely see no difference. Again, git as no concept of fork by itself. All it has are clones and branches. Even a cloned repo is a slightly different beast from a fork (as in github and gitlab), which they themselves explain if you care to read the docs. But I'm the one not knowing here.

As to my comment on excessive branching, this is also nothing new. In well managed projects, excessive branching is avoided - using the right workflows - because they can quickly make merges an untractable problem. That doesn't mean DVCSs are not appropriate. Not at all. It's all about structuring things a bit instead of pure anarchy.

I still stand by the opinion that Github tends to promote bad use of git and VCS in general because it's used a lot as *cloud storage* rather than a truly collaborative tool. Small projects are likely to be more affected than the big ones, for which users will naturally tend to flock to the repo that has the most activity. I've seen some stats showing that a large majority of forks on github were just dead beef. I prefer personal dead beef on personal computers rather than being public and polluting projects. I'm not just saying that in theory. I've seen a lot of projects, some I'm interested int, being diluted this way and thus harder to contribute to or even use. I doubt I'm the only one.

Again, everyone working on their own branch and having multiple *public* forks of a project are two different things, which you apparently don't want to acknowledge, good. Maintaining or contributing to a an open-source project takes some work and active collaboration, even if it's just to report bugs (which can be every bit as useful as contributing code, btw, and for which splitting reports on many different projects makes it all the harder to aggregate them. That was one of my point too.) Clicking on a "fork" button takes a split second, otoh.

As to the way the Linux project is handled - it definitely doesn't use git in the way that is common in Github, and has indeed a very specific workflow. It doesn't take anything from github. See what every pull request gets as answer: https://github.com/torvalds/linux/pull/805 . The github repo is read-only as they explain, but "funnily" enough, there are almost 40k forks. Not, Linus himself certainly doesn't use git the way that looks "usual" on github.

So yeah, I'll leave it at that, but just wanted to make my points clear. If they are still not, oh well.

BrianHG:
LOL, Arrow now has just received 2 more DECA boards in stock.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version