git details
_sc_
7.2.108 i see something in the update.log i don't remember
seeing with svn:
src/feature.h: needs update
apparently git wants to bark at me because i had the
temerity to modify feature.h without sending my changes back
to the repository
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?
- replace my feature.h
- with no warning?
- with a message?
- merge the repository feature.h with my modified one?
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...
IIRC svn was mute on the fact that i had modified that file
and replaced it unmerged if it was modified in the svn
repository -- it was pursuant to me to watch his update.log
for 'feature.h' so i could re-apply my changes when it got
replaced
sorry to be such a high maintenance git newbie
sc
Markus Heidelberg
>
> now my old git has had an opportunity to upgrade my vim to
> 7.2.108 i see something in the update.log i don't remember
> seeing with svn:
>
> src/feature.h: needs update
I don't see this message when doing a pull with local changes. Maybe
due to the newer git version.
> apparently git wants to bark at me because i had the
> temerity to modify feature.h without sending my changes back
> to the repository
Come on, git it distributed, in contrast to subversion you have the
opportunity to do local commits. No need to have any local changes lying
around in your working tree. Just commit them and you are fine. To
update you can as always use "git pull" or if you want to see your
adjustments on top of the history "git pull --rebase". The --rebase
option for git-pull is supported since 1.5.3.6, so you would want to use
"git fetch" && "git rebase origin/vim-with-runtime" with your older git.
> 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?
Bark with an error and refuse to merge.
> - replace my feature.h
> - with no warning?
> - with a message?
Never.
> - merge the repository feature.h with my modified one?
Currently not. I'm not sure, if this will be supported sometime.
From man git-merge:
"you can have local modifications in your working tree as long
as they do not overlap with what the merge updates"
> 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...
With local commits this bite is avoidable and you don't have to be
afraid to accidentally delete your adjustments.
> IIRC svn was mute on the fact that i had modified that file
> and replaced it unmerged if it was modified in the svn
> repository -- it was pursuant to me to watch his update.log
> for 'feature.h' so i could re-apply my changes when it got
> replaced
svn does not have another possibility, because you cannot avoid having
local changes. Merges just have to be possible with local changes there.
> sorry to be such a high maintenance git newbie
Never mind. It helps me to enhance the README. But I still have to take
care of it not becoming a git documentation.
Markus
Nazri Ramliy
> 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.
> - replace my feature.h
> - with no warning?
> - with a message?
Yes if you specifically ask it to overwrite your local modification.
> - 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.
> 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)
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.
3. Manually keep it as separate patches.
> sorry to be such a high maintenance git newbie
Everyone is a newbie once. Nobody is born non-newbie is guess,
unless you're that Button guy.
nazri.
_sc_
>
> On Fri, Feb 13, 2009 at 5:04 AM, _sc_ <toot...@swbell.net> 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.
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
Markus Heidelberg
I can see it in the archives:
I will include it anyway:
_sc_, 12.02.2009:
>
> now my old git has had an opportunity to upgrade my vim to
> 7.2.108 i see something in the update.log i don't remember
> seeing with svn:
>
> src/feature.h: needs update
I don't see this message when doing a pull with local changes. Maybe
due to the newer git version.
> apparently git wants to bark at me because i had the
> temerity to modify feature.h without sending my changes back
> to the repository
Come on, git it distributed, in contrast to subversion you have the
opportunity to do local commits. No need to have any local changes lying
around in your working tree. Just commit them and you are fine. To
update you can as always use "git pull" or if you want to see your
adjustments on top of the history "git pull --rebase". The --rebase
option for git-pull is supported since 1.5.3.6, so you would want to use
"git fetch" && "git rebase origin/vim-with-runtime" with your older git.
> 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?
Bark with an error and refuse to merge.
> - replace my feature.h
> - with no warning?
> - with a message?
Never.
> - merge the repository feature.h with my modified one?
Currently not. I'm not sure, if this will be supported sometime.
From man git-merge:
"you can have local modifications in your working tree as long
as they do not overlap with what the merge updates"
> 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...
With local commits this bite is avoidable and you don't have to be
afraid to accidentally delete your adjustments.
> IIRC svn was mute on the fact that i had modified that file
> and replaced it unmerged if it was modified in the svn
> repository -- it was pursuant to me to watch his update.log
> for 'feature.h' so i could re-apply my changes when it got
> replaced
svn does not have another possibility, because you cannot avoid having
local changes. Merges just have to be possible with local changes there.
> sorry to be such a high maintenance git newbie
Never mind. It helps me to enhance the README. But I still have to take
Markus Heidelberg
> To
> update you can as always use "git pull" or if you want to see your
> adjustments on top of the history "git pull --rebase". The --rebase
> option for git-pull is supported since 1.5.3.6, so you would want to use
> "git fetch" && "git rebase origin/vim-with-runtime" with your older git.
I just realized, that this of course will also rebase the 'feat/'
branches you are using on top of 'vim-with-runtime'. I have to take it
back, the rebase solution is not recommend.
Markus
Markus Heidelberg
>
> On Thursday 12 February 2009 5:09 pm, Nazri Ramliy wrote:
> >
> > On Fri, Feb 13, 2009 at 5:04 AM, _sc_ <toot...@swbell.net> wrote:
> > > - 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 think the description was expressed a bit unlucky. What he wanted to
say is that you should just commit your changes. Of course the change
from the repository will surely never be the same. But a merge will
happen anyway.
> > 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
As stated in my previous post, I don't recommend a rebase. That's easy
to do, if you have only ONE remote upstream branch. But in this case you
have TWO or more: 'vim-with-runtime' and one or more features.
> > 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:
A patch solution should not be necessary with a DVCS.
> patch -R -p0 src/feature.h < myfeat.patch
> git pull
> patch -p0 src/feature.h < myfeat.patch
Note that if the feature branch is getting updates, you have to do an
additional "git merge origin/feat/xyz". You should add it into your
update script, even if in the normal case it's necessary. And the
updates can be one of two kinds:
1) enhancements or bugfixes of the feature
2) merge commits with solved conflicts
The first one is obvious. The second means, that a new Vim patch
conflicts with the feature and I manually solved the conflict. So
instead you having to solve the conflict yourself, you can just merge my
conflict resolution.
If you at first do "git pull" which means you firstly merge the
'vim-with-runtime' branch, then the conflict arises. So you should
rather firstly merge the feature branches, which leads to an update like
this instead of merely doing "git pull":
git fetch
git merge origin/feat/a
git merge origin/feat/b
git merge origin/vim-with-runtime
Or you could add your feature branches to your [branch "custom"]
section, so that it looks like this:
[branch "custom"]
remote = origin
merge = refs/heads/vim-with-runtime
merge = refs/heads/feat/a
merge = refs/heads/feat/b
Which will use the octopus merge strategy (merging multiple branches at
the same time), which I currently don't recommend in the README, because
once I did it and got merge conflicts, the part with the conflict
markers was not enough to resolve the conflict properly.
I have to investigate some more for the README, it indeed gets a bit
more complicated, if you have more then one corresponding remote
upstream branch.
Markus