[INTRO] Hello, I have come across a problem that could be easily addressed in order to improve interoperability between CVS and git. I'm new to using git (and a novice with SCMs in general), and I really enjoy the way that git allows me to think. Unfortunately, I am forced to deal with CVS (for one of my classes), but I have been courageously trying to use git behind the scenes, as I can already tell CVS is a nightmare. [SCENARIO] I would like to do the ...

The downside is that this causes totally unncessary conflicts when merging. Maybe a custom merge handler could deal with that, though. -

I think it might also be potentially interesting to make this just be a pre-commit hook - although your point that doing it in the editor is to some degree even nicer, because it also means that it shows up in diffs even *before* you commit. But if you want to explore the pre-commit hook approach, what it would basically boild down to is that at that point you have a list of all files that have changed, and then you could run some script on them to change them even further. I'm ...

The patches spoke. That is what the [PATCH] in the subject line was about. -- David Kastrup -

Hi Jan, Thanks! git-filter-branch looks a bit overwhelming, but I think I can manage :-) I'll do the simple things in separate conversions. Cheers --- Jan -

OK, so the version you have (58ba4) is the latest fast-import after the strbuf.c series went in. The one immediately before that series was 4bf538 and is probably actually stable. So I wonder, can you test 4bf538 and then if it is good bisect between those two commits? There must be a memory corruption introduced by one of the strbuf changes... -- Shawn. -

Hi all, I am using git 1.5.3.4.206.g58ba4-dirty on Mac OS X 10.4. When I tried to run `git-p4 rebase', it failed with a broken pipe to `git-fast-import'. I gather the following from GDB. I am kind of stuck. Does anyone have any idea what's going on? Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x64617469 in_window (win=0x5004d0, offset=3501) at sha1_file.c:701 701 off_t win_off = win->offset; (gdb) bt #0 in_window ...

Thanks for the info! It seems that I was a bit late with my proposal. ;-) /Adam -- .:. Adam Piatyszek - "ediap" .:. JID: ediap(at)jabber.org .:. .:. ediap(at)users.sourceforge.net .:. PGP key ID: 0x1F115CCB .:. -

I think its a bug. But I didn't write the original code. Meaning I think what happened here was someone wanted to enable git-send-pack to match "master" here with "refs/heads/master" on the remote side. One easy way to do that was to see if any ref ended with "/master", as that was what the ref here was called. Way back when that code was written most Git repositories probably only ever had that one branch anyway, or maybe two (refs/heads/master and refs/heads/origin) so matching the ...

This adds a test case for unambigous local match but multiple remote matches. To me, it is unexpected that a ref that is perfectly defined on the local side fails with 'matches more than one'. The following rule could solve this: A ref shall first be unambigously resolved on the local side, and its full name should be used for matching on the remote side. For example 'frotz' resolves locally to 'heads/refs/frotz'. Therefore pretend the user had typed 'heads/refs/frotz'. But maybe there is ...

