[haiku-development] Re: VOTE: Git or Mercurial (hg) as Haiku's new source control tool

  • From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 14 May 2011 18:13:55 +0200

On 2011-05-14 at 15:30:52 [+0200], Adrien Destugues 
<pulkomandy@xxxxxxxxxxxxxxxxx> wrote:
> 
[ ... ]
> We are hopefully going to see more branches, and less patches. Some of
> the branches will live on the main Haiku server, and these may or may
> not get numbering of changesets. We will also likely see branches/forks
> hapenning on github or bitbucket or whatever other site offering similar
> services : like patches in the current situation, these won't get a number.

As I imagine it, there will be no branches except for master and release 
branches in our central repository. Developer/topic branches live elsewhere.

> What I want is *not* "as much information as you can realistically find
> out" : this gets me information about the date&time, the branch where it
> took place, an incremental distance, and a short hash. I don't need any
> of this, actually. I need a way to know if a commit is from last week,
> month, year, or older than that. A full date is good for recent commits,
> but for older ones it doesn't have any use to get second-precision :
> only the year "2003" would tell me enough : if you're running that on
> your computer, upgrade now ! SVN commit numbers have the effect of
> providing a kind of logarithmic scale easily : look at the first number
> and you already know something. If it's a 4, the commit is recent. If
> it's a 2, it's old. then look at more digits if you need so.
> 
> The number SVN way is very short, so it's easy to copy around and use on
> Trac tickets. It gives just the amount of information I need, and it is
> human-readable and machine-readable.
> 
> I know I'll discover a lot of new tools to examine the history, but I
> still find it unpleasant to work with hashes or the proposed
> date-branch-number-hash stuff : it's just too long to be easy to work with.
> 
> Maybe try to think of it a bit like phone numbers : I know with modern
> technology, they are not needed anymore we could use some plaintext
> "place-1stname-lastname-hash" scheme there too. It would work, it would
> be more readable, when you see something in this format you know who
> owns it, where does he live. But :
>   * If you want to remember the number, you still have to learn the hash
> like you had to learn the phone number before
>   * It's longer to type when you want to dial
> Both can be overcome with modern phones having a contact list, but would
> you forget about phone numbers anyway ? they're easy to share and you
> don't need a contact list, you can still use them if you know them.
> 
> I feel the same for both phone numbers and svn commit numbers : they
> give you some information, but not everything ; they are short enough to
> easily work with them (dialing a number or checking out a revision
> requires only a small amount of typing) ; they are useable both by
> humans and machines easily. They don't do everything, but we don't
> expect that from them. There are of course complementary tools to make
> the life even easier. Maybe they'll fade away over time, but I don't
> think it's good to have them disapear suddenly. Give us some time to get
> used to the new tools and stop using the numbers before phasing them
> out, if that is to ever happen.

All very well, but just how would you actually implement those numbers in Git 
or Mercurial? Unless you find a way to do that, this whole argument is 
pointless.

cheers,
        Oliver

Other related posts: