On using Git

[Tobias Heinemann]

Dear Pencil Code developers,

If you don't have a particular need for using Git, then I urge you to continue with Subversion.

If you do decide to use Git in favor of Subversion, please make sure that you familiarize with Git first, for instance by looking through the official book available at http://git-scm.com/book/en/v2

I see a lot of so-called merge commits such as

https://github.com/pencil-code/pencil-code/commit/76506a3ebeae5ab3d6896bb07817b039c4fc22c0

in the commit log. These are completely unnecessary and only cause clutter.

Also, could you *please* follow the first time Git setup, see http://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup, and make sure that

$ git config --global user.email

returns an e-mail address associated with your GitHub account. Also make sure that

$ git config --global user.name

returns a full name and not some unix user name. If in doubt what to put there, just clone the repository and go through the commit log and get the information from one of your entries from before the switch to GitHub.

Regarding the above mentioned commit, this was apparently authored by "jonaskru <jonask...@gmail.com>", but it doesn't appear to be associated with the GitHub account "jnskruger" who is part of the "collaborators" team. So my guess is that for this user

$ git config --global user.name

$ git config --global user.email

return "jonaskru" and "jonask...@gmail.com", respectively and that the e-mail address "jonask...@gmail.com" is not yet associated with the GitHub account "jnskruger". Jonas, please fix this and also issue the commands

$ git config --global user.name "Jonas Krüger"

$ git config --global user.email "jnskr...@gmail.com"

Cheers,

  Toby

[SimonC (Iomsn)]

Dear Toby,

Is there any strong reason why we shouldn't use git alongside svn? Perhaps that could be a discussion point at next week's user meeting.

Cheers

Simon

[Philippe Bourdin]

Hello all,

is there some additional difference in "using git" other than that:

svn update
svn commit ...
svn commit ...

translates to:

git pull
git commit ...
git commit ...
git commit ...
git push


PS: I have quickly checked with the github support that our github
account profiles list now also our past activity:
https://github.com/PABourdin
Before, that was only the case for some of us, as I have seen.

Thanks and best greetings,

Philippe.

[Tobias Heinemann]

Hi Simon,

There's indeed no such reason. In fact if somebody has some experience with Git (and thereby knows how to set one's Git identity and knows what merge commits are and how to avoid them), then I would absolutely encourage using Git instead of SVN.

Best,
  Toby

--
You received this message because you are subscribed to the Google Groups "pencil-code-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pencil-code-dis...@googlegroups.com.
To post to this group, send email to pencil-co...@googlegroups.com.
Visit this group at http://groups.google.com/group/pencil-code-discuss.
For more options, visit https://groups.google.com/d/optout.

[Tobias Heinemann]

Hi Philippe,

> is there some additional difference in "using git" other than that:
>
> svn update
> svn commit ...
> svn commit ...
>
> translates to:
>
> git pull
> git commit ...
> git commit ...
> git commit ...
> git push

That is basically it, but if people are not familiar with the things I mentioned in my reply to Simon, then hell won't break loose, but it will result in a unnecessarily messy commit history.

> PS: I have quickly checked with the github support that our github
> account profiles list now also our past activity:
> https://github.com/PABourdin
> Before, that was only the case for some of us, as I have seen.

This nicely illustrates my point. There should be no need for GitHub support to get involved. For anybody who correctly configures their Git identity and associates the corresponding email address with their GitHub, all the pass commits will automatically be attributed to that person.

Best,
  Toby

[Philippe Bourdin]

Hello Tobias,

> This nicely illustrates my point. There should be no need for GitHub
> support to get involved.

No, sorry, that was actually a "bug" on GitHub only related to our
account statistic. I had configured everything as suggested, and I'm
familiar with git due to other software projects. :-) The github guy
said he just needed to delete the account's cache data, then it worked.


Regarding documentation on "using git":

For proper git configuration, it would help probably a lot, if we could
collect all necessary information (how to clone, configure, pull,
commit, and push) in only one place and refer to that everywhere else.
Currently, some information is found on our website, the manual, the
quick guide, the git project page, and the wiki - none is complete.

I would suggest to put all information on the website:
http://pencil-code.nordita.org/download.php
And everywhere else, we just link to that. An exception could be the
quick_guide.pdf - maybe also the manual, but it is not needed to have
this information there, if one needs to download, one has web access.

[Tobias Heinemann]

> > This nicely illustrates my point. There should be no need for GitHub
> > support to get involved.
>
> No, sorry, that was actually a "bug" on GitHub only related to our
> account statistic. I had configured everything as suggested, and I'm
> familiar with git due to other software projects. :-) The github guy
> said he just needed to delete the account's cache data, then it worked.

Oh I see, thanks a lot for sorting this out then! I misinterpreted what you were saying.

As for the rest of your email, I agree one hundred percent.

Toby

[Philippe-A. Bourdin]

Hello Tobias,