No such thing here: zsh$ /bin/sh $ which getopts $ Yes, bash and zsh do have that, but my (and I suspect many git users') /bin/sh is neither of those. Git scripts should use just POSIX shell features for portability. Which is particularly important when you are trying to replace a common utility, because the systems that won't have it are likely to not have bash either. You may want to have a look at /usr/share/automake-1.9/install-sh (or /usr/share/automake<something>/install-sh). ...

The problem occurs when gmail decides to wrap the lines in the patch (max 72 chars per line, I guess). -- larsh -

<aol>mee too! - I think it's the kind of development culture that Linus tries to foster, and I suspect Junio likes too: "talk in patches" which is a lot more productive than "talk like a pirate", bikeshedding and other maladies that can fester in mailing lists. So no split for me ;-) We have the additional alibi that git users are supposed to be programmers. m -

Yes, but not embedded in the page in a format that is visible to the visitor. For CVS I use something like this: <p class="date">$Date$</p> to embed the last update time into the page. -- \\// Peter - http://www.softwolves.pp.se/ -

No? That would just be strange. Only the files that are actually changed should be updated, no others. A $Date$ or $Id$ will show the last time/commit that specific file was changed, not the latest global state (I guess the fact that most modern VCSs have global state makes this a bit more difficult to achieve, in RCS/CVS/PVCS and others the change history is local to a file and thus it is trivial to find the large change for that But that's not what I want. Then my build procedure would ...

Try this: $ echo 'File revision $Id$' > index.html $ echo "*.html ident" > .gitattributes $ git add index.html .gitattributes $ git commit From now on, the '$Id' in index.html gets expanded to the SHA1 of the content of index.html (not the commit SHA1) each time you checkout (and removed when you commit) If you still want 'last modified date', the closest thing in git is 'commit date' which you can also get for free: $ echo 'Last commit: $Format:%cd$' > index.html $ echo "*.html ...

It does not -- the blob ID is the same. And you can indeed get $Id$ expanded to that (see gitattributes(5)). However, that's the ONLY thing that is the same. The date of last modification or ID of commit that last touched that file might not. Why? Because git tracks content, not history. The trees and blobs (files) a= re identified by SHA1 hashes of their content. Only commit objects add the notion of history. Thus if two commits contain file with the same text, it's the same file. Even if ...

Hi Peter, please do not play games with the To: header. We have a policy here (which is supposed to be good netiquette) that we keep people in the Cc: list that we respond to. But don't you see? When switching branches, this totally breaks down. No, really, IMHO it is enough to show either the commit name or the blob name of the file. After all, you are not interested in the date that this file was last committed, but in the _contents_. So why not go for the contents? With ...

Exactly. When switching branches, or merging or fast-forwarding several commits, the last commit may not be correct. The last commit is only correct for the files being updated by the fast-forward to exactly one commit. Which seem to be pretty natural for the use case of checkout-only Your comment prompted me to think about a narrower case of fast-forwaring to one revision. In that case, 'smudge' script can have commit identifier in FETCH_HEAD, so the example script from previous message ...

I believe you actually wanted "git-svn fetch" here -

Thanks, I found svndumpfilter in the svn book, and gave it a try. Unfortunately it seems to be confused about files that have moved around in the repository, I was at least not able to make it dump the entire history for a directory that over time has changed name, and that contains files that have moved in from other directories. Eivind On Thu, 11 Oct 2007 15:24:59 +0200, Patrick Doyle <wpdster@gmail.com> -

Whoops, my mistake. That should have been "git svn fetch". Sam. -

Actually, reconsidering your proposed patch, there are only a handful of problematic cases, namely those where the test script is quoted with double-quotes, like this: test_expect_success 'load repository with strange names' " - svnadmin load -q $rawsvnrepo < ../t9115/funky-names.dump && + svnadmin load -q '$rawsvnrepo' < ../t9115/funky-names.dump && start_httpd " The problem is that here $rawsvnrepo will be expanded before the entire test script is passed as argument to ...

+1: especially in this case, where it really is "defensive" and not "paranoiac". Cheers, Wincent -

There exist a script contrib/workdir/git-new-workdir, which creates a new working copy that literally shares the same object store. It will share both object store and branches, so some care must be taken: branch which checkout out in one shared working directory must never be updated (committed or pulled into) from the other shared working directory. Said that, I personally find this trick very useful for browsing alternate branch code and quick bug fixing. -

Instead of simply exiting with 255, print an error message including the reason why a config file specified through --file cannot be opened or read. The problem was noticed by Joey Hess, reported through http://bugs.debian.org/445208 --- Okay. I changed the patch to die() only if --file was sepcified, and errno is not 0. Thanks, Gerrit. builtin-config.c | 8 ++++++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/builtin-config.c ...

Fair enough. Regards, Gerrit. -

When calling git-config not from the top level directory of a repository, it changes directory before trying to open the config file specified through the --file option, which then fails if the config file was specified by a relative pathname. This patch adjusts the pathname to the config file if applicable. The problem was noticed by Joey Hess, reported through http://bugs.debian.org/445208 Signed-off-by: Gerrit Pape <pape@smarden.org> --- Sure, thanks, Gerrit. builtin-config.c ...

I disagree with Alex's argument above, because the result of the pattern expansion can be NULL due to a pattern that matched nothing from the remote. This can easily happen if the user originally configured "remote.$name.fetch = +refs/heads/subdir/*:..." and then the remote deletes all branches from refs/heads/subdir at some point in the future. I think the above patch is the only thing to do here. Perhaps Alex can write up a formal patch and send it to back to the list and CC Lars Hjemli ...

Hi, Jakub, thank you very much for doing this. It is a very tedious work, and I deem it invaluable. I had the same problem, and somebody pointed me to http://ircatwork.com/cgi-bin/irc/irc.cgi I find it always a little strange how people want to use something like git, but are unwilling to ask. Is this such a big attack on the manliness Frankly, expectations like these make me want to bang somebody's head on I think it'd be a good idea to put it on git://git.kernel.org/, ...

Well, hey, we asked for suggestions. Think of it as a project someone might want to work on, rather than as a command. I don't know what they mean by "make git more task-oriented rather than data-model-oriented", but the first suggestion ("Find out why people find git hard to learn...") is certainly something I'd enjoy working on if I found the time. --b. -

I'm neither too. But I don't think Git is in a niche. OK, well, in the overall world of software development its certainly in the niche of version control, as uh, it doesn't do Enterprise Resource Planning and Large Scale Embezzlement of Monies (ERPaLSEM). Actually I've seen a number of people on the interweb saying things like they were switching their project to Git because they felt it had more staying power than say Monotone or Mercurial, partly because the kernel devs were actively ...

https://gna.org/bugs/?group=stgit. All of them, if possible :-). If you happen to work on any of them, change the "assigned to" filed so that we don't duplicate the effort. -- Catalin -