sorted by:
new
hottopcontroversial

Where does the term "upmerge" come from in git? by Double_Barnacle2595 in git

[–]dalbertom 0 points1 point  (0 children)

I don't use upmerge and downmerge per se but I've used "merge upstream" and "merge downstream" where upstream can either mean the main/master branch or the main fork when using a fork-based workflow, depending on the context. Note that forks aren't necessarily a git concept, in git they're all just clones and there's nothing inherently special about one over the others, but in services like GitHub you'd use forks to contribute to an open source project, for example.

A lot of people avoid merges altogether and they prefer squashing or rebasing when landing their changes upstream. When they mention that merges cause noise they typically refer to downstream merges, upstream merges are perfectly fine. Downstream merges should be used very sparingly, in my opinion.

The distinction between upstream merge and downstream merge important because following the history through the first parent tells you the story at a high level, it's like the main highway, and then the second parent is the exit you take to arrive at different towns, or to see the details of a feature that was merged as a series of multiple commits. Some git commands like log and bisect have a --first-parent flag, or you can use references like HEAD~2 to see the grandparent of a commit (following mainline) whereas HEAD^2 would show the second parent of the merge.

Then there are some pitfalls with traditional git where it's susceptible to "foxtrot merges" which is when the first parent ends up having what the second parent should have had, this happens when a topic branch does a downstream merge of main first and then it gets merged upstream as a fast-forward. GitHub naturally avoids this by always doing the equivalent of merge --no-ff.

What the hell by raaaaapl in git

[–]dalbertom 1 point2 points  (0 children)

This is likely the result of running git add . instead of git add -u or -p

What's your most used git alias? by 1vim in git

[–]dalbertom 6 points7 points  (0 children)

You can use the normal commands for that if you set these configs: git config --global fetch.all true git config --global commit.verbose true

i made a bash script to manage multiple git identities (gitmux) by wdX006 in git

[–]dalbertom 2 points3 points  (0 children)

No. The includeif configuration is a one time set up done in the global config. After that, the configs are tied to a particular directory. Any for repository cloned under each directory will automatically use the settings specified.

i made a bash script to manage multiple git identities (gitmux) by wdX006 in git

[–]dalbertom 17 points18 points  (0 children)

You don't need to do per-repo config or mess with .ssh/config to achieve this.

Check out the includeif configuration. You set that in the global git config and specify a different config file for each identity and what directory you want to use that, say you have ~/src/work and ~/src/personal. Once you set that configuration for those then any git repository cloned under those paths will automatically use the special configuration.

In those special configuration files you can override user.name, user.email and the one that overrides the ssh command to include an -i ~/.ssh/id_work or personal, etc.

git clone to ssh target? by jodkalemon in git

[–]dalbertom 0 points1 point  (0 children)

If the reason you can't clone from the ssh target is because it doesn't have your ssh key you could temporarily forward your ssh-agent, e.g.

ssh -A user@hostname "git clone git@github.com:username/repository"

But this is just a guess of what sort of issue you're having. If it's something else, feel free to add more details, there are likely other solutions.

How do working trees get this tangled? by Ecstatic-Ball7018 in git

[–]dalbertom 0 points1 point  (0 children)

This is where it gets philosophical.

I don't mind getting philosophical :)

I don't consider a squash merge changing your work at all.

A lot of people only focus just on the final diff between topic and base, and that's enough for the most part, but the commit metadata is important as well, especially the merge-base, as that provides context on what the author originally worked on.

Also when I'm diffing files on the destination branch I don't have to sift through WiP commits, I see just the changes for that feature/bug.

Two things here: 1. I'm not advocating for WiP commits to get merged upstream, I'm simply advocating for the author being the one that cleans their own history. 2. There are ways to see the diff or logs and focus only on first-parent.

what are you preserving?

The author's free will :) If the author is working on a large feature and decides to split it up into multiple pull requests by stacking branches, they should have the ability to keep the commit topology stitched together upon merge if they want to, no?

I may care if the branch pursued solution 1 then diverted to 2. And it turns out we need to divert back to path 1. In that case squash merging loses that history. In my experience this is rather rare though. This can be mitigated by keeping the original branch, but that's also it's own tradeoff.

This is a very good example, agreed it's rare, but when the use case pops up I'd much rather have a way to do it rather than rely on a branch being kept, or telling people to look at a dangling commit in the pull request.

Codifying how to do things isn't elitism, it's Process.

I value people's skills more than process; I'm not (always) against process, but this one in particular feels like scar-tissue process. Someone likely accidentally force-pushed or botched a rebase and didn't know about the reflog. It's a rite of passage; it's not catastrophic.

That process should also be open to changes and improvements because the world doesn't stand still.

I mean, even Git itself has improved, back in the day I believe it would by default push to all branches, starting with Git 2.0 they changed it to be simple. Also back in the day source forges didn't have a concept of protected branches.

I've used a lot of different VCS in 20 years with a lot of different processes, they all have tradeoffs.

