Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Development

Reply
 
Thread Tools Display Modes
Old September 17, 2011, 02:42   #1
nppangband
NPPAngband Maintainer
 
Join Date: Dec 2008
Location: Stat Gain, Angband
Posts: 926
nppangband is on a distinguished road
Github help

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/NPPAng...rk_in_progress

Thanks for any help or suggestions you can offer.
nppangband is offline   Reply With Quote
Old September 17, 2011, 04:22   #2
fizzix
Prophet
 
Join Date: Aug 2009
Location: Madison, Wisconsin, US
Posts: 3,001
fizzix is on a distinguished road
I'm pretty much a novice at git but maybe this will work.

git push origin work_in_progress:master
fizzix is offline   Reply With Quote
Old September 17, 2011, 09:11   #3
nppangband
NPPAngband Maintainer
 
Join Date: Dec 2008
Location: Stat Gain, Angband
Posts: 926
nppangband is on a distinguished road
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?

Last edited by nppangband; September 17, 2011 at 10:04.
nppangband is offline   Reply With Quote
Old September 17, 2011, 12:27   #4
Magnate
Angband Devteam member
 
Join Date: May 2007
Location: London, UK
Posts: 5,057
Magnate is on a distinguished road
Send a message via MSN to Magnate Send a message via Yahoo to Magnate
Quote:
Originally Posted by nppangband View Post
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.
__________________
"3.4 is much better than 3.1, 3.2 or 3.3. It still is easier than 3.0.9, but it is more convenient to play without being ridiculously easy, so it is my new favorite of the versions." - Timo Pietila
Magnate is offline   Reply With Quote
Old September 17, 2011, 16:11   #5
d_m
Angband Devteam member
 
d_m's Avatar
 
Join Date: Aug 2008
Location: Philadelphia, PA, USA
Age: 38
Posts: 1,516
d_m is on a distinguished road
Quote:
Originally Posted by nppangband View Post
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.
__________________
linux->xterm->screen->pmacs
d_m is offline   Reply With Quote
Old September 17, 2011, 17:10   #6
nppangband
NPPAngband Maintainer
 
Join Date: Dec 2008
Location: Stat Gain, Angband
Posts: 926
nppangband is on a distinguished road
Quote:
Originally Posted by d_m View Post
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.
nppangband is offline   Reply With Quote
Old September 17, 2011, 17:19   #7
d_m
Angband Devteam member
 
d_m's Avatar
 
Join Date: Aug 2008
Location: Philadelphia, PA, USA
Age: 38
Posts: 1,516
d_m is on a distinguished road
Quote:
Originally Posted by nppangband View Post
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!
__________________
linux->xterm->screen->pmacs
d_m is offline   Reply With Quote
Old September 17, 2011, 18:20   #8
Magnate
Angband Devteam member
 
Join Date: May 2007
Location: London, UK
Posts: 5,057
Magnate is on a distinguished road
Send a message via MSN to Magnate Send a message via Yahoo to Magnate
Quote:
Originally Posted by d_m View Post
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.
__________________
"3.4 is much better than 3.1, 3.2 or 3.3. It still is easier than 3.0.9, but it is more convenient to play without being ridiculously easy, so it is my new favorite of the versions." - Timo Pietila
Magnate is offline   Reply With Quote
Old September 18, 2011, 02:13   #9
nppangband
NPPAngband Maintainer
 
Join Date: Dec 2008
Location: Stat Gain, Angband
Posts: 926
nppangband is on a distinguished road
Quote:
Originally Posted by d_m View Post

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.
nppangband is offline   Reply With Quote
Old September 20, 2011, 22:11   #10
AnonymousHero
Veteran
 
AnonymousHero's Avatar
 
Join Date: Jun 2007
Posts: 1,365
AnonymousHero is on a distinguished road
Quote:
Originally Posted by Magnate View Post
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.
AnonymousHero is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Getting Angband from Github and compiling it Magnate Development 114 December 17, 2016 23:58


All times are GMT +1. The time now is 17:18.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.