[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On the popularity of git [Was: Git question: when using branches, ho
Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?]
Tue, 03 Nov 2015 09:38:58 -0800
Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux)
On Nov 03 2015, David Kastrup <address@hidden> wrote:
> Nikolaus Rath <address@hidden> writes:
>> On Oct 31 2015, David Kastrup <address@hidden> wrote:
>>> Eli Zaretskii <address@hidden> writes:
>>>> More generally, Git's main problem is that it breaks almost every
>>>> human habit gained with the other VCSes: instead of an easily
>>>> remembered numerical version IDs you have those inhuman hashes
>>> Shrug. In a distributed version control system, numerical version IDs
>>> don't make sense.
>> They make a lot of sense if you don't require them to be constant over
>> time. Mercurial solves this beautifully. It has hashes if you need to
>> constant identifier, but if you just want to refer to the commit that
>> got printed/created/referred to by the command you typed 30 seconds ago,
>> you can use its handy numerical id.
> HEAD~2 works just fine in Git. So does "address@hidden seconds ago}" though
Head-relative references are useful, but no substitute for short numeric
id's of *arbitrary* commits.
# Find first commit after the release following commit 372
$ hg log -r 'limit(sort(descendants(372) and tag("re:^release-"), "date"), 2)'
# ..and show what was changed:
$ hg diff -c 410
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«