|
I just spent an hour and a half using hg-git and git's post-receive hook to let me push to hg-git's internal git repository and automatically have that do hg-git's pull and then hg-push the changes to our central mercurial repository! Now I can pretend that mercurial does not even exist and just use git! At least until someone else pushes something into the repository and I get conflicts. 
|
#
¿
Jan 26, 2010 04:53
|
|
|
|
| # ¿ May 14, 2024 16:19 |
|
|
It is a hobby thing that I was only going to contribute to sporadically and I kind of wanted to avoid spending half of the time trying to figure out how hg is different from git. In retrospect, that was pretty silly.
|
|
#
¿
Jan 26, 2010 17:51
|
|
|
Triple Tech posted:git = good for decentralized; good for merging What makes git worse for centralized than svn?
|
|
#
¿
Mar 11, 2010 17:46
|
|
|
What does branching/merging look like in hg compared to git? I am tracking a hg repository in git using hg-git and slightly confused!
|
|
#
¿
Mar 11, 2010 19:54
|
|
|
Either way you are going to end up with a merge commit that removes all the old files and adds all the new files, why not just make it a separate project 
Vanadium fucked around with this message at 14:50 on May 27, 2010 |
|
#
¿
May 27, 2010 14:46
|
|
|
The closest I can think of is to maintain a separate copy of the repository, use rebase --interactive to squash all but the commits you want to keep, and synch that with your complete repository manually.
|
|
#
¿
Jun 1, 2010 03:15
|
|
|
git rebase --interactive commit-before-your-branch and read the instructions that show This is destructive since it rewrites history so I guess you may want to duplicate your branch before trying. Vanadium fucked around with this message at 17:29 on Jun 29, 2010 |
|
#
¿
Jun 29, 2010 17:27
|
|
|
Ah, I have not used the reflog apart from digging through it manually. I did not realise it counted as anything but an implementation detail. 
|
|
#
¿
Jun 29, 2010 20:52
|
|
|
I only ran into the reflog because git would not gc some multi-gb objects that were checked in at one point but since dropped through history rewriting, welp.
|
|
#
¿
Jun 29, 2010 21:06
|
|
|
Janin posted:I use Bazaar for pretty much everything; it's nice because it's in Python, so there's a real API instead of just bashing everything together with thousands of lines of shell scripts. This advantage also applies to Mercurial. There's Dulwich, a "a pure-Python implementation of the Git file formats and protocols", but I have no idea whether it is any good.
|
|
#
¿
Aug 19, 2011 14:21
|
|
|
Why the hell does git push someremote somebranch cause origin/somebranch to get updated when origin isn't someremote?
|
|
#
¿
Jul 9, 2012 18:57
|
|
|
Deus Rex posted:Is somebranch tracking origin/somebranch? Yeah
|
|
#
¿
Jul 12, 2012 20:53
|
|
|
Can you use that sort of thing to change the initial commit of a git repos? I've not gotten that to work in the past but I wasn't using github's instructions either.
|
|
#
¿
Oct 10, 2012 17:00
|
|
|
Is there a cool way in git to keep around build artifacts on, like, a per-branch basis so that I can switch between branches without having to rebuild everything every time? Do I just keep around multiple working copies of the same repository?
|
|
#
¿
May 23, 2013 07:33
|
|
|
My problem is that switching branches touches files so make wants to rebuild everything. So if I work on one branch, then check out another and build that even in another build dir, and switch back to the first branch, I "need" to rebuild everything that's different in the second branch. That link seems to address that problem, cheers.
|
|
#
¿
May 23, 2013 11:18
|
|
|
Each commit knows it parent(s). Given a commit you can always follow the ancestry chain upwards.
|
|
#
¿
Nov 14, 2013 17:36
|
|
|
Let's post a kickstarter to build a decent commandline interface to git on top of libgit2 or w/e 
|
|
#
¿
Feb 21, 2014 20:27
|
|
|
Deus Rex posted:Most of the ways git gives you to shoot yourself in the foot you can recover completely from, one exception being like reset --hard. The reflog is your friend. reset --hard is hardly worse than checkout . though, which sounds a lot more innocent.
|
|
#
¿
Jun 26, 2014 12:50
|
|
|
HFX posted:I'm not sure what you are talking about with checkout. If you have uncommited changes it won't do it without a warning about overwriting files. If you have files you have not yet added, it will warn you about those too. I mean git checkout <path> where <path> is the current directory or w/e, which just throws away all unadded changes in <path> by overwriting them with the state of the index with no warning. That's also really the destructive thing that git reset --hard does, the bit where it makes the current branch point somewhere else is comparatively easy to undo.
|
|
#
¿
Jul 2, 2014 12:26
|
|
|
ToxicFrog posted:Ha ha ha ha ha ha ha ha ha ha Yeah I'm pretty sure it's not a bug either. The way I've come to rationalize it is that the "core functionality" of git checkout is to copy state in the direction of the committed history towards the working copy, and while setting HEAD to another branch might be where it got its name from, that's really just an incidental detail...
|
|
#
¿
Jul 2, 2014 17:15
|
|
|
KoRMaK posted:I'm rebasing a branch, and I want a kind of specific behavior which seems available but I'm not completely sure. The idea seems to be that you just let the rebase process commit everything in the revision you want to edit, and then you adjust it with git commit --amend. With your git reset --soft, you'll basically lose out on the commit message when you finally decide to commit and otherwise the workflow would be the same as if you were amending, afaict?
|
|
#
¿
Aug 12, 2015 21:16
|
|
|
You could probably convert your hg work into a fresh git history, use git format-patch to turn the new commits that don't have equivalents on github into series of patches, then switch to the github history and use git am to apply the patches as commits again. Afterwards you can probably use hg-git all over again to convert the git history into a hg repos so you can keep working with hg, though that'd break your bitbucket history. I don't know enough about hg to figure out how that mapfile stuff would work (For (1) you could also force-push your new git history to your existing github repostiory, that way you won't lose the stars or followers or whatever, but everybody will now have the problem you're having right now so it's a bad idea.)
|
|
#
¿
Aug 25, 2015 19:49
|
|
|
How much effort would it be to set up a no-op ssh tunnel when you're local? 
|
|
#
¿
Sep 4, 2015 20:53
|
|
|
You can set up a clean branch from origin's master, and use git cherry-pick to grab a single commit (or a range of commits) from the branch you've worked on. Git will duplicate that commit as if the same changes had been made on top of the clean branch, with the same commit message and all.
|
|
#
¿
Sep 7, 2015 20:34
|
|
|
I've been tracking a generated file in git for a while and noticed that the contents are basically unordered, and it gets generated in a seemingly random order every time, making diffs pretty bad to look at. I've looked at clean/smudge filters to just sort it arbitrarily but consistently on checkin, but I can't really figure out how to not make it freak out about unsaved changes every time I look at a commit that predates me adding those filters. Is there a decent way to deal with that short of running a git filter-branch to rewrite history so I will always have been using that filter?
|
|
#
¿
Oct 17, 2015 14:08
|
|
|
How do y'all feel about history-rewriting on published feature branches? I feel as long as it's obviously my personal feature branch it's cool to do whatever to the history even though it's technically public, but I guess it gets iffy when someone else shows up and wants to work on the same thing.
|
|
#
¿
Sep 2, 2016 00:39
|
|
|
git reset moves the branch pointer to the given commit, so the new contents of the branch is all the commits reachable from that commit, dates don't really play into it. I'm not sure what you mean by topology vs ancestry, I thought ancestry defines the topology. But if you're already published the current state of the branch, it's really bad form to try to rewrite history. You'd want to use git revert to undo specific commits/merges by introducing more commits. I think that might become super messy. I'm not sure if git blame would be helpful to find out when certain changes appeared in your branch, I assume it will point to the original commits and not the merge commits, but I don't know from the top of my head. It's not always obvious from glancing at git log what commits are reachable from the branch head, showing the history so linearly is kinda misleading when there's merges involved. I dunno what fisheye is exactly, have you used tools that visualize the history as a graph, so you can just trace all the lines and see where they go?
|
|
#
¿
Jan 21, 2017 17:10
|
|
|
Can't you do all the splitting while maintaining history fairly easily in git with, like, the subtree stuff or just some filter-branch work and some patience? I mean that'd be my preference because I don't know any svn.
|
|
#
¿
Mar 22, 2017 12:35
|
|
|
Has anyone played around with pijul. I keep meaning to but then spending my free time on videogames or organizing my email instead.
Vanadium fucked around with this message at 08:02 on Mar 27, 2017 |
|
#
¿
Mar 27, 2017 07:23
|
|
|
As many branches as possible imo.
|
|
#
¿
May 11, 2017 21:13
|
|
|
I tend to just replace my fork's master with an orphan commit that just says "hi I'm a repo for feature branches" in the readme, but I'm weird like that.
|
|
#
¿
Jul 17, 2017 11:04
|
|
|
Ralith posted:The github UI is pretty good at communicating what's a fork and what's the upstream repo without any effort on your part. To the point where it's kind of obnoxious to manage the (rare) case where that relationship needs to change. I guess I just don't enjoy having this inert, frozen-in-time branch that everybody lands on by default when people click my fork. It can only confuse people.
|
|
#
¿
Jul 19, 2017 11:37
|
|
|
wolffenstein posted:You can change which branch is displayed by default in your repo's GitHub settings. But there isn't any branch it should display! It's just a bunch of random WIP branches or whatever. Why should one be distinguished from the others?
|
|
#
¿
Jul 19, 2017 21:04
|
|
|
I always pull and expect it to do a ff-merge, or reset --hard origin/foo.
|
|
#
¿
Aug 20, 2017 11:05
|
|
|
The notion that it's ok for my history to look like poo poo because it's some other nerd's job to untangle it later is honestly kinda mystifying to me
|
|
#
¿
Sep 20, 2017 13:24
|
|
|
keybase also has a private git repo feature, probably so people stop putting git repos directly on their encrypted distributed file system. I'm not sure how awkward it gets if you want to share the repo with someone eventually, but at least it's gonna be hella encrypted.
|
|
#
¿
Aug 14, 2018 15:06
|
|
|
Put the repo somewhere else and have the big dir symlink into it for the few files you care about.
|
|
#
¿
Feb 20, 2019 00:30
|
|
|
Aren't both of these the same operation / will run into the same merge conflicts? Maybe you can mitigate the pain with git rerere but in principle you're starting with A and sequentially applying a subset of B either way, no?
|
|
#
¿
Apr 25, 2023 14:46
|
|
|
|
| # ¿ May 14, 2024 16:19 |
|
|
Tequila Bob posted:Learning Git isn't the easiest thing in the world, but there are two reasons you should: I bet that's what they told people about why to learn svn.
|
|
#
¿
Oct 11, 2023 22:32
|
|