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

11–20 of 40 posts

Re: Git, Graphs and Software Engineering

#11

Post by paulddraper »

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…

Specifically, for step 5:

    git reset .
    git clean -df
    git checkout -f wip
    git branch -D final

Re: Git, Graphs and Software Engineering

#12

Post by Tenobrus »

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 bother, there's good reason to keep contributing: https://www.reddit.com/r/emacs/comments/71viq3/the_magit_kic...

Re: Git, Graphs and Software Engineering

#13

Post by luckydude »

So Git is what Linus thinks is good. What I think is good, and this was Git's inspiration, is at http://bitkeeper.org

It's very different from Git. Git versions the tree, BK versions the tree and versions files. The difference is profound. In BK, you debug by looking at the file history and then zooming out to the commit history. Git can't do that. Or it fakes it and gets it wrong. Same with merges, renames, creates, deletes, Git gets all that wrong.

I know it won and there is no hope that things can get better but if you want to see what better looks like, check out BK.

Re: Git, Graphs and Software Engineering

#15

Post by corndoge »

luckydude wrote: post #13

So Git is what Linus thinks is good. What I think is good, and this was Git's inspiration, is at http://bitkeeper.org It's very different from Git. Git versions the tree, BK versions the tree and versions files. The difference is profound. In BK, you debug by looking at the file history and then zooming out to the commit history. Git can't do that. Or it fakes it and gets it wrong. Same with merges, renames, creates,…

you said git is wrong but don't explain why bk is right

Re: Git, Graphs and Software Engineering

#16

Post by kazinator »

luckydude wrote: post #13

So Git is what Linus thinks is good. What I think is good, and this was Git's inspiration, is at http://bitkeeper.org It's very different from Git. Git versions the tree, BK versions the tree and versions files. The difference is profound. In BK, you debug by looking at the file history and then zooming out to the commit history. Git can't do that. Or it fakes it and gets it wrong. Same with merges, renames, creates,…

git repos with non-linear history quickly turn to shit.

The only way to use git right is never to allow a commit to have two parents.

Never merge anything: always cherry pick or rebase.

Re: Git, Graphs and Software Engineering

#17

Post by hyperpape »

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…

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).

Re: Git, Graphs and Software Engineering

#18

Post by mappu »

luckydude wrote: post #13

So Git is what Linus thinks is good. What I think is good, and this was Git's inspiration, is at http://bitkeeper.org It's very different from Git. Git versions the tree, BK versions the tree and versions files. The difference is profound. In BK, you debug by looking at the file history and then zooming out to the commit history. Git can't do that. Or it fakes it and gets it wrong. Same with merges, renames, creates,…

Hg user here. One interesting hg/git difference is that Hg allows file history across renames by explicitly tracking the rename operation, whereas git just does a fuzzy content match.

Re: Git, Graphs and Software Engineering

#19

Post by mappu »

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 have tried every single git UI under the sun, command line and not, and they all fall short outside of the basic use cases

I haven't found any git UI that matches TortoiseHg, for new and experienced users alike - my best picks were "Git Extensions" (Windows-only) and gitk + git-gui elsewhere.

I had high hopes for QGit but it seems to be missing a lot of features.

Re: Git, Graphs and Software Engineering

#20

Post by jancsika »

oddlyaromatic wrote: post #9
jancsika wrote: post #8

Earlier quoted context omitted.

> - 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…

I really like this. I get overwhelmed by the options and want to be prudent yet have freedom to screw up.

The other benefit is that this flow encourages you to push the WIP branch to remote as early as possible. Otherwise I find I'll work too long exclusively on the local repo getting things "just right", and creating an unnecessary risk of data loss.
Post reply on HN