файлов на Visual Studio Team Services рассинхронизации (Git репо)

Question

Возможно что-то отсутствует действительно тривиальным здесь, но изо всех сил, чтобы понять выход ..

Мы имеем установку репозитория Git на Visual Studio Team Services. С 1 февраля несколько файлов, похоже, не синхронизированы с их историей совершения. Их история содержит множество недавних изменений, но, вытаскивая последнюю версию, мы фактически получаем старые копии.

Непонятно, могли ли кто-либо из команды случайно напечатать странные команды в удаленном репозитории.

Совершенно очевидно, что «текущие» удаленные версии, видимые через веб-портал VSTS, кажутся старше, чем они должны быть в соответствии с их историей (так что это не проблема только с локальными репозиториями).

Ниже только один пример:

Текущая версия История

Изменения

Последние совершают

Даже если последний коммит показывает были добавлены несколько новых линий, в «текущей версии» файла не содержит их .. И нет никаких дополнительных фиксаций в истории !

Любые предложения о том, как проверить, что происходит на удаленном репо и исправить, или это известная проблема на VSTS (у них были проблемы в последнее время, и обслуживание было вниз вчера ..)

Answer 1

Это, скорее всего, связано с неудачным слиянием. Вероятно, произошло то, что кто-то сделал тягу, получил некоторые конфликты, разрешил упомянутые конфликты, а затем заметил, прежде чем совершить слияние, что у него была куча поэтапных изменений, которые не были его (и никак не связаны с конфликтами). Он считает, что это странная ошибка git или что-то еще, и отбрасывает эти изменения, а затем совершает. Отброшенные изменения - те, которые вам не хватает; они должны были совершены с этим слиянием. Причина, по которой вы не видите, что это «отмена» фиксации в истории для файла, заключается в том, что по умолчанию git (и другие инструменты) не отображают комманды слияния в истории файлов, если файл не отличается от обоих родителей слияния. Если вы делаете git log <filename> --full-history, вы должны увидеть фиксацию слияния, которая вернула файл в более старую версию. Мораль истории: когда вы совершаете слияние, совершайте ВСЕ поэтапные изменения, даже если (или особенно если) вы их не делали.

EDIT: Одна опасная вещь о неудачных слияний является то, что они могут произойти без кого-то, заметив, довольно долгое время, тем более, что они не отображаются в стандартном git log файла (ов), чьи изменения были потеряны. Следующий скрипт обнаружит большинство неудачных слияний, сообщив, какие файлы потеряли изменения. Он может быть изменен, чтобы использоваться как крючок фиксации, чтобы проверять определенные коммиты и т. Д. Он работает, видя, есть ли файлы, возвращенные слиянием, в состояние, в котором они находились, когда две ветви были разведены.

Обратите внимание, что я новичок, когда дело доходит до shell-скриптов, поэтому, пожалуйста, простите плохое качество кода.

isChangeInBaseChanges() { 
    for element in ${baseChanges[@]}; do 
    if [ $element == $change ] 
     then 
     return 1 
    fi 
    done 
    return 0 
} 


for merge in `git rev-list --min-parents=2 --all`; do 
    mergeChanges=`git log -m -1 --name-only --pretty="format:" $merge | sort -u` 
    mergeBase=`git merge-base $merge^ $merge^2` 
    baseChanges=`git diff --name-only $merge $mergeBase` 

    lostFiles=() 
    for change in ${mergeChanges[@]}; do 
    isChangeInBaseChanges 
    if [ $? -ne 1 ] 
    then 
     lostFiles+=($change) 
    fi 
    done 

    if [ ${#lostFiles[@]} -ne 0 ] 
    then 
    echo -n "Possible botched merge at " 
    echo $merge 
    echo "files with lost changes are: " 
    for lostFile in ${lostFiles[@]}; do 
     echo $lostFile 
    done 
    echo -------------------------------------------- 
    fi 

done