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"?
Note: Attached is both - both script and diff.
Slavek --
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:
- 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.
- 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
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:
- 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.
- 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 --
-
Slávek Banko -
Timothy Pearson