On 02/29/2016 12:44 PM, Konstantin Khomoutov wrote: > On Mon, 29 Feb 2016 00:29:07 +0100 Pablo Rodríguez wrote: > >> is there any way to stash already commited local changes against the >> published version in the remote server? > > No, but why would you want to?
Many thanks for your reply again, Konstantin. Well, after your reply I realized that I had to start using branches. (This was something I avoided as I considered too cumbersome for my basic needs [it seems that I was totally wrong].) > If you merely need to have a series of commits available somehow while > you'd like to temporarily reset the branch they were made on to its > state in a remote repo, just do exactly that: either fork a branch off > the tip of your updated branch or tag its tip and then reset the branch. > > If we suppose we're talking about the branch "master", and the remote > server is known as "origin", then you'd do something like this: > > First do > > git fetch origin > > to have origin/master updated to the state of "master" at "origin". > > Then either do > > git branch temp master Probably I prefer creating a branch. But isn’t it better to create the branch before fetching contents from the remote server? > Next, reset your local "master" to "origin/master": > > git checkout master > git reset --hard origin/master > > You might want to omit --hard or use --soft -- depending on whether > you'd like to keep your local changes in the index and/or in the work > tree. I guess hard would be the best option for me. > You then have your "master" "synchronized" with the same-named branch > as held at the remote server, so whatever you commit on it will push > cleanly to origin--of course, unless someone will have updated it by > their code in the mean time. No problem with that. > Having had local "master" reset to its remote state and its previous > state kept in a branch or tag, you might wish to bring those changes > back on the "rewound" state of "master"--by merely merging them > (`git merge`) or using cherry-picking (`git cherry-pick`). Welll, I would do that in due time. > You might also consider rebasing. If your original problem was to deal > with the case where you have a series of local commits on a branch > you'd like to push "upstream" but the upstream version of your branch > got updated so your commits can't be used to fast-forward it (don't push > cleanly) then you might use `git rebase`: > > git fetch origin > git checkout master > git rebase origin/master > > Would first reset your local "master" to point to the same commit > "origin/master" points at then find a point where the local "master" and > "origin/master" have diverged and then try to apply all the commits > your "master" have past that point--one-by-one--to that reset state. > The result, if all comes smoothly, will be the local "master" having all > your "unpushed" commits rebased onto the state of "origin/master", which > means you will be able to safely push your "master" to "origin". Fine, but too complex for me. And origin hasn’t been updated. > TL;DR > Don't try to abuse the stash. It's only use case is to save uncommitted > changes--those kept in the work tree compared to the index, and > those kept in the index compared to HEAD--and, possibly, untracked > files as well. That is, the stash keeps whatever changes would have > constituted a commit. If you need to preserve a series of commits just > preserve them naturally--by having a branch or a tag of them. Now I understand what I did wrong. I had expected from stash to behave like a branch. Many thanks for your help again, Pablo -- http://www.ousia.tk -- 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/d/optout.