21–30 of 148 posts
Hrm… can you really recover branches and tags once you delete them? I was under the impression commits were retained but removing labels (tags, branches, remotes) was unrecoverable and immediate.
If I could just convince colleagues to `pull.rebase`, so CI isn't constantly building 'Merge branch master' on the master branch , I'd be happy enough.
"git pull" in the kernel workflow is for integrating downstream changes into your own upstream repository. Meanwhile, "git pull" in the everyman workflow is for synchronizing your local changes with upstream changes (you know, re-basing your patches on upstream or something).
Even the merge commits left behind by default git pull reveal this. "Merge branch master of ssh://yourorg-git/upstream" - completely backwards for what you are doing - you're merging the upstream into the downstream? What, your local repo is the boss now? Doesn't make any sense.
Hrm… can you really recover branches and tags once you delete them? I was under the impression commits were retained but removing labels (tags, branches, remotes) was unrecoverable and immediate.
You can't recover where your references were but all the objects (anything with a SHA1) are still there.
I love this quote from Part I: "Git has an elegant and powerful underlying model based on a few simple concepts: 1. Commits are immutable snapshots of the repository 2. Branches are named sequences of commits 3. Every object has a unique ID, derived from its content Built atop this elegant system is a flaming trash pile. "
When I started out using git I was working with the same assumptions, but I was perpetually confused. Git became a lot easier to use once that misunderstanding cleared up.
Maybe it's just like that for me but I think we might be doing newcomers to git a disservice by explaining the basics of git in this simplified manner.
If I could just convince colleagues to `pull.rebase`, so CI isn't constantly building 'Merge branch master' on the master branch , I'd be happy enough.
If I could just convince colleagues to `pull.rebase`, so CI isn't constantly building 'Merge branch master' on the master branch , I'd be happy enough.
If I could just convince colleagues to `pull.rebase`, so CI isn't constantly building 'Merge branch master' on the master branch , I'd be happy enough.
Maybe it would have been good if the git defaults were changed from the defaults used for the kernel development workflow to the git workflow ~everyone else is using, even though git was created for the kernel people by the kernel people - most users are not kernel people. "git pull" in the kernel workflow is for integrating downstream changes into your own upstream repository. Meanwhile, "git pull" in the everyman w…
Earlier quoted context omitted.
Maybe it would have been good if the git defaults were changed from the defaults used for the kernel development workflow to the git workflow ~everyone else is using, even though git was created for the kernel people by the kernel people - most users are not kernel people. "git pull" in the kernel workflow is for integrating downstream changes into your own upstream repository. Meanwhile, "git pull" in the everyman w…
The idea of "merging into" has no meaning with git. You're merging two things into one. But saying that there are a master thing and a slave thing has no meanings.
[1] i.e. the branch you did the merge from
If that stuff is committed.
Maybe I'm stating the obvious but conversations seem to revolve so much around finding stuff and merging stuff that my favorite use of git isn't talked about as much -- throwing stuff away. A commit is your save point - once made, you can basically code risk-free, knowing you can always go back to that save point. Try new things, thrash your code, don't stress even if you break everything - because you can always just revert back to that last commit.
So I'd say that it is really hard to lose the stuff you explicitly declared you wanted to keep. And easy to lose the rest.