* [PATCH 2/4] reset: use "unpack_trees()" directly instead of "git read-tree"
From: Christian Couder @ 2009-09-10 20:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski, Linus Torvalds
In-Reply-To: <20090910200334.3722.20140.chriscool@tuxfamily.org>
From: Stephan Beyer <s-beyer@gmx.net>
This patch makes "reset_index_file()" call "unpack_trees()" directly
instead of forking and execing "git read-tree".
The code comes from the sequencer GSoC project:
git://repo.or.cz/git/sbeyer.git
(at commit 5a78908b70ceb5a4ea9fd4b82f07ceba1f019079)
Mentored-by: Daniel Barkalow <barkalow@iabervon.org>
Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-reset.c | 51 ++++++++++++++++++++++++++++++++++++++++-----------
1 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/builtin-reset.c b/builtin-reset.c
index 73e6022..ddb81f3 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -18,6 +18,8 @@
#include "tree.h"
#include "branch.h"
#include "parse-options.h"
+#include "unpack-trees.h"
+#include "cache-tree.h"
static const char * const git_reset_usage[] = {
"git reset [--mixed | --soft | --hard | --merge] [-q] [<commit>]",
@@ -52,29 +54,56 @@ static inline int is_merge(void)
return !access(git_path("MERGE_HEAD"), F_OK);
}
+static int parse_and_init_tree_desc(const unsigned char *sha1,
+ struct tree_desc *desc)
+{
+ struct tree *tree = parse_tree_indirect(sha1);
+ if (!tree)
+ return 1;
+ init_tree_desc(desc, tree->buffer, tree->size);
+ return 0;
+}
+
static int reset_index_file(const unsigned char *sha1, int reset_type, int quiet)
{
- int i = 0;
- const char *args[6];
+ int nr = 1;
+ int newfd;
+ struct tree_desc desc[2];
+ struct unpack_trees_options opts;
+ struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));
- args[i++] = "read-tree";
+ memset(&opts, 0, sizeof(opts));
+ opts.head_idx = 1;
+ opts.src_index = &the_index;
+ opts.dst_index = &the_index;
+ opts.fn = oneway_merge;
+ opts.merge = 1;
if (!quiet)
- args[i++] = "-v";
+ opts.verbose_update = 1;
switch (reset_type) {
case MERGE:
- args[i++] = "-u";
- args[i++] = "-m";
+ opts.update = 1;
break;
case HARD:
- args[i++] = "-u";
+ opts.update = 1;
/* fallthrough */
default:
- args[i++] = "--reset";
+ opts.reset = 1;
}
- args[i++] = sha1_to_hex(sha1);
- args[i] = NULL;
- return run_command_v_opt(args, RUN_GIT_CMD);
+ newfd = hold_locked_index(lock, 1);
+
+ read_cache_unmerged();
+
+ if (parse_and_init_tree_desc(sha1, desc + nr - 1))
+ return error("Failed to find tree of %s.", sha1_to_hex(sha1));
+ if (unpack_trees(nr, desc, &opts))
+ return -1;
+ if (write_cache(newfd, active_cache, active_nr) ||
+ commit_locked_index(lock))
+ return error("Could not write new index file.");
+
+ return 0;
}
static void print_new_head_line(struct commit *commit)
--
1.6.4.271.ge010d
^ permalink raw reply related
* [PATCH 3/4] reset: add option "--merge-dirty" to "git reset"
From: Christian Couder @ 2009-09-10 20:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski, Linus Torvalds
In-Reply-To: <20090910200334.3722.20140.chriscool@tuxfamily.org>
From: Stephan Beyer <s-beyer@gmx.net>
This option is nearly like "--merge" except that it is
a little bit safer as it seems that it tries to keep
changes in the index. On the contrary "--merge", only
keep changes in the work tree.
This will be shown in the next patch that adds some
test cases for "--merge-dirty".
In fact with "--merge-dirty", changes that are both in
the work tree and the index are kept in the work tree
after the reset (but discarded in the index). As with
"--merge", changes that are in both the work tree and
the index are discarded after the reset.
So "--merge-dirty" is probably a very bad name for
this new option. Perhaps "--merge-safe" is better?
The code comes from the sequencer GSoC project:
git://repo.or.cz/git/sbeyer.git
(at commit 5a78908b70ceb5a4ea9fd4b82f07ceba1f019079)
Mentored-by: Daniel Barkalow <barkalow@iabervon.org>
Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-reset.c | 30 +++++++++++++++++++++++++-----
1 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/builtin-reset.c b/builtin-reset.c
index ddb81f3..be7aa8d 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -22,13 +22,15 @@
#include "cache-tree.h"
static const char * const git_reset_usage[] = {
- "git reset [--mixed | --soft | --hard | --merge] [-q] [<commit>]",
+ "git reset [--mixed | --soft | --hard | --merge | --merge-dirty] [-q] [<commit>]",
"git reset [--mixed] <commit> [--] <paths>...",
NULL
};
-enum reset_type { MIXED, SOFT, HARD, MERGE, NONE };
-static const char *reset_type_names[] = { "mixed", "soft", "hard", "merge", NULL };
+enum reset_type { MIXED, SOFT, HARD, MERGE, MERGE_DIRTY, NONE };
+static const char *reset_type_names[] = {
+ "mixed", "soft", "hard", "merge", "merge_dirty", NULL
+};
static char *args_to_str(const char **argv)
{
@@ -84,6 +86,7 @@ static int reset_index_file(const unsigned char *sha1, int reset_type, int quiet
case MERGE:
opts.update = 1;
break;
+ case MERGE_DIRTY:
case HARD:
opts.update = 1;
/* fallthrough */
@@ -95,6 +98,16 @@ static int reset_index_file(const unsigned char *sha1, int reset_type, int quiet
read_cache_unmerged();
+ if (reset_type == MERGE_DIRTY) {
+ unsigned char *head_sha1;
+ if (get_sha1("HEAD", head_sha1))
+ return error("You do not have a valid HEAD.");
+ if (parse_and_init_tree_desc(head_sha1, desc))
+ return error("Failed to find tree of HEAD.");
+ nr++;
+ opts.fn = twoway_merge;
+ }
+
if (parse_and_init_tree_desc(sha1, desc + nr - 1))
return error("Failed to find tree of %s.", sha1_to_hex(sha1));
if (unpack_trees(nr, desc, &opts))
@@ -238,6 +251,9 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
"reset HEAD, index and working tree", HARD),
OPT_SET_INT(0, "merge", &reset_type,
"reset HEAD, index and working tree", MERGE),
+ OPT_SET_INT(0, "merge-dirty", &reset_type,
+ "reset HEAD, index and working tree",
+ MERGE_DIRTY),
OPT_BOOLEAN('q', NULL, &quiet,
"disable showing new HEAD in hard reset and progress message"),
OPT_BOOLEAN('p', "patch", &patch_mode, "select hunks interactively"),
@@ -324,9 +340,13 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
if (reset_type == SOFT) {
if (is_merge() || read_cache() < 0 || unmerged_cache())
die("Cannot do a soft reset in the middle of a merge.");
+ } else {
+ int err = reset_index_file(sha1, reset_type, quiet);
+ if (reset_type == MERGE_DIRTY)
+ err = err || reset_index_file(sha1, MIXED, quiet);
+ if (err)
+ die("Could not reset index file to revision '%s'.", rev);
}
- else if (reset_index_file(sha1, reset_type, quiet))
- die("Could not reset index file to revision '%s'.", rev);
/* Any resets update HEAD to the head being switched to,
* saving the previous head in ORIG_HEAD before. */
--
1.6.4.271.ge010d
^ permalink raw reply related
* Re: obnoxious CLI complaints
From: Jakub Narebski @ 2009-09-10 20:23 UTC (permalink / raw)
To: John Tapsell; +Cc: Wincent Colaiuta, Brendan Miller, git
In-Reply-To: <43d8ce650909101246l50189c97r4f3fc4a8d7a0bd4@mail.gmail.com>
Dnia czwartek 10. września 2009 21:46, John Tapsell napisał:
> 2009/9/10 Jakub Narebski <jnareb@gmail.com>:
> > First, it would be consistent with how ordinary archivers such as tar
> > or zip are used, where you have to specify list of files to archive
> > (in our case this list is HEAD). Second, I'd rather not accidentally
> > dump binary to terminal: "git archive [HEAD]" dumps archive to standard
> > output.
>
> That could be fixed by outputting to a file. git format-patch outputs
> to a file, so why wouldn't git achieve?
"git format-patch" outputs to files because it generates _multiple_
files; generating single patch is special case. Also git-format-patch
can generate file names from patch (commit) subject; it is not the case
for "git archive" (what name should it use?).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Sverre Rabbelier @ 2009-09-10 20:17 UTC (permalink / raw)
To: John Tapsell; +Cc: Jakub Narebski, Wincent Colaiuta, Brendan Miller, git
In-Reply-To: <43d8ce650909101246l50189c97r4f3fc4a8d7a0bd4@mail.gmail.com>
Heya,
On Thu, Sep 10, 2009 at 21:46, John Tapsell <johnflux@gmail.com> wrote:
> That could be fixed by outputting to a file. git format-patch outputs
> to a file, so why wouldn't git achieve?
Because git format-patch works on a per-patch basis, and patches
inherently have a 'name' (the first line of the commit message), an
entire repository does not, so one would have to resort to arbitrary
names such as 'archive.tar.gz' or such.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Junio C Hamano @ 2009-09-10 19:53 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Jeff King, Clemens Buchacher, SZEDER Gbor, git
In-Reply-To: <20090910084653.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> We could probably declare "In 1.X.0 everything will be relative to the
>> root and you have to give an explicit '.' if you mean the cwd".
>>
>> Three questions:
>>
>> #1 What are the commands that will be affected, other than "add -u" and
>> "grep"? Are there others?
>>
>> #2 Do all the commands in the answer to #1 currently behave exactly the
>> same when run without any path parameter and when run with a single
>> '.'?
>
> 'git-archive' behaves relative to your current directory.
>
> http://thread.gmane.org/gmane.comp.version-control.git/41300/focus=44125
>
> You can limit it to the current directory with a dot.
Thanks.
If you want to make a tarball of the Documentation directory from your
work tree, you do this:
$ cd Documentation
$ tar cf - . >/tmp/docs.tar
If you want to do the same but from your committed content, you do this:
$ cd Documentation
$ git archive HEAD >/tmp/docs.tar
and you do not have to say:
$ cd Documentation
$ git archive HEAD . >/tmp/docs.tar
So in that sense it does make sense to archive the current directory. It
matches what the users expect from their archivers.
The traditional archivers may not default to "." but we do. That is about
giving a sensible default [*1*]. Perhaps defaulting to the cwd behaviour
for one command may seem a sensible thing when looking at that particular
command alone; archive and grep fall into that category.
But as this "add -u" discussion showed us [*2*], people may expect
different "sensible default", and as a suite of commands as the whole, it
becomes messy. People have to remember which ones obey cwd, and to some
people the choice is not intuitive.
To avoid confusion, I am beginning to agree with people who said in the
thread that it is a good idea to consistently default to the root of the
contents. When we use "everything" as the default due to lack of command
line pathspec, we would use "everything from root" no matter where you
are, regardless of what command we are talking about. That would make the
rule easier to remember [*3*].
This changes the way how "git (add -u|grep|clean|archive)" without
pathspec and "git (add -u|grep|clean|archive) ." with an explicit dot
work. The former (adds all changed files in, finds hits in, removes
untracked paths in, creates a tarball for) the whole tree, while the
latter limits the operation explicitly to the current directory.
If this were going to happen as a list concensus, I am very tempted to
suggest that we at least _consider_ applying the same rule even to
ls-files and ls-tree. That would impact scripts, so we need to be extra
careful, though.
Also this takes us to a tangent.
If we try to give a sensible default to make it easier for the user,
perhaps we should also default to HEAD when the user did not specify which
tree-ish to archive from. This is a topic in a separate thread.
[Footnote]
*1* Actually we don't allow "git archive HEAD ..", which I think is a
bug. Also we do not have --full-tree workaround, which makes it slightly
cumbersome to use.
*2* And the thread you quoted shows us that the argument applies equally
to "git archive" as well; you see me complaining that it is unintuitive
for me to care about "archive", and the counterargument was that ls-tree
does so. I however think it is more important for archive to behave in a
way that is easier for the users to understand, than mimick the historical
mistake in a plumbing command.
*3* Command line pathspec of course should honor cwd as before. When you
say "git distim Makefile" inside t/ directory, we distim t/Makefile, not
the toplevel Makefile. This discussion is only about the case where the
user didn't give us any pathspec.
^ permalink raw reply
* Re: obnoxious CLI complaints
From: John Tapsell @ 2009-09-10 19:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Wincent Colaiuta, Brendan Miller, git
In-Reply-To: <200909101850.26109.jnareb@gmail.com>
2009/9/10 Jakub Narebski <jnareb@gmail.com>:
> Dnia czwartek 10. września 2009 00:06, Wincent Colaiuta napisał:
>> El 09/09/2009, a las 23:54, Jakub Narebski escribió:
>>> Brendan Miller <catphive@catphive.net> writes:
>>>
>>>> 5. Most commands require lots of flags, and don't have reasonable
>>>> defaults. e.g. archive.
>>>>
>>>> $ git archive --format=tar --prefix=myproject/ HEAD |
>>>> > gzip myproject.tar.gz
>>>>
>>>> Should just be:
>>>> git archive
>>>> run from the root of the repo.
>>>
>>> I'd rather not have "git archive" work without specifying tree-ish.
>>
>> Why, out of interest? I would've thought that HEAD would be a pretty
>> good default, although I confess that I have never used "git archive"
>> without specifying a particular signed tag.
>
> First, it would be consistent with how ordinary archivers such as tar
> or zip are used, where you have to specify list of files to archive
> (in our case this list is HEAD). Second, I'd rather not accidentally
> dump binary to terminal: "git archive [HEAD]" dumps archive to standard
> output.
That could be fixed by outputting to a file. git format-patch outputs
to a file, so why wouldn't git achieve?
John
^ permalink raw reply
* Re: [PATCH v3 3/3] INSTALL: Describe dependency knobs from Makefile
From: Junio C Hamano @ 2009-09-10 18:56 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List
In-Reply-To: <1252591928-2278-1-git-send-email-brian@gernhardtsoftware.com>
Brian Gernhardt <brian@gernhardtsoftware.com> writes:
> We said that some of our dependencies were optional, but didn't say
> how to turn them off. Add information for that and mention where to
> save the options close to the top of the file.
>
> Also, standardize on both using quotes for the names of the dependencies
> and tabs for indentation of the list.
>
> Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
> ---
>
> Junio C Hamano <gitster@pobox.com> wrote:
> > I did not like calling "make variables" "options", and also it was unclear
> > what good these "options" are for. How about...
>
> Sounds good. Would have sent this out yesterday, but I ran out of tuits.
>
> INSTALL | 38 ++++++++++++++++++++++++--------------
> 1 files changed, 24 insertions(+), 14 deletions(-)
>
> diff --git a/INSTALL b/INSTALL
> index 7ab2580..69c97b2 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -13,6 +13,10 @@ that uses $prefix, the built results have some paths encoded,
> which are derived from $prefix, so "make all; make prefix=/usr
> install" would not work.
>
> +There are many options that can be configured in the makefile using either
> +command line defines or a config.mak file. These options are documented at
> +the beginning of the Makefile.
Sorry, but the description still speaks of options and does not say what
good they are. Sent a wrong patch?
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Matthieu Moy @ 2009-09-10 18:54 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Brendan Miller, git
In-Reply-To: <20090910013235.GA9980@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> On 2009.09.09 14:27:56 -0700, Brendan Miller wrote:
>> 8. There's no obvious way to make a remote your default push pull
>> location without editing the git config file. Why not just something
>> like
>>
>> git remote setdefault origin
>
> Because "git remote" is the wrong tool. The default remote for
> fetch/push is configured per branch head, not globally.
(the --track option of git branch and git checkout can help).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Junio C Hamano @ 2009-09-10 18:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Wincent Colaiuta, Brendan Miller, git
In-Reply-To: <200909101850.26109.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> First, it would be consistent with how ordinary archivers such as tar
> or zip are used, where you have to specify list of files to archive
> (in our case this list is HEAD). Second, I'd rather not accidentally
> dump binary to terminal: "git archive [HEAD]" dumps archive to standard
> output.
So does "cat". I do not agree with your second point.
While I somewhat see the similarity argument, your first point, I am not
sure if it is relevant. It is not like "tar or zip allows us to say what
files to archive, but git-archive doesn't and it always archives HEAD";
you are saying "they require us to specify, so should we".
But I do not see a strong reason not to default to HEAD. The case that
would make difference would be to differentiate among
$ git archive HEAD TAIL
$ git archive HEAD -- TAIL
$ git archive -- HEAD TAIL
i.e. what if you happen to have a tracked content called HEAD. I didn't
check the current command line parser in git-archive understands the "--"
convention for that, but it is not a rocket science to add it if it
doesn't.
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Sverre Rabbelier @ 2009-09-10 18:52 UTC (permalink / raw)
To: Eric Schaefer; +Cc: git
In-Reply-To: <34f8975d0909101118x7c95be1ehda085bea1611b70c@mail.gmail.com>
Heya,
On Thu, Sep 10, 2009 at 20:18, Eric Schaefer
<eric.schaefer@ericschaefer.org> wrote:
> "Unimportant bug reports"? Interesting concept... ;-)
Sure, if there's a bug in feature foo, but it only happens when
invoking it with some rarely used argument, and only on Solaris
platforms, it is probably not worth spending time on it if the
original reporter does not even have the time to stick around and aid
in resolving the issue. It's probably better to spend that precious
time on other bug fixes, or features instead.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
From: Junio C Hamano @ 2009-09-10 18:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0909101852080.8306@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> There is a reason why you call the series "foreign" vcs helpers. And
> that's because it would be very wrong to pretend that they are the rule,
> and the current URL schemes the exception. Very wrong, indeed.
I do not know what you mean by "very wrong".
If the name bothers you, you can think of the earlier part of the series
cleaning up the transport code so that it makes easier to choose which
transport, either internal or external, and ports the native transport
support to use the mechanism. Then the rest of the series builds on it to
add further support for "foreign" vcs helpers.
^ permalink raw reply
* Re: [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Junio C Hamano @ 2009-09-10 18:29 UTC (permalink / raw)
To: Jeff King
Cc: Johan Herland, git, Michael J Gruber, Johannes Schindelin,
Junio C Hamano, Björn Steinbrink, Pete Wyckoff
In-Reply-To: <20090910111156.GA2910@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Sep 10, 2009 at 12:18:06PM +0200, Johan Herland wrote:
>
>> > > A special shortcut '@{tracked}' refers to the branch tracked by the
>> > > current branch.
>> >
>> > Sorry, I didn't know the name of the long form was up for discussion.
>> > But it should certainly coincide with the key which for-each-ref
>> > uses, shouldn't it? I don't care whether tracked or upstream, but
>> > for-each-ref's "upstream" has set the precedent.
>>
>> ...and 'git branch --track' set an even earlier precedent...
>
> FWIW, that came about from this discussion:
>
> http://article.gmane.org/gmane.comp.version-control.git/115765
After re-reading the discussion in the thread that contains the quoted
article, it sounds like we may want to fix "branch --track X Y". X does
not "track" Y in the same sense as origin/master "tracks" master at
origin. Rather, X builds on Y.
^ permalink raw reply
* Re: [PATCH v2] git-p4: Avoid modules deprecated in Python 2.6.
From: Junio C Hamano @ 2009-09-10 18:22 UTC (permalink / raw)
To: Reilly Grant; +Cc: git
In-Reply-To: <1252566158-13305-1-git-send-email-reillyeon@qotw.net>
Reilly Grant <reillyeon@qotw.net> writes:
> The popen2, sha and sets modules are deprecated in Python 2.6 (sha in
> Python 2.5). Both popen2 and sha are not actually used in git-p4.
> Replace usage of sets.Set with the builtin set object.
>
> The built-in set object was added in Python 2.4 and is already used in
> other parts of this script, so this dependency is nothing new.
Thanks for a resend. Will apply.
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Eric Schaefer @ 2009-09-10 18:18 UTC (permalink / raw)
To: git
In-Reply-To: <200909101116.55098.jnareb@gmail.com>
2009/9/10 Jakub Narebski <jnareb@gmail.com>:
> This is a good way to separate important from unimportant bug reports
> and feature requests ;-)
"Unimportant bug reports"? Interesting concept... ;-)
BTW: A bug tracker has the advantage that bugs don't fall on the
floor. They can be postponed for later fixing but you will not forget
them.
But you are right about feature request. You would either have to have
a rigorous policy of dropping bogus or unwanted (unimportant) requests
or you go with the mailing list approach to keep the pile from
stinking. ;-)
Eric
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
From: Daniel Barkalow @ 2009-09-10 17:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0909101852080.8306@pacific.mpi-cbg.de>
On Thu, 10 Sep 2009, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 10 Sep 2009, Daniel Barkalow wrote:
>
> > I'm pretty sure that there were no objections to 'Make the
> > "traditonally-supported"...' patch,
>
> Well, there were. By me.
>
> There is a reason why you call the series "foreign" vcs helpers. And
> that's because it would be very wrong to pretend that they are the rule,
> and the current URL schemes the exception. Very wrong, indeed.
The current URL scheme *is* an "exception" to the "rule" that all remotes
are foreign, or the current "rule" that all remotes are ssh-style. Any
patterns that we currently support are handled by recognizing a particular
pattern (starts with "git://", starts with "rsync://", starts with
"https://", is a local file, is a local directory, etc), so they're all
special cases. They're further special cases by virtue of the fact that
the code to handle them is in the git distribution.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
From: Johannes Schindelin @ 2009-09-10 16:53 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.2.00.0909101206540.28290@iabervon.org>
Hi,
On Thu, 10 Sep 2009, Daniel Barkalow wrote:
> I'm pretty sure that there were no objections to 'Make the
> "traditonally-supported"...' patch,
Well, there were. By me.
There is a reason why you call the series "foreign" vcs helpers. And
that's because it would be very wrong to pretend that they are the rule,
and the current URL schemes the exception. Very wrong, indeed.
Thankyouvermuch,
Dscho
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Jakub Narebski @ 2009-09-10 16:50 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Brendan Miller, git
In-Reply-To: <4C1FB36D-F8A6-4C01-A42A-8AD2355A9961@wincent.com>
Dnia czwartek 10. września 2009 00:06, Wincent Colaiuta napisał:
> El 09/09/2009, a las 23:54, Jakub Narebski escribió:
>> Brendan Miller <catphive@catphive.net> writes:
>>
>>> 5. Most commands require lots of flags, and don't have reasonable
>>> defaults. e.g. archive.
>>>
>>> $ git archive --format=tar --prefix=myproject/ HEAD |
>>> > gzip myproject.tar.gz
>>>
>>> Should just be:
>>> git archive
>>> run from the root of the repo.
>>
>> I'd rather not have "git archive" work without specifying tree-ish.
>
> Why, out of interest? I would've thought that HEAD would be a pretty
> good default, although I confess that I have never used "git archive"
> without specifying a particular signed tag.
First, it would be consistent with how ordinary archivers such as tar
or zip are used, where you have to specify list of files to archive
(in our case this list is HEAD). Second, I'd rather not accidentally
dump binary to terminal: "git archive [HEAD]" dumps archive to standard
output.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
From: Daniel Barkalow @ 2009-09-10 16:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtyzexnhm.fsf@alter.siamese.dyndns.org>
On Mon, 7 Sep 2009, Junio C Hamano wrote:
> * db/vcs-helper (2009-09-03) 16 commits
> - Allow helpers to report in "list" command that the ref is unchanged
> - Add support for "import" helper command
> - Add a config option for remotes to specify a foreign vcs
> - Allow programs to not depend on remotes having urls
> - Allow fetch to modify refs
> - Use a function to determine whether a remote is valid
> - Use a clearer style to issue commands to remote helpers
> - Make the "traditionally-supported" URLs a special case
> (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.)
>
> I'd really want to have this in 1.6.5 so that we can eject -lcurl from the
> main "git" binary. The patches in 'pu' got some review comments, and I
> thought Daniel's responses were sensible. Comments?
I'm pretty sure that there were no objections to 'Make the
"traditonally-supported"...' patch, and directly after that is a
reasonable stopping point (everything that used to work works the same,
nothing new and user-visible is introduced, the implementation is
reasonably straightforward and tidy, and the git binary doesn't
link against -lcurl). I'd suggest putting everything up to that point into
master and debating the rest of the series on its own merits (and likely
deferring it to post-1.6.5, since it doesn't have an in-tree user to
exercise it yet).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH v2] Introduce <branch>@{upstream} as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-09-10 16:18 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Björn Steinbrink, Michael J Gruber,
Pete Wyckoff, git
In-Reply-To: <20090910155547.GA12409@coredump.intra.peff.net>
Hi,
On Thu, 10 Sep 2009, Jeff King wrote:
> I wrote:
>
> > + ret = tracked_suffix(*string, *len);
> > + if (ret) {
> > + char *ref = xstrndup(*string, *len - ret);
> > + struct branch *tracking = branch_get(*ref ? ref : NULL);
> > +
> > + free(ref);
> > + if (!tracking)
> > + die ("No tracking branch found for '%s'", ref);
> > + if (tracking->merge && tracking->merge[0]->dst) {
> > + *string = xstrdup(tracking->merge[0]->dst);
> > + *len = strlen(*string);
> > + return (char *)*string;
> > + }
> > + }
> > +
>
> I don't think it is a good idea to die for !tracking, but not for
> !tracking->merge. That leads to inconsistent user-visible results:
>
> $ git checkout HEAD^0
> $ git rev-parse HEAD@{u}
> fatal: No tracking branch found for 'HEAD'
> $ git rev-parse bogus@{u}
> bogus@{u}
> fatal: ambiguous argument 'bogus@{u}': unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions
>
> Shouldn't both cases say the same thing?
>
> Also, your die message has two problems:
>
> 1. It looks at ref immediately after it is free'd, spewing junk.
>
> 2. Ref can be the empty string, which gives you the ugly:
>
> fatal: No tracking branch found for ''
>
> Should we munge that into HEAD (or "the current branch") for the
> user?
All true, but I cannot take care of it today.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] Introduce <branch>@{upstream} as shortcut to the tracked branch
From: Jeff King @ 2009-09-10 15:55 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Björn Steinbrink, Michael J Gruber,
Pete Wyckoff, git
In-Reply-To: <alpine.DEB.1.00.0909101724520.8306@pacific.mpi-cbg.de>
On Thu, Sep 10, 2009 at 05:25:57PM +0200, Johannes Schindelin wrote:
> Changes since v1:
> - changed to @{upstream} (and @{u})
Hmm. After applying v2, I accidentally tried "git rev-parse @{t}" and
was surprised to find that it worked! The problem, of course, is that we
saw that it was not one of our keywords and therefore dumped it into
approxidate, which happily converted it into the current time, and
provided me with HEAD@{now}.
Which is sad, because it means "HEAD@{usptream}" will silently produce
incorrect results.
I don't see a way around it, though, short of tightening approxidate's
parsing. Maybe it could keep a flag for "I noticed _anything_ of value
in this string", and we could barf if it isn't set. That would still
allow arbitrary stuff like:
the 6th of july
and keep Linus' favorite
I ate 6 hot dogs in July.
but disallow the most obviously wrong dates like:
t
usptream
total bogosity
> + ret = tracked_suffix(*string, *len);
> + if (ret) {
> + char *ref = xstrndup(*string, *len - ret);
> + struct branch *tracking = branch_get(*ref ? ref : NULL);
> +
> + free(ref);
> + if (!tracking)
> + die ("No tracking branch found for '%s'", ref);
> + if (tracking->merge && tracking->merge[0]->dst) {
> + *string = xstrdup(tracking->merge[0]->dst);
> + *len = strlen(*string);
> + return (char *)*string;
> + }
> + }
> +
I don't think it is a good idea to die for !tracking, but not for
!tracking->merge. That leads to inconsistent user-visible results:
$ git checkout HEAD^0
$ git rev-parse HEAD@{u}
fatal: No tracking branch found for 'HEAD'
$ git rev-parse bogus@{u}
bogus@{u}
fatal: ambiguous argument 'bogus@{u}': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
Shouldn't both cases say the same thing?
Also, your die message has two problems:
1. It looks at ref immediately after it is free'd, spewing junk.
2. Ref can be the empty string, which gives you the ugly:
fatal: No tracking branch found for ''
Should we munge that into HEAD (or "the current branch") for the
user?
-Peff
^ permalink raw reply
* git svn propset support
From: David Fraser @ 2009-09-10 15:41 UTC (permalink / raw)
To: git; +Cc: David Moore
In-Reply-To: <1699967795.351252597251356.JavaMail.root@klofta.sjsoft.com>
[-- Attachment #1: Type: text/plain, Size: 868 bytes --]
Hi
I've been trying to hack at getting manually property setting support for git-svn.
I've got a start of a patch that basically stores an attribute 'svn-properties' for each file that needs them changed, and then sets the properties when committing.
Issues remaining:
* The way it edits the .gitattributes file is suboptimal - it just appends to the end the latest version
* It could use the existing code to get the current svn properties to see if properties need to be changed; but this doesn't work on add
* It would be better to cache all the svn properties locally - this could be done automatically in .gitattributes but I'm not sure everyone would want this, etc
* No support for deleting properties
Usage is:
git svn propset PROPNAME PROPVALUE PATH
Patch attached (against 1.6.0.2) - any comments welcome
David
--
David Fraser
St James Software
[-- Attachment #2: git-svn-propset-0.patch --]
[-- Type: text/x-patch, Size: 5427 bytes --]
--- git-1.6.0.2/git-svn.perl 2008-12-15 15:52:14.000000000 +0200
+++ git-svn.perl 2009-09-10 17:35:04.000000000 +0200
@@ -66,7 +66,7 @@
$_version, $_fetch_all, $_no_rebase,
$_merge, $_strategy, $_dry_run, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
- $_git_format, $_commit_url);
+ $_git_format, $_commit_url, $_set_svn_props);
$Git::SVN::_follow_parent = 1;
my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
'config-dir=s' => \$Git::SVN::Ra::config_dir,
@@ -128,6 +128,7 @@
'dry-run|n' => \$_dry_run,
'fetch-all|all' => \$_fetch_all,
'commit-url=s' => \$_commit_url,
+ 'set-svn-props=s' => \$_set_svn_props,
'revision|r=i' => \$_revision,
'no-rebase' => \$_no_rebase,
%cmt_opts, %fc_opts } ],
@@ -141,6 +142,9 @@
'propget' => [ \&cmd_propget,
'Print the value of a property on a file or directory',
{ 'revision|r=i' => \$_revision } ],
+ 'propset' => [ \&cmd_propset,
+ 'Set the value of a property on a file or directory - will be set on commit',
+ {} ],
'proplist' => [ \&cmd_proplist,
'List all properties of a file or directory',
{ 'revision|r=i' => \$_revision } ],
@@ -700,6 +704,64 @@
print $props->{$prop} . "\n";
}
+sub check_attr
+{
+ my ($attr,$path) = @_;
+ if ( open my $fh, '-|', "git", "check-attr", $attr, "--", $path )
+ {
+ my $val = <$fh>;
+ close $fh;
+ $val =~ s/^[^:]*:\s*[^:]*:\s*(.*)\s*$/$1/;
+ return $val;
+ }
+ else
+ {
+ return undef;
+ }
+}
+
+# cmd_propset (PROPNAME, PROPVAL, PATH)
+# ------------------------
+# Adjust the SVN property PROPNAME to PROPVAL for PATH.
+sub cmd_propset {
+ my ($propname, $propval, $path) = @_;
+ $path = '.' if not defined $path;
+ $path = $cmd_dir_prefix . $path;
+ usage(1) if not defined $propname;
+ usage(1) if not defined $propval;
+ my $file = basename($path);
+ my $dn = dirname($path);
+ my $current_properties = check_attr( "svn-properties", $path );
+ my $new_properties = "";
+ if ($current_properties eq "unset" || $current_properties eq "" || $current_properties eq "set") {
+ $new_properties = "$propname=$propval";
+ } else {
+ # TODO: handle combining properties better
+ my @props = split(/;/, $current_properties);
+ my $replaced_prop = 0;
+ foreach my $prop (@props) {
+ # Parse 'name=value' syntax and set the property.
+ if ($prop =~ /([^=]+)=(.*)/) {
+ my ($n,$v) = ($1,$2);
+ if ($n eq $propname)
+ {
+ $v = $propval;
+ $replaced_prop = 1;
+ }
+ if ($new_properties eq "") { $new_properties="$n=$v"; }
+ else { $new_properties="$new_properties;$n=$v"; }
+ }
+ }
+ if ($replaced_prop eq 0) {
+ $new_properties = "$new_properties;$propname=$propval";
+ }
+ }
+ my $attrfile = "$dn/.gitattributes";
+ open my $attrfh, '>>', $attrfile or die "Can't open $attrfile: $!\n";
+ # TODO: don't simply append here if $file already has svn-properties
+ print $attrfh "$file svn-properties=$new_properties\n";
+}
+
# cmd_proplist (PATH)
# -------------------
# Print the list of SVN properties for PATH.
@@ -3598,6 +3660,34 @@
}
}
+sub apply_manualprops {
+ my ($self, $file, $fbat) = @_;
+ my $path = $cmd_dir_prefix . $file;
+ my $pending_properties = ::check_attr( "svn-properties", $path );
+ if ($pending_properties eq "") { return; }
+ # Parse the list of properties to set.
+ my @props = split(/;/, $pending_properties);
+ # TODO: get existing properties to compare to - this fails for add so currently not done
+ # my $existing_props = ::get_svnprops($file);
+ my $existing_props = {};
+ # TODO: caching svn properties or storing them in .gitattributes would make that faster
+ foreach my $prop (@props) {
+ # Parse 'name=value' syntax and set the property.
+ if ($prop =~ /([^=]+)=(.*)/) {
+ my ($n,$v) = ($1,$2);
+ for ($n, $v) {
+ s/^\s+//; s/\s+$//;
+ }
+ # FIXME: clearly I don't know perl and couldn't work out how to evaluate this better
+ if (defined $existing_props->{$n} && $existing_props->{$n} eq $v) {
+ my $needed = 0;
+ } else {
+ $self->change_file_prop($fbat, $n, $v);
+ }
+ }
+ }
+}
+
sub A {
my ($self, $m) = @_;
my ($dir, $file) = split_path($m->{file_b});
@@ -3606,6 +3696,7 @@
undef, -1);
print "\tA\t$m->{file_b}\n" unless $::_q;
$self->apply_autoprops($file, $fbat);
+ $self->apply_manualprops($file, $fbat);
$self->chg_file($fbat, $m);
$self->close_file($fbat,undef,$self->{pool});
}
@@ -3617,6 +3708,7 @@
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
$self->url_path($m->{file_a}), $self->{r});
print "\tC\t$m->{file_a} => $m->{file_b}\n" unless $::_q;
+ $self->apply_manualprops($file, $fbat);
$self->chg_file($fbat, $m);
$self->close_file($fbat,undef,$self->{pool});
}
@@ -3636,6 +3728,7 @@
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
$self->url_path($m->{file_a}), $self->{r});
print "\tR\t$m->{file_a} => $m->{file_b}\n" unless $::_q;
+ $self->apply_manualprops($file, $fbat);
$self->chg_file($fbat, $m);
$self->close_file($fbat,undef,$self->{pool});
@@ -3651,6 +3744,7 @@
my $fbat = $self->open_file($self->repo_path($m->{file_b}),
$pbat,$self->{r},$self->{pool});
print "\t$m->{chg}\t$m->{file_b}\n" unless $::_q;
+ $self->apply_manualprops($file, $fbat);
$self->chg_file($fbat, $m);
$self->close_file($fbat,undef,$self->{pool});
}
^ permalink raw reply
* [PATCH v2] Introduce <branch>@{upstream} as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-09-10 15:25 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Björn Steinbrink, Michael J Gruber,
Pete Wyckoff, git
In-Reply-To: <alpine.DEB.1.00.0909101723260.8306@pacific.mpi-cbg.de>
Often, it is quite interesting to inspect the branch tracked by a given
branch. This patch introduces a nice notation to get at the tracked
branch: '<branch>@{upstream}' can be used to access that tracked branch.
A special shortcut '@{upstream}' refers to the branch tracked by the
current branch.
Suggested by Pasky.
The syntax was suggested by Junio.
A test for a now-fixed crash was provided by Mikael Magnusson.
The crash has been pointed out by Peff again (because this here developer
managed to forget about the fix).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Changes since v1:
- changed to @{upstream} (and @{u})
- included the fix I forgot about
Documentation/git-rev-parse.txt | 4 ++
sha1_name.c | 39 ++++++++++++++++++++--
t/t1506-rev-parse-tracked.sh | 69 +++++++++++++++++++++++++++++++++++++++
3 files changed, 109 insertions(+), 3 deletions(-)
create mode 100755 t/t1506-rev-parse-tracked.sh
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 82045a2..09a2145 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -231,6 +231,10 @@ when you run 'git-merge'.
* The special construct '@\{-<n>\}' means the <n>th branch checked out
before the current one.
+* The suffix '@{upstream}' to a ref (short form 'blabla@{u}') refers to
+ the branch tracked by that ref. If no ref was specified, it means the
+ branch tracked by the current branch.
+
* A suffix '{caret}' to a revision parameter means the first parent of
that commit object. '{caret}<n>' means the <n>th parent (i.e.
'rev{caret}'
diff --git a/sha1_name.c b/sha1_name.c
index 44bb62d..ae4280e 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -5,6 +5,7 @@
#include "blob.h"
#include "tree-walk.h"
#include "refs.h"
+#include "remote.h"
static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
{
@@ -238,9 +239,24 @@ static int ambiguous_path(const char *path, int len)
return slash;
}
+static inline int tracked_suffix(const char *string, int len)
+{
+ const char *suffix[] = { "@{upstream}", "@{u}" };
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(suffix); i++) {
+ int suffix_len = strlen(suffix[i]);
+ if (len >= suffix_len && !memcmp(string + len - suffix_len,
+ suffix[i], suffix_len))
+ return suffix_len;
+ }
+ return 0;
+}
+
/*
* *string and *len will only be substituted, and *string returned (for
- * later free()ing) if the string passed in is of the form @{-<n>}.
+ * later free()ing) if the string passed in is of the form @{-<n>} or
+ * of the form <branch>@{upstream}.
*/
static char *substitute_branch_name(const char **string, int *len)
{
@@ -254,6 +270,21 @@ static char *substitute_branch_name(const char **string, int *len)
return (char *)*string;
}
+ ret = tracked_suffix(*string, *len);
+ if (ret) {
+ char *ref = xstrndup(*string, *len - ret);
+ struct branch *tracking = branch_get(*ref ? ref : NULL);
+
+ free(ref);
+ if (!tracking)
+ die ("No tracking branch found for '%s'", ref);
+ if (tracking->merge && tracking->merge[0]->dst) {
+ *string = xstrdup(tracking->merge[0]->dst);
+ *len = strlen(*string);
+ return (char *)*string;
+ }
+ }
+
return NULL;
}
@@ -340,8 +371,10 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
if (len && str[len-1] == '}') {
for (at = len-2; at >= 0; at--) {
if (str[at] == '@' && str[at+1] == '{') {
- reflog_len = (len-1) - (at+2);
- len = at;
+ if (!tracked_suffix(str + at, len - at)) {
+ reflog_len = (len-1) - (at+2);
+ len = at;
+ }
break;
}
}
diff --git a/t/t1506-rev-parse-tracked.sh b/t/t1506-rev-parse-tracked.sh
new file mode 100755
index 0000000..72d0579
--- /dev/null
+++ b/t/t1506-rev-parse-tracked.sh
@@ -0,0 +1,69 @@
+#!/bin/sh
+
+test_description='test <branch>@{upstream} syntax'
+
+. ./test-lib.sh
+
+
+test_expect_success 'setup' '
+
+ test_commit 1 &&
+ git checkout -b side &&
+ test_commit 2 &&
+ git checkout master &&
+ git clone . clone &&
+ test_commit 3 &&
+ (cd clone &&
+ test_commit 4 &&
+ git branch --track my-side origin/side)
+
+'
+
+full_name () {
+ (cd clone &&
+ git rev-parse --symbolic-full-name "$@")
+}
+
+commit_subject () {
+ (cd clone &&
+ git show -s --pretty=format:%s "$@")
+}
+
+test_expect_success '@{upstream} resolves to correct full name' '
+ test refs/remotes/origin/master = "$(full_name @{upstream})"
+'
+
+test_expect_success '@{u} resolves to correct full name' '
+ test refs/remotes/origin/master = "$(full_name @{u})"
+'
+
+test_expect_success 'my-side@{upstream} resolves to correct full name' '
+ test refs/remotes/origin/side = "$(full_name my-side@{u})"
+'
+
+test_expect_success 'my-side@{u} resolves to correct commit' '
+ git checkout side &&
+ test_commit 5 &&
+ (cd clone && git fetch) &&
+ test 2 = "$(commit_subject my-side)" &&
+ test 5 = "$(commit_subject my-side@{u})"
+'
+
+test_expect_success 'not-tracking@{u} fails' '
+ test_must_fail full_name non-tracking@{u} &&
+ (cd clone && git checkout --no-track -b non-tracking) &&
+ test_must_fail full_name non-tracking@{u}
+'
+
+test_expect_success '<branch>@{u}@{1} resolves correctly' '
+ test_commit 6 &&
+ (cd clone && git fetch) &&
+ test 5 = $(commit_subject my-side@{u}@{1})
+'
+
+test_expect_success '% without specifying branch crashes on a detached HEAD' '
+ git checkout HEAD^0 &&
+ test_must_fail git rev-parse @{u}
+'
+
+test_done
--
1.6.4.313.g3d9e3
^ permalink raw reply related
* Re: [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-09-10 15:24 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Björn Steinbrink, Michael J Gruber,
Pete Wyckoff, git
In-Reply-To: <20090910142628.GA7275@coredump.intra.peff.net>
Hi,
On Thu, 10 Sep 2009, Jeff King wrote:
> On Thu, Sep 10, 2009 at 10:16:18AM -0400, Jeff King wrote:
>
> diff --git a/sha1_name.c b/sha1_name.c
> index a886846..ef4ec11 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -276,7 +276,7 @@ static char *substitute_branch_name(const char **string, int *len)
> struct branch *tracking = branch_get(*ref ? ref : NULL);
>
> free(ref);
> - if (tracking->merge && tracking->merge[0]->dst) {
> + if (tracking && tracking->merge && tracking->merge[0]->dst) {
Almost.
My version dies if tracking is NULL.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-09-10 15:22 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Björn Steinbrink, Michael J Gruber,
Pete Wyckoff, git
In-Reply-To: <20090910141618.GB4942@coredump.intra.peff.net>
Hi,
On Thu, 10 Sep 2009, Jeff King wrote:
> Also, I seem to be able to stimulate a segfault on a detached HEAD, but
> I haven't investigated it yet.
Aaargh!
Mikachu pointed that out recently, provided a test, I fixed it, and in the
meantime I managed to forget about it!
/me needs to do less things per day.
Ciao,
Dscho
^ permalink raw reply
* bash_completion outside repo
From: james bardin @ 2009-09-10 15:13 UTC (permalink / raw)
To: git
Hi,
I'm making a git rpm for our site, and I'm getting an error with
bash_completion on RHEL/CentOS 5.
When outside a repo, any completion causes git to spit out
fatal: error processing config file(s)
This is 1.6.4.2 using the contrib bash completion file
Thanks
-jim
^ 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