what actually causes these spurious "merge branch master" commits like this one?:
https://github.com/pencil-code/pencil-code/commit/7dd927fbc392e5e58ccf5dfe8cfe12d214e2b650

I'm asking because it seems to have hit me too now, and I'm not understanding, what I have done wrong...

[Philippe-A. Bourdin]

Replying to myself,

this basically describes the issue well:
http://kernowsoul.com/blog/2012/06/20/4-ways-to-avoid-merge-commits-in-git/

So, what we all should do is configure git to always "rebase" on pulls:
$ git config --global branch.autosetuprebase always

Please let me know, if I'm wrong, otherwise I will include that in the git instructions to be written and put onto the website...

Best greetings,
Philippe.



[Philippe Bourdin]

Hello,

I'm currently having _severe_ problems with the github repository.

I have recently switched to the SVN client, because working with the GIT
client on a repository with many commits from others is a pure pain!
(Constantly the client refuses to do its work, complains, wants me to
commit in *all* the changes in order to change only one file, all of a
sudden I'm on a branch, and without prior notification there is a merge
branch, etc.)

At first, the SVN interface to github looked more stable, but in fact it
is not. I have files, where the SVN client complains about a newer
version would be available, but "svn up" shows me I'm up-to-date. Still,
I can't commit the change. What shall I do, how can I commit this file?

(Matthias, you reported something similar, did you fix your issue? How?)

Thanks and best regards,

Philippe.

[Philippe Bourdin]

PS: Even deleting the affected file, doing a "svn revert", and
re-editing the changes does not help. github refuses to take the file.
:-(

[Tobias Heinemann]

Hi Philippe,

Regarding the SVN errors, is this reproducible or does it just occur on a particular machine? Also, it would be helpful to see the actual commands and error messages.

I'm not very inclined to comment on your claims about Git being painful to use. There's countless discussion on the internet with the same theme. However, I do believe there's overwhelming evidence that Git works perfectly fine for projects that are much much bigger and have many more users and I see absolutely no reason why it wouldn't work for the Pencil Code. It just takes some getting used to.

  Toby

[Petri Käpylä]

I've had the same issue with svn. In the end I was able to check in again by renaming (or deleting) the file src/.svn/all-wcprops. Matthias has the same issue too (in the same machine as I did), but apparently the same trick did not work for him.

Petri

[Philippe Bourdin]

Hello Tobias,

> Regarding the SVN errors, is this reproducible or does it just occur on a
> particular machine?

I can confirm that with a freshly checked-out repository (same machine)
the problem does NOT appear. So it is specific to the repository that
obviously got messed up by the github SVN bridge.

Matthias: your solution is to checkout to a fresh local copy, transfer
your changes to that new copy, and submit from there.

> Also, it would be helpful to see the actual commands
> and error messages.

As said, it is the SVN message for "out of date" files.
I only have the German message here, which is of no use for the others:

$ svn up
Aktualisiere ».«:
Revision 23351.
$ svn ci mpich2.conf
[...]
svn: E160024: Datei »mpich2.conf« ist veraltet; versuchen Sie zu
aktualisieren
svn: E160024: resource out of date; try updating
$ svn up
Aktualisiere ».«:
Revision 23351.
$ cp mpich2.conf mpich2.bak
$ svn revert mpich2.conf
$ cp mpich2.bak mpich2.conf
$ svn ci mpich2.conf
[...]
svn: E160024: Datei »mpich2.conf« ist veraltet; versuchen Sie zu
aktualisieren
svn: E160024: resource out of date; try updating
$ echo "Aargh!"

> I'm not very inclined to comment on your claims about Git being painful to
> use.

Well, I would recommend now every Pencil Code user NOT to use the GIT
client after the big mess it created for me - and as you know, it is
usually quite hard to get me stressed (and I'm experienced in GIT). ;-)

> I do believe there's overwhelming evidence that Git works perfectly
> fine for projects that are much much bigger and have many more users

There is definitely something more to consider. For example, on GIT it
is absolutely not recommended to have the master as development branch.
GIT may even change the history of a file. GIT does not know about
"revisions". This is all in clear opposition to our Pencil Code habits.
Other projects may have different development strategies than Pencil?

I think, if we stay on GITHUB (as a repository), we will have to change
our Pencil Code habits, we will have to forbid the mixing of SVN and GIT
clients, and if we decide to enforce the GIT client, we will have to
stop developing on the master branch.
Otherwise, I predict more trouble that will not settle by getting used.

Sorry for this pessimistic outlook,

Philippe.

[Tobias Heinemann]

> So it is specific to the repository that
> obviously got messed up by the github SVN bridge.

Messed up how? Were you using Git and SVN on the same repository?

I'll respond to the rest of your email later.

  Toby

[Philippe Bourdin]

Hello Petri,

> In the end I was able to check in again
> by renaming (or deleting) the file src/.svn/all-wcprops.

I do not have such a file here, also not in pencil-code/.svn/

[Philippe Bourdin]

> > So it is specific to the repository that
> > obviously got messed up by the github SVN bridge.
>
> Messed up how? Were you using Git and SVN on the same repository?

I used only SVN for about one day on only one local copy.

I just see that there was a "merge branch" in between, which includes
the affected file, but I can't tell if that was really the cause.

Best greetings,

Philippe.

[Tobias Heinemann]

> I do believe there's overwhelming evidence that Git works perfectly
> fine for projects that are much much bigger and have many more users

There is definitely something more to consider. For example, on GIT it
is absolutely not recommended to have the master as development branch.
GIT may even change the history of a file.

Changing the history of a file never occurs unless you do a so-called forced push (git push --force). I mentioned in a previous e-mail that I was worried about this and therefore asked GitHub to disable forced pushes on all repositories under http://github.com/pencil-code, which they did.

 

GIT does not know about
"revisions". This is all in clear opposition to our Pencil Code habits.

And yet the very existence of GitHub's SVN bridge shows that it's evidently possible to associate an incrementally increasing revision number with every Git commit to the master branch. But I suppose what we've learned from the trouble you guys are having is that merge commits somehow break this, and I agree that the people at GitHub should consider this to be a serious bug.

I have one suggestion and one comment:

1) If it's true that merge commits expose a bug in the SVN bridge, then it should be easy to (lay out the steps necessary to) set up a GitHub repository with a minimal amount of code that allows us to demonstrate what the problem is and when it occurs. I haven't seen your actual bug report (only the response), but I strongly suspect that GitHub would start to take this more seriously then.

2) Everybody who wants to use Git should figure out how to avoid merge commits to the master branch, which really isn't that difficult! Anybody who hasn't figure this out is not yet ready to use Git. It's simple as that. Just stick with SVN in that case. Problem solved for the time being.

