Petr Baudis <pasky <at> suse.cz> writes:
[...]
quoted text
> > 	let me explain a little bit why this is critically needed
> > 	think of someone misstakely commiting the whole ffmpeg
> > 	reindented or mistakely commiting a old ffmpeg version over the
> > 	new or another total messup, these things do happen, and
> > 	especially if they cannot be corrected and at the time where
> > 	none of the developers is around
> > 
[...]
quoted text
>   Still, if this kind of bogus change checkins happens at any frequent
> rate in the ffmpeg project, there is a serious problem somewhere. 

well, my example above was exagerated, noone ever reindented the whole
ffmpeg or checked in a old version over HEAD. what did and does occasionally
happen is that people check in several things at once (like a 100k reindenton
mixed with various functional changes)
for these we currently copy the last good version of the affected files
over the current one with svn cp and then apply the changes in nicely
split manner. (possibly without the reindention if its uneeded ...)
Another thing that happens occasionally is that complete nonsense is checked
in like checking in the wrong file or some "private" debuging code

we never use the svn cp method to revert normal buggy code ...



quoted text
> But I think the git way of alleviating this problem would be to have a
> way to hint the pickaxe and blame tools to ignore changes in given
> commits. So, you don't _cover up_ the messy things that happened during
> the history, but avoid in getting in the way in your view. You can still
> look it up (with git log or something) in case you'd need to (perhaps
> the revert patch was a bit complicated because of conflicting with some
> other changes, and a subtle bug was introduced; this would be thousand
> times harder to track down if you would've rewritten the history).
> 
>   Would crafting up a patch to implement something like this help ffmpeg
> people in their decision?

well if git blame and others could somehow be told to automatically ignore
nonsense changes and matching nonsense reverts that would be great
maybe by searching for some keyword in the revert message?

ignoring all or no reverts though would again be suboptimal as that would
also ignore some reverts due to normal buggy changes

actually i think ive found an almost working solution for replacing svn cp
(though i dont know if its safe on a public repo? or if theres some other
issue with it iam missing)

ascii > testfile
git add testfile ; git commit
Created initial commit c14755cd59af4b0e6c53fb3d4bf8fa7d5aad3f3d
 1 files changed, 23 insertions(+), 0 deletions(-)
 create mode 100644 testfile

vim testfile 
git add testfile ; git commit
Created commit 0fd74c0955ae4281ac17520eabefea639f635354
 1 files changed, 2 insertions(+), 2 deletions(-)

vim testfile 
git add testfile ; git commit
Created commit d1dce0e5a20603faa0e64b722d93e847f5b80845
 1 files changed, 23 insertions(+), 23 deletions(-)

git checkout 0fd74c0955ae4281ac17520eabefea639f635354
Note: moving to "0fd74c0955ae4281ac17520eabefea639f635354" which 
isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
  git checkout -b <new_branch_name>
HEAD is now at 0fd74c0... good change

cp testfile testbak
git add testbak ; git commit
Created commit 0e55c6f422005e64fd3b73595f0fe409148d725f
 1 files changed, 23 insertions(+), 0 deletions(-)
 create mode 100644 testbak

git checkout d1dce0e5a20603faa0e64b722d93e847f5b80845
HEAD is now at d1dce0e... bad change
$git rm testfile 
rm 'testfile'

git merge 0e55c6f422005e64fd3b73595f0fe409148d725f
 100% (1/1) done
Merge made by recursive.
 testbak |   23 +++++++++++++++++++++++
 1 files changed, 23 insertions(+), 0 deletions(-)
 create mode 100644 testbak

git mv testbak testfile 
fatal: destination exists, source=testbak, destination=testfile
git rm testfile 
rm 'testfile'
git mv testbak testfile 

git commit
Created commit ca5bcbcadb9799b0a6eaa792fae322d511ecd55f
 2 files changed, 23 insertions(+), 46 deletions(-)
 delete mode 100644 testbak

git blame -C1 -C1 -M testfile
(this just shows ca5bcbca)

vim testfile (changing a single line)
git add testfile ; git commit
Created commit 7a0a828629935ce139177fc4623a0eb9916b78fd
 1 files changed, 1 insertions(+), 1 deletions(-)

git blame -C1 -C1 -M testfile | cut -d ' ' -f 1
^c14755c
^c14755c
^c14755c
^c14755c
^c14755c
0fd74c09
0fd74c09
^c14755c
^c14755c
^c14755c
^c14755c
^c14755c
^c14755c
^c14755c
^c14755c
^c14755c
7a0a8286
ca5bcbca
ca5bcbca
ca5bcbca
ca5bcbca
ca5bcbca
ca5bcbca

this is correct except the last 6 lines

[...]

Michael

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html