1) Bertram told me to always use a branch. For everything. I really dislike this, as if I'm just doing a quick bug fix or something, I don't want to go through the steps of creating a branch, checking it out, making my change, grabbing the latest upstream, merging the branch back into master, and then pushing my commit to the server. I feel like the same thing should be accomplished if I made changes to my master, grabbed the latest upstream, merged my changes with upstream, and then push. Shouldn't it be the same?
2) I keep reading about how the git merge tool is supposed to be some holy power to be worshiped, but I've already had problems with it in the relatively minor changes that I have made.
3) I've been following the guide here for this: https://help.github.com/articles/fork-a-repo . So I made the upstream repository which points to Bertram's master. When I need to make a change, I fetch the latest upstream repository and then merge it into my master. After resolving any merge conflicts, then I push it to my remote master and send a pull request to Bertram.
I'll top-add to the original post as we get more and more info. hopefully, with enough information we can maybe sticky the thread.
aaargh, GIT now gives me "unable to determine absolute path of git directory" for my project, which is on a USB external drive...
1) is it best to work directly against my master? Or should I immediately branch so that when Bertram / someone else makes an "upstream" commit, I can pull to the master and trickle down (other wise, it seems I have to roll back commits and looks like a headache...)
2) is git mergetool particulary useful for the above problem
3) are there better ways to get the code and maintain a "my master" vs "global master" ?
I discussed this with some folks on IRC, and I was told that I have to delete it because if my commit doesn't match with his, I wouldn't be able to pull from his repository in the future. -BUT- if that's not the case (the commits do match) then I do not have to delete my commits.
So, what is it that I need to do? I'm scared to try anything after the last git headache I suffered. I'd like to get all the latest changes from your repository, but I'm not making a move until I understand A) what I need to do (if anything) and B) why I need to do it.
Bertarm: on "cleaner" commits, I'm pretty sure that one of the explicit drivers of Git's design was to make sure you commit often. Commits were not intended to be big and clean (as in "finish feature X"). They were intended to be small and atomic.
Just pull or ask to rebase next time. Don't create problems for other developers by refactoring their commits because you are OCDing on the commit log. Don't confuse commit log and changelog.
If you have a minor issue with a developer's change, either pull and then commit your fix and ask them to pull that, or direct them to fix it themselves accordingly.
Changing somebody's commits is a Git worst practice and creates work for you and for them and tension in the project.
Just to add to that; if you want Roots to rebase his commits to make them more changelog friendly, then ask him, don't do it for him.
Charlie, I don't like the tone of those two last comments. In the manaworld project, we kept having problems with people which were not willing or not at ease with git to refactor their commits
before inclusion. By only pointing out problems in the commits and waiting for their fixes, stuff wouldn't never be pushed before weeks. That's what I'm trying to avoid here.
If Roots wants to do stuff himself, then fine. But he could just have said it himself or you could have asked what why I did what I did before playing the boss with me.
You say I'm creating tensions, fine. But you've just created one here.
Bertram {l Wrote}:You might have noticed that I closed the pull request without merging it. Meaning there is no merge point, like this one for instance:
https://github.com/Bertram25/ValyriaTea ... 76eb8b3bcd
As there is none, git doesn't know the commits are the same or not.
Bertram {l Wrote}:Now, for the case where I accept your pull request as is, you'll see a merge point in my commit history, meaning you can surely pull without doing all that.
If you want me to accept your pull requests more "as is", I can also tell you what to change before I accept it if you want, and if you're enough at ease with interactive rebasing. (git rebase -i)
charlie {l Wrote}:Just pull or ask to rebase next time. Don't create problems for other developers by refactoring their commits because you are OCDing on the commit log. Don't confuse commit log and changelog.
If you have a minor issue with a developer's change, either pull and then commit your fix and ask them to pull that, or direct them to fix it themselves accordingly.
Changing somebody's commits is a Git worst practice and creates work for you and for them and tension in the project.
Bertram {l Wrote}:If you have a minor issue with a developer's change, either pull and then commit your fix and ask them to pull that, or direct them to fix it themselves accordingly.
I would, if Roots was at ease to do it. I'm just trying to be proactive here. And I don't see the difficulty in erasing two obsolete commits one's repo before pulling.
Bertram {l Wrote}:In the manaworld project, we kept having problems with people which were not willing or not at ease with git to refactor their commits
before inclusion. By only pointing out problems in the commits and waiting for their fixes, stuff wouldn't never be pushed before weeks. That's what I'm trying to avoid here.
If Roots wants to do stuff himself, then fine. But he could just have said it himself or you could have asked what why I did what I did before playing the boss with me.
Users browsing this forum: No registered users and 1 guest