28 Feb
2013
28 Feb
'13
12:25 a.m.
On Thursday 28 of February 2013 00:57:26 Timothy Pearson wrote:
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
--
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