10000 Delete Orphan folder when last file is deleted by pmiossec · Pull Request #268 · git-tfs/git-tfs · GitHub
[go: up one dir, main page]

Skip to content

Delete Orphan folder when last file is deleted #268

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jan 25, 2013

Conversation

pmiossec
Copy link
Member

The return of the commit ;)
I now detect last deleted file using the git tree...

@spraints
Copy link
Member

This might work. I want to play around with it a bit before a 👍 or 👎. Specifically, I'm interested in ...

  • if there is still a file in tfs, does tfs prevent you from accidentally deleting it, or does it just recursively delete the file? If unintentional removal does happen, we'll probably have to ask tfs about the dir contents before deleting.
  • I think this is covered, but what happens if the last existing file is removed and another file is added?

@pmiossec
Copy link
Member Author

if there is still a file in tfs, does tfs prevent you from accidentally deleting it, or does it just recursively delete the file? If unintentional removal does happen, we'll probably have to ask tfs about the dir contents before deleting.
I think it will delete it. Because when I did my tests, when you delete the last file of the directory AND delete the directory, in the TFS commit window, the only delete command displayed is the one of the directory. So, I think, only this command is send to TFS server and all the files will be deleted!

I think this is covered, but what happens if the last existing file is removed and another file is added?
I didn't test that but I'm 99% sure it's handled because I look for existing files in the directory in the git tree. The file added must be there, so the directory must not be deleted.

PS : I can test nothing because I'm on holdays. Work will restart with the new year ;) and I will not answer anymore in comments too...

@spraints
Copy link
Member

Happy holidays, Merry Christmas, Happy New Year! See you in 2013! 🎆

@pmiossec
Copy link
Member Author

I now look to the TFS tree (and manage file moved/renamed) but it become more and more ugly, I think (but perhaps there is no better solution........)

@@ -11,6 +11,18 @@ namespace Sep.Git.Tfs.Core
{
public class GitChangeInfo
{
public struct ChangeType
{
public const string ADD = "A";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe LibGit2Sharp has constants for these.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had a look but it seems no...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ChangeKind? I swear we have somewhere in the code that maps between that and what we have.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I'm thinking of what I did in b0eb392

@sc68cal
Copy link
Contributor
sc68cal commented Jan 4, 2013

I'm getting a little bit less enthused with the patch as I keep looking it over. We're creating new structs/enums to parse out the change type, just because we haven't bitten the bullet and switched over to using LibGit2Sharp to read out these statuses.

Maybe we should go ahead and refactor GetChangedFiles so that we can stop creating new clasess and other crap to handle parsing the command output, and just rely on LibGit2Sharp classes.

@spraints
Copy link
Member
spraints commented Jan 4, 2013

I think checking the TFS "tree" is the right approach. I'd like this to be decoupled more, though. Could it be done as a second pass inside of PendChangesToWorkspace(), after applying the git diff, rather than embedded into GetChangedFiles?

@pmiossec
Copy link
Member Author
pmiossec commented Jan 6, 2013

@sc68cal I don't really understand your point of view...
Yes, refactoring is possible but few are able to do this refactoring! And it could take a long time...

And correcting this bug (this way or another) instead of waiting the end of the refactor is in my opinon better...

@kgybels
Copy link
Contributor
kgybels commented Jan 7, 2013

@sc68cal Before refactoring GetChangedFiles, better wait until the rename detection in LibGit2Sharp is finished (libgit2/libgit2sharp#278).

@sc68cal
Copy link
Contributor
sc68cal 8000 commented Jan 7, 2013

Cool. Thanks @kgybels !

@iSynaptic
Copy link

Any idea when this change is going to get pulled in?

@spraints
Copy link
Member

@iSynaptic - It's not done. I did some of the refactoring I had in mind at spraints/git-tfs@delete-orphans, but I still need to try it out to make sure that it's not broken.

@spraints spraints merged commit 8a025db into git-tfs:master Jan 25, 2013
@pmiossec pmiossec deleted the delete_orphan_folder branch January 25, 2013 18:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants
0