On Thursday 28 of February 2013 00:57:26 Timothy Pearson wrote:
> > Hello everyone,
> >
> > During the current work on repairing unintended renames I often use to
> > bulk
> > commit commit_all_submodules script. That's why I worked on some of the
> > improvements.
> >
> > The first change is that I moved "git pull" after check whether in the
> > module
> > are any changes to push to the server. The advantages are two:
> >
> > 1) If the module does not contain changes, it is omitted both - pull and
> > push.
> > Step to pushing changes to the server can be significantly faster.
> >
> > 2) In general commit to 'tde' are not included unrelated changes in the
> > modules in which was pushed commits from some other developers.
> >
> > The second change is that I added to "git pull" option --rebase. The
> > advantage
> > is that if changes were made on both sides - on the server and also in
> > the local git clone, then instead of merge temporary local branch are
> > local changes "rebased" to current HEAD on the server in order to
> > maintain linear
> > history without unnecessary merges. As you can see on my commits to
> > master 'tde' repository.
> >
> > What is your opinion on the use of "--rebase"?
>
> Rebase usage in general should be OK as long as it is never used to
> rewrite existing history on the GIT server.
>
> Tim
>

Yes - in the proposed changes is rebase used together with git pull - that is, 
before pushing the changes on the server.

Safe is also use rebase in a situation where an attempt to push stops for a 
newer version on the server and perform an automatic merge. Before re-pushing 
can be used rebase to achieve linear history.

No objections to the proposed changes commit_all_submodules?

Slavek
--