Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You already have a Git server

maurycyz.com

Post reply on HN
Print view View original

431–440 of 454 posts

Re: You already have a Git server

#431

Post by derefr »

noirscape wrote: post #382
scuff3d wrote: post #285

Earlier quoted context omitted.

I'm assuming a "patch" is a group of commits. So would a "patch series" be similar to GitLabs notion of dependent MRs?

There's basically 2 major schools of thought for submitting patches under git: * Pile of commits - each individual commit doesn't matter as much as they all work combined. As a general rule, the only requirement for a valid patch is that the final version does what you say it does. Either the final result is squashed together entirely and then merged onto "master" (or whatever branch you've set up to be the "stable"…

> It's totally okay to change the contents of a patch series, because until it's merged, the history of the patch series is irrelevant as far as git is concerned.

Under the original paradigm, the email list itself — and a (pretty much expected/required) public archive of such, e.g. https://lore.kernel.org for LKML — serves the same history-preserving function for the patch series themselves (and all the other emails that go back and forth discussing them!) that the upstream git repo does for the final patches-turned-commits. The commits that make it into the repo reference URLs of threads on the public mailing-list archive, and vice-versa.

Fun fact: in the modern era where ~nobody uses CLI email clients any more, a tool called b4 (https://b4.docs.kernel.org/) is used to facilitate the parts of the git workflow that interact with the mailing list. The subcommand that pulls patches out of the list (`b4 mbox`) actually relies on the public web archive of the mailing list, rather than relying on you to have an email account with a subscription to the mailing list yourself (let alone a locally-synced mail database for such an account.)

Re: You already have a Git server

#433

Post by xk3 »

brendyn wrote: post #417

So my friend and I were trying to learn some coding together. We had our laptops on the same wifi and I wanted us to use git without depending on GitHub, but I was completely stumped as to how to actually connect us together. I don't want us to setup SSH servers on each other's laptops, giving each other full access to our computers, and sending patches to each other across the living room seems overkill when we're j…

I think if you just setup SSH a certain way you can then use git or sftp for access:

        Match User gituser
            ChrootDirectory /srv/git_chroot
            ForceCommand internal-sftp
            AllowTcpForwarding no
            X11Forwarding no
            PermitTTY no
But tbh sending patches is fun and easy! After you force yourself to do it a few times you might even prefer it to push/pull

Re: You already have a Git server

#434

Post by djoanwnn »

tom_ wrote: post #290
thyristan wrote: post #2

Maybe I'm too old, but are there people that really didn't know that any ssh access is sufficient for using git?

Yep, me. I noticed that you sometimes use ssh:// URLs for GitHub, but I figured it was for authentication purposes only, and that once that step was over, some other thing came into play.

It usually is. Normally you don't put a full shell behind ssh if you only expose git, but of cause you can

Re: You already have a Git server

#435

Post by catmanjan »

BatteryMountain wrote: post #425
catmanjan wrote: post #372

Earlier quoted context omitted.

Why is that disconcerting? There's simply too much software to be familiar with obscure features like this

Because the same kind of guys have one global ssh key they use for all server & all environments... they don't realise they can (and should) have multiple keys on one machine / one user. Different keys for different purposes. Same issues with git: they don't realise they can have multiple configs, multiple remotes, etc. Never mind knowing how to sign commits......... They claim to be linux boffins but cannot initiali…

Most of those things are ops related, not software development

Re: You already have a Git server

#436

Post by cls59 »

johnisgood wrote: post #257
general1465 wrote: post #212

Earlier quoted context omitted.

> Managing code is one of the cornerstones of software engineering. It would be like refusing to learn how to use a screwdriver because someone really just wants to hammer things together. Ok, then make the commands make sense. For example 90%+ people has no idea what rebase does, yet it is a useful command. People does not want to learn with git outside of what works, because they can't experiment. The moment they w…

You can definitely experiment. Make a copy of the directory and experiment on that copy without pushing. I have done it a million times.

Also, "git reflog" lists out all commit SHAs in chronological order. Trying to figure out how to rebase, but got lost and everything seems broken? You're just one "git reset" away from the better place you were in and "reflog" has the list.

Re: You already have a Git server

#437

Post by Sohcahtoa82 »

kragen wrote: post #389
hshdhdhehd wrote: post #353

Earlier quoted context omitted.

Isn't it asking someone to pull your branch (if forked) then merge it into to master

Git pull is git fetch plus git merge.

I've run into so many people that think "git pull" doesn't do anything unless you run "git fetch" first.

In my 10+ year career, I'm not sure I've ever run "git fetch" manually. I've never had a time where I wanted to fetch upstream changes, but not merge (or rebase) them into my branch.

Re: You already have a Git server

#438

Post by mckn1ght »

svieira wrote: post #404
mckn1ght wrote: post #223

Earlier quoted context omitted.

Whenever I fork a repo I rename origin to “fork” and then add the parent repo as a remote named “upstream” so i can pull from that, rebase any of my own changes in to, and push to fork as needed. Multiple remotes is also how you can combine multiple repos into one monorepo by just fetching and pulling from each one, maybe into different subdirectories to avoid path collisions.

This sounds like submodules, but I'm guessing it's completely orthogonal ... multiple distinct remotes for the same _repository_, all of them checked out to different sub-paths; does that result in all the remotes winding up with all the commits for all the shared repositories when you push, or can you "subset" the changes as well?

Yeah, it's different, I was thinking about a time I needed to combine to separate repos into one. To do that, you clone one of them, then add a remote to the other one, fetch that, and `pull --rebase` or similar, and you'll replay all of the first's commits on top of the second's. I can't remember what I was thinking about the subdirectories, I guess they'd already have to be organized that way in the various repos to avoid conflicts or smushing separate sources together.

Re: You already have a Git server

#439

Post by kragen »

webstrand wrote: post #413
kragen wrote: post #392

Earlier quoted context omitted.

Notes aren't refs.

Yes they are, they get put in /refs/notes? git fetch origin refs/notes/*:refs/notes/* is the command you have to run to actually clone remote refs if you're making a working-copy clone?

You're right. Thank you for the correction.

Re: You already have a Git server

#440

Post by imbnwa »

__MatrixMan__ wrote: post #111
thyristan wrote: post #2

Maybe I'm too old, but are there people that really didn't know that any ssh access is sufficient for using git?

I've been using git since 2007, this only dawned on me last year. Git is especially prone to the sort of confusion where all the experts you know use it in slightly different ways so the culture is to just wing it until you're your own unique kind of wizard who can't tie his shoes because he favors sandals anyhow.

This is also vim
Post reply on HN