不思議な事を削除するGit(実際にはdjango-storage)

問題:時にはそうではないが、Gitはリポジトリの static ディレクトリを削除する。私たちはそれが何を引き起こすのかはっきりしていませんが、ブランチをマージしたりブランチをチェックアウトしたりするときに発生するようです。それは尋ねることなくこれを行い、追跡されたファイルを食べる。

背景:

  • I have a (private) project which has a few branches, 'release', 'develop', multiple feature lines.
  • There are two of us (me and @stevejalim) working on the repo. This problem happens to both of us.
  • I am using purely the command line for my git commands; Steve is using a mixture of the command line and Git Tower.
  • It's a Django project with a static directory. We may have git rmed the static directory at some point in the past, or put it in .gitignore, but not recently. And the head of our develop branch doesn't have static in .gitignore and has files in static tracked.
  • This happens so infrequently that we're not sure if it's something we're doing, or an intermittent problem, a bug with Git, or a corrupted tree
  • It might happen only when merging another branch back into develop. But branches are always branched from develop and back into develop. But we're not sure.
  • We are using git-flow, but the issue happens when using non-git-flow commands, too.

  • As examples of when this can strike:

    1) Steve had a develop branch that was clean (no changes to commit or stage) and stable. He cut a new release with git flow release start|finish and in the process (possibly the back-merge from master to develop), the entire /static/ tree got deleted.

    2) Steve repaired the delete by discarding the changes (to essentially undelete the file). But then, Steve simply switched from master back to develop and the /static/ dir got zapped again (this was with Git Tower)

    3) Sometimes just merging from a feature branch to develop as an interim merge can trigger it. It does seem to happen most often when cutting a new release, though

それは/ static/dirのザッピングをどのように修復するのかと関係がありますか?削除されたものを一括取り消しする最良の方法は何ですか?ローカルの変更を破棄することも、HEADにハードリセットすることも、事態を治すことにはなりません。 rebaseは私たちを助けるかもしれない?

UPDATE We've just experienced this again simply with a git add . - no changing branches, no merging. Does that help diagnosis at all?

Steveの.git/configの内容は次のとおりです。

[core]
   repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*
    url = [email protected]:foobarbazbam/bar.git
[branch "master"]
    remote = origin
    merge = refs/heads/master
[gitflow "branch"]
    master = master
    develop = develop
[gitflow "prefix"]
    feature = feature/
    release = release/
    hotfix = hotfix/
    support = support/
    versiontag = 
[difftool "tower"]
    cmd = \"/Applications/Tower.app/Contents/Resources/CompareScripts/kaleidoscope.sh\" \"$LOCAL\" \"$REMOTE\"

.gitignore の内容は次のとおりです。