I agree the best thing to do for now is to tell everybody to stick with SVN, not least because otherwise there's gonna be endless Git vs SVN discussions on how one is supposedly superior to the other or a pain to use in comparison.

Having said this, let me just note that last year, Git seems to have surpassed Subversion as the #1 code management tool in the "open source community" (http://eclipse.dzone.com/articles/eclipse-community-survey-2014). I'm sure it's possible to interpret this data every which way you like depending on your inclination, but I think it's abundantly clear that while some Pencil Code developers are having trouble with Git, a vast number of people involved in other open source projects do not.

  Toby

[Andreas Schreiber]

Hi

Am 22.05.2015 um 01:30 schrieb Tobias Heinemann:
> 2) Everybody who wants to use Git should figure out how to avoid merge
> commits to the master branch, which really isn't that difficult!
> Anybody who hasn't figure this out is not yet ready to use Git. It's
> simple as that. Just stick with SVN in that case. Problem solved for
> the time being.

Yes, okay, but actually the correct behaviour should be then to share
your wisdom with all other people. So, lets do a Wiki page on how to use
git correctly with our repository and working scheme. Then you can tell
people to stick to the rules or if they dont like them use svn instead.

[Philippe Bourdin]

Hello,

> So, lets do a Wiki page on how to use
> git correctly with our repository and working scheme.

Please put it in the website under "Downloads", because this is the
starting point for getting the code, and one should actually directly
see there, what is needed to do (complete and unique information).

Unfortunately I see that the website is still not updated automatically.
Axel, can you check with your System-Administrator to set a cron-job?

[Tobias Heinemann]

On Fri, May 22, 2015 at 9:55 AM, Andreas Schreiber <andreas.s...@googlemail.com> wrote:

Yes, okay, but actually the correct behaviour should be then to share your wisdom with all other people.

This "wisdom" is shared all over the internet. But sure, it doesn't hurt to replicate this on the wiki.

[Tobias Heinemann]

Yes, okay, but actually the correct behaviour should be then to share your wisdom with all other people.

This "wisdom" is shared all over the internet. But sure, it doesn't hurt to replicate this on the wiki.

On second thought I'm not so sure it wouldn't hurt because it will probably encourage people to use Git. And until the errors with the SVN bridge are sorted out, I don't think that's a good idea.

[Boris Dintrans]

+1

Boris.

[Philippe Bourdin]

Hello Tobias,

> This "wisdom" is shared all over the internet.

I'm not sure if the stuff being shared all over the internet is actual
wisdom. Most of the discussions about GIT problems (like the pull-rebase
issue we also see here, or switching back to a master branch) are
discussed, yes, but most of the "solution" actually never worked for me.

> But sure, it doesn't hurt to replicate this on the wiki.

On the download-page, please. I think we agreed to have all the relevant
documentation about cloning and using the repository in only one place.

> On second thought I'm not so sure it wouldn't hurt because it will probably encourage people to use Git. And until the errors with the SVN bridge are sorted out, I don't think that's a good idea.

Ok, but then we have to forbid now using the GIT client for non-experts.
If that is the case, I should delete instructions on how to use the GIT
client from our website (and we also should not discuss it on the wiki).

(On Wednesday I already removed the recommendation for the GIT client.)

