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 --