On Wed, 2006-12-06 at 13:16 -0500, Kristian Høgsberg wrote: > On 12/6/06, Brian Paul <[EMAIL PROTECTED]> wrote: > > Brian Paul wrote: > ... > > Kristian reminded me: > > """ > > Just a heads up to those that have used the git mirror I had running > > prior to this: the new official repo is a new import from scratch, > > since I used a more complete authors list and thus the sha1 sums are > > all different. > > > > If you have changes in a repo clone from my mirror, you can extract > > them using e.g. git-format-patches and re-apply in the new repo. > > """ > > Oh, oops, I wanted to send that to the list too, thanks for forwarding it. > > And it looks like there's an origin branch in the repo now. This > happens when you just say > > git push > > to push changes instead of > > git push origin
I don't think so, I think it happens when you do git-push --all though. Unfortunately, the --all option is rarely a good plan. Right now, the separation between upstream and local data is done almost entirely by convention. Take a look in the .git/remotes/origin file and you'll see lines like: Pull: refs/heads/master:refs/heads/origin When you run $ git-fetch origin changes on the remote 'master' branch changes will be placed on the local 'origin' branch instead of the local 'master' branch. This lets you track a remote repository and still make local changes. Git will not fetch changes from a remote repository unless the head of the local branch is a direct ancestor. Once you have fetched the remote changes and the local 'origin' branch reflects the current state of the remote branch, you can merge those changes to your local master branch by using git-pull: $ git-pull . origin If you have no local changes, this doesn't do anything other than move your local 'master' branch to the same location as your local 'origin' branch. Note that 'git-pull' merges whatever branch you name into your current branch, so this example assumes your current branch is 'master'. The 'origin' in the 'git-fetch' line refers to the .git/remotes/origin file name. the 'origin' in the 'git-pull' line refers to the local branch named 'origin'. Yes, using the same name for two completely different objects is confusing. And, you can add more Pull lines to your .git/remotes/origin file to track additional remote branches, I use a convention of appending -origin to the branch name to represent the local version of the remote branch. The Pull lines are also used by 'git-push' -- if it finds local branches with the same name as the remote branch name in the Pull line, it will automatically push local changes on that branch to the remote repository. I really like the mechanism -- you can add more .git/remotes files to track additional repositories, and even re-name their branches so they don't conflict in your local repository. But, I sure wish it could be made a bit more obvious, and a bit easier to manage. Right now, my preferred configuration tool remains emacs. > well... AFAIK, anyway. The 'origin' branch is a branch that gets > created when you clone a repo and it's always identical to the > 'master' branch in the repo you clone from. Pushing the 'origin' > branch is a common pitfall, and I believe it's a behaviour that has > been fixed in recent git version. It's pretty harmless, but somebody > with access to the upstream repo (which why I'm cc'ing Keith and > Daniel) need to remove the branch there. I removed it; I wish we had some way to make it impossible to push... > Another common mistake with the git commit message format. There is a > convention that the first line in the commit message should be a > single short summary, optionally followed by a blank line and then a > more detailed description if you're so inclined: Right, once you're used to this convention, it starts helping you provide a concise one-line summary of the work done. You know you're waiting too long between commits when a single line is insufficient to summarize the changes; in cases like this, I generally abandon the commit and split it up in several smaller pieces by committing only a few files at a time. Being able to make many tiny changes without having to wait for the network is one of the huge git features; you only need synchronize when you want to publish a long line of development. Please let us know when you have questions about using git; our support group for former CVS users is fairly friendly. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
