Were is a great place to Share your finished projects?

[Natsu Dragneel]

Im asking this because im working on a small project, but i won't say what it is because i want to do it completely on myself.

I just say it has something to do with Steam and a Feature they rly need to add there... so i write it myself :D and it already is finished it only needs a GUI now.

And its not going to be compiled, so everyone can edit it and Fix the errors i did as a beginner(with that i mean, im going to do it a bit different than someone who knows python better as me), because i don't know if my HTML parser is going to be able to do his Function on all sides that may be used.

[Christian Gollwitzer]

Am 30.06.16 um 14:48 schrieb Natsu Dragneel:

> Im asking this because im working on a small project, but i won't say
> what it is because i want to do it completely on myself.
>
> I just say it has something to do with Steam and a Feature they rly
> need to add there... so i write it myself :D and it already is
> finished it only needs a GUI now.

The best place these days to publish software is on github. And that
includes actual development, not just the final results. For reasons
why, see also: http://joshldavis.com/2014/06/13/put-yourself-out-there/

Github makes that extremely easy, just create an account, create a repo,
"git pull" and start working. Your incremental changes will be updated
with each "git push".

Christian

[MRAB]

An alternative is Bitbucket.

[Lawrence D’Oliveiro]

On Friday, July 1, 2016 at 1:09:31 AM UTC+12, Christian Gollwitzer wrote:
> Github makes that extremely easy, just create an account, create a repo,
> "git pull" and start working. Your incremental changes will be updated
> with each "git push".

I start with “git init” and never pull, only push.

I do use “git fetch && git rebase origin/master master” to copy from upstream repos to mine.

[Chris Angelico]

On Fri, Jul 1, 2016 at 9:06 AM, Lawrence D’Oliveiro
<lawren...@gmail.com> wrote:
> On Friday, July 1, 2016 at 1:09:31 AM UTC+12, Christian Gollwitzer wrote:
>> Github makes that extremely easy, just create an account, create a repo,
>> "git pull" and start working. Your incremental changes will be updated
>> with each "git push".
>
> I start with “git init” and never pull, only push.

Same here, and I recommend it to my students because GitHub, when
looking at a completely empty repo (no commits at all) will give a
handy set of copy/paste-ready commands to add a remote and push. But
ultimately, it comes to the same thing.

ChrisA

[Random832]

In context, I assume that by "pull" he actually meant "clone". But,
yeah, git pull is mostly an attractive nuisance for environments that
have a clear hierarchy.