[Philippe Bourdin]

Hello Tobias,

> Changing the history of a file never occurs unless you do a so-called
> forced push (git push --force). I mentioned in a previous e-mail that I was
> worried about this and therefore asked GitHub to disable forced pushes on
> all repositories under http://github.com/pencil-code, which they did.

Still, this (my design) renders impossible the concept of a revision
number (similar to SVN) for GIT, no matter if we deny force-pushes.

> 1) If it's true that merge commits expose a bug in the SVN bridge, then it
> should be easy to (lay out the steps necessary to) set up a GitHub
> repository with a minimal amount of code that allows us to demonstrate what
> the problem is and when it occurs.

I have to report now, that I just again had the situation that my SVN
local working copy came to an "invalid" state, where I could nomore
checkin a file, that only I have edited and no other commit happened in
between my commits. Deleting the SVN local working copy and checkout
agian solved the problem. As previously, it was not successful to only
revert or remove the affected file.

This clearly demonstrates that the GitHub SVN bridge is even broken
independently of the previously mentioned "GIT merge branch commits".

I'm really sorry, but I fear we have to decide between SVN or GitHub.

I would propose to use a self-owned server for a proper SVN repository.
I can offer my server, which is operational since ~1999 (with >99,5%).
I understand that you don't want to rely on individuals, but as we see,
individuals are sometimes more reliably than even Google Inc. is. ;-)

[Tobias Heinemann]

Is it not possible to list the steps necessary to reproduce the problem?

[Tobias Heinemann]

> > Changing the history of a file never occurs unless you do a so-called
> > forced push (git push --force). I mentioned in a previous e-mail that I was
> > worried about this and therefore asked GitHub to disable forced pushes on
> > all repositories under http://github.com/pencil-code, which they did.
>
> Still, this (my design) renders impossible the concept of a revision
> number (similar to SVN) for GIT, no matter if we deny force-pushes.

I don't understand. How can GitHub's SVN bridge work at all if what you say is true?

[Philippe Bourdin]

Hello Tobias,

> Is it not possible to list the steps necessary to reproduce the problem?

Well, all I did was:
$ svn ci test_f2003.f90
modified the file test_f2003.f90
$ svn ci test_f2003.f90

=> svn: E160024: resource out of date; try updating

And this has already happened for more than three users independently.

Best greetings,

Philippe.

[Tobias Heinemann]

And I assume you're committing this to github.com/pencil-code/pencil-code.git?

By the way, I'm in no way denying the problem exists. I would just like to reproduce it.

[Philippe-A. Bourdin]

        Hello Tobi,

> How can GitHub's SVN bridge work at all if what you say is true?

Simple: The revision numbers they produce are fake and unreliable.
Git *can* change the past, therefore revision numbers *could* change.
This is in clear contradiction to SVN.

> And I assume you're committing this to
> github.com/pencil-code/pencil-code.git?

Yes.

Best greetings,

        Philippe.

[Tobias Heinemann]

How do I change the past of origin/master if forced pushes to origin are disabled?

[Philippe-A. Bourdin]

        Hi again,

How do I change the past of origin/master if forced pushes to origin are disabled?

I'm not anyone *is* doing that.
I was saying that "by design" GIT allows for it and that this is in clear contradiction to SVN principles.
Thereore, "by design" GIT does not allow (SVN-like) revision numbers.

But that is not even the most important point here. Even though it gives serious additional troubles, because the GitHub SVN bridge would not expand "$Id$" strings for us, which (currently) destroys the reproducability of Pencil Code runs and requires us to put another (SVN-like) versioning tool on top of GIT, which I find silly, because it is YARIOTW (yet another re-invention of the wheel).

Best greetings,
Philippe.

[Tobias Heinemann]

> I'm not anyone *is* doing that.
> I was saying that "by design" GIT allows for it and that this is in clear contradiction to SVN principles.
> Thereore, "by design" GIT does not allow (SVN-like) revision numbers.

I'm not going to dignify this with a response.

> But that is not even the most important point here. Even though it gives serious additional troubles, because the GitHub SVN bridge would not expand "$Id$" strings for us, which (currently) destroys the reproducability of Pencil Code runs and requires us to put another (SVN-like) versioning tool on top of GIT, which I find silly, because it is YARIOTW (yet another re-invention of the wheel).

That would be very silly indeed. Why do Git hashes not provide the same reproducibility as SVN revision numbers.

[Philippe-A. Bourdin]

        Hello Tobias,

> Why do Git hashes not provide the same
> reproducibility as SVN revision numbers.

First, because these not GIT commit hashes, but only the BLOB hash, which gives us NO WAY of guessing the revision number or the commit hash (in order to re-checkout that specific version).

Second, because this would work only for the GIT clients, not for the SVN clients (which most if the Pencil Code team want to use).

