I've recently tried using branches in git but while they work allright whatever I do I can't display the graph of my branches and merges. I've tried Giggle for ubuntu and gitk -all but none of them works as shown in this nettuts+ tutorial http://net.tutsplus.com/tutorials/other/easy-version-control-with-git/
I type in that
$ git log --graph #Sorry my sreenshot is missing h at the end
but instead of this...
...I get this...
I would be really pleased with a quick reply...
Here is what ' $ gitk --all ' outputs
You might be looking for git log --graph --all, likewise with gitk, I have an alias in my shell:
alias gk='gitk --all'
for just that purpose.
From git help log
--all
Pretend as if all the refs in refs/ are listed on the command line as <commit>.
So if you have branches a, b, and c, it's as if you told git to show the logs and graphs in this manner:
git log --graph a b c
Essentially, git log allows you to list any objets you can reference in what you want to see the logs for. You can even use it on a file, or multiple files files....
$ git log --oneline python-taboot.spec
c96d546 Straighten out the Makefile. Hey -- make rpm works now! Update a lot of docs. Fixes #34 - Taboot 'edit' mode should hint at the file type and give instructi
ea0d60b Version bumpskies to 0.4.0-1beta
a95cfbf Automatic commit of package [python-taboot] release [0.3.2-1].
d9e3ca6 Make python-argparse a Requires for el6 as well
ea7ed54 Automatic commit of package [python-taboot] release [0.3.1-1].
69eaea9 Add conditional Requires on python-argparse. Update README and release notes.
...
And so on...
Related
I face a merge conflict when I would like to rebase the develop branch against my feature branch. I use IntelliJ Idea to execute individual Git commands. Let's say I have 3 pushed commits and I want to squash and rebase them using --interactive mode.
I select all three commits, I select squash, do some rewording, and hit Rebase.
The process fails and an Excel file that appears in the Git panel among Changes and on the diff panel, says the contents are the same. I can only abort or retry the rebase, but continuing doesn't make sense as the change always prevents me to continue.
Here is the console output:
12:50:42.385: [myapplication] git -c credential.helper= -c core.quotepath=false -c log.showSignature=false -c core.commentChar= rebase --interactive develop
Rebasing (1/2)
error: Your local changes to the following files would be overwritten by merge:
excel-file.xlsx
Please commit your changes or stash them before you merge.
Aborting
hint: Could not execute the todo command
hint:
hint: fixup 37d1fc57dff9c7e9a312c88cf78c176cb71dbb47 CommitMessageIsHere
hint:
hint: It has been rescheduled; To edit the command before continuing, please
hint: edit the todo list first:
hint:
hint: git rebase --edit-todo
hint: git rebase --continue
Could not apply 37d1fc5... CommitMessageIsHere
Is there a trick to overcome this obstacle? Is possible to somehow force ignoring and skipping such merge conflict?
You started your rebase with un untracked copy of excel-file.xlsx, and when git met a commit which included the action "create a new excel-file.xlsx file", he stopped.
You have to somehow put aside this untracked version before proceeding.
The simplest way is:
rename that file on disk:
mv excel-file.xlsx excel-file.xlsx.tmp
run git rebase --continue:
either IntelliJ has a button which looks like "proceed with the rebase", or you can run this command from the command line,
once the rebase is complete:
you can compare the contents of both files, and decide what the correct action is -- update the tracked version, delete the tmp file ...
I am using the git mergetool command to fix conflicts. However I have thousands of conflicts, is there way to simplify this so I get everything from the remote?
I am asked to enter c, d or a in the command.
{local}: deleted
{remote}: created file
Use (c)reated or (d)eleted file, or (a)bort?
Since I have thousands of files, I don't want to keep sending c. Is there way to just do this in bulk?
You can solve this outside of git mergetool: run git status --porcelain to get a list of all unmerged files and their states in machine-readable format.
If your Git is new enough, it will support --porcelain=v2. See the git status documentation for details on the output formats. Output format v2 is generally superior for all purposes, but you should be able to make do with either one.
Next, you must write a program. Unfortunately Git has no supplied programs for this. Your program can be fairly simple depending on the specific cases you want to solve, and you can use shell scripting (sh or bash) as the programming language, to keep it easy.
Since you're concerned about the cases where git mergetool says:
Use (m)odified or (d)eleted file, or (a)bort?
you are interested in those cases where the file name is missing in the stage 1 ("base") version and also missing in the stage 2 ("local") version, but exists in the stage 3 ("remote") version. (See the git status documentation again and look at examples of your git status --porcelain=v2 output to see how to detect these cases. Two of the three modes will be zero.) For those particular path names, simply run git add on the path name to mark the file as resolved in favor of the created file.
Once you have marked all such files, you can go back to running git mergetool to resolve additional conflicts, if there are any.
Note that your "program" can consist of running:
git status --porcelain=v2 > /tmp/commands.sh
and then editing /tmp/commands.sh to delete all but the lines containing files that you want to git add. Then change all of those lines to read git add <filename> where <filename> is the name of the file. Exit the editor and run sh /tmp/commands.sh to execute all the git add commands. That's your program!
supposing you want their change and modified yours you can do a pull as like:
git pull -X theirs
Other stackOverflow answers
git pull -X
git merge strategies this link will help understand any other merge strategies for the futuro
If you want that all the change you did will be deleted and you will be sync with the remote.
You should do the following:
git stash
git pull
And if you want to restore the change you did you should type:
git stash pop
Basically 'git stash' is moving the change to a temp repository.
you can learn more in:
NDP software:: Git Cheatsheet
I'm using git on a shared hosting plan which runs a Linux distribution. Because it's shared, I don't have access to sudo. The machine already has git version 1.7.1 installed in /usr/bin/, but this version is rather prehistoric at this point. I've already used make install to get the current version 2.14.1, which is in ~/git-2.14.1/. As detailed by this answer, I can access the correct version of git from the command line like so:
$ git --version
git version 2.14.1
which was a simple change to the $PATH variable, in the ~/.bash_profile, so I can use git just fine.
I have a list of shortcuts in my ~/.gitconfig file that make git much faster for me to use:
[alias]
co = checkout
st = status
ci = commit
... etc etc etc
When I invoke these (e.g. git st), I get the results from the wrong version of git. It goes back to 1.7.1. If I type out the full command (e.g. git status), it uses the correct version of git.
I also have these commands in my ~./bashrc:
git () {
case "$*" in
st* ) shift 1; command ~/git-2.14.1/git status "$#" ;;
* ) shift 1; command ~/git-2.14.1/git "$#" ;;
esac
}
Which I have source-ed since writing.
I have also tried:
alias git="~/git-2.14.1/git"
To no avail.
Is there a work-around that would allow me to use these shortcuts with my preferred version of git? I am imagining a way to hide the config file from the other version by redirecting the pointer to a different location, but I have no knowledge of the existence of any such pointer.
Alternatively, is there a way to totally disable the previous version of git without root access?
When I invoke these (e.g. git st), I get the results from the wrong version of git. It goes back to 1.7.1
That is not what I see in my Ubuntu session.
I have in my .gitconfig
[alias]
st = status
br = branch
v = !git version
That means I type git v, to check git version (which is the same as git --version).
If I change my PATH to a new compiled Git, I do see a different version.
vonc#VONC:~/gits$ echo $PATH
/usr/local/bin:/usr/bin:/bin
vonc#VONC:~/gits$ which git
/usr/bin/git
vonc#VONCAVN7:~/gits$ git v
git version 2.13.0
vonc#VONC:~/gits$ export PATH=~/gits/v2.14.0/bin:$PATH
vonc#VONC:~/gits$ git v
git version 2.14.0
Here's what I found. If I took out the alias section of the .gitconfig, the aforementioned shell wrapper function worked. If I removed that and restarted the ssh connection, nothing worked (as expected).
I found, with help from this answer, that there is a magical GIT_EXEC_PATH variable which tells git where to find tools like git-add, git-commit, git-status, et. al.. Uncommenting my alias section of the .gitconfig file and using
$ export GIT_EXEC_PATH=/path/to/my/new/git's/executables/
made it possible to use the aliases in the .gitconfig file. For me the path that worked was the same folder as I installed into: ~/git-2.14.1.You can check the current value of GIT_EXEC_PATH with:
$ git --exec-path
/path/to/my/new/git's/executables/
Also, echo $GIT_EXEC_PATH works as well. My understanding is that git uses its aliases not through the instance of git which called git <alias>, but rather directly through the executables in it's exec path.
Note: for me,
$ git --exec-path=/path/to/my...
did not work, but if I understand correctly, this is the equivalent command.
TL;DR: add the path to the new executables (git-add, git-status, etc.) in your .bash_profile:
export GIT_EXEC_PATH=/your/path/
we have the following situation:
At time point t0, we took snapshot of C++ project in Unix, which was not finished (release 1702 under Unix), and worked on it migrating to Linux. This was established as Master in a new GIT server.
At time point t1, I created a new branch from Master called 1702, and overwrote everything with the up to date Unix code.
During t1, I made another branch linux_not_working, which is a clone of Master branch.
Now, I tried to merge 1702 into linux_not_working, with git mergetool for handling conflicts, and the result is bad: for example I modified all of the project's Makefiles to work in Linux, and the merge did not even display conflicts, just replaced them with the old Unix ones from 1702 branch, also I did not find how to tell vimdiff to take ALL from REMOTE and not LOCAL (as I understand it, BASE has no meaning in this particular merge).
How best to perform this merge, when in a sense, I have two Masters going? I need to take any new additions from 1702, while KEEPING my customizations in linux_not working (manually, but its a lot of files so cherry pick is not ideal).
Any suggestions for the future? They are going to have to do it at least once more, while a contractor is working on 1703 release, and only later production development will shift to Linux.
Essentially, what I want to do is for GIT to tell me for each file: "File R and L are different, which one you want to keep? (allowing me to take different parts of each, IF it happened to have been modified by both branches)"
Thanks!
Essentially, what I want to do is for GIT to tell me for each file: "File R and L are different, which one you want to keep? (allowing me to take different parts of each, IF it happened to have been modified by both branches)"
If you don't need 3-way merge, you can simply check out the content of the branch and review the change with git gui.
$ git checkout -b manual-merge linux_not_working
$ git checkout 1702 . # overwrites source with 1702's one
$ git gui # take or leave each diff
$ git commi
(Or you may want to do it backwards.)
$ git checkout -b manual-merge-2 1702
$ git checkout linux_not_working .
$ git gui
$ git commit
Once you have manually-merged result, you can overwrite and commit as a merge.
$ git checkout 1702
$ git merge linux_not_working
$ git reset
$ git checkout manual-merge . # or manual-merge-2
$ git commit
I have a repo that I have been committing for 2 months. I do not seem to get any error when I commit daily. However I was looking at git logs and I see that first ever git log (or maybe git can't see beyond that log point) has an error message like this
:100755 100755 1948ac6... 2af905e... M document.doc"
error: Could not read 190d54eb3278746a4e35fd4be82689eb4b1d20a8
fatal: cannot simplify commit cb0c2a3bf0a4ad665eb376b818bdcb0652a06eec (because of 190d54eb3278746a4e35fd4be82689eb4b1d20a8)
I tried the recommendation on: https://git.wiki.kernel.org/index.php/GitFaq#How_to_fix_a_broken_repository.3F
But I did not get what I was trying to achieve, whatever was recommended did not help my case.
This solution could help you:
Make a backup of your .git directory in case you corrupt things more in this process. Then, put back the best version of the packfiles you have available.
For each of the corrupt packfiles, run:
mv .git/objects/pack/pack-**yourpack**.pack oldpack
git-unpack-objects -r < oldpack
Run git fsck --full and git checkout again, give us the output.
Looks like now you should be able to check out, but you will have to run git checkout -f yourbranch, as you have changes in your working dir that are not yet committed. These changes will get lost when you run git checkout -f, though.
Note: This solution was sugested by #Chronial