##############
+# check git version to see if we can use autostash.
+# this appears to be an ubuntu issue, where xenial did not provide it even though the
+# feature appeared in git 2.6 and xenial claims it has git version 2.7.4. eventually,
+# this version test can go away.
+gitvertest="$(git version | sed -e 's/git version [0-9]\.//' | sed -e 's/\.[0-9][0-9]*$//' )"
+if (( $gitvertest >= 11 )); then
+ # auto-stash is not available until 2.6 for git, but ubuntu is misreporting or using a
+ # differing version number somehow. we are sure autostash was missing on ubuntu xenial
+ # with git 2.7.4 and it's definitely present in zesty with git at 2.11.
+# PULL_ADDITION='--rebase --autostash'
+#although initially attractive, above set of flags seems to lose history we don't want to
+#lose.
+PULL_ADDITION=
+fi
+
+##############
+
# the maximum depth that the recursive functions will try to go below the starting directory.
export MAX_DEPTH=5
# use our splitter tool for lengthy output if it's available.
-if [ ! -z "$(which splitter)" ]; then
+if [ ! -z "$(which splitter 2>/dev/null)" ]; then
TO_SPLITTER="$(which splitter)"
# calculate the number of columsn in the terminal.
cols=$(get_maxcols)
if [ $nicedir == "." ]; then
nicedir=$(\pwd)
fi
- local blatt="echo checking in '$nicedir'..."
+ local blatt="echo -n checking in '$nicedir'... "
do_update "$directory"
test_or_die "repository update--this should be fixed before check-in."
fi
# a new set of steps we have to take to make sure the branch integrity is good.
- do_careful_git_update "$(\pwd)"
+ puff_out_list "$(\pwd)"
# we continue on to the push, even if there were no changes this time, because
# there could already be committed changes that haven't been pushed yet.
# upload any changes to the upstream repo so others can see them.
- git push origin "$(my_branch_name)" 2>&1 | grep -v "X11 forwarding request failed" | $TO_SPLITTER
+ git push --tags origin "$(my_branch_name)" 2>&1 | grep -v "X11 forwarding request failed" | $TO_SPLITTER
promote_pipe_return 0
test_or_die "git push"
show_branch_conditionally "$this_branch"
# this code is now doing what i have to do when i repair the repo. and it seems to be good so far.
+ # note that we allow the local branch to be merged with its remote counterpart; otherwise we would
+ # miss changes that happened elsewhere which should be seen in our local copy.
local branch_list=$(all_branch_names)
local bran
for bran in $branch_list; do
remote_branch_info=$(git ls-remote --heads origin $bran 2>/dev/null)
if [ ! -z "$remote_branch_info" ]; then
# we are pretty sure the remote branch does exist.
- git pull --no-ff origin "$bran" | $TO_SPLITTER
+ git pull --tags $PULL_ADDITION origin "$bran" | $TO_SPLITTER
+# we may want to choose to do fast forward, to avoid crazy multiple merge histories
+# without any changes in them. --no-ff
promote_pipe_return 0
fi
test_or_die "git pull of remote branch: $bran"
# now pull down any changes in our own origin in the repo, to stay in synch
# with any changes from others.
- git pull --no-ff --all | $TO_SPLITTER
+ git pull --tags $PULL_ADDITION --all | $TO_SPLITTER
+#is the above really important when we did this branch already in the loop?
+#it does an --all, but is that effective or different? should we be doing that in above loop?
+# --no-ff
promote_pipe_return 0
test_or_die "git pulling all upstream"
elif [ -d ".git" ]; then
if test_writeable ".git"; then
$blatt
- git pull --no-ff 2>&1 | grep -v "X11 forwarding request failed" | $TO_SPLITTER
+ git pull --tags $PULL_ADDITION 2>&1 | grep -v "X11 forwarding request failed" | $TO_SPLITTER
+#ordinary pulls should be allowed to do fast forward: --no-ff
promote_pipe_return 0
- test_or_die "git pull of origin without fast forwards"
+ test_or_die "git pull of origin"
fi
else
# this is not an error necessarily; we'll just pretend they planned this.