git-branch

I find git docs very cryptic regarding this issue. I want to do a simple thing, but it seems doing it is not simple at all. I have the following situation: $ git remote -v origin git://192.168.0.49/mnt/repos stick /mnt/titanium/podaci/repos I can use git pull to fetch and merge from origin, and that works fine: $ git pull Already up-to-date. I can pull from stick like this: $ git pull stick master Already up-to-date. However, when I pull from stick without the master part, I get this message: $ git pull stick From /mnt/titanium/podaci/repos * [new branch] su2009 -> stick/su2009 You asked me to

I want to find all the merge commits which affect or involve a given file. For background, someone mis-resolved a conflict when merging, and it wasn't noticed by the team for a few days. At that point, a lot of other unrelated merges had been committed (some of us have been preferring to not use rebase, or things would be simpler). I need to locate the "bad" merge commit, so it can be checked to identify what else might have been reverted (and, of course, to identify and punish the guilty). The scenario is like this: $ echo First > a.txt && git add a.txt && git commit -m 'First commit' $ git

I have changed a single file in a subdirectory of my repository and I want to push just that file to Github. I've made a small change to one file, and I don't want to re-upload the entire repository. It seems like all of the instructions that I've seen so far require me to merge locally with the master and then push my local master to the remote origin. How can I push just that one file? krilovich When you do a push, git only takes the changes that you have committed. Remember when you do a git status it shows you the files you changed since the last push? Once you commit those changes and do

Here's a common workflow hurdle I encounter often: master is our "stable" branch $ git status # On branch master nothing to commit (working directory clean) create a module on a branch $ git checkout -b foo $ echo "hello" > world $ git add . $ git commit -m "init commit for foo module" $ git checkout master $ git merge foo do work on master or other branches Over the next couple weeks, more code will be committed to master directly and by other branches. foo branch will go untouched for this time period resume work/make updates on foo branch $ git checkout foo Oh no! foo is massively out of

I'm completely confused about what mine vs theirs means. In this specific case, I've got a feature branch where I just squashed about 80 commits via rebase -i and am merging this back into develop . I got a few conflicts, and I just want to use whatever code is on my feature branch. I tried "mine" but that actually seemed to do the opposite. Could someone shed some light on this terminology? ours and theirs is a somewhat confusing concept; exacerbated when performing a rebase: When performing a merge, ours refers to the branch you're merging into , and theirs refers to the branch you are

How can it possible to get all names of some remote origin branches? I started from --remote --list options, but got redundant origin/HEAD -> origin/master message and branches from the another origin. $> git branch --remote --list origin/HEAD -> origin/master origin1/develop origin1/feature/1 origin1/feature/2 origin1/feature/3 origin1/master origin2/develop origin2/feature/1 origin2/feature/2 origin2/master Branches of specific origin could be matched with <pattern> option, but redundant message is still there. Actually that pattern is not really correct, because some origin's name could be

How can I generate patch for all commits in a given branch by knowing only the branch name? This step is part of a complex workflow all of which is being automated. Hence requiring someone to manually determine the first commit in the branch is not an option. Note that anything relying on reflog is not an option either because changes in the branch are not made locally. VonC If you know from which branch your "given branch" has been created, then making a patch is easy : git diff master Branch1 > ../patchfile git checkout Branch2 git apply ../patchfile (and you can generate a patch applicable

A while back I asked our developers to use rebase instead of merge before pushing . Eliminating trivial merges makes for a much easier to follow commit graph (ie: gitk, git log). Sometimes folks still accidentally do trivial merges, then push. Does anyone have handy or have tips for writing a server-side hook that blocks trivial merges? By "trivial merge", I mean a merge without conflicts. Here's an example , and here's a better explanation of a trivial merge in git . Update Wed Nov 10 01:26:41 UTC 2010 : great comments, all! Thank you. Consider the following: all I'm really asking folks to do

There exist a public repo for Quick framework here . I'd like to be able to fork this into a private enterprise GitHub repository. Forking would allow all the branches to remain. the alternative would be to clone the repo and push up only a single branch to the enterprise but then I lose on not having all the branches from the source/original. update: I ended up pushing all my branches into the enterprise git. if you just do a git push yourRemoteName myNewBranch then it will push the code into that branch on the enterprise git while creating that branch in enterprise GitHub. It's not possible,