|
tef posted:I thought about doing this for a wiki. Version control is no small amount of effort, and having a git backend (or any dcvs) does have a lot of advantages. Ikiwiki is kinda cool, yeah.
|
#
¿
Apr 17, 2009 20:21
|
|
|
|
| # ¿ May 5, 2024 01:45 |
|
|
Otto Skorzeny posted:Is there a simple way in git to have standing differences between two branches? Eg. if I want to have a release branch with a bunch of dummy config files, and a regular working branch with fleshed-out versions of those same config files, and be able to merge poo poo from the working branch to release without overwriting the release branch's config files or using cherry-pick instead of merging.
|
|
#
¿
May 1, 2009 20:32
|
|
|
code:
|
|
#
¿
Apr 7, 2010 01:30
|
|
|
Thermopyle posted:Using git, how can I move all my commits since my last push to github to a new branch? Off the top of my head... git checkout -b newbranch creates newbranch at your current commit, and switches you to it. Then, git branch -f master origin/master moves the master branch to point at upstream's master.
|
|
#
¿
Dec 16, 2010 19:22
|
|
|
oiseaux morts 1994 posted:It implies that C6 has two parents. oiseaux morts 1994 posted:If that were the case, which path should C6 follow? oiseaux morts 1994 posted:Or does the merge commit change the commit's parents so now C5 points to C4 points to C3? oiseaux morts 1994 posted:If so, then the iss53 branch still has C5 pointing to C3 - are commits allowed to store more than one pointer to a parent, depending on branch? Evidently not, because if I checked out C5 as a tag, then how does C5 decide to point to C4 or C3?
|
|
#
¿
Nov 14, 2013 18:44
|
|
|
Suspicious Dish posted:I wish merges and rebases were a bit better, so that if I interactively got a merge conflict, I could just say "ignore the conflicts, just pick theirs" without having to go around deleting the "<<<<<<<<<<<<"s every single time.
|
|
#
¿
Feb 21, 2014 17:28
|
|
|
|
| # ¿ May 5, 2024 01:45 |
|
|
Ciaphas posted:I'm trying to think of instances where git pull --rebase would gently caress up or be the wrong answer, and I'm coming up empty. Unless you're in a group that wants every merge commit for 100% true to life history, and nuts to that. Speaking as someone who has git pull setup to rebase by default, I have encountered the following situation: Your upstream looks like oldest -> older -> old. Your checkout is up-to-date with upstream. Your coworker has been doing some work and hasn't pulled in a few hours. Their checkout looks like oldest -> unpublished. Your coworker asks you to pull directly from their checkout and take a look at what they're doing. What you want your repo to look like, in the best possible world: oldest -> older -> old -> unpublished (rebasing their tree to the head of your tree). What would be acceptable, if somewhat annoying: getting an error saying that you have to do some sort of manual merge, because you have very stupidly asked to do a rebasing pull from a checkout that is not your upstream. What git pull --rebase actually does: oldest -> unpublished -> older -> old (rebasing your tree to the head of their tree). In summary, git pull --rebase works perfectly as long as you remember that it always moves the commits that are in your tree to be at the end of where you're pulling from. If you're pulling "unpublished" commits which should be rebased, then you need to rebase in "the other direction" that what it does by default. That said, this is not a common situation and it's super easy to avoid.
|
|
#
¿
Sep 1, 2016 23:41
|
|