I was looking at the follow renames Perl script last week (hey, I was bored!) and while I could tell it didn't work, I did get the feeling that it wasn't an impossible task, at least for the 'explicit paths' case. For the 'whole tree' and subpath cases it _is_ tricky, and would be faster to solve within git, but not impossible. And even then, I am tempted to think that git log could provide some better hints than it does today when walking the whole tree or subpaths, so that cg-log or gitk can as...

Martha has uploaded some new software for you! Click here to view available updated software: http://era-oem.com/?Martha pseudo-device gzip significant dedication to the project are even often asked to join the for the vendor to use UARTs that are compatible with the 8250, 16450, supposed to send +12 VDC or -12 VDC, and the receiver is supposed to printer named rattan: bsd.port.mk file which can be found in /usr/share/mk. This file uses a That DMA channel is now considered to be ``armed''...

This is a very important point to remember not for users but for It is not "somewhere" but "in the current branch", so in a sense it is a bit stricter than that. While on 'master' "branch -d topic" would not remove the topic branch head if it is not fully merged to my 'master' so that is a reasonable safety measure, but when I am on 'next' it will happily remove it. It is One bug in my previous response is that I said we do this only when the command was invoked with shorthand remote name. ...

This is a greatest write-up I've seen for the past several months. I find it very balanced to point out the quirks people would find difficult and explain why things are so by including historical notes in appropriate places when needed. Definitely Documentation/ material when copyediting is done. I have finished only the first half because it's not my git day You might want to check this with the array in sha1_name.c::get_sha1_basic(). It's great that you talk correctly about the latest fe...

I use "git pull . topicA topicB" for a tetrapus, so that is not a reason for me, but when a topicA's older parts are worthy to be in 'next' while later parts are not yet, I often do (on 'next'): git merge "Merge early part of branch 'topicA'" HEAD topicA~3 Also I used to do git merge fast HEAD someTopicIknowIsAFastForward because it felt faster than "git pull . someTopicIknowisAFastForward" I do not think naming a directory (say, ".") to mean "revert everything underneath this direct...

Most likely you didn't run "update-index --refresh" after "cp -l"? Not just in the new copied repository but in the original repository I would suspect you would see this. This is because the index caches ctime and making a new hardlink manipulates the files' inodes, thus making the cached information stale. -

Hello to you! The most important thing in life is love and healthy and strong relationships... That's the thing I desire most of all! Nothing in life can change it, neither money or anything else... I am an ordinary girl with a big and lonely heart... I don't have very high demands to the second half, I want my man to be sensitive, caring and attentive... I want to give my love and tenderness to the only man! If you are looking for a lady, if you are lonely too or your heart misses warmth and attentio...

Yes, I think this is common issue for everybody not just people who worked with BK or mercurial. I find myself almost typing "pwd" to find out what branch I am on (I do not go as far as typing "git cd" to switch branches, though). -

I had a bit different feeling about yesterday's discussion myself. If somebody uses git like you do in "truly distributed way", the current pull behaviour and pull being an operational mirror to push are natural consequence of the model and concepts, and there is nothing to fix (modulo "the default merge source per branch" should be made easier to use). Renaming the pull to merge would not make it any easier to use unless the underlying model is understood, and I fully agree with you on that. ...

Could you try an exactly the same sequence except to make the initial contents of the file 'a' a bit more meaningful (I typically use COPYING file in git.git repository for something like this), by replacing the above "echo 1 > a ..." line with: $ cat COPYING >a && git add a && git commit -a -m '1' and see if it still breaks? You do not need to change the later modification to the file (i.e. "echo 2 >>a"), but only the above single line change. -

Wow, that a magic ! It works ! Thanks for help. P.S. First mail was rejected by my MTA, this is a resend of that mail -

Sounds good to me. When I'm merging in my own projects, I currently always use merge (possibly preceded by fetch) rather than pull. Why? Because I don't want my history full of commit messages like Merge branch "trial_hack" from "../scratch_dir_with_silly_name" In contrast to Linus's case of wanting to record where the remote merge came from, I expressly don't want to record that - I want the merge commit to describe conceptually what was being merged with what. OK, I could use probably ...

