On Thu, Aug 06, 2009 at 10:02:49PM +0200, Nicolas wrote:
> If I make :
> for (;;) {
> $ git fetch
> $ git merge master
> <continue to dev>
> $ git commit
> }
> $ git rebase origin/master
>
> $ git format-patch origin/master
> OR
> $ git push -f progweb master
>
> In fact, if I "rebase", I have to force the push...
Hi Nicolas,
Sorry for the delay.
That's correct, if you rebase, you have to force your pushes.
Which is why I thought you were very kind when you were rebasing. :-)
The alternative method, and one we should maybe use now that you have
a git repo, is that you pull without rebase. This will just merge
your changes with my latest changes, and then when you're ready and
I'm ready, I can merge your tree. This avoids forced pushes.
This is how git works anyway, and how the kernel development
is done, AFAIK.
All I ask, if you do it this way, is that all your commits to your personal
tree are "publication ready". In other words, every commit needs a
proper description, and commits should be for one feature or bugfix at
a time.
I find that rebasing on a personal work branch during heavy development helps
me accomplish this:
git checkout -b work master
// do lots of one-feature commits
// these are done with:
for (;;) {
git add -p .
git commit
}
// double check my work, to make sure commits are in a logical
// order and nothing unnecessary is there
git rebase -i master
// then merge to and push master
git checkout master
git merge work
git push master
git branch -d work
Thanks,
- Chris
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Barry-devel mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel
