git-commit

Is there a way to rebase and squash commits on Gitlab CE UI, instead of using the interactive mode through command-line? It seems implemented in issue EE 150 to the EE PR 1024 , for allowing squashing merge request (GitLab EE 8.17). See the documentation (EE for now) " Squash and merge ". The CE issue 4106 advocates for that feature to migrate back to CE. Update Feb. 2018, a year later: as Jürgen Steinblock adds in the comments : Great news! It looks like this will make it into 10.8: see issue 34591 : "Squash and merge in GitLab Libre (CE)". Update June 2018: Jürgen Steinblock confirms in the

I added a git repository using git-subtree. The problem is that I did a hard reset back to before the repository was added with git-subtree. Now the commit history is still in the repository but it's disconnected from master. Any idea how to remove it? I tried git rm --cached with no luck. LopSae To remove right away commits that are already unreachable, which would be the case of your subtree commits, you can use the following commands: git reflog expire --all --expire-unreachable=0 git repack -A -d git prune git gc will not immediately collect unreachable commits, since these (in the default

After git pull I have done git reset hard to undo the merge with commit id before merge.Somehow my entire commit is gone and I cant the see the commit in history also. But I have the commit id , on git show command I can see my changes. How can I get back my changes and how to track what mistake I have done if you have the commit hash, and you have not run garbage collection, you can always go back to that commit with git checkout <sha1> . if you want to re-apply it on top of your current head, you could do git cherry-pick <sha1> 来源： https://stackoverflow.com/questions/6201802/git-pull-deleted

Given at the end is an extracted screenshot from a SourceTree branch tree view (there is a gap in the middle of the screenshot) In that, #1 points to the line which used to be branch 1.7.6.14.X and #2 points to the current status of the same branch. The commit referred to by #3 and the preceding 8 commits on that line were previously attached to branch 1.7.6.14.X . Then another developer supposedly checked out the same branch and did the fix pointed to by #4 . This #4 commit has removed the former 9 commits from branch 1.7.6.14.X and left them dangling. As a result, the branch 1.7.6.14.X now

After using git gc and git repack (with various options) I still have 4825 loose commits in the folder .git/objects . I would like to have all of them in the pack file with the rest or in another pack file. I'm doing lots commit rewriting (amend + rebase) hence it's perfectly normal to have many unreachable commits. My .gitconfig contains these parameters to keep reflogs and unreachable commits for a long time. [gc] reflogExpire = 300 days reflogExpireUnreachable = 200 days pruneExpire = 90 days You may wonder if it make sense but I already needed and have recovered a few commits made several

We use GitHub and we have a request to perform commit signing . After studying the process, it's not clear to me what problem commit signing solves. As I understand the process, there's "local source code" that gets committed to a "local repo" that gets pushed to a "remote repo" . So there are three boxes, and two arrows creating a directed graph from the local source files to the remote repository. For the end user, the flows are reversed. In the model as described, it seems like we want the authorizations to occur at the push to the remote repo; and commit signings have nearly no benefit.

I have a normal repo where there is a working tree and a .git folder in the same directory as the working tree. I'm trying to run a git command from outside this location with the command git --git-dir=/path/to/repo/.git --work-tree=/path/to/repo pull /some/other/repo master but I keep getting the error fatal: /usr/libexec/git-core/git-pull cannot be used without a working tree. . What am I doing wrong? This is a bug in earlier versions of Git. This problem should go away once you upgrade to 1.7.7.2 or later. From the commit that fixed the bug : You can't currently run git-pull or git-rebase

When doing a regular git commit, git commit --verbose shows the diff in the text editor when writing the commit message. Suppose I am doing an interactive rebase ( git rebase --interactive ) to edit previous commits. To 'continue' rebasing, I run git rebase --continue . This opens a text editor for editing the commit message, but it does not show the diff. After making changes to a commit, how can I display the diff when (re)writing the commit message during an interactive rebase? git rebase --continue --verbose doesn't seem like a valid command... To show the diff: git -c commit.verbose=true

So prior to running git commit I often will run the following: git grep --cached -l -I "debugger" I thought it was similar to: git diff --cached (which will show you all the changes you are about to commit, ie. will show you the diff in your staged files). Unfortunately, I just found that the --cached option for git grep simply tells git to "only" look at everything in its index. So how can I run git grep and have it only grep through my staged files? (Yes, I know I could simply do git diff --cached and search in that, but I would rather have the programmatic ability to grep through my staged