Yes, but be warned. As I just discovered, dcommit always commits up to the HEAD of the current branch. So I just did: git-svn dcommit remotes/git-svn..HEAD~3 And the ~3 was ignored. :-( Not a bug, as the doc says that dcommit operates on HEAD, but it would be convenient to have this work -- especially since reviewing with diff (or better log -p) seems natural. + seth -

Hi Comete, authentication with the SVN stuff is really weird. git-svn and git-svnimport use the SVN libraries so that means that if you do svn login proto://host/path/to/repo git-svn proto://host/path/to/repo it works because svn magic cookies get stored in ~/.svn. cheers, martin -

Well, when I was using BitKeeper, I never would. Bitkeeper has what Linus calls the broken "repository == branch" model. So normally I would have one repository where I would track the upstream branch, and only do bk pull into that branch. I would do my hacking in another repository (i.e., branch), and periodically keep track wha was going on in mainline by cd'ing to the mainline repository and doing the bk pull there. The challenge when you put multiple branches into a single repository, i...

We do that for Wine. The problem is that we recommend using git-rebase to make it easier for occasional developers to keep a clean history, and rebase and pull interfere badly. The result is that we recommend always using fetch+rebase to keep up to date, but this is confusing many people too, because git-fetch appears to do a lot of work yet leaves the working tree completely unchanged, and git-rebase doesn't do anything (since in most cases they don't have commits to rebase) but has an apparentl...

For regular developers, sure. But regular developers will need to properly understand the git model anyway, and then they will able to make sense even of the standard git commands ;-) The problem is that there isn't a smooth progression to that point. At first, a user will simply want to download and build the code, and for that git-pull works great, it's a one-stop command to update their tree. Then after a while the user will fix a bug here and there, and at that point git-rebase is IMO t...

I do actually think that this discussion has been informative, partly because I never even realized that some people would ever think to do "init-db" + "pull". Making things like that work is easy enough, it's just that I never saw any point until people complained. And when they complained, the initial complaint wasn't actually obvious. Only when Han-Wen actually gave something that didn't work, was it clear that the real issue wasn't so I definitely think we can make "git merge" ha...

I think there's a fundamental assumption built into the design of git that most programmers accustomed to a corporate environment don't understand. Namely, that each programmer owns his or her entire "repository", and can do whatever he or she darn well pleases with it at any time. Go ahead and create hundreds of transient branches as part of a scripted "merge complexity metric" calculation. Try three different refactoring strategies on different branches, abandon two of them, and prune them month...

Point taken; thank you. In that case, we're full circle with the command naming issues. Push and pull are fundamentally asymmetric operations, but then a consistent UI would dictate that they wouldn't be named symmetrically, as they are now. -- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen -

What I want here is a command "git update" that fetches and fast-forwards the all branches which are designated as "tracking" a branch in some known remote repository. And git-clone would setup all branches appropriately so that they would be updated by git-update. Additionally, it would be nice if git-update would also create new tracking branches for all remotes repositories that had been designated as being tracked, (and git-clone would do this as well). There should also be a mechanism to e...

put clone would be the putative inverse of clone, ie. make a clone of throw is the hypothetical opposite of fetch. I agree that this is academical, because it's logical to only allow fast-forwards for I think the whole clone design is a bit broken, in that the "master" branch gets renamed or copied to "origin", but all of the other branches remain unchanged in their names. It's more logical for clone to either * leave all names unchanged * put all remote branches into a subdirectory. ...

> I claim that those "annoying little issues" are totally made up by > people > who had trouble wrapping their minds about git, and then make up > reasons > that have nothing to do with reality for why that might be so. Let me put this more personally: I continue to be bitten by stupid naming issues, and the myriad of little mostly non-orthogonal commands. My head is doing just fine otherwise, and has no problems wrapping it around the core of GIT. I've also used Darcs for...

Actually, only a 2 weeks ago, you suggested that I share the website and main source code for my project in a single repository for reasons of organization. In this setup I find it logical to do git init-db git pull ..url.. website/master to wind up with just the 5mb website, instead of the complete 70mb Yes, I would like that. -- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen -

For that we'd also need a way for clone to be able to fetch just a single branch, and not all of them as well. There is some clone vs. fetch asymmetry here that has annoyed me for a while, and that I don't think has been mentioned in this thread yet. Namely: clone: can only be executed once, fetches all branches, "remembers" URLs for later simplified use fetch: can be executed many times, fetches only named branches, doesn't remember anything for later I've often been in the...