* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-10 22:44 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Petr Baudis, Theodore Tso, git
In-Reply-To: <48C80ADC.60207@gnu.org>
Petr wrote:
>> However, having a commit -> nonessential_volatile_metadata database
>> would be useful for many other things as well!
Which brings us back to the "commit notes" proposal.
--
Sincerely,
Stephen R. van den Berg.
"Am I paying for this abuse or is it extra?"
^ permalink raw reply
* Re: [PATCH 6/6] t9400, t9401: use "git cvsserver" without dash
From: Junio C Hamano @ 2008-09-10 22:37 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20080910200318.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Subject: [PATCH] Install git-cvsserver in $(bindir)
>
> It is one of the server side programs and needs to be found on usual $PATH.
>
> Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
> ...
> - $(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X '$(DESTDIR_SQ)$(bindir_SQ)'
> + $(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X git-cvsserver$X '$(DESTDIR_SQ)$(bindir_SQ)'
Thanks.
Will queue but without $X at the end, as I do not think we want it even on
Windows because cvsserver is a script.
^ permalink raw reply
* Re: [PATCH v2] git-rebase-interactive: do not squash commits on abort
From: Junio C Hamano @ 2008-09-10 22:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dmitry Potapov, git
In-Reply-To: <alpine.DEB.1.00.0809101150570.13830@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
>> index 929d681..aaca915 100755
>> --- a/git-rebase--interactive.sh
>> +++ b/git-rebase--interactive.sh
>> @@ -427,14 +427,18 @@ do
>> else
>> . "$DOTEST"/author-script ||
>> die "Cannot find the author identity"
>> + amend=""
>
> Sorry, my mistake... I should have been more explicit. In most (if not
> all) shell scripts, we prefer to set to the empty string with the
> expression
>
> amend=
Don't worry. I would notice and remove "" in my MUA for things like
these; especially the patch is this small it is hard to miss.
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-10 22:34 UTC (permalink / raw)
To: Jeff King; +Cc: Theodore Tso, Petr Baudis, git
In-Reply-To: <20080910215410.GA24432@coredump.intra.peff.net>
Jeff King wrote:
>On Wed, Sep 10, 2008 at 11:50:45PM +0200, Stephen R. van den Berg wrote:
>> >There was a proposal at some point for a "notes" feature which would
>> >allow after-the-fact annotation of commits. I don't recall the exact
>> >details, but I think it stored its information as a git tree of blobs.
>> >You could choose whether or not to transfer the notes based on
>> >transferring a ref pointing to the notes tree.
>> The idea is nice, but if we were to use it to store the origin link
>> information, the following happens:
>> - Origin link information is rare.
>I think you are misunderstanding what I meant by "git tree" here. It is
>literally a git tree object, so you don't ask the filesystem at all. You
>are looking up within the single object file. If it's a miss, you know
>after seeing that object. If not, then you dereference the blob object
>that contains the notes.
I see. Indeed. That's a lot better.
Did the binary search inside tree objects ever get implemented?
It is unclear why the latest commit notes proposal didn't make it,
though I admit that storing the origin link information in there seems
feasible.
The downsides when doing that are:
- The lookup cost is small, but still noticable, since it is sometimes
done on every commit; using the in-commit origin headerfield solves
this at negligible cost.
- The origin information is no longer cryptographically protected (under
certain circumstances this could be considered an advantage and a
disadvantage at the same time).
--
Sincerely,
Stephen R. van den Berg.
"Am I paying for this abuse or is it extra?"
^ permalink raw reply
* Re: [StGit PATCH 1/3] Auto-generate man pages for all StGit commands
From: Catalin Marinas @ 2008-09-10 21:56 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20080908210758.1957.664.stgit@yoghurt>
On 08/09/2008, Karl Hasselström <kha@treskal.com> wrote:
> Auto-generate man pages based on the docs that are in each
> stgit/commands/<cmd>.py file. That doc format is extended in order to
> support both brief command help output and manpage text.
Really great stuff. Thanks.
I can see a slight difference in behaviour but I don't have any issue
with it - previously "stg help <cmd>" showed the full description
while "stg <cmd> --help" only the short one.
An additional point on naming - should we use StGIT or StGit? The
original name was StGIT since GIT looked like an acronym. It looks
like now more people name it Git hence our tool moved slowly into
StGit but not everywhere. I personally like StGIT but the last 3
letters should really be the same as the official git (Git, GIT).
--
Catalin
^ permalink raw reply
* [ANNOUNCE] nbgit 0.1
From: Jonas Fonseca @ 2008-09-10 21:54 UTC (permalink / raw)
To: nbgit; +Cc: git
Hello,
Alexander Coles and I are very pleased to announce the first release of
nbgit, a git module for NetBeans. It uses the JGit library to interact
with Git repositories, which means that it should be as cross-platform
as it can get. Furthermore, both NetBeans 6.1 and 6.5beta should be
supported, the last one only slightly tested though.
The project is still in an early development phase and many features are
currently missing. However, nbgit 0.1 supports the most basic features
of a NetBeans versioning module. This includes showing annotations for
files and directories, viewing the status of tracked files, browsing
differences (both in diff view and in the editor), committing, and more
(see full list below).
Interested and *brave* people are encouraged to take it for a spin and
report first impressions, problems, or hurrahs in the nbgit forum or the
issue tracker on the Google Code project page.
Some useful resources
---------------------
Homepage: http://nbgit.org/
Project: http://nbgit.googlecode.com/
Forum: http://groups.google.com/group/nbgit
Downloads: http://code.google.com/p/nbgit/downloads/list
Gitfeed: git://github.com/myabc/nbgit.git
Gitweb: http://github.com/myabc/nbgit/commits/master
http://repo.or.cz/w/nbgit.git (mirrored)
Changes in this release
-----------------------
New features:
- init: Create a new git repository.
- status: List the status of changed files.
- diff: View changes to files (side-by-side).
- commit: Commit a selected range of files.
- log: Search and view revisions.
- update: Revert individual file changes.
- properties: Change repository specific options (i.e. user.name and
user.email).
- custom: User defined commands (e.g. to open gitk). (issue 16)
Resolved issues:
- Prefill the history summary view when opened. (issue 5)
- Optionally insert Signed-off-by line in commit messages. (issue 7)
- Reorder class path extensions to allow nbgit to be opened in NetBeans
6.5beta. (issue 14)
--
Jonas Fonseca
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Jeff King @ 2008-09-10 21:54 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Theodore Tso, Petr Baudis, git
In-Reply-To: <20080910215045.GA22739@cuci.nl>
On Wed, Sep 10, 2008 at 11:50:45PM +0200, Stephen R. van den Berg wrote:
> >There was a proposal at some point for a "notes" feature which would
> >allow after-the-fact annotation of commits. I don't recall the exact
> >details, but I think it stored its information as a git tree of blobs.
> >You could choose whether or not to transfer the notes based on
> >transferring a ref pointing to the notes tree.
>
> The idea is nice, but if we were to use it to store the origin link
> information, the following happens:
> - Origin link information is rare.
> - Yet during a log/gitk/blame run the information might need to
> be queried for at every commit.
> - Since in most cases the origin information does not exist, this
> will cause misses to fill the dentry cache for directory lookups, and
> thus killing performance.
> - In order to make this efficient, a different database lookup system is
> needed that is fast for misses.
I think you are misunderstanding what I meant by "git tree" here. It is
literally a git tree object, so you don't ask the filesystem at all. You
are looking up within the single object file. If it's a miss, you know
after seeing that object. If not, then you dereference the blob object
that contains the notes.
-Peff
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-10 21:50 UTC (permalink / raw)
To: Jeff King; +Cc: Theodore Tso, Petr Baudis, git
In-Reply-To: <20080910151015.GA8869@coredump.intra.peff.net>
Jeff King wrote:
>On Wed, Sep 10, 2008 at 04:16:30PM +0200, Stephen R. van den Berg wrote:
>> This is nice, I admit, but it has the following downsides:
>> - It is nontrivial to automate this on execution of "git cherry-pick".
>Maybe a cherry-picking hook?
Yes, that works, but it is non-trivial, especially since it needs to
work for gitk, log --graph, blame and revert as well.
>> - In a distributed environment this requires a network-reachable bug
>> database.
>Use a distributed bug tracking system (DBTS).
If it were part of git-core, that would work.
>But maybe Ted is on to something here. Rather than adding the
>information to the commit object itself, why not maintain a separate
>mapping, but keep it _within git_. That is how most of the DBTS's work
>that I have seen. Maybe it is possible to implement some subset of the
>features in a tool that could become part of core git.
Interesting thought.
>There was a proposal at some point for a "notes" feature which would
>allow after-the-fact annotation of commits. I don't recall the exact
>details, but I think it stored its information as a git tree of blobs.
>You could choose whether or not to transfer the notes based on
>transferring a ref pointing to the notes tree.
The idea is nice, but if we were to use it to store the origin link
information, the following happens:
- Origin link information is rare.
- Yet during a log/gitk/blame run the information might need to
be queried for at every commit.
- Since in most cases the origin information does not exist, this
will cause misses to fill the dentry cache for directory lookups, and
thus killing performance.
- In order to make this efficient, a different database lookup system is
needed that is fast for misses.
Whereas if the information is part of the commit, it costs nothing in
the typical case (no origin information present).
--
Sincerely,
Stephen R. van den Berg.
"Am I paying for this abuse or is it extra?"
^ permalink raw reply
* Re: [PATCH] git wrapper: also uses aliases to suggest mistyped commands
From: Junio C Hamano @ 2008-09-10 21:44 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Git Mailinglist
In-Reply-To: <1221062068-5660-1-git-send-email-pdebie@ai.rug.nl>
Pieter de Bie <pdebie@ai.rug.nl> writes:
> @@ -280,6 +284,15 @@ static int levenshtein_compare(const void *p1, const void *p2)
> return l1 != l2 ? l1 - l2 : strcmp(s1, s2);
> }
>
> +static void add_cmd_list(struct cmdnames *cmds, struct cmdnames *old)
> +{
> + int i;
> + ALLOC_GROW(cmds->names, cmds->cnt + old->cnt, cmds->alloc);
> +
> + for (i = 0; i < old->cnt; i++)
> + cmds->names[cmds->cnt++] = old->names[i];
> +}
> +
> const char *help_unknown_cmd(const char *cmd)
> {
> int i, n, best_similarity = 0;
> @@ -287,11 +300,13 @@ const char *help_unknown_cmd(const char *cmd)
>
> memset(&main_cmds, 0, sizeof(main_cmds));
> memset(&other_cmds, 0, sizeof(main_cmds));
> + memset(&aliases, 0, sizeof(aliases));
>
> git_config(git_unknown_cmd_config, NULL);
>
> load_command_list("git-", &main_cmds, &other_cmds);
>
> + add_cmd_list(&main_cmds, &aliases);
> ALLOC_GROW(main_cmds.names, main_cmds.cnt + other_cmds.cnt,
> main_cmds.alloc);
> memcpy(main_cmds.names + main_cmds.cnt, other_cmds.names,
I think your add_cmd_list() to smash two lists into one is a good
abstraction to use here, but the existing code that can be seen at the
tail end of the context already does that between main and other command
list in a slightly different way.
Aliases should not hide the commands available elsewhere, and the actual
execution codepath around ll.480-490 in git.c avoids getting fooled by
misconfigured aliases, but you do not protect yourself from that kind of
misconfiguration in this patch. You can have both "git-foo" command on
your private $PATH and alias.foo in your configuration, and they will have
the same levenshtein score. I suspect this will cause the same "foo"
suggested twice when the user types "git fo" from the command line.
Here is a suggested fix-up on top of your patch to address these issues.
---
help.c | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git i/help.c w/help.c
index 595342f..fd87bb5 100644
--- i/help.c
+++ w/help.c
@@ -291,6 +291,9 @@ static void add_cmd_list(struct cmdnames *cmds, struct cmdnames *old)
for (i = 0; i < old->cnt; i++)
cmds->names[cmds->cnt++] = old->names[i];
+ free(old->names);
+ old->cnt = 0;
+ old->names = NULL;
}
const char *help_unknown_cmd(const char *cmd)
@@ -307,12 +310,10 @@ const char *help_unknown_cmd(const char *cmd)
load_command_list("git-", &main_cmds, &other_cmds);
add_cmd_list(&main_cmds, &aliases);
- ALLOC_GROW(main_cmds.names, main_cmds.cnt + other_cmds.cnt,
- main_cmds.alloc);
- memcpy(main_cmds.names + main_cmds.cnt, other_cmds.names,
- other_cmds.cnt * sizeof(other_cmds.names[0]));
- main_cmds.cnt += other_cmds.cnt;
- free(other_cmds.names);
+ add_cmd_list(&main_cmds, &other_cmds);
+ qsort(main_cmds.names, main_cmds.cnt,
+ sizeof(main_cmds.names), cmdname_compare);
+ uniq(&main_cmds);
/* This reuses cmdname->len for similarity index */
for (i = 0; i < main_cmds.cnt; ++i)
^ permalink raw reply related
* Re: [RFC] origin link for cherry-pick and revert
From: Miklos Vajna @ 2008-09-10 21:06 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Stephen R. van den Berg, git
In-Reply-To: <alpine.LFD.1.10.0809101654020.23787@xanadu.home>
[-- Attachment #1: Type: text/plain, Size: 185 bytes --]
On Wed, Sep 10, 2008 at 04:55:19PM -0400, Nicolas Pitre <nico@cam.org> wrote:
> It's already there: -x
Thanks, and sorry for not reading carefully the manpage before sending
the mail.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Nicolas Pitre @ 2008-09-10 20:55 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Stephen R. van den Berg, git
In-Reply-To: <20080910203249.GX4829@genesis.frugalware.org>
On Wed, 10 Sep 2008, Miklos Vajna wrote:
> So, git revert already includes the "origin" of the commit in the commit
> message, and I think that is fine for most people.
>
> What about adding an option to cherry-pick to add a similar
> "commit 7b27718bdb1b70166383dec91391df5534d449ee upstream" or similar
> string to the commit message?
It's already there: -x
Nicolas
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Miklos Vajna @ 2008-09-10 20:32 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: git
In-Reply-To: <20080909132212.GA25476@cuci.nl>
[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]
On Tue, Sep 09, 2008 at 03:22:12PM +0200, "Stephen R. van den Berg" <srb@cuci.nl> wrote:
> origin a1184d85e8752658f02746982822f43f32316803 2
> author Junio C Hamano <gitster@pobox.com> 1220132115 -0700
> committer Junio C Hamano <gitster@pobox.com> 1220153445 -0700
First, sorry for joining the thread lately, as far as I see the idea I
want to shere here was not mentioned by anybody yet.
So, git revert already includes the "origin" of the commit in the commit
message, and I think that is fine for most people.
What about adding an option to cherry-pick to add a similar
"commit 7b27718bdb1b70166383dec91391df5534d449ee upstream" or similar
string to the commit message?
As far as I see the kernel -stable tree already have this, but it is
added manually and in many different forms, like:
[ Upstream commit 5f3a9a207f1fccde476dd31b4c63ead2967d934f ]
commit 7b27718bdb1b70166383dec91391df5534d449ee upstream
Already in Linus' tree:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b25b791b13aaa336b56c4f9bd417ff126363f80b
etc.
Once git would provide a standard way to do this, that could be used to
avoid this.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH 2/3] builtin-commit: use commit_tree()
From: Miklos Vajna @ 2008-09-10 20:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Russell King, git
In-Reply-To: <cover.1221077214.git.vmiklos@frugalware.org>
First, it adds less code than removes, second this allows us to use
recuce_heads() for parents, so that the parents of a merge will be
always the same with or without a conflict.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-commit.c | 63 ++++++++++++------------------------------------------
1 files changed, 14 insertions(+), 49 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 8165bb3..ad055ea 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -670,11 +670,11 @@ static int prepare_to_commit(const char *index_file, const char *prefix)
* Find out if the message starting at position 'start' in the strbuf
* contains only whitespace and Signed-off-by lines.
*/
-static int message_is_empty(struct strbuf *sb, int start)
+static int message_is_empty(struct strbuf *sb)
{
struct strbuf tmpl;
const char *nl;
- int eol, i;
+ int eol, i, start = 0;
if (cleanup_mode == CLEANUP_NONE && sb->len)
return 0;
@@ -929,34 +929,14 @@ static const char commit_utf8_warn[] =
"You may want to amend it after fixing the message, or set the config\n"
"variable i18n.commitencoding to the encoding your project uses.\n";
-static void add_parent(struct strbuf *sb, const unsigned char *sha1)
-{
- struct object *obj = parse_object(sha1);
- const char *parent = sha1_to_hex(sha1);
- const char *cp;
-
- if (!obj)
- die("Unable to find commit parent %s", parent);
- if (obj->type != OBJ_COMMIT)
- die("Parent %s isn't a proper commit", parent);
-
- for (cp = sb->buf; cp && (cp = strstr(cp, "\nparent ")); cp += 8) {
- if (!memcmp(cp + 8, parent, 40) && cp[48] == '\n') {
- error("duplicate parent %s ignored", parent);
- return;
- }
- }
- strbuf_addf(sb, "parent %s\n", parent);
-}
-
int cmd_commit(int argc, const char **argv, const char *prefix)
{
- int header_len;
struct strbuf sb;
const char *index_file, *reflog_msg;
char *nl, *p;
unsigned char commit_sha1[20];
struct ref_lock *ref_lock;
+ struct commit_list *parents = NULL, **pptr = &parents;
git_config(git_commit_config, NULL);
@@ -971,13 +951,6 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
return 1;
}
- /*
- * The commit object
- */
- strbuf_init(&sb, 0);
- strbuf_addf(&sb, "tree %s\n",
- sha1_to_hex(active_cache_tree->sha1));
-
/* Determine parents */
if (initial_commit) {
reflog_msg = "commit (initial)";
@@ -991,13 +964,13 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
die("could not parse HEAD commit");
for (c = commit->parents; c; c = c->next)
- add_parent(&sb, c->item->object.sha1);
+ pptr = &commit_list_insert(c->item, pptr)->next;
} else if (in_merge) {
struct strbuf m;
FILE *fp;
reflog_msg = "commit (merge)";
- add_parent(&sb, head_sha1);
+ pptr = &commit_list_insert(lookup_commit(head_sha1), pptr)->next;
strbuf_init(&m, 0);
fp = fopen(git_path("MERGE_HEAD"), "r");
if (fp == NULL)
@@ -1007,24 +980,18 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
unsigned char sha1[20];
if (get_sha1_hex(m.buf, sha1) < 0)
die("Corrupt MERGE_HEAD file (%s)", m.buf);
- add_parent(&sb, sha1);
+ pptr = &commit_list_insert(lookup_commit(sha1), pptr)->next;
}
fclose(fp);
strbuf_release(&m);
} else {
reflog_msg = "commit";
- strbuf_addf(&sb, "parent %s\n", sha1_to_hex(head_sha1));
+ pptr = &commit_list_insert(lookup_commit(head_sha1), pptr)->next;
}
-
- strbuf_addf(&sb, "author %s\n",
- fmt_ident(author_name, author_email, author_date, IDENT_ERROR_ON_NO_NAME));
- strbuf_addf(&sb, "committer %s\n", git_committer_info(IDENT_ERROR_ON_NO_NAME));
- if (!is_encoding_utf8(git_commit_encoding))
- strbuf_addf(&sb, "encoding %s\n", git_commit_encoding);
- strbuf_addch(&sb, '\n');
+ parents = reduce_heads(parents);
/* Finally, get the commit message */
- header_len = sb.len;
+ strbuf_init(&sb, 0);
if (strbuf_read_file(&sb, git_path(commit_editmsg), 0) < 0) {
rollback_index_files();
die("could not read commit message");
@@ -1037,16 +1004,15 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
if (cleanup_mode != CLEANUP_NONE)
stripspace(&sb, cleanup_mode == CLEANUP_ALL);
- if (sb.len < header_len || message_is_empty(&sb, header_len)) {
+ if (message_is_empty(&sb)) {
rollback_index_files();
fprintf(stderr, "Aborting commit due to empty commit message.\n");
exit(1);
}
- strbuf_addch(&sb, '\0');
- if (is_encoding_utf8(git_commit_encoding) && !is_utf8(sb.buf))
- fprintf(stderr, commit_utf8_warn);
- if (write_sha1_file(sb.buf, sb.len - 1, commit_type, commit_sha1)) {
+ if (commit_tree(sb.buf, active_cache_tree->sha1, parents, commit_sha1,
+ fmt_ident(author_name, author_email, author_date,
+ IDENT_ERROR_ON_NO_NAME))) {
rollback_index_files();
die("failed to write commit object");
}
@@ -1055,12 +1021,11 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
initial_commit ? NULL : head_sha1,
0);
- nl = strchr(sb.buf + header_len, '\n');
+ nl = strchr(sb.buf, '\n');
if (nl)
strbuf_setlen(&sb, nl + 1 - sb.buf);
else
strbuf_addch(&sb, '\n');
- strbuf_remove(&sb, 0, header_len);
strbuf_insert(&sb, 0, reflog_msg, strlen(reflog_msg));
strbuf_insert(&sb, strlen(reflog_msg), ": ", 2);
--
1.6.0.1
^ permalink raw reply related
* [PATCH 1/3] commit_tree(): add a new author parameter
From: Miklos Vajna @ 2008-09-10 20:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Russell King, git
In-Reply-To: <cover.1221077214.git.vmiklos@frugalware.org>
In case it's NULL, it is still determined automatically, but now you
have the ability to specify one yourself.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-commit-tree.c | 9 ++++++---
builtin-merge.c | 4 ++--
builtin.h | 3 ++-
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/builtin-commit-tree.c b/builtin-commit-tree.c
index 8a5ba4c..33c0e82 100644
--- a/builtin-commit-tree.c
+++ b/builtin-commit-tree.c
@@ -46,7 +46,8 @@ static const char commit_utf8_warn[] =
"variable i18n.commitencoding to the encoding your project uses.\n";
int commit_tree(const char *msg, unsigned char *tree,
- struct commit_list *parents, unsigned char *ret)
+ struct commit_list *parents, unsigned char *ret,
+ const char *author)
{
int result;
int encoding_is_utf8;
@@ -74,7 +75,9 @@ int commit_tree(const char *msg, unsigned char *tree,
}
/* Person/date information */
- strbuf_addf(&buffer, "author %s\n", git_author_info(IDENT_ERROR_ON_NO_NAME));
+ if (!author)
+ author = git_author_info(IDENT_ERROR_ON_NO_NAME);
+ strbuf_addf(&buffer, "author %s\n", author);
strbuf_addf(&buffer, "committer %s\n", git_committer_info(IDENT_ERROR_ON_NO_NAME));
if (!encoding_is_utf8)
strbuf_addf(&buffer, "encoding %s\n", git_commit_encoding);
@@ -123,7 +126,7 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
if (strbuf_read(&buffer, 0, 0) < 0)
die("git commit-tree: read returned %s", strerror(errno));
- if (!commit_tree(buffer.buf, tree_sha1, parents, commit_sha1)) {
+ if (!commit_tree(buffer.buf, tree_sha1, parents, commit_sha1, NULL)) {
printf("%s\n", sha1_to_hex(commit_sha1));
return 0;
}
diff --git a/builtin-merge.c b/builtin-merge.c
index 9ad9791..4a8ec60 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -691,7 +691,7 @@ static int merge_trivial(void)
parent->next = xmalloc(sizeof(struct commit_list *));
parent->next->item = remoteheads->item;
parent->next->next = NULL;
- commit_tree(merge_msg.buf, result_tree, parent, result_commit);
+ commit_tree(merge_msg.buf, result_tree, parent, result_commit, NULL);
finish(result_commit, "In-index merge");
drop_save();
return 0;
@@ -720,7 +720,7 @@ static int finish_automerge(struct commit_list *common,
}
free_commit_list(remoteheads);
strbuf_addch(&merge_msg, '\n');
- commit_tree(merge_msg.buf, result_tree, parents, result_commit);
+ commit_tree(merge_msg.buf, result_tree, parents, result_commit, NULL);
strbuf_addf(&buf, "Merge made by %s.", wt_strategy);
finish(result_commit, buf.buf);
strbuf_release(&buf);
diff --git a/builtin.h b/builtin.h
index e67cb20..8893b3c 100644
--- a/builtin.h
+++ b/builtin.h
@@ -17,7 +17,8 @@ extern int read_line_with_nul(char *buf, int size, FILE *file);
extern int fmt_merge_msg(int merge_summary, struct strbuf *in,
struct strbuf *out);
extern int commit_tree(const char *msg, unsigned char *tree,
- struct commit_list *parents, unsigned char *ret);
+ struct commit_list *parents, unsigned char *ret,
+ const char *author);
extern int check_pager_config(const char *cmd);
extern int cmd_add(int argc, const char **argv, const char *prefix);
--
1.6.0.1
^ permalink raw reply related
* [PATCH 0/3] make builtin-commit use commit_tree() and reduce_heads()
From: Miklos Vajna @ 2008-09-10 20:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Russell King, git
Hi,
On Tue, Sep 09, 2008 at 05:52:37PM +0100, Russell King <rmk@arm.linux.org.uk> wrote:
> Is this intentional, or is it a bug?
It is because builtin-commit does not use reduce_heads(), but
builtin-merge does.
Here are 3 patches to make builtin-commit use commit_tree() and
reduce_heads() as well.
The first one just improves the commit_tree() interface.
The second one is a cleanup, but it also adds reduce_heads() usage, to
fix the issue, pointed out by Russell King.
The third one adds new testcases, based on the ones provided by him.
Miklos Vajna (3):
commit_tree(): add a new author parameter
builtin-commit: use commit_tree()
t7603: add new testcases to ensure builtin-commit uses reduce_heads()
builtin-commit-tree.c | 9 ++++--
builtin-commit.c | 63 +++++++++-------------------------------
builtin-merge.c | 4 +-
builtin.h | 3 +-
t/t7603-merge-reduce-heads.sh | 53 ++++++++++++++++++++++++++++++++++
5 files changed, 77 insertions(+), 55 deletions(-)
^ permalink raw reply
* [PATCH 3/3] t7603: add new testcases to ensure builtin-commit uses reduce_heads()
From: Miklos Vajna @ 2008-09-10 20:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Russell King, git
In-Reply-To: <cover.1221077214.git.vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
t/t7603-merge-reduce-heads.sh | 53 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/t/t7603-merge-reduce-heads.sh b/t/t7603-merge-reduce-heads.sh
index b47b7b9..7e17eb4 100755
--- a/t/t7603-merge-reduce-heads.sh
+++ b/t/t7603-merge-reduce-heads.sh
@@ -60,4 +60,57 @@ test_expect_success 'merge c1 with c2, c3, c4, c5' '
test -f c5.c
'
+test_expect_success 'setup' '
+ for i in A B C D E
+ do
+ echo $i > $i.c &&
+ git add $i.c &&
+ git commit -m $i &&
+ git tag $i
+ done &&
+ git reset --hard A &&
+ for i in F G H I
+ do
+ echo $i > $i.c &&
+ git add $i.c &&
+ git commit -m $i &&
+ git tag $i
+ done
+'
+
+test_expect_success 'merge E and I' '
+ git reset --hard A &&
+ git merge E I
+'
+
+test_expect_success 'verify merge result' '
+ test $(git rev-parse HEAD^1) = $(git rev-parse E) &&
+ test $(git rev-parse HEAD^2) = $(git rev-parse I)
+'
+
+test_expect_success 'add conflicts' '
+ git reset --hard E &&
+ echo foo > file.c &&
+ git add file.c &&
+ git commit -m E2 &&
+ git tag E2 &&
+ git reset --hard I &&
+ echo bar >file.c &&
+ git add file.c &&
+ git commit -m I2 &&
+ git tag I2
+'
+
+test_expect_success 'merge E2 and I2, causing a conflict and resolve it' '
+ git reset --hard A &&
+ test_must_fail git merge E2 I2 &&
+ echo baz > file.c &&
+ git add file.c &&
+ git commit -m "resolve conflict"
+'
+
+test_expect_success 'verify merge result' '
+ test $(git rev-parse HEAD^1) = $(git rev-parse E2) &&
+ test $(git rev-parse HEAD^2) = $(git rev-parse I2)
+'
test_done
--
1.6.0.1
^ permalink raw reply related
* Re: Commit 140b378d07229e breaks gitk highlighting
From: Mark Levedahl @ 2008-09-10 20:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Karl Hasselström, Paul Mackerras
In-Reply-To: <7vtzcnx0uc.fsf@gitster.siamese.dyndns.org>
On Wed, Sep 10, 2008 at 3:22 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Feeding the following to "git diff-tree -r -s --stdin -- t" misbehaves
> with that change. The second line is skipped.
>
> 7c4d0219cf9ab6a7738a09ad7fec72d5e9f2ac67
> a786091b4a487bc08bbff4864717cf5d8383e983
> 4a09bc966449ca0a7e9a5bb70f91b47debdd7c4e
>
> This should fix it.
>
> diff --git a/builtin-diff-tree.c b/builtin-diff-tree.c
> index 1138c2d..a9e32c9 100644
> --- a/builtin-diff-tree.c
> +++ b/builtin-diff-tree.c
> @@ -71,8 +71,7 @@ static int diff_tree_stdin(char *line)
> line[len-1] = 0;
> if (get_sha1_hex(line, sha1))
> return -1;
> - obj = lookup_object(sha1);
> - obj = obj ? obj : parse_object(sha1);
> + obj = parse_object(sha1);
> if (!obj)
> return -1;
> if (obj->type == OBJ_COMMIT)
>
Yes, that fixes the problems I see.
Thanks,
Mark
^ permalink raw reply
* Re: Commit 140b378d07229e breaks gitk highlighting
From: Junio C Hamano @ 2008-09-10 19:22 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Git Mailing List, Karl Hasselström, Paul Mackerras
In-Reply-To: <30e4a070809090531i6c6dd2c8r189e70927b5444c9@mail.gmail.com>
"Mark Levedahl" <mlevedahl@gmail.com> writes:
> gitk since the above commit ("Teach git diff-tree --stdin to diff
> trees") fails to reliably highlight commits matching a given path
> specification. For an example of the problem,
>
> $gitk ec3a4ba519c001
>
> and select commit "touching paths" with "t" in the entry bar
>
> The 4'th commit down (t9124: clean up chdir usage) is NOT highlighted,
> though it clearly touches t. Reverting commit 140b378 restores the
> correct behavior. This gets into parts of the code I don't understand,
> so I decline to try to offer a patch.
Feeding the following to "git diff-tree -r -s --stdin -- t" misbehaves
with that change. The second line is skipped.
7c4d0219cf9ab6a7738a09ad7fec72d5e9f2ac67
a786091b4a487bc08bbff4864717cf5d8383e983
4a09bc966449ca0a7e9a5bb70f91b47debdd7c4e
This should fix it.
I think we should have a stronger warning against misusing lookup_object()
without knowing what it does. It is marked "Internal only" in the header,
but it does not explain why. The interface is there to help the lazy
object lookup (e.g. you parse a commit and learn about a parent it has.
You do not want to read the parent commit at that point, so you create a
placeholder commit object and point at it from the child. You would want
to make sure that you populate the same placeholder object with the data
you read from the parent commit when it gets the turn of the parent commit
to be parsed).
diff --git a/builtin-diff-tree.c b/builtin-diff-tree.c
index 1138c2d..a9e32c9 100644
--- a/builtin-diff-tree.c
+++ b/builtin-diff-tree.c
@@ -71,8 +71,7 @@ static int diff_tree_stdin(char *line)
line[len-1] = 0;
if (get_sha1_hex(line, sha1))
return -1;
- obj = lookup_object(sha1);
- obj = obj ? obj : parse_object(sha1);
+ obj = parse_object(sha1);
if (!obj)
return -1;
if (obj->type == OBJ_COMMIT)
^ permalink raw reply related
* Re: PATCH: git-p4 optional handling of RCS keywords
From: Simon Hausmann @ 2008-09-10 19:18 UTC (permalink / raw)
To: dhruva; +Cc: Junio C Hamano, GIT SCM, Jing Xue
In-Reply-To: <646617.59689.qm@web95011.mail.in2.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]
On Wednesday 10 September 2008 08:29:56 dhruva wrote:
> Hi,
> Incorporated the style tip, sure makes it look cleaner.
>
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> index 2216cac..3e72e43 100755
> --- a/contrib/fast-import/git-p4
> +++ b/contrib/fast-import/git-p4
> @@ -16,6 +16,9 @@ from sets import Set;
>
> verbose = False
>
> +# Handling of RCS keyowrds. To ensure backward compatibility, the default
> +# is to strip keywords. Default behavior is controlled here
> +kwstrip = True
>
> def p4_build_cmd(cmd):
> """Build a suitable p4 command line.
> @@ -975,7 +978,9 @@ class P4Sync(Command):
> sys.stderr.write("p4 print fails with: %s\n" % repr(stat))
> continue
>
> - if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
> + if not kwstrip:
> + pass
> + elif stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
> text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
> elif stat['type'] in ('text+k', 'ktext', 'kxtext',
> 'unicode+k', 'binary+k'): text =
> re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r
>'$\1$', text) @@ -1850,6 +1855,16 @@ def main():
> (cmd, args) = parser.parse_args(sys.argv[2:], cmd);
> global verbose
> verbose = cmd.verbose
> +
> + global kwstrip
> + kwval = gitConfig("git-p4.kwstrip")
> + if len(kwval) > 0:
> + kwval = kwval.lower();
> + if "false" == kwval:
> + kwstrip = False
> + elif "true" == kwval:
> + kwstrip = True
I have another style nitpick, sorry :). Please use "kwval == "false" instead
of the other way around.
Otherwise your patch looks good to me, I think it's a very good option to add.
Please resend with commit message so that Junio can include it.
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RFC: perhaps a "new file" should not be deleted by "git reset --hard"
From: Eric Raible @ 2008-09-10 19:12 UTC (permalink / raw)
To: Git Mailing List
In http://marc.theaimsgroup.com/?l=git&m=114917892328066
(references by http://git.or.cz/gitwiki/GitFaq), Linus says:
'And "git reset" won't be deleting files it doesn't track (it had _better_
not touch them), even more so when it has been told to ignore them, so it
makes total sense to _not_ delete them when doing that reset.'
Now consider this example:
# Create a single commit in a new repo (so that we have a HEAD)
mkdir xx
cd xx
git init
git commit --allow-empty -m"initial"
# Add an important file
echo "Important stuff" > file42
git add file42
git status # -> new file: file42
ls # -> file42, or course
git reset --hard
ls # -> nothing
I would argue that as a "new file" (as reported by git status)
that file42 was never actually tracked by git. Sure, it _would_
have been tracked in the future, but git never actually tracked it
(it's not part of any commits).
So in this scenario wouldn't it make more sense for
"git reset --hard" to handle file42 as "git reset" does
instead of deleting it w/out a trace [1]?
The same question goes for "git checkout -f", too, I suppose.
I actually accidentally deleted hundred of newly added files yesterday
doing just this. https://mozy.com/?code=V3D4MM) saved my butt,
but it wasn't pleasant.
- Eric
[1] - There's not even a reflog entry. Sure, "git fsck" can be
used, but that's hardly a friendly fallback.
^ permalink raw reply
* Re: git svn segfaults in _Delta.so
From: Thomas Harning @ 2008-09-10 18:40 UTC (permalink / raw)
To: Thomas Harning; +Cc: git
In-Reply-To: <E7387B42-6A3D-432B-8478-71A5E510D905@gmail.com>
On Sep 10, 2008, at 2:21 PM, Thomas Harning wrote:
> I just recently setup a new system and installed subversion 1.5.1
> and the latest git from head.
>
> On an existing repository (copied from the same system but slightly
> older software) running git svn rebase will cause it to segfault in
> _Delta.so (part of subversion's perl libraries).... even when there
> is nothing to do... it even seems to successfully do all the
> operations. I've built subversion and git with debugging enabled
> and cannot get any useful stack-trace. the stacktrace is:
>
> #0 0x00007fbed7edd3a0 in ?? ()
> #1 0x00007fbed99fa75d in ?? ()
> #2 0x0000000000000001 in ?? ()
> #3 0x00007fbed99fb217 in ?? ()
> #4 0x00007fbed99e82d8 in ?? ()
> #5 0x0000000000000001 in ?? ()
> #6 0x000000000070e250 in cwd.17580 ()
> #7 0x000000000070d7f8 in buffer.17586 ()
> #8 0x0000000000f7f408 in ?? ()
> #9 0x00007fbed99fb205 in ?? ()
> #10 0x0000000000000000 in ?? ()
>
>
> The only way I know that it is _Delta.so is that in 'dmesg' i get:
> git-svn[1277]: segfault at 7f64fa7213a0 ip 7f64fa7213a0 sp
> 7fff07a9a2b8 error 14 in _Delta.so[7f64fa92c000+22000]
>
> In another machine w/ very similar software (slightly older by a
> month or so) I do not see these segfaults. However it is running
> svn 1.4.6 .. so it might be svn versions... will report on status
> after downgrade
svn 1.4.6 does not suffer the segfaults...
^ permalink raw reply
* git svn segfaults in _Delta.so
From: Thomas Harning @ 2008-09-10 18:21 UTC (permalink / raw)
To: git
I just recently setup a new system and installed subversion 1.5.1 and
the latest git from head.
On an existing repository (copied from the same system but slightly
older software) running git svn rebase will cause it to segfault in
_Delta.so (part of subversion's perl libraries).... even when there is
nothing to do... it even seems to successfully do all the operations.
I've built subversion and git with debugging enabled and cannot get
any useful stack-trace. the stacktrace is:
#0 0x00007fbed7edd3a0 in ?? ()
#1 0x00007fbed99fa75d in ?? ()
#2 0x0000000000000001 in ?? ()
#3 0x00007fbed99fb217 in ?? ()
#4 0x00007fbed99e82d8 in ?? ()
#5 0x0000000000000001 in ?? ()
#6 0x000000000070e250 in cwd.17580 ()
#7 0x000000000070d7f8 in buffer.17586 ()
#8 0x0000000000f7f408 in ?? ()
#9 0x00007fbed99fb205 in ?? ()
#10 0x0000000000000000 in ?? ()
The only way I know that it is _Delta.so is that in 'dmesg' i get:
git-svn[1277]: segfault at 7f64fa7213a0 ip 7f64fa7213a0 sp
7fff07a9a2b8 error 14 in _Delta.so[7f64fa92c000+22000]
In another machine w/ very similar software (slightly older by a month
or so) I do not see these segfaults. However it is running svn
1.4.6 .. so it might be svn versions... will report on status after
downgrade
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Paolo Bonzini @ 2008-09-10 17:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: Stephen R. van den Berg, Theodore Tso, git
In-Reply-To: <20080910164045.GL10360@machine.or.cz>
> I'm not endorsing assigning UUIDs to commits now at all (but I don't
> have time to formulate a comprehensive argument against that either).
>
> However, having a commit -> nonessential_volatile_metadata database
> would be useful for many other things as well!
100 points to Petr. :-)
Paolo
^ permalink raw reply
* Re: git merge vs git commit
From: Ulrik Sverdrup @ 2008-09-10 17:42 UTC (permalink / raw)
To: git
Matthieu Moy <Matthieu.Moy@imag.fr>:
>
>>Russell King <rmk@arm.linux.org.uk> writes:
>>
>> Hi,
>>
>> Using git 1.5.4.5, I notice that the result from git merge and git commit
>> are different in an unexpected way.
>>
>> Take the following tree:
>>
>> B---C---D---E2
>> /
>> -A1
>> \
>> F---G---H---I3
>>
>> (letters represent commits, numbers represent where the references are).
>>
>> Your current head is '1', and you want to merge branches '2' and '3', so
>> you use:
>>
>> git merge 2 3
>
>AAUI, "git merge 2 3" doesn't mean "merge 2 and 3 together", but
>"merge 2 and 3 with the current HEAD". So, what you wanted was :
>
>git checkout 1
>git merge 2
>
>And what you did was an octopus merge of A, E and I (which ends up
>being the same since A is anyway the common ancestor of E and I).
>
>Now, this doesn't explain why the conflicted merge gives a result
>different from the other.
>
(I'm not on the list, please CC)
Reading the whole thread I think we have an explanation: octupus-merge
learned to remove reduntant parents and does so in the clean merge
case, but merge in general does not it; this is what happens in the
conflict case.
However it remains that three parents are to be expected with the
given user action
Ulrik Sverdrup
^ permalink raw reply
* [PATCH] t7501: always use test_cmp instead of diff
From: Miklos Vajna @ 2008-09-10 17:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vljy03m2m.fsf@gitster.siamese.dyndns.org>
This should make the output more readable (by default using diff -u)
when some tests fail.
Also changed the diff order from "current expected" to "expected
current".
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Tue, Sep 09, 2008 at 05:02:09PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> > We seem to use the convention of
> >
> > test_cmp <expected> <actual>
> >
> > elsewhere, rather than
> >
> > test_cmp <actual> <expected>
> >
> > as you have here. Most noticeably, that means the diff will show
> > deviations from expected, rather "what should be done to make this
> > as expected".
>
> Yes, please.
Here is an updated patch that does this as well.
t/t7501-commit.sh | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 469bff8..63bfc6d 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -141,7 +141,7 @@ EOF
test_expect_success \
'validate git rev-list output.' \
- 'diff current expected'
+ 'test_cmp expected current'
test_expect_success 'partial commit that involves removal (1)' '
@@ -151,7 +151,7 @@ test_expect_success 'partial commit that involves removal (1)' '
git commit -m "Partial: add elif" elif &&
git diff-tree --name-status HEAD^ HEAD >current &&
echo "A elif" >expected &&
- diff expected current
+ test_cmp expected current
'
@@ -160,7 +160,7 @@ test_expect_success 'partial commit that involves removal (2)' '
git commit -m "Partial: remove file" file &&
git diff-tree --name-status HEAD^ HEAD >current &&
echo "D file" >expected &&
- diff expected current
+ test_cmp expected current
'
@@ -171,7 +171,7 @@ test_expect_success 'partial commit that involves removal (3)' '
git commit -m "Partial: modify elif" elif &&
git diff-tree --name-status HEAD^ HEAD >current &&
echo "M elif" >expected &&
- diff expected current
+ test_cmp expected current
'
@@ -187,7 +187,7 @@ test_expect_success 'amend commit to fix author' '
expected &&
git commit --amend --author="$author" &&
git cat-file -p HEAD > current &&
- diff expected current
+ test_cmp expected current
'
@@ -256,7 +256,7 @@ test_expect_success 'amend commit to fix author' '
expected &&
git commit --amend --author="$author" &&
git cat-file -p HEAD > current &&
- diff expected current
+ test_cmp expected current
'
--
1.6.0.1
^ permalink raw reply related
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