Woah, it didn't already? Magit has made that easy forever and I just assumed it was part of git at this point.

Hah, I was thinking the same thing and jumped to comments to see if someone else mentioned it. I actually use this quite a bit in Magit.

Magit is genuinely amazing.

Thanks @tarsius!

I usually try to leave the Magit praising to others in these threads but in this case I would have found it hard to resist. Glad others have already taken care of it. ;P

You've made a thing that has many loyal users, myself included. :)

Will this change make your work on Magit easier?

If there was something you could add/remove to/from Git to make your life easier, what would it be?

It probably doesn't make much of a difference because Magit's stashing commands offer more flexibility that even after this addition is still missing from `git stash`. Stash creation is actually one of the very few areas where Magit doesn't use the respective Git procelain commands at all (as opposed to using them and then doing additional things using other pluming and/or porcelain commands as is the case in many other areas).

Also I have to continue supporting older Git releases anyway; people like to use the latest Magit version without considering doing the same for Git, for some reason.

Change the license to GPLv2 OR later.

+1. Magit is definitely the best Git client out there. It makes even non-standard functions transparent to the user.

I really want those temporary commits to end up part of the finished git history, but be hidden from most views... for example, they could be called "sub commits", and tools could not show them by default unless given some extra flag. Then there could be sub-sub commits, etc to show more and more minor edits, potentially down to individual keystrokes.

Throwing away the construction history of something just seems wrong in git-land. The git format already allows this - it's just the tooling and culture that needs to be adapted for it to happen.

Maybe the culture of easy to understand commits exists for a reason?

Imagine someone sending in a patch for the Linux kernel, or for git itself, only it isn't only the patch but a bunch of temporary patches that in the end forms something usable. (But don't worry because a git feature will make the log skip over it!) Would you really want to review that? Would you really want it stored in the repository for all eternity?

Crafting commits that are easy to understand and gives enough context to understand the change is the only way a large software repository can survive without collapsing under its own historical weight.

Thanks, gonna steal using the Linux kernel development as an example regarding this matter. Probably also any huge-scale repo like Google or Windows would work, but Linux is awesome because open source.

I'm honestly rather confused on the whole idea of valuing the journey instead of the end result. Aren't commit messages literally the built-in way to write about your journey to your heart's content? And failing that, you probably (should) have a ticket system or the like to preserve even more context in the form of third party comments etc.

I usually compare git history to a book: it's not valuable for the end user to see all the tiny edits and errors the author made before the final version, and in the end the important thing is that it tells a good story that the end user can easily follow.

Like it's said, the source code is for us humans to read. The computers would do just as fine without the story its trying to tell.

Removing or glossing over can always be done later.

Adding back the thought process that the commits can reveal can often be hard later, even for the original author.

Removing can't always be done later, because that requires rewriting the repository's history.

Logical commits serve a real purpose: they make change review easier and can help bisect bugs later.

That's orders of magnitude more useful than someone else's development thought process, which may or may not even make sense to anybody else.

If thought process is important, it should be captured in a structured way like a thoughtful commit message or README addition. Not some cobbled together mess of whatever commits someone made haphazardly.

First: are we talking past each others? You seem reasonable but some of the things doesn't make sense to me which often indicates a misunderstanding on one of the sides :-)

If not, here are some clarifications. (Maybe they'll help even if we are talking past each other.)

> Removing can't always be done later, because that requires rewriting the repository's history.

I knew this could come up which is why I included glossed over.

> Logical commits serve a real purpose: they make change review easier and can help bisect bugs later.

Nothing I wrote was meant to conflict with that. Quite on the contrary I specifically want more points to bisect against (yes, I'm one of those who actually uses bisect).

> If thought process is important, it should be captured in a structured way like a thoughtful commit message or README addition. Not some cobbled together mess of whatever commits someone made haphazardly.

Have you tried getting anything reasonable about the thought process behind a feature into a README, and then tried to get it to stick there?

On the other hand a bunchbof commits along the lines of:

- rough first sketch

- introduce tests.

Also includes modifications to xyz to simplify testing.

- performance optimizations

- more tests

- Introduce test for foo and fix it in bar and baz

This has a negative impact on performance but is hard to avoid.

etc

Could you please elaborate on the value you find in commits from other people that are along the lines of "more tests" or "first sketch", as opposed to crafting a coherent single commit with a thoughtful commit message?

I'm honestly asking in good faith, as the commits you gave as an example are literal anathema to me, and I'd like to understand what value anyone can see in them.

The one I value is the "performance optimizations" and the last one.

Problem is if we let squash zealots have their way they are gone together with the rest.

Storage is cheap.

You'll never ever be bothered by those commits unless you are bisecting and at that point you are probably thankful of you can find a commit message along the lines of:

- performance optimizations

- workaround for weird problem foo problem in prod

as they will tell you a lot about how to approach it.

Edit:

Just having tests and modification because of tests added in their own commit and with a comment ("Also includes modifications to xyz to simplify testing." above) is useful.

I do look into commits on a weekly basis or more to figure out why stuff was moved / replaced.

Just yesterday I stopped a PR because a constant was changed in an unrelated commit as part of the larger PR.

Because commits are granular it was really easy to see that it wasn't intended.

> I specifically want more points to bisect against (yes, I'm one of those who actually uses bisect).

Wouldn’t that make bisecting more difficult?

If your history is full of checkpoint commits, wouldn’t bisect send you to broken commits (that you’d have to `--skip`) more often?

Why would you want to deal with those extra steps?

Just make sure every step make sense. One or even two or three extra bisect steps is nothing in my kind of projects as long as you get a very specific change.

I guess on AAA game engines where compiles take half an hour it is more of a problem but in my case it takes 30 - 120 seconds depending on project.

(I do have uncompilable WIP steps, and those I am kind of ashamed for but those are so few and so far between that it doesn't matter.)

This sort of happens naturally with a branch-and-merge workflow. The merge commits are what matter. With bors the merge commits get tested before merge and get their commit messages populated from the PR description.

What's missing is many git tools don't let you easily filter out non-merge commits.

Given git's support for merge trees, and arbitrary workflows, this already exists, it's just hard to access. With git, you can create a commit history that looks like this:

    A
    |\
    | B
    |/
    C

and git log --first-parent will show A and C, and hide B, even though B's code is contained in A. We used this all the time at Ksplice, where we had some custom tooling that made it easy create those triangles and our build system would use the commit message on A while ignoring B in order to build updates.

What do you have in mind? Always hiding second parents of second parents? Or a special marker in G's commit message?

I feel the same, except I'd want only me (as the author/committer) to be able to see my sub-commits :D

This feeling goes away the senior you get.

What is the point of keeping construction history? How far do you go? Install a keylogger on each developer's machine?

I'd love to be able to stash individual bits of a diff (from magit) to do something like bisecting on the current changes.

Something like how the current `add -p` allows you to select or reject any given chunk.

Doesn't git stash save -p accomplish that?

The way to get a correct answer on the internet:

  1) Post the wrong answer.
  2) Get corrected.
  3) Profit

Cunningham's Law! "the best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer."

> But what if you only want to store part of your changes in the stash? You could use git stash -p and interactively select hunks to stash or keep.

It's even right in the article. (Then goes on to describe how this change means you can stash those chunks easily if you've already selectively staged them.)

Is this any different than soft reset then git stash

Presumably it doesn't include unstaged changes in the stash.

Yes, --staged doesn't include unstaged changes.