1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
|
Re: High-level Problems with Git and How to Fix Them
####################################################
:date: 2017-12-12
:category: computer
:tags: blogComment, git, DVCS, mercurial, gitlab
(originally written as a comment on `the blogpost`_ by Gregory
Szorc)
Some comments:
1. I like your ideas about the improved documentation and better
sounding options (yes, ``git commit --cached`` is stupid). Did
you file them as RFE to ``git@vger.kernel.org``? I don’t think
they are that controversial.
2. I like your idea about workspaces, and it truly seems like an
ideal, but I think such drastic measures are not completely
necessary. If we just told everybody that more important than
``git clone`` is ``git remote add`` command, and that it is
easy to have five different remotes in the local repository,
things would be better [#]_. I agree that design of
Git{Lab,Hub}/Bitbucket/Sourceforge is poorly based on the idea
of hard clone, but the solution is more in the web user
interface and presentation than in the substance. For example,
I have never understood what's the point of the master branch
on my personal clone of the main repository. That branch
should never be used (``git checkout master && git branch -u
origin/master`` are my first two commands I do after cloning;
origin is of course the primary repository, not my clone) and
it is confusing that it is the default branch displayed on the
webpage of my clone.
3. Concerning the need to name everything, I completely disagree.
The web is full of complaints of people who prefer something
else than git and complain bitterly. I suspect that git
fanboys (and fangirls) who got bitten by Mercurial/bzr are
just silent, being happy that their preferred VCS prevailed.
When doing some Firefox-related projects, I tried hard to do
it in Mercurial (I have even found a repository hosting which
supported hg), but after some weeks of working on my projects,
I got completely frustrated with hg, and moved my project to
git. I have never returned to hg again and I have never looked
back (and yes, it was couple of years ago, and no, I won't try
the latest version, because I don't see one reason why
I should). Multiple unnamed heads in my branches were one of
the biggest pet-peeves I had with hg. Yes, I tried all methods
how to get rid of them I found on the Internet, and no I have
never found a reliable way how to avoid them. So, if the need
to invent short brief name for every branch I make is the
price to pay for sanity, I am all for it. I have never needed
to ask my hosting server admins for wiping out my git repos
and starting over, I had to do it three times with one project
in hg. Never again!
4. Also, I disliked I couldn't overwrite history (yes, I know
about mq extension and other hopeless hacks which try to make
hg model at least somehow palatable, but I just prefer ``git
rebase -i``), and that branches are more or less permanent
(yes, again, I know there is some hack around that).
.. _`the blogpost`:
https://gregoryszorc.com/blog/2017/12/11/high-level-problems-with-git-and-how-to-fix-them/
.. [#] I know there are a way better introductions to git, but
the first good description of how to work with git in the
collaborative manner for me was
https://wiki.gnome.org/Apps/Empathy/Git (yes, it is possible
that this page was the best product of whole Empathy project
;)).
|
