Re: Cloning tags from master
On Mon, Oct 15, 2012 at 12:44 PM, dquince devin.qui...@troppussoftware.com wrote: I am trying to implement using tags in our build process, but am running into an issue with pulling tags from master. My scenario is as follows We decide on a release and I tag master with testtag which has commit testtag-1-gf3b117e When I make another commit to master and check the tag, I see it as testtag-2-gfb56442 I don't know what you mean by check the tag, but those look like the output of git describe when HEAD is one or two commits ahead of testtag (with no tags that are closer). When I try and pull the tag using testtag, it just wants to pull the latest commit to master. You're probably not running git pull origin refs/tags/testtag, but I think that's the only way to pull the tag, so I don't know what you're doing here. The tag doesn't include anything that's not part of the tag's history, though, so pulling it won't get the latest version of anything. I verified this works in branches other than master, so can this be done from master or does the tag just follow the head? Tags never follow anything. Once they're created, they stay put. -PJ Gehm's Corollary to Clark's Law: Any technology distinguishable from magic is insufficiently advanced. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A basic question
On Thu, Oct 11, 2012 at 10:38 AM, Jim Vahl j...@wmdb.com wrote: 1) Does git have a built-in way to get a list of all of the most recently committed files only at a given point in time, thus automatically recording the revisions of all of the component files of a release? This implies that for files which are being modified or which have been staged but not committed, that git would go back to find the predecessor file which had been committed. I feel like I'm missing the point of your questions. Why do you think your central repository would contain anything that hadn't been committed? -PJ Gehm's Corollary to Clark's Law: Any technology distinguishable from magic is insufficiently advanced. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
On Wed, Oct 3, 2012 at 10:34 AM, Angelo Borsotti angelo.borso...@gmail.com wrote: HI PJ, take a git commit without --allow-empty: if the trees are equal, it creates no commit, and if the trees are different it creates one. Take then a git commit --allow-empty: if the trees are equal it may create a commit or not depending on the parent, message, author and date; if the trees are different it creates a commit. So, the statement does not apply to commits in general. But that same thing applies to git commit without --allow-empty. If you create the same object twice then only one copy is stored, regardless of how you create it. In fact, the commits you were creating in your example were orphans, so --allow-empty couldn't have had an effect on them in any case. -PJ Gehm's Corollary to Clark's Law: Any technology distinguishable from magic is insufficiently advanced. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
On Tue, Oct 2, 2012 at 2:56 PM, Angelo Borsotti angelo.borso...@gmail.com wrote: Hi Junio, It does create one; it just is the same one you already happen to have, when you record the same state on top of the same history as the same person at the same time. No, it does not create one: as you can see from the trace of the execution of my script, the sha of the commit is the same as that of the other, which means that in the .git/objects there is only one such commit object, and not two with the same sha. The meaning of the word create is to bring into being something that did not exist before. There is no creation if the object already exists. It's also impossible to create two identical files in Git. If you try, you'll find that they both have the same SHA1, and thus are represented by the same object in .git/objects. You have a script that creates two commits that are identical in every way. What practical difference does it make whether they're represented by one object or two? -PJ Gehm's Corollary to Clark's Law: Any technology distinguishable from magic is insufficiently advanced. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Your branch and 'origin/master' have diverged
On Mon, Aug 13, 2012 at 12:58 PM, Hilco Wijbenga hilco.wijbe...@gmail.com wrote: Hi all, A colleague of mine (after a relatively long absence) noticed the following when running git status: # On branch master # Your branch and 'origin/master' have diverged, # and have 250 and 19 different commit(s) each, respectively. # nothing to commit (working directory clean) He asked me what to do and I told him to do what has always worked for me in the past when something like this happened: gitk, reset master branch to here (to a commit before the divergence and using --hard), git pull origin master. Problem solved. Well, not this one. This one is persistent. :-) I am at a loss what to do. master and origin/master do *not* point at the same commit. Even after the git reset --hard ... and git pull. Running my silver bullet solution gets us in the same situation every time. I assume that the commit you reset to wasn't actually before the divergence, then. It sounds like what you're trying to do is just long-hand for 'git reset --hard origin/master'. As mentioned before, that *does* assume that you want to throw out everything you've committed locally. If that's *not* the case, try 'git rebase origin/master' or 'git pull --rebase'. And then go slap the person who rewrote the history of origin/master. -PJ Gehm's Corollary to Clark's Law: Any technology distinguishable from magic is insufficiently advanced. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pushing branches
On Fri, Jul 20, 2012 at 8:26 AM, Thiago Farina tfrans...@gmail.com wrote: Hi, How can I push a working branch to github inside it? E.g: # On master: $ git checkout -b feature-work # On feature-work # vi, hack, commit, ready to push $ git push origin master # here I expected it would working pushing my commits to a feature-work branch in github. Or if I omit master it gives me a [rejected] error. Everything up-to-date. $ git checkout master $ git push origin feature-work # Now the branch is pushed. ??? I must be missing something. It looks like the reason it didn't push feature-work the first time is because you told it to push master instead. -PJ Gehm's Corollary to Clark's Law: Any technology distinguishable from magic is insufficiently advanced. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pushing branches
On Fri, Jul 20, 2012 at 6:40 PM, Thiago Farina tfrans...@gmail.com wrote: On Fri, Jul 20, 2012 at 4:19 PM, PJ Weisberg p...@irregularexpressions.net wrote: On Fri, Jul 20, 2012 at 8:49 AM, Thiago Farina tfrans...@gmail.com wrote: What I'm looking for is to upload/create the remote branch in github from inside my local branch, without having to checkout master in order to do so. In that case, do exactly what you did, except don't checkout master. Why you suggest that? If I demonstrated that origin master or just origin in the current branch doesn't do what I want, i.e, push it to github. In your original email, you had one command that did what you wanted and one that didn't. $ git push origin master $ git push origin feature-work Can you spot the difference between them? Like Konstantin said, you can look into the different options for push.default, but don't expect Git to push one branch when you told it to push another. -PJ Gehm's Corollary to Clark's Law: Any technology distinguishable from magic is insufficiently advanced. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