.DS_Store
*.pyc
*.log
*.log.*
*.bak
*~
settings_local.py
/build/
/static_collected/*
/static/uploads/*
/static/theme_files/*
/static/picture/*
pip-log.txt
*.tmproj
*.dot
*.db
*.sublime-project
*.sublime-workspace
/docs/_*
11
ディレクトリがあるブランチで削除され、別のブランチで変更されない場合、そのディレクトリはマージ中に削除されます。それが原因だろうか?
追加された 著者 knittl,
@それはただのコメントでした!私は質問に余分な情報を取り入れます。そして、申し訳ありませんが、これは公的なレポではありません。
追加された 著者 Joe,
@knittlはい、それは私が起こっているかもしれないと思うものです。しかし、フィーチャーブランチは常に develop から外れ、常に統合されて戻っています。静的ディレクトリは決して私たちによって決して削除されません。
追加された 著者 Joe,
@stevejalim @Joe - ok というのは、問題のレポにリンクすることができないということです。私は find .git/-print0 |を調べるでしょう。 xargs -0 grep -w static git log - static/を使用して、特にディレクトリが技術的に空でないことを確認してください。空のディレクトリはgitによって追跡されません。また、私はあなたの心の上でトリックを演奏スパムチェックアウトまたはサブモジュールを検討するだろう。
追加された 著者 sehe,
ところで、公開したくないものを削除するには、 git filter-branch を実行することで、実際のproblmを '蒸留'することができます。あなたが小さな共用レポでそれをパッケージ化することができれば、真にあなたが答えを得るのを助けるでしょう。 ( progit.org/book/ch9-7.html#removing_objects を参照)
追加された 著者 sehe,
ありがとうsehe - 私はあなたが後で提案するものの両方を見てみましょう。現在のレポを公開する方法はないと思います。小さな共有リポジトリに複製できるかどうかは懐疑的です。メインのリポジトリからフォークして大量に削除することを提案していますか?
追加された 著者 Steve Jalim,

3 答え

大丈夫、女性と私は公に謝罪する必要があります。 Gitは責任を負いませんでした。私はこの質問を、同じ道を通過するかもしれない他の人たちに教訓として残しておきます。

私たちはdjango-storageのバックエンド(DjangoがAmazon S3にファイルを透過的に保存できるようにするための 'プラグイン')を使用していました。これには HashPathStorageTest というテストがあります。このテストを終了すると、。static に設定された settings.MEDIA_ROOT が削除されます。私の意見では、これは間違いです。ビジネスブランケットは作成されていないファイルは削除されません。

チェックインの前に、良い市民のようなテストを行っていました。ほとんどの場合、コードのテストを実行しましたが、サードパーティのプラグインを含むプロジェクト全体のテストを実行することがありました。これは問題の行動を生み出していた。テストとgitを一緒に実行したので、どのコマンドが削除を行っているのか把握するのは簡単ではありませんでした(削除されたファイルは git status を実行したときにのみ表示されていました)。

だから問題は解決した。もう一度、Gitの良い名前にaspersionsをキャストして申し訳ありません!

6
追加された
私たちは確かにそうです!
追加された 著者 Joe,
あなたはdjango-storageのバグレポートを提出しましたか?あなたは間違いなく!
追加された 著者 Sven Marnach,
非常に良い答え
追加された 著者 Ian P,

これは、A)フォルダを削除したブランチにマージすることを決定するgitのように見えます。B)マージしているブランチよりも新しいと思われます。アメリカの日付タイプとヨーロッパの日付タイプを持つマシンがありますか?あるいは、あなたのテストの中には、マシンの日付をリセットすることが含まれていますか?

私は...するだろう

a)あなたの開発に含まれるすべてのマシンの領域をチェックします。 b)開発中の固定小数点を選択し、ファイルをコピーして新しい腐食を作成し、そこから移動します。

0
追加された
とても興味深い。我々は2台のマシンでのみチェックインしており、どちらもイギリス時間です。時間は決して邪魔されない。しかし、おそらくgitログは、将来の日付で何らかの形で壊れていますか?私たちは、問題があまりにも多く問題になった場合、ある時点でリポジトリを再構築することを検討しています(正しい言葉であれば)。
追加された 著者 Joe,
@CharlesBailey - それから何か提案がありますか?私は困惑している。 (FWIWはログに未来の日付はありません)
追加された 著者 Joe,
悲しいことに、そうかもしれない。仮説を思いつくために断続的に起こるテストケースはありません。おそらくいくつかの検証アドバイスを得ることを望んでいた。
追加された 著者 Joe,
gitは履歴の日付を気にしないかもしれませんが、(再帰的な)マージに関しては、どれが最も関連性の高いバージョンであるかを知る必要があります。スマートなgitの評価版をダウンロードしようとするかもしれません - ログインターフェイスはかなりきれいで、個々のファイルのログと変更を簡単に見ることができます。
追加された 著者 Ian P,
gitは、歴史に関する限り、原作者日付またはコミット日付については気にしませんが、コミットの親子関係のみを気にします。不正な日付はgitに別の方法でマージを実行させることはできません。
追加された 著者 CB Bailey,
@ジョー:あなたのリポジトリと完全なテストケースへのアクセスがなければ、言うことは不可能です。
追加された 著者 CB Bailey,

これはちょうど起こったので、私は別の答えを追加しています。私たちはSQLスクリプトのリポジショニングを持ち、誤って.gitignoreを編集して新しい開発者が* .sqlを含むようにしました - 変更はそのブランチに伝播が止まりませんでした - そして、幸運なことに、しかし、これは上記の問題を引き起こす可能性があることは想像もできません - あなたのgitディレクティブファイルをチェックしましたか?フォルダが無視されている場合(そして、.gitignoreも同様に無視されている場合)、消滅してほぼ魔法によって再び現れる可能性があります。

0
追加された
ああ、ちょうどあなたの答えを読んで
追加された 著者 Ian P,