From: Jakub Narebski <jnareb@gmail•com>
To: git@vger•kernel.org
Subject: Re: FFmpeg considering GIT
Date: Thu, 03 May 2007 01:48:26 +0200 [thread overview]
Message-ID: <f1b806$nc7$1@sea.gmane.org> (raw)
In-Reply-To: loom.20070502T111026-882@post.gmane.org
Panagiotis Issaris wrote:
> Some of the people of the FFmpeg project are looking at both GIT and Mercurial
> as possible replacements for the current Subversion repository. They have some
> questions regarding the possibility of doing certain things, which I prefer not
> to answer as I am not sure my answer would be correct :) Which is why I am
> posting here...
>
> The questions are stated in this e-mail [1]. One of the things that are being
> discussed is the following action on a publicly mirrored repository:
> git branch -m master dead_end
> git branch -m last_good master
>
> I'd think this would fail as people could have pulled from the repository while
> the "dead_end" commit was already available, right?
>
> There are some other things the FFmpeg maintainer mentions, namely:
> * He wants to be able to revert a commit in some way without "wiping" history.
> That is without committing a patch which reverses the broken commit, as this
> would pollute "git blame". The maintainer sees this as critical feature for
> switching to git as it apparently can be doing using Subversion:
> "in svn we can do this with svn cp from a specific
> revission git and mercurial lack proper copy support"
About removing a commit: assume that you have the following history
A---B---C---D---E <--- branch
Now you have noticed that commit C is wrong, and it should not be there.
One solution, which is used usually if the history was published, is to
revert a commit, resulting in the following history:
A---B---C---D---E---C^-1 <--- branch
(which is what git-revert does).
Now if you didn't publish this history, or you don't care that you are
rewriting history, it is fairly easy to remove commit C (for example
using "git rebase --onto B D E" command), resulting in the following
history:
A---B---C---D---E
\
\
\----D'--E' <--- branch
(which after pruning would result in A---B---D'--E' history).
The problem exists _only_ if somebody based his/her work on commit
C or its descendant, i.e. original D, E commits. He/she would have
to rebase his/her work on top of _changed_ (moved) commits D' and E'.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
next prev parent reply other threads:[~2007-05-02 23:48 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-02 9:29 FFmpeg considering GIT Panagiotis Issaris
2007-05-02 23:48 ` Jakub Narebski [this message]
2007-05-03 1:03 ` Petr Baudis
2007-05-04 0:42 ` Jakub Narebski
2007-05-04 7:21 ` [RFC?] Telling git about more complex relationships between commits (Was: Re: FFmpeg considering GIT) Johan Herland
2007-05-04 9:36 ` Alex Riesen
2007-05-04 11:39 ` Andy Parkins
2007-05-04 12:06 ` Andrew Ruder
2007-05-04 12:30 ` Johan Herland
2007-05-04 11:53 ` Johan Herland
2007-05-04 22:11 ` Alex Riesen
2007-05-05 12:49 ` Johan Herland
2007-05-05 18:03 ` Alex Riesen
2007-05-05 16:13 ` Johan Herland
2007-05-04 11:10 ` Petr Baudis
2007-05-04 12:22 ` Johan Herland
2007-05-03 1:48 ` FFmpeg considering GIT Martin Langhoff
2007-05-03 18:00 ` Uwe Kleine-König
2007-05-03 20:00 ` Petr Baudis
2007-05-03 20:05 ` david
2007-05-03 20:13 ` Petr Baudis
2007-05-04 13:46 ` Michael Niedermayer
2007-05-04 15:53 ` Andy Parkins
2007-05-04 16:09 ` Johannes Sixt
2007-05-04 17:23 ` Florian Weimer
2007-05-04 16:40 ` Nicolas Pitre
2007-05-04 18:17 ` Carl Worth
2007-05-04 18:25 ` Johan Herland
2007-05-04 20:24 ` Michael Niedermayer
2007-05-05 4:15 ` Linus Torvalds
2007-05-05 13:35 ` Karl Hasselström
2007-05-05 17:26 ` Linus Torvalds
2007-05-05 22:18 ` Linus Torvalds
2007-05-05 22:30 ` Linus Torvalds
2007-05-06 7:49 ` Junio C Hamano
2007-05-07 12:13 ` Paul Mackerras
2007-05-07 12:30 ` Karl Hasselström
2007-05-07 12:50 ` Johan Herland
2007-05-07 12:56 ` Alex Riesen
2007-05-08 6:30 ` Marco Costalba
2007-05-09 4:28 ` Paul Mackerras
2007-05-09 6:38 ` Marco Costalba
2007-05-09 18:17 ` Robin Rosenberg
2007-05-09 18:28 ` Jan Hudec
2007-05-09 21:09 ` Fredrik Kuivinen
2007-05-09 21:36 ` Jan Hudec
2007-05-10 11:20 ` Marco Costalba
2007-05-10 16:52 ` Jan Hudec
2007-05-07 17:52 ` Jan Hudec
2007-05-07 22:10 ` Gábor Farkas
2007-05-07 23:21 ` Randal L. Schwartz
[not found] ` <fcaeb9bf0705080707x7ad28afelf98ecd93276042d1@mail.gmail.com>
2007-05-08 15:53 ` Gábor Farkas
2007-05-07 19:10 ` Junio C Hamano
2007-05-08 2:03 ` Shawn O. Pearce
2007-05-08 7:26 ` Jeff King
2007-05-06 7:56 ` Karl Hasselström
2007-05-06 10:19 ` Karl Hasselström
2007-05-06 16:38 ` Linus Torvalds
2007-05-06 8:15 ` Marco Costalba
2007-05-06 11:14 ` Karl Hasselström
2007-05-06 12:19 ` Marco Costalba
2007-05-06 12:33 ` Karl Hasselström
2007-05-06 12:33 ` Marco Costalba
2007-05-06 12:59 ` Karl Hasselström
2007-05-06 13:03 ` Karl Hasselström
2007-05-09 22:30 ` Pavel Roskin
-- strict thread matches above, loose matches on Subject: below --
2007-05-08 3:39 Brett Schwarz
2007-05-08 4:06 ` Paul Mackerras
2007-05-08 4:19 ` Shawn O. Pearce
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='f1b806$nc7$1@sea.gmane.org' \
--to=jnareb@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox