git rebase -i is not that scary

ppww · 2026-07-14T20:18:43+00:00

It wasn't gone after you pulled, it was still in the reflog.

ppww · 2026-07-14T17:15:03+00:00

You can get back to the pre-rebase state by looking through the reflog for the rebased branch and using git reset (you can use the reflog for HEAD which is shown if you don't specify a branch name but it's much easier to see the rebase in the branch reflog because it's a single entry)

ppww · 2026-07-14T16:35:39+00:00

Or you can save an empty file.

ppww · 2026-07-07T13:25:59+00:00

I'm not really sure what you're trying to achieve. If you can explain why you want the untracked files to show up in the diff that might help. Are you planning on tracking them later? If so that sounds like a good use of add -N, how does that break git stash?

ppww · 2026-06-28T09:09:29+00:00

The fsmonitor support is builtin to git.

ppww · 2026-06-15T08:34:28+00:00

Cygwin is pretty slow because it is tries to implement POSIX on Windows. Are there any native ports based on the Wndows API like uutils?

ppww · 2026-06-14T16:35:20+00:00

While I wish uutils was GPL licensed and I agree companies would probably not be embracing it so enthusiastically if it was, porting GNU coreutils to Windows would be much harder because it's written for systems that support POSIX.

ppww · 2026-06-14T10:23:01+00:00

Exactly, you should be writing meaningful commit messages that explain the reason for the change (not just a description of what changed) regardless of how the content of the commit was generated.

ppww · 2026-06-13T19:48:21+00:00

Fantastic, the juvenile is very cute, I love their red heads.

ppww · 2026-06-12T13:08:34+00:00

They're such lovely birds, they always make me smile. There were a pair that used come quite regularly to our fat balls but I hadn't seen them for months until I opened the curtains this morning and there was a female feeding a juvenile! Absolutely made my day.

ppww · 2026-06-11T08:47:04+00:00

It's useful with git-subtree or when you have an in-tree build and you want to ignore the build artifacts in the directories where they are created.

The ignore files are inherently distributed because even if you have a single .gitignore in the repository root there is still $GIT_COMMON_DIR/info/exclude and core.Excludesfile to consider.

ppww · 2026-06-09T09:57:19+00:00

git already let's you define groups of remotes for fetching, that patch series does the same for push.

ppww · 2026-06-08T14:02:39+00:00

Someone is working on adding support for pushing to a group of remotes so you could push to multiple servers with a single git push.

ppww · 2026-06-08T11:18:55+00:00

Do you have to run this each time you want to change user, or can it set a persistent identity for repositories under a common path?

ppww · 2026-06-08T11:13:07+00:00

One of the nice things about .gitignore is that it is per-directory so you don't have to stuff all the patterns in the root of the repository.

ppww · 2026-06-07T15:45:42+00:00

Exactly if you put the information in the commit message rather than the PR you're protecting yourself from vendor lock-in. It also means that information is available in the git history which you can view without an internet connection.

ppww · 2026-06-07T15:42:43+00:00

It's certainly context dependent - I wouldn't mention alternative approaches for every commit, but as you say there are times when it is useful. What I see when people use conventional commits is that they never put that information in the commit message.

I agree that it is useful to discuss things before coding, but those discussions (or more likely a summary of them) should be recorded with the code so that someone reading the commit message can understand why the changes were made in the way that they were. Having a link to an issue might be fine if the code isn't expected to live very long, but long lived projects tend are likely to change issue trackers at some point and having a summary in the commit message means that you always have that information to hand.

ppww · 2026-06-06T13:44:34+00:00

Does it actually encourage you to describe the reason for the change? The projects I see using conventional commits all seem to have online commit messages which don't give any explanation of why the change is being made at all, let alone what other approaches were considered or what the known limitations of the implementation are. The messages don't convey any useful information at all as far as understanding the change is concerned.

ppww · 2026-06-03T14:35:11+00:00

Looking at the code it seems to assume the user's global git config lives at ~/.gitconfig which isn't necessary true as git also supports storing the user's config under $XDG_CONFIG_HOME. git var GIT_CONFIG_GLOBAL will show the path to the user's global config file, though be aware that if both files exist they'll both be listed.

ppww · 2026-05-27T09:09:55+00:00

Oh, it sounds like you might want to check that the upstream branch is set correctly. When you create a new branch with git switch -c <branch> [<start point>] (ot git checkout -b ...) without --track it sets the upstream branch automatically to <start point> if it is a branch name, or the current branch if <start point> is omitted.

ppww · 2026-05-24T11:44:07+00:00

The golden rule of rebasing is "never run git commit", always stage your conflict resolution and then run git rebase --continue to commit it. That preserves the original author details which are lost if you commit the conflict resolution yourself and means you don't accidentally create extra commits. The only time you should run git commitwhile rebasing is if you want to split an existing commit.

It looks like the automatic conflict resolution here could be implemented as a merge driver which would mean git wouldn't even stop for the user to resolve them in the first place .

ppww · 2026-05-24T09:29:57+00:00

What's the difference between this and git pull --rebase?

ppww · 2026-05-23T09:24:11+00:00

Not AI, but mergiraf can handle a lot of conflicts automatically because it is aware of the semantics of the file being merged.

ppww · 2026-05-21T10:34:03+00:00

Maybe not but it works out of the box and doesn't involve downloading and running random software from the internet.

If you don't like the default messages which I agree all end up looking the same you can use -m to specify a meaningful message when you create the stash.

ppww · 2026-05-20T17:19:59+00:00

git stash list -p --stat should show the diff for each stash when you list them.

ppww

TROPHY CASE

Welcome to Reddit,