response
This commit is contained in:
		
					parent
					
						
							
								de408626b7
							
						
					
				
			
			
				commit
				
					
						bd54dadb0b
					
				
			
		
					 1 changed files with 10 additions and 0 deletions
				
			
		| 
						 | 
					@ -6,3 +6,13 @@ However, if 2 copies are unannexed, only one is restored, the other becomes a br
 | 
				
			||||||
so my plan is to unninit this repo, delete the .git dir, and then annex everything, as I don't mind the history).
 | 
					so my plan is to unninit this repo, delete the .git dir, and then annex everything, as I don't mind the history).
 | 
				
			||||||
 | 
					
 | 
				
			||||||
Rafaël
 | 
					Rafaël
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					> The only way for git-annex to support this in its current state would be
 | 
				
			||||||
 | 
					> for the unannex command to copy the file content from the annex, rather
 | 
				
			||||||
 | 
					> than moving it out. Then multiple links to the same content could be
 | 
				
			||||||
 | 
					> unannexed.
 | 
				
			||||||
 | 
					> 
 | 
				
			||||||
 | 
					> But, this would be slower, and would depend on a later `unused` and
 | 
				
			||||||
 | 
					> `dropunused` to actually remove the content. While doable, by use case
 | 
				
			||||||
 | 
					> for unannex is more to quickly undo a mistaken add, and it's unlikely there
 | 
				
			||||||
 | 
					> are multiple symlinks to the same content in this situation. --[[Joey]] 
 | 
				
			||||||
| 
						 | 
					
 | 
				
			||||||
		Loading…
	
	Add table
		Add a link
		
	
		Reference in a new issue