Github help

[nppangband]

This should be a simple task, but I can't make it work.

I just finalized NPP 0.5.3, and uploaded to the npp branch called work_in_progress. I want to push the changes to the branch called master. But I am not having any success, and I have this uneasy feeling the solution is so simple that the help files don't even bother to cover it. What should I be doing to simply make everything in the current work_in_progress branch push to the master branch?

The link is here:

https://github.com/nppangband/NPPAngband/tree/Work_in_progress

Thanks for any help or suggestions you can offer.

[fizzix]

I'm pretty much a novice at git but maybe this will work.

git push origin work_in_progress:master

[nppangband]

I think the proplem is that, on my computer the branch is called Master, and on github it is called master (no caps). They aren't recognized as the same branch. I think I first need to pull "master" from github to my computer, then make the changes & push back.

Edit: It worked, sort of. The work_in_progress branch had about a dozen commits in between 0.5.2 and 0.5.3, and the master branch now has taken all of the updates and has the final 0.5.3. But the master branch took each commit individually. What I was hoping to do in the master branch was to have a single commit showing all of the differences between 0.5.2 and 0.5.3. Or is that just not how github works?

[Magnate]

Edit: It worked, sort of. The work_in_progress branch had about a dozen commits in between 0.5.2 and 0.5.3, and the master branch now has taken all of the updates and has the final 0.5.3. But the master branch took each commit individually. What I was hoping to do in the master branch was to have a single commit showing all of the differences between 0.5.2 and 0.5.3. Or is that just not how github works?

Git will always default to what is called a "fast-forward" if it can. This is where every commit is replicated individually in the same order, as you observed. When using git push, this is the only possible way: git push will fail if it cannot be fast-forwarded (i.e. it cannot do merges).

The alternative is to use git merge. This will also default to fast-forward, but if it can't fast-forward it will merge and produce a summary commit, called the merge commit. IIUC this is what you want - I've never forced this to happen in preference to a fast-forward, but with git anything is possible. According to git help merge, you need to use the --no-ff option. So I think what you want to do is

git checkout Master
git merge --no-ff work_in_progress
git push origin Master:master

Please note that the merge commit is merely a summary: it does not replace the individual commits - they will be shown separately in the log. You can get rid of them by generating a huge patch (git diff commit1 commit2 >../052-to-053.patch) and then applying it as a single commit to your master branch. Not sure why you'd want to do that though, but it shouldn't take long.

EDIT: in case it's not clear, commit1 is the head of your master branch and commit2 is the head of your work_in_progress branch, and you need to generate the diff from the wip branch.

[d_m]

Edit: It worked, sort of. The work_in_progress branch had about a dozen commits in between 0.5.2 and 0.5.3, and the master branch now has taken all of the updates and has the final 0.5.3. But the master branch took each commit individually. What I was hoping to do in the master branch was to have a single commit showing all of the differences between 0.5.2 and 0.5.3. Or is that just not how github works?

I don't think it's a great idea to squash all your work between 0.5.2 and 0.5.3 into one commit.

That said, you can combine commits if you want. The general way to do this is to use rebase. Once you've used git a little bit more and gotten more comfortable with it I can try to explain how this is done. But since it modifies your commits, you can lose work if you aren't careful, so I will hold off for now.

[nppangband]

I don't think it's a great idea to squash all your work between 0.5.2 and 0.5.3 into one commit.

That said, you can combine commits if you want. The general way to do this is to use rebase. Once you've used git a little bit more and gotten more comfortable with it I can try to explain how this is done. But since it modifies your commits, you can lose work if you aren't careful, so I will hold off for now.

I do now realize you both are right & it is better this way. I am still getting used to everything github can do. I still only commit code after I have done a dozen changes or so. I really should try to have only one purpose to each commit.

My main thinking behind having only commit for each final release is that most of my commits contain bugs that are fixed later, so the good, working code that makes a useful patch are spread out over several commits. But of course, I can always just run a diff between different commits for that. And if I am really stuck on the idea of having one commit per version, I should just open up a second repository.

Thanks again for the help.

[d_m]

My main thinking behind having only commit for each final release is that most of my commits contain bugs that are fixed later, so the good, working code that makes a useful patch are spread out over several commits. But of course, I can always just run a diff between different commits for that. And if I am really stuck on the idea of having one commit per version, I should just open up a second repository.

The case where you commit, realize there are bugs, and want to combine the earlier commit with its bugfix is a common one. If the commits occur next to each other it's usually not too hard to accomplish this. However, if they are spaced out (and include other changes as well) it can be more trouble than it's worth.

Hope getting up to speed with Git isn't too painful, and welcome to Github!

[Magnate]

The case where you commit, realize there are bugs, and want to combine the earlier commit with its bugfix is a common one. If the commits occur next to each other it's usually not too hard to accomplish this. However, if they are spaced out (and include other changes as well) it can be more trouble than it's worth.

Hope getting up to speed with Git isn't too painful, and welcome to Github!

If I've understood git correctly (and I'm no expert), the idea is that things are as atomic as possible, i.e. more commits is better. So yes, it can be painful/embarrassing to realise there's a bug in your commit, but you simply commit a fix with "fix for logic bug in 3cd4f65" or whatever.

Rebase is a special form of merge btw. It doesn't set out to squash commits together - if all the work can be fast-forwarded onto the new base, it will be. It's just that it usually can't, and a merge commit results. (In such a case, conflicting individual commits are *not* replicated separately from the merge commit.)

If you're thinking "but what if I want my original commit and its bugfix commit, without all the stuff in between", then you need git cherry-pick. This takes just the commit(s) you specify, and applies them to your current branch. So you can cherry pick the commit you want, and any bugfix commit(s) for it, all neatly in your master branch. This is one reason that small atomic commits are good: you can't cherry pick a commit if it does more than just the thing you want.

[nppangband]

Hope getting up to speed with Git isn't too painful, and welcome to Github!

I think I am picking it up, thanks to youall. For the first time I actually prefer using a prompt to the GIT GUI. You all will make a real programmer out of me yet.

[AnonymousHero]

Rebase is a special form of merge btw. It doesn't set out to squash commits together - if all the work can be fast-forwarded onto the new base, it will be. It's just that it usually can't, and a merge commit results. (In such a case, conflicting individual commits are *not* replicated separately from the merge commit.)

You're talking about "gitt pull --rebase". I think d_m is talking about "git rebase -i ...". That is quite different and extremely powerful for cleaning up history before submitting upstream (squashing, rearranging the order of commits for clarity, etc.). It should be wielded with care though, especially if you've already published your changes somewhere public.

@d_m: Though rebase will let you drop commits (thus losing history), you can always get back to where you started by using "git reflog" and doing a "git reset --hard ABCDE" where ABCDE is an appropriate entry from the reflog.