On 11/16/15, Ron W wrote:
> On Mon, Nov 16, 2015 at 12:38 PM, bch wrote:
>
>> In the immediate case, it's me tracking 3rd party vendor code which I
>> depend on. I untar, add, commit. On upstream updates, I nuke the
>> 3rd-party
>> code, lay down the
In the immediate case, it's me tracking 3rd party vendor code which I
depend on. I untar, add, commit. On upstream updates, I nuke the 3rd-party
code, lay down the new release and this is where we might find renaming
issues as I described.
On Nov 16, 2015 9:24 AM, "Ron W"
On Mon, Nov 16, 2015 at 12:38 PM, bch wrote:
> In the immediate case, it's me tracking 3rd party vendor code which I
> depend on. I untar, add, commit. On upstream updates, I nuke the 3rd-party
> code, lay down the new release and this is where we might find renaming
>
On Mon, Nov 16, 2015 at 2:20 PM, bch wrote:
> This is roughly what I'm doing, but it's not 100% accurate, and for
> the case of 100s of files, still tedious. I guess the point is that
> there's not any special secret method available with-in or outside
> fossil (outside of
On 11/16/2015 6:00 PM, bch wrote:
Further to that:
http://stackoverflow.com/questions/4908336/can-git-really-track-the-movement-of-a-single-function-from-1-file-to-another-i
To be clear, I don't fully understand what the git model is (I
repeatedly hear "it doesn't track files", but I haven't
On 11/16/15, Ron W wrote:
> On Mon, Nov 16, 2015 at 2:20 PM, bch wrote:
>
>> This is roughly what I'm doing, but it's not 100% accurate, and for
>> the case of 100s of files, still tedious. I guess the point is that
>> there's not any special secret
[apologies if shows this up twice, but I think I messed up the first time]
On Mon, Nov 16, 2015 at 2:20 PM, bch wrote:
> In this sense, the behavour of git (iiuc) would be roughly what I want
> where it tracks bytes, not files (this is what I think I undertand; it
> allows
7 matches
Mail list logo