On Saturday 14 February 2009 8:53 am, Markus Heidelberg wrote: [...] > > git add src/feature.h > > > > so git knows to track this module, then > > git is already tracking it, you staged your changes into the index.
uh oh [...] > > and by checking out to myfeatures last, the code flips back > > to my modified state and i'm ready to build > > But you only updated 'custom', your 'myfeatures' branch didn't get the > updates. You say it yourself: "the code flips back" or do I > misunderstand you? no, it really flips back -- i had thought that since feature.h was the only one i "added" it would be the only one flipping [...] > > so -- do you see something less than optimal here? > > Given that I your script doesn't update your 'myfeatures' branch, which > you want to build, here the setup I propose: > > git checkout -b custom origin/vim-with-runtime > git merge origin/feat/rel-line-numbers > vim src/feature.h > git add src/feature.h > git commit alright -- that certainly looks doable i whacked everything down to the vim72 path and started over with the clone > No need for a second branch. it went with everything else, and will not be re-created > And the relevant parts of what the update script should look like: > > git fetch > git merge origin/feat/rel-line-numbers > git merge origin/vim-with-runtime we were pulling, now we're fetching -- i really need to spend some quality time with the git docs i know it's not necessary, but i feel safer with a checkout to custom in front of the fetch -- his 'already there' message is not an error, and gives me a warm fuzzy that git's pointing where i want him to before i start > Note that the feature branches should be merged before the > 'origin/vim-with-runtime' or 'origin/vim'. Because if a feature branch > conflicts with new Vim patches, the conflict is already solved in the > merge commit of the feature branch. > > Look at commit 72e4bbc (Merge commit 'vim_mainline/vim' into > feat/rel-line-numbers, 2009-02-05), where a conflict at src/normal.c > occured because of commit 3afd138 (Patch 7.2.095) and try the following: > > # checkout a state before 7.2.095 > # checkout 'vim-with-runtime' at 7.2.093 > git checkout -b test 76a8acd > # merge 'feat/rel-line-numbers' at 7.2.093 > git merge 0a390f9 > # Now you are on 7.2.093 with the latest runtime files and the > # relativenumber feature. > > # Update to the latest version > git merge origin/vim-with-runtime # this will conflict > git merge origin/feat/rel-line-numbers > > If you switch the order of the last two git-merge commands, the merge > will be successfully. i created an 'experimental' path and re-cloned the repository to try the above, and i'm glad i did -- it is locked from the 2nd to last merge, exactly where you said a problem would appear, and the last merge errors out because i am "in the middle of a conflicted merge" i'd be pulling my hair out at this point if i were doing this in my real repository potentially a "git branch -d test" or "git branch -D test" would fix it ... no, i can't even checkout back to custom: ~/.build/vim/experimental/vim_extended $ git checkout custom fatal: you need to resolve your current index first this is fun -- i can thumb my nose at my unresolved index and hit the whack button i really appreciate all your hand-holding on this, markus, and i apologize for being so dense at times sc --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