[Steven D'Aprano]

On Thu, 30 Jun 2016 11:09 pm, Christian Gollwitzer wrote:

> The best place these days to publish software is on github.

http://nedbatchelder.com/blog/201405/github_monoculture.html





--
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

[Ben Finney]

Christian Gollwitzer <auri...@gmx.de> writes:

> The best place these days to publish software is on github.

For what value of “best”?

If one wants to avoid vendor lock-in, Github is not best: the workflow
tools (other than Git itself) are completely closed and not available
for implementation on another vendor's servers.

If one wants to communicate equally with Git repositories elsewhere,
GitHub is not best: federation between hosts is actively discouraged by
the lock-in.

If one wants to build a community on tools owned by that community,
GitHub is not best.

If one wants to teach newcomers with tools that will still be working
even when GitHub goes out of business, GitHub is not best.

If one wants to grow software freedom, Github is not best
<URL:https://mako.cc/writing/hill-free_tools.html>.

Convenience is not a reliable measure of how good something is, so it is
not the best measure of “best”.

--
\ “For myself, I am an optimist — it does not seem to be much use |
`\ being anything else.” —Winston Churchill, 1954-11-09 |
_o__) |
Ben Finney

[Christian Gollwitzer]

Am 01.07.16 um 03:38 schrieb Ben Finney:

> Christian Gollwitzer <auri...@gmx.de> writes:
>
>> The best place these days to publish software is on github.
>
> For what value of “best”?

The question was about visibility of a project for a single beginner
developer.

> If one wants to avoid vendor lock-in, Github is not best: the workflow
> tools (other than Git itself) are completely closed and not available
> for implementation on another vendor's servers.

Yes, but that is relevant only if the workflow (i.e. pull requests) are
an important part of the history. The code history is just git and that
is independent from github. For projects which rely on a single
developer, there is no issue. Additionally I wanted to point out that
"finishing" a project is the wrong idea, at least in open source terms.

> If one wants to communicate equally with Git repositories elsewhere,
> GitHub is not best: federation between hosts is actively discouraged by
> the lock-in.

I don't understand what that means. I can git pull my local repo from
somewhere else and then git push it to github. What do you mean by
federation between hosts?

> If one wants to teach newcomers with tools that will still be working
> even when GitHub goes out of business, GitHub is not best.

? git will not stop working

> If one wants to grow software freedom, Github is not best
> <URL:https://mako.cc/writing/hill-free_tools.html>.
>
> Convenience is not a reliable measure of how good something is, so it is
> not the best measure of “best”.

Then please propose an alternative instead of just arguing. Make sure
you try to understand the OPs objectives and background.

Christian

[Christian Gollwitzer]

Am 01.07.16 um 01:16 schrieb Random832:

> On Thu, Jun 30, 2016, at 19:06, Lawrence D’Oliveiro wrote:
>> On Friday, July 1, 2016 at 1:09:31 AM UTC+12, Christian Gollwitzer wrote:
>>> Github makes that extremely easy, just create an account, create a repo,
>>> "git pull" and start working. Your incremental changes will be updated
>>> with each "git push".
>>
>> I start with “git init” and never pull, only push.
>>
>> I do use “git fetch && git rebase origin/master master” to copy from
>> upstream repos to mine.
>
> In context, I assume that by "pull" he actually meant "clone".

Yes, sorry, I meant clone.

Christian

[Lawrence D’Oliveiro]

On Friday, July 1, 2016 at 1:39:04 PM UTC+12, Ben Finney wrote:

> Christian Gollwitzer writes:
>
>> The best place these days to publish software is on github.
>
> For what value of “best”?
>
> If one wants to avoid vendor lock-in, Github is not best: the workflow
> tools (other than Git itself) are completely closed and not available
> for implementation on another vendor's servers.

That’s (mostly) OK. Git is what I mainly want it for anyway.

> If one wants to communicate equally with Git repositories elsewhere,
> GitHub is not best: federation between hosts is actively discouraged by
> the lock-in.

I can add as many remotes to my Git repos as I like, pointing to servers wherever I like, so I guess it’s not that bad.

[Ben Finney]

Christian Gollwitzer <auri...@gmx.de> writes:

> Am 01.07.16 um 03:38 schrieb Ben Finney:

> > If one wants to avoid vendor lock-in, Github is not best: the
> > workflow tools (other than Git itself) are completely closed and not
> > available for implementation on another vendor's servers.
>
> Yes, but that is relevant only if the workflow (i.e. pull requests)

Pull requests. Code review. Issues. Integration with other services. All
the social information around all of those interactions, and more.

If *any* of that is valuable, then yes it's important that it not be
locked to any one vendor.

If *none* of that is valuable, then why prefer GitHub? Clearly people do
find those quite valuable, and it is disingenuous to pretend that the
code is the only valuable thing in a Github repository.

--
\ “The cost of a thing is the amount of what I call life which is |
`\ required to be exchanged for it, immediately or in the long |
_o__) run.” —Henry David Thoreau |
Ben Finney

[Chris Angelico]

On Wed, Jul 13, 2016 at 11:28 AM, Ben Finney <ben+p...@benfinney.id.au> wrote:
> Pull requests. Code review. Issues. Integration with other services. All
> the social information around all of those interactions, and more.
>
> If *any* of that is valuable, then yes it's important that it not be
> locked to any one vendor.

