Re: [git-users] Re: How to recover from a "Detached Head"
> > > git fetch origin > git merge origin/master > OK, maybe safer. For instance, you take for granted that everyone would use > `git commit -a` for a start and then may be try using "advanced" stuff. > But as one example, here at my $dayjob a bunch of webdevs hired about > 2-3 month ago used those partial staged commits all the time even before > they did their first `git merge` (actually, they used `git add --patch` > which provides for even more fine-grained staging). Why? Because we > here value clean history and atomic commits and so we focussed on that > first. > How does using snapshots make for clean commits? I would think it would make for broken builds when files are forgotten. You should not be working on three different things at the same time. Commit often, one step at a time. Push most commits to minimize merge issues and allow restructures with minimal pain. You do need to structure things properly. For example, you might have a config file that has a standard version checked in but each developer tailors it. In that case do not use the source control to manage the differences. Instead, each dev should have both the standard and tailored version in their working directory and then have some mechanism to chose which to use (e.g. and environment variable). > > You seem to assume that the approach Subversion takes is a de-facto > standard and hence every other tool out there must strive to make > Subversion users feel at home. I use "Subversion" as a metaphore for basic source control. Even MS team studio and perforce do the basic shared repository work. I am not talking about Subversion's quirks. > Also I think you might check out Fossil [1]. I'd say it's a DVCS with > > Thanks for the pointer. But Git seems to have market share, which counts for a lot. I think Git will be fine as long as one keeps it simple. Anthony -- 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.
Re: [git-users] Git ancestor/descendant terminogy clarification
> From: Vasily Makarov > > Git documentation defines commit ancestry as "reachability" of one commit > from another. > Formally, this might mean that every commit is ancestor and descendant of > itself. > I've also checked git merge-base --is-ancestor and found it returns "true" > for same commit passed twice as argument. > > This is formal although not so evident detail, and IMO it changes meaning > of some git commands/options. > > Does anybody have any thoughts on this? I believe that "ancestor" and "descendant" are consistently used in the "inclusive" sense, that is, a commit is its own ancestor and descendant. If the documentation is not consistent in this use, that needs to be fixed, because not getting that detail right could cause unpleasant surprises. Dale -- 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.
Re: [git-users] Re: How to recover from a "Detached Head"
On Sun, 2 Nov 2014 18:26:15 -0800 (PST) Anthony Berglas wrote: > Thank you for all your very considered replies. The solution I end > ed up using (without the complex explanations) was > > git push > # fail > git pull > git merge origin/master This step is not needed: `git pull`, when you're on "master" which is set to track "origin/master" (we imply this is the case here) will fetch all the new stuff from "master" at origin and then merge it into "master". I would reiterate that `git pull` has too much magic built in so I would use git fetch origin git merge origin/master instead until you do really understand what these two commands do and how `git pull` combines them. > # resolve conflicts > git push > > This should go up the front of any manual of GIT, right after git > clone. But I have not seen it explicitly that I can recall. (I threw > the abtmp branch away) > > My interpretation is that that when you push to a remote it will will > follow any direct set of arrows (only) to move origin/master along. Correct, unless you use "--force" with `git push` *and* the remote repository allows such forced pushes--they are disallowed by default for obvious reasons (if these are not obvious feel free to ask). > I have not read that anywhere though. > > > > One problem with GIT is that every document author gets so carried > away with advanced features for obscure branching and even partial > staged commits(!) that they just lose track of the basics. > > For example the Git Basics chapter in the git-scm.com book talks about > advanced things like staging in the intro (which I would never use, > just always commit -a) but does not describe how to check in to a > shared repository and resolve conflicts. Then the external > repository chapter does not talk about merging! > > The simple model, which I use, is that there is one shared repository > used by all developers. I have a local cache, much like Subversion > but storing all the history for convenience. We all normally work on > head, with branches for releases that are kept very short. Big > merges are dangerous and avoided. > > I have seen teams get into big trouble just introducing branches to > CVS. As code is merged backwards and forwards between the branches > errors are introduced. Buggy code often reappears on different > branches, only to be merged back onto good branches. But the good > news is that once you fix the same bug multiple times you get really > good at fixing that bug. Of course because of all this merging the > code could never be restructured which would make the merges > unmanageable. > > Note that the above is not because of CVS's many, many issues. It is > instead the nature of branching and merging code. And in particular > to rely on complex branching rather than having a good module > structure that makes branching largely unnecessary. > > The idea that people are only staging some file in their working > directory at particular times during the edit, and then putting > different staged changes into different branches, and then pushing > different branches to different shared repositories seems just crazy > to me. Broken builds would be the least of the problems. Maybe a > team of people as smart as Linus Torvald might be able to handle it, > but not the people that I have worked with. > > So it is great to have fancy functionality. But getting the basics > right is most important. Using git like Subversion doc should be > chapter 1, not just left as a something implied. > > The problem is that "basics" is a different thing depending on where you stand for. For instance, you take for granted that everyone would use `git commit -a` for a start and then may be try using "advanced" stuff. But as one example, here at my $dayjob a bunch of webdevs hired about 2-3 month ago used those partial staged commits all the time even before they did their first `git merge` (actually, they used `git add --patch` which provides for even more fine-grained staging). Why? Because we here value clean history and atomic commits and so we focussed on that first. You seem to assume that the approach Subversion takes is a de-facto standard and hence every other tool out there must strive to make Subversion users feel at home. While Subversion does indeed have a great "market share" and is well entrenched in the shops not completely sold on Microsoft-supplied stuff, and there's nothing really wrong with the approaches to SCM it implements, Git is just different. I know this sounds weak, but no, you can't really make it work like Subversion because it has been created with different mindset and different goals. It's like procedural programming languages vs functional: you can write programs in both, and (typically) you can to a certain extent mimic approaches from a "foreign" domain in a code written in "native" but it will look and feel clumsy at best. The same goes to Git vs Subversion: the key to getti
Re: [git-users] how to convince git ls-files to include ALL files in repo?
> From: Sam Roberts > Alternatively, there must be a command that gives the path to the root > of the current .git tree, what is that command? I could use its output > as an argument to git ls-files... "git rev-parse --show-toplevel" There are several related options; see the manual page. Dale -- 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.
Re: [git-users] Git ancestor/descendant terminogy clarification
On Mon, 3 Nov 2014 06:42:56 -0800 (PST) Vasily Makarov wrote: > Git documentation defines commit ancestry as "reachability" of one > commit from another. > Formally, this might mean that every commit is ancestor and > descendant of itself. > I've also checked git merge-base --is-ancestor and found it returns > "true" for same commit passed twice as argument. > > This is formal although not so evident detail, and IMO it changes > meaning of some git commands/options. > > Does anybody have any thoughts on this? I'm afraid this question is of so academic we on this list have nothing to do with it. If you think this is a documentation bug, I recommend you to post a message to the main Git list (git at vger.kernel.org). You don't have to be subscribed to it for posting but please make sure your MUA doesn't produce a HTML-formatted message as it will be rejected. See [1] for more info. 1. https://gist.github.com/tfnico/4441562 -- 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.
[git-users] Git ancestor/descendant terminogy clarification
Git documentation defines commit ancestry as "reachability" of one commit from another. Formally, this might mean that every commit is ancestor and descendant of itself. I've also checked git merge-base --is-ancestor and found it returns "true" for same commit passed twice as argument. This is formal although not so evident detail, and IMO it changes meaning of some git commands/options. Does anybody have any thoughts on this? -- 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.
[git-users] Re: remote depot with branch displayed; but no info from git remote
Thanks, I thought something was wrong; I'll give it a try. On Thursday, October 30, 2014 10:31:58 AM UTC-4, Ben A wrote: > > Hi, > I am new to git; and created a bare shared repository from one I had been > working on. > The shared depot has a reference to a remote branch I had copied from; > but git remote gives no information. > > git branch -a > branch1 > branch2 > * master > remotes/origin/branch2 > > git remote -v > > Did something break, or is it normal? I was following directions in git > guide using scp. > Also, I wouldn't mind deleting this reference as I will be treating my new > shared repository as the new origin; but wasn't sure how to clean up as > origin is not listed by remote command. > Thanks > -- 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.
[git-users] Re: Git upgrade to latest version to support stash
On Tuesday, 28 October 2014 10:34:26 UTC+1, Manjunath Kashyap wrote: > > We've been running git 1.7.2 on staging/production server (Linux), > We are planning to upgrade the existing GIT to latest version. > My main preoccupations are that we've got a number of ongoing projects > that are all "in git1.7.2". > So if I upgrade git on the server's box, would anything break? > Would anything totally happen to the existing repositories if we installed > the latest version of git on the external server? > Please let me know the generic steps to upgrade GIT. > > This question has already been asked and answered, see https://groups.google.com/d/topic/git-users/-lN51q6qL5Q/discussion . -- 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.
