News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Using git

Started by Dwachs, October 25, 2013, 01:31:09 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Dwachs

About using git: found that there is a windows application to work with github, no extra git installation necessary: http://windows.github.com
Parsley, sage, rosemary, and maggikraut.

Markohs

I just installed that one yesterday, Dwachs, quite useful, even I didn't had problems with merging trunk back to my branch, some of those have to be done manually:

https://help.github.com/articles/fork-a-repo

The upsteream part is not doine automatically by the Windows frontend, and so far it has worked, I wonder what will happen if there are conflicts, and how I'm suposed to solve them.

git merge upstream/master

worked, what will happen if the conflict is not automatically solved, I don't know. ;)

Combuijs

At work we use Git Extensions (http://sourceforge.net/projects/gitextensions/) as a windows GIT interface. Very useful tool that, is actively developed as well.
Bob Marley: No woman, no cry

Programmer: No user, no bugs



Dwachs

#3
Quote from: Max-Max on October 25, 2013, 03:25:40 PM
Well, I did installed and tried to fork the experimental and had somewhat success. I found a TortoiseGIT but the nomeclature is quite different from SVN so I didn't understood really how to do the things I'm used to do in SVN.
[...]
Maybe we should try to stabilize the current patch before I star to mess around with GitHUB, I can try to isolate the stuff into smaller and more defined patches or do we want things forked first? How does it work on gitHub, should I create patches or just announce a revision for review?
I split these posts from the original discussion. Will answer these question later.

Edit: Yes, git is different to svn in more than one respect.

To start, you have to fork/clone an existing repository, (github.com/aburch/simutrans), first do this on github, then clone your github repository on your local machine.

Working with branches is one of the strenghts of git: create a branch, checkout a branch switches your working copy to the branch's copy.

To commit stuff: first git-add changes, then git commit. The nice thing here is, that you can do commits on a line-by-line basis, you do not need to commit all the changes in a file. Here the git-gui (or the gui of github for windows) helps.

Then you have to push your changes to your github repository, then others can review your work.

Another feature of git is that you get a copy of the whole history on your local machine. You do not need a server connection to view the history.

In order to integrate changes on github to our svn, we (I ?) have to create ordinary patch files, apply them to the svn working copy, commit there.
Parsley, sage, rosemary, and maggikraut.

sdog

#4
QuoteIn order to integrate changes on github to our svn, we (I ?) have to create ordinary patch files, apply them to the svn working copy, commit there.
Which lost it's edge as the conflicts have berm resolved on the git repository(?|.)


We lately has some unreliability with the sync of git repos to SVN upstream. Do you think this could be provided from one of the simians servers? (also @our benevolent dictator)

Edit: 'git' being a not to uncommon word, in its non-computer use, I wonder why android changes it into 'got'all the time.

prissi

The window git gui is really a pain. To get the changes from upstream, you have to use the commandline, where is clashed with an older command line git. Somehow svn versus git reminds me of Pascal versus C++, very powerful but unless you really know what you are doing very cryptical ... ;)

Markohs

I share prissi's oppinion. It's a gppd system, but harder to manage, tortoiseSVN made things much easier. I'll try Combuijs's suggested software to see if it eases. The main problem is conflict solving, rest is more or less ok.

sdog

For this topic perception seems to be mostly determined by the OS used. To Linux users git might look much easier than for windows users. (I often fall back on gitg, a GUI git manager.)

On Linux SVN appears to require quite a bit of knowledge of the repository's structure, and some experience to configure it properly while git is a bit fire and forget, works out of the box and one can learn it while using. This seems to be very much different on windows.

(Since it us so convenient to use for me it replaced most other method I used for syncing, except basic rsync.)

Ters

Quote from: sdog on November 07, 2013, 06:12:21 PM
For this topic perception seems to be mostly determined by the OS used. To Linux users git might look much easier than for windows users. (I often fall back on gitg, a GUI git manager.)

On Linux SVN appears to require quite a bit of knowledge of the repository's structure, and some experience to configure it properly while git is a bit fire and forget, works out of the box and one can learn it while using. This seems to be very much different on windows.

(Since it us so convenient to use for me it replaced most other method I used for syncing, except basic rsync.)

Another issue is that Git and Mercurial, both being made for and by Linux people, don't agree to Windows' way of handling Unicode. Working with both Windows and Linux, and letters beyond z, I had to rule out both for some things. I've heard that Git is closest to having a fix, maybe they even already have it, despite Mercurial apparently having the otherwise best Windows intergration through TortoiseHg (never heard of any TortoiseGit for some reason).