Don't get me wrong, I have nothing against GIT, I used it for ages in my software company (as well as rcs, cvs, and svn). I just see GIT does not work our with the Pencil Code habits that we currently have. And we need a solution (back to SVN) or a clear decision for discontinuing SVN and forcing everyone to use GIT (then still lacking a proper revision number system).

[Tobias Heinemann]

> Why do Git hashes not provide the same
> reproducibility as SVN revision numbers.

First, because these not GIT commit hashes, but only the BLOB hash, which gives us NO WAY of guessing the revision number or the commit hash (in order to re-checkout that specific version).

You're losing me again. Obviously there's got to be a way to print out the Git commit hash at runtime. And then all one has to do is

$ git co <hash>

Second, because this would work only for the GIT clients, not for the SVN clients (which most if the Pencil Code team want to use).

Again, because the SVN bridge exists, there also has to be a way of uniquely mapping commit hashes to revision numbers of origin/master. And because forced pushes are disabled, this mapping is -- for all intents and purposes -- predictable.

Don't get me wrong, I have nothing against GIT, I used it for ages in my software company (as well as rcs, cvs, and svn).

That's not the impression I'm getting. You're basically implying that the Git world doesn't care about reproducibility. And that's an absurd implication.

 

I just see GIT does not work our with the Pencil Code habits that we currently have. And we need a solution (back to SVN) or a clear decision for discontinuing SVN and forcing everyone to use GIT (then still lacking a proper revision number system).

So you've completely written off the possibility of a functioning SVN bridge? I see no principle reason for why the SVN bridge couldn't work for us, and I still think that if it'd be possible to reproduce the error messages you guys are getting then there's very reasonable hope that it will be fixed.

There's also the possibility of effectively mimicking the SVN workflow in Git, see https://debconf.org/wiki/GitMigration#Getting_you_started_quickly. The whole document is worth reading by the way.

But yes, reverting back to SVN hosting is of course also an option. But if that's what's gonna happen, then it should happen for the right reasons. A broken SVN bridge is in my opinion a valid reasos. All the others I've heard so far are not.

  Toby

[Tobias Heinemann]

$ git co <hash>

Yes, I've aliased 'co' to 'checkout'.

[Philippe-A. Bourdin]

        Hello,

You're losing me again.

As are you loosing me again. :-)
Therefore we speak: to converge our understanding of each other.
 

Obviously there's got to be a way to print out the Git commit hash at runtime.

There is no "GIT commit hash" that you can inject into your source code, like the SVN-keyword "$Id$" did.
The only thing you can inject into your source code is the BLOB hash.
And this simply does not translate into anything that you could checkout.
The Internet fora are full of people searching for a solution... go, check yourself.
The only "solution" I can think of is silly, as we both agreed.
 
Of course, you could make a shell script printing out the GIT commit hashes of each (relevant) module, but that would not work on a SVN working copy. So, are we ging to force people to use the GIT client?
Or do you want to make a script that also automatically checks, if it is running inside a GIT or SVN local copy and then use some other commands to print out the SVN revision numbers?
That might be doable, but it is much more complicated as before.
Are you volunteering? ;-)

Again, because the SVN bridge exists, there also has to be a way of uniquely mapping commit hashes to revision numbers of origin/master.

Again: SVN revisions have no counterpart in GIT.
The existence of fake revision numbers in the GitHub SVN bridge does not prove wrong a simple fact that is easily understandable already from theory.
Furthermore: the GitHub people are not willing to extend thir SVN bridge to support the SVN-keyword "$Id$" with their faked revision numbers, so we can't use it as we did with the SVN repository.
 

Don't get me wrong, I have nothing against GIT, I used it for ages in my software company (as well as rcs, cvs, and svn).

That's not the impression I'm getting.

Then you should stop interpreting what I say and simply stay with the pure facts.
What I say is that GIT does not work out with the Pencil Code habits.

I'm probably one of the most willing persons in this whole team to change my habits (Pencil Code is anyway an exot for me where I have already adopted a lot of "foreign habits"), if we all switch to use only the GIT client and someone else takes care to implement the "silly solution" (a versioning tool on top of a versioning tool) that we need as a feasible way to guarantee reproducibility.
 

You're basically implying that the Git world doesn't care about reproducibility.

I don't know what the GIT world thinks, and you should not think that you know what I think! ;-)
One more fact: the GIT world works to largest parts in a very different way as we do. I have already explained this statement before (either on this list or in our private communications).
 

So you've completely written off the possibility of a functioning SVN bridge? I see no principle reason for why the SVN bridge couldn't work for us, and I still think that if it'd be possible to reproduce the error messages you guys are getting then there's very reasonable hope that it will be fixed.

Good luck, then. I don't know how I should reproduce something that happens occasionally for no obvious reason.
If you want, you can try to explain to the GitHub people that my local SVN working copy got stuck after 80faff7ea74874075a42c2b8e99c05f711312255 and I had to delete everything and re-checkout in order to commit b00ca4ff2f4ba4b22a00c02e16d18a30835853a3. Maybe they have log files on their server. Error message was: "svn: E160024: resource out of date; try updating".
I'm not going to communicate with GitHub again. The first person I had to deal with was very polite and cooperative, but the person responsible for answering questions about the SVN bridge (Steven) was rather ignorant and incooperative to me.
 

