I received the new pull request and I have merged it successfully into master (after testing on my installation).
Concerning your questions: I think most of them are resolved since you created the correct pull request.
And concerning the invalid pull request: on the web interface there is a 'close' button. To close the pull request, just click it (I did that already for you) :-)
Op 27-nov.-2012, om 22:32 heeft Jim Duda <jim@...> het volgende geschreven:
> Lieven Hollevoet <lieven <at> lika.be> writes:
>> Hi Jim,
> First, I'm typing in a web browser, with a limited width. There might be
> some erroneous format issues in this post.
>> Op 27-nov.-2012, om 04:43 heeft Jim Duda <jim <at> duda.tzo.com> het volgende
>>> I'm trying to reconcile in my head a difference between svn and git.
>>> I just made changes to five files. In git, I did a commit of these five
> files in a branch called android_updates.
>>> I pushed the branch changes to github://jduda/misterhouse. I then created a
> pull request for the git master
>>> to merge into the hollie/misterhouse master branch. I'm fine with this.
>> Actually, I'm not really
>> If you look closely here: https://github.com/hollie/misterhouse/pull/18
>> you see that you have asked to merge all changes between master and your
> personal branch into hollie/master.
> No, I don't want this. I know where these are files are coming from, but
> they are not important, just some debugging that I've done in the past.
> How do I withdraw a pull request?
>> This is not exactly what you're trying to obtain. I guess you're trying to get
> only these changes in master:
> Yes, this is all I wanted to have you pull. Am I not doing the pull in
> the proper way? Can I just pull a single commit?
>> Please confirm and I will cherry-pick them from your repo.
> Please don't. I need to learn how to do this properly.
>> The root cause of the unclean pull request is that you want to keep a
> personal/specific version of files that
>> are under revision control but that should not be merged into master. Note
> that I'm not accusing you of
>> something, as this situation is based on my recommendation that you could
> proceed in this way (more on that
>> at the end of the mail).
>> Those personal files should never make it to the main repo according to you. I
> can live with that (partially
>> that is, according to me and if possible they should be fixed to solve your
> problem and make it into master).
>> However, if you then actually develop on that personal branch and you want to
> apply only the last changes to
>> master, then you cannot merge your branch with master because every time you
> do that, you tell git to apply
>> the changes you made in your branch (including your personal changes) to
> master. If you want to only apply a
>> specific commit to master you need to cherry-pick as documented
> None of these other changes are a problem if they get into the master. It's
> all debugging stuff, harmless.
> I think what I need to do is wipe everything clean, including my fork, and
> start from scratch.
> Believe it or not, I think I'm finally starting to catch on here.
> For these other files, I should have checked them into some other branch.
> Somehow, I managed to cross jduda_working and android_updates.
>>> With svn, after I did the commit, my changes were in the mother-ship and I
> was done.
>> Yes, you were done, but I think that was actually only half of the work that
> should be done to ensure that HEAD
>> is working fine. Since you replaced certain files from the mothership in your
> own working copy, your
>> working copy did not reflect HEAD. So to be sure HEAD was working you had to
> checkout HEAD on a separate
>> location and test. Right?
> Yes, and no. In most cases I will simply do an svn update to head. Test one
> more time, then commit the files I wanted to from the set of modified files
> in my sandbox. Occasionally, based upon the severity of the change, I would
> use a "clean" sandbox and do what you say, update to head in this sandbox and
> run a regression test. At work, I work with a group of 20-30 ppl, we all
> "cheat" this way, but it works for the most part.
>>> With git, it seems that these changes are off "in limbo". I don't get any
> indication with a git status
>>> that says there are outstanding commits which are ahead of what is in my
> master. As far as git status
>>> is concerned, I am done. But in reality, I have these changes which are
> sitting in the wind.
>> No, that is not correct. If you ask git to update your local clone with the
> changes that made it to the upstream
>> master, the tool would tell you this if you 'git status'. You ask git to
> update by doing a 'git fetch
>> upstream'. If you don't do this, git is not aware of updates in remote repos
> and hence will not report them to you.
> I just tried this again.
> linux> git fetch upstream
> remote: Counting objects: 27, done.
> remote: Compressing objects: 100% (12/12), done.
> remote: Total 16 (delta 10), reused 10 (delta 4)
> Unpacking objects: 100% (16/16), done.
>> From github.com:hollie/misterhouse
> * [new branch] fix_tts_for_os_x -> upstream/fix_tts_for_os_x
> 6662dd0..068afe0 master -> upstream/master
> linux> git status
> # On branch android_updates
> # Changes not staged for commit:
> # (use "git add <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working directory)
> no changes added to commit (use "git add" and/or "git commit -a")
> I think what I'm looking for is how do I get git to tell me that
> my origin has a branch which is different than the upstream master.
> linux> git remote -v
> origin git@... (fetch)
> origin git@... (push)
> upstream git@... (fetch)
> upstream git@... (push)
>>> After my commit and push to my github clone, I have this:
>>> linux> git status
>>> # On branch android_updates
>>> # Untracked files:
>>> # (use "git add <file>..." to include in what will be committed)
>>> # nothing added to commit but untracked files present (use "git add" to
>>> It seems to clean to me. Shouldn't there be something to tell me that I
>>> commits which are different than the master? In reality, my sandbox is out-
>>> with master, which is okay, but how do I know?
>> git fetch upstream
>> git status.
> See above.
>> Now on the 'more on that at the end of the mail'. Since I recommended you to
> commit your local changes to a
>> branch, I learned a bit more from the way you're trying to work. Let's say
> that the way you want to work does
>> not completely matches my expectations form when I made the recommendation. My
> impression was you were
>> planning to have your own branch with modifications and that you would work on
> master to apply changes.
>> Tracking master in your local branch is in that case a no-brainer. However,
> since you're working on your
>> local branch and you only want to apply certain changes from the branch,
> you'll need to cherry-pick them.
>> This works but is not the most easy way to use git.
>> Options are:
>> * you continue as you're doing, and you cherry-pick changes to your local
> master instead of merging your
>> complete branch. I can then merge your cherry-picks easily with hollie/master.
> I believe I simply need to do a better job at managing my branches.
>> * you get rid of the local files and work with a simple master/feature branch
> setup. Actually is there a
>> reason to keep certain files specific to your working copy? The changes you
> made I see are mostly logging
>> prints. Why can't they make it to master? An additional advantage of this
> would be that you're immediately
>> testing on master before committing.
> The only reason I have things that I don't want in Master are mainly for
> work-in-progress things that aren't ready for community. With svn, I could
> just leave them in my sandbox and "cherry-pick" them to push when ready.
> Whenever I did an svn update, svn would simply merge changes into my sandbox
> even though I had modified files. Rarely, but occasionally, svn couldn't merge
> on the svn update and I had to fix a conflict.
> I believe this is the mode I want to work with. I just need to learn how
> to keep my branches organized or learn how to "stash" changes away.
> Final Questions:
> How do I withdraw the PULL?
> Can you just delete it?
> I will submit a new one with only the changes I want.
> I will figure out how to clean up my sandbox.
> Keep yourself connected to Go Parallel:
> DESIGN Expert tips on starting your parallel project right.
> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365