I’m not sure why two of the pull requests have merge conflicts. Doing pull requests is all new to me as well. I’m doing to hand merge them as see that is going on. I’ll do that later today.
Thanks! Actually these two are just copies of the same things.
The first one should have been merged directly to master but it seemed that I coudn’t do it and GitHub suggested to create a new branch that included the same changes. It did not seem to help either.
I don’t really understand the logic of this. I changed several lines in my “original” Translations_cz.tsv and I don’t understand why GitHub expects me to edit the same lines again during the merge/resolve. I just wanted to replace the whole file but it’s probably too readable for GitHub to let it go the simple way. 
Anyway, if you are going to fix it by hand don’t bother editing it and just replace the file with the latest version:
I usually go the most conservative way with git (as I’m a long time svn user) and create a new branch every time I have to make changes 
I’d suggest you to fetch&pull the current master, then create a new local branch, replace your tsv file, push and PR.
I see in your latest PR that you’re trying to merge your own master, I’m no git expert but doesn’t this create some issues in history since you can’t fast-forward after someone else (i.e. me with the art addition) made changes to the upstream?
Thanks for the hints!
I’m no git expert at all. 
The only version tools I use for my solo programming projects are batch files running WinRAR and Google Drive.
Hm, I kind of expected I could work locally with just my master without additional branches because I thought this is (?) already a branch of Ron’s master. I’m just not sure if I could fix my local master… 
Actually it seems is has already happened but I thought it is related to the stuck pull requests.
I guess I have to throw away my changes first and then start anew.
It’s intended to be a copy, not a branch. So git tries to keep it consistent, history and all. If it can’t automatically merge (because there are changes in the middle, for example) then it asks for user intervention and this can be tedious if you’re not familiar with it.
I like git, but the whole idea is confusing for people who are used to other systems like svn, and you can really really mess up things 
so I just stick to what I’ve been taught at my last job: branch as soon as you want to change something, fetch&pull regularly, fetch&pull right before making the pull request. So all conflicts are now on your side and you’ll have to manually resolve them, but at least once you’ve done, your PR goes without conflicts and the maintainer (i.e. Ron) has his life facilitated 
Ah, and whenever you get into a situation so messed up you can’t manually merge… just save all your files somewhere else, remove everything, re-branch from master and copy your files back in
2 Likes
Unbelievable! 
This branch has no conflicts with the base branch
I am not really sure what to expect in future but the PRs seem to be solved at the moment.
I have to let it sink in a bit.
Thanks again!
2 Likes
If you rebase your own changes on top of upstream (e.g., with git pull -r upstream master) that shouldn’t be a problem. Note the -r flag, short for --rebase. That’s the same as something like git pull upstream master followed by git rebase upstream master (or should that be a fetch). But just use git pull -r; the alternative is too much work. 
You can set up that remote with git remote add upstream https://github.com/grumpygamer/DeloresDev.git.
A GitHub fork is basically a complete copy of another repo. You can fix anything with more branches and cherry picking. But this probably isn’t the kind of situation where that’s fruitful.
Edit: apologies, I opened this tab a few hours ago and didn’t notice the new replies.
I’ve never been able to wrap my head around SVN. Git actually makes sense to me. 
Going OT here (but hey, that’s what we do, isn’t it?), but I think it’s a matter of habit. I’ve been using SVN for like 10 years before having to switch, and in the beginning it was as confusing as it could be. Especially since git uses some terminology that reminds of SVN but it means totally different things. When I’ve been told “a branch isn’t a branch but a self-moving commit” I was… well, eyebrows were raised.
Now that I got a basic grasp of git, I feel like it’s way better. It makes more sense, it’s more powerful. But you really need to forget everything you knew about SVN.
1 Like
The first Czech description of GihHut I found started exactly with this sentence. 
1 Like
Right, but SVN simply never made sense to me. You could say I had a decade of SVN “habit.” I have always found it complex and convoluted. I’ll take Git/Mercurial/Bazaar all day, any day.
IMHO SVN is really simple: It’s just a versioned directory structure, that’s it.
The repository is at a central location and you typically work with your working copies (which are local copies of a part of this directory structure) against this single repository.
Git is a distributed VCS and much more flexible but it’s a little bit more complex.
You are basically merging all the time with also led to Git having superior merging tools/integration early on, while in SVN branching and merging was always quite some work (it has improved though).
1 Like
I understand and use SVN on a daily basis. So it really can’t be that hard.
I am happy if I can simply get the sourcefiles from a git repository in less than 30 minutes of searching on the web (
)
and registering for all kinds of github accounts.
Oh, there is a basic introduction course… average completion time 1 hour…? Ok, another time perhaps.
Git is a mess. It’s amazingly powerful, but you need to know a lot of arcane knowledge. Everything you want to do is there, but it often requires to the use commands and make little sense. About 90% of the git commands I use I don’t know why they a work, but they do so I keep using them. One of the most confusing things to me is when I merge and there is a conflict. The terms “theirs” and “mine” are used but seen 100% backwards. To make matters worse, some Git GUI apps seem to flip them to make more sense, so you never really know. Most of the online examples deal with merge from one brach to another, but that is NOT my use case, mine is pulling down master from a remote repository that another team member has modified.
2 Likes
Same here! 
I agree wit Ron 100%. I’ve worked with several other VCS in the past. AFAIR I hadn’t any issues with Subversion. And Mercurial had a much cleaner interface than Git. But today everybody seems to work with Git. So you haven’t really a choice if you work with other projects or within a team.
One slightly-off-topic-question:
How do you (plural 
use Git with your projects?
I mean do you work directly in the Git folder or do you keep a separate working copy of the folder?
I suppose one common folder should be more convenient but also a bit more dangerous - unless you really know what you’re doing with Git. =)
Normally just one folder with a few branches in Git.
If you want to do something possibly destructive to a branch and you don’t quite know what you’re doing yet, just make a new branch based on the one you want to modify first and go from there.
1 Like
Let’s all be friends and just call it “ours”, shall we?
Can it be, you are doing actually a rebase in that moment. Do you use cli tool with “git pull -r” or are you using an IDE which is trying to be smart and is doing a rebase for you?
The suspected flip is caused by the fact, that rebase creates a new reality by modifying the history. And it does this by
- creating an anonymous branch,
- cherry picking all the changes on remote and then
- merging your branch into this anonymous branch.
From the perspective of the anonymous branch, your branch is theirs.
Good to know I’m not the only one that’s confused by this