* Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)
From: Daniel Barkalow @ 2009-08-30 1:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxbeb0mt.fsf@alter.siamese.dyndns.org>
On Wed, 26 Aug 2009, Junio C Hamano wrote:
> * db/vcs-helper (2009-08-09) 17 commits
> - Allow helpers to request marks for fast-import
> - Allow helpers to report in "list" command that the ref is unchanged
> - Add support for "import" helper command
> - transport-helper_init(): fix a memory leak in error path
> - Add a config option for remotes to specify a foreign vcs
> - Allow programs to not depend on remotes having urls
> - Allow fetch to modify refs
> - Use a function to determine whether a remote is valid
> - Use a clearer style to issue commands to remote helpers
> (merged to 'next' on 2009-08-07 at f3533ba)
> + Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible
> + Makefile: do not link three copies of git-remote-* programs
> + Makefile: git-http-fetch does not need expat
> (merged to 'next' on 2009-08-06 at 15da79d)
> + http-fetch: Fix Makefile dependancies
> + Add transport native helper executables to .gitignore
> (merged to 'next' on 2009-08-05 at 33d491e)
> + git-http-fetch: not a builtin
> + Use an external program to implement fetching with curl
> + Add support for external programs for handling native fetches
> (this branch is used by jh/cvs-helper.)
>
> There was a discussion that suggests that the use of colon ':' before vcs
> helper name needs to be corrected. Nothing happened since.
I believe the outcome of that discussion was:
- We want to keep supporting using regular location URLs that are URLs of
git repositories (e.g., http://git.savannah.gnu.org/cgit/xboard.git),
and we probably want to do it with a helper which runs when
run_command() is given "remote-<scheme>". I think installing hardlinks
in EXECPATH ended up being the best implementation here. This is
currently a special case, because these URLs have push handled
internally (or, rather, with internal code calling a different external
program), but I think we want to make it no longer special at all, so
that people can install the handling for access to native repos via
dumb filesystem-like protocols separately. This is in next.
- We want to support a separate "vcs" option for cases where repositories
in the foreign system need to be addressed through the combination of a
bunch of options, which will be read from the configuration by the
helper. The helper which gets run is "remote-<value of vcs option>".
This is in pu.
- We want to support URLs of some sort leading to using helpers
appropriate for foreign systems that use URLs and are most conveniently
located this way. We didn't come to any concensus on what this should
do, but we also haven't had any helpers proposed yet that would use it,
and the series doesn't include any code that would lead to running a
helper other than in one of the above two cases. (jh's cvs helper
clearly wants "cvsroot" and "cvsmodule" options, and my p4 helper wants
"port" and "codeline" options; SVN is the big use cases for URLs, but
nobody's tackled that as a helper)
So I think this issue is squarely in "future work" anyway, and the current
part of the series should be able to move forward, unless I've missed some
other issue.
Of course, there are a bunch of things that are beyond the present
contents of the series, but I think there's nothing wrong in the series as
it is, and it's worthwhile without any further patches.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: how to add an empty initial commit
From: Sean Estabrooks @ 2009-08-30 1:39 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20090830005224.GC10952@debian.b2j>
On Sun, 30 Aug 2009 08:52:24 +0800
bill lam <cbill.lam@gmail.com> wrote:
> I want to insert an empty initial commit so that I can rebase and edit
> files in the real initial commit. There is a --root option in
> git-rebase but I can not find example of how to use it.
Bill,
This sounds like a hard way to go about things. Instead, you can edit
the files as you wish, "git add" the new edits, and then use
"git commit --amend" to alter the initial commit. Don't think rebase
would help in the situation you describe.
Sean
^ permalink raw reply
* git-svn messing up merge commits on dcommit
From: Björn Steinbrink @ 2009-08-30 1:32 UTC (permalink / raw)
To: Eric Wong; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]
Hi Eric,
I have two "test cases" here (attached), which I actually wrote months
ago, but forgot to sent, as I wanted to clean them up/turn them into
something suitable for the test suite, but honestly, I'll probably never
get around to do that, so here they are, as they are. They show git-svn
messing up merge commits when dcommitting a branch that is not
up-to-date WRT the svn repo.
The basic history for both cases (before dcommit) is:
C---D (master)
/ /
/---E (side)
/
A---B (trunk)
\
X (revision in SVN, not yet fetched)
So the dcommit (which would send C and D to the svn repo) needs to
"rebase" C and D.
In the first test case, this rebasing causes conflicts, and leads to a
linearized history:
E (side)
/
A---B---X---C' (trunk)
\
D (master)
The merge is broken apart. This is probably expected, but I thought I'd
tell anyway.
The second test case is a bit more interesting, there are no conflicts
between the local commits to be dcommitted and the new commit X in the
svn repo. In this case, git-svn manages to dcommit the merge commit just
fine, keeping the history correct, but it messes the merge commit's
commit message up. So the history becomes:
A---B---X---C'--D' (trunk) (master)
\ /
--------E (side)
But D' has the same commit message as C/C', not the one from D.
I hope that makes any sense to you (or you can figure it out from the
testing scripts).
Björn
[-- Attachment #2: test --]
[-- Type: text/plain, Size: 582 bytes --]
#!/bin/sh
mkdir git-svn-test
cd git-svn-test
SVN="file://$PWD/svnrepo"
svnadmin create svnrepo
svn co "$SVN" co
cd co
svn mkdir trunk tags branches
svn ci -m init
echo 123 > trunk/foo
svn add trunk/foo
svn ci -m "SVN 1"
cd ..
git svn clone -s "$SVN" git
cd co
echo 456 >> trunk/foo
svn ci -m "SVN 2"
cd ..
cd git
git checkout -b side
echo 123 >> foo
git add foo
git commit -m "On side"
git checkout master
echo 123 > foo3
git add foo3
git commit -m "On master"
git merge --no-ff side
gitk --all&
git svn dcommit
echo resolved > foo
git add -u
git rebase --continue
gitk --all
[-- Attachment #3: test2 --]
[-- Type: text/plain, Size: 532 bytes --]
#!/bin/sh
mkdir git-svn-test
cd git-svn-test
SVN="file://$PWD/svnrepo"
svnadmin create svnrepo
svn co "$SVN" co
cd co
svn mkdir trunk tags branches
svn ci -m init
echo 123 > trunk/foo
svn add trunk/foo
svn ci -m "SVN 1"
cd ..
git svn clone -s "$SVN" git
cd co
echo 456 >> trunk/foo
svn ci -m "SVN 2"
cd ..
cd git
git checkout -b side
echo 123 >> foo2
git add foo2
git commit -m "On side"
git checkout master
echo 123 > foo3
git add foo3
git commit -m "On master"
git merge --no-ff side
gitk --all&
git svn dcommit
gitk --all&
^ permalink raw reply
* how to add an empty initial commit
From: bill lam @ 2009-08-30 0:52 UTC (permalink / raw)
To: git
I want to insert an empty initial commit so that I can rebase and edit
files in the real initial commit. There is a --root option in
git-rebase but I can not find example of how to use it.
I googled some said it needs to create a new branch, I tried but it
failed to merge.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: How does git follow branch history across a merge commit?
From: Steven E. Harris @ 2009-08-30 0:29 UTC (permalink / raw)
To: git
In-Reply-To: <7vy6p38p4j.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> *1* If you do not know what a merge simplification is, refer to e.g.
> http://gitster.livejournal.com/35628.html and notice there is a place
> where we follow "a parent that is the same as the merge result".
I read this article today with great interest. Had I known of it
beforehand, it would have changed some of my flawed assumptions evident
in my post. Thanks for writing that. I'll be looking into the rest of
the articles there to learn more.
--
Steven E. Harris
^ permalink raw reply
* Re: [BUG] git stash refuses to save after "add -N"
From: Junio C Hamano @ 2009-08-29 22:34 UTC (permalink / raw)
To: Jeff King; +Cc: Yann Dirson, git
In-Reply-To: <20090828190531.GB11488@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> - inserted as blank files, then you may be a bit surprised by the fact
> that it looks like you added a blank version, but at least you will
> still see a diff against the working tree file, alerting you to the
> fact that maybe they weren't entirely ready for commit.
>
> So I think of the three, the last one is the least surprising. The other
> option is to die and force the user to resolve the issue, which is what
> we do now. It does actually tell you the problem "bar: not added yet",
> though we could perhaps improve on that message a bit.
I am slightly in favor of leaving the things as they are, as the error
message is quite clear.
The third option would probably loo like this, which is not too bad,
though.
builtin-commit.c | 2 +-
builtin-write-tree.c | 3 +++
cache-tree.c | 29 ++++++++++++++---------------
cache-tree.h | 4 +++-
git-stash.sh | 2 +-
merge-recursive.c | 2 +-
test-dump-cache-tree.c | 2 +-
7 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 200ffda..fc97d54 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -595,7 +595,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
if (!active_cache_tree)
active_cache_tree = cache_tree();
if (cache_tree_update(active_cache_tree,
- active_cache, active_nr, 0, 0) < 0) {
+ active_cache, active_nr, 0) < 0) {
error("Error building trees");
return 0;
}
diff --git a/builtin-write-tree.c b/builtin-write-tree.c
index b223af4..6fce25e 100644
--- a/builtin-write-tree.c
+++ b/builtin-write-tree.c
@@ -23,6 +23,9 @@ int cmd_write_tree(int argc, const char **argv, const char *unused_prefix)
struct option write_tree_options[] = {
OPT_BIT(0, "missing-ok", &flags, "allow missing objects",
WRITE_TREE_MISSING_OK),
+ OPT_BIT(0, "intent-as-empty", &flags,
+ "write intent-to-add entries as empty blobs",
+ WRITE_TREE_ADD_INTENT_AS_EMPTY),
{ OPTION_STRING, 0, "prefix", &prefix, "<prefix>/",
"write tree object for a subdirectory <prefix>" ,
PARSE_OPT_LITERAL_ARGHELP },
diff --git a/cache-tree.c b/cache-tree.c
index d917437..7377066 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -148,7 +148,7 @@ void cache_tree_invalidate_path(struct cache_tree *it, const char *path)
}
static int verify_cache(struct cache_entry **cache,
- int entries)
+ int entries, int flags)
{
int i, funny;
@@ -156,7 +156,9 @@ static int verify_cache(struct cache_entry **cache,
funny = 0;
for (i = 0; i < entries; i++) {
struct cache_entry *ce = cache[i];
- if (ce_stage(ce) || (ce->ce_flags & CE_INTENT_TO_ADD)) {
+ if (ce_stage(ce) ||
+ (!(flags & WRITE_TREE_ADD_INTENT_AS_EMPTY) &&
+ (ce->ce_flags & CE_INTENT_TO_ADD))) {
if (10 < ++funny) {
fprintf(stderr, "...\n");
break;
@@ -237,8 +239,7 @@ static int update_one(struct cache_tree *it,
int entries,
const char *base,
int baselen,
- int missing_ok,
- int dryrun)
+ int flags)
{
struct strbuf buffer;
int i;
@@ -284,8 +285,7 @@ static int update_one(struct cache_tree *it,
cache + i, entries - i,
path,
baselen + sublen + 1,
- missing_ok,
- dryrun);
+ flags);
if (subcnt < 0)
return subcnt;
i += subcnt - 1;
@@ -328,7 +328,9 @@ static int update_one(struct cache_tree *it,
mode = ce->ce_mode;
entlen = pathlen - baselen;
}
- if (mode != S_IFGITLINK && !missing_ok && !has_sha1_file(sha1))
+ if (mode != S_IFGITLINK &&
+ !(flags & WRITE_TREE_MISSING_OK) &&
+ !has_sha1_file(sha1))
return error("invalid object %06o %s for '%.*s'",
mode, sha1_to_hex(sha1), entlen+baselen, path);
@@ -345,7 +347,7 @@ static int update_one(struct cache_tree *it,
#endif
}
- if (dryrun)
+ if (flags & WRITE_TREE_DRY_RUN)
hash_sha1_file(buffer.buf, buffer.len, tree_type, it->sha1);
else if (write_sha1_file(buffer.buf, buffer.len, tree_type, it->sha1)) {
strbuf_release(&buffer);
@@ -365,14 +367,13 @@ static int update_one(struct cache_tree *it,
int cache_tree_update(struct cache_tree *it,
struct cache_entry **cache,
int entries,
- int missing_ok,
- int dryrun)
+ int flags)
{
int i;
- i = verify_cache(cache, entries);
+ i = verify_cache(cache, entries, flags);
if (i)
return i;
- i = update_one(it, cache, entries, "", 0, missing_ok, dryrun);
+ i = update_one(it, cache, entries, "", 0, flags);
if (i < 0)
return i;
return 0;
@@ -565,11 +566,9 @@ int write_cache_as_tree(unsigned char *sha1, int flags, const char *prefix)
was_valid = cache_tree_fully_valid(active_cache_tree);
if (!was_valid) {
- int missing_ok = flags & WRITE_TREE_MISSING_OK;
-
if (cache_tree_update(active_cache_tree,
active_cache, active_nr,
- missing_ok, 0) < 0)
+ flags) < 0)
return WRITE_TREE_UNMERGED_INDEX;
if (0 <= newfd) {
if (!write_cache(newfd, active_cache, active_nr) &&
diff --git a/cache-tree.h b/cache-tree.h
index 3df641f..4ee03bb 100644
--- a/cache-tree.h
+++ b/cache-tree.h
@@ -29,11 +29,13 @@ void cache_tree_write(struct strbuf *, struct cache_tree *root);
struct cache_tree *cache_tree_read(const char *buffer, unsigned long size);
int cache_tree_fully_valid(struct cache_tree *);
-int cache_tree_update(struct cache_tree *, struct cache_entry **, int, int, int);
+int cache_tree_update(struct cache_tree *, struct cache_entry **, int, int);
/* bitmasks to write_cache_as_tree flags */
#define WRITE_TREE_MISSING_OK 1
#define WRITE_TREE_IGNORE_CACHE_TREE 2
+#define WRITE_TREE_ADD_INTENT_AS_EMPTY 4
+#define WRITE_TREE_DRY_RUN 8
/* error return codes */
#define WRITE_TREE_UNREADABLE_INDEX (-1)
diff --git a/git-stash.sh b/git-stash.sh
index d61c9d0..735e511 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -63,7 +63,7 @@ create_stash () {
msg=$(printf '%s: %s' "$branch" "$head")
# state of the index
- i_tree=$(git write-tree) &&
+ i_tree=$(git write-tree --intent-as-empty) &&
i_commit=$(printf 'index on %s\n' "$msg" |
git commit-tree $i_tree -p $b_commit) ||
die "Cannot save the current index state"
diff --git a/merge-recursive.c b/merge-recursive.c
index 10d7913..dea5400 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -211,7 +211,7 @@ struct tree *write_tree_from_memory(struct merge_options *o)
if (!cache_tree_fully_valid(active_cache_tree) &&
cache_tree_update(active_cache_tree,
- active_cache, active_nr, 0, 0) < 0)
+ active_cache, active_nr, 0) < 0)
die("error building trees");
result = lookup_tree(active_cache_tree->sha1);
diff --git a/test-dump-cache-tree.c b/test-dump-cache-tree.c
index 1f73f1e..a6ffdf3 100644
--- a/test-dump-cache-tree.c
+++ b/test-dump-cache-tree.c
@@ -59,6 +59,6 @@ int main(int ac, char **av)
struct cache_tree *another = cache_tree();
if (read_cache() < 0)
die("unable to read index file");
- cache_tree_update(another, active_cache, active_nr, 0, 1);
+ cache_tree_update(another, active_cache, active_nr, WRITE_TREE_DRY_RUN);
return dump_cache_tree(active_cache_tree, another, "");
}
^ permalink raw reply related
* Re: [PATCH] Allow testing of _relative family of time formatting and parsing functions
From: Junio C Hamano @ 2009-08-29 21:46 UTC (permalink / raw)
To: Alex Riesen; +Cc: Jeff King, Nicolas Pitre, David Reiss, git
In-Reply-To: <20090828205232.GD9233@blimp.localdomain>
Alex Riesen <raa.lkml@gmail.com> writes:
> To complement the testability of approxidate.
> ---
> Alex Riesen, Fri, Aug 28, 2009 21:33:02 +0200:
>>
>> It should allow safe testing of this part of the code.
>
> And this should really allow testing of it:
>
> $ ./test-date '10.days.ago'
> 10.days.ago -> bad -> Thu Jan 1 01:00:00 1970
> 10.days.ago -> Tue Aug 18 22:50:20 2009
>
> relative: 10.days.ago -> Fri Dec 22 12:00:00 1989
>
> relative: 10 days ago, out of Fri Dec 22 12:00:00 1989
>
> $
What are these blank lines for? Is this intended as a serious submission
for inclusion? I am having a hrad time to guess, especially you did not
sign this off, nor Cc'ed me.
^ permalink raw reply
* Re: git-svn intermittent issues with absent_file
From: Ealdwulf Wuffinga @ 2009-08-29 21:35 UTC (permalink / raw)
To: Matthias Andree; +Cc: Eric Wong, git
In-Reply-To: <op.uzc46sm43myrm3@balu.cs.uni-paderborn.de>
On Fri, Aug 28, 2009 at 9:14 AM, Matthias
Andree<matthias.andree@uni-paderborn.de> wrote:
> So, the common idea set is apparently down to (a) intermittent server issues
> (I've asked for the relevant log excerpts) and (b) Cygwin issues, and we
> should keep in mind (c) git-svn, or svn bindings/libraries, losing the
> causes error conditions from (a) or (b) and git-svn just reporting later
> symptoms (absent files). More on the other experiments once I get around to
> them.
Won't help if it's a server issue, but if your suspicion towards
git-svn (or anything else you have the source for) increases, it may
be worth trying bbchop:
http://github.com/Ealdwulf/bbchop
That is like git-bisect, except it can cope with intermittent bugs.
Ealdwulf
^ permalink raw reply
* Re: vc in emacs problem with git
From: Junio C Hamano @ 2009-08-29 18:41 UTC (permalink / raw)
To: Rustom Mody; +Cc: help-gnu-emacs, Git Mailing List
In-Reply-To: <f46c52560908270914o7027dc0bo873544dc0687cc48@mail.gmail.com>
Rustom Mody <rustompmody@gmail.com> writes:
> Just updating my own question:
> when I do a C-x v v (vc-next-action)
> which is supposed to be the most basic operation for checking in a file I get
>
> Wrong type argument: stringp, nil
>
> So vc can be assumed to be a broken I guess?
Have you checked contrib/emacs/README?
^ permalink raw reply
* Re: vc in emacs problem with git
From: Rustom Mody @ 2009-08-29 14:37 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <f46c52560908270914o7027dc0bo873544dc0687cc48@mail.gmail.com>
On Thu, Aug 27, 2009 at 9:44 PM, Rustom Mody<rustompmody@gmail.com> wrote:
> Just updating my own question:
> when I do a C-x v v (vc-next-action)
> which is supposed to be the most basic operation for checking in a file I get
>
> Wrong type argument: stringp, nil
>
> So vc can be assumed to be a broken I guess?
Answering my own question:
Short answer: vc-git.el from git breaks vc in emacs
Long answer: see emacs mailing list discussion
http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/657d9c58baed7b0f#
^ permalink raw reply
* Re: git-bz: command line integration for bugzilla
From: Owen Taylor @ 2009-08-29 10:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3fxbbkpq5.fsf@localhost.localdomain>
On Sat, 2009-08-29 at 01:07 -0700, Jakub Narebski wrote:
> Owen Taylor <otaylor@redhat.com> writes:
>
> > Was filling out the Git user's survey today, and noticed that my git-bz
> > tool wasn't on the long list of "Git interfaces, implementations,
> > frontends and tools"
>
> Well, you can always add it in "Other (please specify)" in survey
Certainly. It was not meant as a real complaint - git has a large and
varied ecosystem.
> > - but then again, I've never really advertised it
> > beyond GNOME IRC. So, I was reminded to mention it here...
>
> Could you please add (short) information about this tool to Git Wiki:
> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
One step ahead of you there, added:
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#git-bz
yesterday.
- Owen
^ permalink raw reply
* [PATCH] UI consistency: allow --force for where -f means force
From: René Scharfe @ 2009-08-29 9:05 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
git branch, checkout, clean, mv and tag all have an option -f to override
certain checks. This patch makes them accept the long option --force as
a synonym.
While we're at it, document that checkout support --quiet as synonym for
its short option -q.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
Documentation/git-branch.txt | 1 +
Documentation/git-checkout.txt | 2 ++
Documentation/git-clean.txt | 1 +
Documentation/git-mv.txt | 1 +
Documentation/git-tag.txt | 1 +
builtin-branch.c | 2 +-
builtin-checkout.c | 2 +-
builtin-clean.c | 2 +-
builtin-mv.c | 2 +-
builtin-tag.c | 2 +-
10 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 9998887..aad71dc 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -76,6 +76,7 @@ OPTIONS
based sha1 expressions such as "<branchname>@\{yesterday}".
-f::
+--force::
Reset <branchname> to <startpoint> if <branchname> exists
already. Without `-f` 'git-branch' refuses to change an existing branch.
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index ad4b31e..b1314b5 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -45,9 +45,11 @@ file can be discarded to recreate the original conflicted merge result.
OPTIONS
-------
-q::
+--quiet::
Quiet, suppress feedback messages.
-f::
+--force::
When switching branches, proceed even if the index or the
working tree differs from HEAD. This is used to throw away
local changes.
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index ae8938b..9d291bd 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -32,6 +32,7 @@ OPTIONS
if you really want to remove such a directory.
-f::
+--force::
If the git configuration specifies clean.requireForce as true,
'git-clean' will refuse to run unless given -f or -n.
diff --git a/Documentation/git-mv.txt b/Documentation/git-mv.txt
index 9c56602..bdcb585 100644
--- a/Documentation/git-mv.txt
+++ b/Documentation/git-mv.txt
@@ -28,6 +28,7 @@ committed.
OPTIONS
-------
-f::
+--force::
Force renaming or moving of a file even if the target exists
-k::
Skip move or rename actions which would lead to an error
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 5113eae..299b04f 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -51,6 +51,7 @@ OPTIONS
Make a GPG-signed tag, using the given key
-f::
+--force::
Replace an existing tag with the given name (instead of failing)
-d::
diff --git a/builtin-branch.c b/builtin-branch.c
index 1a03d5f..9f57992 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -586,7 +586,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
OPT_BIT('m', NULL, &rename, "move/rename a branch and its reflog", 1),
OPT_BIT('M', NULL, &rename, "move/rename a branch, even if target exists", 2),
OPT_BOOLEAN('l', NULL, &reflog, "create the branch's reflog"),
- OPT_BOOLEAN('f', NULL, &force_create, "force creation (when already exists)"),
+ OPT_BOOLEAN('f', "force", &force_create, "force creation (when already exists)"),
{
OPTION_CALLBACK, 0, "no-merged", &merge_filter_ref,
"commit", "print only not merged branches",
diff --git a/builtin-checkout.c b/builtin-checkout.c
index c6d6ac9..36e2116 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -584,7 +584,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
2),
OPT_SET_INT('3', "theirs", &opts.writeout_stage, "stage",
3),
- OPT_BOOLEAN('f', NULL, &opts.force, "force"),
+ OPT_BOOLEAN('f', "force", &opts.force, "force"),
OPT_BOOLEAN('m', "merge", &opts.merge, "merge"),
OPT_STRING(0, "conflict", &conflict_style, "style",
"conflict style (merge or diff3)"),
diff --git a/builtin-clean.c b/builtin-clean.c
index 05c763c..28cdcd0 100644
--- a/builtin-clean.c
+++ b/builtin-clean.c
@@ -41,7 +41,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
struct option options[] = {
OPT__QUIET(&quiet),
OPT__DRY_RUN(&show_only),
- OPT_BOOLEAN('f', NULL, &force, "force"),
+ OPT_BOOLEAN('f', "force", &force, "force"),
OPT_BOOLEAN('d', NULL, &remove_directories,
"remove whole directories"),
OPT_BOOLEAN('x', NULL, &ignored, "remove ignored files, too"),
diff --git a/builtin-mv.c b/builtin-mv.c
index b592c36..1b20028 100644
--- a/builtin-mv.c
+++ b/builtin-mv.c
@@ -53,7 +53,7 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
int verbose = 0, show_only = 0, force = 0, ignore_errors = 0;
struct option builtin_mv_options[] = {
OPT__DRY_RUN(&show_only),
- OPT_BOOLEAN('f', NULL, &force, "force move/rename even if target exists"),
+ OPT_BOOLEAN('f', "force", &force, "force move/rename even if target exists"),
OPT_BOOLEAN('k', NULL, &ignore_errors, "skip move/rename errors"),
OPT_END(),
};
diff --git a/builtin-tag.c b/builtin-tag.c
index a51a6d1..c479018 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -390,7 +390,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
OPT_BOOLEAN('s', NULL, &sign, "annotated and GPG-signed tag"),
OPT_STRING('u', NULL, &keyid, "key-id",
"use another key to sign the tag"),
- OPT_BOOLEAN('f', NULL, &force, "replace the tag if exists"),
+ OPT_BOOLEAN('f', "force", &force, "replace the tag if exists"),
OPT_GROUP("Tag listing options"),
{
--
1.6.4.1
^ permalink raw reply related
* [PATCH] update-server-info: make builtin, use parseopt
From: René Scharfe @ 2009-08-29 9:04 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
Convert git update-server-info to a built-in command and use parseopt.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
Makefile | 2 +-
builtin-update-server-info.c | 25 +++++++++++++++++++++++++
builtin.h | 1 +
git.c | 1 +
update-server-info.c | 28 ----------------------------
5 files changed, 28 insertions(+), 29 deletions(-)
create mode 100644 builtin-update-server-info.c
delete mode 100644 update-server-info.c
diff --git a/Makefile b/Makefile
index d842e52..a614347 100644
--- a/Makefile
+++ b/Makefile
@@ -357,7 +357,6 @@ PROGRAMS += git-patch-id$X
PROGRAMS += git-shell$X
PROGRAMS += git-show-index$X
PROGRAMS += git-unpack-file$X
-PROGRAMS += git-update-server-info$X
PROGRAMS += git-upload-pack$X
PROGRAMS += git-var$X
@@ -636,6 +635,7 @@ BUILTIN_OBJS += builtin-tar-tree.o
BUILTIN_OBJS += builtin-unpack-objects.o
BUILTIN_OBJS += builtin-update-index.o
BUILTIN_OBJS += builtin-update-ref.o
+BUILTIN_OBJS += builtin-update-server-info.o
BUILTIN_OBJS += builtin-upload-archive.o
BUILTIN_OBJS += builtin-verify-pack.o
BUILTIN_OBJS += builtin-verify-tag.o
diff --git a/builtin-update-server-info.c b/builtin-update-server-info.c
new file mode 100644
index 0000000..2b3fddc
--- /dev/null
+++ b/builtin-update-server-info.c
@@ -0,0 +1,25 @@
+#include "cache.h"
+#include "builtin.h"
+#include "parse-options.h"
+
+static const char * const update_server_info_usage[] = {
+ "git update-server-info [--force]",
+ NULL
+};
+
+int cmd_update_server_info(int argc, const char **argv, const char *prefix)
+{
+ int force = 0;
+ struct option options[] = {
+ OPT_BOOLEAN('f', "force", &force,
+ "update the info files from scratch"),
+ OPT_END()
+ };
+
+ argc = parse_options(argc, argv, prefix, options,
+ update_server_info_usage, 0);
+ if (argc > 0)
+ usage_with_options(update_server_info_usage, options);
+
+ return !!update_server_info(force);
+}
diff --git a/builtin.h b/builtin.h
index 51e4ba7..a2174dc 100644
--- a/builtin.h
+++ b/builtin.h
@@ -102,6 +102,7 @@ extern int cmd_tar_tree(int argc, const char **argv, const char *prefix);
extern int cmd_unpack_objects(int argc, const char **argv, const char *prefix);
extern int cmd_update_index(int argc, const char **argv, const char *prefix);
extern int cmd_update_ref(int argc, const char **argv, const char *prefix);
+extern int cmd_update_server_info(int argc, const char **argv, const char *prefix);
extern int cmd_upload_archive(int argc, const char **argv, const char *prefix);
extern int cmd_upload_tar(int argc, const char **argv, const char *prefix);
extern int cmd_verify_tag(int argc, const char **argv, const char *prefix);
diff --git a/git.c b/git.c
index 5da6c65..0b22595 100644
--- a/git.c
+++ b/git.c
@@ -359,6 +359,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "unpack-objects", cmd_unpack_objects, RUN_SETUP },
{ "update-index", cmd_update_index, RUN_SETUP },
{ "update-ref", cmd_update_ref, RUN_SETUP },
+ { "update-server-info", cmd_update_server_info, RUN_SETUP },
{ "upload-archive", cmd_upload_archive },
{ "verify-tag", cmd_verify_tag, RUN_SETUP },
{ "version", cmd_version },
diff --git a/update-server-info.c b/update-server-info.c
deleted file mode 100644
index 7b38fd8..0000000
--- a/update-server-info.c
+++ /dev/null
@@ -1,28 +0,0 @@
-#include "cache.h"
-#include "exec_cmd.h"
-
-static const char update_server_info_usage[] =
-"git update-server-info [--force]";
-
-int main(int ac, char **av)
-{
- int i;
- int force = 0;
- for (i = 1; i < ac; i++) {
- if (av[i][0] == '-') {
- if (!strcmp("--force", av[i]) ||
- !strcmp("-f", av[i]))
- force = 1;
- else
- usage(update_server_info_usage);
- }
- }
- if (i != ac)
- usage(update_server_info_usage);
-
- git_extract_argv0_path(av[0]);
-
- setup_git_directory();
-
- return !!update_server_info(force);
-}
--
1.6.4.1
^ permalink raw reply related
* Re: [PATCH] Remove unused t/t8005/iso8859-5.txt file
From: Nanako Shiraishi @ 2009-08-29 8:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6p3giwf.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Out of curiosity, how did you find this?
Soon after you posted your original in http://thread.gmane.org/gmane.comp.version-control.git/121881, I applied it to my tree, and I have been running 'git pull --rebase' for ever. I noticed that rebase didn't remove the commit, even after your 54bc13c.
Today I found that the rebased patch only removed that file. The real question is how you lost the deletion of the file when you applied. What happened?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: git-bz: command line integration for bugzilla
From: Jakub Narebski @ 2009-08-29 8:07 UTC (permalink / raw)
To: Owen Taylor; +Cc: git
In-Reply-To: <1251512664.666.349.camel@localhost.localdomain>
Owen Taylor <otaylor@redhat.com> writes:
> Was filling out the Git user's survey today, and noticed that my git-bz
> tool wasn't on the long list of "Git interfaces, implementations,
> frontends and tools"
Well, you can always add it in "Other (please specify)" in survey
> - but then again, I've never really advertised it
> beyond GNOME IRC. So, I was reminded to mention it here...
Could you please add (short) information about this tool to Git Wiki:
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Remove unused t/t8005/iso8859-5.txt file
From: Junio C Hamano @ 2009-08-29 7:48 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20090829161637.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> This file is no longer used since commit 54bc13c.
Hmm, the patch is grossly encoding damaged, so I'll hand apply.
Out of curiosity, how did you find this?
^ permalink raw reply
* [PATCH] Majorly simplify the definition of scissors line
From: しらいし ななこ @ 2009-08-29 7:17 UTC (permalink / raw)
To: git; +Cc: Nicolas Sebrecht, Junio C Hamano
The definition of scissors line was "a line that mainly consists of
scissors and perforation". While it is easy to explain to new people,
this does not exactly define where the line between "mainly consists
of" and "contains some amount of" lies.
Make the definition more strict and allow only lines that begin with
a '-- >8 --' (or its left-handed equivalent '-- 8< --'), which is
equally easy to explain to new people. More important, the rule is
much shorter and more precise, so it is easier to remember.
This pattern also is how Nicolas Sebrecht initially thought what the
definition was, without reading what Junio's code really did, so we
have an empirical evidence that this matches at least one newcomer's
intuition.
Signed-off-by: しらいし ななこ <nanako3@lavabit.com>
---
Documentation/git-mailinfo.txt | 4 +-
builtin-mailinfo.c | 48 +++------------------------------------
t/t5100/msg0014 | 4 +-
t/t5100/sample.mbox | 4 +-
4 files changed, 10 insertions(+), 50 deletions(-)
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index 71b93ad..1c2c414 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -56,8 +56,8 @@ conversion, even with this flag.
--scissors::
Remove everything in body before a scissors line. A line that
- mainly consists of scissors (either ">8" or "8<") and perforation
- (dash "-") marks is called a scissors line, and is used to request
+ begins with "-- >8 --" or "-- 8< --" is called a scissors line,
+ and is used to request
the reader to cut the message at that line. If such a line
appears in the body of the message before the patch, everything
before it (including the scissors line itself) is ignored when
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 508bdf0..1bbad4e 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -722,52 +722,12 @@ static inline int patchbreak(const struct strbuf *line)
static int is_scissors_line(const struct strbuf *line)
{
- size_t i, len = line->len;
- int scissors = 0, gap = 0;
- int first_nonblank = -1;
- int last_nonblank = 0, visible, perforation = 0, in_perforation = 0;
const char *buf = line->buf;
+ size_t len = line->len;
- for (i = 0; i < len; i++) {
- if (isspace(buf[i])) {
- if (in_perforation) {
- perforation++;
- gap++;
- }
- continue;
- }
- last_nonblank = i;
- if (first_nonblank < 0)
- first_nonblank = i;
- if (buf[i] == '-') {
- in_perforation = 1;
- perforation++;
- continue;
- }
- if (i + 1 < len &&
- (!memcmp(buf + i, ">8", 2) || !memcmp(buf + i, "8<", 2))) {
- in_perforation = 1;
- perforation += 2;
- scissors += 2;
- i++;
- continue;
- }
- in_perforation = 0;
- }
-
- /*
- * The mark must be at least 8 bytes long (e.g. "-- >8 --").
- * Even though there can be arbitrary cruft on the same line
- * (e.g. "cut here"), in order to avoid misidentification, the
- * perforation must occupy more than a third of the visible
- * width of the line, and dashes and scissors must occupy more
- * than half of the perforation.
- */
-
- visible = last_nonblank - first_nonblank + 1;
- return (scissors && 8 <= visible &&
- visible < perforation * 3 &&
- gap * 2 < perforation);
+ if (len < 8)
+ return 0;
+ return (!memcmp("-- >8 --", buf, 8) || !memcmp("-- 8< --", buf, 8));
}
static int handle_commit_msg(struct strbuf *line)
diff --git a/t/t5100/msg0014 b/t/t5100/msg0014
index 62e5cd2..187ff57 100644
--- a/t/t5100/msg0014
+++ b/t/t5100/msg0014
@@ -6,8 +6,8 @@ Subject: [PATCH] BLAH TWO
And then we will see the scissors.
- This line is not a scissors mark -- >8 -- but talks about it.
- - - >8 - - please remove everything above this line - - >8 - -
+ This is not a scissors line -- >8 -- but talks about it.
+-- >8 -- please remove everything above this line -- >8 --
Subject: [PATCH] Teach mailinfo to ignore everything before -- >8 -- mark
From: Junio C Hamano <gitster@pobox.com>
diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
index 13fa4ae..563f713 100644
--- a/t/t5100/sample.mbox
+++ b/t/t5100/sample.mbox
@@ -576,8 +576,8 @@ Subject: [PATCH] BLAH TWO
And then we will see the scissors.
- This line is not a scissors mark -- >8 -- but talks about it.
- - - >8 - - please remove everything above this line - - >8 - -
+ This is not a scissors line -- >8 -- but talks about it.
+-- >8 -- please remove everything above this line -- >8 --
Subject: [PATCH] Teach mailinfo to ignore everything before -- >8 -- mark
From: Junio C Hamano <gitster@pobox.com>
--
1.6.4.1
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* [PATCH] Remove unused t/t8005/iso8859-5.txt file
From: Nanako Shiraishi, しらいし ななこ @ 2009-08-29 7:16 UTC (permalink / raw)
To: git
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 676 bytes --]
This file is no longer used since commit 54bc13c.
Signed-off-by: ’¤·’¤é’¤¤’¤· ’¤Ê’¤Ê’¤³ <nanako3@lavabit.com>
---
t/t8005/iso8859-5.txt | Bin 74 -> 0 bytes
1 files changed, 0 insertions(+), 0 deletions(-)
delete mode 100644 t/t8005/iso8859-5.txt
diff --git a/t/t8005/iso8859-5.txt b/t/t8005/iso8859-5.txt
deleted file mode 100644
index 2e4b80c8df4da30722561049c46cca778e49cd2f..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001
literal 74
zcmeYa_P4MwwTw57_jB}hwN=`2>B3!w{Z}77xOeHsbA^L9uG|B%l(;<M%6x;}ZIupP
Zefa3!rF&Nu9^Sim@#WRKH?Asi0RTCvCqV!J
--
1.6.4.1
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] upload-pack: add a trigger for post-upload-pack hook
From: Junio C Hamano @ 2009-08-29 6:17 UTC (permalink / raw)
To: Jakub Narebski
Cc: Johan Sorensen, Jeff King, Tom Werner, Tom Preston-Werner, git
In-Reply-To: <m3ws4pl6x7.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
>> I'd like to suggest the following line from the original patch:
>>
>> full-pack integer::
>> 1 if the request was considered a full clone, 0 if it was a
>> partial update (fetch)
>
> If it is all "want" and no "have", it is clone or fetch into empty
> repository. If additionaly "want"s cover all refs, it is a clone.
> No need to pass this information: it can be derived.
Well, not exactly.
Here is an iffy RFC patch. Iffy not in the sense that its implementation
is questionable, but in the sense that I am not really convinced if the
distinction between fetching some (or in the worst case, most) but not all
refs, and fetching full set of refs, into an empty repository is something
worth making.
Does anybody from GitHub have any input? Is there something that can
still improved to suit GitHub's needs?
-- >8 --
Subject: [PATCH] upload-pack: feed "kind [clone|fetch]" to post-upload-pack hook
A request to clone the repository does not give any "have" but asks for
all the refs we offer with "want". When a request does not ask to clone
the repository fully, but asks to fetch some refs into an empty
repository, it will not give any "have" but its "want" won't ask for all
the refs we offer.
If we suppose (and I would say this is a rather big if) that it makes
sense to distinguish these two cases, a hook cannot reliably do this
alone. The hook can detect lack of "have" and bunch of "want", but there
is no direct way to tell if the other end asked for all refs we offered,
or merely most of them.
Between the time we talked with the other end and the time the hook got
called, we may have acquired more refs or lost some refs in the repository
by concurrent operations. Given that we plan to introduce selective
advertisement of refs with a protocol extension, it would become even more
difficult for hooks to guess between these two cases.
This adds "kind [clone|fetch]" to hook's input, as a stable interface to
allow the hooks to tell these cases apart.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/githooks.txt | 4 ++++
t/t5501-post-upload-pack.sh | 24 ++++++++++++++++++++++--
upload-pack.c | 4 ++++
3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 036f6c7..c308d29 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -332,6 +332,10 @@ time float::
size decimal::
Size of the resulting packfile in bytes.
+kind string:
+ Either "clone" (when the client did not give us any "have", and asked
+ for all our refs with "want"), or "fetch" (otherwise).
+
pre-auto-gc
-----------
diff --git a/t/t5501-post-upload-pack.sh b/t/t5501-post-upload-pack.sh
index 47ee7b5..d89fb51 100755
--- a/t/t5501-post-upload-pack.sh
+++ b/t/t5501-post-upload-pack.sh
@@ -29,7 +29,9 @@ test_expect_success initial '
) &&
want=$(sed -n "s/^want //p" "$LOGFILE") &&
test "$want" = "$(git rev-parse --verify B)" &&
- ! grep "^have " "$LOGFILE"
+ ! grep "^have " "$LOGFILE" &&
+ kind=$(sed -n "s/^kind //p" "$LOGFILE") &&
+ test "$kind" = fetch
'
test_expect_success second '
@@ -43,7 +45,25 @@ test_expect_success second '
want=$(sed -n "s/^want //p" "$LOGFILE") &&
test "$want" = "$(git rev-parse --verify C)" &&
have=$(sed -n "s/^have //p" "$LOGFILE") &&
- test "$have" = "$(git rev-parse --verify B)"
+ test "$have" = "$(git rev-parse --verify B)" &&
+ kind=$(sed -n "s/^kind //p" "$LOGFILE") &&
+ test "$kind" = fetch
+'
+
+test_expect_success all '
+ rm -fr sub &&
+ HERE=$(pwd) &&
+ git init sub &&
+ (
+ cd sub &&
+ git clone "file://$HERE/.git" new
+ ) &&
+ sed -n "s/^want //p" "$LOGFILE" | sort >actual &&
+ git rev-parse A B C | sort >expect &&
+ test_cmp expect actual &&
+ ! grep "^have " "$LOGFILE" &&
+ kind=$(sed -n "s/^kind //p" "$LOGFILE") &&
+ test "$kind" = clone
'
test_done
diff --git a/upload-pack.c b/upload-pack.c
index 857440d..8e82179 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -187,6 +187,10 @@ static int run_post_upload_pack_hook(size_t total, struct timeval *tv)
(long)tv->tv_sec, (long)tv->tv_usec);
if (!err)
err |= feed_msg_to_hook(proc.in, "size %ld\n", (long)total);
+ if (!err)
+ err |= feed_msg_to_hook(proc.in, "kind %s\n",
+ (nr_our_refs == want_obj.nr && !have_obj.nr)
+ ? "clone" : "fetch");
if (close(proc.in))
err = 1;
if (finish_command(&proc))
--
1.6.4.1.307.g70e9f
^ permalink raw reply related
* git-bz: command line integration for bugzilla
From: Owen Taylor @ 2009-08-29 2:24 UTC (permalink / raw)
To: git
Was filling out the Git user's survey today, and noticed that my git-bz
tool wasn't on the long list of "Git interfaces, implementations,
frontends and tools" - but then again, I've never really advertised it
beyond GNOME IRC. So, I was reminded to mention it here...
The Pitch
=========
Do you use git? You wouldn't be reading this list if you didn't. Do you
use Bugzilla? No? You can stop here.
Since you use Git and you use Bugzilla, you want to use git-bz.
Setup:
git config --global bz.default-tracker bugzilla.example.com
# in some module
git config bz.default-product TiddlyWinks
git config bz.default-component AI-Engine
File a new bug with a commit attached as a patch, rewrite the commit
message to include the URL of the newly filed bug:
git bz file -u HEAD
Attach a series of commits to an existing bug, bringing each up in
an editor to allow editing the comment and picking old patches to
obsolete:
git bz attach -e 43215 HEAD~3..
Apply patches already attached to an existing bug to a local branch:
git bz apply http://bugzilla.example.com/show_bug.cgi?34132
Getting It
==========
The script: http://git.fishsoup.net/cgit/git-bz/plain/git-bz
CGIT: http://git.fishsoup.net/cgit/git-bz
clone: git://git.fishsoup.net/git-bz
It's a standalone Python script, no dependencies, so you can just copy it
or symlink it somewhere in your path.
Notes
=====
* Yes, it's in Python.
* It should work with most Bugzilla installations
* There are some nice things that could be added - support for automatically
creating a branch when applying patches from a bug locally, 'git bz close'
to push patches and close the corresponding Bugzilla bugs, and so forth.
It's pretty good as is.
* The utility of attaching patches to Bugzilla is probably greatest
in a shared-central repository workflow. If all contributors already
are publishing all changes to personal public repositories, then attaching
them to Bugzilla in addition may not make sense.
Tracking merge requests would require a quite different form of Bugzilla
integration (probably server side)
* It used to be command-line compatible with git-format-patch for the handling
of 'git bz file <revision>' - but I switched it at some point so you didn't
need to add '-1' to file a single commit. Still undecided if it's better
to be obvious or to be compatible.
^ permalink raw reply
* Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults
From: Tay Ray Chuan @ 2009-08-29 2:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Ali Polatel, git
In-Reply-To: <7vprafzap3.fsf@alter.siamese.dyndns.org>
Hi,
On Sat, Aug 29, 2009 at 9:10 AM, Junio C Hamano<gitster@pobox.com> wrote:
> I forgot to add...
>
> In this case, it is _now_ clear to me that you consider your
>
> Subject: Re: git clone http://git.... segfaults
> To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Cc: Ali Polatel <polatel@gmail.com>, git@vger.kernel.org
> Date: Wed, 26 Aug 2009 20:20:53 +0800
> Message-ID: <20090826202053.6e6442a6.rctay89@gmail.com>
>
> to be the final version,
(I refer to this and your previous message) Thanks for taking the time
to explain the procedures/workflow involved. Yes, I thought Ali's
report on the patch was sufficient to flag the patch as
here-is-the-good one, but I didn't indicate this to you clearly
enough. Sorry for all the trouble.
> so I'd just add "noticed by Ali Polatel who later
> tested this patch to verify; Dscho helped to identify the problem spot."
> at the end of the commit log message in the message and apply. IOW, no
> need to resend.
Thanks again. Somehow, I neglected to include credits to Ali and Dscho.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults
From: Junio C Hamano @ 2009-08-29 1:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tay Ray Chuan, Johannes Schindelin, Ali Polatel, git
In-Reply-To: <7v8wh35tl8.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Nobody can expect me to keep track of everything; the final "Here is the
> good one" would help the process flow smoothly and reduce the chance of
> mistakes.
I forgot to add...
In this case, it is _now_ clear to me that you consider your
Subject: Re: git clone http://git.... segfaults
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Ali Polatel <polatel@gmail.com>, git@vger.kernel.org
Date: Wed, 26 Aug 2009 20:20:53 +0800
Message-ID: <20090826202053.6e6442a6.rctay89@gmail.com>
to be the final version, so I'd just add "noticed by Ali Polatel who later
tested this patch to verify; Dscho helped to identify the problem spot."
at the end of the commit log message in the message and apply. IOW, no
need to resend.
Ali's original report is about 1.6.4 so I presume this is 'maint'
material, so let's include this in 1.6.4.2.
^ permalink raw reply
* Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults
From: Junio C Hamano @ 2009-08-29 0:53 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Johannes Schindelin, Ali Polatel, git
In-Reply-To: <be6fef0d0908281707o59fdb0c9h9a5a78864b6ad063@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> 2009/8/26 Ali Polatel <polatel@gmail.com>:
>> It works, I don't get any segfaults after applying this patch.
>
> Junio, I hope you don't mind me asking but why hasn't this patch been
> accepted? It addresses a pretty severe problem, and the sooner users
> have it the better.
The procedure ideally goes like this:
(0) original bug report is sent; Ali did this with:
Date: Mon, 17 Aug 2009 16:56:52 +0300
Message-ID: <20090817135651.GA4570@harikalardiyari>
(1) a helpful contributor (or somebody ashamed of having introduced
the bug ;-)) sends a potential fix as an RFT to the reporter, with
Cc: to list. You did this with:
Date: Wed, 26 Aug 2009 20:20:53 +0800
Message-ID: <20090826202053.6e6442a6.rctay89@gmail.com>
This message was clear that it was a request-for-test of a
potential fix, not a "I know this is the correct fix to the
problem; the maintainer, please apply". It wasn't even Cc:'ed to
me, and not CC'ing me is the right thing to do for this kind of
request-for-test patches.
(2) success/failure report is given. Ali did this with:
Date: Wed, 26 Aug 2009 16:12:35 +0300
Message-ID: <20090826131235.GF16486@harikalardiyari>
to report a success.
(3) Upon seeing (2), the sender of (1) submits the final patch for
inclusion, with To: me and CC: list.
The sender makes sure that it is easy for me and others who sees
(3) first without necessarily having followed the earlier
discussions to find the previous messages (i.e. 0, 1, 2). In this
case, sending a follow-up to (2) is sufficient, just like you did
in the message I am responding to, because these three steps were
neatly threaded already.
If you knew the flow I am describing here, you would have sent
"the final patch for inclusion" instead of the message I am
replying to. The final patch for inclusion would have consisted
of:
* The usual "applicable patch": a proper subject, the log message,
your Signed-off-by:, and Tested-by: to credit Ali;
* Optionally, after the three-dash line before the diffstat, any
out-of-band communication, e.g.
"Junio, please apply to 'maint'; this is a fix for a grave bug,
and the problem goes all the way down to version 1.6.1."
* And the diffstat and the diff.
My request for this procedure is not red tape.
While an issue (such as this http one) is resolved that is in an area
(e.g. http) people other than me (i.e. you) are much more familiar with, I
do not have to keep track of the discussion while more capable hands are
on top of it. Having (3) as the concluding step will
- give me a way to easily verify, if I wanted to, the claim that this is
the right solution, by referring to the previous dialog; and
- give you a way to make sure that what is recorded is the correct final
solution (this is especially important if steps 1 and 2 have to be
repeated before reaching the final solution), and that the necessary
background information (e.g. credits to the original reporter) are
given in your own words, instead of having _me_ come up with one with
less-than-perfect understanding of the issues I would gain after
skimming the archive for the previous discussion.
Nobody can expect me to keep track of everything; the final "Here is the
good one" would help the process flow smoothly and reduce the chance of
mistakes.
Thanks.
^ permalink raw reply
* Re: How does git follow branch history across a merge commit?
From: Björn Steinbrink @ 2009-08-29 0:25 UTC (permalink / raw)
To: Steven E. Harris; +Cc: git
In-Reply-To: <831vmv5wh7.fsf@torus.sehlabs.com>
On 2009.08.28 19:50:44 -0400, Steven E. Harris wrote:
> I missed the point that merge commits are not "predecessor neutral";
> they apparently have a bias indicating "/this branch/ received content
> from /that branch/ (or /those branches/)".
>
> To try to recreate my confusing scenario, I tried this:
>
> ,----
> | git checkout competition
> | git merge master
> | # This fast-forwarded "competition" be equivalent to "master".
> | git checkout 'HEAD^'
> | # This wound up again at "master"'s predecessor, not "competition"'s.
> `----
>
> It seems that since fast-forward merges don't produce a commit, the
> merge record remains in place recording that branch "competition" came
> into branch "master".Even though we're checked out to branch
> "competition" here, following its history back in time requires some
> manual intervention. Do you concur, or is my example perhaps flawed?
As there is no merge commit, there's no "merge record" either.
"competition" just got updated to reference the same commit as "master".
Branch "competition" did not "come into" branch "master" either.
"competition" and "master" are just the names of the branch heads. And
those just reference commits, which actually form the history and have
no record of belonging to any branch head on their own.
IOW: "master" and "competition" aren't branches as in "a series of
commits with a fixed relation to each other", but just branch heads,
referencing the tips where the branches grow.
Scenario A:
Given this history:
A---B---C (master)
\
D---E (competition)
If you now merge "master" to "competition" you get:
A---B---C (master)
\ \
D---E---M (competition)
Where M is a merge commit with two parents, E being the first one, C
being the second one. And that's everything that git knows, that M is a
merged of C and E. That E is the first parent is just a smart choice,
nothing else.
Scenario B:
Given this history:
A (competition)
\
B---C (master)
If you ask git to merge "master" to "competition", it will see that
there aren't any commits reachable through "competition" that aren't
reachable through "master". So simply fast-forwarding "competition won't
make you lose anything. Thus you get:
A---B---C (master) (competition)
There's no trace of any merge, because it wasn't required. You can't
even tell that a fast-forward happened from that history. You could as
well just have created "competition".
That said, if you want to force a merge commit (which can sometimes be
useful), you can use the --no-ff flag:
git checkout competition
git merge --no-ff master
And this leads to:
A------M (competition)
\ /
B---C (master)
With M's first parent being A, and the second parent being C.
(Assuming that "competition" is a topic branch, this would be a bit
weird though, as you produce a totally pointless merge commit, before
you even started working on your topic branch. OTOH doing this the other way
around, i.e. forcing a merge commit when you merge a topic branch to
"master" _can_ be useful. Don't over do it though).
HTH
Björn
^ permalink raw reply
* Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults
From: Tay Ray Chuan @ 2009-08-29 0:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Ali Polatel, git
In-Reply-To: <20090826131235.GF16486@harikalardiyari>
Hi,
2009/8/26 Ali Polatel <polatel@gmail.com>:
> It works, I don't get any segfaults after applying this patch.
Junio, I hope you don't mind me asking but why hasn't this patch been
accepted? It addresses a pretty severe problem, and the sooner users
have it the better.
--
Cheers,
Ray Chuan
^ 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