As I see this, we need to pick the better of two options, even when neither is 
perfect. I’d rather have magnum’s source as intuitive and easy to maintain as 
possible. If it becomes more difficult to follow the commit history for a file 
in order to achieve that improvement, I’m willing to live with it. In truth, 
following the commit history of a file is not something we do often in our 
development workflows, so it does not need to be optimized. On the other hand, 
looking at the contents of our source tree is something that all of us do 
often, and we deserve to have that be nice and clear.


On Nov 19, 2015, at 1:13 AM, Tom Cammann 
<<>> wrote:

This is a defect with Github and should not affect our ability to fix defects 
and correct/refactor our code. git is a CLI tool not a GUI tool and should be 
treated as such. We should not be imposing restrictions on our developers 
because a 3rd party GUI does not fit our workflows.


On 18/11/15 22:48, Hongbin Lu wrote:
Hi team,

I would like to start this ML to discuss the git rename issue. Here is the 
problem. In Git, it is handy to retrieve commit history of a file/folder. There 
are several ways to do that. In CLI, you can run “git log …” to show the 
history. In Github, you can click “History” bottom on top of the file. The 
history of a file is traced back to the commit in which the file was created or 
renamed. In other words, renaming a file will cut the commit history of the 
file. If you want to trace the full history of a renamed file, in CLI, you can 
use “git log –follow …”. However, this feature is not supported in Github.

A way to mitigate the issue is to avoid renaming file/folder if it is not for 
fixing a functional defect (e.g. for improving the naming style). If we do 
that, we sacrifice quality of file/folder names to get a more traceable 
history. On the other hand, if we don’t do that, we have to tolerant the 
history disconnection in Github. I want to discuss which solution is preferred? 
Or there is a better way to handle it?

Best regards,

OpenStack Development Mailing List (not for usage questions)

OpenStack Development Mailing List (not for usage questions)

OpenStack Development Mailing List (not for usage questions)

Reply via email to