GIT(7) -- 03/05/2007 NAME git - the stupid content tracker Well, I use git for tracking contents. That means, for example, installation trees for some application. Let's take a typical TeXlive tree as an example. Those trees contain, among other things, directories where new fonts/formats/whatever get placed as things run. Quite a few of them start out empty, but their permissions have to correspond to their purpose (for example, some are world-writable). I see little chance to get th...

,----[ http://www.spinics.net/lists/git/msg30730.html ] | From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> | | I wouldn't personally mind if somebody taught git to just track empty | directories too. | | There is no fundamental git database reason not to allow them: it's in | fact quite easy to create an empty tree object. The problems with | empty directories are in the *index*, and they shouldn't be | insurmountable. | | [...] `---- -- Matthieu -

The fact that browsers behave this way is of course a bug, but it's a common one. Can we switch the documentation over to UTF-8, this is 2007 after all...? -hpa -

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> --- builtin-fetch.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/builtin-fetch.c b/builtin-fetch.c index 2f24c22..f1045ac 100644 --- a/builtin-fetch.c +++ b/builtin-fetch.c @@ -381,7 +381,10 @@ static int do_fetch(struct transport *transport, } } - fetch_refs(transport, ref_map); + if (fetch_refs(transport, ref_map)) { + free_refs(ref_map); + return 1; + } fetch_map = ref_...

The transport specific stuff was moved into libgit.a, and the bundle specific stuff will not be left behind. This is a big code move, with one exception: the function unbundle() no longer outputs the list of refs. You have to call list_bundle_refs() yourself for that. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> --- FWIW this patch series is based on the bf_series branch of git://iabervon.org/~barkalow/git.git, revision a204e4b4. Makefile | 2 +- b...

