Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git, Graphs and Software Engineering

third-bit.com

Post reply on HN
Print view View original

21–30 of 40 posts

Re: Git, Graphs and Software Engineering

#21

Post by sheriff »

hyperpape wrote: post #17
sheriff wrote: post #5

Earlier quoted context omitted.

I came here to post something similar. I'll add that many of the hard things we do with Git seem to do with re-ordering or re-combining of the underlying changes. If we want to make it easier to reason about changes to a set of changes, then I think we really want those changes to have some properties which they don't currently have. It's powerful for Git to treat changes as line-by-line text diffs, because it allows…

Curious, have you compared this idea to what Darcs does (I don't know Darcs well enough to do justice to it, but it sounds related).

I'm unfamiliar with Darcs, but thanks for calling it to my attention. Based on a quick look, it appears Darcs uses text diffs, so it's not quite what I'm talking about, but it's definitely interesting.

Re: Git, Graphs and Software Engineering

#22

Post by steventhedev »

sheriff wrote: post #5
sametmax wrote: post #2

Except most hard but interesting operations with Git are not very visible in histories. They are: - getting a clear status of you repo so you know where you are and what you do; - figure out which one of the various method of undo you need for this specific screw up; - find a practical way to compare this particular version of a snippet with another particular version of a snippet, and work on the result; - merge the…

I came here to post something similar. I'll add that many of the hard things we do with Git seem to do with re-ordering or re-combining of the underlying changes. If we want to make it easier to reason about changes to a set of changes, then I think we really want those changes to have some properties which they don't currently have. It's powerful for Git to treat changes as line-by-line text diffs, because it allows…

Git doesn't operate on diffs. It stores full content using delta compression. Subtle difference, but it can create ours reverse merges that don't have a diff, but radically change the content of the repo.

What you're talking about is patch theory, which is used by darcs and pujil. Pujil does a better job of explaining the theory.

At the end of the day, the point of version control is to keep a universally consistent snapshot of a sequence of bytes. Patch theory only tells you how to resolve conflicts. TreeDoc, etc simply resolve the conflicts differently based on consistency of ordering, as patches may be applied out of order for it to be a CRDT.

Re: Git, Graphs and Software Engineering

#23

Post by yeukhon »

fovc wrote: post #4

I think Tarsius already did this and called the result Magit. For bonus points he made it perfectly interoperable with git Edit: Kickstarter campaign going on with 23h left https://www.kickstarter.com/projects/1681258897/its-magit-th...

Personally... this looks confusing... perhaps just an Emacs thing, but I couldn't follow what was going on in the video. Or perhaps the yellow background really threw me off.

Re: Git, Graphs and Software Engineering

#24

Post by sheriff »

hyperpape wrote: post #17
sheriff wrote: post #5

Earlier quoted context omitted.

I came here to post something similar. I'll add that many of the hard things we do with Git seem to do with re-ordering or re-combining of the underlying changes. If we want to make it easier to reason about changes to a set of changes, then I think we really want those changes to have some properties which they don't currently have. It's powerful for Git to treat changes as line-by-line text diffs, because it allows…

Curious, have you compared this idea to what Darcs does (I don't know Darcs well enough to do justice to it, but it sounds related).

An example of what I'm thinking about, which I don't think Darcs can do (I'd love to be wrong):

Alice and Bob both branch off of master at the same point. In Alice's branch, she moves function `foo` into a different module/file. In Bob's branch, he changes `foo` to handle a new condition. Both wish to merge into master.

Whoever merges later is going to have a merge conflict, and have to resolve it manually, using their human understanding of the semantics of both changes. It's clear to me how that conflict should likely be resolved, but as long as those changes are presented as text diffs, I don't expect my VCS to be smart enough to figure that out on its own.

It would be interesting to explore other ways of representing changes, such that a computer would understand how to compose them in more situations like this.

You can quickly come up with examples of changes which conflict in a way that should probably always require human intervention: Say Alice and Bob each wish to assign the same constant to different values.

So, I don't expect that you could completely remove the need for developers to manually resolve tricky conflicts. At least, not without completely changing how we express changes to programs, which may well be a non-starter for practical purposes.

Re: Git, Graphs and Software Engineering

#25

Post by noway421 »

jancsika wrote: post #8
sametmax wrote: post #2

Except most hard but interesting operations with Git are not very visible in histories. They are: - getting a clear status of you repo so you know where you are and what you do; - figure out which one of the various method of undo you need for this specific screw up; - find a practical way to compare this particular version of a snippet with another particular version of a snippet, and work on the result; - merge the…

> - rediscover the arcanes required to save only what you want. Maybe I should branch and commit. Or stash. Or reset and add. Or do an interactive thingy ? Here's something I'm trying: 1. Always branch and commit. 2. Push branch as a work in progress. 3. When branch seems ready to merge, make a new branch from that branch. 4. In the new branch, go crazy. Squash, reorder, whatever the heck. 5. If you screw something u…

Work in progress branch can't be named the same as final branch. That's inconvenient.

reseting back based on reflog is more straightforward in terms of preparation.

Re: Git, Graphs and Software Engineering

#26

Post by noway421 »

couchand wrote: post #10
sametmax wrote: post #2

Except most hard but interesting operations with Git are not very visible in histories. They are: - getting a clear status of you repo so you know where you are and what you do; - figure out which one of the various method of undo you need for this specific screw up; - find a practical way to compare this particular version of a snippet with another particular version of a snippet, and work on the result; - merge the…

To answer just one of your questions, many commands have a patch mode as -p. At this point I rarely just git add, it's always git add -p. A side benefit is that you get a chance to review your own code, make sure you cleaned everything up, and can't accidentally commit something. And you may be interested in the Gitless papers, they are a very interesting approach. I personally think I've got a good enough sense of G…

>-p

thank you!!

Re: Git, Graphs and Software Engineering

#27

Post by skrebbel »

fovc wrote: post #4

I think Tarsius already did this and called the result Magit. For bonus points he made it perfectly interoperable with git Edit: Kickstarter campaign going on with 23h left https://www.kickstarter.com/projects/1681258897/its-magit-th...

Not quite:

> Magit fully embraces Git. It does not limit itself to a subset of simple features.

(from the Kickstarter you linked to)

Re: Git, Graphs and Software Engineering

#28

Post by skrebbel »

I feel like most comments in this thread focus on the process mining, whereas IMO they are missing the core idea of this article:

> Build a tool that provides those, and only those, to users.

The author probably assumes that it is obvious that this means that the UI of such a tool (be it a CLI or a UI) can be simpler. So much simpler, that it in turn can be made much more powerful. So much more powerful, that maybe, just maybe, one day there will be a time where programmers won't have to spend serious effort on learning and doing source control anymore.

Re: Git, Graphs and Software Engineering

#29

Post by tarsius »

yeukhon wrote: post #23
fovc wrote: post #4

I think Tarsius already did this and called the result Magit. For bonus points he made it perfectly interoperable with git Edit: Kickstarter campaign going on with 23h left https://www.kickstarter.com/projects/1681258897/its-magit-th...

Personally... this looks confusing... perhaps just an Emacs thing, but I couldn't follow what was going on in the video. Or perhaps the yellow background really threw me off.

The video is indeed... not so great. I would go as far as to say that this might be the Kickstarter campaign with the crappiest video that ever succeeded.

But at some point I just had to launch instead of continuing to hope I would eventually get around to launching the perfect campaign. I did however make an effort to give non-Emacs a better glimpse into how Magit works using a few articles listed at [1]. You might also want to check out some of the screencasts that were created by users [2].

[1] https://emacsair.me/2017/09/01/campaign-articles/#start

[2] https://www.youtube.com/watch?v=rzQEIRRJ2T0 https://magit.vc/screencasts

Re: Git, Graphs and Software Engineering

#30

Post by tarsius »

Tenobrus wrote: post #12
fovc wrote: post #4

I think Tarsius already did this and called the result Magit. For bonus points he made it perfectly interoperable with git Edit: Kickstarter campaign going on with 23h left https://www.kickstarter.com/projects/1681258897/its-magit-th...

For clarity, Tarsius is not the original creator of Magit, that would be Marius Vollmer ( https://github.com/mvollmer ). Tarsius is "just" the current maintainer and most prolific contributor. I'd strongly recommend contributing to the kickstarter if you use Magit, however. I donated $100 and felt that was not near what it's actually been worth to me. Don't think that just because it's fully funded you shouldn't both…

Indeed I would not have created Magit from scratch. From the campaign description:

"I would like to thank [Marius] and the maintainers who came later, for I would not even have known that I needed something like Magit had they not laid the groundwork in the early days of Git."

Not trying to undersell my own work - elsewhere I also write:

"Despite all this, it would be wrong to assume that Magit started out with a predefined set of interface concepts and abstractions, and all that was left to be done was incrementally filling in the gaps."

Oh, and thanks for you contribution.

Post reply on HN