September 09, 2018 Re: Source changes should include date of change | ||||
---|---|---|---|---|
| ||||
Posted in reply to Neia Neutuladh | On Saturday, 8 September 2018 at 18:47:39 UTC, Neia Neutuladh wrote:
> On Saturday, 8 September 2018 at 06:59:28 UTC, Josphe Brigmo wrote:
>> Having source code that doesn't show changes with dates is pretty useless for diagnostics. I realize that git has the changes but the source code should.
>
> What problem did you encounter where you had trouble getting the information you needed with git blame, where a source code comment listing change dates would help?
>
>> Why not also add a link to the git hub patch
>
> Because that's a lot of work to replicate something git already does.
>
>> or bugzilla or whatever?
>
> Currently, some code in phobos does reference issues on the dlang bugzilla. The common categories for this include:
>
> * Explaining why we want things to work this way, if that requires more than a couple sentences of explanation
> * Pointing out what problem this is a workaround for
> * Pointing out which past problem motivated this unittest
>
> Things that help you understand the code as it currently is.
>
> Is there some situation you've encountered in the past where that kind of comment wasn't enough?
This has nothing to do with git. People think git is the end all be all. What if git is not available, then what? It's moronic to think that one has to use one or the other when both options are available and both only add information.
The same people that are saying use git used to say that git was overkill because it wasn't needed before it became popular. They are simply always looking for a way to justify their current belief. They think the world is black or white. They then pretend that a choice has to be made between two possibilities. e.g., either religion or science(but not both because they only have xor in their operations), either black or white. Either yes or no, either hot or cold, either this or that. They then go crazy when someone offers the other choice as a solution because they feel they will lose their safety blanket.
How hard would it be to automate dating for dmd source so that everything is consistent in a way that makes sense?
See, people rather blow off their bad leg just so they have one good leg rather than have a bad leg and a good leg.
"A false dilemma is a type of informal fallacy in which something is falsely claimed to be an "either/or" situation, when in fact there is at least one additional option. A false dilemma can arise intentionally, when a fallacy is used in an attempt to force a choice or outcome."
BTW, not every uses git and git is not always available so to say "You must use git" just sounds likes arrogant(of course, arrogant people don't think they are arrogant).
When I have to dive in to source code to find something, it helps to have some clue when the code was added. A clue is better than being in the dark, but as we know, some people just like to bury their head in the sand. For them, ignorance is bliss.
|
September 09, 2018 Re: Source changes should include date of change | ||||
---|---|---|---|---|
| ||||
Posted in reply to Josphe Brigmo | On Sunday, 9 September 2018 at 01:27:06 UTC, Josphe Brigmo wrote:
> How hard would it be to automate dating for dmd source so that everything is consistent in a way that makes sense?
Perhaps you could find out by trying to implement such a system? That's what I usually do.
You haven't described the problems you want to address in any detail, so you're the only one who knows what would make sense. That means you're the only person who could even hope to estimate the difficulty. Plus it would be a fair bit of work that nobody else seems that interested in, so unless you're offering to pay, you're the only one motivated to do the work.
But perhaps, if you presented your results, they would be interesting enough for others to adopt.
|
September 08, 2018 Re: Source changes should include date of change | ||||
---|---|---|---|---|
| ||||
Posted in reply to Josphe Brigmo | On 9/8/2018 4:29 AM, Josphe Brigmo wrote:
> Um, I didn't say don't use Git!
I've done this manually before git. I can guarantee you that the dates put in the file are invariably wrong, incomplete, or non-existent.
But if you bring up a source file in github, and click on the "Blame" button, it'll tell you, for every line in the source, which PR last changed that line.
|
September 09, 2018 Re: Source changes should include date of change | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Sunday, 9 September 2018 at 02:49:45 UTC, Walter Bright wrote:
> On 9/8/2018 4:29 AM, Josphe Brigmo wrote:
>> Um, I didn't say don't use Git!
>
> I've done this manually before git. I can guarantee you that the dates put in the file are invariably wrong, incomplete, or non-existent.
>
> But if you bring up a source file in github, and click on the "Blame" button, it'll tell you, for every line in the source, which PR last changed that line.
Yes, but if one has access to git then that is pointless.
Yes, dates go out of sync and are hard to maintain. THis is why it takes a more complex system to cover those issues property.
One wouldn't just include the date but other meta information that removes and reduces these problems that people complain about.
If git would automatically do the dates then one could download the source code. Git would be the central repository and if one wanted an offline version that had enough info in it such as the data a change was made, who changed it, the date the file was generated etc, then it would be better than having nothing.
To throw the baby out with the bath water is wrong.
Special comments could be used so they could easily be removed if desired along with any necessary information such as the library version, dates the code was changed, etc. No need to include everything. Some information is better than none, that is always the case. Data(knowledge) can't hurt you, only the lack of it.
The thing is, none of this shit hurts anything. Comments don't change programs so really it is just an issue about bloat and rot. The rot is covered by git hub automatically generating all the info(then it becomes no different than the problem of versioning with everything, want an update, just download it from git). The bloat is minimum and the bloat is precisely valid information(it's not like it is gibberish).
So, for people to pretend that this is evil and shouldn't be done just because they feel it is not as good as using git directly is really moronic. What they are saying is "Because git hub has it all we shouldn't go the extra step to provide partial information". But the problem with such logic is git up is not always available and not everyone wants to go that route. So, instead of a compromise these people want to enforce some absolute law that they imagined they can enforce(some people murder over such things, just to show you how bad it can get).
It's one thing to say that it shouldn't be done because no one thinks it's important(e.g., almost everyone uses git hub) and quite a different thing to dictate some fictitious authoritative dictator persona as if the dictator is god and knows everything.
30 years ago if asked most programmers about starting a git hub they would laugh at you and tell you it is not needed. The sad fact is that most people have no clue what is actually needed and what is good and what is bad. They just follow the asses in front of them, usually, eventually, over a cliff.
|
September 09, 2018 Re: Source changes should include date of change | ||||
---|---|---|---|---|
| ||||
Posted in reply to Neia Neutuladh | On Sunday, 9 September 2018 at 02:48:40 UTC, Neia Neutuladh wrote:
> On Sunday, 9 September 2018 at 01:27:06 UTC, Josphe Brigmo wrote:
>> How hard would it be to automate dating for dmd source so that everything is consistent in a way that makes sense?
>
> Perhaps you could find out by trying to implement such a system? That's what I usually do.
>
> You haven't described the problems you want to address in any detail, so you're the only one who knows what would make sense. That means you're the only person who could even hope to estimate the difficulty. Plus it would be a fair bit of work that nobody else seems that interested in, so unless you're offering to pay, you're the only one motivated to do the work.
>
> But perhaps, if you presented your results, they would be interesting enough for others to adopt.
Yes, but the fact is they would not appreciate my work because they do not appreciate it now. You might appreciate it but the fact is, people that bitch and complain about someone saying they have a problem with something and that "Do it my way attitude" are people who don't appreciate other peoples work, they only use it to further their own self.
So, since I don't have to implement it, and because it is not a huge problem, I won't. Screw the assholes who try to shut down people and progress just because they are assholes(and who have no good reasons). It's one thing to debate a topic to find the best solution and it's another to try to shut it down based on an irrelevant argument.
You know, not everything is complex:
What is proposed here does not change the source any one bit. It only adds to it. It is basically inheritance(or a product). It doesn't distort the code(e.g., map it to a random alphabet) nor does it introduce any bugs.
All it can do is add bloat. That is it!
So, what they are bitching about, really, is they don't want bloat. But they can't see that because they are only conformist and they don't want anything to interfere with them conforming.
But see, the problem with bloat is not necessary a problem. It is only a problem if the bloat is not useful. E.g., a class inheriting another class is adding bloat, so to speak.
So, the issue should be how much bloat, how to control the bloat, and how to make the bloat useful...
But guess what? No relevant discussion on these meaningful issues of the problem(the ones that, if they could be solved would solve the problem for everyone within reason) because they shut down the argument with there authoritative and mindless drivel.
So, no, I will not help out, it's obviously no one wants help. I do have to do a risk analysis assessment because it does cost me my time. What I see is that I won't invest it because I won't invest in people with such attitudes which further helps them along and only generally strengthens their attitudes(because it must be working, right?).
I will not play the shit slinging game. You or others will think I am slinging shit because I don't conform, but it's precisely why I am not slinging shit, because I am not conforming to the shit slingers. Of course, that assumes I am not a shit linger but it does prove that only one side slings shit. I let the historical record be my proof of who slings shit. They should be easy to spot because they have the smelly hands.
A question I propose to you is that if a shit slinger slings shit at someone and that person throws the shit back at the original shit slinger, are they too a shit slinger? If so, are they equally culpable?
|
September 09, 2018 Re: Source changes should include date of change | ||||
---|---|---|---|---|
| ||||
Posted in reply to Josphe Brigmo | On Sunday, 9 September 2018 at 04:37:48 UTC, Josphe Brigmo wrote:
> If git would automatically do the dates then one could download the source code. Git would be the central repository and if one wanted an offline version that had enough info in it such as the data a change was made, who changed it, the date the file was generated etc, then it would be better than having nothing.
>
> [...]
>
> The thing is, none of this shit hurts anything. Comments don't change programs so really it is just an issue about bloat and rot. The rot is covered by git hub automatically generating all the info(then it becomes no different than the problem of versioning with everything, want an update, just download it from git). The bloat is minimum and the bloat is precisely valid information(it's not like it is gibberish).
I think perhaps you are laboring under a severe misunderstanding of what git is, and how git and Github actually work.
Git is a version control system. It records historical snapshots ("commits") of a project, along with metadata like date and author, and lets you navigate between different versions. The collection of data and metadata saved by git for a particular project is called a "git repository".
Github is a website for hosting git repositories. When you download the dmd source code from Github using `git clone`, you receive a complete copy of the entire history of dmd, including both the commits themselves and the metadata associated with them.
That's why there's no need to add comments--all the data you want is already there, not just on Github, but in *every single* offline copy. When we say "just use git," we don't mean "use Github, the website," we mean "use git, the version control system, to view the historical information *in your local copy*".
|
September 09, 2018 Re: Source changes should include date of change | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paul Backus | On 09/09/2018 5:43 PM, Paul Backus wrote:
> On Sunday, 9 September 2018 at 04:37:48 UTC, Josphe Brigmo wrote:
>> If git would automatically do the dates then one could download the source code. Git would be the central repository and if one wanted an offline version that had enough info in it such as the data a change was made, who changed it, the date the file was generated etc, then it would be better than having nothing.
>>
>> [...]
>>
>> The thing is, none of this shit hurts anything. Comments don't change programs so really it is just an issue about bloat and rot. The rot is covered by git hub automatically generating all the info(then it becomes no different than the problem of versioning with everything, want an update, just download it from git). The bloat is minimum and the bloat is precisely valid information(it's not like it is gibberish).
>
> I think perhaps you are laboring under a severe misunderstanding of what git is, and how git and Github actually work.
>
> Git is a version control system. It records historical snapshots ("commits") of a project, along with metadata like date and author, and lets you navigate between different versions. The collection of data and metadata saved by git for a particular project is called a "git repository".
>
> Github is a website for hosting git repositories. When you download the dmd source code from Github using `git clone`, you receive a complete copy of the entire history of dmd, including both the commits themselves and the metadata associated with them.
>
> That's why there's no need to add comments--all the data you want is already there, not just on Github, but in *every single* offline copy. When we say "just use git," we don't mean "use Github, the website," we mean "use git, the version control system, to view the historical information *in your local copy*".
Or Mercurial, SVN, CVS... we are not using mainframes anymore. We can afford the cost of a full blown database with all this extra information in it as well as all the past changes. Anyways, we're no longer talking hundreds of lines of code. We talk in millions of lines of code where comments just don't scale to.
|
September 08, 2018 Re: Source changes should include date of change | ||||
---|---|---|---|---|
| ||||
Posted in reply to Josphe Brigmo | On 9/8/2018 9:37 PM, Josphe Brigmo wrote:
> [...]s**t[...]
We expect professional demeanor here. Please don't use such language.
|
September 09, 2018 Re: Source changes should include date of change | ||||
---|---|---|---|---|
| ||||
Posted in reply to Josphe Brigmo | On Sunday, 9 September 2018 at 04:59:08 UTC, Josphe Brigmo wrote: > Yes, but the fact is they would not appreciate my work because they do not appreciate it now. I can't really argue against that logic. But then again, I fail to see when such a situation would apply. I personally use the tortoisesvn diff viewers bound to hotkeys to help me with this, giving me perfect date and revision tracking + commit messages. Like you said, you might not have access to internet but git has the full history on your local repo and thus allowing you to do this. My personal preference is with mercurial, but this this works with pretty much any source control system that has a local repo and a working directory. > All it can do is add bloat. That is it! No one here wants more bloat, and that's what they're scared of. And that's why a usecase for this proposal is so much wanted. |
September 09, 2018 Re: Source changes should include date of change | ||||
---|---|---|---|---|
| ||||
Posted in reply to Josphe Brigmo | On Sunday, 9 September 2018 at 01:27:06 UTC, Josphe Brigmo wrote:
> This has nothing to do with git. People think git is the end all be all. What if git is not available, then what? It's moronic to think that one has to use one or the other when both options are available and both only add information.
>
What do you mean by "git not being available"? The program? You'll sooner have git on a system than a compiler. The repository? Then the same argument can be said for the sources. And if you say mirror, so will I.
|
Copyright © 1999-2021 by the D Language Foundation