Thread (72 messages) flat view 72 messages, 20 authors, 2016-06-15

Re: What's cooking in git.git (topics)

From: Petr Baudis <hidden>
Date: 2016-06-15 22:44:52

Possibly related (same subject, not in this thread)

On Mon, Jun 30, 2008 at 03:15:52PM -0700, Junio C Hamano wrote:
I do not recall if Cogito required to have .git/branches created by us or
it can create it on demand if we don't.  If the latter, that would be
great, otherwise remaining users would be in the latter camp as well, and
we may have to make sure Cogito is really dead already (or wait for it to
die), or Cogito gets updated for its remaining users to tolerate the
initial lack of the directory (and wait for that version percolates down
to the users).
Cogito is getting somewhat broken by removing of the git- plumbing from
$PATH anyway (you have to hack around it; and I'm not saying it's bad
thing).

But it is actually quite resilient against this kind of stuff (as it was
constructed to be able to run on very rudimental repositories dating
early to the dawn of time). All versions supporting .git/branches [*] will
autocreate the .git/branches directory if missing.

[*] .git/branches was actually called .git/remotes even earlier; yay,
how rich our history is. ;-)
Some people rely on (or at least "like") the convenience of being able to
create a single-liner file in .git/branches/ to easily add, and remove
such a file to easily remove where they integrate from.  This is
especially so when they have dozens of source repositories to fetch from.
I do not think we want to remove support for .git/branches as a way to
specify fetch sources (this is why I am CC'ing Andrew who I know uses
branches, and Stephen who is also a heavy integrator even though I do not
know if he is in branches camp or uses more modern style), but they now
have to do an extra "mkdir .git/branches" after "git init" to continue
their workflow if we adopt the change you are proposing here.  It is not a
big deal, but it still is a backward incompatible change.
Now, I think it would be nice to keep backward compatibility here. I'm
still _regularly_ running into people who still use Cogito (and it's not
because they know me :-)) and are only now doing the switch, or only
planning to yet.

(On the other hand, using Git on repositories created by old Git
versions or Cogito can be quite a confusing experience for non-expert
users - things related to remote repositories behave differently to what
the documentation describes, obviously.  Maybe it _would_ be reasonable
option to do something radical when hitting old repository, like
"(Re-)clone me for non-confusing user experience, pretty please, or
git-config force_old_repo 1 if you know what are you doing.")

-- 
				Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help