You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

DirCacheCheckoutTest.java 59KB

Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Send a detailed event on working tree modifications Currently there is no way to determine the precise changes done to the working tree by a JGit command. Only the CheckoutCommand actually provides access to the lists of modified, deleted, and to-be-deleted files, but those lists may be inaccurate (since they are determined up-front before the working tree is modified) if the actual checkout then fails halfway through. Moreover, other JGit commands that modify the working tree do not offer any way to figure out which files were changed. This poses problems for EGit, which may need to refresh parts of the Eclipse workspace when JGit has done java.io file operations. Provide the foundations for better file change tracking: the working tree is modified exclusively in DirCacheCheckout. Make it emit a new type of RepositoryEvent that lists all files that were modified or deleted, even if the checkout failed halfway through. We update the 'updated' and 'removed' lists determined up-front in case of file system problems to reflect the actual state of changes made. EGit thus can register a listener for these events and then knows exactly which parts of the Eclipse workspace may need to be refreshed. Two commands manage checking out individual DirCacheEntries themselves: checkout specific paths, and applying a stash with untracked files. Make those two also emit such a new WorkingTreeModifiedEvent. Furthermore, merges may modify files, and clean, rm, and stash create may delete files. CQ: 13969 Bug: 500106 Change-Id: I7a100aee315791fa1201f43bbad61fbae60b35cb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441451461471481491501511521531541551561571581591601611621631641651661671681691701711721731741751761771781791801811821831841851861871881891901911921931941951961971981992002012022032042052062072082092102112122132142152162172182192202212222232242252262272282292302312322332342352362372382392402412422432442452462472482492502512522532542552562572582592602612622632642652662672682692702712722732742752762772782792802812822832842852862872882892902912922932942952962972982993003013023033043053063073083093103113123133143153163173183193203213223233243253263273283293303313323333343353363373383393403413423433443453463473483493503513523533543553563573583593603613623633643653663673683693703713723733743753763773783793803813823833843853863873883893903913923933943953963973983994004014024034044054064074084094104114124134144154164174184194204214224234244254264274284294304314324334344354364374384394404414424434444454464474484494504514524534544554564574584594604614624634644654664674684694704714724734744754764774784794804814824834844854864874884894904914924934944954964974984995005015025035045055065075085095105115125135145155165175185195205215225235245255265275285295305315325335345355365375385395405415425435445455465475485495505515525535545555565575585595605615625635645655665675685695705715725735745755765775785795805815825835845855865875885895905915925935945955965975985996006016026036046056066076086096106116126136146156166176186196206216226236246256266276286296306316326336346356366376386396406416426436446456466476486496506516526536546556566576586596606616626636646656666676686696706716726736746756766776786796806816826836846856866876886896906916926936946956966976986997007017027037047057067077087097107117127137147157167177187197207217227237247257267277287297307317327337347357367377387397407417427437447457467477487497507517527537547557567577587597607617627637647657667677687697707717727737747757767777787797807817827837847857867877887897907917927937947957967977987998008018028038048058068078088098108118128138148158168178188198208218228238248258268278288298308318328338348358368378388398408418428438448458468478488498508518528538548558568578588598608618628638648658668678688698708718728738748758768778788798808818828838848858868878888898908918928938948958968978988999009019029039049059069079089099109119129139149159169179189199209219229239249259269279289299309319329339349359369379389399409419429439449459469479489499509519529539549559569579589599609619629639649659669679689699709719729739749759769779789799809819829839849859869879889899909919929939949959969979989991000100110021003100410051006100710081009101010111012101310141015101610171018101910201021102210231024102510261027102810291030103110321033103410351036103710381039104010411042104310441045104610471048104910501051105210531054105510561057105810591060106110621063106410651066106710681069107010711072107310741075107610771078107910801081108210831084108510861087108810891090109110921093109410951096109710981099110011011102110311041105110611071108110911101111111211131114111511161117111811191120112111221123112411251126112711281129113011311132113311341135113611371138113911401141114211431144114511461147114811491150115111521153115411551156115711581159116011611162116311641165116611671168116911701171117211731174117511761177117811791180118111821183118411851186118711881189119011911192119311941195119611971198119912001201120212031204120512061207120812091210121112121213121412151216121712181219122012211222122312241225122612271228122912301231123212331234123512361237123812391240124112421243124412451246124712481249125012511252125312541255125612571258125912601261126212631264126512661267126812691270127112721273127412751276127712781279128012811282128312841285128612871288128912901291129212931294129512961297129812991300130113021303130413051306130713081309131013111312131313141315131613171318131913201321132213231324132513261327132813291330133113321333133413351336133713381339134013411342134313441345134613471348134913501351135213531354135513561357135813591360136113621363136413651366136713681369137013711372137313741375137613771378137913801381138213831384138513861387138813891390139113921393139413951396139713981399140014011402140314041405140614071408140914101411141214131414141514161417141814191420142114221423142414251426142714281429143014311432143314341435143614371438143914401441144214431444144514461447144814491450145114521453145414551456145714581459146014611462146314641465146614671468146914701471147214731474147514761477147814791480148114821483148414851486148714881489149014911492149314941495149614971498149915001501150215031504150515061507150815091510151115121513151415151516151715181519152015211522152315241525152615271528152915301531153215331534153515361537153815391540154115421543154415451546154715481549155015511552155315541555155615571558155915601561156215631564156515661567156815691570157115721573157415751576157715781579158015811582158315841585158615871588158915901591159215931594159515961597159815991600160116021603160416051606160716081609161016111612161316141615161616171618161916201621162216231624162516261627162816291630163116321633163416351636163716381639164016411642164316441645164616471648164916501651165216531654165516561657165816591660166116621663166416651666166716681669167016711672167316741675167616771678167916801681168216831684168516861687168816891690169116921693169416951696169716981699170017011702170317041705170617071708170917101711171217131714171517161717171817191720172117221723172417251726172717281729173017311732173317341735173617371738173917401741174217431744174517461747174817491750175117521753175417551756175717581759176017611762176317641765176617671768176917701771177217731774177517761777177817791780178117821783178417851786178717881789179017911792179317941795179617971798179918001801180218031804180518061807180818091810181118121813181418151816181718181819182018211822182318241825182618271828182918301831183218331834183518361837183818391840184118421843184418451846184718481849185018511852185318541855185618571858185918601861186218631864186518661867186818691870187118721873187418751876187718781879188018811882188318841885188618871888188918901891189218931894189518961897189818991900190119021903190419051906190719081909191019111912191319141915191619171918191919201921192219231924192519261927192819291930193119321933193419351936193719381939194019411942194319441945194619471948194919501951195219531954
  1. /*
  2. * Copyright (C) 2007, Dave Watson <dwatson@mimvista.com>
  3. * Copyright (C) 2008-2011, Shawn O. Pearce <spearce@spearce.org>
  4. * Copyright (C) 2008-2011, Robin Rosenberg <robin.rosenberg@dewire.com>
  5. * Copyright (C) 2010-2011, Christian Halstrick <christian.halstrick@sap.com>
  6. * and other copyright owners as documented in the project's IP log.
  7. *
  8. * This program and the accompanying materials are made available under the
  9. * terms of the Eclipse Distribution License v1.0 which accompanies this
  10. * distribution, is reproduced below, and is available at
  11. * http://www.eclipse.org/org/documents/edl-v10.php
  12. *
  13. * All rights reserved.
  14. *
  15. * Redistribution and use in source and binary forms, with or without
  16. * modification, are permitted provided that the following conditions are met:
  17. *
  18. * - Redistributions of source code must retain the above copyright notice, this
  19. * list of conditions and the following disclaimer.
  20. *
  21. * - Redistributions in binary form must reproduce the above copyright notice,
  22. * this list of conditions and the following disclaimer in the documentation
  23. * and/or other materials provided with the distribution.
  24. *
  25. * - Neither the name of the Eclipse Foundation, Inc. nor the names of its
  26. * contributors may be used to endorse or promote products derived from this
  27. * software without specific prior written permission.
  28. *
  29. * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
  30. * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  31. * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  32. * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
  33. * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
  34. * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
  35. * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
  36. * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
  37. * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  38. * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
  39. * POSSIBILITY OF SUCH DAMAGE.
  40. */
  41. package org.eclipse.jgit.lib;
  42. import static org.junit.Assert.assertArrayEquals;
  43. import static org.junit.Assert.assertEquals;
  44. import static org.junit.Assert.assertFalse;
  45. import static org.junit.Assert.assertNotNull;
  46. import static org.junit.Assert.assertTrue;
  47. import static org.junit.Assert.fail;
  48. import java.io.File;
  49. import java.io.FileInputStream;
  50. import java.io.IOException;
  51. import java.util.Arrays;
  52. import java.util.HashMap;
  53. import java.util.List;
  54. import java.util.Map;
  55. import org.eclipse.jgit.api.CheckoutCommand;
  56. import org.eclipse.jgit.api.CheckoutResult;
  57. import org.eclipse.jgit.api.Git;
  58. import org.eclipse.jgit.api.MergeResult.MergeStatus;
  59. import org.eclipse.jgit.api.ResetCommand.ResetType;
  60. import org.eclipse.jgit.api.Status;
  61. import org.eclipse.jgit.api.errors.GitAPIException;
  62. import org.eclipse.jgit.api.errors.NoFilepatternException;
  63. import org.eclipse.jgit.dircache.DirCache;
  64. import org.eclipse.jgit.dircache.DirCacheCheckout;
  65. import org.eclipse.jgit.dircache.DirCacheCheckout.CheckoutMetadata;
  66. import org.eclipse.jgit.dircache.DirCacheEditor;
  67. import org.eclipse.jgit.dircache.DirCacheEditor.PathEdit;
  68. import org.eclipse.jgit.dircache.DirCacheEntry;
  69. import org.eclipse.jgit.errors.CheckoutConflictException;
  70. import org.eclipse.jgit.errors.CorruptObjectException;
  71. import org.eclipse.jgit.errors.NoWorkTreeException;
  72. import org.eclipse.jgit.events.ChangeRecorder;
  73. import org.eclipse.jgit.events.ListenerHandle;
  74. import org.eclipse.jgit.junit.RepositoryTestCase;
  75. import org.eclipse.jgit.junit.TestRepository;
  76. import org.eclipse.jgit.junit.TestRepository.BranchBuilder;
  77. import org.eclipse.jgit.revwalk.RevCommit;
  78. import org.eclipse.jgit.treewalk.FileTreeIterator;
  79. import org.eclipse.jgit.treewalk.TreeWalk;
  80. import org.eclipse.jgit.util.FS;
  81. import org.eclipse.jgit.util.FileUtils;
  82. import org.junit.Assume;
  83. import org.junit.Test;
  84. public class DirCacheCheckoutTest extends RepositoryTestCase {
  85. private DirCacheCheckout dco;
  86. protected ObjectId theHead;
  87. protected ObjectId theMerge;
  88. private DirCache dirCache;
  89. private void prescanTwoTrees(ObjectId head, ObjectId merge)
  90. throws IllegalStateException, IOException {
  91. DirCache dc = db.lockDirCache();
  92. try {
  93. dco = new DirCacheCheckout(db, head, dc, merge);
  94. dco.preScanTwoTrees();
  95. } finally {
  96. dc.unlock();
  97. }
  98. }
  99. private void checkout() throws IOException {
  100. DirCache dc = db.lockDirCache();
  101. try {
  102. dco = new DirCacheCheckout(db, theHead, dc, theMerge);
  103. dco.checkout();
  104. } finally {
  105. dc.unlock();
  106. }
  107. }
  108. private List<String> getRemoved() {
  109. return dco.getRemoved();
  110. }
  111. private Map<String, CheckoutMetadata> getUpdated() {
  112. return dco.getUpdated();
  113. }
  114. private List<String> getConflicts() {
  115. return dco.getConflicts();
  116. }
  117. private static HashMap<String, String> mk(String a) {
  118. return mkmap(a, a);
  119. }
  120. private static HashMap<String, String> mkmap(String... args) {
  121. if ((args.length % 2) > 0)
  122. throw new IllegalArgumentException("needs to be pairs");
  123. HashMap<String, String> map = new HashMap<>();
  124. for (int i = 0; i < args.length; i += 2) {
  125. map.put(args[i], args[i + 1]);
  126. }
  127. return map;
  128. }
  129. @Test
  130. public void testResetHard() throws IOException, NoFilepatternException,
  131. GitAPIException {
  132. ChangeRecorder recorder = new ChangeRecorder();
  133. ListenerHandle handle = null;
  134. try (Git git = new Git(db)) {
  135. handle = db.getListenerList()
  136. .addWorkingTreeModifiedListener(recorder);
  137. writeTrashFile("f", "f()");
  138. writeTrashFile("D/g", "g()");
  139. git.add().addFilepattern(".").call();
  140. git.commit().setMessage("inital").call();
  141. assertIndex(mkmap("f", "f()", "D/g", "g()"));
  142. recorder.assertNoEvent();
  143. git.branchCreate().setName("topic").call();
  144. recorder.assertNoEvent();
  145. writeTrashFile("f", "f()\nmaster");
  146. writeTrashFile("D/g", "g()\ng2()");
  147. writeTrashFile("E/h", "h()");
  148. git.add().addFilepattern(".").call();
  149. RevCommit master = git.commit().setMessage("master-1").call();
  150. assertIndex(mkmap("f", "f()\nmaster", "D/g", "g()\ng2()", "E/h", "h()"));
  151. recorder.assertNoEvent();
  152. checkoutBranch("refs/heads/topic");
  153. assertIndex(mkmap("f", "f()", "D/g", "g()"));
  154. recorder.assertEvent(new String[] { "f", "D/g" },
  155. new String[] { "E/h" });
  156. writeTrashFile("f", "f()\nside");
  157. assertTrue(new File(db.getWorkTree(), "D/g").delete());
  158. writeTrashFile("G/i", "i()");
  159. git.add().addFilepattern(".").call();
  160. git.add().addFilepattern(".").setUpdate(true).call();
  161. RevCommit topic = git.commit().setMessage("topic-1").call();
  162. assertIndex(mkmap("f", "f()\nside", "G/i", "i()"));
  163. recorder.assertNoEvent();
  164. writeTrashFile("untracked", "untracked");
  165. resetHard(master);
  166. assertIndex(mkmap("f", "f()\nmaster", "D/g", "g()\ng2()", "E/h", "h()"));
  167. recorder.assertEvent(new String[] { "f", "D/g", "E/h" },
  168. new String[] { "G", "G/i" });
  169. resetHard(topic);
  170. assertIndex(mkmap("f", "f()\nside", "G/i", "i()"));
  171. assertWorkDir(mkmap("f", "f()\nside", "G/i", "i()", "untracked",
  172. "untracked"));
  173. recorder.assertEvent(new String[] { "f", "G/i" },
  174. new String[] { "D", "D/g", "E", "E/h" });
  175. assertEquals(MergeStatus.CONFLICTING, git.merge().include(master)
  176. .call().getMergeStatus());
  177. assertEquals(
  178. "[D/g, mode:100644, stage:1][D/g, mode:100644, stage:3][E/h, mode:100644][G/i, mode:100644][f, mode:100644, stage:1][f, mode:100644, stage:2][f, mode:100644, stage:3]",
  179. indexState(0));
  180. recorder.assertEvent(new String[] { "f", "D/g", "E/h" },
  181. ChangeRecorder.EMPTY);
  182. resetHard(master);
  183. assertIndex(mkmap("f", "f()\nmaster", "D/g", "g()\ng2()", "E/h", "h()"));
  184. assertWorkDir(mkmap("f", "f()\nmaster", "D/g", "g()\ng2()", "E/h",
  185. "h()", "untracked", "untracked"));
  186. recorder.assertEvent(new String[] { "f", "D/g" },
  187. new String[] { "G", "G/i" });
  188. } finally {
  189. if (handle != null) {
  190. handle.remove();
  191. }
  192. }
  193. }
  194. /**
  195. * Reset hard from unclean condition.
  196. * <p>
  197. * WorkDir: Empty <br/>
  198. * Index: f/g <br/>
  199. * Merge: x
  200. *
  201. * @throws Exception
  202. */
  203. @Test
  204. public void testResetHardFromIndexEntryWithoutFileToTreeWithoutFile()
  205. throws Exception {
  206. ChangeRecorder recorder = new ChangeRecorder();
  207. ListenerHandle handle = null;
  208. try (Git git = new Git(db)) {
  209. handle = db.getListenerList()
  210. .addWorkingTreeModifiedListener(recorder);
  211. writeTrashFile("x", "x");
  212. git.add().addFilepattern("x").call();
  213. RevCommit id1 = git.commit().setMessage("c1").call();
  214. writeTrashFile("f/g", "f/g");
  215. git.rm().addFilepattern("x").call();
  216. recorder.assertEvent(ChangeRecorder.EMPTY, new String[] { "x" });
  217. git.add().addFilepattern("f/g").call();
  218. git.commit().setMessage("c2").call();
  219. deleteTrashFile("f/g");
  220. deleteTrashFile("f");
  221. // The actual test
  222. git.reset().setMode(ResetType.HARD).setRef(id1.getName()).call();
  223. assertIndex(mkmap("x", "x"));
  224. recorder.assertEvent(new String[] { "x" }, ChangeRecorder.EMPTY);
  225. } finally {
  226. if (handle != null) {
  227. handle.remove();
  228. }
  229. }
  230. }
  231. /**
  232. * Test first checkout in a repo
  233. *
  234. * @throws Exception
  235. */
  236. @Test
  237. public void testInitialCheckout() throws Exception {
  238. ChangeRecorder recorder = new ChangeRecorder();
  239. ListenerHandle handle = null;
  240. try (Git git = new Git(db)) {
  241. handle = db.getListenerList()
  242. .addWorkingTreeModifiedListener(recorder);
  243. TestRepository<Repository> db_t = new TestRepository<>(db);
  244. BranchBuilder master = db_t.branch("master");
  245. master.commit().add("f", "1").message("m0").create();
  246. assertFalse(new File(db.getWorkTree(), "f").exists());
  247. git.checkout().setName("master").call();
  248. assertTrue(new File(db.getWorkTree(), "f").exists());
  249. recorder.assertEvent(new String[] { "f" }, ChangeRecorder.EMPTY);
  250. } finally {
  251. if (handle != null) {
  252. handle.remove();
  253. }
  254. }
  255. }
  256. private DirCacheCheckout resetHard(RevCommit commit)
  257. throws NoWorkTreeException,
  258. CorruptObjectException, IOException {
  259. DirCacheCheckout dc;
  260. dc = new DirCacheCheckout(db, null, db.lockDirCache(),
  261. commit.getTree());
  262. dc.setFailOnConflict(true);
  263. assertTrue(dc.checkout());
  264. return dc;
  265. }
  266. private void assertIndex(HashMap<String, String> i)
  267. throws CorruptObjectException, IOException {
  268. String expectedValue;
  269. String path;
  270. DirCache read = DirCache.read(db.getIndexFile(), db.getFS());
  271. assertEquals("Index has not the right size.", i.size(),
  272. read.getEntryCount());
  273. for (int j = 0; j < read.getEntryCount(); j++) {
  274. path = read.getEntry(j).getPathString();
  275. expectedValue = i.get(path);
  276. assertNotNull("found unexpected entry for path " + path
  277. + " in index", expectedValue);
  278. assertTrue("unexpected content for path " + path
  279. + " in index. Expected: <" + expectedValue + ">",
  280. Arrays.equals(db.open(read.getEntry(j).getObjectId())
  281. .getCachedBytes(), i.get(path).getBytes()));
  282. }
  283. }
  284. @Test
  285. public void testRules1thru3_NoIndexEntry() throws IOException {
  286. ObjectId head = buildTree(mk("foo"));
  287. ObjectId merge = db.newObjectInserter().insert(Constants.OBJ_TREE,
  288. new byte[0]);
  289. prescanTwoTrees(head, merge);
  290. assertTrue(getRemoved().contains("foo"));
  291. prescanTwoTrees(merge, head);
  292. assertTrue(getUpdated().containsKey("foo"));
  293. merge = buildTree(mkmap("foo", "a"));
  294. prescanTwoTrees(head, merge);
  295. assertConflict("foo");
  296. }
  297. void setupCase(HashMap<String, String> headEntries, HashMap<String, String> mergeEntries, HashMap<String, String> indexEntries) throws IOException {
  298. theHead = buildTree(headEntries);
  299. theMerge = buildTree(mergeEntries);
  300. buildIndex(indexEntries);
  301. }
  302. private void buildIndex(HashMap<String, String> indexEntries) throws IOException {
  303. dirCache = new DirCache(db.getIndexFile(), db.getFS());
  304. if (indexEntries != null) {
  305. assertTrue(dirCache.lock());
  306. DirCacheEditor editor = dirCache.editor();
  307. for (java.util.Map.Entry<String,String> e : indexEntries.entrySet()) {
  308. writeTrashFile(e.getKey(), e.getValue());
  309. ObjectInserter inserter = db.newObjectInserter();
  310. final ObjectId id = inserter.insert(Constants.OBJ_BLOB,
  311. Constants.encode(e.getValue()));
  312. editor.add(new DirCacheEditor.DeletePath(e.getKey()));
  313. editor.add(new DirCacheEditor.PathEdit(e.getKey()) {
  314. @Override
  315. public void apply(DirCacheEntry ent) {
  316. ent.setFileMode(FileMode.REGULAR_FILE);
  317. ent.setObjectId(id);
  318. ent.setUpdateNeeded(false);
  319. }
  320. });
  321. }
  322. assertTrue(editor.commit());
  323. }
  324. }
  325. static final class AddEdit extends PathEdit {
  326. private final ObjectId data;
  327. private final long length;
  328. public AddEdit(String entryPath, ObjectId data, long length) {
  329. super(entryPath);
  330. this.data = data;
  331. this.length = length;
  332. }
  333. @Override
  334. public void apply(DirCacheEntry ent) {
  335. ent.setFileMode(FileMode.REGULAR_FILE);
  336. ent.setLength(length);
  337. ent.setObjectId(data);
  338. }
  339. }
  340. private ObjectId buildTree(HashMap<String, String> headEntries)
  341. throws IOException {
  342. DirCache lockDirCache = DirCache.newInCore();
  343. // assertTrue(lockDirCache.lock());
  344. DirCacheEditor editor = lockDirCache.editor();
  345. if (headEntries != null) {
  346. for (java.util.Map.Entry<String, String> e : headEntries.entrySet()) {
  347. AddEdit addEdit = new AddEdit(e.getKey(),
  348. genSha1(e.getValue()), e.getValue().length());
  349. editor.add(addEdit);
  350. }
  351. }
  352. editor.finish();
  353. return lockDirCache.writeTree(db.newObjectInserter());
  354. }
  355. ObjectId genSha1(String data) {
  356. try (ObjectInserter w = db.newObjectInserter()) {
  357. ObjectId id = w.insert(Constants.OBJ_BLOB, data.getBytes());
  358. w.flush();
  359. return id;
  360. } catch (IOException e) {
  361. fail(e.toString());
  362. }
  363. return null;
  364. }
  365. protected void go() throws IllegalStateException, IOException {
  366. prescanTwoTrees(theHead, theMerge);
  367. }
  368. @Test
  369. public void testRules4thru13_IndexEntryNotInHead() throws IOException {
  370. // rules 4 and 5
  371. HashMap<String, String> idxMap;
  372. idxMap = new HashMap<>();
  373. idxMap.put("foo", "foo");
  374. setupCase(null, null, idxMap);
  375. go();
  376. assertTrue(getUpdated().isEmpty());
  377. assertTrue(getRemoved().isEmpty());
  378. assertTrue(getConflicts().isEmpty());
  379. // rules 6 and 7
  380. idxMap = new HashMap<>();
  381. idxMap.put("foo", "foo");
  382. setupCase(null, idxMap, idxMap);
  383. go();
  384. assertAllEmpty();
  385. // rules 8 and 9
  386. HashMap<String, String> mergeMap;
  387. mergeMap = new HashMap<>();
  388. mergeMap.put("foo", "merge");
  389. setupCase(null, mergeMap, idxMap);
  390. go();
  391. assertTrue(getUpdated().isEmpty());
  392. assertTrue(getRemoved().isEmpty());
  393. assertTrue(getConflicts().contains("foo"));
  394. // rule 10
  395. HashMap<String, String> headMap = new HashMap<>();
  396. headMap.put("foo", "foo");
  397. setupCase(headMap, null, idxMap);
  398. go();
  399. assertTrue(getRemoved().contains("foo"));
  400. assertTrue(getUpdated().isEmpty());
  401. assertTrue(getConflicts().isEmpty());
  402. // rule 11
  403. setupCase(headMap, null, idxMap);
  404. assertTrue(new File(trash, "foo").delete());
  405. writeTrashFile("foo", "bar");
  406. db.readDirCache().getEntry(0).setUpdateNeeded(true);
  407. go();
  408. assertTrue(getRemoved().isEmpty());
  409. assertTrue(getUpdated().isEmpty());
  410. assertTrue(getConflicts().contains("foo"));
  411. // rule 12 & 13
  412. headMap.put("foo", "head");
  413. setupCase(headMap, null, idxMap);
  414. go();
  415. assertTrue(getRemoved().isEmpty());
  416. assertTrue(getUpdated().isEmpty());
  417. assertTrue(getConflicts().contains("foo"));
  418. // rules 14 & 15
  419. setupCase(headMap, headMap, idxMap);
  420. go();
  421. assertAllEmpty();
  422. // rules 16 & 17
  423. setupCase(headMap, mergeMap, idxMap); go();
  424. assertTrue(getConflicts().contains("foo"));
  425. // rules 18 & 19
  426. setupCase(headMap, idxMap, idxMap); go();
  427. assertAllEmpty();
  428. // rule 20
  429. setupCase(idxMap, mergeMap, idxMap); go();
  430. assertTrue(getUpdated().containsKey("foo"));
  431. // rules 21
  432. setupCase(idxMap, mergeMap, idxMap);
  433. assertTrue(new File(trash, "foo").delete());
  434. writeTrashFile("foo", "bar");
  435. db.readDirCache().getEntry(0).setUpdateNeeded(true);
  436. go();
  437. assertTrue(getConflicts().contains("foo"));
  438. }
  439. private void assertAllEmpty() {
  440. assertTrue(getRemoved().isEmpty());
  441. assertTrue(getUpdated().isEmpty());
  442. assertTrue(getConflicts().isEmpty());
  443. }
  444. /*-
  445. * Directory/File Conflict cases:
  446. * It's entirely possible that in practice a number of these may be equivalent
  447. * to the cases described in git-read-tree.txt. As long as it does the right thing,
  448. * that's all I care about. These are basically reverse-engineered from
  449. * what git currently does. If there are tests for these in git, it's kind of
  450. * hard to track them all down...
  451. *
  452. * H I M Clean H==M H==I I==M Result
  453. * ------------------------------------------------------------------
  454. *1 D D F Y N Y N Update
  455. *2 D D F N N Y N Conflict
  456. *3 D F D Y N N Keep
  457. *4 D F D N N N Conflict
  458. *5 D F F Y N N Y Keep
  459. *5b D F F Y N N N Conflict
  460. *6 D F F N N N Y Keep
  461. *6b D F F N N N N Conflict
  462. *7 F D F Y Y N N Update
  463. *8 F D F N Y N N Conflict
  464. *9 F D F Y N N N Update
  465. *10 F D D N N Y Keep
  466. *11 F D D N N N Conflict
  467. *12 F F D Y N Y N Update
  468. *13 F F D N N Y N Conflict
  469. *14 F F D N N N Conflict
  470. *15 0 F D N N N Conflict
  471. *16 0 D F Y N N N Update
  472. *17 0 D F N N N Conflict
  473. *18 F 0 D Update
  474. *19 D 0 F Update
  475. */
  476. @Test
  477. public void testDirectoryFileSimple() throws IOException {
  478. ObjectId treeDF = buildTree(mkmap("DF", "DF"));
  479. ObjectId treeDFDF = buildTree(mkmap("DF/DF", "DF/DF"));
  480. buildIndex(mkmap("DF", "DF"));
  481. prescanTwoTrees(treeDF, treeDFDF);
  482. assertTrue(getRemoved().contains("DF"));
  483. assertTrue(getUpdated().containsKey("DF/DF"));
  484. recursiveDelete(new File(trash, "DF"));
  485. buildIndex(mkmap("DF/DF", "DF/DF"));
  486. prescanTwoTrees(treeDFDF, treeDF);
  487. assertTrue(getRemoved().contains("DF/DF"));
  488. assertTrue(getUpdated().containsKey("DF"));
  489. }
  490. @Test
  491. public void testDirectoryFileConflicts_1() throws Exception {
  492. // 1
  493. doit(mk("DF/DF"), mk("DF"), mk("DF/DF"));
  494. assertNoConflicts();
  495. assertUpdated("DF");
  496. assertRemoved("DF/DF");
  497. }
  498. @Test
  499. public void testDirectoryFileConflicts_2() throws Exception {
  500. // 2
  501. setupCase(mk("DF/DF"), mk("DF"), mk("DF/DF"));
  502. writeTrashFile("DF/DF", "different");
  503. go();
  504. assertConflict("DF/DF");
  505. }
  506. @Test
  507. public void testDirectoryFileConflicts_3() throws Exception {
  508. // 3
  509. doit(mk("DF/DF"), mk("DF/DF"), mk("DF"));
  510. assertNoConflicts();
  511. }
  512. @Test
  513. public void testDirectoryFileConflicts_4() throws Exception {
  514. // 4 (basically same as 3, just with H and M different)
  515. doit(mk("DF/DF"), mkmap("DF/DF", "foo"), mk("DF"));
  516. assertConflict("DF/DF");
  517. }
  518. @Test
  519. public void testDirectoryFileConflicts_5() throws Exception {
  520. // 5
  521. doit(mk("DF/DF"), mk("DF"), mk("DF"));
  522. assertRemoved("DF/DF");
  523. assertEquals(0, dco.getConflicts().size());
  524. assertEquals(0, dco.getUpdated().size());
  525. }
  526. @Test
  527. public void testDirectoryFileConflicts_5b() throws Exception {
  528. // 5
  529. doit(mk("DF/DF"), mkmap("DF", "different"), mk("DF"));
  530. assertRemoved("DF/DF");
  531. assertConflict("DF");
  532. assertEquals(0, dco.getUpdated().size());
  533. }
  534. @Test
  535. public void testDirectoryFileConflicts_6() throws Exception {
  536. // 6
  537. setupCase(mk("DF/DF"), mk("DF"), mk("DF"));
  538. writeTrashFile("DF", "different");
  539. go();
  540. assertRemoved("DF/DF");
  541. assertEquals(0, dco.getConflicts().size());
  542. assertEquals(0, dco.getUpdated().size());
  543. }
  544. @Test
  545. public void testDirectoryFileConflicts_6b() throws Exception {
  546. // 6
  547. setupCase(mk("DF/DF"), mk("DF"), mkmap("DF", "different"));
  548. writeTrashFile("DF", "again different");
  549. go();
  550. assertRemoved("DF/DF");
  551. assertConflict("DF");
  552. assertEquals(0, dco.getUpdated().size());
  553. }
  554. @Test
  555. public void testDirectoryFileConflicts_7() throws Exception {
  556. // 7
  557. doit(mk("DF"), mk("DF"), mk("DF/DF"));
  558. assertUpdated("DF");
  559. assertRemoved("DF/DF");
  560. cleanUpDF();
  561. setupCase(mk("DF/DF"), mk("DF/DF"), mk("DF/DF/DF/DF/DF"));
  562. go();
  563. assertRemoved("DF/DF/DF/DF/DF");
  564. assertUpdated("DF/DF");
  565. cleanUpDF();
  566. setupCase(mk("DF/DF"), mk("DF/DF"), mk("DF/DF/DF/DF/DF"));
  567. writeTrashFile("DF/DF/DF/DF/DF", "diff");
  568. go();
  569. assertConflict("DF/DF/DF/DF/DF");
  570. // assertUpdated("DF/DF");
  571. // Why do we expect an update on DF/DF. H==M,
  572. // H&M are files and index contains a dir, index
  573. // is dirty: that case is not in the table but
  574. // we cannot update DF/DF to a file, this would
  575. // require that we delete DF/DF/DF/DF/DF in workdir
  576. // throwing away unsaved contents.
  577. // This test would fail in DirCacheCheckoutTests.
  578. }
  579. @Test
  580. public void testDirectoryFileConflicts_8() throws Exception {
  581. // 8
  582. setupCase(mk("DF"), mk("DF"), mk("DF/DF"));
  583. recursiveDelete(new File(db.getWorkTree(), "DF"));
  584. writeTrashFile("DF", "xy");
  585. go();
  586. assertConflict("DF/DF");
  587. }
  588. @Test
  589. public void testDirectoryFileConflicts_9() throws Exception {
  590. // 9
  591. doit(mkmap("DF", "QP"), mkmap("DF", "QP"), mkmap("DF/DF", "DF/DF"));
  592. assertRemoved("DF/DF");
  593. assertUpdated("DF");
  594. }
  595. @Test
  596. public void testDirectoryFileConflicts_10() throws Exception {
  597. // 10
  598. cleanUpDF();
  599. doit(mk("DF"), mk("DF/DF"), mk("DF/DF"));
  600. assertNoConflicts();
  601. }
  602. @Test
  603. public void testDirectoryFileConflicts_11() throws Exception {
  604. // 11
  605. doit(mk("DF"), mk("DF/DF"), mkmap("DF/DF", "asdf"));
  606. assertConflict("DF/DF");
  607. }
  608. @Test
  609. public void testDirectoryFileConflicts_12() throws Exception {
  610. // 12
  611. cleanUpDF();
  612. doit(mk("DF"), mk("DF/DF"), mk("DF"));
  613. assertRemoved("DF");
  614. assertUpdated("DF/DF");
  615. }
  616. @Test
  617. public void testDirectoryFileConflicts_13() throws Exception {
  618. // 13
  619. cleanUpDF();
  620. setupCase(mk("DF"), mk("DF/DF"), mk("DF"));
  621. writeTrashFile("DF", "asdfsdf");
  622. go();
  623. assertConflict("DF");
  624. assertUpdated("DF/DF");
  625. }
  626. @Test
  627. public void testDirectoryFileConflicts_14() throws Exception {
  628. // 14
  629. cleanUpDF();
  630. doit(mk("DF"), mk("DF/DF"), mkmap("DF", "Foo"));
  631. assertConflict("DF");
  632. assertUpdated("DF/DF");
  633. }
  634. @Test
  635. public void testDirectoryFileConflicts_15() throws Exception {
  636. // 15
  637. doit(mkmap(), mk("DF/DF"), mk("DF"));
  638. // This test would fail in DirCacheCheckoutTests. I think this test is wrong,
  639. // it should check for conflicts according to rule 15
  640. // assertRemoved("DF");
  641. assertUpdated("DF/DF");
  642. }
  643. @Test
  644. public void testDirectoryFileConflicts_15b() throws Exception {
  645. // 15, take 2, just to check multi-leveled
  646. doit(mkmap(), mk("DF/DF/DF/DF"), mk("DF"));
  647. // I think this test is wrong, it should
  648. // check for conflicts according to rule 15
  649. // This test would fail in DirCacheCheckouts
  650. // assertRemoved("DF");
  651. assertUpdated("DF/DF/DF/DF");
  652. }
  653. @Test
  654. public void testDirectoryFileConflicts_16() throws Exception {
  655. // 16
  656. cleanUpDF();
  657. doit(mkmap(), mk("DF"), mk("DF/DF/DF"));
  658. assertRemoved("DF/DF/DF");
  659. assertUpdated("DF");
  660. }
  661. @Test
  662. public void testDirectoryFileConflicts_17() throws Exception {
  663. // 17
  664. cleanUpDF();
  665. setupCase(mkmap(), mk("DF"), mk("DF/DF/DF"));
  666. writeTrashFile("DF/DF/DF", "asdf");
  667. go();
  668. assertConflict("DF/DF/DF");
  669. // Why do we expect an update on DF. If we really update
  670. // DF and update also the working tree we would have to
  671. // overwrite a dirty file in the work-tree DF/DF/DF
  672. // This test would fail in DirCacheCheckout
  673. // assertUpdated("DF");
  674. }
  675. @Test
  676. public void testDirectoryFileConflicts_18() throws Exception {
  677. // 18
  678. cleanUpDF();
  679. doit(mk("DF/DF"), mk("DF/DF/DF/DF"), null);
  680. assertRemoved("DF/DF");
  681. assertUpdated("DF/DF/DF/DF");
  682. }
  683. @Test
  684. public void testDirectoryFileConflicts_19() throws Exception {
  685. // 19
  686. cleanUpDF();
  687. doit(mk("DF/DF/DF/DF"), mk("DF/DF/DF"), null);
  688. assertRemoved("DF/DF/DF/DF");
  689. assertUpdated("DF/DF/DF");
  690. }
  691. protected void cleanUpDF() throws Exception {
  692. tearDown();
  693. setUp();
  694. recursiveDelete(new File(trash, "DF"));
  695. }
  696. protected void assertConflict(String s) {
  697. assertTrue(getConflicts().contains(s));
  698. }
  699. protected void assertUpdated(String s) {
  700. assertTrue(getUpdated().containsKey(s));
  701. }
  702. protected void assertRemoved(String s) {
  703. assertTrue(getRemoved().contains(s));
  704. }
  705. protected void assertNoConflicts() {
  706. assertTrue(getConflicts().isEmpty());
  707. }
  708. protected void doit(HashMap<String, String> h, HashMap<String, String> m, HashMap<String, String> i)
  709. throws IOException {
  710. setupCase(h, m, i);
  711. go();
  712. }
  713. @Test
  714. public void testUntrackedConflicts() throws IOException {
  715. setupCase(null, mk("foo"), null);
  716. writeTrashFile("foo", "foo");
  717. go();
  718. // test that we don't overwrite untracked files when there is a HEAD
  719. recursiveDelete(new File(trash, "foo"));
  720. setupCase(mk("other"), mkmap("other", "other", "foo", "foo"),
  721. mk("other"));
  722. writeTrashFile("foo", "bar");
  723. try {
  724. checkout();
  725. fail("didn't get the expected exception");
  726. } catch (CheckoutConflictException e) {
  727. assertConflict("foo");
  728. assertEquals("foo", e.getConflictingFiles()[0]);
  729. assertWorkDir(mkmap("foo", "bar", "other", "other"));
  730. assertIndex(mk("other"));
  731. }
  732. // test that we don't overwrite untracked files when there is no HEAD
  733. recursiveDelete(new File(trash, "other"));
  734. recursiveDelete(new File(trash, "foo"));
  735. setupCase(null, mk("foo"), null);
  736. writeTrashFile("foo", "bar");
  737. try {
  738. checkout();
  739. fail("didn't get the expected exception");
  740. } catch (CheckoutConflictException e) {
  741. assertConflict("foo");
  742. assertWorkDir(mkmap("foo", "bar"));
  743. assertIndex(mkmap("other", "other"));
  744. }
  745. // TODO: Why should we expect conflicts here?
  746. // H and M are empty and according to rule #5 of
  747. // the carry-over rules a dirty index is no reason
  748. // for a conflict. (I also feel it should be a
  749. // conflict because we are going to overwrite
  750. // unsaved content in the working tree
  751. // This test would fail in DirCacheCheckoutTest
  752. // assertConflict("foo");
  753. recursiveDelete(new File(trash, "foo"));
  754. recursiveDelete(new File(trash, "other"));
  755. setupCase(null, mk("foo"), null);
  756. writeTrashFile("foo/bar/baz", "");
  757. writeTrashFile("foo/blahblah", "");
  758. go();
  759. assertConflict("foo");
  760. assertConflict("foo/bar/baz");
  761. assertConflict("foo/blahblah");
  762. recursiveDelete(new File(trash, "foo"));
  763. setupCase(mkmap("foo/bar", "", "foo/baz", ""),
  764. mk("foo"), mkmap("foo/bar", "", "foo/baz", ""));
  765. assertTrue(new File(trash, "foo/bar").exists());
  766. go();
  767. assertNoConflicts();
  768. }
  769. @Test
  770. public void testCloseNameConflictsX0() throws IOException {
  771. setupCase(mkmap("a/a", "a/a-c"), mkmap("a/a","a/a", "b.b/b.b","b.b/b.bs"), mkmap("a/a", "a/a-c") );
  772. checkout();
  773. assertIndex(mkmap("a/a", "a/a", "b.b/b.b", "b.b/b.bs"));
  774. assertWorkDir(mkmap("a/a", "a/a", "b.b/b.b", "b.b/b.bs"));
  775. go();
  776. assertIndex(mkmap("a/a", "a/a", "b.b/b.b", "b.b/b.bs"));
  777. assertWorkDir(mkmap("a/a", "a/a", "b.b/b.b", "b.b/b.bs"));
  778. assertNoConflicts();
  779. }
  780. @Test
  781. public void testCloseNameConflicts1() throws IOException {
  782. setupCase(mkmap("a/a", "a/a-c"), mkmap("a/a","a/a", "a.a/a.a","a.a/a.a"), mkmap("a/a", "a/a-c") );
  783. checkout();
  784. assertIndex(mkmap("a/a", "a/a", "a.a/a.a", "a.a/a.a"));
  785. assertWorkDir(mkmap("a/a", "a/a", "a.a/a.a", "a.a/a.a"));
  786. go();
  787. assertIndex(mkmap("a/a", "a/a", "a.a/a.a", "a.a/a.a"));
  788. assertWorkDir(mkmap("a/a", "a/a", "a.a/a.a", "a.a/a.a"));
  789. assertNoConflicts();
  790. }
  791. @Test
  792. public void testCheckoutHierarchy() throws IOException {
  793. setupCase(
  794. mkmap("a", "a", "b/c", "b/c", "d", "d", "e/f", "e/f", "e/g",
  795. "e/g"),
  796. mkmap("a", "a2", "b/c", "b/c", "d", "d", "e/f", "e/f", "e/g",
  797. "e/g2"),
  798. mkmap("a", "a", "b/c", "b/c", "d", "d", "e/f", "e/f", "e/g",
  799. "e/g3"));
  800. try {
  801. checkout();
  802. } catch (CheckoutConflictException e) {
  803. assertWorkDir(mkmap("a", "a", "b/c", "b/c", "d", "d", "e/f",
  804. "e/f", "e/g", "e/g3"));
  805. assertConflict("e/g");
  806. assertEquals("e/g", e.getConflictingFiles()[0]);
  807. }
  808. }
  809. @Test
  810. public void testCheckoutOutChanges() throws IOException {
  811. setupCase(mk("foo"), mk("foo/bar"), mk("foo"));
  812. checkout();
  813. assertIndex(mk("foo/bar"));
  814. assertWorkDir(mk("foo/bar"));
  815. assertFalse(new File(trash, "foo").isFile());
  816. assertTrue(new File(trash, "foo/bar").isFile());
  817. recursiveDelete(new File(trash, "foo"));
  818. assertWorkDir(mkmap());
  819. setupCase(mk("foo/bar"), mk("foo"), mk("foo/bar"));
  820. checkout();
  821. assertIndex(mk("foo"));
  822. assertWorkDir(mk("foo"));
  823. assertFalse(new File(trash, "foo/bar").isFile());
  824. assertTrue(new File(trash, "foo").isFile());
  825. setupCase(mk("foo"), mkmap("foo", "qux"), mkmap("foo", "bar"));
  826. assertIndex(mkmap("foo", "bar"));
  827. assertWorkDir(mkmap("foo", "bar"));
  828. try {
  829. checkout();
  830. fail("did not throw exception");
  831. } catch (CheckoutConflictException e) {
  832. assertIndex(mkmap("foo", "bar"));
  833. assertWorkDir(mkmap("foo", "bar"));
  834. }
  835. }
  836. @Test
  837. public void testCheckoutChangeLinkToEmptyDir() throws Exception {
  838. Assume.assumeTrue(FS.DETECTED.supportsSymlinks());
  839. String fname = "was_file";
  840. ChangeRecorder recorder = new ChangeRecorder();
  841. ListenerHandle handle = null;
  842. try (Git git = new Git(db)) {
  843. handle = db.getListenerList()
  844. .addWorkingTreeModifiedListener(recorder);
  845. // Add a file
  846. writeTrashFile(fname, "a");
  847. git.add().addFilepattern(fname).call();
  848. // Add a link to file
  849. String linkName = "link";
  850. File link = writeLink(linkName, fname).toFile();
  851. git.add().addFilepattern(linkName).call();
  852. git.commit().setMessage("Added file and link").call();
  853. assertWorkDir(mkmap(linkName, "a", fname, "a"));
  854. // replace link with empty directory
  855. FileUtils.delete(link);
  856. FileUtils.mkdir(link);
  857. assertTrue("Link must be a directory now", link.isDirectory());
  858. // modify file
  859. writeTrashFile(fname, "b");
  860. assertWorkDir(mkmap(fname, "b", linkName, "/"));
  861. recorder.assertNoEvent();
  862. // revert both paths to HEAD state
  863. git.checkout().setStartPoint(Constants.HEAD).addPath(fname)
  864. .addPath(linkName).call();
  865. assertWorkDir(mkmap(fname, "a", linkName, "a"));
  866. recorder.assertEvent(new String[] { fname, linkName },
  867. ChangeRecorder.EMPTY);
  868. Status st = git.status().call();
  869. assertTrue(st.isClean());
  870. } finally {
  871. if (handle != null) {
  872. handle.remove();
  873. }
  874. }
  875. }
  876. @Test
  877. public void testCheckoutChangeLinkToEmptyDirs() throws Exception {
  878. Assume.assumeTrue(FS.DETECTED.supportsSymlinks());
  879. String fname = "was_file";
  880. ChangeRecorder recorder = new ChangeRecorder();
  881. ListenerHandle handle = null;
  882. try (Git git = new Git(db)) {
  883. handle = db.getListenerList()
  884. .addWorkingTreeModifiedListener(recorder);
  885. // Add a file
  886. writeTrashFile(fname, "a");
  887. git.add().addFilepattern(fname).call();
  888. // Add a link to file
  889. String linkName = "link";
  890. File link = writeLink(linkName, fname).toFile();
  891. git.add().addFilepattern(linkName).call();
  892. git.commit().setMessage("Added file and link").call();
  893. assertWorkDir(mkmap(linkName, "a", fname, "a"));
  894. // replace link with directory containing only directories, no files
  895. FileUtils.delete(link);
  896. FileUtils.mkdirs(new File(link, "dummyDir"));
  897. assertTrue("Link must be a directory now", link.isDirectory());
  898. assertFalse("Must not delete non empty directory", link.delete());
  899. // modify file
  900. writeTrashFile(fname, "b");
  901. assertWorkDir(mkmap(fname, "b", linkName + "/dummyDir", "/"));
  902. recorder.assertNoEvent();
  903. // revert both paths to HEAD state
  904. git.checkout().setStartPoint(Constants.HEAD).addPath(fname)
  905. .addPath(linkName).call();
  906. assertWorkDir(mkmap(fname, "a", linkName, "a"));
  907. recorder.assertEvent(new String[] { fname, linkName },
  908. ChangeRecorder.EMPTY);
  909. Status st = git.status().call();
  910. assertTrue(st.isClean());
  911. } finally {
  912. if (handle != null) {
  913. handle.remove();
  914. }
  915. }
  916. }
  917. @Test
  918. public void testCheckoutChangeLinkToNonEmptyDirs() throws Exception {
  919. Assume.assumeTrue(FS.DETECTED.supportsSymlinks());
  920. String fname = "file";
  921. ChangeRecorder recorder = new ChangeRecorder();
  922. ListenerHandle handle = null;
  923. try (Git git = new Git(db)) {
  924. handle = db.getListenerList()
  925. .addWorkingTreeModifiedListener(recorder);
  926. // Add a file
  927. writeTrashFile(fname, "a");
  928. git.add().addFilepattern(fname).call();
  929. // Add a link to file
  930. String linkName = "link";
  931. File link = writeLink(linkName, fname).toFile();
  932. git.add().addFilepattern(linkName).call();
  933. git.commit().setMessage("Added file and link").call();
  934. assertWorkDir(mkmap(linkName, "a", fname, "a"));
  935. // replace link with directory containing only directories, no files
  936. FileUtils.delete(link);
  937. // create but do not add a file in the new directory to the index
  938. writeTrashFile(linkName + "/dir1", "file1", "c");
  939. // create but do not add a file in the new directory to the index
  940. writeTrashFile(linkName + "/dir2", "file2", "d");
  941. assertTrue("File must be a directory now", link.isDirectory());
  942. assertFalse("Must not delete non empty directory", link.delete());
  943. // 2 extra files are created
  944. assertWorkDir(mkmap(fname, "a", linkName + "/dir1/file1", "c",
  945. linkName + "/dir2/file2", "d"));
  946. recorder.assertNoEvent();
  947. // revert path to HEAD state
  948. git.checkout().setStartPoint(Constants.HEAD).addPath(linkName)
  949. .call();
  950. // expect only the one added to the index
  951. assertWorkDir(mkmap(linkName, "a", fname, "a"));
  952. recorder.assertEvent(new String[] { linkName },
  953. ChangeRecorder.EMPTY);
  954. Status st = git.status().call();
  955. assertTrue(st.isClean());
  956. } finally {
  957. if (handle != null) {
  958. handle.remove();
  959. }
  960. }
  961. }
  962. @Test
  963. public void testCheckoutChangeLinkToNonEmptyDirsAndNewIndexEntry()
  964. throws Exception {
  965. Assume.assumeTrue(FS.DETECTED.supportsSymlinks());
  966. String fname = "file";
  967. ChangeRecorder recorder = new ChangeRecorder();
  968. ListenerHandle handle = null;
  969. try (Git git = new Git(db)) {
  970. handle = db.getListenerList()
  971. .addWorkingTreeModifiedListener(recorder);
  972. // Add a file
  973. writeTrashFile(fname, "a");
  974. git.add().addFilepattern(fname).call();
  975. // Add a link to file
  976. String linkName = "link";
  977. File link = writeLink(linkName, fname).toFile();
  978. git.add().addFilepattern(linkName).call();
  979. git.commit().setMessage("Added file and link").call();
  980. assertWorkDir(mkmap(linkName, "a", fname, "a"));
  981. // replace link with directory containing only directories, no files
  982. FileUtils.delete(link);
  983. // create and add a file in the new directory to the index
  984. writeTrashFile(linkName + "/dir1", "file1", "c");
  985. git.add().addFilepattern(linkName + "/dir1/file1").call();
  986. // create but do not add a file in the new directory to the index
  987. writeTrashFile(linkName + "/dir2", "file2", "d");
  988. assertTrue("File must be a directory now", link.isDirectory());
  989. assertFalse("Must not delete non empty directory", link.delete());
  990. // 2 extra files are created
  991. assertWorkDir(mkmap(fname, "a", linkName + "/dir1/file1", "c",
  992. linkName + "/dir2/file2", "d"));
  993. recorder.assertNoEvent();
  994. // revert path to HEAD state
  995. git.checkout().setStartPoint(Constants.HEAD).addPath(linkName)
  996. .call();
  997. // original file and link
  998. assertWorkDir(mkmap(linkName, "a", fname, "a"));
  999. recorder.assertEvent(new String[] { linkName },
  1000. ChangeRecorder.EMPTY);
  1001. Status st = git.status().call();
  1002. assertTrue(st.isClean());
  1003. } finally {
  1004. if (handle != null) {
  1005. handle.remove();
  1006. }
  1007. }
  1008. }
  1009. @Test
  1010. public void testCheckoutChangeFileToEmptyDir() throws Exception {
  1011. String fname = "was_file";
  1012. ChangeRecorder recorder = new ChangeRecorder();
  1013. ListenerHandle handle = null;
  1014. try (Git git = new Git(db)) {
  1015. handle = db.getListenerList()
  1016. .addWorkingTreeModifiedListener(recorder);
  1017. // Add a file
  1018. File file = writeTrashFile(fname, "a");
  1019. git.add().addFilepattern(fname).call();
  1020. git.commit().setMessage("Added file").call();
  1021. // replace file with empty directory
  1022. FileUtils.delete(file);
  1023. FileUtils.mkdir(file);
  1024. assertTrue("File must be a directory now", file.isDirectory());
  1025. assertWorkDir(mkmap(fname, "/"));
  1026. recorder.assertNoEvent();
  1027. // revert path to HEAD state
  1028. git.checkout().setStartPoint(Constants.HEAD).addPath(fname).call();
  1029. assertWorkDir(mkmap(fname, "a"));
  1030. recorder.assertEvent(new String[] { fname }, ChangeRecorder.EMPTY);
  1031. Status st = git.status().call();
  1032. assertTrue(st.isClean());
  1033. } finally {
  1034. if (handle != null) {
  1035. handle.remove();
  1036. }
  1037. }
  1038. }
  1039. @Test
  1040. public void testCheckoutChangeFileToEmptyDirs() throws Exception {
  1041. String fname = "was_file";
  1042. ChangeRecorder recorder = new ChangeRecorder();
  1043. ListenerHandle handle = null;
  1044. try (Git git = new Git(db)) {
  1045. handle = db.getListenerList()
  1046. .addWorkingTreeModifiedListener(recorder);
  1047. // Add a file
  1048. File file = writeTrashFile(fname, "a");
  1049. git.add().addFilepattern(fname).call();
  1050. git.commit().setMessage("Added file").call();
  1051. // replace file with directory containing only directories, no files
  1052. FileUtils.delete(file);
  1053. FileUtils.mkdirs(new File(file, "dummyDir"));
  1054. assertTrue("File must be a directory now", file.isDirectory());
  1055. assertFalse("Must not delete non empty directory", file.delete());
  1056. assertWorkDir(mkmap(fname + "/dummyDir", "/"));
  1057. recorder.assertNoEvent();
  1058. // revert path to HEAD state
  1059. git.checkout().setStartPoint(Constants.HEAD).addPath(fname).call();
  1060. assertWorkDir(mkmap(fname, "a"));
  1061. recorder.assertEvent(new String[] { fname }, ChangeRecorder.EMPTY);
  1062. Status st = git.status().call();
  1063. assertTrue(st.isClean());
  1064. } finally {
  1065. if (handle != null) {
  1066. handle.remove();
  1067. }
  1068. }
  1069. }
  1070. @Test
  1071. public void testCheckoutChangeFileToNonEmptyDirs() throws Exception {
  1072. String fname = "was_file";
  1073. ChangeRecorder recorder = new ChangeRecorder();
  1074. ListenerHandle handle = null;
  1075. try (Git git = new Git(db)) {
  1076. handle = db.getListenerList()
  1077. .addWorkingTreeModifiedListener(recorder);
  1078. // Add a file
  1079. File file = writeTrashFile(fname, "a");
  1080. git.add().addFilepattern(fname).call();
  1081. git.commit().setMessage("Added file").call();
  1082. assertWorkDir(mkmap(fname, "a"));
  1083. // replace file with directory containing only directories, no files
  1084. FileUtils.delete(file);
  1085. // create but do not add a file in the new directory to the index
  1086. writeTrashFile(fname + "/dir1", "file1", "c");
  1087. // create but do not add a file in the new directory to the index
  1088. writeTrashFile(fname + "/dir2", "file2", "d");
  1089. assertTrue("File must be a directory now", file.isDirectory());
  1090. assertFalse("Must not delete non empty directory", file.delete());
  1091. // 2 extra files are created
  1092. assertWorkDir(mkmap(fname + "/dir1/file1", "c",
  1093. fname + "/dir2/file2", "d"));
  1094. recorder.assertNoEvent();
  1095. // revert path to HEAD state
  1096. git.checkout().setStartPoint(Constants.HEAD).addPath(fname).call();
  1097. // expect only the one added to the index
  1098. assertWorkDir(mkmap(fname, "a"));
  1099. recorder.assertEvent(new String[] { fname }, ChangeRecorder.EMPTY);
  1100. Status st = git.status().call();
  1101. assertTrue(st.isClean());
  1102. } finally {
  1103. if (handle != null) {
  1104. handle.remove();
  1105. }
  1106. }
  1107. }
  1108. @Test
  1109. public void testCheckoutChangeFileToNonEmptyDirsAndNewIndexEntry()
  1110. throws Exception {
  1111. String fname = "was_file";
  1112. ChangeRecorder recorder = new ChangeRecorder();
  1113. ListenerHandle handle = null;
  1114. try (Git git = new Git(db)) {
  1115. handle = db.getListenerList()
  1116. .addWorkingTreeModifiedListener(recorder);
  1117. // Add a file
  1118. File file = writeTrashFile(fname, "a");
  1119. git.add().addFilepattern(fname).call();
  1120. git.commit().setMessage("Added file").call();
  1121. assertWorkDir(mkmap(fname, "a"));
  1122. // replace file with directory containing only directories, no files
  1123. FileUtils.delete(file);
  1124. // create and add a file in the new directory to the index
  1125. writeTrashFile(fname + "/dir", "file1", "c");
  1126. git.add().addFilepattern(fname + "/dir/file1").call();
  1127. // create but do not add a file in the new directory to the index
  1128. writeTrashFile(fname + "/dir", "file2", "d");
  1129. assertTrue("File must be a directory now", file.isDirectory());
  1130. assertFalse("Must not delete non empty directory", file.delete());
  1131. // 2 extra files are created
  1132. assertWorkDir(mkmap(fname + "/dir/file1", "c", fname + "/dir/file2",
  1133. "d"));
  1134. recorder.assertNoEvent();
  1135. // revert path to HEAD state
  1136. git.checkout().setStartPoint(Constants.HEAD).addPath(fname).call();
  1137. assertWorkDir(mkmap(fname, "a"));
  1138. recorder.assertEvent(new String[] { fname }, ChangeRecorder.EMPTY);
  1139. Status st = git.status().call();
  1140. assertTrue(st.isClean());
  1141. } finally {
  1142. if (handle != null) {
  1143. handle.remove();
  1144. }
  1145. }
  1146. }
  1147. @Test
  1148. public void testCheckoutOutChangesAutoCRLFfalse() throws IOException {
  1149. setupCase(mk("foo"), mkmap("foo/bar", "foo\nbar"), mk("foo"));
  1150. checkout();
  1151. assertIndex(mkmap("foo/bar", "foo\nbar"));
  1152. assertWorkDir(mkmap("foo/bar", "foo\nbar"));
  1153. }
  1154. @Test
  1155. public void testCheckoutOutChangesAutoCRLFInput() throws IOException {
  1156. setupCase(mk("foo"), mkmap("foo/bar", "foo\nbar"), mk("foo"));
  1157. db.getConfig().setString("core", null, "autocrlf", "input");
  1158. checkout();
  1159. assertIndex(mkmap("foo/bar", "foo\nbar"));
  1160. assertWorkDir(mkmap("foo/bar", "foo\nbar"));
  1161. }
  1162. @Test
  1163. public void testCheckoutOutChangesAutoCRLFtrue() throws IOException {
  1164. setupCase(mk("foo"), mkmap("foo/bar", "foo\nbar"), mk("foo"));
  1165. db.getConfig().setString("core", null, "autocrlf", "true");
  1166. checkout();
  1167. assertIndex(mkmap("foo/bar", "foo\nbar"));
  1168. assertWorkDir(mkmap("foo/bar", "foo\r\nbar"));
  1169. }
  1170. @Test
  1171. public void testCheckoutOutChangesAutoCRLFtrueBinary() throws IOException {
  1172. setupCase(mk("foo"), mkmap("foo/bar", "foo\nb\u0000ar"), mk("foo"));
  1173. db.getConfig().setString("core", null, "autocrlf", "true");
  1174. checkout();
  1175. assertIndex(mkmap("foo/bar", "foo\nb\u0000ar"));
  1176. assertWorkDir(mkmap("foo/bar", "foo\nb\u0000ar"));
  1177. }
  1178. @Test
  1179. public void testCheckoutUncachedChanges() throws IOException {
  1180. setupCase(mk("foo"), mk("foo"), mk("foo"));
  1181. writeTrashFile("foo", "otherData");
  1182. checkout();
  1183. assertIndex(mk("foo"));
  1184. assertWorkDir(mkmap("foo", "otherData"));
  1185. assertTrue(new File(trash, "foo").isFile());
  1186. }
  1187. @Test
  1188. public void testDontOverwriteDirtyFile() throws IOException {
  1189. setupCase(mk("foo"), mk("other"), mk("foo"));
  1190. writeTrashFile("foo", "different");
  1191. try {
  1192. checkout();
  1193. fail("Didn't got the expected conflict");
  1194. } catch (CheckoutConflictException e) {
  1195. assertIndex(mk("foo"));
  1196. assertWorkDir(mkmap("foo", "different"));
  1197. assertEquals(Arrays.asList("foo"), getConflicts());
  1198. assertTrue(new File(trash, "foo").isFile());
  1199. }
  1200. }
  1201. @Test
  1202. public void testDontOverwriteEmptyFolder() throws IOException {
  1203. setupCase(mk("foo"), mk("foo"), mk("foo"));
  1204. FileUtils.mkdir(new File(db.getWorkTree(), "d"));
  1205. checkout();
  1206. assertWorkDir(mkmap("foo", "foo", "d", "/"));
  1207. }
  1208. @Test
  1209. public void testOverwriteUntrackedIgnoredFile() throws IOException,
  1210. GitAPIException {
  1211. String fname="file.txt";
  1212. ChangeRecorder recorder = new ChangeRecorder();
  1213. ListenerHandle handle = null;
  1214. try (Git git = new Git(db)) {
  1215. handle = db.getListenerList()
  1216. .addWorkingTreeModifiedListener(recorder);
  1217. // Add a file
  1218. writeTrashFile(fname, "a");
  1219. git.add().addFilepattern(fname).call();
  1220. git.commit().setMessage("create file").call();
  1221. // Create branch
  1222. git.branchCreate().setName("side").call();
  1223. // Modify file
  1224. writeTrashFile(fname, "b");
  1225. git.add().addFilepattern(fname).call();
  1226. git.commit().setMessage("modify file").call();
  1227. recorder.assertNoEvent();
  1228. // Switch branches
  1229. git.checkout().setName("side").call();
  1230. recorder.assertEvent(new String[] { fname }, ChangeRecorder.EMPTY);
  1231. git.rm().addFilepattern(fname).call();
  1232. recorder.assertEvent(ChangeRecorder.EMPTY, new String[] { fname });
  1233. writeTrashFile(".gitignore", fname);
  1234. git.add().addFilepattern(".gitignore").call();
  1235. git.commit().setMessage("delete and ignore file").call();
  1236. writeTrashFile(fname, "Something different");
  1237. recorder.assertNoEvent();
  1238. git.checkout().setName("master").call();
  1239. assertWorkDir(mkmap(fname, "b"));
  1240. recorder.assertEvent(new String[] { fname },
  1241. new String[] { ".gitignore" });
  1242. assertTrue(git.status().call().isClean());
  1243. } finally {
  1244. if (handle != null) {
  1245. handle.remove();
  1246. }
  1247. }
  1248. }
  1249. @Test
  1250. public void testOverwriteUntrackedFileModeChange()
  1251. throws IOException, GitAPIException {
  1252. String fname = "file.txt";
  1253. ChangeRecorder recorder = new ChangeRecorder();
  1254. ListenerHandle handle = null;
  1255. try (Git git = new Git(db)) {
  1256. handle = db.getListenerList()
  1257. .addWorkingTreeModifiedListener(recorder);
  1258. // Add a file
  1259. File file = writeTrashFile(fname, "a");
  1260. git.add().addFilepattern(fname).call();
  1261. git.commit().setMessage("create file").call();
  1262. assertWorkDir(mkmap(fname, "a"));
  1263. // Create branch
  1264. git.branchCreate().setName("side").call();
  1265. // Switch branches
  1266. git.checkout().setName("side").call();
  1267. recorder.assertNoEvent();
  1268. // replace file with directory containing files
  1269. FileUtils.delete(file);
  1270. // create and add a file in the new directory to the index
  1271. writeTrashFile(fname + "/dir1", "file1", "c");
  1272. git.add().addFilepattern(fname + "/dir1/file1").call();
  1273. // create but do not add a file in the new directory to the index
  1274. writeTrashFile(fname + "/dir2", "file2", "d");
  1275. assertTrue("File must be a directory now", file.isDirectory());
  1276. assertFalse("Must not delete non empty directory", file.delete());
  1277. // 2 extra files are created
  1278. assertWorkDir(mkmap(fname + "/dir1/file1", "c",
  1279. fname + "/dir2/file2", "d"));
  1280. try {
  1281. git.checkout().setName("master").call();
  1282. fail("did not throw exception");
  1283. } catch (Exception e) {
  1284. // 2 extra files are still there
  1285. assertWorkDir(mkmap(fname + "/dir1/file1", "c",
  1286. fname + "/dir2/file2", "d"));
  1287. }
  1288. recorder.assertNoEvent();
  1289. } finally {
  1290. if (handle != null) {
  1291. handle.remove();
  1292. }
  1293. }
  1294. }
  1295. @Test
  1296. public void testOverwriteUntrackedLinkModeChange()
  1297. throws Exception {
  1298. Assume.assumeTrue(FS.DETECTED.supportsSymlinks());
  1299. String fname = "file.txt";
  1300. ChangeRecorder recorder = new ChangeRecorder();
  1301. ListenerHandle handle = null;
  1302. try (Git git = new Git(db)) {
  1303. handle = db.getListenerList()
  1304. .addWorkingTreeModifiedListener(recorder);
  1305. // Add a file
  1306. writeTrashFile(fname, "a");
  1307. git.add().addFilepattern(fname).call();
  1308. // Add a link to file
  1309. String linkName = "link";
  1310. File link = writeLink(linkName, fname).toFile();
  1311. git.add().addFilepattern(linkName).call();
  1312. git.commit().setMessage("Added file and link").call();
  1313. assertWorkDir(mkmap(linkName, "a", fname, "a"));
  1314. // Create branch
  1315. git.branchCreate().setName("side").call();
  1316. // Switch branches
  1317. git.checkout().setName("side").call();
  1318. recorder.assertNoEvent();
  1319. // replace link with directory containing files
  1320. FileUtils.delete(link);
  1321. // create and add a file in the new directory to the index
  1322. writeTrashFile(linkName + "/dir1", "file1", "c");
  1323. git.add().addFilepattern(linkName + "/dir1/file1").call();
  1324. // create but do not add a file in the new directory to the index
  1325. writeTrashFile(linkName + "/dir2", "file2", "d");
  1326. assertTrue("Link must be a directory now", link.isDirectory());
  1327. assertFalse("Must not delete non empty directory", link.delete());
  1328. // 2 extra files are created
  1329. assertWorkDir(mkmap(fname, "a", linkName + "/dir1/file1", "c",
  1330. linkName + "/dir2/file2", "d"));
  1331. try {
  1332. git.checkout().setName("master").call();
  1333. fail("did not throw exception");
  1334. } catch (Exception e) {
  1335. // 2 extra files are still there
  1336. assertWorkDir(mkmap(fname, "a", linkName + "/dir1/file1", "c",
  1337. linkName + "/dir2/file2", "d"));
  1338. }
  1339. recorder.assertNoEvent();
  1340. } finally {
  1341. if (handle != null) {
  1342. handle.remove();
  1343. }
  1344. }
  1345. }
  1346. @Test
  1347. public void testFileModeChangeWithNoContentChangeUpdate() throws Exception {
  1348. if (!FS.DETECTED.supportsExecute())
  1349. return;
  1350. ChangeRecorder recorder = new ChangeRecorder();
  1351. ListenerHandle handle = null;
  1352. try (Git git = new Git(db)) {
  1353. handle = db.getListenerList()
  1354. .addWorkingTreeModifiedListener(recorder);
  1355. // Add non-executable file
  1356. File file = writeTrashFile("file.txt", "a");
  1357. git.add().addFilepattern("file.txt").call();
  1358. git.commit().setMessage("commit1").call();
  1359. assertFalse(db.getFS().canExecute(file));
  1360. // Create branch
  1361. git.branchCreate().setName("b1").call();
  1362. // Make file executable
  1363. db.getFS().setExecute(file, true);
  1364. git.add().addFilepattern("file.txt").call();
  1365. git.commit().setMessage("commit2").call();
  1366. recorder.assertNoEvent();
  1367. // Verify executable and working directory is clean
  1368. Status status = git.status().call();
  1369. assertTrue(status.getModified().isEmpty());
  1370. assertTrue(status.getChanged().isEmpty());
  1371. assertTrue(db.getFS().canExecute(file));
  1372. // Switch branches
  1373. git.checkout().setName("b1").call();
  1374. // Verify not executable and working directory is clean
  1375. status = git.status().call();
  1376. assertTrue(status.getModified().isEmpty());
  1377. assertTrue(status.getChanged().isEmpty());
  1378. assertFalse(db.getFS().canExecute(file));
  1379. recorder.assertEvent(new String[] { "file.txt" },
  1380. ChangeRecorder.EMPTY);
  1381. } finally {
  1382. if (handle != null) {
  1383. handle.remove();
  1384. }
  1385. }
  1386. }
  1387. @Test
  1388. public void testFileModeChangeAndContentChangeConflict() throws Exception {
  1389. if (!FS.DETECTED.supportsExecute())
  1390. return;
  1391. ChangeRecorder recorder = new ChangeRecorder();
  1392. ListenerHandle handle = null;
  1393. try (Git git = new Git(db)) {
  1394. handle = db.getListenerList()
  1395. .addWorkingTreeModifiedListener(recorder);
  1396. // Add non-executable file
  1397. File file = writeTrashFile("file.txt", "a");
  1398. git.add().addFilepattern("file.txt").call();
  1399. git.commit().setMessage("commit1").call();
  1400. assertFalse(db.getFS().canExecute(file));
  1401. // Create branch
  1402. git.branchCreate().setName("b1").call();
  1403. // Make file executable
  1404. db.getFS().setExecute(file, true);
  1405. git.add().addFilepattern("file.txt").call();
  1406. git.commit().setMessage("commit2").call();
  1407. // Verify executable and working directory is clean
  1408. Status status = git.status().call();
  1409. assertTrue(status.getModified().isEmpty());
  1410. assertTrue(status.getChanged().isEmpty());
  1411. assertTrue(db.getFS().canExecute(file));
  1412. writeTrashFile("file.txt", "b");
  1413. // Switch branches
  1414. CheckoutCommand checkout = git.checkout().setName("b1");
  1415. try {
  1416. checkout.call();
  1417. fail("Checkout exception not thrown");
  1418. } catch (org.eclipse.jgit.api.errors.CheckoutConflictException e) {
  1419. CheckoutResult result = checkout.getResult();
  1420. assertNotNull(result);
  1421. assertNotNull(result.getConflictList());
  1422. assertEquals(1, result.getConflictList().size());
  1423. assertTrue(result.getConflictList().contains("file.txt"));
  1424. }
  1425. recorder.assertNoEvent();
  1426. } finally {
  1427. if (handle != null) {
  1428. handle.remove();
  1429. }
  1430. }
  1431. }
  1432. @Test
  1433. public void testDirtyFileModeEqualHeadMerge()
  1434. throws Exception {
  1435. if (!FS.DETECTED.supportsExecute())
  1436. return;
  1437. ChangeRecorder recorder = new ChangeRecorder();
  1438. ListenerHandle handle = null;
  1439. try (Git git = new Git(db)) {
  1440. handle = db.getListenerList()
  1441. .addWorkingTreeModifiedListener(recorder);
  1442. // Add non-executable file
  1443. File file = writeTrashFile("file.txt", "a");
  1444. git.add().addFilepattern("file.txt").call();
  1445. git.commit().setMessage("commit1").call();
  1446. assertFalse(db.getFS().canExecute(file));
  1447. // Create branch
  1448. git.branchCreate().setName("b1").call();
  1449. // Create second commit and don't touch file
  1450. writeTrashFile("file2.txt", "");
  1451. git.add().addFilepattern("file2.txt").call();
  1452. git.commit().setMessage("commit2").call();
  1453. // stage a mode change
  1454. writeTrashFile("file.txt", "a");
  1455. db.getFS().setExecute(file, true);
  1456. git.add().addFilepattern("file.txt").call();
  1457. // dirty the file
  1458. writeTrashFile("file.txt", "b");
  1459. assertEquals(
  1460. "[file.txt, mode:100755, content:a][file2.txt, mode:100644, content:]",
  1461. indexState(CONTENT));
  1462. assertWorkDir(mkmap("file.txt", "b", "file2.txt", ""));
  1463. recorder.assertNoEvent();
  1464. // Switch branches and check that the dirty file survived in
  1465. // worktree and index
  1466. git.checkout().setName("b1").call();
  1467. assertEquals("[file.txt, mode:100755, content:a]",
  1468. indexState(CONTENT));
  1469. assertWorkDir(mkmap("file.txt", "b"));
  1470. recorder.assertEvent(ChangeRecorder.EMPTY,
  1471. new String[] { "file2.txt" });
  1472. } finally {
  1473. if (handle != null) {
  1474. handle.remove();
  1475. }
  1476. }
  1477. }
  1478. @Test
  1479. public void testDirtyFileModeEqualIndexMerge()
  1480. throws Exception {
  1481. if (!FS.DETECTED.supportsExecute())
  1482. return;
  1483. ChangeRecorder recorder = new ChangeRecorder();
  1484. ListenerHandle handle = null;
  1485. try (Git git = new Git(db)) {
  1486. handle = db.getListenerList()
  1487. .addWorkingTreeModifiedListener(recorder);
  1488. // Add non-executable file
  1489. File file = writeTrashFile("file.txt", "a");
  1490. git.add().addFilepattern("file.txt").call();
  1491. git.commit().setMessage("commit1").call();
  1492. assertFalse(db.getFS().canExecute(file));
  1493. // Create branch
  1494. git.branchCreate().setName("b1").call();
  1495. // Create second commit with executable file
  1496. file = writeTrashFile("file.txt", "b");
  1497. db.getFS().setExecute(file, true);
  1498. git.add().addFilepattern("file.txt").call();
  1499. git.commit().setMessage("commit2").call();
  1500. // stage the same content as in the branch we want to switch to
  1501. writeTrashFile("file.txt", "a");
  1502. db.getFS().setExecute(file, false);
  1503. git.add().addFilepattern("file.txt").call();
  1504. // dirty the file
  1505. writeTrashFile("file.txt", "c");
  1506. db.getFS().setExecute(file, true);
  1507. assertEquals("[file.txt, mode:100644, content:a]",
  1508. indexState(CONTENT));
  1509. assertWorkDir(mkmap("file.txt", "c"));
  1510. recorder.assertNoEvent();
  1511. // Switch branches and check that the dirty file survived in
  1512. // worktree
  1513. // and index
  1514. git.checkout().setName("b1").call();
  1515. assertEquals("[file.txt, mode:100644, content:a]",
  1516. indexState(CONTENT));
  1517. assertWorkDir(mkmap("file.txt", "c"));
  1518. recorder.assertNoEvent();
  1519. } finally {
  1520. if (handle != null) {
  1521. handle.remove();
  1522. }
  1523. }
  1524. }
  1525. @Test
  1526. public void testFileModeChangeAndContentChangeNoConflict() throws Exception {
  1527. if (!FS.DETECTED.supportsExecute())
  1528. return;
  1529. ChangeRecorder recorder = new ChangeRecorder();
  1530. ListenerHandle handle = null;
  1531. try (Git git = new Git(db)) {
  1532. handle = db.getListenerList()
  1533. .addWorkingTreeModifiedListener(recorder);
  1534. // Add first file
  1535. File file1 = writeTrashFile("file1.txt", "a");
  1536. git.add().addFilepattern("file1.txt").call();
  1537. git.commit().setMessage("commit1").call();
  1538. assertFalse(db.getFS().canExecute(file1));
  1539. // Add second file
  1540. File file2 = writeTrashFile("file2.txt", "b");
  1541. git.add().addFilepattern("file2.txt").call();
  1542. git.commit().setMessage("commit2").call();
  1543. assertFalse(db.getFS().canExecute(file2));
  1544. recorder.assertNoEvent();
  1545. // Create branch from first commit
  1546. assertNotNull(git.checkout().setCreateBranch(true).setName("b1")
  1547. .setStartPoint(Constants.HEAD + "~1").call());
  1548. recorder.assertEvent(ChangeRecorder.EMPTY,
  1549. new String[] { "file2.txt" });
  1550. // Change content and file mode in working directory and index
  1551. file1 = writeTrashFile("file1.txt", "c");
  1552. db.getFS().setExecute(file1, true);
  1553. git.add().addFilepattern("file1.txt").call();
  1554. // Switch back to 'master'
  1555. assertNotNull(git.checkout().setName(Constants.MASTER).call());
  1556. recorder.assertEvent(new String[] { "file2.txt" },
  1557. ChangeRecorder.EMPTY);
  1558. } finally {
  1559. if (handle != null) {
  1560. handle.remove();
  1561. }
  1562. }
  1563. }
  1564. @Test(expected = CheckoutConflictException.class)
  1565. public void testFolderFileConflict() throws Exception {
  1566. RevCommit headCommit = commitFile("f/a", "initial content", "master");
  1567. RevCommit checkoutCommit = commitFile("f/a", "side content", "side");
  1568. FileUtils.delete(new File(db.getWorkTree(), "f"), FileUtils.RECURSIVE);
  1569. writeTrashFile("f", "file instead of folder");
  1570. new DirCacheCheckout(db, headCommit.getTree(), db.lockDirCache(),
  1571. checkoutCommit.getTree()).checkout();
  1572. }
  1573. @Test
  1574. public void testMultipleContentConflicts() throws Exception {
  1575. commitFile("a", "initial content", "master");
  1576. RevCommit headCommit = commitFile("b", "initial content", "master");
  1577. commitFile("a", "side content", "side");
  1578. RevCommit checkoutCommit = commitFile("b", "side content", "side");
  1579. writeTrashFile("a", "changed content");
  1580. writeTrashFile("b", "changed content");
  1581. try {
  1582. new DirCacheCheckout(db, headCommit.getTree(), db.lockDirCache(),
  1583. checkoutCommit.getTree()).checkout();
  1584. fail();
  1585. } catch (CheckoutConflictException expected) {
  1586. assertEquals(2, expected.getConflictingFiles().length);
  1587. assertTrue(Arrays.asList(expected.getConflictingFiles())
  1588. .contains("a"));
  1589. assertTrue(Arrays.asList(expected.getConflictingFiles())
  1590. .contains("b"));
  1591. assertEquals("changed content", read("a"));
  1592. assertEquals("changed content", read("b"));
  1593. }
  1594. }
  1595. @Test
  1596. public void testFolderFileAndContentConflicts() throws Exception {
  1597. RevCommit headCommit = commitFile("f/a", "initial content", "master");
  1598. commitFile("b", "side content", "side");
  1599. RevCommit checkoutCommit = commitFile("f/a", "side content", "side");
  1600. FileUtils.delete(new File(db.getWorkTree(), "f"), FileUtils.RECURSIVE);
  1601. writeTrashFile("f", "file instead of a folder");
  1602. writeTrashFile("b", "changed content");
  1603. try {
  1604. new DirCacheCheckout(db, headCommit.getTree(), db.lockDirCache(),
  1605. checkoutCommit.getTree()).checkout();
  1606. fail();
  1607. } catch (CheckoutConflictException expected) {
  1608. assertEquals(2, expected.getConflictingFiles().length);
  1609. assertTrue(Arrays.asList(expected.getConflictingFiles())
  1610. .contains("b"));
  1611. assertTrue(Arrays.asList(expected.getConflictingFiles())
  1612. .contains("f"));
  1613. assertEquals("file instead of a folder", read("f"));
  1614. assertEquals("changed content", read("b"));
  1615. }
  1616. }
  1617. @Test
  1618. public void testLongFilename() throws Exception {
  1619. char[] bytes = new char[253];
  1620. Arrays.fill(bytes, 'f');
  1621. String longFileName = new String(bytes);
  1622. // 1
  1623. doit(mkmap(longFileName, "a"), mkmap(longFileName, "b"),
  1624. mkmap(longFileName, "a"));
  1625. writeTrashFile(longFileName, "a");
  1626. checkout();
  1627. assertNoConflicts();
  1628. assertUpdated(longFileName);
  1629. }
  1630. public void assertWorkDir(Map<String, String> i)
  1631. throws CorruptObjectException,
  1632. IOException {
  1633. try (TreeWalk walk = new TreeWalk(db)) {
  1634. walk.setRecursive(false);
  1635. walk.addTree(new FileTreeIterator(db));
  1636. String expectedValue;
  1637. String path;
  1638. int nrFiles = 0;
  1639. FileTreeIterator ft;
  1640. while (walk.next()) {
  1641. ft = walk.getTree(0, FileTreeIterator.class);
  1642. path = ft.getEntryPathString();
  1643. expectedValue = i.get(path);
  1644. File file = new File(db.getWorkTree(), path);
  1645. assertTrue(file.exists());
  1646. if (file.isFile()) {
  1647. assertNotNull("found unexpected file for path " + path
  1648. + " in workdir", expectedValue);
  1649. FileInputStream is = new FileInputStream(file);
  1650. byte[] buffer = new byte[(int) file.length()];
  1651. int offset = 0;
  1652. int numRead = 0;
  1653. while (offset < buffer.length
  1654. && (numRead = is.read(buffer, offset, buffer.length
  1655. - offset)) >= 0) {
  1656. offset += numRead;
  1657. }
  1658. is.close();
  1659. assertArrayEquals("unexpected content for path " + path
  1660. + " in workDir. ", buffer, i.get(path).getBytes());
  1661. nrFiles++;
  1662. } else if (file.isDirectory()) {
  1663. String[] files = file.list();
  1664. if (files != null && files.length == 0) {
  1665. assertEquals("found unexpected empty folder for path "
  1666. + path + " in workDir. ", "/", i.get(path));
  1667. nrFiles++;
  1668. }
  1669. }
  1670. if (walk.isSubtree()) {
  1671. walk.enterSubtree();
  1672. }
  1673. }
  1674. assertEquals("WorkDir has not the right size.", i.size(), nrFiles);
  1675. }
  1676. }
  1677. }