On Thursday 12 February 2009 5:09 pm, Nazri Ramliy wrote:
>
> On Fri, Feb 13, 2009 at 5:04 AM, _sc_ <[email protected]> wrote:
> > src/feature.h: needs update
>
> It barks you because it honors your modification. Before updating
> your working tree with the latest tip of a branch (either by switching to
> a new branch or doing a pull), it tries very hard in making sure that
> the update will not bork your changes. IOW it won't replace your
> feature.h unless you really ask it to.
>
> > my question is: what will [my old] git do if/when feature.h
> > gets modified on the repository end?
> >
> > - bark at me with the same warning?
>
> By default, yes.
with no difference between warnings i could miss an update
to this module -- i don't much like this option
> > - replace my feature.h
> > - with no warning?
> > - with a message?
>
> Yes if you specifically ask it to overwrite your local modification.
in which case i'd lose my changes, also not a likable
option
> > - merge the repository feature.h with my modified one?
>
> Yes if you have 'git add'ed your modification to feature.h and that
> changes happens to be exactly the same as the new change coming
> in from the 'reposition end'. If it's not the same then the merge will not
> happen.
this sounds complicated and iffy -- doesn't get a lot of
points for likability either
> > i can not only live with getting barked at for having
> > uncommitted changes, i think it qualifies as a Good Idea --
> > but the attention called to this module as caused me to
> > wonder if his bark is as good as his bite...
>
> There a few alternatives to keeping your local changes:
>
> 1. Put it in the stash (git help stash)
oof -- we may have tripped over a reason an upgrade might be
in my future:
~ $ git help stash
No manual entry for git-stash
> 2. Commit it into your own branch, and rebase that branch against
> its 'parallel' remote branch every now and then when the
> 'repository end' is updated.
sounds doable, however complicated -- the downside i see to
this is the "every now and then" part -- i'd be back to my
old "svn ways", watching the update log and hopefully
catching any updates to feature.h
> 3. Manually keep it as separate patches.
this sounds like something i can do with my current state of
knowledge -- in fact, has none of the downsides i've been
moaning about concerning all the other options -- i'll be
reading the patch and diff man pages in the next few days,
but i envision my update script doing something along the
lines of:
patch -R -p0 src/feature.h < myfeat.patch
git pull
patch -p0 src/feature.h < myfeat.patch
which keeps me up to date and with unwanted features gone --
looking at this i wonder why i never did this back in the
good old svn days
thank you, nazri, this is going to be a nice addition to my
process
sc
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
