Randal L. Schwartz, Wed, Jun 13, 2007 17:01:14 +0200: > > We have some CVS users who complain that they cannot do a pull > > into a dirty working tree, as they could under CVS. Here is > > their scenario: they make a few changes to their code and want > > to test it out; someone else pushes changes to the central repo > > that they then want to add to their working tree to test also; > > they then want to pull in these changes and test everything, as > > if they had done 'mv stuff stuff-; git pull; mv stuff- stuff'. > > > They would like an option (perhaps a config option) to do a "dirty > > pull". > > Maybe this will do it, presuming they haven't published any of their local > work, and they're on a topic branch "topic" > > git-tag WIP # mark HEAD so we can come back > git-commit -a -m WIP # commit current work so we can replay it > git-fetch origin # grabs the upstream > git-rebase origin # rebase current work-in-progress onto new upstream > # might need to resolve and commit conflicts repeatedly > git-reset --soft WIP # next commit will be on top of commit prior to rebase > git-reset # mark all files as uncommitted as yet > git-tag -d WIP # no more need for this tag > > This effectively puts the upstream changes "under" (or "prior to") the current > topic branch. > Wont work for new files (not yet known to git) which conflict with the same names from origin. Your method will not put them anywhere and their presence will break git-rebase. You _must_ do a merge. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