Exactly how important? Not so important as to stop slabs of Python
from migrating to GitHub, including its pull request system. (Work in
progress; currently, PEPs are on GitHub, but the core interpreter
hasn't moved yet. See PEP 512.)

ChrisA

[Ben Finney]

Chris Angelico <ros...@gmail.com> writes:

> On Wed, Jul 13, 2016 at 11:28 AM, Ben Finney <ben+p...@benfinney.id.au> wrote:
> > Pull requests. Code review. Issues. Integration with other services.
> > All the social information around all of those interactions, and
> > more.
> >
> > If *any* of that is valuable, then yes it's important that it not be
> > locked to any one vendor.
>
> Exactly how important? Not so important as to stop slabs of Python
> from migrating to GitHub, including its pull request system.

I maintain that it is important enough to stop that.

The migration happened anyway, because not everyone is convinced of the
importance of avoiding vendor lock-in of valuable data, over criteria
such as “this person happens to like Vendor-locked Solution Foo”.

There are other projects considering such a migration; I am hopeful they
can still be reasoned with.

--
\ “Begin with false premises and you risk reaching false |
`\ conclusions. Begin with falsified premises and you forfeit your |
_o__) authority.” —Kathryn Schulz, 2015-10-19 |
Ben Finney

[Chris Angelico]

On Wed, Jul 13, 2016 at 2:42 PM, Ben Finney <ben+p...@benfinney.id.au> wrote:
> Chris Angelico <ros...@gmail.com> writes:
>
>> On Wed, Jul 13, 2016 at 11:28 AM, Ben Finney <ben+p...@benfinney.id.au> wrote:
>> > Pull requests. Code review. Issues. Integration with other services.
>> > All the social information around all of those interactions, and
>> > more.
>> >
>> > If *any* of that is valuable, then yes it's important that it not be
>> > locked to any one vendor.
>>
>> Exactly how important? Not so important as to stop slabs of Python
>> from migrating to GitHub, including its pull request system.
>
> I maintain that it is important enough to stop that.
>
> The migration happened anyway, because not everyone is convinced of the
> importance of avoiding vendor lock-in of valuable data, over criteria
> such as “this person happens to like Vendor-locked Solution Foo”.
>

Fine. You're welcome to take a 100% philosophical stance; I applaud
you for it. (I understand Richard Stallman is so adamant about not
using *any* non-free code - software or firmware - that he restricts
himself to a tiny selection of laptops that have free BIOSes.)
Personally, I believe practicality beats purity in computing
philosophy as well as API design, and I'll happily let GitHub carry my
software. What's the worst that can happen? I have to switch to
somewhere else, and I lose the issue tracker and pull requests. In the
case of CPython, they wouldn't even be lost - they're (to be) backed
up. In the meantime, I'm on a well-polished platform with a large
number of users. The same cannot be said for *many* other hosts, even
if they do use exclusively free software.

ChrisA

[Steven D'Aprano]

On Wednesday 13 July 2016 15:11, Chris Angelico wrote:

> You're welcome to take a 100% philosophical stance

It's not a philosophical stance to avoid vendor lockin, nor to avoid incipient
monopolies, nor to avoid rewarding companies that behave badly.

It's not for philosophical reasons that we should avoid tendencies to band-
wagon jumping and monopoly building. Its for REAL, PRACTICAL reasons that the
short-term gain will invariably be overwhelmed by the long-term loss.

You just need to value more than the immediate right here, right now, and not
discount future risks excessively.

There are people who plan and plant great gardens which they will never see
completed, trees taking many decades to reach maturity. And there are those who
think that doing the washing on the weekend so they'll have clothes to wear on
Tuesday counts as "long term planning".

People over-estimate the costs of technical competition and under-estimate the
costs of monopolies and the single-network effect. They jump on the bandwagon
of "but everyone else is using IBM/Windows/Word/iPhones/Facebook/Github/
whatever" and then wonder why conditions slowly get worse. Its boiling frogs
everywhere.

Even if Github was 100% open source with no proprietary extensions, and the
*technical* cost of leaving was low, the single-network effect would still lock
you in, which leaves you (to some degree) at the mercy of Github's management.
Don't like the fact that they run their servers on electricity made from
burning puppies and the tears of little children? Too bad, what are you going
to do, move your project to some backwater VCS where nobody ever goes? You
might as well be on AOL for all anyone will ever find your project.

It boggles my mind that even devs who are the most socially aware and are all
for diversity and codes of conduct and building a better world have such a
blind eye when it comes to jumping on bandwagons and blindly following trends.


Time-to-read-Connie-Willis'-"Bellwether"-again-ly y'rs,



--
Steve

[Chris Angelico]

On Wed, Jul 13, 2016 at 4:44 PM, Steven D'Aprano
<steve+comp....@pearwood.info> wrote:
> Even if Github was 100% open source with no proprietary extensions, and the
> *technical* cost of leaving was low, the single-network effect would still lock
> you in, which leaves you (to some degree) at the mercy of Github's management.
> Don't like the fact that they run their servers on electricity made from
> burning puppies and the tears of little children? Too bad, what are you going
> to do, move your project to some backwater VCS where nobody ever goes? You
> might as well be on AOL for all anyone will ever find your project.

So what're you going to do? Move *now* to some backwater where nobody
ever goes, just in case GitHub ever turns evil?

ChrisA

[Steven D'Aprano]

Move *now* to a viable alternative, while it's still viable and before it's too
late, in order to encourage competition and discourage those idiots who don't
know how to use Google and think Github is the entire Internet-for-code.

"I couldn't find it on Github, therefore it doesn't exist" is already a real
phenomenon. Fortunately, at this point you probably won't want to accept
patches from those people. But in five or ten years? I give odds of about 50:50
that even competent coders will have bought into the Github-is-the-universe,
just as even people who know better treat Facebook as the entire Internet, and
worse.


"...some backwater where nobody ever goes..."

If you really mean that, then you're saying that Github has already captured
such a dominant market share that they are an effective monopoly over all
hosted DVCSes, and that programmers no longer have a choice about using them.
Its Github, or you're invisible, and leaving is not an option.

If you mean that, then be honest:

"The horse has already bolted, and vendor lockin is not a concern, its a fact.
All I can do is *hope* that Github doesn't turn evil."

On the other hand, if you genuinely think that Github *hasn't* captured the
market, that migration away from them is still an option, then you've undercut
your argument against using competing services. If you genuinely think that
migrating away from Github to (let's say) Bitbucket is an option, then your
quip about backwaters is invalid.



Speaking of F/B, a true story. A friend of mine in the US had this conversation
(edited for brevity):

"You got married??!? When did you get married?"

"Oh, about three months ago."

"I'm disappointed that you didn't invite me. I would have loved to have come."

"What do you mean? I posted the details on my Wall. Didn't you see it?"



--
Steve

[Chris Angelico]

On Wed, Jul 13, 2016 at 6:49 PM, Steven D'Aprano
<steve+comp....@pearwood.info> wrote:
>> what
>> are you going to do, move your project to some backwater VCS where nobody
>> ever goes?
>

> "...some backwater where nobody ever goes..."
>
> If you really mean that, then you're saying that Github has already captured
> such a dominant market share that they are an effective monopoly over all
> hosted DVCSes, and that programmers no longer have a choice about using them.
> Its Github, or you're invisible, and leaving is not an option.

Your words, not mine.

ChrisA

[Rustom Mody]

On Wednesday, July 13, 2016 at 10:42:01 AM UTC+5:30, Chris Angelico wrote:
> On Wed, Jul 13, 2016 at 2:42 PM, Ben Finney wrote:
> > Chris Angelico writes:

Speaking of notable figure(heads) its good to compare Stallman (rms) and
Torvalds.

rms started working on the gnu-system before Torvalds
He did more work on that
He was (and likely is) a more capable programmer

Note further that Torvalds was told off by prof. Tanenbaum for his poor quality
unimaginative approach to Linux

Torvalds still gets the Lion's share of the credit – how many people say
“GNU-Linux distros” rather than just plain “Linux”?

I’d say this is directly related to his choosing practicality over purity
He didn’t change the obsolete (so-called) Unix API
He didn’t redesign the OS along the lines fashionable to guys like Tanenbaum

He just found himself at the right place at the right time — holding a
protection capable home PC. And beat IBM and Microsoft at producing a kernel for that.

No I am not saying that the fears of Ben and Steven are unfounded
Just that we may have other battles to fight

And other heroes to cheer, eg
http://www.trueactivist.com/muslim-man-hugs-isis-suicide-bomber-saves-hundreds-of-lives-in-iraq/

[Lawrence D’Oliveiro]

On Thursday, July 14, 2016 at 1:03:30 AM UTC+12, Rustom Mody wrote:
>
> Note further that Torvalds was told off by prof. Tanenbaum for his poor
> quality unimaginative approach to Linux

And today, Prof Tanenbaum is struggling to find a little niche where his Minix product can be of relevance, while the entire computing world is converging around Linux.

Who was the “poor quality unimaginative” one, again?

[Michael Torrie]

On 07/13/2016 01:00 AM, Chris Angelico wrote:

> On Wed, Jul 13, 2016 at 4:44 PM, Steven D'Aprano
> <steve+comp....@pearwood.info> wrote:
>> Even if Github was 100% open source with no proprietary extensions, and the
>> *technical* cost of leaving was low, the single-network effect would still lock
>> you in, which leaves you (to some degree) at the mercy of Github's management.
>> Don't like the fact that they run their servers on electricity made from
>> burning puppies and the tears of little children? Too bad, what are you going
>> to do, move your project to some backwater VCS where nobody ever goes? You
>> might as well be on AOL for all anyone will ever find your project.
>

> So what're you going to do? Move *now* to some backwater where nobody
> ever goes, just in case GitHub ever turns evil?

No, you just run git as it was designed to be used. In a completely
decentralized fashion. If Github had honored this aspect of git,
there'd be no problem. A repo on GitHub would be just one of many
publicly-facing git repos. But by refusing to allow federated pull
requests, GitHub has most definitely created lock-in.

I understand that in Python's case, pure cost wins out. Python.org
could host a GitLab instance, which contains the repo tools plus ticket
tracking, etc, and ordinary developers could push their changes to their
own public git repos and send in pull requests and it would all work
swimmingly. However this comes at considerable cost in terms of
maintenance of the server and server software. So I can understand the
allure of GitHub. It's shiny and free-ish.

[Paul Rubin]

Michael Torrie <tor...@gmail.com> writes:
> So I can understand the allure of GitHub. It's shiny and free-ish.

Savannah.nongnu.org is a nice free host for free software projects. I
suppose it's less shiny than Github. On the other hand, Github is
written in Ruby--what self-respecting Pythonista would stand for that?! ;-)

[hasan...@gmail.com]

Michael Torrie <tor...@gmail.com> writes:

>I understand that in Python's case, pure cost wins out. Python.org
>could host a GitLab instance, which contains the repo tools plus ticket
>tracking, etc, and ordinary developers could push their changes to their
>own public git repos and send in pull requests and it would all work
>swimmingly. However this comes at considerable cost in terms of
>maintenance of the server and server software. So I can understand the
>allure of GitHub. It's shiny and free-ish.

Python's primary repository is Mercurial (hg.python.org), not Git. Were python
to switch, it wouldn't be too much work to just deploy gitlab (or whatever)
instead of mercurial. However, I see nothing git offers over mercurial. -- H

[Terry Reedy]

On 7/14/2016 3:04 PM, hasan...@gmail.com wrote:

> Python's primary repository is Mercurial (hg.python.org), not Git.

CPython's current repository ....
Ditto for the PSF Python docs.

> Were python to switch,

Like it or not, CPython and the Docs are moving to git and github.
PEPs and the devguide have already been moved.

--
Terry Jan Reedy

[Lawrence D’Oliveiro]

On Friday, July 15, 2016 at 7:04:14 AM UTC+12, hasan...@gmail.com wrote:

> ... I see nothing git offers over mercurial.

Except greater productivity.

[Brendan Abel]

A lot of these arguments and points have already been made and hashed out
on the python-dev list. There's a very good article that one of the python
core developers wrote about the decision to move to github

http://www.snarky.ca/the-history-behind-the-decision-to-move-python-to-github

Basically, maintaining an open source git server, bug tracker, etc. would
have cost time and money, and historically very few people were willing to
contribute those, especially the people who were the most opinionated on
the desire to remain "pure to open source". Github gives all these things
away for free. And pretty much every python developer has already used
github for other projects. In the article he makes a good point that if
you're that worried about always using open-source, then you shouldn't be
using gmail, or twitter, or even automobiles, since they all use software
that is closed-source. At some point, paying for software just makes sense.

On Thu, Jul 14, 2016 at 12:34 PM, Terry Reedy <tjr...@udel.edu> wrote:

> On 7/14/2016 3:04 PM, hasan...@gmail.com wrote:
>

> Python's primary repository is Mercurial (hg.python.org), not Git.
>>
>

> CPython's current repository ....
> Ditto for the PSF Python docs.
>
> Were python to switch,
>>
>
> Like it or not, CPython and the Docs are moving to git and github.
> PEPs and the devguide have already been moved.
>
> --
> Terry Jan Reedy
>

> --
> https://mail.python.org/mailman/listinfo/python-list
>

[Steven D'Aprano]

That has not been even close to my experience. And I don't mean my
*personal* experience.

About seven years ago, the senior technical manager at my work chose hg over
git. When he left to go to greener pastures, the dev team took about 30
seconds to to reverse his decision and migrate to git, after which the
level of VCS-related screw-ups and queries went through the roof.

To give you an idea of how screwed up things are, even though I'm not one of
the developer team, and have never pushed a thing into the code
repositories (I have pushed into documentation repos), somehow according
to "git blame" I'm responsible for a bunch of code.

(If I'd been paid for this code I didn't write, I wouldn't mind so much...)

[Steven D'Aprano]

On Fri, 15 Jul 2016 09:13 am, Brendan Abel wrote:

> In the article he makes a good point that if
> you're that worried about always using open-source, then you shouldn't be
> using gmail, or twitter, or even automobiles,

It's not a good point. I don't use gmail, or twitter, and if I could find a
car that didn't rely on closed-source code, I would use it. Just because
choice is limited and its hard or impossible to get open-source engines
doesn't mean that closed-source engines are a good idea.

> since they all use software
> that is closed-source.  At some point, paying for software just makes
> sense.

No, that doesn't follow. The opposite of "open source" is not "paying for
software". You can pay somebody to maintain your open source repo just as
easily as you can pay somebody else to maintain their own closed source
repo.

I watched the discussion on Python-Dev that decided to move to github, and
there were completely viable open source hg alternatives. Although nobody
was quite crass enough to come right out and say it, the alternatives were
all dismissed because they weren't Github, because "everyone uses github".

[Ben Finney]

Steven D'Aprano <st...@pearwood.info> writes:

> On Fri, 15 Jul 2016 09:13 am, Brendan Abel wrote:
> > since they all use software that is closed-source.  At some point,
> > paying for software just makes sense.

Is it 1998 again already?

Or am I expecting too much that people involved in software in the 21st
century should not fall for the canard of “why don't you want to pay for
software”, because it is *completely irrelevant* to the issue of
software freedom.

So please, stop repeating that canard. Of course paying for software
makes sense. That in no way entails vendor lock-in of valuable community
data, and we should not be paying for that.

> No, that doesn't follow. The opposite of "open source" is not "paying
> for software". You can pay somebody to maintain your open source repo
> just as easily as you can pay somebody else to maintain their own
> closed source repo.

Yes. Likewise, just because you don't hand any money to someone doesn't
mean you are free from vendor lock-in and proprietary protocols. One day
perhaps we won't need to repeat that for it to be understood.

> I watched the discussion on Python-Dev that decided to move to github,
> and there were completely viable open source hg alternatives. Although
> nobody was quite crass enough to come right out and say it, the
> alternatives were all dismissed because they weren't Github, because
> "everyone uses github".

Fortunately there are a zillion software projects who can still choose a
hosting provider that won't lock them in, and good free-software hosting
alternatives like Pagure are beginning to appear. Not all is lost.

--
\ “The Initial Mystery that attends any journey is: how did the |
`\ traveller reach his starting point in the first place?” —Louise |
_o__) Bogan, _Journey Around My Room_ |
Ben Finney

