* Re: [PATCH] git-send-email: Generalize auto-cc recipient mechanism.
From: Sean @ 2007-12-26 4:54 UTC (permalink / raw)
To: David Brown; +Cc: git, Joel Becker, Junio C Hamano
In-Reply-To: <1198641389-959-1-git-send-email-git@davidb.org>
On Tue, 25 Dec 2007 19:56:29 -0800
David Brown <git@davidb.org> wrote:
> Add a new option --suppress-cc, which can be specified one or more
> times to list the categories of auto-cc fields that should be
> suppressed. If not specified, it defaults to values to give the same
> behavior as specified by --suppress-from, and --signed-off-cc. The
> categories are:
>
> self - patch sender. Same as --suppress-from.
> author - patch author.
> cc - cc lines mentioned in the patch.
> cccmd - avoid running the cccmd.
> sob - signed off by lines.
> all - all non-explicit recipients
>
Hi Dave,
It's great to see you're taking care of this issue, it's one that i've tripped over
a few times. If your patch is accepted as-is, i think it's an improvement.
But i wonder about the case where a user has "sendemail.suppresscc = all" in their
~/.gitconfig. For the occasion when they do want to cc the author of
a patch, what do they do? The above UI seems to lack a way to enable a cc option
that has been disabled by default.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] git-send-email: Generalize auto-cc recipient mechanism.
From: David Brown @ 2007-12-26 5:32 UTC (permalink / raw)
To: Sean; +Cc: git, Joel Becker, Junio C Hamano
In-Reply-To: <BAYC1-PASMTP131135B69209F6EB72F809AE5B0@CEZ.ICE>
On Tue, Dec 25, 2007 at 11:54:38PM -0500, Sean wrote:
>But i wonder about the case where a user has "sendemail.suppresscc = all" in their
>~/.gitconfig. For the occasion when they do want to cc the author of
>a patch, what do they do? The above UI seems to lack a way to enable a cc option
>that has been disabled by default.
Well, in that instance, --no-suppress-from would override that, if I did it
right. Perhaps we could add an unsuppress-cc option, but then the whole
thing is starting to get more complicated than I think it really needs to
be.
My suggestion would be to keep this patch as is, and if the people using it
decide they want the override option, we/I can figure out how to add it.
Dave
^ permalink raw reply
* Re: [PATCH] Force new line at end of commit message
From: Bernt Hansen @ 2007-12-26 17:47 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20071225044202.GO14735@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> This is a patch for git-gui, so why not make that clear in the subject?
>> (And I have a hunch that Shawn would have liked the patch relative to
>> git-gui.git, not git.git...)
>
> Indeed.
>
> its clear in both the email and in the commit log that the change is
> a git-gui change. Remember, git-gui's logs show up in the core Git
> logs (as its merged with -s subtree) so having that git-gui: prefix
> does help people to localize the change within the overall suite.
>
Thanks for the feedback on the patch.
This is my first attempt at creating a patch for git (even if it is
mostly trivial in this case) and I wasn't aware of the git-gui.gitk repo
and conventions regarding the commit message. I just tried to follow
what was in Documentation/SubmittingPatches. I'll try to do better next
time :)
>> Further, there are other tools than rebase -i that like commit messages
>> better when terminated by a newline, and _that_ is what I would like to
>> read in the commit message for this patch.
>
> Hmmph. For that reason alone I'm tempted to *not* apply Bernt's
> patch.
>
> There is nothing that requires that a commit object end with an LF.
> So tools that make this assumption (that there is a trailing LF)
> while processing the body of a commit message are quite simply
> broken.
Forcing a LF on the end of the commit message feels wrong to me too.
This band-aid solution fixes the issue I'm dealing with for
git-rebase -i when squashing 3 or more commits created by git-gui.
I agree with Sean and think the more correct fix would be to make
git rebase -i and any other tools we encounter with similar problems
handle the case where there is no newline at the end of the commit
message.
The patch as it stands should probably not be applied.
-Bernt
^ permalink raw reply
* Re: [PATCH] Force new line at end of commit message
From: Junio C Hamano @ 2007-12-26 19:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Bernt Hansen, git
In-Reply-To: <20071225044202.GO14735@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> There is nothing that requires that a commit object end with an LF.
> So tools that make this assumption (that there is a trailing LF)
> while processing the body of a commit message are quite simply
> broken.
> ...
> IMHO git-gui is producing valid commit messages, and always does
> so with no trailing LF, and any tool that is assuming a trailing
> LF is always present is broken.
I would not go that far, even though I would agree that the
consumers of existing commits should be lenient and the creators
of new commits should be strict.
Now, "strict" and "lenient" are both relative to some yardstick,
but relative to what? I would say that the UI layer of "git the
SCM" is about helping humans create commit messages for human
consumption, even though the low-level commit objects are
equipped to record any binary blob (including NUL byte).
As UI layer programs, I think "git commit" and "git rebase -i"
can and should be stricter than allowing "arbitrary binary
blobs". Namely, they should make sure what they produce are
good text messages (and a good text message ends with a LF ---
prepare a file with an incomplete line, run "cat file" from
interactive shell on it, and see your prompt tucked at the end
before arguing otherwise).
So how about doing something like this?
---
git-rebase--interactive.sh | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 090c3e5..d0d83c3 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -215,15 +215,17 @@ make_squash_message () {
COUNT=$(($(sed -n "s/^# This is [^0-9]*\([1-9][0-9]*\).*/\1/p" \
< "$SQUASH_MSG" | tail -n 1)+1))
echo "# This is a combination of $COUNT commits."
- sed -n "2,\$p" < "$SQUASH_MSG"
+ sed -e 1d -e '2,/^./{
+ /^$/d
+ }' <"$SQUASH_MSG"
else
COUNT=2
echo "# This is a combination of two commits."
echo "# The first commit's message is:"
echo
git cat-file commit HEAD | sed -e '1,/^$/d'
- echo
fi
+ echo
echo "# This is the $(nth_string $COUNT) commit message:"
echo
git cat-file commit $1 | sed -e '1,/^$/d'
^ permalink raw reply related
* Re: [PATCH] Fix "git log --diff-filter" bug
From: Junio C Hamano @ 2007-12-26 19:41 UTC (permalink / raw)
To: Arjen Laarhoven; +Cc: git
In-Reply-To: <1198580807-18802-1-git-send-email-arjen@yaph.org>
Thanks. Some tests?
^ permalink raw reply
* Re: [ANNOUNCE] qgit2.1rc1_win.exe
From: Peter Klavins @ 2007-12-26 21:22 UTC (permalink / raw)
To: msysgit-/JYPxA39Uh5TLH3MbocFFw; +Cc: git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <e5bfff550712240113y4acdaa11y3483705172a5980e-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> You can find an auto-extract zip file with a version of qgit built for
> Windows (Vista).
I found it a bit obscure as to how to rebuild qgit from scratch on Vista, so
just for the record:
# Set up VS2008
1. Install Visual Studio 2008
# Set up Qt4
2. Download qt-win-opensource-src-4.3.3.zip from
http://trolltech.com/developer/downloads/qt/windows and unzip into directory
(e.g.,) C:\qt-win-opensource-src-4.3.3
3. cd C:\qt-win-opensource-src-4.3.3
4. configure (takes significant time, around 10 minutes from
memory)
5. nmake (takes over an hour on a Core 2 Duo 2 GHz,
consumes 2 GByte of disk)
# Install git and use it to get qgit4 source
6. Download Git-1.5.4-rc1-preview20071221-corrected.exe from
http://code.google.com/p/msysgit/downloads/ and install (default directory
C:\Program Files\Git is fine)
7. Open Git Bash from Start menu, set up Src directory (e.g., mkdir Src, cd
Src)
8. git clone git://git.kernel.org/pub/scm/qgit/qgit4.git (to get qgit
sources into Src/qgit4)
9. Exit Git Bash shell
# Build and run qgit
10. Open VS2008 command prompt, ensuring that VS tools are on the PATH by
test invoking 'nmake'
11. Add qmake to path with PATH=C:\qt-win-opensource-src-4.3.3\bin;%PATH%
12. Add git to path with PATH=C:\Program Files\Git\bin;%PATH%
13. Navigate to qgit4 directory (e.g., cd C:\Users\<you>\Src\qgit4)
14. qmake (to preprocess with Qt4)
15. nmake (to build debug version)
16. bin\qgit (to run qgit to browse qgit4's own repository!)
------------------------------------------------------------------------
Peter Klavins
^ permalink raw reply
* Using git for file archival/backup purposes - deletion strategy
From: Martin Langhoff @ 2007-12-26 22:43 UTC (permalink / raw)
To: Git Mailing List
Hi list!
I am drafting a tool to use GIT as a behind-the-scenes archival/backup
tool for web applications. There's been countless threads covering
generic file archival, discussing /etc and homedirs, so I am pretty
comfortable with the mechanics and the whole idea. This is a fairly
narrow use, where the web apps are reasonable well behaved -- most
(all?) of the caveats in ~ and /etc archival seem to be under control.
What I am not 100% clear on is the "old history" deletion strategy.
The history will be *strictly* linear, so my intention is to keep the
last N commits, by overriding the parent of the Nth commit that git
log lists with a "shallow" entry in $GIT_DIR/shallow as documented in
Documentation/technical/shallow.txt , and call gc after that.
Is that the correct way to "forget" old history? Searching high and
low in the list, I fail to find a definitive answer. Shallow and
grafts entries are discussed as ways of doing this, but I can't find a
"correct" way of doing this.
BTW I've just done a git clone --depth 10 ~/src/git and while I do get
a clearly "shallow" checkout, with a tiny .git/objects directory, I
can't find any file called shallow, or grafts. .git/config doesn't say
anything either, and alternates is empty. I frankly cannot tell how
git recognizes it as a shallow repo.
Ah! Local clones won't honour --depth!. A clone from git.kernel.org
does get its .git/shallow file.
So the question is: is it safe (and enough) to add the SHA1 to the
.git/shallow file and call git gc? Is there a better way?
cheers,
m
^ permalink raw reply
* Re: [ANNOUNCE] qgit2.1rc1_win.exe
From: Marco Costalba @ 2007-12-26 23:23 UTC (permalink / raw)
To: Peter Klavins; +Cc: git-u79uwXL29TY76Z2rM5mHXA, msysgit-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <fkugn8$d2s$1@ger.gmane.org>
On Dec 26, 2007 10:22 PM, Peter Klavins <klavins-ooduxAEi7gXtt0EhB6fy4g@public.gmane.org> wrote:
>
> 4. configure (takes significant time, around 10 minutes from
> memory)
configure -fast -no-qt3support -static -release -no-qmake
Takes much less (about one minute)
> 5. nmake (takes over an hour on a Core 2 Duo 2 GHz,
> consumes 2 GByte of disk)
>
2GBytes because default configure is -debug, but giving -release
instead the needed space is much less because debug symbols are not
built.
Also use:
nmake sub-src
30minutes on my Core Duo 1.5Ghz. It just compiles the Qt libraries
under src directory, not Qt tools like designer, assistant and
expecially the Qt examples.
Note: first you need to run nmake to build makefile then, just after
the makefile in main directory is built (few seconds) you can stop it
and run nmake sub-src.
> 16. bin\qgit (to run qgit to browse qgit4's own repository!)
>
msysgit must be in PATH, both Git\cmd and Git\bin. Or you can use the
launch script start_qgit.bat that just adds msysgit to the PATH for
you before to call qgit.exe
> ------------------------------------------------------------------------
> Peter Klavins
>
Thanks Peter,
Just a question. How about using the auto-extract zip I advertise in
this thread? With this both Qt and qgit are already compiled and
should be ready to go.
Marco
^ permalink raw reply
* Re: [ANNOUNCE] qgit2.1rc1_win.exe
From: Peter Klavins @ 2007-12-26 23:37 UTC (permalink / raw)
To: msysgit-/JYPxA39Uh5TLH3MbocFFw; +Cc: git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <e5bfff550712261523g7aab6e76nd37257e7b21d1653-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> Just a question. How about using the auto-extract zip I advertise in
> this thread? With this both Qt and qgit are already compiled and
> should be ready to go.
I did use your auto-extract utility, and it worked as advertised, thanks.
Just as an aside, I think it would be better for it to also package git
(msysgit version), so there's no need to search for git and pre-download it.
But being and old engineer at heart, I had to understand how to build qgit
from scratch, and not being at all familiar with Qt, it was difficult to get
it working, thus I wrote the note just in case others were having similar
difficulties. I appreciate your clarification of the build steps.
Do you think it's worthwhile adding this info into your README?
------------------------------------------------------------------------
Peter Klavins
^ permalink raw reply
* Re: [PATCH] Reallow git-rebase --interactive --continue if commit is unnecessary
From: Junio C Hamano @ 2007-12-26 23:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, Bernt Hansen, git
In-Reply-To: <7vy7bppv3s.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Will do, but the code looks quite bad (not entirely your fault).
>
> Line by line comment to show my puzzlement.
>
> # commit if necessary
>
> Ok, the user has prepared the index for us, and we are going to do some
> tests and conditionally create commit.
>
> git rev-parse --verify HEAD > /dev/null &&
>
> Do we have HEAD commit? Why check this --- we do not want to rebase
> from the beginning of time? No, that's not it. If this fails, there is
> something seriously wrong. This is not about "will we make a commit?"
> check at all. This is a basic sanity check and if it fails we must
> abort, not just skip.
>
> git update-index --refresh &&
> git diff-files --quiet &&
>
> Is the work tree clean with respect to the index? Why check this --- we
> want to skip the commit if work tree is dirty? Or is this trying to
> enforce the invariant that during the rebase the work tree and index and
> HEAD should all match? If the latter, failure from this again is a
> reason to abort.
>
> ! git diff-index --cached --quiet HEAD -- &&
>
> Do we have something to commit? This needs to be checked so that we can
> skip a commit that results in emptyness, so using this as a check to see
> if we should commit makes sense.
>
> . "$DOTEST"/author-script && {
> test ! -f "$DOTEST"/amend || git reset --soft HEAD^
> } &&
>
> Find GIT_AUTHOR_* variables and if we are amending rewind the HEAD. The
> failure from this is a grave problem and reason to abort, isn't it?
>
> export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&
> git commit --no-verify -F "$DOTEST"/message -e
>
> Then we go on to create commit. As you said, failure from this is a
> grave error.
Any response to this or problems in the clean-up patch?
> ---
> git-rebase--interactive.sh | 29 +++++++++++++++++++----------
> 1 files changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 090c3e5..7aa4278 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -363,17 +363,26 @@ do
>
> test -d "$DOTEST" || die "No interactive rebase running"
>
> - # commit if necessary
> - git rev-parse --verify HEAD > /dev/null &&
> - git update-index --refresh &&
> - git diff-files --quiet &&
> - ! git diff-index --cached --quiet HEAD -- &&
> - . "$DOTEST"/author-script && {
> - test ! -f "$DOTEST"/amend || git reset --soft HEAD^
> - } &&
> - export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&
> - if ! git commit --no-verify -F "$DOTEST"/message -e
> + # Sanity check
> + git rev-parse --verify HEAD >/dev/null ||
> + die "Cannot read HEAD"
> + git update-index --refresh && git diff-files --quiet ||
> + die "Working tree is dirty"
> +
> + # do we have anything to commit?
> + if git diff-index --cached --quiet HEAD --
> then
> + : Nothing to commit -- skip this
> + else
> + . "$DOTEST"/author-script ||
> + die "Cannot find the author identity"
> + if test -f "$DOTEST"/amend
> + then
> + git reset --soft HEAD^ ||
> + die "Cannot rewind the HEAD"
> + fi
> + export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&
> + git commit --no-verify -F "$DOTEST"/message -e ||
> die "Could not commit staged changes."
> fi
>
^ permalink raw reply
* Re: [PATCH 4/4] Allow selection of different cleanup modes for commit messages
From: Junio C Hamano @ 2007-12-26 23:54 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Linus Torvalds
In-Reply-To: <1198382136-15724-4-git-send-email-gitster@pobox.com>
Junio C Hamano <gitster@pobox.com> writes:
> From: Alex Riesen <raa.lkml@gmail.com>
> Date: Sat, 22 Dec 2007 19:46:24 +0100
>
> Although we traditionally stripped away excess blank lines, trailing
> whitespaces and lines that begin with "#" from the commit log message,
> sometimes the message just has to be the way user wants it.
> ...
Any comments on the cleaned-up series?
^ permalink raw reply
* Re: [PATCH 4/4] Allow selection of different cleanup modes for commit messages
From: Linus Torvalds @ 2007-12-27 0:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vmyrxm2qh.fsf@gitster.siamese.dyndns.org>
On Wed, 26 Dec 2007, Junio C Hamano wrote:
>
> Any comments on the cleaned-up series?
Me likee. I think there's still room for some possible future discussions
(the whole "flag in the file to allow the editor to choose" kind of
thing), but this seems like a good improvement on the current state.
Linus
^ permalink raw reply
* Re: [PATCH] combine-diff: use diff_opts->a_prefix
From: Junio C Hamano @ 2007-12-27 0:57 UTC (permalink / raw)
To: Salikh Zakirov; +Cc: Git Mailing List
In-Reply-To: <477109A5.9040000@gmail.com>
Salikh Zakirov <salikh@gmail.com> writes:
> The introduction of configurable dir prefix for diff headers in commit
> eab9a40b 'Teach diff machinery to display other prefixes than "a/" and "b/"'
> missed combined diff generation.
>
> Signed-off-by: Salikh Zakirov <salikh@gmail.com>
> ---
>
> I realize that this fix is ugly, so I am all ears for a suggestion
> of a better fix.
It is not so ugly, but I think the original code is broken wrt
its calling of quote_c_style(). It will output "a/" literally
and then would spit out the path with quoting. IOW, you would
get something like:
--- a/"foo\tbar"
+++ b/"foo\tbar"
when it should show:
--- "a/foo\tbar"
+++ "b/foo\tbar"
Incidentally, I just noticed that diff.c::emit_rewrite_diff()
has the same bug.
Here is a fix to combine-diff.c
-- >8 --
[PATCH] combine-diff: Fix path quoting
Earlier when showing combined diff, the filenames on the ---/+++
header lines were quoted incorrectly. a/ (or b/) prefix was
output literally and then the path was output, with c-quoting.
This fixes the quoting logic, and while at it, adjusts the code
to use the customizable prefix (a_prefix and b_prefix)
introduced recently.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
combine-diff.c | 41 +++++++++++++++++++++++++++++++----------
1 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index e22db89..7d71033 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -646,12 +646,28 @@ static void reuse_combine_diff(struct sline *sline, unsigned long cnt,
sline->p_lno[i] = sline->p_lno[j];
}
-static void dump_quoted_path(const char *prefix, const char *path,
+static void dump_quoted_path(const char *head,
+ const char *prefix,
+ const char *path,
const char *c_meta, const char *c_reset)
{
- printf("%s%s", c_meta, prefix);
- quote_c_style(path, NULL, stdout, 0);
- printf("%s\n", c_reset);
+ static struct strbuf buf = STRBUF_INIT;
+
+ strbuf_reset(&buf);
+ strbuf_addstr(&buf, c_meta);
+ strbuf_addstr(&buf, head);
+ if (quote_c_style(prefix, NULL, NULL, 0) ||
+ quote_c_style(path, NULL, NULL, 0)) {
+ strbuf_addch(&buf, '"');
+ quote_c_style(prefix, &buf, NULL, 1);
+ quote_c_style(path, &buf, NULL, 1);
+ strbuf_addch(&buf, '"');
+ } else {
+ strbuf_addstr(&buf, prefix);
+ strbuf_addstr(&buf, path);
+ }
+ strbuf_addstr(&buf, c_reset);
+ puts(buf.buf);
}
static void show_patch_diff(struct combine_diff_path *elem, int num_parent,
@@ -793,7 +809,7 @@ static void show_patch_diff(struct combine_diff_path *elem, int num_parent,
if (rev->loginfo && !rev->no_commit_id)
show_log(rev, opt->msg_sep);
dump_quoted_path(dense ? "diff --cc " : "diff --combined ",
- elem->path, c_meta, c_reset);
+ "", elem->path, c_meta, c_reset);
printf("%sindex ", c_meta);
for (i = 0; i < num_parent; i++) {
abb = find_unique_abbrev(elem->parent[i].sha1,
@@ -829,14 +845,19 @@ static void show_patch_diff(struct combine_diff_path *elem, int num_parent,
printf("%s\n", c_reset);
}
if (added)
- dump_quoted_path("--- /dev/", "null", c_meta, c_reset);
+ dump_quoted_path("--- ", "", "/dev/null",
+ c_meta, c_reset);
else
- dump_quoted_path("--- a/", elem->path, c_meta, c_reset);
+ dump_quoted_path("--- ", opt->a_prefix, elem->path,
+ c_meta, c_reset);
if (deleted)
- dump_quoted_path("+++ /dev/", "null", c_meta, c_reset);
+ dump_quoted_path("+++ ", "", "/dev/null",
+ c_meta, c_reset);
else
- dump_quoted_path("+++ b/", elem->path, c_meta, c_reset);
- dump_sline(sline, cnt, num_parent, DIFF_OPT_TST(opt, COLOR_DIFF));
+ dump_quoted_path("+++ ", opt->b_prefix, elem->path,
+ c_meta, c_reset);
+ dump_sline(sline, cnt, num_parent,
+ DIFF_OPT_TST(opt, COLOR_DIFF));
}
free(result);
--
1.5.4.rc1.23.g3a969
^ permalink raw reply related
* [PATCH] Fix rewrite_diff() name quoting.
From: Junio C Hamano @ 2007-12-27 1:19 UTC (permalink / raw)
To: Salikh Zakirov; +Cc: Git Mailing List
In-Reply-To: <7vodcdkl82.fsf@gitster.siamese.dyndns.org>
This moves the logic to quote two paths (prefix + path) in
C-style introduced in the previous commit from the
dump_quoted_path() in combine-diff.c to quote.c, and uses it to
fix rewrite_diff() that never C-quoted the pathnames correctly.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
combine-diff.c | 11 +----------
diff.c | 12 +++++++++---
quote.c | 16 ++++++++++++++++
quote.h | 1 +
4 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index 7d71033..0e19cba 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -656,16 +656,7 @@ static void dump_quoted_path(const char *head,
strbuf_reset(&buf);
strbuf_addstr(&buf, c_meta);
strbuf_addstr(&buf, head);
- if (quote_c_style(prefix, NULL, NULL, 0) ||
- quote_c_style(path, NULL, NULL, 0)) {
- strbuf_addch(&buf, '"');
- quote_c_style(prefix, &buf, NULL, 1);
- quote_c_style(path, &buf, NULL, 1);
- strbuf_addch(&buf, '"');
- } else {
- strbuf_addstr(&buf, prefix);
- strbuf_addstr(&buf, path);
- }
+ quote_two_c_style(&buf, prefix, path, 0);
strbuf_addstr(&buf, c_reset);
puts(buf.buf);
}
diff --git a/diff.c b/diff.c
index 61fd492..5bdc111 100644
--- a/diff.c
+++ b/diff.c
@@ -300,19 +300,25 @@ static void emit_rewrite_diff(const char *name_a,
const char *old = diff_get_color(color_diff, DIFF_FILE_OLD);
const char *new = diff_get_color(color_diff, DIFF_FILE_NEW);
const char *reset = diff_get_color(color_diff, DIFF_RESET);
+ static struct strbuf a_name = STRBUF_INIT, b_name = STRBUF_INIT;
name_a += (*name_a == '/');
name_b += (*name_b == '/');
name_a_tab = strchr(name_a, ' ') ? "\t" : "";
name_b_tab = strchr(name_b, ' ') ? "\t" : "";
+ strbuf_reset(&a_name);
+ strbuf_reset(&b_name);
+ quote_two_c_style(&a_name, o->a_prefix, name_a, 0);
+ quote_two_c_style(&b_name, o->b_prefix, name_b, 0);
+
diff_populate_filespec(one, 0);
diff_populate_filespec(two, 0);
lc_a = count_lines(one->data, one->size);
lc_b = count_lines(two->data, two->size);
- printf("%s--- %s%s%s%s\n%s+++ %s%s%s%s\n%s@@ -",
- metainfo, o->a_prefix, name_a, name_a_tab, reset,
- metainfo, o->b_prefix, name_b, name_b_tab, reset, fraginfo);
+ printf("%s--- %s%s%s\n%s+++ %s%s%s\n%s@@ -",
+ metainfo, a_name.buf, name_a_tab, reset,
+ metainfo, b_name.buf, name_b_tab, reset, fraginfo);
print_line_count(lc_a);
printf(" +");
print_line_count(lc_b);
diff --git a/quote.c b/quote.c
index 6986b44..d061626 100644
--- a/quote.c
+++ b/quote.c
@@ -213,6 +213,22 @@ size_t quote_c_style(const char *name, struct strbuf *sb, FILE *fp, int nodq)
return quote_c_style_counted(name, -1, sb, fp, nodq);
}
+void quote_two_c_style(struct strbuf *sb, const char *prefix, const char *path, int nodq)
+{
+ if (quote_c_style(prefix, NULL, NULL, 0) ||
+ quote_c_style(path, NULL, NULL, 0)) {
+ if (!nodq)
+ strbuf_addch(sb, '"');
+ quote_c_style(prefix, sb, NULL, 1);
+ quote_c_style(path, sb, NULL, 1);
+ if (!nodq)
+ strbuf_addch(sb, '"');
+ } else {
+ strbuf_addstr(sb, prefix);
+ strbuf_addstr(sb, path);
+ }
+}
+
void write_name_quoted(const char *name, FILE *fp, int terminator)
{
if (terminator) {
diff --git a/quote.h b/quote.h
index ab7596f..4da110e 100644
--- a/quote.h
+++ b/quote.h
@@ -41,6 +41,7 @@ extern char *sq_dequote(char *);
extern int unquote_c_style(struct strbuf *, const char *quoted, const char **endp);
extern size_t quote_c_style(const char *name, struct strbuf *, FILE *, int no_dq);
+extern void quote_two_c_style(struct strbuf *, const char *, const char *, int);
extern void write_name_quoted(const char *name, FILE *, int terminator);
extern void write_name_quotedpfx(const char *pfx, size_t pfxlen,
--
1.5.4.rc1.23.g3a969
^ permalink raw reply related
* [ANNOUNCE] GIT 1.5.4-rc2
From: Junio C Hamano @ 2007-12-27 3:36 UTC (permalink / raw)
To: git
GIT 1.5.4-rc2 is available at the usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.4.rc2.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.4.rc2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.4.rc2.tar.{gz,bz2} (preformatted docs)
testing/*-1.5.4.rc2-1.*.rpm (RPM)
This round we still did not manage to keep non-fixes out, and
you can now tell "git commit" to keep the "# comment" lines in
the message, but otherwise the changes are all fixes, fixes and
fixes.
----------------------------------------------------------------
Changes since v1.5.4-rc1 are as follows:
Alex Riesen (1):
Allow selection of different cleanup modes for commit messages
Arjen Laarhoven (1):
Fix "git log --diff-filter" bug
Charles Bailey (1):
Remove old generated files from .gitignore.
Gustaf Hendeby (2):
Make git send-email accept $EDITOR with arguments
shortlog manpage documentation: work around asciidoc markup issues
Jakub Narebski (1):
gitweb: fix whitespace in config_to_multi (indent with tab)
Jeff King (2):
clean up 1.5.4 release notes
cvsimport: die on cvsps errors
Jim Meyering (1):
Don't dereference NULL upon lookup failure.
Johannes Schindelin (2):
Teach diff machinery to display other prefixes than "a/" and "b/"
Mention git-shell's "cvs" substitution in the RelNotes
Junio C Hamano (14):
t4024: fix test script to use simpler sed pattern
fix git commit --amend -m "new message"
shell-scripts usage(): consistently exit with non-zero
Documentation: ls-files -v is about "assume unchanged".
Fix $EDITOR regression introduced by rewrite in C.
t7005: do not exit inside test.
builtin-commit: fix amending of the initial commit
builtin-commit: avoid double-negation in the code.
Documentation: describe 'union' low-level merge driver
Fix documentation of --first-parent in git-log and copy it to git-rev-list
combine-diff: Fix path quoting
Fix rewrite_diff() name quoting.
contrib: resurrect scripted git-revert.
GIT 1.5.4-rc2
Linus Torvalds (1):
Re(-re)*fix trim_common_tail()
Miklos Vajna (1):
everyday: replace 'prune' and 'repack' with 'gc'
Pierre Habouzit (3):
git-tag: fix -l switch handling regression.
Force the sticked form for options with optional arguments.
parse-options: Add a gitcli(5) man page.
René Scharfe (1):
Make "--pretty=format" parser a bit more careful.
Shawn O. Pearce (2):
Reallow git-rebase --interactive --continue if commit is unnecessary
Improve error messages when int/long cannot be parsed from config
Stefan Sperling (1):
Small comment fix for git-cvsimport.
Wincent Colaiuta (1):
Emit helpful status for accidental "git stash" save
^ permalink raw reply
* [PATCH] Point out merged submodule maintainers as better addresses for patches
From: Shawn O. Pearce @ 2007-12-27 4:12 UTC (permalink / raw)
To: Junio C Hamano, paulus; +Cc: git
Junio doesn't directly manage the git-gui or gitk-git subdirectories
within git.git; these are currently managed by other individuals
and then periodically merged to git.git. Users often send patches
to Junio for these directories when they should be directed at the
current maintainer instead, so we should point out these special
cases in the SubmittingPatches documentation.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Just a suggestion. Might help people who are new to the Git
community to get involved.
Documentation/SubmittingPatches | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index de08d09..b7c886c 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -34,10 +34,16 @@ Checklist (and a short version for the impatient):
- if your name is not writable in ASCII, make sure that
you send off a message in the correct encoding.
- send the patch to the list (git@vger.kernel.org) and the
- maintainer (gitster@pobox.com). If you use
+ active maintainer (see below). If you use
git-send-email(1), please test it first by sending
email to yourself.
+ Active maintainers:
+
+ - git-gui/ submodule: spearce@spearce.org
+ - gitk-git/ submodule: paulus@samba.org
+ - Everything else: gitster@pobox.com
+
Long version:
I started reading over the SubmittingPatches document for Linux
--
1.5.4.rc2.1097.gb6e0d
^ permalink raw reply related
* Re: [PATCH] Force new line at end of commit message
From: Shawn O. Pearce @ 2007-12-27 4:19 UTC (permalink / raw)
To: Bernt Hansen; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <87myrxqrev.fsf@gollum.intra.norang.ca>
Bernt Hansen <bernt@alumni.uwaterloo.ca> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> >
> > its clear in both the email and in the commit log that the change is
> > a git-gui change. Remember, git-gui's logs show up in the core Git
> > logs (as its merged with -s subtree) so having that git-gui: prefix
> > does help people to localize the change within the overall suite.
>
> This is my first attempt at creating a patch for git (even if it is
> mostly trivial in this case) and I wasn't aware of the git-gui.gitk repo
> and conventions regarding the commit message. I just tried to follow
> what was in Documentation/SubmittingPatches. I'll try to do better next
> time :)
Its a good first attempt. I also just sent a patch to Junio to try
and make this "special case" of directing git-gui changes to me more
clear for new folk.
> Forcing a LF on the end of the commit message feels wrong to me too.
I think Junio just convinced me otherwise.
We probably should change git-gui to always end the last line of
the message with an LF. To be honest I'm not really sure why it
doesn't do that now. ;-)
> The patch as it stands should probably not be applied.
But I think that is now only because the commit message could be
clarified to state that its for git-gui (e.g. start with "git-gui:")
and probably shouldn't be so specific to rebase -i's breakage but
instead talk about how its good to be strict in what you create,
and lenient in what you accept, and since we're creating here,
we should always try to Do The Right Thing(tm).
If you respin the patch with a more descriptive message I'll put
it into 0.9.1.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Point out merged submodule maintainers as better addresses for patches
From: Junio C Hamano @ 2007-12-27 4:37 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: paulus, git
In-Reply-To: <20071227041220.GA22256@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio doesn't directly manage the git-gui or gitk-git subdirectories
> within git.git; these are currently managed by other individuals
> and then periodically merged to git.git. Users often send patches
> to Junio for these directories when they should be directed at the
> current maintainer instead, so we should point out these special
> cases in the SubmittingPatches documentation.
This is a good start, but I think it would be good to mention
that contributors should at least Cc: the people who have been
heavily involved in the past in the surrounding area of the code
or documentation (not necessarily the last person who touched
the area) the patch attempts to improve and/or enhance.
Parts of the system are "actively managed" by people other than
me even though they aren't merged with the subtree strategy.
The areas I mentioned in MaintNotes (in 'todo') are:
- git-svn is generally deferred to Eric, unless the patch is
truly trivial.
- Documentation/user-manual.txt is primarily JBF's bailiwick.
- Nico is the guy around pack generation.
- Jakub, Luben and Pasky are more familiar than I am with
gitweb.
In fact, I would rather see any nontrivial patch to be first
sent "To: " such people with "Cc: " the list. After it has been
improved into a good enough shape in the discussion that follows
(i.e. success stories to back it up, and without regression
reports and objections), I can pick up the last round directly
from the list, or the active maintainer in the area (if exists;
it might be a better wording to call them "subsystem
maintainers") can forward it to me to apply after a final
submission is made. Sending the final submission to the
subsystem maintainer who forwards it to the higher level is what
the kernel folks regularly do, but I do not think we are large
enough to require such a formality.
^ permalink raw reply
* Re: Using git for file archival/backup purposes - deletion strategy
From: Johannes Sixt @ 2007-12-27 9:18 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90712261443t6aa0cd76u46d8ae88fc7c1eba@mail.gmail.com>
Martin Langhoff schrieb:
> What I am not 100% clear on is the "old history" deletion strategy.
> The history will be *strictly* linear, so my intention is to keep the
> last N commits, by overriding the parent of the Nth commit that git
> log lists with a "shallow" entry in $GIT_DIR/shallow as documented in
> Documentation/technical/shallow.txt , and call gc after that.
>
> Is that the correct way to "forget" old history? Searching high and
> low in the list, I fail to find a definitive answer. Shallow and
> grafts entries are discussed as ways of doing this, but I can't find a
> "correct" way of doing this.
I'm doing something like this. Basically:
git rev-parse "HEAD~$N" > .git/info/grafts
git filter-branch -f HEAD
If you omit filter-branch, then a repack -a -d will corrupt the repository
(I think) unless you keep the grafts file with it and in all its clones
forever.
-- Hannes
^ permalink raw reply
* Re: [PATCH] git-pull: don't complain about branch merge config if only fetching tags
From: Gerrit Pape @ 2007-12-27 9:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x3oatvi.fsf@gitster.siamese.dyndns.org>
On Fri, Dec 21, 2007 at 08:35:13AM -0800, Junio C Hamano wrote:
> Gerrit Pape <pape@smarden.org> writes:
> > When running git pull with the -t switch, it properly fetches tags, but
> > complains about missing information on how to merge. Since there's
> > nothing to merge, make git-pull simply exit after fetching the tags.
> I've seen this patch on this list in the past, but isn't "git
> pull -t" a user-error?
If so, we shouldn't advertise the -t switch in the git-pull(1) manpage.
As it stands, I'd understand 'git pull -t' as 'fetch _all_ tags and
branch heads and merge according to the configuration'.
Regards, Gerrit.
^ permalink raw reply
* Re: [PATCH] git-pull: don't complain about branch merge config if only fetching tags
From: Junio C Hamano @ 2007-12-27 10:39 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20071227093016.18337.qmail@e6d9fb481b7087.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
>> I've seen this patch on this list in the past, but isn't "git
>> pull -t" a user-error?
>
> If so, we shouldn't advertise the -t switch in the git-pull(1) manpage.
Perhaps. Patches are welcomed as always.
> As it stands, I'd understand 'git pull -t' as 'fetch _all_ tags and
> branch heads and merge according to the configuration'.
Yeah, but that would mean that the current error message needs
to be kept, as that is the logical conclusion of "merge
according to the configuration". Which is not so nice.
Perhaps using the same logic as your patch to detect the case of
"pull --tags and nothing else" case, and exit with non-zero
saying "you probably meant fetch --tags" would be a sane
compromise? I dunno.
^ permalink raw reply
* [PATCH] git-pull: warn if only fetching tags with the -t switch
From: Gerrit Pape @ 2007-12-27 14:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsr0ifqi.fsf@gitster.siamese.dyndns.org>
Subject: [PATCH] git-pull: warn if only fetching tags with the -t switch
git-pull -t|--tags isn't supposed to be run, remove that option from
fetch-options.txt, and explicitely add it to git-fetch.txt. Have git pull
still fetch tags with the -t switch, but warn afterwards to better use
git fetch --tags, and error out.
---
How about this?
Documentation/fetch-options.txt | 8 --------
Documentation/git-fetch.txt | 8 ++++++++
git-pull.sh | 9 +++++++++
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index da03422..debdc87 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -29,14 +29,6 @@
and stores them locally. This option disables this
automatic tag following.
--t, \--tags::
- Most of the tags are fetched automatically as branch
- heads are downloaded, but tags that do not point at
- objects reachable from the branch heads that are being
- tracked will not be fetched by this mechanism. This
- flag lets all tags and their associated objects be
- downloaded.
-
-k, \--keep::
Keep downloaded pack.
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index 9003473..3cdac7f 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -33,6 +33,14 @@ OPTIONS
-------
include::fetch-options.txt[]
+-t, \--tags::
+ Most of the tags are fetched automatically as branch
+ heads are downloaded, but tags that do not point at
+ objects reachable from the branch heads that are being
+ tracked will not be fetched by this mechanism. This
+ flag lets all tags and their associated objects be
+ downloaded.
+
include::pull-fetch-param.txt[]
include::urls-remotes.txt[]
diff --git a/git-pull.sh b/git-pull.sh
index 698e82b..ab15eda 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -112,6 +112,15 @@ case "$merge_head" in
exit 1;;
*) exit $?;;
esac
+ # warn if only tags have been fetched
+ not_for_merge=$(sed -e '/ not-for-merge tag/d' \
+ "$GIT_DIR"/FETCH_HEAD)
+ if test "$not_for_merge" = ''; then
+ echo >&2 "Fetching tags only, you probably meant:"
+ echo >&2 " git fetch --tags"
+ exit 1;
+ fi
+
curr_branch=${curr_branch#refs/heads/}
echo >&2 "You asked me to pull without telling me which branch you"
--
1.5.3.7
^ permalink raw reply related
* Re: Using git for file archival/backup purposes - deletion strategy
From: Charles Bailey @ 2007-12-27 16:36 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90712261443t6aa0cd76u46d8ae88fc7c1eba@mail.gmail.com>
Martin Langhoff wrote:
> Ah! Local clones won't honour --depth!. A clone from git.kernel.org
> does get its .git/shallow file.
This should be fixed in git v1.5.4-rc0 and later. For reference
what version of git are you using?
Charles.
^ permalink raw reply
* [RFC] Distributing Windows binary package compiled with non gpl code
From: Marco Costalba @ 2007-12-27 18:32 UTC (permalink / raw)
To: git-u79uwXL29TY76Z2rM5mHXA, msysgit-/JYPxA39Uh5TLH3MbocFFw
It seems I have finally worked out a binary installation of qgit under Windows:
http://digilander.libero.it/mcostalba/qgit2.1rc1_win.exe
It seems to work with msysgit distribution of git. It DOES NOT work as
expected with Cygwin git that IMHO is very broken for qgit. I ended up
giving the blame to mingw, but after testing the MSVC compiled qgit
both with msysgit and cygwin git I have to say that the problem
*probably* is not in mingw but in cygwin.
Anyhow the MSVC 2008 compiled qgit seems stable and works as
advertised. Now that's the question:
Packaged together with qgit.exe there are the necessary Micorsoft
Visual C dll's. Is this a problem for someone?
I could try to compile again everything with mingw and test if under
msysgit the artifacts that appear with cygwin are fixed, if this
succeed I could prepare a binary package built with mingw and
distribute this instead, but would be this necessary?
qgit is GPL and I for sure want to be stick to GPL, so I don't know if
this can be an issue.
Thanks for help me in clarifing this point
Marco
P.S: Just to be fair I have to say that developing under Windows with
MSVC is much easier, because the debugging tools available with MSVC
2008 are very advanced and powerful, nothing similar exists _for
Window_ in the GPL camp. Indeed MSVC (together with SQL Server) are
(the only) two good products from MS, so good that even do not seem
produced by Microsoft !
^ permalink raw reply
* Re: [RFC] Distributing Windows binary package compiled with non gpl code
From: Daniel Barkalow @ 2007-12-27 22:08 UTC (permalink / raw)
To: Marco Costalba; +Cc: git, msysgit
In-Reply-To: <e5bfff550712271032q25d135e7y47d68337e937d401@mail.gmail.com>
On Thu, 27 Dec 2007, Marco Costalba wrote:
> Packaged together with qgit.exe there are the necessary Micorsoft
> Visual C dll's. Is this a problem for someone?
It depends on how they're packaged together. If it's possible to unpack
them (into a bunch of separate files, where each is either all GPL or no
GPL), then this is "mere aggregation" and perfectly fine (assuming you're
allowed to distribute the Visual C dlls, of course). IIRC, bundled
libraries for Windows programs are stored on the user's disk as separate
files anyway, so this is automatically okay.
I'd actually be more concerned about whether you can (or should)
distribute GPL code compiled with a proprietary compiler; people who get
the binaries and the source still couldn't edit the source and generate a
corresponding binary, because they don't necessarily have the build
environment you used. On the other hand, nothing you could do differently
would be any better for anyone with the right to complain, so it shouldn't
be an issue in practice. (And a user of qgit for Windows is more likely
than usual to have MSVC anyway)
-Daniel
*This .sig left intentionally blank*
^ 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