There's also the possibility of effectively mimicking the SVN workflow in Git, see https://debconf.org/wiki/GitMigration#Getting_you_started_quickly. The whole document is worth reading by the way.

Well, that does not help me in any way, sorry.
 

But yes, reverting back to SVN hosting is of course also an option. But if that's what's gonna happen, then it should happen for the right reasons. A broken SVN bridge is in my opinion a valid reasos. All the others I've heard so far are not.

One more reason are (meaningful) revision numbers that are injectable to the source code.
And one more: SVN is simpler to use, I never understood, why a "git push" is needed by default.
One more: if you prefer to use GIT, you can actually do that (without loss of any SVN-functionality) on top of a SVN working copy, so that you can commit even offline, like in GIT.

Again: for me the future path is irrelevant, I can live well with both, SVN or GIT. Just I can't live with the combination of: a) not changing our Pencil Code habits, b) a broken GitHub SVN bridge, c) mixing of SVN and GIT clients, d) re-inventing existing SVN-wheels that we need on top of GIT. ;-)

[Tobias Heinemann]

Obviously there's got to be a way to print out the Git commit hash at runtime.

There is no "GIT commit hash" that you can inject into your source code, like the SVN-keyword "$Id$" did.
The only thing you can inject into your source code is the BLOB hash.

If injecting commit hashes and/or revision numbers into the source code is of such crucial importance, then Git is simply not the right tool to use. To quote Linus Torvalds:

"The whole notion of keyword substitution is just totally idiotic. It's trivial to do 'outside' of the actual content tracking, if you want to have it when doing release trees as tar-balls etc."

See http://www.gelato.unsw.edu.au/archives/git/0610/28891.html

Furthermore: the GitHub people are not willing to extend thir SVN bridge to support the SVN-keyword "$Id$" with their faked revision numbers...

And I find it difficult to blame them for this given that each repository on GitHub is primarily a Git repository.

  

So you've completely written off the possibility of a functioning SVN bridge? I see no principle reason for why the SVN bridge couldn't work for us, and I still think that if it'd be possible to reproduce the error messages you guys are getting then there's very reasonable hope that it will be fixed.

Good luck, then. I don't know how I should reproduce something that happens occasionally for no obvious reason.

In that case I don't have much hope either that this bug will be fixed soon. And even if it is, it would probably not be wise to rely on a functioning SVN bridge in the future.

 

There's also the possibility of effectively mimicking the SVN workflow in Git, see https://debconf.org/wiki/GitMigration#Getting_you_started_quickly. The whole document is worth reading by the way.

Well, that does not help me in any way, sorry.

See below.

But yes, reverting back to SVN hosting is of course also an option. But if that's what's gonna happen, then it should happen for the right reasons. A broken SVN bridge is in my opinion a valid reasos. All the others I've heard so far are not.

One more reason are (meaningful) revision numbers that are injectable to the source code.

Whether or not this a good reason in general has been fiercely debated in the past, see http://thread.gmane.org/gmane.comp.version-control.git/44750.

And one more: SVN is simpler to use, I never understood, why a "git push" is needed by default.

It literally takes one command, i.e.

$ git config --global alias.scommit '!scommit() { git commit -a "$@" && git push; }; scommit'

to restore this aspect of Subversion's famed simplicity.

A "git push" is required by default because Git is a distributed revision control system. It is, however, possible to use Git as a centralized revision control system in an effort to maintain the workflow one is used to coming from Subversion. In order to do this, the steps outlined https://debconf.org/wiki/GitMigration#Getting_you_started_quickly are very helpful in my opinion. I'm not sure for what reasons you characterized this as not helpful.

 

One more: if you prefer to use GIT, you can actually do that (without loss of any SVN-functionality) on top of a SVN working copy, so that you can commit even offline, like in GIT.

That's certainly a valid point. However, let's keep in mind that the move to GitHub wasn't just about moving from SVN to Git, but also about moving to code hosting platform that maximizes the Pencil Code's visibility. Also, one of the major advantages of GitHub is that it makes it so easy for people that don't have write access to improve the code by sending in changes via pull requests. I strongly believe that the Pencil Code will also benefit from this functionality, which simply doesn't exist in a comparable form if the code is hosted using Subversion and/or privately.

Again: for me the future path is irrelevant, I can live well with both, SVN or GIT. Just I can't live with the combination of: a) not changing our Pencil Code habits, b) a broken GitHub SVN bridge, c) mixing of SVN and GIT clients, d) re-inventing existing SVN-wheels that we need on top of GIT. ;-)

So I think we're actually mostly in agreement. I can't live with that combination either. And given the trouble with the GitHub's SVN bridge, I don't think a hybrid Git/SVN hosting solution is feasible long term. So I think our options are