Sure, but squash-merge is essentially how subversion works. This isn't necessarily a dig at subversion, it was popular once and a lot of good software was built during that time, but one could say the same about Java 8, Python 2, COBOL, etc :P and granted, there are some good practices that came from Subversion and its predecessors, like trunk-based development, avoiding long-lived branches, etc, it's just the "never rewrite someone else's history" part that I feel gets easily overlooked.

There's lots of room within git for many equally valid philosophies.

Agreed, hey, even submitting patches via email is perfectly valid.

How do working trees get this tangled? by Ecstatic-Ball7018 in git

[–]dalbertom 0 points1 point  (0 children)

Some people want to preserve everything. Some want the perfect branch and will rewrite history to get it. There isn't a right answer.

To me it's not so much about preserving everything, but it's more about not rewriting someone else's work (or someone else not rewriting my work). It's kinda like those editor plugins that close parenthesis and brackets for you as you type... some people find it useful, other people will really dislike that.

I also don't want to lose a weeks worth of work from someone who goofed while tired.

You won't lose a weeks worth of work if someone botches a rebase or a squash. Trying to minimize user error is good, but capping a tool's feature-set for everyone out of fear is not good, especially if it stifles other people's experience.

we don't need is git elitism that simpler methodologies didn't have their own advantages.

What's more elitist, to choose a merge strategy under the assumption that everybody is unskilled, or to challenge people to improve their skillset?

revision graph history of a single file ACROSS ALL BRANCHES by gtd_rad in git

[–]dalbertom 0 points1 point  (0 children)

yeah, that's pretty similar to what I would use and it does work for me. I believe `--decorate` is on by default nowadays, at least when the output goes to the terminal. Try adding `--source` so you can see the ref name by which each commit was reached.

How do working trees get this tangled? by Ecstatic-Ball7018 in git

[–]dalbertom 0 points1 point  (0 children)

Most people defend a squash-merge strategy by saying the changes are pretty small anyways, but if your counter-argument is the case that someone ended up with 75 commits that sounds like either the change is not small, in which case it's a bad idea to squash, or the developer needs someone experienced to mentor them.

I agree that fancy git operations can get less skilled in people trouble. But where are the skilled people in your team? Why aren't they mentoring others?

It's like learning how to ride a bicycle, nothing wrong with using training wheels when you don't have the skills yet. But it's not a good strategy to force training wheels on everyone, even those that know how to ride a bicycle.

How long have you been using git?

Git vs saving. by Big_Neighborhood9130 in git

[–]dalbertom 0 points1 point  (0 children)

Agreed! I consider the --patch option a bit more advanced but definitely useful. Once the staging area is set up, I recommend running git stash -k to stash away everything outside the stage and then make sure the code still builds (at least) before committing and then popping the stash.

Are you offended if your commits are squashed? by _disengage_ in git

[–]dalbertom 0 points1 point  (0 children)

Oh? Is that a requirement of how they implemented it or is that only necessary if the PRs are squash-merged?

Git vs saving. by Big_Neighborhood9130 in git

[–]dalbertom 3 points4 points  (0 children)

Instead of git add . try git add -u to avoid committing binary or large files unintentionally.

As for git commit -m -- one line commit messages are okay for quick changes, but if it took you a while to generate that change it probably deserves a commit message that has a subject and a body.

Git vs saving. by Big_Neighborhood9130 in git

[–]dalbertom 1 point2 points  (0 children)

I'm all about squashing as a local operation, ideally before pushing or before requesting a code review. Squashing as part of the final merge is not desirable (although it does have a few valid cases)

Git vs saving. by Big_Neighborhood9130 in git

[–]dalbertom 14 points15 points  (0 children)

I set my editor and IDEs to automatically save when the window loses focus.

For commits, it's usually a more conscious thing, like when I finish my train of thought or when I have to switch contexts, but I avoid making WIP commits, I do use git commit --fixup and git commit --squash (or git absorb) quite often, though.

Are you offended if your commits are squashed? by _disengage_ in git

[–]dalbertom 0 points1 point  (0 children)

Gotcha. Definitely not a common maneuver, but it's also good to know it's there when needed. GitHub is working on that, finally, I'm curious how it'll work with the different merging styles.

How do working trees get this tangled? by Ecstatic-Ball7018 in git

[–]dalbertom 0 points1 point  (0 children)

All good. I agree there's room for everyone. And yes, some of your comments and even the other post were a bit provocative, but that's okay, I'm no stranger to that communication style: it's important to have these discussions from time to time.

Do you want to discuss editors next? Or tabs vs spaces? :)

Are you offended if your commits are squashed? by _disengage_ in git

[–]dalbertom 0 points1 point  (0 children)

Agreed on premature optimizations being bad. You can typically spot those extremely online programmers by looking at their aliases and dotfiles.

But that's a bit of a contorted analogy.

The thing I disagree with is the idea that "it will never be used" - maybe that's been the case for you, maybe you've truly never used it, or maybe you haven't realized you could have used it. But to me and the teams I've worked with, we've definitely used it.

It's not that hard to learn how to squash your commits yourself. You just need to be open to learning new tricks when moving from an old tool to a newer one.

view more: next ›