The .git/brances directory is actually a piece of cogito infrastructure that git creates, and is only there to prevent cogito falling over. Signed-off-by: Kristian Høgsberg <krh@redhat.com> --- I think it's time to drop this confusing directory from the .git template. If not for 1.5.x, let's at least schedule it for 1.6.0. cheers, Kristian templates/branches-- | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) delete mode 100644 templates/branches-- diff --git a/templat...

Done some digging with cvsps itself and it looks like the lbdb.py,v file has become corrupted from a very early version... Is there a way that I can tell git to ignore the early revisions? Cheers Adam --

Sure, what I mean is that you checkout a branch, the workspace reflects the state of that branch. If you do a build in the workspace, the build artifacts match up with the source that's in the workspace. If you then checkout a new branch, it's unlikely that the source reflects the build artifacts any more. Here's how we did it in CVS. Any feature or defect got it's own branch, no matter how trivial it was (yes, it was very painful with CVS, but the benefits outweighed the pain. Moving to Git is...

Personally, I'd clone a local rep for each build, with the -s option to clone. Something like: git clone server:/rep ~/master git clone -s ~/master build/abc git clone -s ~/master build/foo =2E.. The -s option should reduce disk-usage considerably. --=20 Luciano Rocha <luciano@eurotux.com> Eurotux Inform=E1tica, S.A. <http://www.eurotux.com/>

Yes, that's precisely what we want to do. So according to your Cheers, Craig --

Thanks for the feedback, it's making me think about the problem ;-) Cheers, Craig --

OK. Will submit a patch later today. -- Heikki Orsila heikki.orsila@iki.fi http://www.iki.fi/shd --

Hello! When using git-cherry-pick there are two things missing for me and just wondered how you see it (or maybe have a good solution): - Apply only parts of the patch which applies to <file ...>: I sometimes want to apply patches only to some, but not all files the patch introduces - Interactively selecting which parts to apply: I want only 7 out of 10 changes the patch introduces. It would help alot, if I could choose which parts I want to apply for every part of the pa...

The patterns to the case statement could never be matched, so the hook was a noop. This patch also replaces the non-portable use of in-place sed. Signed-off-by: Marcel Koeppen <git-dev@marzelpan.de> --- templates/hooks--prepare-commit-msg | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/templates/hooks--prepare-commit-msg b/templates/hooks--prepare-commit-msg index ff0f42a..d3c1da3 100644 --- a/templates/hooks--prepare-commit-msg +++ b/templates/hooks--prepa...

You can skip the whole merge-foo thing and just merge local-foo into local-trunk, the second merge would end-up as a fast-forward anyway. That said, the above should work, given that a) you don't do any rebasing after merging and b) the merge commit is the first commit that gets dcommitted to svn. I don't remember what happens when there are new revisions in svn since you last ran "git svn rebase", so you might want to try that case on a throw-away svn repo first. What SVN will see is basica...

Hi there It seems that negating path patterns in gitignore doesn't work, or I don't understand it (or both). With the attached script, git status (1.5.5.1) reports "dir/a" as new and "dir/b" as untracked. I would rather expect it to report "dir/c" as untracked also. It seems that "!b" matches to include "dir/b" (reverting the exclusion "*" as expected), whereas "!dir/" does not match to include "dir/c". What's going on here? Michael P.S.: "*" in dir/.gitignore would do what I want, bu...

That the change was committed to the "master" branch, and not the "maint" branch. So folks who run stable releases haven't seen the bug yet. -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle --

When rebasing fails during "pull --rebase", you cannot just clean up the working directory and call "pull --rebase" again, since the remote branch was already fetched. Therefore, die early when the working directory is dirty. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> --- git-pull.sh | 5 +++++ t/t5520-pull.sh | 18 ++++++++++++++++++ 2 files changed, 23 insertions(+), 0 deletions(-) diff --git a/git-pull.sh b/git-pull.sh index bf0c298..9a9e764 100755 ...

