git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: FFmpeg considering GIT

From
MNMichael Niedermayer <michaelni@gmx.at>
Date
May 4, 2007, 13:46 UTC
Message-ID
<loom.20070504T143538-533@post.gmane.org>
In-Reply-To
<20070503200013.GG4489@pasky.or.cz>

Petr Baudis <pasky <at> suse.cz> writes: [...]

Show 7 quoted lines
> > 	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
> > 
[...]
>   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 ...
Show 11 quoted lines
> 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
Previous: Petr BaudisNext: Andy Parkins
Message 22 of 66 in “FFmpeg considering GIT”
  1. Panagiotis IssarisMay 2, 2007
  2. Jakub NarebskiMay 2, 2007
  3. Petr BaudisMay 3, 2007
  4. Jakub NarebskiMay 4, 2007
  5. [RFC?] Telling git about more complex relationships between commits (Was: Re: FFmpeg considering GIT)Johan Herland, May 4, 2007
  6. Alex RiesenMay 4, 2007
  7. Andy ParkinsMay 4, 2007
  8. Andrew RuderMay 4, 2007
  9. Johan HerlandMay 4, 2007
  10. Johan HerlandMay 4, 2007
  11. Alex RiesenMay 4, 2007
  12. Johan HerlandMay 5, 2007
  13. Alex RiesenMay 5, 2007
  14. Johan HerlandMay 5, 2007
  15. Petr BaudisMay 4, 2007
  16. Johan HerlandMay 4, 2007
  17. Martin LanghoffMay 3, 2007
  18. Uwe Kleine-KönigMay 3, 2007
  19. Petr BaudisMay 3, 2007
  20. david@lang.hmMay 3, 2007
  21. Petr BaudisMay 3, 2007
  22. Michael NiedermayerMay 4, 2007
  23. Andy ParkinsMay 4, 2007
  24. Johannes SixtMay 4, 2007
  25. Florian WeimerMay 4, 2007
  26. Nicolas PitreMay 4, 2007
  27. Carl WorthMay 4, 2007
  28. Johan HerlandMay 4, 2007
  29. Michael NiedermayerMay 4, 2007
  30. Linus TorvaldsMay 5, 2007
  31. Karl HasselströmMay 5, 2007
  32. Linus TorvaldsMay 5, 2007
  33. Linus TorvaldsMay 5, 2007
  34. Linus TorvaldsMay 5, 2007
  35. Junio C HamanoMay 6, 2007
  36. Paul MackerrasMay 7, 2007
  37. Karl HasselströmMay 7, 2007
  38. Johan HerlandMay 7, 2007
  39. Alex RiesenMay 7, 2007
  40. Marco CostalbaMay 8, 2007
  41. Paul MackerrasMay 9, 2007
  42. Marco CostalbaMay 9, 2007
  43. Robin RosenbergMay 9, 2007
  44. Jan HudecMay 9, 2007
  45. Fredrik KuivinenMay 9, 2007
  46. Jan HudecMay 9, 2007
  47. Marco CostalbaMay 10, 2007
  48. Jan HudecMay 10, 2007
  49. Jan HudecMay 7, 2007
  50. Gábor FarkasMay 7, 2007
  51. Randal L. SchwartzMay 7, 2007
  52. Junio C HamanoMay 7, 2007
  53. Shawn O. PearceMay 8, 2007
  54. Jeff KingMay 8, 2007
  55. Karl HasselströmMay 6, 2007
  56. Karl HasselströmMay 6, 2007
  57. Linus TorvaldsMay 6, 2007
  58. Marco CostalbaMay 6, 2007
  59. Karl HasselströmMay 6, 2007
  60. Marco CostalbaMay 6, 2007
  61. Karl HasselströmMay 6, 2007
  62. Marco CostalbaMay 6, 2007
  63. Karl HasselströmMay 6, 2007
  64. Karl HasselströmMay 6, 2007
  65. Pavel RoskinMay 9, 2007
  66. Gábor FarkasMay 8, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.