* [PATCH 0/3] Add a pretty format to rewrapping/indenting commit messages
From: Johannes Schindelin @ 2009-09-23 20:34 UTC (permalink / raw)
To: Git Mailing List; +Cc: Johannes Gilger, Junio C Hamano
In-Reply-To: <1253655038-20335-1-git-send-email-heipei@hackvalue.de>
I needed that a long time ago, so I implemented it and let it rut in my
personal tree.
Maybe somebody else wants to benefit from my work, too.
Johannes Schindelin (3):
print_wrapped_text(): allow hard newlines
Add strbuf_add_wrapped_text() to utf8.[ch]
Add "%w" to pretty formats, which rewraps the commit message
Documentation/pretty-formats.txt | 1 +
pretty.c | 27 ++++++++++++++++++++++
utf8.c | 45 ++++++++++++++++++++++++++++++-------
utf8.h | 2 +
4 files changed, 66 insertions(+), 9 deletions(-)
^ permalink raw reply
* Re: Feature Enhancement Idea.
From: Junio C Hamano @ 2009-09-23 20:08 UTC (permalink / raw)
To: Deon George; +Cc: git
In-Reply-To: <5b5e291e0909222317q47ae36d4la470f17ec3902124@mail.gmail.com>
Deon George <deon.george@gmail.com> writes:
> Like I mentioned, I can achieve some of this by the use of branches
> already, however, where it comes complicated, is when:
> * I commit a change to the wrong branch (and thus upstream will never
> see my enhancements),
> * I want to identify changes to one layer (that I went to send to
> upstream for review), without including the other layers (because it
> probably isnt relevant)
> * I want to work on more than one layer (I need to be diligent about
> pulling and merging)
I think you are getting ahead of yourself by coming up with "layers" as a
solution, without really spelling out and then thinking through what
problem you are trying to solve.
I think the primary scenario your itch comes from is (I am writing this
down to make sure I understand where you are trying to go):
- you would want to build your changes on top of somebody else's code;
- while doing so it is often more convenient if you do not have to think
about which pieces of changes should go to upstream, and which other
pieces of changes should stay local;
- git allows you to do this with topic branch workflow, with selective
adding with "add -p", stashing and branch switching.
- You can however misidentify which bits should go to upstream and commit
to a wrong branch. You want to reduce the chance of this mistake.
Am I following you Ok so far?
Now, how does "layers" (I understand by this word you mean the concept of
"layering a worktree from one branch on top of layering a worktree from
another") solve that problem? If you come up with a nice way to identify,
and have the tool help you identify, "these bits belong to that layer",
wouldn't that approach also apply to existing topic branch workflow by
having the same logic of that magic tool to help you say "these bits
should go to that topic branch"?
When the granularity of the change is per-file (your "autonomous" case),
"git checkout" to switch back to your topic would already solve half of
that issue.
Suppose you have mainline (origin/master) and your customization topic
(custom), and file F is something that does not and will never exist in
the mainline. You use your master branch as your integration testing
branch. With traditional topic branch workflow, you would
$ git checkout custom
... work on F and other files, test the changes to your satisfaction
$ git commit -m 'I am satisfied on my custom work'
$ git checkout master
$ git rebase origin/master ;# keep up with the upstream
$ git cherry-pick ... ;# some commits in custom that should go to upstream
$ git merge custom ;# test merge to be thrown away!
... now you are on the integrated result in 'master'.
... test, notice breakages in F, and edit it to improve it
... the changes to F belongs to 'custom', not for upstream!
$ git checkout custom ;# this will take the changes to F with you
$ git commit -m 'I should have done this to F instead' F
... go back to do more work
$ git checkout master
... loop forever ;-)
and after you are satisfied, you would reset the merge from custom away
and offer the master that is combination of what was in the origin/master
plus the "upstream worthy" bits you cherry-picked ones from your custom
branch.
When the granularity is sub-file, "checkout -m custom" or "stash, checkout
custom, then unstash" would help carrying the changes across branches.
You would need to identify which changes you would want to commit to
"custom" and which changes you would want to give to upstream by making a
commit on "master" when you go back there again. The middle part of the
above workflow will be slightly modified for a file G that is shared
between origin/master and custom branches, perhaps something like:
... now you are on the integrated result in 'master'.
... test, notice breakages in G, and edit it to improve it
... the changes to G belongs to 'custom', not for upstream!
$ git checkout -m custom ;# this will take the changes to G with you
$ git add -p G ;# pick changes that only belong to custom
$ git commit -m 'I should have done this to G instead'
If the "layers" logic somehow can help you automate the process of sifting
your changes into these two categories (perhaps it may scan the file and
knows which function belongs to "custom" alone, I dunno and care about the
details at this level of discussion), wouldn't that same logic help you
the same way?
Past attempts that made into the toolchest are "add -p" (and "stash -p"
that uses the same mechanism) which is interactive and not automated.
Maybe you can build some logic to automate it further (e.g. "changes to
this function should automatically be excluded from "git add" while on
'master', but should automatically be included in "git add" while on
'custom'), and it may turn out be a good addition to the toolchest.
It also may make a good addition to the toolchest to have a tool to
further simplify the branch switching explicitly initiated by the end user
in the above illustrations. In some cases, such as the "autonomous" case
above, you do not _have_ to go back to custom branch from the work-flow
point of view (you would be committing a totally untested work to custom
branch, but as long as you will revisit and retest the changes in its
context, it is not a major crime at all). It would be useful if you can
say, while still on 'master' branch, "I just made this fix to file F that
belongs to 'custom'; commit that change alone to 'custom' branch".
Written as a shell script, roughly, it would look something like:
#!/bin/sh
target_branch="$1"
base=$(git rev-parse --verify "$target_branch") || exit
shift ;# all others are paths
GIT_INDEX_FILE=.git/temp
export GIT_INDEX_FILE
git read-tree -m "$1"
git add "$@"
c=$(echo "side commit" | git commit-tree $(git write-tree) -p "$base")
git update-ref "refs/heads/$target_branch" "$c"
But I do not see how the concept of "layering a worktree from one branch
on top of layering a worktree from another", which is the implication I
get from the word "git layers", helps any of that. It seems an orthogonal
concept that we can do without to solve the problem you are describing.
^ permalink raw reply
* Re: git-cvsimport: missing branches
From: Heiko Voigt @ 2009-09-23 19:51 UTC (permalink / raw)
To: Reto Glauser; +Cc: git, Matthias Urlichs, mhagger
In-Reply-To: <4ABA5C5C.2060207@blinkeye.ch>
On Wed, Sep 23, 2009 at 07:35:24PM +0200, Reto Glauser wrote:
> - Is the problem in cvsps or git-cvsimport or in the CVS history?
It is very likely a problem of cvsps. I have collected a couple of tests
illustrating the current limitations:
http://repo.or.cz/w/cvsps-hv.git
Interested in fixing some of them ?
> - Can I use the cvs2git import as a starting point and later use
> git-cvsimport for incrementally update the git repository?
Unfortunately there is no robust incremental tool for cvs at the moment.
As soon as you get your colleagues to use git the pain just dissapears ;)
> - Can I somehow compare the result of git-cvsimport and cvs2git to see
> differences?
How about a plain diff between the directory structures.
> - Is there any other feasible workflow to stay in sync with a CVS
> repository with a large history while still using git behind the scene?
During the transition phase I used to track the old system with a
seperate branch. Everytime you get an update from CVS you simply
commit it to that branch. Its important that you do not mix this branch
with your development. You do not do any work on it just commit the
clean revision like you get them from the server.
I then used feature branches for the work which I rebased regularly.
Once you want to merge a branch comes the hard part:
A:
* Update the tracking branch from CVS
* Merge the first/next commit from the branch in git
* Commit to cvs and copy the commit message
* Goto A:
Maybe for cvs you can script this. You can also merge the whole branch at
once if you are lazy but then the diffs will not be nice when you later
completely migrate to git.
cheers Heiko
^ permalink raw reply
* Re: [BUG?] git-cvsimport: path to cvspsfile
From: Jeff King @ 2009-09-23 19:14 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt
In-Reply-To: <20090923182756.GA12430@onyx.camk.edu.pl>
On Wed, Sep 23, 2009 at 08:27:56PM +0200, Kacper Kornet wrote:
> When I use:
>
> git cvs-import -C <dir> -P <cvspsfile>
>
> it looks for <cvpsfile> relative to <dir>, not the working directory.
> Is it a bug or a feature?
Bug. The script does a chdir() and then looks at the cvspsfile later. I
think "-A" would have the same problem. Here is a totally untested patch
to address the issue. Johannes, will this is_absolute_path actually work
on Windows? I think The Right Way would be to use
File::Spec::file_name_is_absolute, but I haven't checked whether that is
part of core perl and if so, which version it appeared in.
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 1ad20ac..08a30ec 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -579,10 +579,26 @@ sub get_headref ($) {
return $r;
}
+sub is_absolute_path {
+ local $_ = shift;
+ return m{^/};
+}
+
+my $user_filename_prepend = '';
+sub munge_user_filename {
+ my $name = shift;
+ return is_absolute_path($name) ?
+ $name :
+ $user_filename_prepend . $name;
+}
+
-d $git_tree
or mkdir($git_tree,0777)
or die "Could not create $git_tree: $!";
-chdir($git_tree);
+if ($git_tree ne '.') {
+ $user_filename_prepend = getwd() . '/';
+ chdir($git_tree);
+}
my $last_branch = "";
my $orig_branch = "";
@@ -644,7 +660,7 @@ unless (-d $git_dir) {
-f "$git_dir/cvs-authors" and
read_author_info("$git_dir/cvs-authors");
if ($opt_A) {
- read_author_info($opt_A);
+ read_author_info(munge_user_filename($opt_A));
write_author_info("$git_dir/cvs-authors");
}
@@ -679,7 +695,7 @@ unless ($opt_P) {
$? == 0 or die "git-cvsimport: fatal: cvsps reported error\n";
close $cvspsfh;
} else {
- $cvspsfile = $opt_P;
+ $cvspsfile = munge_user_filename($opt_P);
}
open(CVS, "<$cvspsfile") or die $!;
^ permalink raw reply related
* [BUG?] git-cvsimport: path to cvspsfile
From: Kacper Kornet @ 2009-09-23 18:27 UTC (permalink / raw)
To: git
Hi,
When I use:
git cvs-import -C <dir> -P <cvspsfile>
it looks for <cvpsfile> relative to <dir>, not the working directory.
Is it a bug or a feature?
Best wishes,
--
Kacper
^ permalink raw reply
* [PATCH] fix testsuite to not use any hooks possibly provided by source
From: Heiko Voigt @ 2009-09-23 18:30 UTC (permalink / raw)
To: git
This is useful if you are using the testsuite with local changes that
include activated default hooks suitable for your teams installation.
In some cases the pre-commit or other hooks can prevent the testsuite
from getting the expected result.
Currently all example hooks in the main git repository are deactivated
so it makes no difference when running the testsuite without any. In
case a future testcase wants to test a default hooks behavior it should
copy it locally.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
or would you say that we need hooks in the testsuite template?
t/test-lib.sh | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index f2ca536..446ab57 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -626,7 +626,7 @@ else
GIT_EXEC_PATH=$GIT_VALGRIND/bin
export GIT_VALGRIND
fi
-GIT_TEMPLATE_DIR=$(pwd)/../templates/blt
+GIT_TEMPLATE_DIR=$(pwd)/trash\ directory.templates
unset GIT_CONFIG
GIT_CONFIG_NOSYSTEM=1
GIT_CONFIG_NOGLOBAL=1
@@ -638,6 +638,11 @@ test -d ../templates/blt || {
error "You haven't built things yet, have you?"
}
+test -d "$GIT_TEMPLATE_DIR" || {
+ cp -r ../templates/blt "$GIT_TEMPLATE_DIR"
+ rm -f "$GIT_TEMPLATE_DIR"/hooks/*
+}
+
if ! test -x ../test-chmtime; then
echo >&2 'You need to build test-chmtime:'
echo >&2 'Run "make test-chmtime" in the source (toplevel) directory'
--
1.6.5.rc1.12.gc72fe
^ permalink raw reply related
* [PATCH] Documentation - pt-BR.
From: Thiago Farina @ 2009-09-23 18:25 UTC (permalink / raw)
To: git; +Cc: Thiago Farina
Translate some english words to portuguese and fix some typos on translation.
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
Documentation/pt_BR/gittutorial.txt | 22 +++++++++++-----------
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/Documentation/pt_BR/gittutorial.txt b/Documentation/pt_BR/gittutorial.txt
index 81e7ad7..6fb396a 100644
--- a/Documentation/pt_BR/gittutorial.txt
+++ b/Documentation/pt_BR/gittutorial.txt
@@ -1,15 +1,15 @@
gittutorial(7)
==============
-NAME
+NOME
----
gittutorial - Um tutorial de introdução ao git (para versão 1.5.1 ou mais nova)
-SYNOPSIS
+SINOPSE
--------
git *
-DESCRIPTION
+DESCRIÇÃO
-----------
Este tutorial explica como importar um novo projeto para o git,
@@ -64,11 +64,11 @@ Git irá responder
Initialized empty Git repository in .git/
------------------------------------------------
-Você agora iniciou seu diretório de trabalho--você deve ter notado um
-novo diretório criado, com o nome de ".git".
+Agora que você iniciou seu diretório de trabalho, você deve ter notado que um
+novo diretório foi criado com o nome de ".git".
A seguir, diga ao git para gravar um instantâneo do conteúdo de todos os
-arquivos sob o diretório corrente (note o '.'), com 'git-add':
+arquivos sob o diretório atual (note o '.'), com 'git-add':
------------------------------------------------
$ git add .
@@ -126,8 +126,8 @@ mudanças com:
$ git commit
------------------------------------------------
-Isto irá novamente te pedir por uma mensagem descrevendo a mudança, e,
-então, gravar a nova versão do projeto.
+Ao executar esse comando, ele irá te pedir uma mensagem descrevendo a mudança,
+e, então, irá gravar a nova versão do projeto.
Alternativamente, ao invés de executar 'git-add' antes, você pode usar
@@ -143,7 +143,7 @@ idéia começar a mensagem com uma simples e curta (menos de 50
caracteres) linha sumarizando a mudança, seguida de uma linha em branco
e, então, uma descrição mais detalhada. Ferramentas que transformam
commits em email, por exemplo, usam a primeira linha no campo de
-cabeçalho Subject: e o resto no corpo.
+cabeçalho "Assunto:", e o resto no corpo.
Git rastreia conteúdo, não arquivos
----------------------------
@@ -155,7 +155,7 @@ usado tanto para arquivos novos e arquivos recentemente modificados, e
em ambos os casos, ele tira o instantâneo dos arquivos dados e armazena
o conteúdo no Ãndice, pronto para inclusão do próximo commit.
-Visualizando história do projeto
+Visualizando a história do projeto
-----------------------
Em qualquer ponto você pode visualizar a história das suas mudanças
@@ -165,7 +165,7 @@ usando
$ git log
------------------------------------------------
-Se você também quer ver a diferença completa a cada passo, use
+Se você também quiser ver a diferença completa a cada passo, use
------------------------------------------------
$ git log -p
--
1.6.5.rc1.44.ga1675
^ permalink raw reply related
* Re: Feature Enhancement Idea.
From: Ciprian Dorin, Craciun @ 2009-09-23 18:17 UTC (permalink / raw)
To: Deon George; +Cc: Johan Herland, git
In-Reply-To: <5b5e291e0909230412r3ce143abgd990c36e27736bae@mail.gmail.com>
On Wed, Sep 23, 2009 at 2:12 PM, Deon George <deon.george@gmail.com> wrote:
> 2009/9/23 Johan Herland <johan@herland.net>:
>> Have a look at git submodules ('git help submodule'), or the git-subtree
>> script that has been discussed on this list a couple of times [1].
>
> git submodule looks like it will do a little of what I want - I'll do
> some more reading on it to see exactly how it works. Thanks for the
> tip.
>
> My initial look at it seems to miss an important feature that my layer
> idea would provide. It looks like git submodule assumes that
> everything in a subdirectory belongs to a repository - with my layer
> idea, I would want any layer to share the same directory structure and
> files (or content) belonging to a distinct layer's repository.
>
> IE:
> the base might provide
> plugins
> plugins/README
> modules
> modules/README
> lib/common.php
>
> and a layer might provide
> plugins/a.php
> modules/a.php
> lib/a.php
>
> another layer might provide
> plugins/b.php
> modules/b.php
> lib/b.php
>
> If I was a C developer, I'd have a go at creating it - but I'm just a
> php developer :)
> ...deon
Practically you want something like unionfs [1] but for git. Right?
But probably you could settle for something like Hg Queues [2]. Is
there similar for Git?
Ciprian Craciun.
[1] http://en.wikipedia.org/wiki/UnionFS
[2] http://mercurial.selenic.com/wiki/MqExtension
^ permalink raw reply
* git-cvsimport: missing branches
From: Reto Glauser @ 2009-09-23 17:35 UTC (permalink / raw)
To: git; +Cc: Matthias Urlichs, mhagger
Hello
I need to use CVS with a history of about 20 years (someway back it was
converted from SCCS to CVS). I have to stay in sync with the CVS
repository to import changes from co-workers and to eventually commit
changes back. I do have access to the RCS ',v' files.
So, git-cvsimport is exactly what I was looking for. Except, if I do a
git-cvsimport I have a couple of branches missing, and I don't know why.
I see the branch names from cvsps in the output, but somehow
git-cvsimport skips them anyway. I tried to add a branch manually which
got mit a couple of years of history back, but then it stops anyway.
I used cvs2git from http://cvs2svn.tigris.org which shows me these
missing branches.
So, my questions are:
- Is the problem in cvsps or git-cvsimport or in the CVS history?
- Can I use the cvs2git import as a starting point and later use
git-cvsimport for incrementally update the git repository?
- Can I somehow compare the result of git-cvsimport and cvs2git to see
differences?
- Is there any other feasible workflow to stay in sync with a CVS
repository with a large history while still using git behind the scene?
Any pointers appreciated.
Regards,
Reto
^ permalink raw reply
* [JGIT PATCH 2/2] added some tests for config param logAllRefUpdates
From: Halstrick, Christian @ 2009-09-23 16:45 UTC (permalink / raw)
To: Shawn O. Pearce, Robin Rosenberg; +Cc: git@vger.kernel.org
From: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
---
.../tst/org/spearce/jgit/lib/ReflogConfigTest.java | 111 ++++++++++++++++++++
1 files changed, 111 insertions(+), 0 deletions(-)
create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/lib/ReflogConfigTest.java
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/ReflogConfigTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/ReflogConfigTest.java
new file mode 100644
index 0000000..0e696a0
--- /dev/null
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/ReflogConfigTest.java
@@ -0,0 +1,111 @@
+/*
+ * Copyright (C) 2009, Christian Halstrick, Matthias Sohn, SAP AG
+ *
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials provided
+ * with the distribution.
+ *
+ * - Neither the name of the Git Development Community nor the
+ * names of its contributors may be used to endorse or promote
+ * products derived from this software without specific prior
+ * written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+package org.spearce.jgit.lib;
+
+import java.io.IOException;
+
+public class ReflogConfigTest extends RepositoryTestCase {
+ public void testlogAllRefUpdates() throws Exception {
+ long commitTime = 1154236443000L;
+ int tz = -4 * 60;
+ assertFalse(db.getConfig().getCore().isLogAllRefUpdates());
+ assertTrue("Reflog for HEAD should be empty", db.getReflogReader(
+ Constants.HEAD).getReverseEntries().size() == 0);
+
+ // do one commit and check that reflog size is 0: no reflogs should be
+ // written
+ final Tree t = new Tree(db);
+ addFileToTree(t, "i-am-a-file", "and this is the data in me\n");
+ commit(t, "A Commit\n", new PersonIdent(jauthor, commitTime, tz),
+ new PersonIdent(jcommitter, commitTime, tz));
+ commitTime += 100;
+ assertTrue(
+ "Reflog for HEAD should contain one entry",
+ db.getReflogReader(Constants.HEAD).getReverseEntries().size() == 0);
+
+ // set the logAllRefUpdates parameter to true and check it
+ db.getConfig().setBoolean("core", null, "logAllRefUpdates", true);
+ assertTrue(db.getConfig().getCore().isLogAllRefUpdates());
+
+ // do one commit and check that reflog size is 1
+ addFileToTree(t, "i-am-another-file", "and this is other data in me\n");
+ commit(t, "A Commit\n", new PersonIdent(jauthor, commitTime, tz),
+ new PersonIdent(jcommitter, commitTime, tz));
+ commitTime += 100;
+ assertTrue(
+ "Reflog for HEAD should contain one entry",
+ db.getReflogReader(Constants.HEAD).getReverseEntries().size() == 1);
+
+ // set the logAllRefUpdates parameter to false and check it
+ db.getConfig().setBoolean("core", null, "logAllRefUpdates", false);
+ assertFalse(db.getConfig().getCore().isLogAllRefUpdates());
+
+ // do one commit and check that reflog size is 2
+ addFileToTree(t, "i-am-anotheranother-file",
+ "and this is other other data in me\n");
+ commit(t, "A Commit\n", new PersonIdent(jauthor, commitTime, tz),
+ new PersonIdent(jcommitter, commitTime, tz));
+ assertTrue(
+ "Reflog for HEAD should contain one entry",
+ db.getReflogReader(Constants.HEAD).getReverseEntries().size() == 2);
+ }
+
+ private void addFileToTree(final Tree t, String filename, String content)
+ throws IOException {
+ FileTreeEntry f = t.addFile(filename);
+ writeTrashFile(f.getName(), content);
+ t.accept(new WriteTree(trash, db), TreeEntry.MODIFIED_ONLY);
+ }
+
+ private void commit(final Tree t, String commitMsg, PersonIdent author,
+ PersonIdent committer) throws IOException {
+ final Commit commit = new Commit(db);
+ commit.setAuthor(author);
+ commit.setCommitter(committer);
+ commit.setMessage(commitMsg);
+ commit.setTree(t);
+ ObjectWriter writer = new ObjectWriter(db);
+ commit.setCommitId(writer.writeCommit(commit));
+
+ int nl = commitMsg.indexOf('\n');
+ final RefUpdate ru = db.updateRef(Constants.HEAD);
+ ru.setNewObjectId(commit.getCommitId());
+ ru.setRefLogMessage("commit : "
+ + ((nl == -1) ? commitMsg : commitMsg.substring(0, nl)), false);
+ ru.forceUpdate();
+ }
+}
\ No newline at end of file
--
1.6.4.msysgit.0
^ permalink raw reply related
* [JGIT PATCH 1/2] add support for core.logAllRefUpdates configuration parameter
From: Halstrick, Christian @ 2009-09-23 16:42 UTC (permalink / raw)
To: Shawn O. Pearce, Robin Rosenberg; +Cc: git@vger.kernel.org
From: Christian Halstrick <christian.halstrick@sap.com>
JGit should understand configuration parameter logAllRefUpdates and should
only log updates of refs when
either the log file for this ref is already present
or this configuration parameter is set to true
Before this commit JGit was always writing logs, regardless of this
parameter or existence of logfiles.
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
---
.../src/org/spearce/jgit/lib/CoreConfig.java | 10 ++++++++++
.../src/org/spearce/jgit/lib/RefLogWriter.java | 18 ++++++++++--------
2 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/CoreConfig.java b/org.spearce.jgit/src/org/spearce/jgit/lib/CoreConfig.java
index ed3827b..ecd9544 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/CoreConfig.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/CoreConfig.java
@@ -56,10 +56,13 @@ public CoreConfig parse(final Config cfg) {
private final int compression;
private final int packIndexVersion;
+
+ private final boolean logAllRefUpdates;
private CoreConfig(final Config rc) {
compression = rc.getInt("core", "compression", DEFAULT_COMPRESSION);
packIndexVersion = rc.getInt("pack", "indexversion", 2);
+ logAllRefUpdates = rc.getBoolean("core", "logAllRefUpdates", false);
}
/**
@@ -77,4 +80,11 @@ public int getCompression() {
public int getPackIndexVersion() {
return packIndexVersion;
}
+
+ /**
+ * @return whether to log all refUpdates
+ */
+ public boolean isLogAllRefUpdates() {
+ return logAllRefUpdates;
+ }
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/RefLogWriter.java b/org.spearce.jgit/src/org/spearce/jgit/lib/RefLogWriter.java
index 4aad809..1e5155c 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/RefLogWriter.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/RefLogWriter.java
@@ -112,16 +112,18 @@ private static void appendOneRecord(final ObjectId oldId,
final byte[] rec = Constants.encode(r.toString());
final File logdir = new File(db.getDirectory(), Constants.LOGS);
final File reflog = new File(logdir, refName);
- final File refdir = reflog.getParentFile();
+ if (reflog.exists() || db.getConfig().getCore().isLogAllRefUpdates()) {
+ final File refdir = reflog.getParentFile();
- if (!refdir.exists() && !refdir.mkdirs())
- throw new IOException("Cannot create directory " + refdir);
+ if (!refdir.exists() && !refdir.mkdirs())
+ throw new IOException("Cannot create directory " + refdir);
- final FileOutputStream out = new FileOutputStream(reflog, true);
- try {
- out.write(rec);
- } finally {
- out.close();
+ final FileOutputStream out = new FileOutputStream(reflog, true);
+ try {
+ out.write(rec);
+ } finally {
+ out.close();
+ }
}
}
--
1.6.4.msysgit.0
^ permalink raw reply related
* Re: gitk management of git diff-tree processes
From: David Holmer @ 2009-09-23 16:05 UTC (permalink / raw)
To: git
In-Reply-To: <1253632204.8531.78.camel@blackbird>
On Tue, 2009-09-22 at 11:10 -0400, David Holmer wrote:
> I find that if I am in gitk browsing through commits, gitk seems to be
> spawning a git diff-tree process in order to display the changes and
> patch file list in the bottom panes.
>
> I have a certain commit that adds a very large amount of data to my
> repository (1.2 GB). Understandably, the git diff-tree process that
> tries to display the changes in this commit takes a VERY long time to
> run (e.g. churns indefinitely).
>
> The issue is that I find that if I simply browse past this commit (e.g.
> using up/down arrows), gitk starts up a git diff-tree process and leaves
> it running. As many times as I pass the commit (e.g. while looking at
> changes before and after this commit), I end up with multiple processes
> all running and my CPUs quickly go to 100%. Furthermore, even if I exit
> gitk, all the git diff-tree processes keep running unless I manually
> kill them.
>
> Perhaps gitk could kill the git diff-tree process it spawns if its
> output is no longer needed (e.g. user browses to a different commit, or
> gitk exits).
>
> Thank you,
> David
>
> $ ps -aF
> UID PID PPID C SZ RSS PSR STIME TTY TIME CMD
> david 23635 1 18 88365 102892 0 10:49 pts/1 00:01:11 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
> david 23640 1 18 88368 102908 1 10:49 pts/1 00:01:10 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
> david 23644 1 16 88368 102904 0 10:49 pts/1 00:01:04 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
> david 23646 1 16 88367 102916 0 10:49 pts/1 00:01:04 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
> david 23652 1 17 88365 102892 1 10:49 pts/1 00:01:07 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
> david 23656 1 17 88368 102920 1 10:49 pts/1 00:01:06 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
> david 23660 1 16 88369 102932 0 10:49 pts/1 00:01:03 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
> david 23664 1 16 88368 102908 0 10:49 pts/1 00:01:03 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
> david 23670 1 16 88368 102904 1 10:49 pts/1 00:01:03 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
> david 23680 1 17 88365 102896 1 10:49 pts/1 00:01:05 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
> david 23851 10444 0 692 1032 0 10:56 pts/1 00:00:00 ps -aF
>
> $ git version
> git version 1.6.4.4
>
Looking at the code of gitk, I believe the git diff-tree process is
spawned by proc getblobdiffs (gitk-git/gitk:7322). It sets up a command
that matches all the arguments I see in the above ps -aF listing
(gitk-git/gitk:7335):
set cmd [diffcmd $ids "-p $textconv -C --cc --no-commit-id -U
$diffcontext"]
It then seems to setup this command to be run and the output processed
via proc filerun (gitk-git/gitk:7352):
filerun $bdf [list getblobdiffline $bdf $diffids]
I am not very familiar with TCL. Is there a standard/correct way to
pre-maturely halt this filerun processing? It seems to use the fileevent
to know when there is more data to process.
A Google search turned up a way to get the PID from $bfd and said that
on unix systems you could run a kill, but that TCL had no built in kill
mechanism. This seems a bit hackish/non-cross platform. Is there a
better mechanism? Would something like closing the file descriptor cause
the filerun processing to finish and the git diff-tree to terminate with
a broken pipe?
Thank you,
David
--
David G. Holmer, Ph.D.
dholmer@persistentsystems.com
CTO and Co-Founder
Persistent Systems, LLC
www.persistentsystems.com
Office: 212-561-5895
Mobile: 650-533-4964
Fax: 212-202-3625
^ permalink raw reply
* Re: Add scripts to generate projects for other buildsystems (MSVC vcproj, QMake)
From: Sebastian Schuberth @ 2009-09-23 15:04 UTC (permalink / raw)
To: msysGit
Cc: Marius Storm-Olsen, git, Johannes.Schindelin, gitster, j6t,
lznuaa, raa.lkml, snaury
In-Reply-To: <aa80ad559c731ca73179956e34b2743d903fbbec.1253088099.git.mstormo@gmail.com>
On Sep 16, 10:20 am, Marius Storm-Olsen <mstormo@gmail.com> wrote:
> These scripts generate projects for the MSVC IDE (.vcproj files) or
> QMake (.pro files), based on the output of a 'make -n MSVC=1 V=1' run.
>
> This enables us to simply do the necesarry changes in the Makefile, and you
> can update the other buildsystems by regenerating the files. Keeping the
> other buildsystems up-to-date with main development.
I know I'm a little late with my comments as this patch set has
already been merged to master. However, for future reference I'd like
to point out that something similar could be archived by using e.g.
CMake, and only maintaining the CMake project file. I'm not suggesting
to actually switch to CMake at this time, but I wanted to point out
that a guy called Pau Garcia i Quiles already seems to have created a
preliminary CMakeLists.txt file for Git [1], and also tried to build
Git for Windows using his CMake-generated MSVC project files.
[1] "CMake-ifying git", http://www.elpauer.org/?p=324
--
Sebastian
^ permalink raw reply
* [PATCH] Test for correct behaviour on %B(1) and %B(-1)
From: Johannes Gilger @ 2009-09-23 13:12 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Johannes Gilger
In-Reply-To: <7vmy4mo85b.fsf@alter.siamese.dyndns.org>
Small test for correct indentation of the new %B tag (and whether
negative values are ignored as an incorrect placeholder).
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
---
Hi Junio,
seeing as the %B-patch is in your pu you seem to be almost happy with it. It's
marked NEEDSWORK: tests, so I thought I give that a try too. Probably best to
be squashed with the other one.
Greetings,
Jojo
t/t4202-log.sh | 20 ++++++++++++++------
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 1e952ca..9b7825d 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -32,8 +32,9 @@ test_expect_success setup '
git commit -m fifth &&
git rm a/two &&
+ echo -e "sixth\n\nlineone\nlinetwo" >sixth &&
test_tick &&
- git commit -m sixth
+ git commit -F sixth
'
@@ -63,8 +64,15 @@ test_expect_success 'format' '
test_cmp expect actual
'
+printf "sixth\n\n lineone\n linetwo\n%%B(-1)\n" > expect
+test_expect_success 'format (subject %s, body %B(1), %B(-1))' '
+
+ git log --format="%s%n%n%B(1)%n%B(-1)" 394ef78..5821e35 > actual &&
+ test_cmp expect actual
+'
+
cat > expect << EOF
-804a787 sixth
+5821e35 sixth
394ef78 fifth
5d31159 fourth
2fbe8c0 third
@@ -150,22 +158,22 @@ test_expect_success 'git log --follow' '
'
cat > expect << EOF
-804a787 sixth
+5821e35 sixth
394ef78 fifth
5d31159 fourth
EOF
test_expect_success 'git log --no-walk <commits> sorts by commit time' '
- git log --no-walk --oneline 5d31159 804a787 394ef78 > actual &&
+ git log --no-walk --oneline 5d31159 5821e35 394ef78 > actual &&
test_cmp expect actual
'
cat > expect << EOF
5d31159 fourth
-804a787 sixth
+5821e35 sixth
394ef78 fifth
EOF
test_expect_success 'git show <commits> leaves list of commits as given' '
- git show --oneline -s 5d31159 804a787 394ef78 > actual &&
+ git show --oneline -s 5d31159 5821e35 394ef78 > actual &&
test_cmp expect actual
'
--
1.6.5.rc1.38.g1fbd3
^ permalink raw reply related
* Re: Add MinGW header files to build git with MSVC
From: Marius Storm-Olsen @ 2009-09-23 11:29 UTC (permalink / raw)
To: Sebastian Schuberth
Cc: msysGit, git, Johannes.Schindelin, gitster, j6t, lznuaa, raa.lkml,
snaury
In-Reply-To: <a416a9d0-90f3-40b7-bd39-ea67ceb2e0b9@j19g2000vbp.googlegroups.com>
Sebastian Schuberth said the following on 23.09.2009 12:03:
>> From: Frank Li <lznuaa@gmail.com>
>>
>> Added the header files dirent.h, unistd.h and utime.h
>> Add alloca.h, which simply includes malloc.h, which defines alloca
>>
>> Signed-off-by: Frank Li <lznuaa@gmail.com>
>> Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
>
> [...]
>
>> create mode 100644 compat/vcbuild/include/sys/utime.h
>
> Have you considered simply including MSVC's sys/utime.h here? From a
> first glance, it seems as if it contains all required symbols.
This was a patch which originated from Frank Li's original series.
While we might have been able to simply use the MSVC one, I'm sure
Frank had a reason for overriding it with the small content which you
see in this patch. We'll have to ask Frank about that. We can always
remove it now, if the MSVC version works ok and doesn't introduce any
compiler errors/warnings.
While I appreciate your comments, they are a tad late, as the whole
series is already in master.. :)
See http://repo.or.cz/w/git.git?a=shortlog;h=refs/heads/master
So, give it a try, to see if removing the include override
compat/vcbuild/include/utime.h
doesn't introduce a regression, and send a patch for it.
--
.marius
^ permalink raw reply
* Re: Feature Enhancement Idea.
From: Deon George @ 2009-09-23 11:12 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200909231106.03305.johan@herland.net>
2009/9/23 Johan Herland <johan@herland.net>:
> Have a look at git submodules ('git help submodule'), or the git-subtree
> script that has been discussed on this list a couple of times [1].
git submodule looks like it will do a little of what I want - I'll do
some more reading on it to see exactly how it works. Thanks for the
tip.
My initial look at it seems to miss an important feature that my layer
idea would provide. It looks like git submodule assumes that
everything in a subdirectory belongs to a repository - with my layer
idea, I would want any layer to share the same directory structure and
files (or content) belonging to a distinct layer's repository.
IE:
the base might provide
plugins
plugins/README
modules
modules/README
lib/common.php
and a layer might provide
plugins/a.php
modules/a.php
lib/a.php
another layer might provide
plugins/b.php
modules/b.php
lib/b.php
If I was a C developer, I'd have a go at creating it - but I'm just a
php developer :)
...deon
^ permalink raw reply
* Re: Add MinGW header files to build git with MSVC
From: Sebastian Schuberth @ 2009-09-23 10:03 UTC (permalink / raw)
To: msysGit
Cc: Marius Storm-Olsen, git, Johannes.Schindelin, gitster, j6t,
lznuaa, raa.lkml, snaury
In-Reply-To: <7afd55f9b2f0f7859f757c715034cc3520e07f0e.1253088099.git.mstormo@gmail.com>
> From: Frank Li <lznuaa@gmail.com>
>
> Added the header files dirent.h, unistd.h and utime.h
> Add alloca.h, which simply includes malloc.h, which defines alloca
>
> Signed-off-by: Frank Li <lznuaa@gmail.com>
> Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
[...]
> create mode 100644 compat/vcbuild/include/sys/utime.h
Have you considered simply including MSVC's sys/utime.h here? From a
first glance, it seems as if it contains all required symbols.
--
Sebastian
^ permalink raw reply
* Re: Avoid declaration after statement
From: Sebastian Schuberth @ 2009-09-23 9:44 UTC (permalink / raw)
To: msysGit
Cc: Marius Storm-Olsen, git, Johannes.Schindelin, gitster, j6t,
lznuaa, raa.lkml, snaury
In-Reply-To: <213f3c7799721c3f42ffa689498175f0495048eb.1253088099.git.mstormo@gmail.com>
> From: Frank Li <lznuaa@gmail.com>
>
> MSVC does not understand this C99 style
>
> Signed-off-by: Frank Li <lznuaa@gmail.com>
> Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
Indeed, even in recent Visual Studio versions the C compiler only
understands C90, not C99. Would it make sense to just force MSVC to
compile *.c files with the C++ compiler to fix this, rather than
patching files (which might be necessary for future files, too)? See
the "/TP" command line option to "CL".
--
Sebastian
^ permalink raw reply
* [ANNOUNCE] TopGit 0.8
From: Uwe Kleine-König @ 2009-09-23 9:32 UTC (permalink / raw)
To: git
Cc: Jon Ringle, Bert Wesarg, Ilpo Järvinen, Marc Weber,
Bernhard R. Link, martin f. krafft
Hello,
I'm happy to announce that TopGit 0.8 was released today.
TopGit aims to make handling of large amount of interdependent topic
branches easier. In fact, it is designed especially for the case when
you maintain a queue of third-party patches on top of another (perhaps
Git-controlled) project and want to easily organize, maintain and submit
them - TopGit achieves that by keeping a separate topic branch for each
patch and providing few tools to maintain the branches
It has been a bit silent around TopGit for some time. Still a few
patches accumulated since the last relase. To get them out I have made
this release.
The highlight is a new command tg-push that makes pushing topgit
branches more comfortable. Thanks to Marc Weber and Bert Wesarg.
Other than that there are quite a few bugfixes.
If ever you have problems with or suggestions for or need for discussion
about TopGit, join us in #topgit in the freenode irc network.
As usual the release is available at
http://repo.or.cz/w/topgit.git
I will talk to martin to get this release into Debian/unstable soon.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: Feature Enhancement Idea.
From: Johan Herland @ 2009-09-23 9:06 UTC (permalink / raw)
To: git; +Cc: Deon George
In-Reply-To: <5b5e291e0909222317q47ae36d4la470f17ec3902124@mail.gmail.com>
On Wednesday 23 September 2009, Deon George wrote:
> Could this be included as part of GITs functionality (or is it
> possible already) ?
Have a look at git submodules ('git help submodule'), or the git-subtree
script that has been discussed on this list a couple of times [1].
[1] http://alumnit.ca/~apenwarr/log/?m=200904#30 and
http://github.com/apenwarr/git-subtree
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] Initial manually svn property setting support for git-svn
From: Eric Wong @ 2009-09-23 8:58 UTC (permalink / raw)
To: David Fraser; +Cc: git, David Moore
In-Reply-To: <1927112650.1281253084529659.JavaMail.root@klofta.sjsoft.com>
David Fraser <davidf@sjsoft.com> wrote:
> This basically stores an attribute 'svn-properties' for each file that
> needs them changed, and then sets the properties when committing.
Hi David,
Please wrap your commit messages and emails at 72 columns or less.
All git svn code should be wrapped at 80 or less, too.
> Issues remaining:
> * The way it edits the .gitattributes file is suboptimal - it just
> appends to the end the latest version
Consider using $GIT_DIR/info/attributes or having an option to use that
instead. Keeping a .gitattributes file in the git working tree but
_out_ of SVN is important and required, but also difficult to get right.
There are users working on projects that frown upon using unsupported
clients like git svn, and accidentally checking .gitattributes into
the project would likely annoy non-git users. It's best to keep
*.git* stuff outside of SVN projects unless they allow/want it.
But also you should not fail to consider the case that somebody else did
intentionally commit .gitattributes into svn and you have little choice
but to commit your modifications to .gitattributes. Things like
maintaining a mapping between svn:ignore and .gitignore has never
happened because of the corner cases that could pop up.
> * It could use the existing code to get the current svn properties to
> see if properties need to be changed; but this doesn't work on add
> * It would be better to cache all the svn properties locally - this
> could be done automatically in .gitattributes but I'm not sure
> everyone would want this, etc
It should be possible to infer/rebuild this by parsing unhandled.log
files git svn generates by default. There are definitely people who
don't want .gitattributes being written to automatically.
> * No support for deleting properties
What advantage(s) does having this feature in git svn this give over
using:
svn prop(edit|set|del) ARGS $(git svn info --url)
In my experience, explicitly set properties are rarely-used so I
need to be convinced it's worth supporting in the future.
> Usage is:
> git svn propset PROPNAME PROPVALUE PATH
>
> Added minimal documentation for git-svn propset
We'll also need a test case to ensure it continues working as other
changes get made and refactoring gets done.
> +sub check_attr
> +{
> + my ($attr,$path) = @_;
Please use formatting consistent with the rest of the file. Always use
tabs for indent here.
> + if ( open my $fh, '-|', "git", "check-attr", $attr, "--", $path )
Consider command_output_pipe for better portability/consistency in
Git.pm instead of open(my $fh, "-|", @args) which is Perl 5.8+-only.
Thanks for the effort and keep us informed of improvements you make.
--
Eric Wong
^ permalink raw reply
* Re: Feature Enhancement Idea.
From: Christian Couder @ 2009-09-23 8:26 UTC (permalink / raw)
To: Deon George; +Cc: git
In-Reply-To: <5b5e291e0909222317q47ae36d4la470f17ec3902124@mail.gmail.com>
Hi,
On Wed, Sep 23, 2009 at 8:17 AM, Deon George <deon.george@gmail.com> wrote:
> Hi,
>
> I'm not sure if this is the right place, but I thought I'd post my
> idea and maybe somebody will either redirect me to the right place, or
> give me that "that wont happen".
>
> Im fairly new to GIT (wish I had discovered it long ago), and I really
> like using it - great work guys/garls :)
>
> My idea is to enhance GIT to support (I'll call it) development
> "layers". The current design of GIT is that the working repository and
> working directory assume that all files belong together in the same
> project. I would like to see GIT go 3D and support layers, so that
> files (and/or file content) can belong to multiple repositories (or
> considered unique projects), even though the working tree presents all
> files as if they were one.
Perhaps you could have a look at "git replace" that is now in the master branch.
It could be improved to provide different "views" of a single repository.
I don't think that alone it would provide everything you want though.
Best regards,
Christian.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2009, #05; Wed, 23)
From: Sverre Rabbelier @ 2009-09-23 8:01 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce; +Cc: git
In-Reply-To: <7vhbuui1ys.fsf@alter.siamese.dyndns.org>
Heya,
On Wed, Sep 23, 2009 at 08:56, Junio C Hamano <gitster@pobox.com> wrote:
> * sr/gfi-options (2009-09-06) 6 commits
> (merged to 'next' on 2009-09-07 at 5f6b0ff)
> + fast-import: test the new option command
> + fast-import: add option command
> + fast-import: test the new feature command
> + fast-import: add feature command
> + fast-import: put marks reading in it's own function
> + fast-import: put option parsing code in separate functions
> (this branch is used by jh/notes.)
>
> Ping?
Ping indeed, Shawn? Blocking on a reply to whether I should drop the
option part and make location of the marks file a feature or not in
general, and $128290 in specific [0].
[0] http://article.gmane.org/gmane.comp.version-control.git/128290
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* What's cooking in git.git (Sep 2009, #05; Wed, 23)
From: Junio C Hamano @ 2009-09-23 6:56 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
In 1.7.0, we plan to correct handful of warts in the interfaces everybody
agrees that they were mistakes. The resulting system may not be strictly
backward compatible. Currently planeed changes are:
* refuse push to update the checked out branch in a non-bare repo by
default
Make "git push" into a repository to update the branch that is checked
out fail by default. You can countermand this default by setting a
configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
* refuse push to delete the current branch by default
Make "git push $there :$killed" to delete the branch that is pointed at
by its HEAD fail by default. You can countermand this default by
setting a configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936
* git-send-email won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter. You can countermand this by setting a
configuration variable.
http://article.gmane.org/gmane.comp.version-control.git/109790
* git-status won't be "git-commit --dry-run" anymore
http://thread.gmane.org/gmane.comp.version-control.git/125989/focus=125993
* "git-diff -w --exit-code" will exit success if only differences it
found are whitespace changes that are stripped away from the output.
http://thread.gmane.org/gmane.comp.version-control.git/119731/focus=119751
We are in pre-release feature freeze. 'next' will hold topics meant for
1.6.6 and 1.7.0.
Tonight's tip of 'master' is 1.6.5-rc2, and I'll disappear for about a
week. Hopefully when I come back in early October all the regressions are
found and already squashed ;-)
--------------------------------------------------
[New Topics]
* jc/fix-tree-walk (2009-09-14) 9 commits
- read-tree --debug-unpack
- unpack-trees.c: look ahead in the index
- unpack-trees.c: prepare for looking ahead in the index
- traverse_trees(): handle D/F conflict case sanely
- more D/F conflict tests
- tests: move convenience regexp to match object names to test-lib.sh
- unpack_callback(): use unpack_failed() consistently
- unpack-trees: typofix
- diff-lib.c: fix misleading comments on oneway_diff()
This is my replacement for Linus's lt/maint-traverse-trees-fix patch. It
is not so much as a counter-proposal; I originally thought it might make
sense to walk the index and drive the walker to return the entries from
trees to match entries from the index, but I ended up doing pretty much
what Linus outlined --- walk the trees, and have the index walker follow
it. It turned out that the index side also needed some hairy look-ahead,
and I am only half satisfied with the current status of the series.
To fix the resolve merge regression seen in t6035, git-merge-resolve needs
to be rewritten not to use the one-path-at-a-time "git merge-index".
* jp/fetch-tag-match (2009-09-17) 1 commit
- fetch: Speed up fetch by rewriting find_non_local_tags
I did not have much energy left while dealing with the "fix-tree-walk"
series, so I just queued this without reading nor thinking about it very
much. I personally liked my version that had far smaller number of lines
changed (which means I can be fairly certain that it did not introduce any
regression), but perhaps the majorly rewritten logic this patch gives us
may be easier to follow and maintain. We'll see.
* jg/log-format-body-indent (2009-09-19) 1 commit
- [NEEDSWORK: tests] git-log --format: Add %B tag with %B(x) option
* jl/submodule-add-noname (2009-09-22) 1 commit
- git submodule add: make the <path> parameter optional
--------------------------------------------------
[Stalled]
* je/send-email-no-subject (2009-08-05) 1 commit
(merged to 'next' on 2009-08-30 at b6455c2)
+ send-email: confirm on empty mail subjects
The existing tests cover the positive case (i.e. as long as the user says
"yes" to the "do you really want to send this message that lacks subject",
the message is sent) of this feature, but the feature itself needs its own
test to verify the negative case (i.e. does it correctly stop if the user
says "no"?)
* jh/cvs-helper (2009-08-18) 8 commits
- More fixes to the git-remote-cvs installation procedure
- Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs
- Add simple selftests of git-remote-cvs functionality
- git-remote-cvs: Remote helper program for CVS repositories
- 2/2: Add Python support library for CVS remote helper
- 1/2: Add Python support library for CVS remote helper
- Basic build infrastructure for Python scripts
- Allow helpers to request marks for fast-import
(this branch uses db/vcs-helper-rest.)
Builds on db/vcs-helper. There is a re-roll planned.
* ne/rev-cache (2009-09-07) 7 commits
- support for commit grafts, slight change to general mechanism
- support for path name caching in rev-cache
- full integration of rev-cache into git, completed test suite
- administrative functions for rev-cache, start of integration into git
- support for non-commit object caching in rev-cache
- basic revision cache system, no integration or features
- man page and technical discussion for rev-cache
Tonight's 'pu' ships with this and this series seems to break a few
tests. I didn't debug.
--------------------------------------------------
[Cooking]
* jc/maint-blank-at-eof (2009-09-15) 0 commits.
(this branch uses jc/maint-1.6.0-blank-at-eof.)
The series does not have a commit of its own but is a preparation for
merging the original jc/1.6.0-maint-blank-at-eof topic to 'maint' and then
'master'. It is a fix for longstanding bug and 1.6.5 will not contain
this topic.
* db/vcs-helper-rest (2009-09-03) 6 commits
- Allow helpers to report in "list" command that the ref is unchanged
- Add support for "import" helper command
- Add a config option for remotes to specify a foreign vcs
- Allow programs to not depend on remotes having urls
- Allow fetch to modify refs
- Use a function to determine whether a remote is valid
(this branch is used by jh/cvs-helper.)
This holds the remainder of the db/vcs-helper topic that has already
merged for 1.6.5.
* jh/notes (2009-09-12) 13 commits
- Selftests verifying semantics when loading notes trees with various fanouts
- Teach the notes lookup code to parse notes trees with various fanout schemes
- notes.[ch] fixup: avoid old-style declaration
- Teach notes code to free its internal data structures on request.
- Add '%N'-format for pretty-printing commit notes
- Add flags to get_commit_notes() to control the format of the note string
- t3302-notes-index-expensive: Speed up create_repo()
- fast-import: Add support for importing commit notes
- Teach "-m <msg>" and "-F <file>" to "git notes edit"
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
(this branch uses sr/gfi-options.)
Rerolled and queued.
* jn/gitweb-show-size (2009-09-07) 1 commit
- gitweb: Add 'show-sizes' feature to show blob sizes in tree view
* lt/maint-traverse-trees-fix (2009-09-06) 1 commit.
. Prepare 'traverse_trees()' for D/F conflict lookahead
Ejected from 'pu' (see jc/fix-tree-walk above).
* jc/maint-1.6.0-blank-at-eof (2009-09-14) 15 commits.
(merged to 'next' on 2009-09-15 at 9cbfa00)
+ diff -B: colour whitespace errors
+ diff.c: emit_add_line() takes only the rest of the line
+ diff.c: split emit_line() from the first char and the rest of the line
+ diff.c: shuffling code around
+ diff --whitespace: fix blank lines at end
(merged to 'next' on 2009-09-07 at 165dc3c)
+ core.whitespace: split trailing-space into blank-at-{eol,eof}
+ diff --color: color blank-at-eof
+ diff --whitespace=warn/error: fix blank-at-eof check
+ diff --whitespace=warn/error: obey blank-at-eof
+ diff.c: the builtin_diff() deals with only two-file comparison
+ apply --whitespace: warn blank but not necessarily empty lines at EOF
+ apply --whitespace=warn/error: diagnose blank at EOF
+ apply.c: split check_whitespace() into two
+ apply --whitespace=fix: detect new blank lines at eof correctly
+ apply --whitespace=fix: fix handling of blank lines at the eof
(this branch is used by jc/maint-blank-at-eof.)
This is a fix for an ancient bug (or inconsistent set of features); the
topic is based on an ancient codebase and is designed to be merged
upwards. jc/maint-blank-at-eof serves that purpose.
Will not be in 1.6.5.
* jn/gitweb-blame (2009-09-01) 5 commits
- gitweb: Minify gitweb.js if JSMIN is defined
- gitweb: Create links leading to 'blame_incremental' using JavaScript
(merged to 'next' on 2009-09-07 at 3622199)
+ gitweb: Colorize 'blame_incremental' view during processing
+ gitweb: Incremental blame (using JavaScript)
+ gitweb: Add optional "time to generate page" info in footer
Ajax-y blame.
* sr/gfi-options (2009-09-06) 6 commits
(merged to 'next' on 2009-09-07 at 5f6b0ff)
+ fast-import: test the new option command
+ fast-import: add option command
+ fast-import: test the new feature command
+ fast-import: add feature command
+ fast-import: put marks reading in it's own function
+ fast-import: put option parsing code in separate functions
(this branch is used by jh/notes.)
Ping?
* nd/sparse (2009-08-20) 19 commits
- sparse checkout: inhibit empty worktree
- Add tests for sparse checkout
- read-tree: add --no-sparse-checkout to disable sparse checkout support
- unpack-trees(): ignore worktree check outside checkout area
- unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
- unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
- unpack-trees.c: generalize verify_* functions
- unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
- Introduce "sparse checkout"
- dir.c: export excluded_1() and add_excludes_from_file_1()
- excluded_1(): support exclude files in index
- unpack-trees(): carry skip-worktree bit over in merged_entry()
- Read .gitignore from index if it is skip-worktree
- Avoid writing to buffer in add_excludes_from_file_1()
- Teach Git to respect skip-worktree bit (writing part)
- Teach Git to respect skip-worktree bit (reading part)
- Introduce "skip-worktree" bit in index, teach Git to get/set this bit
- Add test-index-version
- update-index: refactor mark_valid() in preparation for new options
--------------------------------------------------
[For 1.7.0]
* jk/1.7.0-status (2009-09-05) 5 commits
- docs: note that status configuration affects only long format
(merged to 'next' on 2009-09-07 at 8a7c563)
+ commit: support alternate status formats
+ status: add --porcelain output format
+ status: refactor format option parsing
+ status: refactor short-mode printing to its own function
(this branch uses jc/1.7.0-status.)
Gives the --short output format to post 1.7.0 "git commit --dry-run" that
is similar to that of post 1.7.0 "git status".
* jc/1.7.0-status (2009-09-05) 4 commits
(merged to 'next' on 2009-09-06 at 19d4beb)
+ status: typo fix in usage
(merged to 'next' on 2009-08-22 at b3507bb)
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit"
(this branch is used by jk/1.7.0-status.)
With this, "git status" is no longer "git commit --dry-run".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit
(merged to 'next' on 2009-08-22 at 5106de8)
+ send-email: make --no-chain-reply-to the default
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
(merged to 'next' on 2009-08-30 at 0623572)
+ diff.c: fix typoes in comments
(merged to 'next' on 2009-08-27 at 81fb2bd)
+ Make test case number unique
(merged to 'next' on 2009-08-02 at 9c08420)
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change, but
we could argue that it is a bugfix.
* jc/1.7.0-push-safety (2009-02-09) 2 commits
(merged to 'next' on 2009-08-02 at 38b82fe)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
--------------------------------------------------
[I have been too busy to purge these]
* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected
Maybe some people care about this. I dunno.
* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
- mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Maybe some people care about this. I dunno.
* lt/read-directory (2009-05-15) 3 commits.
. Add initial support for pathname conversion to UTF-8
. read_directory(): infrastructure for pathname character set conversion
. Add 'fill_directory()' helper function for directory traversal
* cc/reset-merge (2009-09-16) 4 commits
. reset: add test cases for "--merge-safe" option
. reset: add option "--merge-safe" to "git reset"
. reset: use "unpack_trees()" directly instead of "git read-tree"
. reset: add a few tests for "git reset --merge"
* cc/sequencer-rebase-i (2009-08-28) 15 commits
. rebase -i: use "git sequencer--helper --cherry-pick"
. sequencer: add "--cherry-pick" option to "git sequencer--helper"
. sequencer: add "do_commit()" and related functions working on "next_commit"
. pick: libify "pick_help_msg()"
. revert: libify cherry-pick and revert functionnality
. rebase -i: use "git sequencer--helper --fast-forward"
. sequencer: let "git sequencer--helper" callers set "allow_dirty"
. sequencer: add "--fast-forward" option to "git sequencer--helper"
. sequencer: add "do_fast_forward()" to perform a fast forward
. rebase -i: use "git sequencer--helper --reset-hard"
. sequencer: add "--reset-hard" option to "git sequencer--helper"
. sequencer: add "reset_almost_hard()" and related functions
. rebase -i: use "git sequencer--helper --make-patch"
. sequencer: add "make_patch" function to save a patch
. sequencer: add "builtin-sequencer--helper.c"
^ permalink raw reply
* Re: git-svn-problem: Unnecessary downloading entire branch?
From: Eric Wong @ 2009-09-23 6:55 UTC (permalink / raw)
To: Martin Larsson; +Cc: git
In-Reply-To: <1253102039.6509.143.camel@martin>
Martin Larsson <martin.liste.larsson@gmail.com> wrote:
> I have a local git-copy of the company svn-repository. The git-copy is
> up-to-date (git svn fetch). I then add a new branch in the
> svn-repository (svn cp http://.../trunk http://...branches/JIRA-4444).
> When I then do 'git svn fetch' again, it pulls all the files from the
> svn-repository.
>
> I was expecting it to only pull the fact that a new branch was made
> (taking milliseconds), not all the files in the branch (taking more than
> half an hour to complete). Why does it need to transfer all the files?
Are some branches at a different depth in the repository? E.g:
project/trunk
project/branches/feature-a
project/branches/martin/feature-b
project/branches/martin/feature-c
project/branches/feature-d
project/branches/feature-e
Basically a refs layout like this in your $GIT_CONFIG:
fetch = project/trunk:refs/remotes/trunk
branches = project/branches/*:refs/remotes/*
Is going to get git svn confused and think "martin" is a branch when
it is rather a container of a branch.
However if you have a consistent depth and two branch containers
("martin" and his evil twin, "nitram"):
project/trunk
project/branches/martin/feature-b
project/branches/martin/feature-c
project/branches/nitram/feature-a
project/branches/nitram/feature-d
project/branches/nitram/feature-e
As of git v1.6.4, you can repeat "branches" or "tags" lines in
$GIT_CONFIG thanks to Marc Branchaud:
fetch = project/trunk:refs/remotes/trunk
branches = project/branches/martin/*:refs/remotes/martin/*
branches = project/branches/nitram/*:refs/remotes/nitram/*
This is a known problem with the (extremely flexible and therefore
inconsistent) way SVN repositories can be laid out.
> I did have problems getting the original svn-repository. It took several
> days and stopped several times in the process. Each time it stopped, I
> just issued 'git svn fetch' again and it seemed to continue. Could this
> be related? How could I make a better copy?
It could be the server disconnecting you or a bad Internet connection.
Resuming "git svn fetch" should be perfectly safe, though.
--
Eric Wong
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox