On Thu, 17 Mar 2016 01:41:28 -0700 (PDT) Michele Marcon <michelemarco...@gmail.com> wrote:
> I hade a shallow copy of a github repo for saving space and > bandwidth, since I'm not interested on past history nor I want to > switch branch. > > git clone --depth=1 > > The repo has a gradle build file which I run to create the binaries. > > Then I want to pull the updates from the repo, but git pull warns me > that I made changes... This is not really supported. To cite the documentation: | How to get a Git repository with minimal history | ------------------------------------------------ | | A shallow clone, with its truncated history, is useful when one is | interested only in recent history of a project and getting full | history from the upstream is expensive. | | A shallow clone is created by specifying the git-clone `--depth` | switch. The depth can later be changed with the git-fetch `--depth` | switch, or full history restored with `--unshallow`. | | Merging inside a shallow clone will work as long as a merge base is | in the recent history. Otherwise, it will be like merging unrelated | histories and may have to result in huge conflicts. This limitation | may make such a repository unsuitable to be used in merge based | workflows. To your case, the last paragraph is of most interest. Pulling consists of fetching and them merging. That is, if you have the branch "master" checked out and tell Git to pull "master" from remote "origin", and then merge the tip of the "master" fetched from that remote into your local "master". "The merge base" is the last commit both branches share, and that's what Git uses when doing it's standard -- the so-called "recursive" -- merging which by default uses three-way diffing algorythm which considers not only two tips of the branches to be merged but also their last point of common history. There, "in the recent history" means "available in the local repository". If your remote branch is always updated linearly and hence merging will always result in mere fast-forwarding of your local branch, all is going to be OK, but be warned of possible problems if this assumption breaks for whatever reason. OK, that was some explanation and a word of warning. As to your immediate issue, I'm inclined to think it really lies elsewhere: since pulling is fetching followed by merging, and fetching has nothing to do with your local changes, the message you referred to is most probably generated by merging. Let's now cite the `git merge` manual: | PRE-MERGE CHECKS | | Before applying outside changes, you should get your own work in good | shape and committed locally, so it will not be clobbered if there are | conflicts. See also git-stash(1). git pull and git merge will stop | without doing anything when local uncommitted changes overlap with | files that git pull/git merge may need to update. | | To avoid recording unrelated changes in the merge commit, git pull | and git merge will also abort if there are any changes registered in | the index relative to the HEAD commit. (One exception is when the | changed index entries are in the state that would result from the | merge already.) So there really are two possibilities: you have uncommitted local changes in the work tree, you have uncommitted local changes in the index, or both. The sure way to verify this is by running `git status` and seeing what it tells you. And really, please tell us exactly how do you call Git to do pulling and what exactly does this command invocation tells to you. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
