|
http://git-scm.com/book If you're using Mac or Windows I'd recommend also getting Atlassian SourceTree for a graphical interface.
|
#
¿
Jan 23, 2014 18:19
|
|
|
|
| # ¿ May 3, 2024 22:11 |
|
|
Is there any way, in Mercurial, to avoid pushing some branches? I.e. I have some local branches that I'd really prefer to keep private, but it seems I can't push without them going to the remote as well. (This annoys me quite a bit since I'm used to git where branch-tracking is opt-in.)
|
|
#
¿
Jan 31, 2014 18:30
|
|
|
I keep seeing the "git reset does three different things" argument. What? It does one thing. Or rather, it does a double operation: First, moves the "current revision" pointer somewhere else, and then updates the working copy (in a more or less destructive way) to match that new current revision. This could sound very similar to the "git checkout" command,except that checkout won't let you destroy data in the current working copy. So it makes the distinction pretty easy. Need to work on a different branch? "git checkout". Need to go to somewhere in the past? "git reset".
|
|
#
¿
Feb 20, 2014 12:48
|
|
|
Ender.uNF posted:Is there any way to set an ignore file that is committed as part of the repo, but applies to all branches? Right now I have to cherry pick and merge to mine and everyone else's named branches, plus the legit branches, otherwise some of our devs accidentally commit crap. No, since the .gitignore file is a file, it's part of a tree like any other file and you can't really just silently add anything to a tree. (At least it creates a new commit anyway, per tree/branch.) What you can perhaps do is write a hook script that validates pushes to the central repository, and reject them if they contain unwanted things.
|
|
#
¿
Apr 26, 2014 09:00
|
|
|
Definitely. You can't switch to a different VCS without also changing your procedures. Particularly not when going from a centralized VCS to a decentralized one. There are two different equivalents for SVN Commit, as I see it. One is always rebasing your changes onto master. This gives you commits with mismatched physical and actual timestamps, since they had to be re-written to match the new past history. Still do keep in mind that every commit keeps both timestamps: The one the author claims it was made, and the one it was actually made. The former will be out of order if you use a rebase-based workflow, the latter will not. The other way is to view the merge-to-master as the equivalent to the SVN Commit. The SVN Commit is when you share your changes with the world, but your changes have to be one big lump, with no time-structure to it. The Git merge-to-master (followed by push) is also when you share your changes to the world, but it can have more structure in it, since the separate history of multiple Git commits is kept. Using Git the same way you use SVN is going to be painful, you really should try to change your procedures and re-educate your developers, to use it better: Private branches, feature branches. Merge the master into the feature branch once in a while, merge the feature branch into master when it's finished (or at a good point). It's somewhat more complex, but it keeps your logical history cleaner, since related commits (related by feature/bugfix) are kept together in a branch; compare with SVN where commits related by feature may be distant in the history.
|
|
#
¿
Jun 21, 2014 09:15
|
|
|
wwb posted:^^^ Sourcetree actually does pretty well on that front. I still haven't figured out how to work git add -p, so it's always SourceTree for me when I need to make "partial" adds/commits. The git add -p UI is barely better than that of venerable 'ed'.
|
|
#
¿
Jul 2, 2014 22:19
|
|
|
Have you created a repository for your project on the site? Have you cloned the repository to your own computer? Can you commit changesets to your local repository? Can you push local changesets back to the remote?
|
|
#
¿
Apr 1, 2015 14:08
|
|
|
If you have a few but invasive changes you want to put on top of another branch history, you can also simulate a rebase by checking out the head of the branch you want to rebase onto, make a new branch and switch to that, then cherry-pick the commits you want to place on top of it. Those cherry-picks will probably cause conflicts, but it might be more obvious how to resolve them.
|
|
#
¿
Apr 4, 2015 20:42
|
|
|
ExcessBLarg! posted:Which results in a single commit, "Summary of all the changes." that includes your changes against the latest upstream. The force push updates the pull request to point to the squashed version, which it wouldn't do normally. Beware that this operation will lose your original commit history, so you might want to back it up first. You can "back up" your original commit history of the branch by placing a tag or another branch at the last commit of it, then those commits will still be reachable after the squash operation rewrites history by making new commits.
|
|
#
¿
Apr 11, 2015 19:04
|
|
|
Also note that git actually snapshots the file when you add it to the index. This means that in the following sequence: 1. Check out repository 2. Modify file A 3. git add A 4. Modify file A (some more) 5. git commit Only the changes made in step 2 are committed to a new revision, those made in step 4 are not stored anywhere in the history yet.
|
|
#
¿
May 11, 2015 16:14
|
|
|
It looks like there is a FreeBSD port called git-lite that probably avoids those things.
|
|
#
¿
Apr 2, 2016 22:58
|
|
|
Your own HEAD is on origin/master, which is pretty weird. Try to checkout master (not origin/master), then pull from that.
|
|
#
¿
May 3, 2016 10:21
|
|
|
"master" is the name of the default branch in git. "origin/master" refers to the "master" branch on the remote named "origin", which is the default name for the remote you get when you clone a repository. When you make changes, you commit them to your "master" branch. When you've got a bunch of changes you're ready to share with the world, you push your "master" to "origin/master". That's only possible if "origin/master" hasn't moved since you diverted from it, if others have committed to "origin/master" since then you'll have to either merge your changes, or rebase your changes on top of it. HEAD is the name for your current working copy base, it usually follows the local branch you're working on.
|
|
#
¿
May 3, 2016 12:26
|
|
|
uXs posted:Is there some way in Git to just checkout the latest commit, skipping over all the intermediate ones? Is the problem that your current working copy (on Windows) has files with too long paths, which then can't be removed? If that's the case, you will probably have to remove them manually. The easiest way, that doesn't need special software, is usually to rename folders above the "victim" files until the total paths are sufficiently short. You may have to do some hard resetting or other nasty stuff after that, to get your working copy working again.
|
|
#
¿
May 11, 2016 17:35
|
|
|
22 Eargesplitten posted:I feel like there should be an obvious answer to this question, but googling isn't finding it. Is there some sort of setting for github to let people download a repo without my needing to approve it? Or does it do that automatically? I just see that it's called a pull request, which sounds like I need to approve it. A pull request is someone asking you to integrate a change of theirs. (Requesting you to pull a change from them.) If your repository is public, anyone can clone it, i.e. make a copy for themselves.
|
|
#
¿
May 21, 2016 19:28
|
|
|
peepsalot posted:What do you mean "become an orphan", that sounds like its still around in some way? Isn't it completely gone with no trace after a hard reset? Objects in git stay in a repository copy even when nothing references them, until they are removed by garbage collection. By default, garbage collection also only removes objects after they have gone unreferenced for a grace period of 30 days or so. That gives you a chance to recover from many types of fuckups, as long as you had your files added in some way. In fact, even just "git add" without a commit should still create an object for the file, as far as I understand. That file object is then referenced in the temporary tree object constructed up until a commit.
|
|
#
¿
Jul 28, 2016 21:55
|
|
|
peepsalot posted:"A" was put in a stash, but the editor apparently did not reload the file from disk or warn me because its a piece of poo poo (atom). Stash B. Make a new temporary branch from your starting point. Apply A from the stash. Commit. Apply B from stash. Commit. Check out starting point again. Cherry pick commit after applying B on the temp branch. That should isolate those changes. It's probably possible to do in a shorter way, but this seems like the most straight-forward.
|
|
#
¿
Oct 16, 2016 23:15
|
|
|
In Git? I don't know how you'd actually perform it, but you'd have to generate a new branch mirroring the branch the file with changes comes from, but containing only that file. Then you can merge that new "fake" branch in. I think "filter-branch" may be the command? This would obviously still decouple those changes from the original branch, and you may get trouble if you later attempt to merge in that branch too.
|
|
#
¿
Jan 6, 2017 15:45
|
|
|
ExcessBLarg! posted:You can merge the two branches such that the merge commit only includes one file from the "other" branch. But both branch histories would show in "git log", the history wouldn't be specific to that one file. That was also my first idea, but not only will it cause history to show commits not relevant to the single file, it will probably also cause even bigger issues if you need to merge the branch in full later on.
|
|
#
¿
Jan 6, 2017 17:03
|
|
|
Looks like a permission problem on the server, your user account doesn't have read permissions on the directories hosting the submodules' repositories.
|
|
#
¿
Apr 14, 2017 21:32
|
|
|
You could either do a full history rewrite, to put everything into a single branch history, or otherwise you could do something where you import one repository into the other as a disconnected branch, then merge them to a single branch going forward.
|
|
#
¿
Feb 17, 2018 15:13
|
|
|
Can't you make the version bump an amendment to the merge commit? It's not illegal to have more changes than just the strict merge in a merge commit, although might be unusual.
|
|
#
¿
Mar 16, 2018 23:14
|
|
|
Grump posted:When you are trying to run git rebase with a bunch of commits, each of which has a merge conflict is the process, as follows? > git rebase develop fix merge conflicts > git add fixedfile.py > git rebase --continue fix more conflicts, add fixes, continue rebase, until done > git push When fixing conflicts during rebase you do not commit yourself, leave the fixed files in the index. The only time you'd use 'git commit' during a rebase operation, I can think of, is when using the 'edit' action in an interactive rebase.
|
|
#
¿
May 5, 2018 06:55
|
|
|
Create a new branch with head at 4, then reset master's head to 2.
|
|
#
¿
Feb 26, 2020 14:06
|
|
|
If you're being asked to push all the sausage-making then the reviewers should understand they should be judging the end product and not the intermediate steps. Don't review individual commits if the commits are subject to rejiggering.
|
|
#
¿
Mar 11, 2020 08:59
|
|
|
There's a bunch of tricks to avoid cherry-picking, or making handle merges better, in this article series: https://devblogs.microsoft.com/oldnewthing/20180312-00/?p=98215
|
|
#
¿
Sep 3, 2021 13:54
|
|
|
I have a similar situation, except it's more like wanting to make a monorepo of several projects that will continue to be developed. The plan I have right now is to move everything in each repo individually to a subdirectory as they should be structured after the combining, then replay the history of each repo into a new one, with branch names changed so they don't clash. Then at the end do an octopus merge between all the separate heads from each repo and end up with a single one. I'd rather not have to bother with rewriting the history of all the original trees, but prefer to preserve everything.
|
|
#
¿
Jan 27, 2023 08:12
|
|
|
At the very top of the git status, does it say what branch you're in? Or does it perhaps say "detached head"? Or maybe a merge or rebase in progress?
|
|
#
¿
Oct 11, 2023 06:22
|
|
|
|
| # ¿ May 3, 2024 22:11 |
|
|
Do anyone have a favorite tool to follow a git history along a specific branch, and easily view complete diffs for the changes? Preferably with a way to only view merge commits to the branch and commits directly on the branch. (Use case: I have a few months of changes to a repository I'd like to review. Most are developed in feature branches.)
|
|
#
¿
Oct 24, 2023 14:25
|
|