On Thu, Jan 6, 2011 at 4:38 PM, Garrett Cooper wrote:
> On Thu, Jan 6, 2011 at 1:30 PM, Mike Frysinger wrote:
>> On Thu, Jan 6, 2011 at 2:35 PM, Garrett Cooper wrote:
>>> A really bad merge (I posted a reply to it a while ago in the archives).
>>
>> is there a way for us to manage the git hooks ? we could have them
>> reject trivial merge commits (ones that should be fast forwards), and
>> commits with merge cruft in it ...
>
> This was nastier. A lot of the problems I caused was ignorance and
> human error based -- in particular I thought that git reset --hard
> would actually reset merges (but it didn't!)
sure it will ... you just have to reset to before the merge
> I didn't bother to fake the push before I did it and the rest is history.
if you caught it soon, you could have pushed up an old one and forced
it back to the sane state ...
git push --force origin <older commit>:refs/head/master
> So I don't know if adding hooks would fix that
i saw that you had actual conflicts in there, and the hook would have
caught that (">>>>>>>>>" and "=========" and such)
but i'm not sure if your non-trivial merge would have been detected as
a trivial merge since we dont want that (it'd prevent people from
being able to pull a branch from someone else)
-mike
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