1) We stay on GitHub and use Git exclusively. I think this is a viable and would provide many benefits in the long run. The transition from centralized to distributed revision control will no doubt be painful for some, but this can be mitigated (see above). From what I can tell, the mess you guys were experiencing when using Git would not have occurred if everybody would always commit and push in one go.

2) We revert to hosting the code in a Subversion repository.

  Toby

[Tobias Heinemann]

On Sun, May 24, 2015 at 4:52 PM, Tobias Heinemann <tobias.h...@gmail.com> wrote:

Also, one of the major advantages of GitHub is that it makes it so easy for people that don't have write access to improve the code by sending in changes via pull requests. I strongly believe that the Pencil Code will also benefit from this functionality...

Let me add that I think this functionality could also be useful for e.g. students that are newcomers to the code. I remember that gaining full write access to the Pencil Code repository and thereby the possibility of messing things up for everybody else was very daunting when I first started developing the code.

[Philippe Bourdin]

Hello Tobi,

you continue to ignore what I said earlier:
Typical GIT workflow and Pencil Code habits do not fit to each other.

See your citation and please read it *fully* to the end:

> "The whole notion of keyword substitution is just totally idiotic.
> It's trivial to do 'outside' of the actual content tracking,
> if you want to have it when doing release trees as tar-balls etc."

(PS: Here already you can see, Linus in no god and no theoretician. In
SVN, keyword substitution IS done 'outside' of the content tracking!)

Furthermore: Are we producing stable releases? No.
(Btw., I have proposed to do so already in 2010! Guess why...)
So that citation does simply not apply to the Pencil Code.
We all work on a development-branch (especially: on the same one!).
Typical Linux-Projects (based on GIT) do NOT work like that.

So, are we going to enforce this paradigm change to the Pencil Team?:
- Fully drop SVN support and enforce the GIT client
- No more developing on the master branch
- Develop on individual branches and merge frequently to master
- Tag stable releases and use these tagged versions for production

If we really enforce all that, then you understand my statement, that
using SVN is just so much simpler than GIT.

Furthermore, I see that you have committed very little on GitHub, so you
simply don't know what amount of trouble we had, when using the GIT
client. It is simply not sufficient to alias one or two commands. We
also need to enforce configuration options, and still we have no means
to disallow "merge branch commits", which completely mess up the commit
history! And GitHub is not taking action on this - I have asked them.

Finally, noone can explain me up to today, why I suddenly ended up on a
branch (using the GIT client), without prior notification! Or why the
hell GIT enforced me to commit all my changes in order to push only one
of them... Yes, that really happened to me - and I'm not a GIT beginner.

> And I find it difficult to blame them for this given that each
> repository on GitHub is primarily a Git repository.

Well, the SVN bridge is their own buggy code. I only did not object
strongly to the GitHub transition, because I thought that the feature
they advertise is actually doing what it should. Yes, I blame GitHub!

> > One more reason are (meaningful) revision numbers that are
> > injectable to the source code.
>

> Whether or not this a good reason [...]

That is not debatable at this point for the Pencil Code, because we
currently still rely on it, so it is a requirement. And just to be
precise here: This was already clear before the GitHub transition.

Alternatively, those who are strongly bound to GIT/GitHub must implement
a working substitution for that feature. (If the Pencil Code team is not
going to change their workflow substantially and have stable releases.)

> It is, however, possible to use Git as a centralized
> revision control system in an effort to maintain the workflow one is used
> to coming from Subversion. In order to do this, the steps outlined
> https://debconf.org/wiki/GitMigration#Getting_you_started_quickly are very
> helpful in my opinion. I'm not sure for what reasons you characterized this
> as not helpful.

Because it will lead to the same troubles again that I already had with
the GIT client (during the Pencil Code Meeting week) in conjunction with
our classical Pencil Code workflow. (See details already given above.)

> However, let's keep in mind that the move
> to GitHub wasn't just about moving from SVN to Git, but also about moving
> to code hosting platform that maximizes the Pencil Code's visibility.

I doubt that "being on GitHub" increases visibility.
People search with search engines. They don't go to GitHub in order to
search for an MHD code with the features we offer. So people will first
visit our homepage before finding the Pencil Code repository on GitHub.

> one of the major advantages of GitHub is that it makes it so easy for
> people that don't have write access to improve the code by sending in
> changes via pull requests.

In the past, these people were students of team members with write
permission. They can pass on their changes to an experienced person.
So this is a tiny feature, which will probably never really be used.
Especially these people usually implement only something very specific
for them, which is therefore seldom of importance for the whole team.
One could btw. also send a patch/diff to the mailing list, which is even
easier, because you don't have to be a GIT expert.

> And given the trouble with the GitHub's SVN bridge, I don't
> think a hybrid Git/SVN hosting solution is feasible long term.

Well, the trouble I had with the SVN bridge was even less than I had
with using the GIT client together with the classical Pencil Code
workflow. Therefore I switched back to using the SVN bridge now...