sdog

That's rather interesting. I read a couple of surprising things when looking things up. Thanks for that posting Ters.

The encoding on the filesystem is transparent to the apps?* How could they actually fix something on the side of mercurial and git? How would other software handm/index.php?topic=12770.msg127203;topicseen#newle this? This should be a problem for any interaction with software, starting with simple file operations between file systems mounted in win, or day-to-day operations with a simple scp or rsync.

How does SVN handle that?

On a brief search it appears it is related to UTF-16 being the standard in Win. The rest i couldn't follow from this brief search.

There appears to be a solution for mercurial comming up (http://stackoverflow.com/questions/12540247/unicode-filenames-on-windows-mercurial-2-5-or-future):
Quote
No, Mercurial still doesn't support transcoding of filenames. That is, it will checkin and checkout filenames as binary strings and you will experience problems if you need to move files between systems with incompatible filename encodings.
[...]
There is a Windows UTF-8 plan in the works, and FUJIWARA Katsunori has been working on it, but it's not yet (September 2012) ready.

Will MS stick to utf-16 with their NTFS succesors (perhaps ReFS). There must be something comming, afterall we're up for a complete seperation of file systems for low bandwith data storage and for high bandwith operation. Due to conventional file systems (BTRFS, NTFS, etc) complete inadequacy for solid state storage, while the requirements for disks change to safe very large storage.

* That is something i easily said, but giving it a bit of thought i found i have only a very very dim idea about it. Need to read into it. So double-thanks for bringing this topic up.

IgorEliezer

Quote from: sdog on November 08, 2013, 05:35:15 PM@mod or Igor: I've pushed the thread so far astray, it might be prudent to move it to randomness lounge. #9 would be a good break. I suppose Ters wouldn't mind.
Done. Hope I chose a good topic title.

Revision control softwares (split from: Using git)
:arrow: http://forum.simutrans.com/index.php?topic=12825.0

prissi

Is it just the git supplied from github that get strange error messages (like I need to provide an email, when I merge from master ??? )

sdog

when the merge works without conflicts, git does it 'fast forward'. That means it merges and commits it immediately. It requires to have your identity set for committing.

Dwachs

I recently read about this tool:

http://www.syntevo.com/smartgithg/

According to their homepage, this tool lets you clone an existing svn repository but as a local git repository. Sounds like a good idea to use this for simutrans development and patch making: Clone the true svn repository (not the github mirror), but with the full functionality of git, where it is a LOT easier to maintain branches, resolve conflicts etc.

I did not try it out yet, but will do definitely. Do others have experience with this tool?
Parsley, sage, rosemary, and maggikraut.

prissi

#14
EDIT: This tools requires a git already installed on your system. It did not recognize the github git, for whatever reasons in my short test. It did not work with cygwin git too, but I did not try to much then.

So the quest for nice userfriendly mingw compatible, non-bloatware git is still open for windows. Github was close, it gives very little feedback on the state of the repo, is not aware of the filenames and line ending issues and you need the commandline to merge from upstream (and hence have to resolve conflicts there). It has buttons with unclear functionality until you click on it. I comitted twice stuff I did not want to do just because of this.

On a personal note: During the branching of the GUI I tried git. But it was not a nice experience, as git is full of strange commands (like "git checkout -- file" to reset a file to its unmodified state) or things like fetch and merge (does anybody only do the first, and how do the last without the first). Also it was impossible to get github create a patch that was usuable with the commong patch tool. Only cygwins patchtool can handle git patches. I deleted my github branch and left simutrans too, since with git it is way to easy to acidently destroy it (for me).

If you have never used version revision systems, your probably better start with git. If you are on windows and are used to svn and do not want to use a commandline, you better still stay with svn.

Dwachs

Tried smartgit. It has a bloated gui - all git commands seems to be cloned to gui controls. However r6913 was done with smartgit :)

It has one disadvantage: it ignores the already existing .gitignore file ...
Parsley, sage, rosemary, and maggikraut.

Ters

I have a local Mecurial clone of the Simutrans SVN repo (and a further clone of that for my experiments). It required a small plugin, but I'd be surprised if such a thing didn't exist for Git as well. Creating a local Git clone from SVN shouldn't really be any different from creating the GitHub clone from SVN. GitHub perhaps has some GUI on top.