Actually, I ended up touching this up a tiny bit, too: I ordered the functions in bundle.c the way they were in builtin-bundle.c (so that the patch is more trivial) and removed the blank lines at the end of the file. This makes the "git diff -C" output really obvious. (Someday, I'd like to have a diff that can show that a substantial block of '+' lines matches a block of lines from somewhere in the "before" content, so reviewers can verify that the patch reorders code but doesn't change it...

Cygwin's Tcl is configured to honor any occurence of ctrl-z as an end-of-file marker, while some commits in the git repository and possibly elsewhere include that character in the commit comment. This causes gitk ignore commit history following such a comment and incorrect graphs. This change affects only Windows as Tcl on other platforms already has eofchar == {}. This fixes problems noted by me and by Ray Lehtiniemi, and the fix was suggested by Shawn Pierce. Signed-off-by: Mark Levedahl <mdl1...

Wouldn't it be nicer to avoid a lot of the complexity in checking symlinks, environment variables and what not, and just overwrite the file in place (with open(..., O_TRUNC | O_CREAT))? Does it happen terribly often that git-config crashes in the middle and leaves the file broken? Fredrik Tolf -

Hi, I think current gitweb generates invalid XHTML when get_file_owner returns a string containing <>&. (Version 1.5.2.1 certainly does, and in a quick browse of current source I didn't notice relevant changes.) Here is a dirty patch to fix this problem. Apologies if it is no longer a problem or if the patch is gross. Thanks, Eddie (newbie)

In particular, when moving back to a commit without a given submodule and then moving back forward to a commit with the given submodule, we shouldn't complain that updating would lose untracked file in the submodule, because git currently does not checkout subprojects during superproject check-out. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> --- I'm not sure if t7400-submodule-basic is the best place for the test, but it has the right context for the test. skimo t/t7400-submo...

Hi, IMHO this is a good change. Encodings are such a hassle, and probably only because the inventors of ASCII just were narrow-minded enough not to care. With this patch, the hassle factor diminishes AFAICT. Ciao, Dscho P.S.: I think that in case of undesired behaviour, even if it is detected late in the game, filter-branch/rewrite-commits will help. -

Changed filter for username in svn-authors file, so even 'user name' is accepted. --- git-svn.perl | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/git-svn.perl b/git-svn.perl index 01c3904..975075e 100755 --- a/git-svn.perl +++ b/git-svn.perl @@ -740,7 +740,7 @@ sub load_authors { my $log = $cmd eq 'log'; while (<$authors>) { chomp; - next unless /^(\S+?|\(no author\))\s*=\s*(.+?)\s*<(.+)>\s*$/; + ...

By the analogy with the maxtime and maxmount in the ext3 when it reminds you to fsck, when number of mounts since last fsck, or time since last fsck is above some limits. I think this makes practical sense. I think the similar thing makes sense wrt to 'git gc'. Is it possible that git repo had a parameter N, and when the counter of unpacked object hit this number, then git operations start to print semi-annoying warnings "Time to optimize your repo using 'git gc' command ... " ? I am nai...

Hi! I was trying to do a git bisect on 2.6.22-git6 and 2.6.22-git8. For which I get following error : root@amit:/usr/src/linux-git # git bisect good v2.6.22-git6 Bad rev input: v2.6.22-git6 The repository is obtained by : root@amit:/usr/src # git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 linux-git I am running following git version on Debian Sid, updated today. # git --version git version 0.99.8.GIT '# dpkg -l | grep git' shows ' git-core 1:1.5.2.3-1' I tri...

Thanks a ton everyone for all the replies. Here is the current status : Ren

you seem to be missing a "git bisect start" from that sequence ... see the= =20 man page for more details. --=20 Julian --- Peter Griffin: You wanna talk about awkward moments? Once, during sex, I c= alled Lois "Frank". Your move, Sherlock.

The -git# is added by a script and does not exists as tags. The same place where you retreive the -git files has a file identifying the commit that is the latest - use the SHA of this and you should be happy. Sam -

Hi, Thanks for both the replies. This struck me as being weird, but I thought 'git' utility version is I didn't build my own git version. What I did do was to remove the old git and ensure I am using the Debian installed one. Now I am getting a different error : root@amit:/usr/src/linux-git # which git /usr/bin/git root@amit:/usr/src/linux-git # git --version git version 1.5.2.3 root@amit:/usr/src/linux-git # git bisect good v2.6.22-rc6 root@amit:/usr/src/linux-git # git bisect bad v2.6.22-...

There is a very old GIT version in your PATH (version 0.99*), which -Peter -

After first doing a "git fetch", to update your local view of those remote branches: Commits on your current branch, not in origin: git diff origin..HEAD Commits in the origin branch, not in your current branch (so this is what you'd probably get if you pulled): git diff HEAD..origin Commits in either one, not in the other (the union of the above two): git diff HEAD...origin The "HEAD" is actually optional in all the above. And, finally, I think gitk HEAD...origin gives...

Guilt v0.26 is available for download (once it mirrors out on kernel.org). Guilt (Git Quilt) is a series of bash scripts which add a Mercurial queues-like functionality and interface to git. Tarballs: http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/ Git repo: git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git Although there was a v0.26-rc1 release, I never announced it so the following summary includes all the changes since v0.25. Unfortunately, it took two months t...

I have a machine on which git was installed from a tarball created by running git-archive on master (so a 1.5.3ish version). When I try running git-gui I get an error message: 'Error in startup script: expected version number but got "1.5.3.GIT"' followed by what I assume is a code snippet where it failed (I wouldn't know tcl if it hit me with a large brick). Is this expected? driver error? or maybe a bug? -- Julian --- mixed emotions: Watching a bus-load of lawyers plunge off ...

Many thanks for the fix. I was about to do this myself but found your message in my inbox instead. Happy days. Fortunately git-am -3 does wonders, and it didn't matter: $ git am -s -3 jp Applying git-gui: Handle git versions of the form n.n.n.GIT error: git-gui/git-gui.sh: does not exist in index Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Renamed git-gui/git-gui.sh => git-gui.sh Wrote tree 1909733645c3bd167b1b28...

I think we are now cleaning up the Git version as best we can: regsub -- {-dirty$} $_git_version {} _git_version regsub {\.[0-9]+\.g[0-9a-f]+$} $_git_version {} _git_version regsub {\.rc[0-9]+$} $_git_version {} _git_version regsub {\.GIT$} $_git_version {} _git_version The first fixes the -dirty build problem. The second drops off the extra information that git-describe throws into the mix when it generates output for a non-tagged commit. The third kills the rc* component if this ...

Already fixed. Please get the latest version of git-gui... -- Shawn. -