_sc_, 14.02.2009:
>
> On Friday 13 February 2009 7:27 pm, Markus Heidelberg wrote:
> [...]
>
> > I recommend rebase when having just one remote branch for updating the
> > custom branch.
>
> there are so many ways of using git i'd like to re-hash what
> i've done so you can correct me or not -- i *think* i've got
> it set up and happy
>
> first i reverted my feature.h to its unmodified pristine
> mainline form -- then
>
> get checkout -b myfeatures
>
> to create a local branch -- then i modified feature.h, then
>
> 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.
> git commit
>
> so he knows that's the way i want it
>
> in order to keep git happy i added checkouts to my update
> script:
>
> #!/bin/bash
> set -e
> cd ~/.build/vim/vim72/vim_extended
> tail ~/.build/vim/update.log
> dttm | tee -a ~/.build/vim/update.log
> git checkout custom 2>&1 | tee -a ~/.build/vim/update.log
> git pull 2>&1 | tee -a ~/.build/vim/update.log
> git checkout myfeatures 2>&1 | tee -a ~/.build/vim/update.log
> dsh 60 | tee -a ~/.build/vim/update.log
>
> 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?
> it's cool the way the code on src changes when i use git to
> checkout between custom and myfeatures -- i had fun with
> that -- also i made use of git log, git branch, git status,
> and git diff --cached as i was working through this
>
> i am now very favorably impressed with git -- the words
> people use when discussing it are starting to make sense to
> me -- after seeing src/feature.h change by virtue of doing
> those checkouts i became an instant fan
I also had the moment, where i made *click* and there are still moments
you learn something new for more *clicks* :)
> and before i forget, i got help from a friendly expert on
> irc: freenode has a #git channel and my newbieness was
> tolerated extremely well -- say hi to jast if you go there
I'm not a big IRC user. I once looked in into #git, but left after some
time.
> 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
No need for a second branch.
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
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.
Markus
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
