On Tue, Nov 08, 2016 at 12:12:34PM -0500, Nick Sabalausky via Digitalmars-d wrote:
> On 11/08/2016 11:57 AM, H. S. Teoh via Digitalmars-d wrote:
> > 
> > The thing about git is that at its core, it's really very simple. Dumb, even.  It's basically a program for managing a directed acyclic graph (DAG).  That's all there is to it. The rest is just frills.
> > 
> > Trying to rationalize git in terms of traditional version control systems is what usually causes lots of confusion, incomprehension, and frustration.  To truly grok git, you have to just forget about traditional version control concepts, and think purely in terms of DAGs.  Once you do, everything falls into place and it all makes sense in its own peculiar way (including all the flaws :-P).
> > 
> 
> I don't suppose you have a handy link to an "Understanding Git as a DAG manager instead of VCS" document?

Nothing immediately comes to mind, but thanks to Dr. Google, I found this page that's sorta helpful:

	http://ericsink.com/vcbe/html/directed_acyclic_graphs.html

And perhaps these:

	http://eagain.net/articles/git-for-computer-scientists/
	http://marklodato.github.io/visual-git-guide/index-en.html

Or maybe I should write my own article about git being based on a DAG. :-P


T

-- 
Leather is waterproof.  Ever see a cow with an umbrella?

On Tuesday, 8 November 2016 at 16:40:31 UTC, Nick Sabalausky wrote:
> On 11/05/2016 11:48 AM, Marc Schütz wrote:
>> On Saturday, 5 November 2016 at 01:21:48 UTC, Stefan Koch wrote:
>>>
>>> I recently lost 3 days of work because of my git-skills.
>>
>> Unless you haven't committed your work yet, almost everything in Git can
>> be undone. Make a copy of your entire project directory (including .git)
>> and then have a look at `git reflog` around the time the disaster
>> happened. It will show you commit IDs that you can check out.
>
> Yea, but unless you're a git-fu master, sometimes figuring out how to fix whatever got messed up can lose you 3 days of work ;)
>
> I really want to make a saner CLI front-end for git, but that would require learning more about git than I really ever want to know :(

http://gitless.com/

Back to CTFE.
The 64Bit bug is fixed.
And now there is one bailout-line less.

I am onto the next bug.
Let's hunt them all down!

On 11/08/2016 02:30 PM, Patrick Schluter wrote:
> I describe git not as a vcs but as exacly what Linus Torvalds described
> it when he first presented it the Kernel mailing list: a directory
> content state recorder optimized for text files.
>

...that's incapable of comprehending the concept of empty directories, contrary to every major file system in use.

I never bought the argument about "b/c it tracks content, not files". If that really did explain the limitation, then it wouldn't be capable of handling empty *files* either, and yet it does.

On 11/08/2016 05:54 PM, Nick Sabalausky wrote:
> On 11/08/2016 02:30 PM, Patrick Schluter wrote:
>> I describe git not as a vcs but as exacly what Linus Torvalds described
>> it when he first presented it the Kernel mailing list: a directory
>> content state recorder optimized for text files.
>>
>
> ...that's incapable of comprehending the concept of empty directories,
> contrary to every major file system in use.
>
> I never bought the argument about "b/c it tracks content, not files". If
> that really did explain the limitation, then it wouldn't be capable of
> handling empty *files* either, and yet it does.
>

(Pardon the OT)

On Tuesday, 8 November 2016 at 21:56:32 UTC, Stefan Koch wrote:
> I am onto the next bug.
> Let's hunt them all down!

Marvellous!

On Tuesday, 8 November 2016 at 21:56:32 UTC, Stefan Koch wrote:
> Back to CTFE.
> The 64Bit bug is fixed.
> And now there is one bailout-line less.
>
> I am onto the next bug.
> Let's hunt them all down!

https://media.giphy.com/media/FmNXeuoadNTpe/giphy.gif

On Tue, 08 Nov 2016 11:44:50 -0500, Nick Sabalausky wrote:
> I really wish Google would take that to heart. They seem to make a habit of ripping things out *before* having replacements in place.
> 
> I think they just simply love deleting code.

I've seen this more internally than externally. The joke was that there are two versions of everything: the deprecated one, and the one that doesn't work yet.

On Tuesday, 8 November 2016 at 21:56:32 UTC, Stefan Koch wrote:
> Back to CTFE.
> The 64Bit bug is fixed.
> And now there is one bailout-line less.
>
> I am onto the next bug.
> Let's hunt them all down!

More 64bit bugs appeared that were shadowed by the one I fixed.
Also a new bugs related to labeled breaks appeared.

After the bad news now a bit of good news.
I just finished the strCat algorithm;

The reason this took so much time is because of the representation the heap has in the elevator.
it is a uint[] meaning you are getting into trouble with offsets if the first string is not a multiple of 4 characters long:)
This is the code for strcat :

uint[] strcat(const uint[] a, const uint[] b, uint aLength = 0, uint bLength = 0)
{
  aLength = a[0];
  bLength = b[0];
  uint resultLength = a[0] + b[0];
  uint[] result;
  result.length = neededArraySize(resultLength);
  assert(result.length == (a.length + b.length) - 2);
  result[0] = resultLength;
  auto resultPosition = 1;

  auto aMinusOne = !(aLength & 3);
  foreach(p, ca; a[1 .. $ - aMinusOne])
  {
    result[resultPosition++] = ca;
  }
  // this one is easy we just copy
    auto bMinusOne = !(bLength & 3);

  uint offset = aLength & 3;
  if (offset)
  {
    assert(offset == 2);
    resultPosition--;
    foreach(p, cb; b[1 .. $])
    {
      result[resultPosition++] |= (cb & ((1U << (offset*8)) -1)) << (offset*8);
      if (resultPosition == result.length) break;
      result[resultPosition++] |= (cb & ~((1U << (offset*8)) -1)) >> (offset*8);
      resultPosition--;
    }
  }
  else
  {
    foreach(p, cb; b[1 .. $ - bMinusOne])
    {
      result[resultPosition++] = cb;
    }
  }

  return result;
}

uint neededArraySize(uint size)
{
  return (((size - 1) / 4) + 2) + (!(size & 3));
}