(The Mercurial plugin isn't 100% at pushing back to SVN according to it's documentation (haven't tried), as it can't push back branches and Mercurial opted out of rebasing, which Git apparently uses for almost every problem.)

prissi

git has the git-svn utility, which does fine most stuff but moving files. When I have time, I will try mercurial, as it seems I cannot get warm with git.

Ters

Mercurial does behave more like Subversion (which is an important part of the rivalry between followers of Git and followers of Mercurial), and with TortoiseHg integrates into Windows like Subversion with TortoiseSVN. It also doesn't act "as strange" with pull and merge. But distributed VCSes have their own quirks by nature. And there is the filename charset problem. Mercurial is also more strict about the history. Once something is committed, you typically can't do rebasing and other stuff like with Git. Although, with the proper plugins (which is bundled, at least with TortoiseHg), you can to some degree pop committed changesets into patches.

prissi

I am not afraid of typing commands, as long as there is a way to memorize them without knots left in my brain ...

sdog

Quote from: prissi on November 22, 2013, 10:29:44 PM
I am not afraid of typing commands, as long as there is a way to memorize them without knots left in my brain ...

Is there a good shell with syntax completion available for windows? zsh does most of the remembering for me. (i couldn't get myself to remember git reset --hard or git checkout --hard HEAD~1)

Quote
git is full of strange commands (like "git checkout -- file" to reset a file to its unmodified state) or things like fetch and merge (does anybody only do the first, and how do the last without the first). Also it was impossible to get github create a patch that was usuable with the commong patch tool.

fetch only fetches the upstream and saves it somewhere in .git, you can check out copies of the remote repository (call it remote here) by for example  git checkout remote/master. The fetch doesn't change your lokal own repositories however. You can either fetch first and then merge the changes of remote into your own branch eg git merge remote/master when you are already in master. Or you can just go into your branch and pull git pull remote master, this will fetch only the changes of remote/master and immediately merge them into your master branch.


QuoteWhen I have time, I will try mercurial, as it seems I cannot get warm with git.
happened to me with svn, it really seems to be:
QuoteIf you have never used version revision systems, your probably better start with git.
most svn things seem a bit counterintuitive to me, while git seems much clearer.*  but is started with git.


*especially, with regard to branching, and working on the same thing on several computers, ie commiting changes in parallel, or unfinished work) In git when i started on monday A on my notebook, didn't finish, then did B in the office on tuesday and pushed it. On wednesday i would just stash the changes A on my notebook, pull B, apply the stashed A again and continue where i stopped on monday. That way i got 430 commits, when writing a 4 page paper (over the course of one year)...

Ters

Quote from: sdog on November 22, 2013, 11:53:55 PM
Is there a good shell with syntax completion available for windows? zsh does most of the remembering for me. (i couldn't get myself to remember git reset --hard or git checkout --hard HEAD~1)

You can probably use zsh on Windows, or at least bash. Perhaps powershell can do something fancy, at least if someone exposes git as a .net object or something, but then the syntax would likely be non-standard.

Quote from: sdog on November 22, 2013, 11:53:55 PM
especially, with regard to branching, and working on the same thing on several computers, ie commiting changes in parallel, or unfinished work) In git when i started on monday A on my notebook, didn't finish, then did B in the office on tuesday and pushed it. On wednesday i would just stash the changes A on my notebook, pull B, apply the stashed A again and continue where i stopped on monday. That way i got 430 commits, when writing a 4 page paper (over the course of one year)...

I don't see what you write has to do with branching. If you skipped the stashing, then you'd have branched development. But it's very typical of how I perceive typical Git usage: you fake a linear development by moving your own changes to always be after the current head, just as one would without branches in any other tool, except that it's done per push, not per commit.

Markohs

Tried to commit a change "Nicolas Kaiser" pulled, did:


C:\code\gitHub\base\simutrans [master]> git pull https://github.com/nikai3d/simu
trans patch-1
From https://github.com/nikai3d/simutrans
* branch            patch-1    -> FETCH_HEAD
Merge made by the 'recursive' strategy.
readme.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
C:\code\gitHub\base\simutrans [master]> git push
remote: Permission to aburch/simutrans.git denied to Markohs.
fatal: unable to access 'https://github.com/aburch/simutrans.git/': The requeste
d URL returned error: 403


It's impossible to commit using git to the master repository? Are we forced to use svn?

Dwachs

This is only a one-way mirror, only aburch has writing permission there. Changing this repository would not change the svn repository at all.

You have to submit it the traditional way: Create a patch, apply it with 'patch -p1 < file' and 'svn ci'.
Parsley, sage, rosemary, and maggikraut.

Markohs