Re: git-p4import.py robustness changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Jun 2, 2007, at 2:33 PM, Junio C Hamano wrote:

A much more preferable alternative is for you to say "Hey, don't
say you want to demote it.  I'll keep it maintained, I regularly
use p4 and have a strong incentive to keep it working".  Then we
do not have to do the "patch 0" ;-)

Hmm. I'd like to say that, but keep in mind that I'd never even used git before Wednesday, and I'm not sure yet how well git-p4import.py will work out for me.

It'd be a huge leap from git-p4import.py to something that could remove my need to use p4 commands daily. First, I'd need something that could follow all upstream branches with merge history. Then I'd either need to convince my team to ditch p4 entirely (not easy, and then I wouldn't use/maintain git-p4import.py afterward anyway) or a way to robustly generate "p4 integrate", "p4 resolve", "p4 submit" command sequences to merge between upstream branches.

We're attempting to address more modest needs, like those of our off- site contractors who should only be sending patches anyway. (Another guy wrote a script that pulls changes into an svn mirror basically by "svn ci -m 'changed some stuff'" every half hour, but I made fun of it and now have to replace it. ;)

I'll at least finish up the other patches first and see how it goes.

--
Scott Lamb <http://www.slamb.org/>


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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux