Junio C Hamano wrote:
> So from my point of view, a proposal to remove them has an almost no
> benefit vs potentially very high cost of having to break many people
> who are silently happily using them; not a very good benefit/cost
> ratio.
Yep, it should stay around because it's useful to some pe
Junio C Hamano writes:
> I myself thought that replacing the established work process of
> these people to the one that instead uses "git config" should be
> simple enough even back then, and in the longer term, these old
> mechanisms will become disused so that we can remove them, but
> deciding
Junio C Hamano wrote:
> The last time I hinted removal of .git/branches/, Andrew Morton
> reminded me that there are those who use Git primarily to fetch from
> many dozens of other people's branches, to maintain his own quilt
> patch series on top of, and never push anything back. To them,
> bein
Ramkumar Ramachandra writes:
> This is a cleanup operation to get rid of the historical
> $GIT_DIR/{branches,remotes} cruft. Mostly no-brainers that don't
> deserve a second look.
Only reacting to "no-brainer".
The last time I hinted removal of .git/branches/, Andrew Morton
reminded me that th
Hi,
This is a cleanup operation to get rid of the historical
$GIT_DIR/{branches,remotes} cruft. Mostly no-brainers that don't
deserve a second look. The ordering of the series might be somewhat
weird, but that's because it's the order in which I wrote those
patches: rebasing results in stupid co
5 matches
Mail list logo
