Re: Cloning tags from master
On Mon, Oct 15, 2012 at 12:44 PM, dquince 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 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 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 Wed, Oct 3, 2012 at 7:25 AM, Angelo Borsotti wrote: > Hi Phil, > >> Perhaps the confusion arises from the the meaning of "the safety". In >> this case, the safety mechanism in place is to prevent you from >> creating a child commit which has the same "tree" contents (working >> directory) as the parent commit. It will not be the same commit >> because it has different parent(s) than its parent commit; but the >> tree (working directory) is the same and git normally prevents you >> from doing this because normally this is an accident, a mistake. >> >> --allow-empty tells git you intend to do this and so it should bypass >> this "no changed files" safety mechanism. It is not a safety to >> prevent you creating a new commit with the exact same sha1; the safety >> is concerned only with the exact same "working directory" file >> contents. >> >> Can you suggest a rewrite of this description which would make it more clear? > > Instead of: > > "Usually recording a commit that has the exact same tree as its sole > parent commit is a mistake, and the command prevents you from making > such a commit. This option bypasses the safety, and is primarily for > use by foreign SCM interface scripts." > > I would suggest: > > "Usually recording a commit that has the exact same tree as its sole > parent commit is not allowed, and the command prevents you from making > such a commit. This option allows to disregard this condition, thereby > making a commit even when the trees are the same. Note that when the > tree, author, parents, message and date (with the precision of one > second) are the same as those of an existing commit object, no new > commit object is created, and the identity of the existing one is > returned." But that's true of 'git commit' generally; it has nothing to do with --allow-empty. -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 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: Git 1.7.12 installer blocked by Gatekeeper - needs signing with an Apple developer ID
On Wed, Sep 19, 2012 at 10:31 AM, Junio C Hamano wrote: > Torsten Louland writes: > >> Installing latest stable git on Mac OS X Mountain Lion is blocked >> by Gatekeeper. >> >> Could you provide an installer for latest stable git that is >> signed with an Apple issued developer ID so gatekeeper will let it >> through? [...] > Whoever you are, please speak up and help Torsten and fellow MacOS > folks. One could argue that anyone whose system requires applications to be signed with a key that the system owner does not possess is beyond help. -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 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 6:40 PM, Thiago Farina wrote: > On Fri, Jul 20, 2012 at 4:19 PM, PJ Weisberg > wrote: >> On Fri, Jul 20, 2012 at 8:49 AM, Thiago Farina 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
Re: pushing branches
On Fri, Jul 20, 2012 at 8:49 AM, Thiago Farina 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. -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 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
