* how to fix the problem correctly?
@ 2010-04-28 16:54 Eugene Sajine
2010-04-28 18:30 ` Avery Pennarun
0 siblings, 1 reply; 3+ messages in thread
From: Eugene Sajine @ 2010-04-28 16:54 UTC (permalink / raw)
To: git; +Cc: Eugene Sajine
I have a following situation (in dev branch):
3 files:
1.txt, 2.txt, 3.txt
A -> B -> C -> D -> E
| |
Master dev
Between B and C the version of file 1.txt was screwed up (let’s say it
was copied into git repo from other location where it was in state A
(CVS) and then committed by mistake in C, effectively reverting the
change of this file in commit B)
Commit C also had changes to files 2 and 3.
After this commits D and E did not have changes for file 1.txt, only 2
and 3 were touched.
When we tried to revert commit C – this lead to the code completely
messed up, with conflicts – so this seems to be not an option.
Rebase also doesn’t seem to help here
Only two variants I saw:
1. Do “git co A 1.txt” and commit the change as F
2. Do “git reset –soft master” and recommit all changes once again
Is there a better way?
PS interesting enough – CVS keywords helped us to notice the problem
as master state was imported from CVS.
In commit A file 1.txt had version ID 1.5 in commit B it was 1.6 ,
commit C was changing the line back to 1.5
Is there a way for git to help me to recognize this kind of issue if
there are no keywords?
DISCLAIMER: I don’t like keywords, and I don’t want them to be
implemented in git.
Thanks,
Eugene
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: how to fix the problem correctly?
2010-04-28 16:54 how to fix the problem correctly? Eugene Sajine
@ 2010-04-28 18:30 ` Avery Pennarun
2010-04-28 18:55 ` Eugene Sajine
0 siblings, 1 reply; 3+ messages in thread
From: Avery Pennarun @ 2010-04-28 18:30 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
On Wed, Apr 28, 2010 at 12:54 PM, Eugene Sajine <euguess@gmail.com> wrote:
> Between B and C the version of file 1.txt was screwed up (let’s say it
> was copied into git repo from other location where it was in state A
> (CVS) and then committed by mistake in C, effectively reverting the
> change of this file in commit B)
> Commit C also had changes to files 2 and 3.
> After this commits D and E did not have changes for file 1.txt, only 2
> and 3 were touched.
>
> When we tried to revert commit C – this lead to the code completely
> messed up, with conflicts – so this seems to be not an option.
> Rebase also doesn’t seem to help here
>
> Only two variants I saw:
> 1. Do “git co A 1.txt” and commit the change as F
> 2. Do “git reset –soft master” and recommit all changes once again
>
> Is there a better way?
Virtually any way that works is "correct." It depends a bit on your goals.
Step 1 is certainly the easiest place to start. If you're then
concerned about making sure your history never showed the mistake
(which is a lofty goal, though rarely very important), you could use
git rebase to 'squash' this new commit into C. But rewriting history
in git has well-documented dangers, so you should be careful and read
the docs first.
> PS interesting enough – CVS keywords helped us to notice the problem
> as master state was imported from CVS.
> In commit A file 1.txt had version ID 1.5 in commit B it was 1.6 ,
> commit C was changing the line back to 1.5
> Is there a way for git to help me to recognize this kind of issue if
> there are no keywords?
Sadly, git doesn't have any magic features for detecting when someone
checks in something stupid :) But 'git bisect' can be very helpful
in isolating which commit caused a particular problem. Once you know
you have a problem, it's pretty easy to narrow it down that way.
Have fun,
Avery
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: how to fix the problem correctly?
2010-04-28 18:30 ` Avery Pennarun
@ 2010-04-28 18:55 ` Eugene Sajine
0 siblings, 0 replies; 3+ messages in thread
From: Eugene Sajine @ 2010-04-28 18:55 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git
>
> Virtually any way that works is "correct." It depends a bit on your goals.
>
> Step 1 is certainly the easiest place to start. If you're then
> concerned about making sure your history never showed the mistake
> (which is a lofty goal, though rarely very important), you could use
> git rebase to 'squash' this new commit into C. But rewriting history
> in git has well-documented dangers, so you should be careful and read
> the docs first.
Good idea to clean up with rebase after step 1. I didn't think about
that, thanks! And yes I know about the restrictions;)
>
>> PS interesting enough – CVS keywords helped us to notice the problem
>> as master state was imported from CVS.
>> In commit A file 1.txt had version ID 1.5 in commit B it was 1.6 ,
>> commit C was changing the line back to 1.5
>> Is there a way for git to help me to recognize this kind of issue if
>> there are no keywords?
>
> Sadly, git doesn't have any magic features for detecting when someone
> checks in something stupid :) But 'git bisect' can be very helpful
> in isolating which commit caused a particular problem. Once you know
> you have a problem, it's pretty easy to narrow it down that way.
yes, it is very hard to be fool-proof. I just got an idea:
In this particular case some script scanning for pairs of commits
where blob SHA-1 changes
are like below (for the same path) and warns about such occurrences.
commit 1111
... blobaaaaaa... blobbbbbbb... path
commit 3333
... blobbbbbbb... blobaaaaaaa... path
Unless the commit 3333 is a real revert, this might be suspicious, isn't it?
I don't know if it has any real sense or use, but i will try to create
such thing at least as an exercise...
Thanks,
Eugene
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-04-28 18:55 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-04-28 16:54 how to fix the problem correctly? Eugene Sajine
2010-04-28 18:30 ` Avery Pennarun
2010-04-28 18:55 ` Eugene Sajine
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.