* [PATCH 2/3] Set a couple more tags in the original repository.
From: Michael Haggerty @ 2009-12-04 14:36 UTC (permalink / raw)
To: git; +Cc: gitster, Johannes.Schindelin, Michael Haggerty
In-Reply-To: <cover.1259934977.git.mhagger@alum.mit.edu>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
t/t3404-rebase-interactive.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 073674f..236d698 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -23,7 +23,7 @@ set_fake_editor
# I (branch2)
#
# where B, D and G touch the same file. In addition, set tags at
-# points A, F, and I.
+# points A, E, F, H, and I.
test_expect_success 'setup' '
: > file1 &&
@@ -45,6 +45,7 @@ test_expect_success 'setup' '
git add file3 &&
test_tick &&
git commit -m E &&
+ git tag E &&
git checkout -b branch1 A &&
: > file4 &&
git add file4 &&
@@ -58,6 +59,7 @@ test_expect_success 'setup' '
git add file5 &&
test_tick &&
git commit -m H &&
+ git tag H &&
git checkout -b branch2 F &&
: > file6 &&
git add file6 &&
--
1.6.5.4
^ permalink raw reply related
* [PATCH 3/3] Add a command "fix" to rebase --interactive.
From: Michael Haggerty @ 2009-12-04 14:36 UTC (permalink / raw)
To: git; +Cc: gitster, Johannes.Schindelin, Michael Haggerty
In-Reply-To: <cover.1259934977.git.mhagger@alum.mit.edu>
The command is like "squash", except that it discards the commit message
of the corresponding commit.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
Documentation/git-rebase.txt | 13 ++++++++-----
git-rebase--interactive.sh | 39 +++++++++++++++++++++++++++++----------
t/lib-rebase.sh | 7 ++++---
t/t3404-rebase-interactive.sh | 30 ++++++++++++++++++++++++++++++
4 files changed, 71 insertions(+), 18 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index ca5e1e8..eafab57 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -382,9 +382,12 @@ If you just want to edit the commit message for a commit, replace the
command "pick" with the command "reword".
If you want to fold two or more commits into one, replace the command
-"pick" with "squash" for the second and subsequent commit. If the
-commits had different authors, it will attribute the squashed commit to
-the author of the first commit.
+"pick" for the second and subsequent commits with "squash" or "fix".
+If the commits had different authors, the folded commit will be
+attributed to the author of the first commit. The suggested commit
+message for the folded commit is the concatenation of the commit
+messages of the first commit and of those with the "squash" command,
+but omits the commit messages of commits with the "fix" command.
'git-rebase' will stop when "pick" has been replaced with "edit" or
when a command fails due to merge errors. When you are done editing
@@ -512,8 +515,8 @@ Easy case: The changes are literally the same.::
Hard case: The changes are not the same.::
This happens if the 'subsystem' rebase had conflicts, or used
- `\--interactive` to omit, edit, or squash commits; or if the
- upstream used one of `commit \--amend`, `reset`, or
+ `\--interactive` to omit, edit, squash, or fix commits; or if
+ the upstream used one of `commit \--amend`, `reset`, or
`filter-branch`.
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 0bd3bf7..539413d 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -302,7 +302,7 @@ nth_string () {
make_squash_message () {
if test -f "$SQUASH_MSG"; then
- COUNT=$(($(sed -n "s/^# This is [^0-9]*\([1-9][0-9]*\).*/\1/p" \
+ COUNT=$(($(sed -n "s/^# Th[^0-9]*\([1-9][0-9]*\)\(th\|st\|nd\|rd\) commit message.*:/\1/p" \
< "$SQUASH_MSG" | sed -ne '$p')+1))
echo "# This is a combination of $COUNT commits."
sed -e 1d -e '2,/^./{
@@ -315,10 +315,20 @@ make_squash_message () {
echo
git cat-file commit HEAD | sed -e '1,/^$/d'
fi
- echo
- echo "# This is the $(nth_string $COUNT) commit message:"
- echo
- git cat-file commit $1 | sed -e '1,/^$/d'
+ case $1 in
+ squash)
+ echo
+ echo "# This is the $(nth_string $COUNT) commit message:"
+ echo
+ git cat-file commit $2 | sed -e '1,/^$/d'
+ ;;
+ fix)
+ echo
+ echo "# The $(nth_string $COUNT) commit message will be skipped:"
+ echo
+ git cat-file commit $2 | sed -e '1,/^$/d' -e 's/^/#/'
+ ;;
+ esac
}
peek_next_command () {
@@ -367,20 +377,28 @@ do_next () {
warn
exit 0
;;
- squash|s)
- comment_for_reflog squash
+ squash|s|fix|f)
+ case "$command" in
+ squash|s)
+ squash_style=squash
+ ;;
+ fix|f)
+ squash_style=fix
+ ;;
+ esac
+ comment_for_reflog $squash_style
test -f "$DONE" && has_action "$DONE" ||
- die "Cannot 'squash' without a previous commit"
+ die "Cannot '$squash_style' without a previous commit"
mark_action_done
- make_squash_message $sha1 > "$MSG"
+ make_squash_message $squash_style $sha1 > "$MSG"
failed=f
author_script=$(get_author_ident_from_commit HEAD)
output git reset --soft HEAD^
pick_one -n $sha1 || failed=t
case "$(peek_next_command)" in
- squash|s)
+ squash|s|fix|f)
USE_OUTPUT=output
MSG_OPT=-F
EDIT_OR_FILE="$MSG"
@@ -768,6 +786,7 @@ first and then run 'git rebase --continue' again."
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
+# f, fix = like "squash", but discard this commit's log message
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 62f452c..8b42f23 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@ -9,8 +9,9 @@
#
# "[<lineno1>] [<lineno2>]..."
#
-# If a line number is prefixed with "squash", "edit", or "reword", the
-# respective line's command will be replaced with the specified one.
+# If a line number is prefixed with "squash", "fix", "edit", or
+# "reword", the respective line's command will be replaced with the
+# specified one.
set_fake_editor () {
echo "#!$SHELL_PATH" >fake-editor.sh
@@ -32,7 +33,7 @@ cat "$1".tmp
action=pick
for line in $FAKE_LINES; do
case $line in
- squash|edit|reword)
+ squash|fix|edit|reword)
action="$line";;
*)
echo sed -n "${line}s/^pick/$action/p"
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 236d698..27645c4 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -264,6 +264,36 @@ test_expect_success 'multi-squash only fires up editor once' '
test 1 = $(git show | grep ONCE | wc -l)
'
+test_expect_success 'multi-fix only fires up editor once' '
+ git checkout -b multi-fix E &&
+ base=$(git rev-parse HEAD~4) &&
+ FAKE_COMMIT_AMEND="ONCE" FAKE_LINES="1 fix 2 fix 3 fix 4" \
+ git rebase -i $base &&
+ test $base = $(git rev-parse HEAD^) &&
+ test 1 = $(git show | grep ONCE | wc -l) &&
+ git checkout to-be-rebased &&
+ git branch -D multi-fix
+'
+
+cat > expect-squash-fix << EOF
+B
+
+D
+
+ONCE
+EOF
+
+test_expect_success 'squash and fix generate correct log messages' '
+ git checkout -b squash-fix E &&
+ base=$(git rev-parse HEAD~4) &&
+ FAKE_COMMIT_AMEND="ONCE" FAKE_LINES="1 fix 2 squash 3 fix 4" \
+ git rebase -i $base &&
+ git cat-file commit HEAD | sed -e 1,/^\$/d > actual-squash-fix &&
+ test_cmp expect-squash-fix actual-squash-fix &&
+ git checkout to-be-rebased &&
+ git branch -D squash-fix
+'
+
test_expect_success 'squash works as expected' '
for n in one two three four
do
--
1.6.5.4
^ permalink raw reply related
* [PATCH 1/3] Better document the original repository layout.
From: Michael Haggerty @ 2009-12-04 14:36 UTC (permalink / raw)
To: git; +Cc: gitster, Johannes.Schindelin, Michael Haggerty
In-Reply-To: <cover.1259934977.git.mhagger@alum.mit.edu>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
t/t3404-rebase-interactive.sh | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 3a37793..073674f 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -16,13 +16,14 @@ set_fake_editor
# set up two branches like this:
#
-# A - B - C - D - E
+# A - B - C - D - E (master)
# \
-# F - G - H
+# F - G - H (branch1)
# \
-# I
+# I (branch2)
#
-# where B, D and G touch the same file.
+# where B, D and G touch the same file. In addition, set tags at
+# points A, F, and I.
test_expect_success 'setup' '
: > file1 &&
--
1.6.5.4
^ permalink raw reply related
* [PATCH 0/3] Add a "fix" command to "rebase --interactive"
From: Michael Haggerty @ 2009-12-04 14:36 UTC (permalink / raw)
To: git; +Cc: gitster, Johannes.Schindelin, Michael Haggerty
This patch series adds "fix" to the commands that can be used within
the "rebase --interactive" patch editor. "fix" is like "squash"
except that it discards the log message of the corresponding commit.
Why I would like this feature:
One of my favorite aliases is
fix = commit --amend -C HEAD
which I use in those all-too-frequent head-slapping "I just committed
something with a minor typo" moments. It amends the last commit with
whatever is staged, reusing the same commit message. It can also be
used with the "-a" option, a list of filenames, etc.
But sometimes I don't have my head-slapping moments until a few
commits later. In this case, my usual practice is to commit the
trivial typo change on top of the current branch, then "rebase
--interactive" to move the typo fix on top of the erroneous commit and
squash it:
pick 05d3b81 Commit with typo
pick c29114a Good commit 1
pick 250b013 Good commit 2
pick 5eb3299 Fix for typo
|
V
pick 05d3b81 Commit with typo
squash 5eb3299 Fix for typo
pick c29114a Good commit 1
pick 250b013 Good commit 2
But then it is necessary to go into the commit message editor, move
the cursor down past the first commit message, delete the "Fix for
typo" commit message, save, and quit.
This patch implements a "fix" command, similar to "squash", except
that the corresponding log message is not included in the log message
suggested for the combined commit. (In fact, it includes the log
message, but commented out.) It therefore saves the editor chores.
"fix" and "squash" can be used in the same group, in which case the
"squash" commit messages are preserved and the "fix" commit messages
are skipped.
If the idea of a "fix" command is acceptable, then I would like to
implement a further convenience: if a group of commits to be folded
together includes *only* "fix" commits, then the first log message
should be used without even opening an editor. But I would like to
get a reaction to the "fix" command in general before doing so.
Michael Haggerty (3):
Better document the original repository layout.
Set a couple more tags in the original repository.
Add a command "fix" to rebase --interactive.
Documentation/git-rebase.txt | 13 ++++++++-----
git-rebase--interactive.sh | 39 +++++++++++++++++++++++++++++----------
t/lib-rebase.sh | 7 ++++---
t/t3404-rebase-interactive.sh | 41 +++++++++++++++++++++++++++++++++++++----
4 files changed, 78 insertions(+), 22 deletions(-)
^ permalink raw reply
* Re: git gsoc money
From: Jeff King @ 2009-12-04 12:14 UTC (permalink / raw)
To: git
In-Reply-To: <20091203153935.GB23281@spearce.org>
On Thu, Dec 03, 2009 at 07:39:35AM -0800, Shawn O. Pearce wrote:
> > 1. Become an affiliated project of an organization like The Software
> > Freedom Conservancy or Software in the Public Interest.
>
> Try to join the Software Freedom Conservancy and retain the funds
> for Git's use? Maybe you can slide in before the Dec 31st deadline.
Everybody who responded seems to think that is a good idea, so I've
contacted the SFC about joining. I'll keep the list up to date as things
develop there.
I expect they'll need a liaison from the project. I can do that, but if
somebody else is interested, let me know.
-Peff
^ permalink raw reply
* Re: git reset --hard in .git causes a checkout in that directory
From: Jeff King @ 2009-12-04 11:11 UTC (permalink / raw)
To: Maarten Lankhorst; +Cc: Junio C Hamano, git
In-Reply-To: <4B17A166.60306@gmail.com>
On Thu, Dec 03, 2009 at 12:30:46PM +0100, Maarten Lankhorst wrote:
> When I was working on my code and made a mess that I wanted to undo,
> I accidentally did it in the .git directory, and had a whole clone of
> my last committed tree there.
>
> It can be triggered easily:
>
> mkdir test; cd test; git init; touch foo; git add foo; git commit -m
> 'add foo'; cd .git; git reset --hard; [ -f foo ] && echo hello beauty
>
> Other parts of git could be affected, I haven't checked where exactly
> the bug hides, so I was afraid to send in a patch
Yuck. Thanks for the bug report. This is due to a too-loose check on my
part in 49b9362 (git-reset: refuse to do hard reset in a bare
repository, 2007-12-31).
Junio, I think the following should go to maint (I didn't bother
splitting the --merge and --hard code; --merge is in v1.6.2. I assumed
we don't care about maint releases that far back).
-- >8 --
Subject: [PATCH] reset: improve worktree safety valves
The existing code checked to make sure we were not in a bare
repository when doing a hard reset. However, we should take
this one step further, and make sure we are in a worktree.
Otherwise, we can end up munging files inside of '.git'.
Furthermore, we should do the same check for --merge resets,
which have the same properties. Actually, a merge reset of
HEAD^ would already complain, since further down in the code
we want a worktree. However, it is nicer to check up-front;
then we are sure we cover all cases ("git reset --merge"
would run, even though it wasn't doing anything) and we can
give a more specific message.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-reset.c | 6 ++++--
t/t7103-reset-bare.sh | 14 ++++++++++++++
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/builtin-reset.c b/builtin-reset.c
index 73e6022..11d1c6e 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -286,8 +286,10 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
if (reset_type == NONE)
reset_type = MIXED; /* by default */
- if (reset_type == HARD && is_bare_repository())
- die("hard reset makes no sense in a bare repository");
+ if ((reset_type == HARD || reset_type == MERGE)
+ && !is_inside_work_tree())
+ die("%s reset requires a work tree",
+ reset_type_names[reset_type]);
/* Soft reset does not touch the index file nor the working tree
* at all, but requires them in a good order. Other resets reset
diff --git a/t/t7103-reset-bare.sh b/t/t7103-reset-bare.sh
index 42bf518..3ddf0ac 100755
--- a/t/t7103-reset-bare.sh
+++ b/t/t7103-reset-bare.sh
@@ -11,6 +11,16 @@ test_expect_success 'setup non-bare' '
git commit -a -m two
'
+test_expect_success 'hard reset requires a worktree' '
+ (cd .git &&
+ test_must_fail git reset --hard)
+'
+
+test_expect_success 'merge reset requires a worktree' '
+ (cd .git &&
+ test_must_fail git reset --merge)
+'
+
test_expect_success 'setup bare' '
git clone --bare . bare.git &&
cd bare.git
@@ -20,6 +30,10 @@ test_expect_success 'hard reset is not allowed' '
test_must_fail git reset --hard HEAD^
'
+test_expect_success 'merge reset is not allowed' '
+ test_must_fail git reset --merge HEAD^
+'
+
test_expect_success 'soft reset is allowed' '
git reset --soft HEAD^ &&
test "`git show --pretty=format:%s | head -n 1`" = "one"
--
1.6.6.rc1.18.ga777f.dirty
^ permalink raw reply related
* Re: Running commands in wrong environment
From: Jeff King @ 2009-12-04 10:44 UTC (permalink / raw)
To: Marinescu Paul dan; +Cc: Junio C Hamano, git@vger.kernel.org
In-Reply-To: <D6F784B72498304C93A8A4691967698E8EE2C44FE5@REX2.intranet.epfl.ch>
On Thu, Dec 03, 2009 at 08:19:05PM +0100, Marinescu Paul dan wrote:
> git's start_command (run_command.c) executes a command (e.g. hook) but
> does not verify that it has properly set up the environment. It seems
> that in the unlikely case where putenv (run_command.c:117) fails, the
> command may have undesirable effects e.g. GIT_INDEX_FILE should have
> been set (interactive pre-commit hooks) but the default index will be
> used instead. It would be safer not to run the command but just exit
> in that case.--
Hmm. It is simple enough to patch the one use of putenv, but there are
34 other calls to setenv, which has the same problem. I am tempted to
ignore it, as it is extremely unlikely for this ever to happen, and
adding error checking everywhere reduces the code readability.
But the consequences, as you mention, could include data loss, which
argues for being on the safe side. In that case, we would probably want
an "xsetenv" to die() if we fail to avoid cluttering the code
everywhere.
I dunno. If we're going to do it, it is probably maint-worthy. Junio?
-Peff
^ permalink raw reply
* Re: [RFC PATCH 2/2] MSVC: Fix an "incompatible pointer types" compiler warning
From: Johannes Schindelin @ 2009-12-04 10:47 UTC (permalink / raw)
To: Ramsay Jones
Cc: Junio C Hamano, Marius Storm-Olsen, Johannes Sixt,
GIT Mailing-list
In-Reply-To: <4B1806FB.2050401@ramsay1.demon.co.uk>
Hi,
On Thu, 3 Dec 2009, Ramsay Jones wrote:
> compat/mingw.h | 27 ++++++++++++++++++++++++++-
> compat/msvc.h | 25 +------------------------
> 2 files changed, 27 insertions(+), 25 deletions(-)
I'd prefer to have the MSVC-specific definitions in msvc.h, along with a
definition of, say, ALREADY_DEFINED_STATI64 or some such (which tells
mingw.h not to do anything about those types). There is no need to
clutter mingw.h with stuff for MSVC.
Ciao,
Dscho
^ permalink raw reply
* Re: [BUG] crash on make test
From: Jeff King @ 2009-12-04 10:35 UTC (permalink / raw)
To: Marinescu Paul dan; +Cc: Junio C Hamano, git@vger.kernel.org
In-Reply-To: <D6F784B72498304C93A8A4691967698E8EE2C44FE2@REX2.intranet.epfl.ch>
On Thu, Dec 03, 2009 at 04:38:58PM +0100, Marinescu Paul dan wrote:
> I got a crash on git's make test with and a core file in ./t/trash
> directory.t4200-rerere/ The problem seems to be in garbage_collect
> (builtin-rerere.c) where readdir can be called with a null pointer
Hmm. The problematic code is pretty straightforward to see, but what I
don't understand is how you managed to trigger it. The code path to get
there makes sure that the rr-cache directory exists (because we check
whether rerere is enabled, which means either rr-cache exists, or
rerere.enabled is set, and in the latter case we mkdir the directory).
I can see how it might happen if rr-cache exists but isn't readable. I
can easily trigger a segfault with:
mkdir .git/rr-cache
sudo chown root .git/rr-cache
sudo chmod 0700 .git/rr-cache
git gc
and we should definitely fix that (patch below).
But how do you end up with this situation in the middle of the test
suite? And if it is not a permissions problem, but that the directory is
missing, that would indicate something randomly deleting files while
you're running the test.
I think we should apply the patch below to maint, as this is something
that can come up due to permissions problems. But I fear it won't
actually fix the test failure you are seeing; you will just see it die()
instead of segfaulting. However, the value of errno should give us a
clue about what is happening, so please try running the test again with
this patch.
-- >8 --
Subject: [PATCH] rerere: don't segfault on failure to open rr-cache
The rr-cache directory should always exist if we are doing
garbage collection (earlier code paths check this
explicitly), but we may not necessarily succeed in opening
it (for example, due to permissions problems). In that case,
we should print an error message rather than simply
segfaulting.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-rerere.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-rerere.c b/builtin-rerere.c
index 343d6cd..2be9ffb 100644
--- a/builtin-rerere.c
+++ b/builtin-rerere.c
@@ -48,6 +48,8 @@ static void garbage_collect(struct string_list *rr)
git_config(git_rerere_gc_config, NULL);
dir = opendir(git_path("rr-cache"));
+ if (!dir)
+ die_errno("unable to open rr-cache directory");
while ((e = readdir(dir))) {
if (is_dot_or_dotdot(e->d_name))
continue;
--
1.6.6.rc1.18.ga777f.dirty
^ permalink raw reply related
* Re: [PATCH resend 3/3] transport.c::transport_push(): make ref status affect return value
From: Jeff King @ 2009-12-04 10:20 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: git, Shawn O. Pearce, Daniel Barkalow, Sverre Rabbelier,
Clemens Buchacher, Junio C Hamano
In-Reply-To: <20091204145842.57c3c51c.rctay89@gmail.com>
On Fri, Dec 04, 2009 at 02:58:42PM +0800, Tay Ray Chuan wrote:
> - if (!quiet || push_had_errors(remote_refs))
> - print_push_status(transport->url, remote_refs,
> - verbose | porcelain, porcelain,
> - nonfastforward);
> + if (!quiet)
> + if (push_had_errors(remote_refs)) {
> + ret = -1;
> + print_push_status(transport->url, remote_refs,
> + verbose | porcelain, porcelain,
> + nonfastforward);
> + }
Er, this doesn't seem right. It will no longer print anything under
non-quiet mode unless there are errors, and it will only set a return
value in non-quiet mode.
I think you want:
if (push_had_errors(remote_refs)) {
ret = -1;
if (!quiet)
print_push_status(...)
}
else if (!quiet)
print_push_status(...)
Actually, it may simply be more readable by storing the error result:
int err = push_had_errors(remote_refs);
if (err)
ret = -1;
if (!quiet || err)
print_push_status(...);
-Peff
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.6.5.4
From: Andreas Schwab @ 2009-12-04 10:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Todd Zullinger, Michael J Gruber, git
In-Reply-To: <7vbpif4rn2.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think it depends on the likelihood that a distro has xmlto so old that
> it does not understand --stringparam yet it uses stylesheet so new that
> setting the parameter makes a positive difference (either it gives the
> full URL or at least squelches the "You should define the parameter"
> noise) in the output.
openSUSE 11.2, for example. Its xmlto has a non-standard --xsltopts
option that passes its argument down to xsltproc.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH] git-gui: suppress the X error on exit
From: Jindrich Makovicka @ 2009-12-04 9:28 UTC (permalink / raw)
To: git
Hi,
Due to a bug in Tk, git-gui almost always (unless git-gui is closed
right after starting) produces an X window error message on exit,
something like
X Error of failed request: RenderBadPicture (invalid Picture parameter)
Major opcode of failed request: 150 (RENDER)
Minor opcode of failed request: 7 (RenderFreePicture)
Picture id in failed request: 0x3a000dc
Serial number of failed request: 1965
Current serial number in output stream: 1980
Respective Tk bug report is here:
http://sourceforge.net/tracker/?func=detail&atid=112997&aid=1821174&group_id=12997
This bug is triggered only when the send command is blocked via
rename send {} . The following patch re-enables send just
before quiting git-gui to suppress the error.
--- git-gui~ 2009-11-17 23:28:30.000000000 +0100
+++ git-gui 2009-12-03 23:32:50.848588924 +0100
@@ -2023,6 +2023,10 @@
}
set ret_code $rc
+
+ # briefly re-enable send to suppress the RenderBadPicture error
+ tk appname [appname]
+
destroy .
}
^ permalink raw reply
* Re: How do you best store structured data in git repositories?
From: jamesmikedupont @ 2009-12-04 8:00 UTC (permalink / raw)
To: git
In-Reply-To: <32541b130912031745i60dc918dk3e510ef1a3b28526@mail.gmail.com>
On Thu, Dec 3, 2009 at 7:14 PM, David Aguilar <davvid@gmail.com> wrote:
> JSON's not too bad for data structures and is known to
> be friendly to XML expats.
>
> http://json.org/
I am currently working on two projects in this direction :
1. mediawiki on git, using mediawiki markup files. I apologise that I
have not made progress on that lately, because I have had inspiration
on my older project
2. the gcc rdf introspector, storage of the files in rdf. It is
working now with a mysql database, using the librdf mysql driver, and
running on a catalyst framework using jquery/jstree on the front end.
None of those formats are perfect, the sizing of the files is
important. I am returning individual nodes in json on the cataylst
server and that works to deliver the AST nodes from the compiler to
the jstree front end. But these fetches to the front end should be
longer and contain direct components of the fetched node. I think that
a cluster of nodes should be pulled together to make a more optimal
system.
here is just my two cents:
if you are using a distributed git data repository as your central
repository, then think about a database page. Imagine that you would have
pages of data being retrieved and compared.
Would it not make sense to split your pages something that would be swapped
into memory directly, or with very little parsing, and then used?
So, in effect, you would design the sizing of the pages and the page
contents around the usage model, since git is a low level storage system.
I dont know what would be available if some database manager system like
mysql or postgres could be taught to store table pages in git.
just some ideas,
mike
^ permalink raw reply
* Re: [RFC PATCH 2/2] MSVC: Fix an "incompatible pointer types" compiler warning
From: Johannes Sixt @ 2009-12-04 7:44 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, Marius Storm-Olsen, GIT Mailing-list
In-Reply-To: <4B1806FB.2050401@ramsay1.demon.co.uk>
Ramsay Jones schrieb:
> In order to avoid the compiler warning, we use the appropriate
> structure type names (and function names) from the msvc headers.
> This allows us to compile with -D_USE_32BIT_TIME_T if necessary.
"if necessary"? Who defines when -D_USE_32BIT_TIME_T is necessary?
> Also, I added the "&& defined(_stati64)" in the hope that it would work with
> older msvc/sdk versions.
I think that this is an unnecessary complication and I did wonder why you
added this extra check. Anybody doing some serious development with MS's
tools is using VS2005 at least. But isn't the .vcproj file made for VS2008
anyway?
> The reason for the RFC is:
>
> - maybe we don't need the flexibility of compiling with/without the 32-bit
> time_t definition (which *works* BTW) and can revert to the original patch?
Indeed I'm wondering why we should cater for 64 bit time_t. It is an
unnessary complication as long as MinGW gcc supports only 32 bit time_t
and the old MSVCRT.DLL.
> - I *think* this will work with older msvc, but I can't test it!
This should not be a concern, IMHO.
> - I've tried to be careful not to break the MinGW build, but again I can't
> test it. (I will be shocked if I have ;-)
It compiles without warnings and doesn't break t/t[01]* ;)
-- Hannes
^ permalink raw reply
* Re: [PATCH resend 0/3] transport: catch non-fast-forwards
From: Daniel Barkalow @ 2009-12-04 7:05 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: git, Shawn O. Pearce, Daniel Barkalow, Sverre Rabbelier,
Clemens Buchacher, Jeff King, Junio C Hamano
In-Reply-To: <20091204144822.a61355d2.rctay89@gmail.com>
On Fri, 4 Dec 2009, Tay Ray Chuan wrote:
> This patch series applies on top of 'next', and deals with alerting
> the user to non-fast-forward pushes when using helpers (smart).
>
> Previously, git silently exited. This situation involves the curl
> helper and the smart protocol. The fast-forward push is only detected
> when curl executes the rpc client (git-send-pack). Now, we detect it
> before telling the helper to push.
>
> The first patch refactors ref status logic out of builtin-send-pack.c.
>
> The second patch lets git know of non-fast-forwards before actually
> telling the helper to push anything.
>
> The third patch changes the return code when ref status indicate an
> error (determined by push_had_errors()), so that the caller of
> transport_push() is alerted.
Seems to me like transport_push() ought to set this sort of status
information before calling the push method, rather than requiring all of
the implementations to remember to call the generic function, since
there's not really anything else sane they can do, right?
(There's eventually going to be at least a third push implementation:
export the data to a foreign system a la "git svn dcommit")
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [StGit PATCH v2 3/6] stg mail: make __send_message do more
From: Karl Wiberg @ 2009-12-04 7:00 UTC (permalink / raw)
To: Alex Chiang; +Cc: catalin.marinas, git
In-Reply-To: <20091203193018.GF23258@ldl.fc.hp.com>
On Thu, Dec 3, 2009 at 8:30 PM, Alex Chiang <achiang@hp.com> wrote:
> * Karl Wiberg <kha@treskal.com>:
>
> > On Wed, Dec 2, 2009 at 1:46 AM, Alex Chiang <achiang@hp.com> wrote:
> >
> > > + for (p, n) in zip(patches, range(1, total_nr + 1)):
> > > + msg_id = __send_message('patch', tmpl, options, p, n, total_nr, ref_id)
> >
> > Can be written as
> >
> > for (n, p) in enumerate(patches):
> >
> > if you use n + 1 instead of n in the loop body.
>
> That is a little cleaner, but I decided to keep it as zip(). Why?
> Because using n + 1 in the loop body will push that line past 80
> columns. ;)
>
> It's also the original code (albeit with a simple variable rename).
>
> I know this isn't the kernel, and that there are plenty of other
> lines that are 80+ characters, but if you can keep it short, why
> not?
Oh, I fully favor keeping lines within the 80 columns allotted to us
by the ancestors---I just didn't realize it was going to be a problem
here.
In general, though, programmer time is worth optimizing for, and
thinking through exactly what zip(patches, range(1, total_nr + 1))
means (and getting it right!) is a small but not insignificant cost
every time someone reads the code.
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH resend 3/3] transport.c::transport_push(): make ref status affect return value
From: Tay Ray Chuan @ 2009-12-04 6:58 UTC (permalink / raw)
To: git
Cc: Shawn O. Pearce, Daniel Barkalow, Sverre Rabbelier,
Clemens Buchacher, Jeff King, Junio C Hamano
In-Reply-To: <20091204145437.1a9910db.rctay89@gmail.com>
When determining whether to print the ref status table,
push_had_errors() is called. Piggy-back this and modify the return
value accordingly.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
transport.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/transport.c b/transport.c
index 3eea836..32c122b 100644
--- a/transport.c
+++ b/transport.c
@@ -889,10 +889,13 @@ int transport_push(struct transport *transport,
ret = transport->push_refs(transport, remote_refs, flags);
- if (!quiet || push_had_errors(remote_refs))
- print_push_status(transport->url, remote_refs,
- verbose | porcelain, porcelain,
- nonfastforward);
+ if (!quiet)
+ if (push_had_errors(remote_refs)) {
+ ret = -1;
+ print_push_status(transport->url, remote_refs,
+ verbose | porcelain, porcelain,
+ nonfastforward);
+ }
if (!(flags & TRANSPORT_PUSH_DRY_RUN)) {
struct ref *ref;
--
1.6.6.rc1.286.gbc15a
^ permalink raw reply related
* [PATCH resend 2/3] transport-helper.c::push_refs(): know more about refs before pushing
From: Tay Ray Chuan @ 2009-12-04 6:57 UTC (permalink / raw)
To: git
Cc: Shawn O. Pearce, Daniel Barkalow, Sverre Rabbelier,
Clemens Buchacher, Jeff King, Junio C Hamano
In-Reply-To: <20091204145437.1a9910db.rctay89@gmail.com>
Know about rejected non-fast-forward refs, in addition to up-to-date
ones, by calling set_ref_status_for_push() in remote.[ch], before
passing push commands to the helper.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
transport-helper.c | 10 +++-------
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index 11f3d7e..6ed7b55 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -334,16 +334,12 @@ static int push_refs(struct transport *transport,
else if (!mirror)
continue;
- ref->deletion = is_null_sha1(ref->new_sha1);
- if (!ref->deletion &&
- !hashcmp(ref->old_sha1, ref->new_sha1)) {
- ref->status = REF_STATUS_UPTODATE;
- continue;
- }
-
if (force_all)
ref->force = 1;
+ if (set_ref_status_for_push(ref, force_all))
+ continue;
+
strbuf_addstr(&buf, "push ");
if (!ref->deletion) {
if (ref->force)
--
1.6.6.rc1.286.gbc15a
^ permalink raw reply related
* [PATCH resend 1/3] refactor ref status logic for pushing
From: Tay Ray Chuan @ 2009-12-04 6:56 UTC (permalink / raw)
To: git
Cc: Shawn O. Pearce, Daniel Barkalow, Sverre Rabbelier,
Clemens Buchacher, Jeff King, Junio C Hamano
In-Reply-To: <20091204145437.1a9910db.rctay89@gmail.com>
Move the logic to a new function in remote.[ch],
set_ref_status_for_push().
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
builtin-send-pack.c | 39 +++------------------------------------
remote.c | 42 ++++++++++++++++++++++++++++++++++++++++++
remote.h | 1 +
3 files changed, 46 insertions(+), 36 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 8fffdbf..8c98624 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -412,44 +412,11 @@ int send_pack(struct send_pack_args *args,
else if (!args->send_mirror)
continue;
- ref->deletion = is_null_sha1(ref->new_sha1);
- if (ref->deletion && !allow_deleting_refs) {
- ref->status = REF_STATUS_REJECT_NODELETE;
- continue;
- }
- if (!ref->deletion &&
- !hashcmp(ref->old_sha1, ref->new_sha1)) {
- ref->status = REF_STATUS_UPTODATE;
+ if (set_ref_status_for_push(ref, args->force_update))
continue;
- }
- /* This part determines what can overwrite what.
- * The rules are:
- *
- * (0) you can always use --force or +A:B notation to
- * selectively force individual ref pairs.
- *
- * (1) if the old thing does not exist, it is OK.
- *
- * (2) if you do not have the old thing, you are not allowed
- * to overwrite it; you would not know what you are losing
- * otherwise.
- *
- * (3) if both new and old are commit-ish, and new is a
- * descendant of old, it is OK.
- *
- * (4) regardless of all of the above, removing :B is
- * always allowed.
- */
-
- ref->nonfastforward =
- !ref->deletion &&
- !is_null_sha1(ref->old_sha1) &&
- (!has_sha1_file(ref->old_sha1)
- || !ref_newer(ref->new_sha1, ref->old_sha1));
-
- if (ref->nonfastforward && !ref->force && !args->force_update) {
- ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
+ if (ref->deletion && !allow_deleting_refs) {
+ ref->status = REF_STATUS_REJECT_NODELETE;
continue;
}
diff --git a/remote.c b/remote.c
index e3afecd..188869a 100644
--- a/remote.c
+++ b/remote.c
@@ -1247,6 +1247,48 @@ int match_refs(struct ref *src, struct ref **dst,
return 0;
}
+int set_ref_status_for_push(struct ref *ref, int force_update)
+{
+ ref->deletion = is_null_sha1(ref->new_sha1);
+ if (!ref->deletion &&
+ !hashcmp(ref->old_sha1, ref->new_sha1)) {
+ ref->status = REF_STATUS_UPTODATE;
+ return 1;
+ }
+
+ /* This part determines what can overwrite what.
+ * The rules are:
+ *
+ * (0) you can always use --force or +A:B notation to
+ * selectively force individual ref pairs.
+ *
+ * (1) if the old thing does not exist, it is OK.
+ *
+ * (2) if you do not have the old thing, you are not allowed
+ * to overwrite it; you would not know what you are losing
+ * otherwise.
+ *
+ * (3) if both new and old are commit-ish, and new is a
+ * descendant of old, it is OK.
+ *
+ * (4) regardless of all of the above, removing :B is
+ * always allowed.
+ */
+
+ ref->nonfastforward =
+ !ref->deletion &&
+ !is_null_sha1(ref->old_sha1) &&
+ (!has_sha1_file(ref->old_sha1)
+ || !ref_newer(ref->new_sha1, ref->old_sha1));
+
+ if (ref->nonfastforward && !ref->force && !force_update) {
+ ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
+ return 1;
+ }
+
+ return 0;
+}
+
struct branch *branch_get(const char *name)
{
struct branch *ret;
diff --git a/remote.h b/remote.h
index 8b7ecf9..0f45553 100644
--- a/remote.h
+++ b/remote.h
@@ -98,6 +98,7 @@ char *apply_refspecs(struct refspec *refspecs, int nr_refspec,
int match_refs(struct ref *src, struct ref **dst,
int nr_refspec, const char **refspec, int all);
+int set_ref_status_for_push(struct ref *ref, int force_update);
/*
* Given a list of the remote refs and the specification of things to
--
1.6.6.rc1.286.gbc15a
^ permalink raw reply related
* [PATCH resend 0/3] transport: catch non-fast-forwards
From: Tay Ray Chuan @ 2009-12-04 6:54 UTC (permalink / raw)
To: git
Cc: Shawn O. Pearce, Daniel Barkalow, Sverre Rabbelier,
Clemens Buchacher, Jeff King, Junio C Hamano
This patch series applies on top of 'next', and deals with alerting
the user to non-fast-forward pushes when using helpers (smart).
Previously, git silently exited. This situation involves the curl
helper and the smart protocol. The fast-forward push is only detected
when curl executes the rpc client (git-send-pack). Now, we detect it
before telling the helper to push.
The first patch refactors ref status logic out of builtin-send-pack.c.
The second patch lets git know of non-fast-forwards before actually
telling the helper to push anything.
The third patch changes the return code when ref status indicate an
error (determined by push_had_errors()), so that the caller of
transport_push() is alerted.
PS. There are at least 2 bug fixes related to this series. If you
usually do so from repo.or.cz, please fetch from git.kernel.org; the
former is 2 days old.
builtin-send-pack.c | 39 +++------------------------------------
remote.c | 42 ++++++++++++++++++++++++++++++++++++++++++
remote.h | 1 +
transport-helper.c | 10 +++-------
transport.c | 11 +++++++----
5 files changed, 56 insertions(+), 47 deletions(-)
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.6.5.4
From: Matthieu Moy @ 2009-12-04 6:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: Eugene Sajine, Todd Zullinger, Michael J Gruber, Andreas Schwab,
git
In-Reply-To: <7vocmfxnxh.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Eugene Sajine <euguess@gmail.com> writes:
>
>> We have RH with xmlto 0.0.18. I was getting ready to update our
>> installation to 1.6.5.4, but as i understand the documentation will
>> not be fully available untill this issue is resolved. Could you,
>> please, advise if this is going to be in next 1.6.5.5?
>
> I've applied the patch in the thread you are responding to already on
> 'maint' so it will appear in both 1.6.5.5 and 1.6.6. In the meantime, if
> you want to run 1.6.5.4 or preferably 1.6.6-rc1, you can locally revert
> 8dd35c7 (Unconditionally set man.base.url.for.relative.links,
> 2009-12-03).
Also, one can download the man pages from git.git :
# in a clone of git://git.kernel.org/pub/scm/git/git.git
git archive --format=tar origin/man | tar -x -C /usr/share/man/ -vf -
(or leave with 1.6.5.5 and the docs of 1.6.5.4 for some time)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.6.5.4
From: Junio C Hamano @ 2009-12-04 6:18 UTC (permalink / raw)
To: Eugene Sajine
Cc: Junio C Hamano, Todd Zullinger, Michael J Gruber, Andreas Schwab,
git
In-Reply-To: <76c5b8580912031949k7f4193f9q94f9a2040b877571@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> We have RH with xmlto 0.0.18. I was getting ready to update our
> installation to 1.6.5.4, but as i understand the documentation will
> not be fully available untill this issue is resolved. Could you,
> please, advise if this is going to be in next 1.6.5.5?
I've applied the patch in the thread you are responding to already on
'maint' so it will appear in both 1.6.5.5 and 1.6.6. In the meantime, if
you want to run 1.6.5.4 or preferably 1.6.6-rc1, you can locally revert
8dd35c7 (Unconditionally set man.base.url.for.relative.links, 2009-12-03).
^ permalink raw reply
* [PATCH 1/3] refactor ref status logic for pushing
From: Tay Ray Chuan @ 2009-12-04 4:54 UTC (permalink / raw)
To: git; +Cc: Clemens Buchacher, Junio C Hamano
In-Reply-To: <20091204125042.c64f347d.rctay89@gmail.com>
Move the logic to a new function in remote.[ch],
set_ref_status_for_push().
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
builtin-send-pack.c | 39 +++------------------------------------
remote.c | 42 ++++++++++++++++++++++++++++++++++++++++++
remote.h | 1 +
3 files changed, 46 insertions(+), 36 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 8fffdbf..8c98624 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -412,44 +412,11 @@ int send_pack(struct send_pack_args *args,
else if (!args->send_mirror)
continue;
- ref->deletion = is_null_sha1(ref->new_sha1);
- if (ref->deletion && !allow_deleting_refs) {
- ref->status = REF_STATUS_REJECT_NODELETE;
- continue;
- }
- if (!ref->deletion &&
- !hashcmp(ref->old_sha1, ref->new_sha1)) {
- ref->status = REF_STATUS_UPTODATE;
+ if (set_ref_status_for_push(ref, args->force_update))
continue;
- }
- /* This part determines what can overwrite what.
- * The rules are:
- *
- * (0) you can always use --force or +A:B notation to
- * selectively force individual ref pairs.
- *
- * (1) if the old thing does not exist, it is OK.
- *
- * (2) if you do not have the old thing, you are not allowed
- * to overwrite it; you would not know what you are losing
- * otherwise.
- *
- * (3) if both new and old are commit-ish, and new is a
- * descendant of old, it is OK.
- *
- * (4) regardless of all of the above, removing :B is
- * always allowed.
- */
-
- ref->nonfastforward =
- !ref->deletion &&
- !is_null_sha1(ref->old_sha1) &&
- (!has_sha1_file(ref->old_sha1)
- || !ref_newer(ref->new_sha1, ref->old_sha1));
-
- if (ref->nonfastforward && !ref->force && !args->force_update) {
- ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
+ if (ref->deletion && !allow_deleting_refs) {
+ ref->status = REF_STATUS_REJECT_NODELETE;
continue;
}
diff --git a/remote.c b/remote.c
index e3afecd..188869a 100644
--- a/remote.c
+++ b/remote.c
@@ -1247,6 +1247,48 @@ int match_refs(struct ref *src, struct ref **dst,
return 0;
}
+int set_ref_status_for_push(struct ref *ref, int force_update)
+{
+ ref->deletion = is_null_sha1(ref->new_sha1);
+ if (!ref->deletion &&
+ !hashcmp(ref->old_sha1, ref->new_sha1)) {
+ ref->status = REF_STATUS_UPTODATE;
+ return 1;
+ }
+
+ /* This part determines what can overwrite what.
+ * The rules are:
+ *
+ * (0) you can always use --force or +A:B notation to
+ * selectively force individual ref pairs.
+ *
+ * (1) if the old thing does not exist, it is OK.
+ *
+ * (2) if you do not have the old thing, you are not allowed
+ * to overwrite it; you would not know what you are losing
+ * otherwise.
+ *
+ * (3) if both new and old are commit-ish, and new is a
+ * descendant of old, it is OK.
+ *
+ * (4) regardless of all of the above, removing :B is
+ * always allowed.
+ */
+
+ ref->nonfastforward =
+ !ref->deletion &&
+ !is_null_sha1(ref->old_sha1) &&
+ (!has_sha1_file(ref->old_sha1)
+ || !ref_newer(ref->new_sha1, ref->old_sha1));
+
+ if (ref->nonfastforward && !ref->force && !force_update) {
+ ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
+ return 1;
+ }
+
+ return 0;
+}
+
struct branch *branch_get(const char *name)
{
struct branch *ret;
diff --git a/remote.h b/remote.h
index 8b7ecf9..0f45553 100644
--- a/remote.h
+++ b/remote.h
@@ -98,6 +98,7 @@ char *apply_refspecs(struct refspec *refspecs, int nr_refspec,
int match_refs(struct ref *src, struct ref **dst,
int nr_refspec, const char **refspec, int all);
+int set_ref_status_for_push(struct ref *ref, int force_update);
/*
* Given a list of the remote refs and the specification of things to
--
1.6.6.rc1.286.gbc15a
^ permalink raw reply related
* Re: [ANNOUNCE] Git 1.6.5.4
From: Eugene Sajine @ 2009-12-04 3:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Todd Zullinger, Michael J Gruber, Andreas Schwab, git
In-Reply-To: <7vbpif4rn2.fsf@alter.siamese.dyndns.org>
On Thu, Dec 3, 2009 at 5:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Todd Zullinger <tmz@pobox.com> writes:
>
>> I tested with this in Documentation/manpage-base.xsl on a CentOS 5 box
>> and it builds fine, leaving no cruft in the man pages regarding the
>> man.base.url...
>>
>> <!-- set a base URL for relative links -->
>> <xsl:param name="man.base.url.for.relative.links"
>> >/path/to/git/docs</xsl:param>
>>
>> Of course, the relative links looked just like they did in older
>> docbook releases:
>>
>> 1. Everyday Git
>> everyday.html
>>
>> Is it worth the effort to have @@MAN_BASE_URL@@ in
>> Documentation/manpage-base.xsl or similar and replace it at build
>> time?
>
> I think it depends on the likelihood that a distro has xmlto so old that
> it does not understand --stringparam yet it uses stylesheet so new that
> setting the parameter makes a positive difference (either it gives the
> full URL or at least squelches the "You should define the parameter"
> noise) in the output.
>
> I am guessing that the answer would be that is a very unlikely combination
> and not worth worrying about it, but I've been wrong before in this exact
> area ;-)
Hello,
We have RH with xmlto 0.0.18. I was getting ready to update our
installation to 1.6.5.4, but as i understand the documentation will
not be fully available untill this issue is resolved. Could you,
please, advise if this is going to be in next 1.6.5.5?
Thanks,
Eugene
^ permalink raw reply
* Re: How do you best store structured data in git repositories?
From: Avery Pennarun @ 2009-12-04 1:45 UTC (permalink / raw)
To: David Aguilar; +Cc: sebastianspublicaddress, git
In-Reply-To: <20091204001359.GA6709@gmail.com>
On Thu, Dec 3, 2009 at 7:14 PM, David Aguilar <davvid@gmail.com> wrote:
> JSON's not too bad for data structures and is known to
> be friendly to XML expats.
>
> http://json.org/
yaml is also really good for storing structured data, and its
line-by-line format lends itself to easy merging (if you don't feel
like writing a custom merge algorithm).
Have fun,
Avery
^ 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