[Brandon McCaig]

On Fri, Jul 15, 2016 at 10:39:05AM +1000, Steven D'Aprano wrote:
> About seven years ago, the senior technical manager at my work chose hg over
> git. When he left to go to greener pastures, the dev team took about 30
> seconds to to reverse his decision and migrate to git, after which the
> level of VCS-related screw-ups and queries went through the roof.

Git used to have much sharper edges than Mercurial, but that is
pretty much a thing of the past. With Git you pretty much can't
permanently lose history unless you try really, really hard.
It'll always be there in the reflog for a period of several days
minimum (I think 2 weeks by default?) and if you're worried about
it you can configure it to put that off for months or years...

On the other hand, I have had Mercurial bugs repeatedly lose work
of mine. The kind of bugs that aren't easy to reproduce so nearly
impossible to report and nearly impossible to fix. The ecosystem
of "extensions" makes this problem inevitable. You depend on
extensions, typically third-party extensions for the first few
years of their life, for all of the power-user stuff, and the
extensions have as much power to corrupt or lose history as the
main library does. And of course, they have the potential to
alter the behavior of the core library making reporting bugs that
much more difficult ("ok, but which extensions, official or
unofficial, do you have installed?"). Now instead of one team
writing bugs you have N teams writing them in isolation.

Combined with their failure to accomodate the distributed
development model properly you now have a bunch of incompatible
ideas for managing branches and history editing and they still
haven't gotten it all right yet (but they're getting closer the
more and more they model the design after Git).

