How do I see “merge events” in history?
I use the GitHub web interface and the git cli. Answers for either or both are appreciated. Sometimes, when I merge a branch into another branch, I see a commit with a message like "Merge branch 'master' into other_branch" in the GitHub history. But not always. So how do I see all "merge events", inside the history? Even better if I can get a view with vertical lines showing branches and merges (like a graph).
Git context menu in Windows Exporer has a “git bash” option but it doesn't work
Hi. The default git distribution for windows contains, besides the CLI tools, a shell integration, i.e. a context menu for Windows Explorer. This context menu has a "Git bash" option which I suppose should open a Git bash prompt cd'd to the current directory. But instead, the git bash window opens and immediately closes, giving me no chance to even see what it says inside it. Any fix? Note: Opening Git Bash from the Windows Start Menu works fine, but if I open it that way, then I need to manually cd to the needed dir. TIA, Stefan Monov
Re: Git context menu in Windows Exporer has a “git bash” option but it doesn't work
On Fri, Oct 21, 2016 at 3:40 PM, Johannes Schindelin wrote: > Are you referring to Git for Windows? > Which version? From where did you obtain it? I'm not sure about the answer to these questions, so to clear things up, I'm downloading it anew now. Getting it from https://git-scm.com/download/win . I downloaded and installed Git for Windows, version 2.10.1, 32-bit. Indeed the context menu option is now called "Git Bash Here". I don't know what it was called before I installed this new version of git, but now it works fine. I.e. no more auto-closing bash window. Thanks for (indirectly) helping me resolve the issue. :) On Fri, Oct 21, 2016 at 3:40 PM, Johannes Schindelin wrote: > Hi Stefan, > > On Fri, 21 Oct 2016, Stefan Monov wrote: > >> The default git distribution for windows > > Are you referring to Git for Windows? Which version? From where did you > obtain it? > >> contains, besides the CLI tools, a shell integration, i.e. a context >> menu for Windows Explorer. This context menu has a "Git bash" option >> which I suppose should open a Git bash prompt cd'd to the current >> directory. > > I guess you mean either "Git Bash Here" or "Git Bash" (not "Git bash")? > >> But instead, the git bash window opens and immediately closes, giving me >> no chance to even see what it says inside it. Any fix? > > Sorry, there is not enough information to go on here. In Git for Windows' > bug tracker, we were careful to provide you with a template that helps > with providing relevant information: > https://github.com/git-for-windows/git/issues/new > >> Note: Opening Git Bash from the Windows Start Menu works fine, but if >> I open it that way, then I need to manually cd to the needed dir. > > For me, both work fine. For the record, I use Git for Windows (64-bit) > v2.10.1, as downloaded from https://git-for-windows.github.io/: > > $ git version > git version 2.10.1.windows.1 > > Ciao, > Johannes >
Git crash course for SVN users - which of the 2?
I googled and found these two official-looking results: https://git.wiki.kernel.org/index.php/GitSvnCrashCourse https://git-scm.com/course/svn.html Which of the two should I use? And I'd ask for the other one to be deleted so there's no such further confusion for other user.
Is the entire working copy “at one branch”?
This is a very basic question but maybe I just don't know how to phrase my query well enough to find an answer. Let me begin with a SVN example. SVN doesn't have a "current branch" as a property of a working copy, so I'll give the example with revisions instead. Consider a working copy with the dirs `foo` and `bar` in it. In SVN one can `update` foo to an earlier version, but keep `bar` at `HEAD`. Is it possible in an analogical git working copy to checkout one branch in dir `foo` without changing the branch checked out in `bar`? If not, why not? TIA, Stefan Monov
Re: Is the entire working copy “at one branch”?
Thanks Alexei! On Sat, Oct 29, 2016 at 12:47 PM, Alexei Lozovsky wrote: > Hi Stefan, > > Generally with git, your entire working copy will have the same > revision (set to current branch, aka HEAD). The idea behind this > is that your working copy of a repository should always be in > consistent state. > > You can check out specific files or directories from another > revision (mimicking "svn update -r1234 filename"): > > $ git checkout branch-or-sha-hash -- filename > > However, SVN tracks the 'revision' thing on per-file basis, while > in git this is a property of the working copy. So if you do like > above then git will be telling you that the 'filename' has been > changed (as it is certainly different from its pristine version > in HEAD): > > $ git status > On branch master > Changes to be committed: > (use "git reset HEAD ..." to unstage) > > modified: filename > > So it's generally not recommended to do such a thing. > > Another thing that you _can do_ in git to mimick SVN is the > 'standard layout'. There is a feature called "git worktree" which > allows you to have SVN-like directory structure with multiple > directories linked to different working copies: > > $ mkdir my-project > $ cd my-project > $ git clone my-project-repository master > $ mkdir branches > $ cd master > $ git worktree add -b branch-1 ../branches/branch-1 > $ git worktree add -b branch-2 ../branches/branch-2 > > After that you will have directory structure like this: > > $ tree my-project > my-project > ├── branches > │ ├── branch-1 > │ │ ├── 1 > │ │ ├── 2 > │ │ └── 3 > │ └── branch-2 > │ ├── 1 > │ ├── 2 > │ └── banana > └── master > ├── 1 > └── 2 > You can work with these working copies separately, like you > would be working with SVN. Commits in 'master' will go to the > 'master' branch, commits made in 'branches/branch-1' will go > to the 'branch-1' branch.
`git stash apply` deleted a random dir from my working copy
Hi. I just tried `git stash save` for the first time. It worked fine. Then I tried `git stash apply` and while my uncommitted changes were restored, another effect was that a random dir from the root of my working copy was deleted. I don't know why it chose that exact dir, there's lots of other dirs like it in the root. `git stash save` output and shortened `git stash apply` output are attached. Note: The dir that got deleted was a committed and pushed dir. It had no uncommitted local changes. It's not a huge problem, because there was no data loss - I can pull the deleted data back from the repo. But I'd still like to know why this problem happened. TIA, Stefan Monov Saved working directory and index state WIP on clipping: cfeac4b - applying the solution from http://stackoverflow.com/questions/40385482/why-cant-i-use-opengl-es-3-0-in-qt HEAD is now at cfeac4b - applying the solution from http://stackoverflow.com/questions/40385482/why-cant-i-use-opengl-es-3-0-in-qtRemoving debug_stencil_not_working/textureandlight.js Removing debug_stencil_not_working/qtlogo.png [... more removes here ...] On branch clipping Changes to be committed: (use "git reset HEAD ..." to unstage) new file: documentation/textureSize_missing.txt Changes not staged for commit: (use "git add/rm ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) deleted:../debug_stencil_not_working/qtlogo.png deleted:../debug_stencil_not_working/textureandlight.js [... more deleted files here ...] modified: main.cpp modified: main.qml [... more modified files here ...] Untracked files: (use "git add ..." to include in what will be committed) ../dbg_repeater/dbg_repeater.pro.user debug_stencil_not_working/ [... more files and dirs here ...]
Re: `git stash apply` deleted a random dir from my working copy
Actually, I just tried restoring my dir with `git pull origin clipping`, but that didn't restore it. So, besides the question "why did it get deleted", I'd like to ask "how do I restore it?", as well. On Thu, Nov 3, 2016 at 6:06 PM, Stefan Monov wrote: > Hi. > > I just tried `git stash save` for the first time. It worked fine. Then > I tried `git stash apply` and while my uncommitted changes were > restored, another effect was that a random dir from the root of my > working copy was deleted. I don't know why it chose that exact dir, > there's lots of other dirs like it in the root. > > `git stash save` output and shortened `git stash apply` output are attached. > > Note: The dir that got deleted was a committed and pushed dir. It had > no uncommitted local changes. > > It's not a huge problem, because there was no data loss - I can pull > the deleted data back from the repo. But I'd still like to know why > this problem happened. > > TIA, Stefan Monov
Re: `git stash apply` deleted a random dir from my working copy
Scratch my last message, I figured out how to restore it. In the TortoiseGit context menu I selected "Diff", and in the list the deleted files were listed as "missing". I selected them all, right clicked them, and selected "revert". Still don't know why the dir got deleted in the first place though. On Thu, Nov 3, 2016 at 7:01 PM, Stefan Monov wrote: > Actually, I just tried restoring my dir with `git pull origin > clipping`, but that didn't restore it. So, besides the question "why > did it get deleted", I'd like to ask "how do I restore it?", as well. > > On Thu, Nov 3, 2016 at 6:06 PM, Stefan Monov wrote: >> Hi. >> >> I just tried `git stash save` for the first time. It worked fine. Then >> I tried `git stash apply` and while my uncommitted changes were >> restored, another effect was that a random dir from the root of my >> working copy was deleted. I don't know why it chose that exact dir, >> there's lots of other dirs like it in the root. >> >> `git stash save` output and shortened `git stash apply` output are attached. >> >> Note: The dir that got deleted was a committed and pushed dir. It had >> no uncommitted local changes. >> >> It's not a huge problem, because there was no data loss - I can pull >> the deleted data back from the repo. But I'd still like to know why >> this problem happened. >> >> TIA, Stefan Monov
Making it possible to do “git push origin” instead of “git push origin ”, without having to one-time prepare each branch for it
Hi. I'd like to use just: git push or at most: git push origin rather than having to first check which is the active branch with `git branch --list`, then type: git push origin At [1] and [2] I've seen that if I do this once: git push -u origin then from then on I can use just `git push` _for that branch_. However, I don't want to do this "setup" step for each branch, because it's extra work that I also may forget to do. Why is this "setup" step necessary and can I avoid it? Thanks, Stefan [1] http://stackoverflow.com/q/19312622 [2] http://stackoverflow.com/q/6529136
Re: Making it possible to do “git push origin” instead of “git push origin ”, without having to one-time prepare each branch for it
Also, if I do the "setup" step (`push -u`) for a branch that doesn't exist yet (neither on my PC nor on the server), does that remove the need to do `git checkout -b ` first? On Thu, Dec 22, 2016 at 11:14 PM, Stefan Monov wrote: > Hi. > > I'd like to use just: > > git push > > or at most: > > git push origin > > rather than having to first check which is the active branch with `git > branch --list`, then type: > > git push origin > > At [1] and [2] I've seen that if I do this once: > > git push -u origin > > then from then on I can use just `git push` _for that branch_. > However, I don't want to do this "setup" step for each branch, because > it's extra work that I also may forget to do. > > Why is this "setup" step necessary and can I avoid it? > > Thanks, > Stefan > > [1] http://stackoverflow.com/q/19312622 > [2] http://stackoverflow.com/q/6529136
Re: Making it possible to do “git push origin” instead of “git push origin ”, without having to one-time prepare each branch for it
Thanks guys!
