V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  xiangyuecn  ›  全部回复第 7 页 / 共 132 页
回复总数  2634
1 ... 3  4  5  6  7  8  9  10  11  12 ... 132  
不是不可以,但假如有天 app 被某个第三方针对了,不允许你调用时,你就知道错了。记得早年的抖音 app 就吃过这个亏
@zhuisui #88 我也不知道是哪里的问题

“比如已有 a.txt ,我现在要个 b.txt 。 如何复制出 b.txt 这个文件,并且复制前的历史和 a.txt 保持一致?”

这句是主题里面的原文,这段话不清楚是不是有歧义,还是需求描述不够准确,也没人提这句话有没有毛病😂
@quqiu #91 复制的新文件 b.txt 第一次提交前,不要修改内容,提交前要保持和老文件 a.txt 一致,提交后就能关联到 a.txt 的历史记录。如果修改了不一致就会关联不上,目前测试结果是这样的

老文件 a.txt 也可以修改,修改后再复制出 b.txt ,只要提交时,两个文件内容一致,提交后就能关联上
@geelaw #86 测试结果来看,git 本身是支持类似 git cp 的命令的,就是提交的时候 人为的保证复制的新文件和老文件内容一致,提交上去,外行人来看他们就自动的关联到了一起了。修改新文件再提交就没有这个效果

跟用的 git 命令、还是 TortoiseGit 图形界面,在这个功能上是没有区别的

cp mv 这种应该是属于同一类基本操作,要是 git 以前能明确显式的支持 cp 命令,后面这个修改复制的文件后再提交导致的不能关联的问题,也就会不存在了
@lnbiuc #83 是的,您说的对,谢谢,已经解决了 简单有效
@zhuisui #79 翻文档也得找到到地方,时间成本太高,前几天问 deepseek ,给的解决方案太复杂
实际压根什么都不需要做就能解决,前提是要知道怎么规避会产生影响的地方,完事

上面还有个让我 fork git 源码,自己实现这个功能😂
@lnbiuc @63 “欢迎 fork 此仓库,就叫 xiangyuecn-git 如何” 不感兴趣,欢迎提点有建设性的意见。

对于源码管理,一个复制的文件,文件本身是有来源的也有历史记录,但 git 没法简单做到这个复制,这本身就是少了点什么

在本地文件目录里面,直接复制一个新文件改改提交,使用场景中规中矩,可能很多时候不会去在意这个历史记录而已
@j869716 #60 “谢谢, 已 block”,不谢😘
@mangoDB #58 主题里面 [写的是] “并且复制前的历史和 a.txt 保持一致?”,复制前的记录两个文件保持一致。 [没说] 没说复制之后去修改 b.txt 的记录,也要去两个文件记录保持一致 [没说] 。难绷😐
@geelaw #22 感谢,前几天 deepseek 也给出了类似的方案,我就是嫌操作起来太复杂了,要是有 git cp 一条命令解决,这个世界就安静了,这记录如果没有简单操作实现,其实不要历史也没什么关系,提交的时候 commit 里面手动备注是从 a.txt 复制来的,到了这个位置就手动切换到 a.txt 查看历史
@WhiskerSpark “想看历史记录就去看 a.txt 就好了”,目前就是这样看历史记录的,总感觉差点意思
@mangoDB 我不需要“理念”
@gesse 我不需要“哲学”

我只想要我复制出的文件能简单的做到历史记录追踪😐
@whoosy @xubingok “伪造” “造假”
比如:新文件 b.txt 提交的时候会有新建文件的记录,显示是从 a.txt 复制。就像 mv 一样 显示从 a.txt 改名 新文件名可以看到以前的老文件名记录

维护一下这个记录很难的嘛🙏
@pagxir @ningxing 不需要提分支功能,跟这个复制毫无干系
@magggia “没戏,跟 git 自身的原理相悖了,不支持”
但又存在 git mv 这个命令,mv 本身按字面意思就是删文件+新建文件,要实现复制只是不需要删文件+新建文件
@BrowerDriver @Iakihsoug
有没有基础可以用的操作,太复杂的不是说不可以学,要用的时候肯得去翻文档,时间成本太高了,前提是知道翻什么地方,不常用的命令普通人也不大会去记 现用现翻文档
@skankhunt42 @cookygg
场景一:a.txt 里面有 500 行代码,现在有个新功能 b.txt ,和 a.txt 功能完全一致,就只用改某一行的几个字

场景二:a.txt 里面有 2000 行代码,现在要把里面后半部分 1000 行拆分到 b.txt 里,拆分出来的代码新文件要有原来的历史记录
225 天前
回复了 mikewang 创建的主题 MySQL 坑爹的字符集问题:踩到了 MySQL 的 bug
前些年发现的:
/t/725189 《多灾多难,今天又来了零宽字符,导致字符串手机号在数据库查询不出结果》

/t/724866 《发现多种数据库 group by 对字符串首尾空格的坑死人不偿命规范》

有些空白/零宽是 trim 不掉的,不同开发语言 tirm 的默认字符范围还不一样,反正到了数据库就会有奇奇怪怪但又很难发现的 bug
1 ... 3  4  5  6  7  8  9  10  11  12 ... 132  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   1109 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 27ms · UTC 17:25 · PVG 01:25 · LAX 09:25 · JFK 12:25
♥ Do have faith in what you're doing.