> To give you an idea of how screwed up things are, even though I'm not one of
> the developer team, and have never pushed a thing into the code
> repositories (I have pushed into documentation repos), somehow according
> to "git blame" I'm responsible for a bunch of code.

The user name and email fields are not controlled in either Git
or Mercurial so anybody can commit code under your name without
you being involved. That would be pretty unprofessional though...
I can't imagine Git magically pulling your name out of nowhere
when it looks up the author of commits that are responsible for
lines of code... Maybe you should report that to the mailing list
and get to the bottom of it... I suspect that the explanation has
nothing to do with any bugs in Git.

Regards,


--
Brandon McCaig <bamc...@gmail.com> <bam...@castopulence.org>
Castopulence Software <https://www.castopulence.org/>
Blog <http://www.bambams.ca/>
perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'

[Chris Angelico]

On Sat, Jul 16, 2016 at 1:39 AM, Brandon McCaig <bamc...@gmail.com> wrote:
> [regarding Mercurial]

> Combined with their failure to accomodate the distributed
> development model properly you now have a bunch of incompatible
> ideas for managing branches and history editing and they still
> haven't gotten it all right yet (but they're getting closer the
> more and more they model the design after Git).

I've never managed to get Mercurial's branching system into my head
(and then you have the people saying "don't use hg branches at all,
just use named tags" or somesuch), but the git branching system is
extremely simple. In fact, all of git is very simple. To anyone who is
having trouble with comprehending git, I strongly recommend this
video. It assumes you have a basic understanding of git commands (or
can pause the video and look up a git-hg Rosetta Stone), but you don't
need expert-level knowledge. In fact, it's aimed at people ages 4 and
up...

https://www.youtube.com/watch?v=1ffBJ4sVUb4

>> To give you an idea of how screwed up things are, even though I'm not one of
>> the developer team, and have never pushed a thing into the code
>> repositories (I have pushed into documentation repos), somehow according
>> to "git blame" I'm responsible for a bunch of code.
>

> The user name and email fields are not controlled in either Git
> or Mercurial so anybody can commit code under your name without
> you being involved. That would be pretty unprofessional though...

If you're paranoid, you can have git sign your commits, in which case
anyone could commit code under your name, but not using your private
key. You can then tell people to be suspicious of any commits they
can't cryptographically verify.

> I can't imagine Git magically pulling your name out of nowhere
> when it looks up the author of commits that are responsible for
> lines of code... Maybe you should report that to the mailing list
> and get to the bottom of it... I suspect that the explanation has
> nothing to do with any bugs in Git.

There are a few possibilities. If someone copied a slab of code from
the documentation repo straight into the code repo (maybe you provided
examples or something), git might detect that and recognize the
copying. In that case, you'd be (correctly) responsible for that code,
and the author would be a two-part "originally authored" pointing to
your docs commit and "moved or copied here by" pointing to the commit
that actually incorporated it. But if the repositories are completely
separate, this is unlikely. More likely, someone might be able to
cherry-pick the commit itself, if there is a corresponding file in
code; again, this would have a two-part authorship marker "author" and
"committer", because every git commit has this. (This is something
Mercurial lacks. Every commit is blamed to the person with the
commit-bit who pushed it, rather than the person who actually wrote
the code. Obviously the committer is important, but so is the author.)

If you want to get to the bottom of it, I would advise exploring the
commits that are tagged with your name. Do they look like changes you
made? Did you provide a patch file that someone else committed? And,
who committed the changes - can you email that person to ask for
clarification?

The beauty of git is that all the information is right there, if you
just look at it - 'git show 142857' will answer most of the above
questions, and add "--format=full" or "--format=fuller" [1] to get the
committer's info. Dig around... have fun!

[1] I mean, not "fuller", just... more formatful. Wait, what?

ChrisA

[Marko Rauhamaa]

Chris Angelico <ros...@gmail.com>:

> I've never managed to get Mercurial's branching system into my head
> (and then you have the people saying "don't use hg branches at all,
> just use named tags" or somesuch), but the git branching system is
> extremely simple. In fact, all of git is very simple. To anyone who is
> having trouble with comprehending git, I strongly recommend this
> video. It assumes you have a basic understanding of git commands (or
> can pause the video and look up a git-hg Rosetta Stone), but you don't
> need expert-level knowledge. In fact, it's aimed at people ages 4 and
> up...

I use git daily but don't really use branches, and need to ask a
coworker about the branching commands. Also, reverting changes in git
keeps baffling me (I need to check the source code of emacs' vc-mode to
figure out how it's done).

Anyway, all of this has reminded me that bitkeeper is now free. I've
never tried it so let's see if it is everything Sun's Teamware was.


Marko

[Marko Rauhamaa]

Marko Rauhamaa <ma...@pacujo.net>:

> Anyway, all of this has reminded me that bitkeeper is now free. I've
> never tried it so let's see if it is everything Sun's Teamware was.

Hm, ran into compilation trouble.

Maybe I should wait till bk is available for Fedora.


Marko