On 29 April 2015 at 10:14, Valencia <divinecreationsvo...@gmail.com> wrote:
> On Wednesday, April 29, 2015 at 1:08:03 PM UTC+5:30, Philip Oakley wrote:
>> ----- Original Message -----
>> From: Valencia
>> To: git-...@googlegroups.com
>> Sent: Wednesday, April 29, 2015 5:50 AM
>> Subject: [git-users] How to do a selective push
>> Say I have done 10 commits and I want to push only the 2nd and the 8th
>> commit. How to do this?
>> Can you describe what you think you will get.
>> Do you mean just the changes that #2 and #8 introduced (thus dropping the
>> changes in #1, #3..#7, #9 & #10). ['git rebase -i', and remove the offending
>> Or do you mean you want the graph to simply missout #1, #3..#7, #9 & #10,
>> but keep the snapshot of #2 & #8? ['git rebase -i', and squash the ones you
>> want omitted].
>> It's worth creating a duplicate branch [which only costs ~40 bytes] for
>> testing, and then reviewing the many and various tutorials on --interactive
>> The key is to be clear about what you want, what you expect, and how Git
>> actually works (as opposed to te many explanations that try to describe it
>> as if it is 'change management', rather than 'snapshot management')
> Thanks for your reply Philip
> And yes, I should have given more detailed requirement: well it goes like
> Requirement: I want to push just the 2nd and the 8th commit and I also don't
> want to loose the other commits. The others I may push later on.
> As I was trying to find a way out on my own I came across the cherry-picking
> concept. So I tried to cherry-pick, from other branch to my master branch,
> only those commits that I want to push to main repo. But again here I'm
> getting some merge conflicts.
> I would be glad if u could put some light on this "cherry-picking" concept.
First you have to understand the concept of the parent-child
relationship between commits, i.e. what a "history" is. Once you have
that under your belt it becomes a lot easier to understand what
cherry-picking is, and why using it sometimes fails.
> I am not so comfortable with the "rebase" concept, but, if there is any
> better way out using it, I am willing to understand.
Rebasing is all about rewriting history, among other things you can
merge a parent and child into a single commit and rearrange
Magnus Therning OpenPGP: 0xAB4DFBA4
email: mag...@therning.org jabber: mag...@therning.org
twitter: magthe http://therning.org/magnus
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.