[git-users] Re: git rebase keeps giving the conflict
On Monday, September 23, 2013 6:02:22 AM UTC+2, dexter ietf wrote: On Saturday, September 21, 2013 5:18:13 PM UTC+5:30, dexter ietf wrote: hi, i cloned a new tree, made changes to file readme.txt meantime readme.txt in the remote has changed at the same location. when i do a git pull i got merge conflicts, i resolved the conflicts and did a 'git commit' So far so good. After this commit, you have a merge commit where your local commits joined together with the remote commits. This merge commit includes the fixes from the conflicts you resolved. now i did git rebase, Now why on earth would you do rebase at this point? When you want to merge with another branch of development, you EITHER rebase OR merge. In the above case you decided to pull, which means fetch merge. So what happens when you try rebasing a branch that you already merged? Well, your local commits, including the merge commit we talked about earlier, are temporarily removed, then the remote commits are played back first. And then your local commits are played back on top of that again. If you can follow that reasoning (read up on rebase if not), what happens now is: - your local commits are applied in running order - the first commit that does not apply cleanly will create a conflict similar to the one you had before - rebase will now stop, and ask you to resolve the conflicts - if you resolve the conflicts and continue, you'll later run into your local merge commit, where you have to resolve conflicts that have already been resolved in the previous step. No doubt this will lead to more conflicts that have to be resolved. If you do resolve the conflicts again and continue through with the rebase, you should get through it OK. However, you were on the wrong track already when you tried rebasing in changes that you had already merged. I would advise you to first decide whether you want to merge or rebase, then have a good look at the `git reflog`, find the last state you had before the mess, and then `reset hard` back to this. Do take a full copy of your git repository before doing anything more though. Maybe all of this seems intimidating and complicated, but it's a classic case of Git's freedom allowing you to chop of your own foot. Luckily it's easy to reset the foot back on again :) -- 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] git pull: Observation for local / NFS bare repository
I use git to help me synchronize my files between my work machine and home machine (both Linux based). The bare repository is accessed from my work machine via SSH. On my home machine, it is on an NFS server. As an aside, the work machine accesses the NFS server via the home machine via SSH, not directly from the NFS server. I noticed when I do a git pull, git will apparently recompress the data before sending it. This makes sense to me when it is not local, i.e. from my work machine, in order to decrease the number of bytes transmitted. But it doesn't make sense at all when the repository is local (on the local HD or NFS mounted) because the data is now coming into the machine twice. First to recompress it, then to transfer it into the working directory. Now, on my internal gig-ethernet network, this is likely not a big deal. But I am wonder if it would be a good idea to mention this to the developers. IOW, are there many people who use a bare repository over a _slow_ NFS link? Or is it so rare that it would not be worth using up their time? Thanks for your thoughts on this. -- As of next week, passwords will be entered in Morse code. Maranatha! John McKown -- 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] git pull: Observation for local / NFS bare repository
On Mon, 23 Sep 2013 10:10:24 -0500 John McKown john.archie.mck...@gmail.com wrote: I use git to help me synchronize my files between my work machine and home machine (both Linux based). The bare repository is accessed from my work machine via SSH. On my home machine, it is on an NFS server. As an aside, the work machine accesses the NFS server via the home machine via SSH, not directly from the NFS server. I noticed when I do a git pull, git will apparently recompress the data before sending it. This makes sense to me when it is not local, i.e. from my work machine, in order to decrease the number of bytes transmitted. But it doesn't make sense at all when the repository is local (on the local HD or NFS mounted) because the data is now coming into the machine twice. First to recompress it, then to transfer it into the working directory. Now, on my internal gig-ethernet network, this is likely not a big deal. But I am wonder if it would be a good idea to mention this to the developers. IOW, are there many people who use a bare repository over a _slow_ NFS link? Or is it so rare that it would not be worth using up their time? What's the URL you're using to access the repository on NFS? The trick is that if you're using the explicit file:// scheme Git spawns two processes which then communicate even if this happens on the local host. Conversely, if you're using just a regular (full) Unix pathname, like /a/path/to/the/repository, Git tries to be more clever when accessing it, and even does hardlinking where applicable. Not sure this makes sense for your situation though... -- 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