> 1) We stay on GitHub and use Git exclusively.

Yes, but we all have to completely change our workflow.

> the mess you guys were experiencing when using Git would not have
> occurred if everybody would always commit and push in one go.

Actually, that is not true. Yes, of course, I tried to do so...

> 2) We revert to hosting the code in a Subversion repository.

I have a hard time choosing!
Actually, I would prefer GIT together with a complete workflow change.
But I fear that would lead to major troubles in the rest of the team.

I think we both should now work out all the final consequences of
staying at GIT and the SVN option. Then we should put this in some small
paragraphs and let the team decide on their preference. This should
include a sample workflow with GIT, and a solution for stable-tagging.

PS: A GIT => SVN transition looks easy for me, there are some tools.

Summary for the GitHub option 1):

- enforce using the GIT client
- SVN bridge can only be used for read-only access
- development takes place on individual branches
- finalized features need to be merged back to master
- on successful autotest completion a stable tag has to be set
- enforce the configuration option for automatic rebase'ing on pull
- tool needs to be written in order to output the stable tag number

Summary for the SVN option 2):

- transferring the GIT repository to SVN
- old Pencil Code workflow (develop on trunk) can be continued
- either have to use self-owned server or non-free web service
- might have an automatic mirroring over to GitHub (that is simple)

Do you have other points to append?

[Tobias Heinemann]

This conversation is over.

[Axel Brandenburg]

I'm not quite sure what your error message was,
but one thing I heard first from Piyali and then I had
this myself was that during checkin it said the repository
was outdated. I could still update it (so it was not out of
date), but could not check it in. I then did

cd src
svn up
cd ..
mv src src2
svn up src
mv src2/affectedfile.f90 src
cd src
svn diff
svn ci -m checkin

and that worked.
Axel

On Wed, May 20, 2015 at 05:17:09PM +0200, Philippe Bourdin wrote:
> PS: Even deleting the affected file, doing a "svn revert", and
> re-editing the changes does not help. github refuses to take the file.
> :-(

[Axel Brandenburg]

But have the GitHub people been asked about the $Id$ expansion
for svn checkins? If nothing can be done, we can probably live
with it (and think about a workaround). All the other issues,
as serious as they may be, don't pose a real threat, it seems,
so we can probably live with those too.

Given that there is no SvnHub, maybe github/pencil-code can be
reconfigured to run svn (and perhaps with a git bridge).
What do you think?
Axel

[Philippe Bourdin]

Hello Axel,

sorry, your email reached me with some delay.

> But have the GitHub people been asked about the $Id$ expansion
> for svn checkins?

Yes, I have asked, but the answer was rather disappointing, even though
implementing this feature in their SVN bridge is a "minor effort".
Maybe, if more people ask, GitHub will reconsider.

> If nothing can be done, we can probably live
> with it (and think about a workaround). All the other issues,
> as serious as they may be, don't pose a real threat, it seems,
> so we can probably live with those too.

Well, it means you can't continue to work seriously with SVN.
Even with the GIT client, I had some very strange errors that I couldn't
resolve with any of the suggested methods found in manuals or fora.

Furthermore, for consistency and reproducibility, we have to start
tagging stable releases and use only those releases for production runs.
Printing out a release tag is btw. much simpler.

Best greetings,

Philippe.

[Philippe Bourdin]

Hello all,

it just happened again: After the trouble with the SVN bridge, I
restarted using the GIT client, yesterday. Now, I experience the same
problems as I already had before with GIT on the Pencil Code repository.

The attached protocol nicely documents my points against hosting on
GitHub and proves wrong all who claim that "GIT can be used like SVN",
or who claim that "the Pencil Code workflow fits to a GIT repository".

Btw. can anyone tell me what I actually did wrong? Why I would have had
to commit/stash all my changes in order to push only one of them?

PS: Just to make clear why I have to insist and why this affects me
obviously most: https://github.com/pencil-code/pencil-code/pulse/monthly

[Philippe Bourdin]

Hello Axel,

it happened to me, again, today that I couldn't checkin via SVN.

> one thing I heard first from Piyali and then I had
> this myself was that during checkin it said the repository
> was outdated. I could still update it (so it was not out of
> date), but could not check it in.

That is exactly what I have now. Matthias saw it, too.
I have tried your suggestion:

> I then did
>
> cd src
> svn up
> cd ..
> mv src src2
> svn up src
> mv src2/affectedfile.f90 src
> cd src
> svn diff
> svn ci -m checkin

But for me, this did not work.
Basically, I have to delete the whole "pencil-code" directory and
re-checkout, transfer manually the changed files, and checkin.
Only then, my change was accepted from this new checkout:
57e4419d4b19c3873d4e3dc5782c504fce0bd95c

You may see the problem in the attached SVN protocol, which clearly
demonstrates the SVN bridge of GitHub is at fault.

This is really annoying.
How should I/we continue to work on Pencil Code?
Running away or ignoring the problem is probably not a solution?