Perhaps the "up-to-date" should be changed to something else, following the recent discussion about the "up-to-date" message in checkout (but here we don't have to worry about breaking anything else). In that case, I'd suggest: "Refusing to pull with rebase: your working tree has uncommitted changes" -- Best regards Jan Krüger <jk@jk.gs> --

I haven't followed the codepath but what do the callers do to the string returned from chop_str? Don't they assume the string hasn't been decoded (because the old implementation of chop_str did not do this to_utf8), and emit the result directly to the output because it also assumes the undecoded format is what the outside world wants? In other words, don't they now need to do different things because returned string has gone through the to_utf8() processing already? Maybe I am worrying too much...

Yeah, that is a very good explanation. Thanks for a constructive suggestion for improvements. Here is an incremental on top of the one I sent out, in case people want to improve on it. unpack-trees.c | 12 ++++++++++-- 1 files changed, 10 insertions(+), 2 deletions(-) diff --git a/unpack-trees.c b/unpack-trees.c index da3bdc8..0de5a31 100644 --- a/unpack-trees.c +++ b/unpack-trees.c @@ -8,7 +8,15 @@ #include "progress.h" #include "refs.h" -static struct unpack_trees_error_msgs ...

Hi list, Saw this this morning, http://google-opensource.blogspot.com/2008/05/develop-with-git-on-google-code-project.... You can't beat a bit of exposure! -- Peter Farmer --

I've promoted a bunch of stuff from "experimental" to "safe", so that "experimental" currently only consists of the stack log stuff. The stack log stuff in experimental now sports a rewrite of "stg log", so that you can see what's in your log. This work is nearing completion, or at least nearing the point where I'll be considering moving it to "safe". -+- The following changes since commit 9564af74822b276d435319fc271eda591e5125a6: Catalin Marinas (1): ...

Fix chop_str not to cut in middle of utf8 multibyte chars. Without this fix at least author name in short log may cut in middle of a multibyte char. When the result comes to esc_html to_utf8 is called again, which doesn't find valid utf8 and decodes using $fallback_encoding making it even worse. This also have the nice side effect that it actually tries to show the first 10 _characters_, not the number of characters that happened to fit into 10 bytes. Signed-off-by: Anders Waldenborg <anders@...

Yeah, also a lot of people have CVS installed from when they used it, but they not use something different, but haven't built new computers without I think that around 05-2007, a lot more people started voting, largely non-coders, but also coders. In the percentage, there's a sharp drop where that sharp rise is. -Daniel *This .sig left intentionally blank* --

I have been using RCS for local version control (like in my /etc directory), when I did not want to involve a CVS server. I find that Git does that job much better, so I am switching to Git there as well. Very nice :-) The graphs are all missing "cvsnt", which does replace the cvs package if installed. But even if added, cvs is still losing market share. -- \\// Peter - http://www.softwolves.pp.se/ --

On Wed, May 21, 2008 at 4:06 PM, Linus Torvalds Heh. And trim it to start on 2005-7-12 - the date of the first debian package for it. Makes the graph more interesting. Do I confess I added tla to the list too? Some things in my past I rather not talk about... cheers, m -- martin.langhoff@gmail.com martin@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff --...

Actually, if we define the "market" to be DSCM, and the timeframe to be existence of the git-core package, this graph of installs is quite useful: Maybe git-archimport has made a dent? ;-) http://tinyurl.com/5okewp cheers, m -- martin.langhoff@gmail.com martin@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff --

Diff+tar+patch should be counted too. http://tinyurl.com/3frawy Seems far more popilar than anything else added together, including cvs and other subversive systems. -- robin --

Yes, tar and diff are in every Debian system and can't be casually removed: $ aptitude remove tar [...] WARNING: Performing this action will probably cause your system to break! Do NOT continue unless you know EXACTLY what you are doing! To continue, type the phrase "I am aware that this is a very bad idea": --