* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Jakub Narebski @ 2009-09-05 17:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Clemens Buchacher, Jeff King, SZEDER Gabor, git
In-Reply-To: <7veiql1etz.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Clemens Buchacher <drizzd@aon.at> writes:
>
> > "git add -u ." is friendly enough. Just like "git commit ." versus "git
> > commit -a", which is exactly the same concept and should therefore have the
> > same behavior.
> >
> > You are assuming that people are in a subdirectory because they want to
> > limit the scope. But I am usually in a subdirectory for totally
> > versioning-unrelated reasons.
>
> Limit the scope of what you see in "ls" (no argument) output, shorten the
> paths you must type to non-git commands. They are the kind of "limit the
> scope" I meant, and they are totally versioning-unrelated. In other
> words, cwd-centric default helps the users (especially the new ones) by
> making git behave consistently with other commands.
Well, there is still complication that some commands are considered
whole-tree in absence of pathspec, like "git commit".
>
> So if anything, I personally think it would be much less surprising if all
> git commands worked relative to the cwd (not whole tree root) when run
> without path argument, at least from the newbie's point of view [*1*].
I think it would be very suprising if "git commit" in subdirectory was
limited to changes affecting given subdirectory...
>
> But notice that the above is qualified with "personally". An alternative
> would be to declare that in 1.8.0, all commands run without path argument
> will work on the whole tree and you have to give an explicit '.' when you
> want to limit their effect to the cwd.
>
> This may be slightly less intuitive to newbies than the "relative to cwd",
> but nevertheless that is the course I would suggest us taking, because of
> the following observations:
>
> (1) if the commands work on the whole tree when run without paths, it is
> easy to limit to the cwd with "git frotz ." when you want to.
>
> (2) if the commands work on the cwd when run without paths, you have to
> always be aware how deep you are, and say "git frotz ../../.." when
> you want to extend their effects to the whole tree.
>
> The latter is much more irritating.
Well, we can always invent some magic notation meaning either "up to
top directory", e.g. make
$ git frotz ...
more or less equivalent to
$ git frotz "$(git rev-parse --show-cdup)"
(The other solution of having "git frotz /" to refer to top directory
is slightly worse, because there are git commands that work without
git repository, and "/" is legitimate parameter, like e.g. for
"git diff --no-index").
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Strange merge failure (would be overwritten by merge / cannot merge)
From: Junio C Hamano @ 2009-09-05 17:46 UTC (permalink / raw)
To: David Aguilar; +Cc: Christoph Haas, git
In-Reply-To: <20090904234552.GA43797@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> Does anyone else on the list have any insights?
Yes; the problem does not have anything to do with renames but
unfortunately is much deeper. See $gmane/127783.
Here is a reproduction recipe for the lowest-level ingredient of the
breakage in "git read-tree -m"that needs to be fixed, before we can start
looking at what "git merge-recursive" does incorrectly (if any) and what
"git merge" does incorrectly (again, if any).
t/t1004-read-tree-m-u-wf.sh | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/t/t1004-read-tree-m-u-wf.sh b/t/t1004-read-tree-m-u-wf.sh
index f19b4a2..055bb00 100755
--- a/t/t1004-read-tree-m-u-wf.sh
+++ b/t/t1004-read-tree-m-u-wf.sh
@@ -238,4 +238,27 @@ test_expect_success 'D/F recursive' '
'
+################################################################
+
+test_expect_failure 'D/F D-F' '
+ git reset --hard &&
+ git rm -f -r . &&
+
+ mkdir t && echo 1 >t/f && git add t &&
+ git tag ONE $(git write-tree) &&
+
+ echo 3 >t-f && echo 3 >t/f && git add t-f t &&
+ git tag THREE $(git write-tree) &&
+
+ git rm -f -r t &&
+ echo 2 >t && echo 2 >t-f && git add t t-f &&
+ git tag TWO $(git write-tree) &&
+ git commit -a -m TWO &&
+
+ test_must_fail git read-tree -m -u ONE TWO THREE &&
+ git ls-files -u >actual &&
+ grep t/f actual &&
+ grep t-f actual
+'
+
test_done
^ permalink raw reply related
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Junio C Hamano @ 2009-09-05 17:28 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Jeff King, SZEDER Gábor, git
In-Reply-To: <20090905084641.GA24865@darc.dnsalias.org>
Clemens Buchacher <drizzd@aon.at> writes:
> "git add -u ." is friendly enough. Just like "git commit ." versus "git
> commit -a", which is exactly the same concept and should therefore have the
> same behavior.
>
> You are assuming that people are in a subdirectory because they want to
> limit the scope. But I am usually in a subdirectory for totally
> versioning-unrelated reasons.
Limit the scope of what you see in "ls" (no argument) output, shorten the
paths you must type to non-git commands. They are the kind of "limit the
scope" I meant, and they are totally versioning-unrelated. In other
words, cwd-centric default helps the users (especially the new ones) by
making git behave consistently with other commands.
So if anything, I personally think it would be much less surprising if all
git commands worked relative to the cwd (not whole tree root) when run
without path argument, at least from the newbie's point of view [*1*].
But notice that the above is qualified with "personally". An alternative
would be to declare that in 1.8.0, all commands run without path argument
will work on the whole tree and you have to give an explicit '.' when you
want to limit their effect to the cwd.
This may be slightly less intuitive to newbies than the "relative to cwd",
but nevertheless that is the course I would suggest us taking, because of
the following observations:
(1) if the commands work on the whole tree when run without paths, it is
easy to limit to the cwd with "git frotz ." when you want to.
(2) if the commands work on the cwd when run without paths, you have to
always be aware how deep you are, and say "git frotz ../../.." when
you want to extend their effects to the whole tree.
The latter is much more irritating.
Please also see:
Message-ID: <7vy6ot4x61.fsf@alter.siamese.dyndns.org> ($gmane/127795)
think about the three questions there, and help us move the discussion
forward.
The first part of the message has some comments related to your patch, by
the way.
[Footnote]
*1* Except for the ones that cannot make any sense to limit their
operation to a subdirectory you happen to be in (e.g. it would be insane
if "git am" run to accept somebody's patch ignored paths outside your
cwd).
^ permalink raw reply
* Re: Use case I don't know how to address
From: Johannes Sixt @ 2009-09-05 17:23 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <4AA20CEC.8060408@chandlerfamily.org.uk>
On Samstag, 5. September 2009, Alan Chandler wrote:
> The problem comes when I want to now merge back further work that I did
> on the master branch (the 5-6 transition) to the fan club site
>
>
> 2' - 2a - 3' - 4' ----------------- 6' SITE
> / / / /
> 1 - 2 ------ 3 - 4 ------------6'''- 6a TEST
> \ /
> 5 ------ 6 MASTER
> \ \
> 5''- 5a- 6'' DEMO
>
>
> What will happen is the changes made in 4->5 will get applied to the
> (now) Test branch as part of the 6->6'' merge, and I will be left having
> to add a new commit, 6a, to undo them all again. Given this is likely
> to be quite a substantial change I want to try and avoid it if possible.
>
> Is there any way I could use git to remember the 4->5 transition,
> reverse it and apply it back to the Test branch before hand.
Basically, your mistake was to rename master to test and continue development
on the demo branch. So what you should do instead is this:
2' - 2a - 3' - 4' ------ 6' SITE
/ / / /
1 - 2 ------ 3 - 4 ------- 6 MASTER
\ \
5 - 5a - 6'' DEMO
IOW, you keep developing on master, and merge that into the two deployment
branches.
In practice, it may be easier to develop commit 6 on DEMO (because you can
debug it more easily, or for similar reasons), but then you should rebase it
back to MASTER, reset DEMO back to 5a, and finally merge MASTER into DEMO.
-- Hannes
^ permalink raw reply
* Re: [JGIT] Request for help
From: Mark Struberg @ 2009-09-05 16:40 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Douglas Campos, Jonas Fonseca, git, Gabe McArthur
In-Reply-To: <200909051825.49619.robin.rosenberg.lists@dewire.com>
Haven't counted it, but I will check it.
Please note that for running the tests previously in 'exttest' you have to activate the tck profile:
$> mvn test -Ptck
And yes, we currently only run *Test.java. Any other patterns/files to include?
txs and LieGrue,
strub
--- On Sat, 9/5/09, Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> From: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
> Subject: Re: [JGIT] Request for help
> To: "Mark Struberg" <struberg@yahoo.de>
> Cc: "Douglas Campos" <douglas@theros.info>, "Jonas Fonseca" <jonas.fonseca@gmail.com>, git@vger.kernel.org, "Gabe McArthur" <gabriel.mcarthur@gmail.com>
> Date: Saturday, September 5, 2009, 6:25 PM
> fredag 04 september 2009 19:28:39
> skrev Mark Struberg <struberg@yahoo.de>:
> > Hi!
> >
> > Work has been done at
> >
> > http://github.com/sonatype/JGit/tree/mavenize
> >
> > Please feel free to pull/fork and share your changes!
> I'd be happy to pull it in.
> >
>
> Why does this new mvn test only execute 1024 tests here,
> while the old maven setup
> does 1108 ones? It seems the classes that don't match
> *Test.java are omitted.
>
> In both cases I invoke with "mvn clean test"
>
> -- robin
>
^ permalink raw reply
* Re: [JGIT] Request for help
From: Robin Rosenberg @ 2009-09-05 16:25 UTC (permalink / raw)
To: Mark Struberg; +Cc: Douglas Campos, Jonas Fonseca, git, Gabe McArthur
In-Reply-To: <658028.86274.qm@web27804.mail.ukl.yahoo.com>
fredag 04 september 2009 19:28:39 skrev Mark Struberg <struberg@yahoo.de>:
> Hi!
>
> Work has been done at
>
> http://github.com/sonatype/JGit/tree/mavenize
>
> Please feel free to pull/fork and share your changes! I'd be happy to pull it in.
>
Why does this new mvn test only execute 1024 tests here, while the old maven setup
does 1108 ones? It seems the classes that don't match *Test.java are omitted.
In both cases I invoke with "mvn clean test"
-- robin
^ permalink raw reply
* Re: `Git Status`-like output for two local branches
From: demerphq @ 2009-09-05 14:58 UTC (permalink / raw)
To: Jeff King; +Cc: Sverre Rabbelier, Tim Visher, Git Mailing List
In-Reply-To: <20090905081726.GA7109@coredump.intra.peff.net>
2009/9/5 Jeff King <peff@peff.net>:
> On Wed, Sep 02, 2009 at 10:18:54AM +0200, Sverre Rabbelier wrote:
>
>> On Wed, Sep 2, 2009 at 09:57, Jeff King<peff@peff.net> wrote:
>> > 2. Count the commits on each side that are not in the other.
>>
>> [...]
>>
>> > You can also do that by parsing the output of:
>> > git rev-list --left-right $a...$b --
>>
>> Perhaps it is useful to introduce a --left-right-count or such?
>
> I'm not opposed to that if it is something a lot of people found useful,
> but I am not sure we have established that as the case (I am curious to
> hear from Tim what his actual use case is).
It would be useful in for instance prompt status line. At $work we
have a number of people using a prompt that includes the result of
parsing git-status, but something --left-right-count would be much
nicer, and if i understand it, more efficient (although maybe im
wrong). In the prompt they use a number of different unicode arrows to
show what has happened, with a Y type thing for diverged.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: tracking branch for a rebase
From: Jeff King @ 2009-09-05 14:28 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Michael J Gruber, Pete Wyckoff, git
In-Reply-To: <20090905140127.GA29037@atjola.homenet>
On Sat, Sep 05, 2009 at 04:01:27PM +0200, Björn Steinbrink wrote:
> > And by automating the shorthand we reduce the chance of errors. For
> > example, I usually base my topic branches from origin/master. But the
> > other day I happened to be building a new branch, jk/date, off of
> > lt/approxidate, salvaged from origin/pu. I did "git rebase -i
> > origin/master" and accidentally rewrote the early part of
> > lt/approxidate.
>
> Hm, I'd prefer a shorthand for "upstream for this branch", instead of
> magic defaults.
The more I think about, the more I think that is the right solution.
Because magic defaults for "rebase -i" don't help when you want to do
"gitk $UPSTREAM..".
The previous discussion on the topic seems to be here:
http://article.gmane.org/gmane.comp.version-control.git/113666
And apparently you and I both participated in the discussion, which I
totally forgot about.
Looks like the discussion ended with people liking the idea but not
knowing what the specifier should look like. Maybe tightening the ref
syntax a bit to allow more extensible "special" refs is a good v1.7.0
topic? I dunno.
> > That wouldn't help me, because you can't "pull -i". :)
>
> I probably shouldn't tell anyone, as it's a crude hack, but "git pull
> --rebase -s -i" does the trick... *hides*
OK, that's just sick. :)
-Peff
^ permalink raw reply
* Re: tracking branch for a rebase
From: Björn Steinbrink @ 2009-09-05 14:01 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Pete Wyckoff, git
In-Reply-To: <20090905061250.GA29863@coredump.intra.peff.net>
On 2009.09.05 02:12:50 -0400, Jeff King wrote:
> On Fri, Sep 04, 2009 at 08:59:49PM +0200, Björn Steinbrink wrote:
>
> > "git pull --rebase" is not the same as:
> > "git fetch origin && git rebase origin/foo", but:
> >
> > git fetch origin && git rebase --onto origin/foo $reflog_merge_base
> >
> > Where $reflog_merge_base is the first merge base is found between the
> > current branch head, and the reflog entries for origin/foo.
>
> Thanks, I didn't know about the trick (not being, as I mentioned, a pull
> --rebase user). I can see arguments for or against a rebase-default
> using that feature. On one hand, it simplifies the explanation for
> people going between "pull --rebase" and "fetch && rebase". And I think
> it should generally Do What You Mean in the case that upstream hasn't
> rebased. Are there cases you know of where it will do the wrong thing?
>
> I don't know if people would be confused that "git rebase" does not
> exactly default to "git rebase $upstream", which is at least easy to
> explain.
For me, the confusion would arise from the fact that "git rebase"
(without args) would seem like a "pull --rebase" without the fetch, but
isn't. And to reducing the difference to just the fetch would require a
quite change in bahaviour.
Currently, when branch.<name>.merge is set:
"git rebase <upstream>" ==> Can't really be done with "pull --rebase"
"git pull --rebase [...]" ==> Can't be done with "rebase" alone.
Currently, "pull" is a convenience thing, and thus may do more magic,
while "rebase" is dumb, and needs arguments. Starting to add _different_
magic to rebase seems wrong to me.
> And by automating the shorthand we reduce the chance of errors. For
> example, I usually base my topic branches from origin/master. But the
> other day I happened to be building a new branch, jk/date, off of
> lt/approxidate, salvaged from origin/pu. I did "git rebase -i
> origin/master" and accidentally rewrote the early part of
> lt/approxidate.
Hm, I'd prefer a shorthand for "upstream for this branch", instead of
magic defaults.
> > Now, basically "git svn rebase" is pretty much git-svn's "pull". Maybe
> > its idea could be taken, so we get "git pull --local" to just skip the
> > fetch part, but keep "git rebase" and "git merge" 'dumb', requiring
> > explicit arguments.
>
> That wouldn't help me, because you can't "pull -i". :)
I probably shouldn't tell anyone, as it's a crude hack, but "git pull
--rebase -s -i" does the trick... *hides*
Björn
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2009, #01; Sat, 05)
From: Nicolas Pitre @ 2009-09-05 13:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vocpp3i2l.fsf@alter.siamese.dyndns.org>
On Sat, 5 Sep 2009, Junio C Hamano wrote:
> What's cooking in git.git (Sep 2009, #01; Sat, 05)
> --------------------------------------------------
>
> Here are the topics that have been cooking. Commits prefixed with '-' are
> only in 'pu' while commits prefixed with '+' are in 'next'. The ones
> marked with '.' do not appear in any of the integration branches, but I am
> still holding onto them.
Just to make sure you didn't miss the last 2 patches I posted:
Date: Thu, 03 Sep 2009 19:08:33 -0400 (EDT)
Subject: [PATCH] make shallow repository deepening more network efficient
Date: Thu, 03 Sep 2009 21:54:03 -0400 (EDT)
Subject: [PATCH] pack-objects: free preferred base memory after usage
Nicolas
^ permalink raw reply
* [PATCH 2/2 v2] add 'scope' config option
From: Clemens Buchacher @ 2009-09-05 13:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, SZEDER Gábor, git
In-Reply-To: <20090905123304.GB3099@darc.dnsalias.org>
On Sat, Sep 05, 2009 at 02:33:04PM +0200, Clemens Buchacher wrote:
> - if ((addremove || take_worktree_changes) && !argc) {
> + if (!scope_global && (addremove || take_worktree_changes) && !argc) {
> static const char *here[2] = { ".", NULL };
> argc = 1;
> argv = here;
Ok, scrape that. Seems validate_pathspec does that implicitly already. So
this code was redundant. The attached patch should now work (I tested it
this time...).
It also seems that "git add -A" doesn't work without a pathspec any more?
Was that intentional?
Clemens
--o<--
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
Documentation/config.txt | 6 ++++++
builtin-add.c | 12 +++++-------
builtin-grep.c | 2 +-
cache.h | 1 +
config.c | 8 ++++++++
environment.c | 1 +
6 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5256c7f..f587cf1 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -439,6 +439,12 @@ On some file system/operating system combinations, this is unreliable.
Set this config setting to 'rename' there; However, This will remove the
check that makes sure that existing object files will not get overwritten.
+core.scope::
+ By default, the commands 'git add -u', 'git add -A' and 'git grep'
+ are limited to files below the current working directory
+ (scope='workdir'). Set this variable to scope='global' to make these
+ commands act on the whole tree instead.
+
add.ignore-errors::
Tells 'git-add' to continue adding files when some files cannot be
added due to indexing errors. Equivalent to the '--ignore-errors'
diff --git a/builtin-add.c b/builtin-add.c
index 006fd08..737b155 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -285,14 +285,9 @@ int cmd_add(int argc, const char **argv, const char *prefix)
if (addremove && take_worktree_changes)
die("-A and -u are mutually incompatible");
- if ((addremove || take_worktree_changes) && !argc) {
- static const char *here[2] = { ".", NULL };
- argc = 1;
- argv = here;
- }
add_new_files = !take_worktree_changes && !refresh_only;
- require_pathspec = !take_worktree_changes;
+ require_pathspec = !addremove && !take_worktree_changes;
newfd = hold_locked_index(&lock_file, 1);
@@ -308,7 +303,10 @@ int cmd_add(int argc, const char **argv, const char *prefix)
fprintf(stderr, "Maybe you wanted to say 'git add .'?\n");
return 0;
}
- pathspec = validate_pathspec(argc, argv, prefix);
+ if (scope_global && !argc)
+ pathspec = NULL;
+ else
+ pathspec = validate_pathspec(argc, argv, prefix);
if (read_cache() < 0)
die("index file corrupt");
diff --git a/builtin-grep.c b/builtin-grep.c
index f6af3d4..447b195 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -861,7 +861,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
if (i < argc)
paths = get_pathspec(prefix, argv + i);
- else if (prefix) {
+ else if (!scope_global && prefix) {
paths = xcalloc(2, sizeof(const char *));
paths[0] = prefix;
paths[1] = NULL;
diff --git a/cache.h b/cache.h
index 5fad24c..85c5fee 100644
--- a/cache.h
+++ b/cache.h
@@ -523,6 +523,7 @@ extern int auto_crlf;
extern int read_replace_refs;
extern int fsync_object_files;
extern int core_preload_index;
+extern int scope_global;
enum safe_crlf {
SAFE_CRLF_FALSE = 0,
diff --git a/config.c b/config.c
index e87edea..8dec019 100644
--- a/config.c
+++ b/config.c
@@ -503,6 +503,14 @@ static int git_default_core_config(const char *var, const char *value)
return 0;
}
+ if (!strcmp(var, "core.scope")) {
+ if (!strcasecmp(value, "global"))
+ scope_global = 1;
+ if (!strcasecmp(value, "worktree"))
+ scope_global = 0;
+ return 0;
+ }
+
/* Add other config variables here and to Documentation/config.txt. */
return 0;
}
diff --git a/environment.c b/environment.c
index 5de6837..4d1c6e1 100644
--- a/environment.c
+++ b/environment.c
@@ -50,6 +50,7 @@ enum push_default_type push_default = PUSH_DEFAULT_MATCHING;
#endif
enum object_creation_mode object_creation_mode = OBJECT_CREATION_MODE;
int grafts_replace_parents = 1;
+int scope_global = 0;
/* Parallel index stat data preload? */
int core_preload_index = 0;
--
1.6.4.2.266.gbaa17
^ permalink raw reply related
* Re: Strange merge failure (would be overwritten by merge / cannot merge)
From: Christoph Haas @ 2009-09-05 13:07 UTC (permalink / raw)
To: git
In-Reply-To: <20090904234552.GA43797@gmail.com>
David Aguilar schrieb:
> On Fri, Sep 04, 2009 at 10:28:36PM +0200, Christoph Haas wrote:
>> Now I imported a new upstream version into the upstream branch. And then
>> tried to merge the 'upstream' branch into the 'master' branch to work on
>> it. And suddenly I get this error:
>>
>> error: Entry 'cream-abbr-eng.vim' would be overwritten by merge.
>> Cannot merge.
>>
>> To reproduce my problem:
>>
>> $> git clone git://git.workaround.org/cream
>> $> cd cream
>> $> git merge origin/upstream
>> error: Entry 'cream-abbr-eng.vim' would be overwritten by merge.
>> Cannot merge.
>> fatal: merging of trees 70008c82f82a7985531aa2d039c03fdf944ea267 and
>> 78d3a35e300434d6369424dd873bb587beacfaa4 failed
>
> Very odd indeed!
>
> $ git version
> git version 1.6.4.2.264.g79b4f
>
> I was able to workaround it:
>
> $ rm *
> $ git add -u
> $ git merge origin/upstream
Thank you. I had to "rm -r addons", too, but the general hint helped me
a lot.
> I've never run into this before.
> I think it has to do with all the renamed files.
> It looks like you're running into ain unfortunate edge case.
Actually I'm not aware of any renames. But I don't claim that I always
know what I'm doing. :)
> Does anyone else on the list have any insights?
I'd be curious, too.
Kindly
Christoph
^ permalink raw reply
* Re: Commit to wrong branch. How to fix?
From: Michael J Gruber @ 2009-09-05 12:51 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Howard Miller, git@vger.kernel.org
In-Reply-To: <40aa078e0909041011s7639cccbqa758f17a56c61863@mail.gmail.com>
Erik Faye-Lund venit, vidit, dixit 04.09.2009 19:11:
> On Fri, Sep 4, 2009 at 6:19 PM, Michael J
> Gruber<git@drmicha.warpmail.net> wrote:
>> Let's say "geesh" is the branch on which you committed by mistake, and
>> which you have reset.
>>
>> git reflog geesh
>
> That should be "git reflog show geesh", no?
>
Yes, sorry. "show" is default, but only without a branch arg :|
Michael
^ permalink raw reply
* [PATCH 2/2] add 'scope' config option
From: Clemens Buchacher @ 2009-09-05 12:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, SZEDER Gábor, git
In-Reply-To: <20090905123117.GA3099@darc.dnsalias.org>
Documentation/config.txt says it all.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
Documentation/config.txt | 6 ++++++
builtin-add.c | 2 +-
builtin-grep.c | 2 +-
cache.h | 1 +
config.c | 8 ++++++++
environment.c | 1 +
6 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5256c7f..f587cf1 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -439,6 +439,12 @@ On some file system/operating system combinations, this is unreliable.
Set this config setting to 'rename' there; However, This will remove the
check that makes sure that existing object files will not get overwritten.
+core.scope::
+ By default, the commands 'git add -u', 'git add -A' and 'git grep'
+ are limited to files below the current working directory
+ (scope='workdir'). Set this variable to scope='global' to make these
+ commands act on the whole tree instead.
+
add.ignore-errors::
Tells 'git-add' to continue adding files when some files cannot be
added due to indexing errors. Equivalent to the '--ignore-errors'
diff --git a/builtin-add.c b/builtin-add.c
index 006fd08..33ea3e4 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -285,7 +285,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
if (addremove && take_worktree_changes)
die("-A and -u are mutually incompatible");
- if ((addremove || take_worktree_changes) && !argc) {
+ if (!scope_global && (addremove || take_worktree_changes) && !argc) {
static const char *here[2] = { ".", NULL };
argc = 1;
argv = here;
diff --git a/builtin-grep.c b/builtin-grep.c
index f6af3d4..447b195 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -861,7 +861,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
if (i < argc)
paths = get_pathspec(prefix, argv + i);
- else if (prefix) {
+ else if (!scope_global && prefix) {
paths = xcalloc(2, sizeof(const char *));
paths[0] = prefix;
paths[1] = NULL;
diff --git a/cache.h b/cache.h
index 5fad24c..85c5fee 100644
--- a/cache.h
+++ b/cache.h
@@ -523,6 +523,7 @@ extern int auto_crlf;
extern int read_replace_refs;
extern int fsync_object_files;
extern int core_preload_index;
+extern int scope_global;
enum safe_crlf {
SAFE_CRLF_FALSE = 0,
diff --git a/config.c b/config.c
index e87edea..8dec019 100644
--- a/config.c
+++ b/config.c
@@ -503,6 +503,14 @@ static int git_default_core_config(const char *var, const char *value)
return 0;
}
+ if (!strcmp(var, "core.scope")) {
+ if (!strcasecmp(value, "global"))
+ scope_global = 1;
+ if (!strcasecmp(value, "worktree"))
+ scope_global = 0;
+ return 0;
+ }
+
/* Add other config variables here and to Documentation/config.txt. */
return 0;
}
diff --git a/environment.c b/environment.c
index 5de6837..4d1c6e1 100644
--- a/environment.c
+++ b/environment.c
@@ -50,6 +50,7 @@ enum push_default_type push_default = PUSH_DEFAULT_MATCHING;
#endif
enum object_creation_mode object_creation_mode = OBJECT_CREATION_MODE;
int grafts_replace_parents = 1;
+int scope_global = 0;
/* Parallel index stat data preload? */
int core_preload_index = 0;
--
1.6.4.2.264.g79b4f
^ permalink raw reply related
* [PATCH 1/2] grep: accept relative paths outside current working directory
From: Clemens Buchacher @ 2009-09-05 12:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, SZEDER Gábor, git
In-Reply-To: <7v3a717rgl.fsf@alter.siamese.dyndns.org>
On Sat, Sep 05, 2009 at 12:58:50AM -0700, Junio C Hamano wrote:
> >> If "git add -u ../.." (I mean "the grand parent directory", not "an
> >> unnamed subdirectory") did not work
I just noticed that this doesn't work with grep. In git.git:
$ cd t
$ git grep addremove -- ../
fatal: git grep: cannot generate relative filenames containing '..'
So here's a fix for that. And a configurable solution for add and grep's
scope as a follow-up. I did not look at any other commands yet.
Clemens
--o<--
Previously, "git grep" would bark at relative paths pointing outside
the current working directory (or subdirectories thereof). We already
have quote_path_relative(), which can handle such cases just fine. So
use that instead.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
builtin-grep.c | 44 ++++++++++++++------------------------------
grep.h | 1 +
2 files changed, 15 insertions(+), 30 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index ad0e0a5..f6af3d4 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -13,6 +13,7 @@
#include "parse-options.h"
#include "userdiff.h"
#include "grep.h"
+#include "quote.h"
#ifndef NO_EXTERNAL_GREP
#ifdef __unix__
@@ -152,40 +153,27 @@ static int pathspec_matches(const char **paths, const char *name, int max_depth)
return 0;
}
-static int grep_sha1(struct grep_opt *opt, const unsigned char *sha1, const char *name, int tree_name_len)
+static int grep_sha1(struct grep_opt *opt, const unsigned char *sha1, const char *path, int tree_name_len)
{
unsigned long size;
char *data;
enum object_type type;
- char *to_free = NULL;
int hit;
+ struct strbuf pathbuf = STRBUF_INIT;
data = read_sha1_file(sha1, &type, &size);
if (!data) {
- error("'%s': unable to read %s", name, sha1_to_hex(sha1));
+ error("'%s': unable to read %s", path, sha1_to_hex(sha1));
return 0;
}
if (opt->relative && opt->prefix_length) {
- static char name_buf[PATH_MAX];
- char *cp;
- int name_len = strlen(name) - opt->prefix_length + 1;
-
- if (!tree_name_len)
- name += opt->prefix_length;
- else {
- if (ARRAY_SIZE(name_buf) <= name_len)
- cp = to_free = xmalloc(name_len);
- else
- cp = name_buf;
- memcpy(cp, name, tree_name_len);
- strcpy(cp + tree_name_len,
- name + tree_name_len + opt->prefix_length);
- name = cp;
- }
+ quote_path_relative(path + tree_name_len, -1, &pathbuf, opt->prefix);
+ strbuf_insert(&pathbuf, 0, path, tree_name_len);
+ path = pathbuf.buf;
}
- hit = grep_buffer(opt, name, data, size);
+ hit = grep_buffer(opt, path, data, size);
+ strbuf_release(&pathbuf);
free(data);
- free(to_free);
return hit;
}
@@ -195,6 +183,7 @@ static int grep_file(struct grep_opt *opt, const char *filename)
int i;
char *data;
size_t sz;
+ struct strbuf buf = STRBUF_INIT;
if (lstat(filename, &st) < 0) {
err_ret:
@@ -219,8 +208,9 @@ static int grep_file(struct grep_opt *opt, const char *filename)
}
close(i);
if (opt->relative && opt->prefix_length)
- filename += opt->prefix_length;
+ filename = quote_path_relative(filename, -1, &buf, opt->prefix);
i = grep_buffer(opt, filename, data, sz);
+ strbuf_release(&buf);
free(data);
return i;
}
@@ -798,6 +788,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
};
memset(&opt, 0, sizeof(opt));
+ opt.prefix = prefix;
opt.prefix_length = (prefix && *prefix) ? strlen(prefix) : 0;
opt.relative = 1;
opt.pathname = 1;
@@ -868,15 +859,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
verify_filename(prefix, argv[j]);
}
- if (i < argc) {
+ if (i < argc)
paths = get_pathspec(prefix, argv + i);
- if (opt.prefix_length && opt.relative) {
- /* Make sure we do not get outside of paths */
- for (i = 0; paths[i]; i++)
- if (strncmp(prefix, paths[i], opt.prefix_length))
- die("git grep: cannot generate relative filenames containing '..'");
- }
- }
else if (prefix) {
paths = xcalloc(2, sizeof(const char *));
paths[0] = prefix;
diff --git a/grep.h b/grep.h
index 28e6b2a..f6eecc6 100644
--- a/grep.h
+++ b/grep.h
@@ -59,6 +59,7 @@ struct grep_opt {
struct grep_pat *pattern_list;
struct grep_pat **pattern_tail;
struct grep_expr *pattern_expression;
+ const char *prefix;
int prefix_length;
regex_t regexp;
int linenum;
--
1.6.4.2.264.g79b4f
^ permalink raw reply related
* Re: [PATCH v2] status: list unmerged files last
From: Mark Brown @ 2009-09-05 11:39 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090905090422.GA13221@coredump.intra.peff.net>
On Sat, Sep 05, 2009 at 05:04:22AM -0400, Jeff King wrote:
> On Wed, Sep 02, 2009 at 07:39:23PM +0100, Mark Brown wrote:
> > My main wishlist would be to have the same control for the changes to be
> > committed for the big merge case, the use case being while resolving
> I think we need to be more concrete than that. What is the "big merge
> case"? If there are any unmerged paths?
The context was that this was done when explictly requested by the user
so all the time when enabled. In the context I'm thinking of this would
be used via the command line more than via the config file.
> What exactly should be cut out, and how can it be configured? Should you
> have "status.unmerged" to cut out certain things? Which things (of
> staged, unstaged, and untracked)? Or should it go the other way, with a
> status.showStaged variable which can be set to "always", "never", or
> "unmerged" (and probably adding an "unmerged" option to
> "status.showUntrackedFiles).
I'd been thinking of not showing anything in the index but keeping
everything else. In terms of a configuration variable I'd go with
specifying the things not to show rather than the things to show -
the noise to cut out.
^ permalink raw reply
* Re: [git-svn] [FEATURE-REQ] track merges from git
From: Jakub Narebski @ 2009-09-05 9:23 UTC (permalink / raw)
To: git
In-Reply-To: <4A9565ED.4010608@cam.ac.uk>
Ximin Luo wrote:
> For now I just have a .git/info/grafts, but this doesn't get exported anywhere,
> so if other people "git svn clone" from svn, or "git clone" from my git repo,
> they don't get the merge information.
In future version of git (I'm not sure if it is in master yet) there
would be refs/replace feature (grafts-like), which can be exported.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH v2] status: list unmerged files last
From: Jeff King @ 2009-09-05 9:08 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090905084809.GA13073@coredump.intra.peff.net>
On Sat, Sep 05, 2009 at 04:48:09AM -0400, Jeff King wrote:
> On Sat, Sep 05, 2009 at 02:28:46AM -0400, Jeff King wrote:
>
> > I see. I still think you may want to improve "commit --dry-run" with a
> > plumbing format, though, instead of "git status". Then it would
> > automagically support "--amend", as well as other dry-run things (e.g.,
> > "git commit --dry-run --porcelain --amend foo.c"). And not having looked
> > at the code, I would guess it is a one-liner patch to switch the "output
> > format" flag that commit passes to the wt-status.c code.
>
> OK, it was a bit more complex than that. But here is a series which does
> a few things. It is still missing a few bits, so is RFC.
BTW, in case it was not obvious from the context, these are built on top
of jc/1.7.0-status.
-Peff
^ permalink raw reply
* Re: [PATCH v2] status: list unmerged files last
From: Jeff King @ 2009-09-05 9:04 UTC (permalink / raw)
To: Mark Brown; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090902183923.GA10581@rakim.wolfsonmicro.main>
On Wed, Sep 02, 2009 at 07:39:23PM +0100, Mark Brown wrote:
> My main wishlist would be to have the same control for the changes to be
> committed for the big merge case, the use case being while resolving
> merges where those changes are those that have been dealt with and the
> remaining (hopefully much fewer) changes are those that still need
> attention.
I think we need to be more concrete than that. What is the "big merge
case"? If there are any unmerged paths?
What exactly should be cut out, and how can it be configured? Should you
have "status.unmerged" to cut out certain things? Which things (of
staged, unstaged, and untracked)? Or should it go the other way, with a
status.showStaged variable which can be set to "always", "never", or
"unmerged" (and probably adding an "unmerged" option to
"status.showUntrackedFiles).
-Peff
^ permalink raw reply
* [PATCH/RFC 6/6] commit: support alternate status formats
From: Jeff King @ 2009-09-05 8:59 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090905084809.GA13073@coredump.intra.peff.net>
The status command recently grew "short" and "porcelain"
options for alternate output formats. Since status is no
longer "commit --dry-run", these formats are inaccessible to
people who do want to see a dry-run in a parseable form.
This patch makes those formats available to "git commit",
implying the "dry-run" option when they are used.
Signed-off-by: Jeff King <peff@peff.net>
---
This one is very RFC, as it has a few problems/questions:
- no tests yet, and it definitely should have some
- should alternate formats imply dry-run? It makes no sense to _not_ do
dry-run, since you would be putting cruft into the editor for the
user to see. But the other option would be barfing and complaining
about mismatched options.
- the "committable" flag is set in wt_status_print, which means it will
not be set correctly for short output. I can hack it into the short
output format, but I think it is probably a mistake for it to be
stuck with the printing routines in the first place (it is a
historical artifact, I suspect, from before we always had a "collect"
phase). So I think it should probably just be part of the "collect"
phase.
Documentation/git-commit.txt | 14 ++++++++++++++
builtin-commit.c | 39 ++++++++++++++++++++++++++++++++-------
2 files changed, 46 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 64f94cf..c45fbe4 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -75,6 +75,20 @@ OPTIONS
and paths that are untracked, similar to the one that is given
in the commit log editor.
+--short::
+ When doing a dry-run, give the output in the short-format. See
+ linkgit:git-status[1] for details. Implies `--dry-run`.
+
+--porcelain::
+ When doing a dry-run, give the output in a porcelain-ready
+ format. See linkgit:git-status[1] for details. Implies
+ `--dry-run`.
+
+-z::
+ When showing `short` or `porcelain` status output, terminate
+ entries in the status output with NUL, instead of LF. If no
+ format is given, implies the `--porcelain` output format.
+
-F <file>::
--file=<file>::
Take the commit message from the given file. Use '-' to
diff --git a/builtin-commit.c b/builtin-commit.c
index ffdee31..f2fd0a4 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -72,6 +72,15 @@ static int use_editor = 1, initial_commit, in_merge;
static const char *only_include_assumed;
static struct strbuf message;
+static int null_termination;
+static enum {
+ STATUS_FORMAT_LONG,
+ STATUS_FORMAT_SHORT,
+ STATUS_FORMAT_PORCELAIN,
+} status_format = STATUS_FORMAT_LONG;
+
+static void short_print(struct wt_status *s, int null_termination);
+
static int opt_parse_m(const struct option *opt, const char *arg, int unset)
{
struct strbuf *buf = opt->value;
@@ -105,6 +114,12 @@ static struct option builtin_commit_options[] = {
OPT_BOOLEAN('o', "only", &only, "commit only specified files"),
OPT_BOOLEAN('n', "no-verify", &no_verify, "bypass pre-commit hook"),
OPT_BOOLEAN(0, "dry-run", &dry_run, "show what would be committed"),
+ OPT_SET_INT(0, "short", &status_format, "show status concisely",
+ STATUS_FORMAT_SHORT),
+ OPT_SET_INT(0, "porcelain", &status_format,
+ "show porcelain output format", STATUS_FORMAT_PORCELAIN),
+ OPT_BOOLEAN('z', "null", &null_termination,
+ "terminate entries with NUL"),
OPT_BOOLEAN(0, "amend", &amend, "amend previous commit"),
{ OPTION_STRING, 'u', "untracked-files", &untracked_files_arg, "mode", "show untracked files, optional modes: all, normal, no. (Default: all)", PARSE_OPT_OPTARG, NULL, (intptr_t)"all" },
OPT_BOOLEAN(0, "allow-empty", &allow_empty, "ok to record an empty change"),
@@ -363,7 +378,18 @@ static int run_status(FILE *fp, const char *index_file, const char *prefix, int
s->is_initial = get_sha1(s->reference, sha1) ? 1 : 0;
wt_status_collect(s);
- wt_status_print(s);
+
+ switch (status_format) {
+ case STATUS_FORMAT_SHORT:
+ short_print(s, null_termination);
+ break;
+ case STATUS_FORMAT_PORCELAIN:
+ short_print(s, null_termination);
+ break;
+ case STATUS_FORMAT_LONG:
+ wt_status_print(s);
+ break;
+ }
return s->commitable;
}
@@ -821,6 +847,11 @@ static int parse_and_validate_options(int argc, const char *argv[],
else if (interactive && argc > 0)
die("Paths with --interactive does not make sense.");
+ if (null_termination && status_format == STATUS_FORMAT_LONG)
+ status_format = STATUS_FORMAT_PORCELAIN;
+ if (status_format != STATUS_FORMAT_LONG)
+ dry_run = 1;
+
return argc;
}
@@ -991,12 +1022,6 @@ static void short_print(struct wt_status *s, int null_termination)
int cmd_status(int argc, const char **argv, const char *prefix)
{
struct wt_status s;
- static int null_termination;
- static enum {
- STATUS_FORMAT_LONG,
- STATUS_FORMAT_SHORT,
- STATUS_FORMAT_PORCELAIN,
- } status_format = STATUS_FORMAT_LONG;
unsigned char sha1[20];
static struct option builtin_status_options[] = {
OPT__VERBOSE(&verbose),
--
1.6.4.2.418.g1a1d3.dirty
^ permalink raw reply related
* [PATCH/RFC 5/6] status: add --porcelain output format
From: Jeff King @ 2009-09-05 8:55 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090905084809.GA13073@coredump.intra.peff.net>
The "short" format was added to "git status" recently to
provide a less verbose way of looking at the same
information. This has two practical uses:
1. Users who want a more dense display of the information.
2. Scripts which want to parse the information and need a
stable, easy-to-parse interface.
For now, the "--short" format covers both of those uses.
However, as time goes on, users of (1) may want additional
format tweaks, or for "git status" to change its behavior
based on configuration variables. Those wishes will be at
odds with (2), which wants to stability for scripts.
This patch introduces a separate --porcelain option early to
avoid problems later on. Right now the --short and
--porcelain outputs are identical. However, as time goes on,
we will have the freedom to customize --short for human
consumption while keeping --porcelain stable.
Signed-off-by: Jeff King <peff@peff.net>
---
No tests. Does this really need them? At this point, it would be pure
duplication of the --short tests; I am inclined to leave such tests
until later when there is actually a difference between the two formats
(and then we will know _what_ to test).
Documentation/git-status.txt | 9 +++++++--
builtin-commit.c | 9 ++++++++-
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index fd71a7a..58d35fb 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -27,6 +27,11 @@ OPTIONS
--short::
Give the output in the short-format.
+--porcelain::
+ Give the output in a stable, easy-to-parse format for scripts.
+ Currently this is identical to --short output, but is guaranteed
+ not to change in the future, making it safe for scripts.
+
-u[<mode>]::
--untracked-files[=<mode>]::
Show untracked files (Default: 'all').
@@ -45,8 +50,8 @@ used to change the default for when the option is not
specified.
-z::
- Terminate entries with NUL, instead of LF. This implies `-s`
- (short status) output format.
+ Terminate entries with NUL, instead of LF. This implies
+ the `--porcelain` output format if no other format is given.
OUTPUT
diff --git a/builtin-commit.c b/builtin-commit.c
index aa4a358..ffdee31 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -995,12 +995,16 @@ int cmd_status(int argc, const char **argv, const char *prefix)
static enum {
STATUS_FORMAT_LONG,
STATUS_FORMAT_SHORT,
+ STATUS_FORMAT_PORCELAIN,
} status_format = STATUS_FORMAT_LONG;
unsigned char sha1[20];
static struct option builtin_status_options[] = {
OPT__VERBOSE(&verbose),
OPT_SET_INT('s', "short", &status_format,
"show status concisely", STATUS_FORMAT_SHORT),
+ OPT_SET_INT(0, "porcelain", &status_format,
+ "show porcelain output format",
+ STATUS_FORMAT_PORCELAIN),
OPT_BOOLEAN('z', "null", &null_termination,
"terminate entries with NUL"),
{ OPTION_STRING, 'u', "untracked-files", &untracked_files_arg,
@@ -1011,7 +1015,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)
};
if (null_termination && status_format == STATUS_FORMAT_LONG)
- status_format = STATUS_FORMAT_SHORT;
+ status_format = STATUS_FORMAT_PORCELAIN;
wt_status_prepare(&s);
git_config(git_status_config, &s);
@@ -1032,6 +1036,9 @@ int cmd_status(int argc, const char **argv, const char *prefix)
case STATUS_FORMAT_SHORT:
short_print(&s, null_termination);
break;
+ case STATUS_FORMAT_PORCELAIN:
+ short_print(&s, null_termination);
+ break;
case STATUS_FORMAT_LONG:
s.verbose = verbose;
if (s.relative_paths)
--
1.6.4.2.418.g1a1d3.dirty
^ permalink raw reply related
* Re: how to skip branches on git svn clone/fetch when there are errors
From: Daniele Segato @ 2009-09-05 8:55 UTC (permalink / raw)
To: Eric Wong; +Cc: Git Mailing List
In-Reply-To: <20090905061657.GC22272@dcvr.yhbt.net>
Il giorno ven, 04/09/2009 alle 23.16 -0700, Eric Wong ha scritto:
> It's unfortunate, but there's not yet an exclude/ignore directive
> when globbing. You'll have to change your $GIT_CONFIG to only
> have a list of branches you want, something like this:
>
> [svn-remote "svn"]
> url = svn://svn.mydomain.com
> fetch = path/to/repo/HEAD/root:refs/remotes/svn/trunk
>
> ; have one "fetch" line for every branch except the one you want
> fetch = path/to/repo/BRANCHES/a/root:refs/remotes/svn/a
> fetch = path/to/repo/BRANCHES/b/root:refs/remotes/svn/b
> fetch = path/to/repo/BRANCHES/c/root:refs/remotes/svn/c
>
> ; you can do the same for tags if you have the same problem
> tags = path/to/repo/TAGS/*/root:refs/remotes/svn/tags/*
>
> But you shouldn't have to worry about having "fetch" entries for
> stale/old branches/tags you've already imported.
I see...
That means that then I'll have to manually add new created branches,
right?
well... I tried to avoid this kind of configuration for weeks :) but
that's probably my best way with that repo....
thank you,
Daniele
^ permalink raw reply
* [PATCH/RFC 4/6] status: refactor format option parsing
From: Jeff King @ 2009-09-05 8:54 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090905084809.GA13073@coredump.intra.peff.net>
This makes it possible to have more than two formats.
Signed-off-by: Jeff King <peff@peff.net>
---
This would make a "--long" option trivial, but I'm not sure there is
much point.
builtin-commit.c | 21 ++++++++++++++-------
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 5b42179..aa4a358 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -991,12 +991,16 @@ static void short_print(struct wt_status *s, int null_termination)
int cmd_status(int argc, const char **argv, const char *prefix)
{
struct wt_status s;
- static int null_termination, shortstatus;
+ static int null_termination;
+ static enum {
+ STATUS_FORMAT_LONG,
+ STATUS_FORMAT_SHORT,
+ } status_format = STATUS_FORMAT_LONG;
unsigned char sha1[20];
static struct option builtin_status_options[] = {
OPT__VERBOSE(&verbose),
- OPT_BOOLEAN('s', "short", &shortstatus,
- "show status concisely"),
+ OPT_SET_INT('s', "short", &status_format,
+ "show status concisely", STATUS_FORMAT_SHORT),
OPT_BOOLEAN('z', "null", &null_termination,
"terminate entries with NUL"),
{ OPTION_STRING, 'u', "untracked-files", &untracked_files_arg,
@@ -1006,8 +1010,8 @@ int cmd_status(int argc, const char **argv, const char *prefix)
OPT_END(),
};
- if (null_termination)
- shortstatus = 1;
+ if (null_termination && status_format == STATUS_FORMAT_LONG)
+ status_format = STATUS_FORMAT_SHORT;
wt_status_prepare(&s);
git_config(git_status_config, &s);
@@ -1024,9 +1028,11 @@ int cmd_status(int argc, const char **argv, const char *prefix)
s.is_initial = get_sha1(s.reference, sha1) ? 1 : 0;
wt_status_collect(&s);
- if (shortstatus)
+ switch (status_format) {
+ case STATUS_FORMAT_SHORT:
short_print(&s, null_termination);
- else {
+ break;
+ case STATUS_FORMAT_LONG:
s.verbose = verbose;
if (s.relative_paths)
s.prefix = prefix;
@@ -1035,6 +1041,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)
if (diff_use_color_default == -1)
diff_use_color_default = git_use_color_default;
wt_status_print(&s);
+ break;
}
return 0;
}
--
1.6.4.2.418.g1a1d3.dirty
^ permalink raw reply related
* [PATCH/RFC 3/6] status: refactor short-mode printing to its own function
From: Jeff King @ 2009-09-05 8:53 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090905084809.GA13073@coredump.intra.peff.net>
We want to be able to call it from multiple places.
Signed-off-by: Jeff King <peff@peff.net>
---
I am tempted to move all of the short-printing code to its own file, and
move "cmd_status" to its own builtin-status.c, as well. I don't know if
that is a cleanup that makes sense to others, as well, or if it is too
much churn for too little good.
builtin-commit.c | 45 +++++++++++++++++++++++++--------------------
1 files changed, 25 insertions(+), 20 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 812470e..5b42179 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -966,11 +966,32 @@ static void short_untracked(int null_termination, struct string_list_item *it,
}
}
+static void short_print(struct wt_status *s, int null_termination)
+{
+ int i;
+ for (i = 0; i < s->change.nr; i++) {
+ struct wt_status_change_data *d;
+ struct string_list_item *it;
+
+ it = &(s->change.items[i]);
+ d = it->util;
+ if (d->stagemask)
+ short_unmerged(null_termination, it, s);
+ else
+ short_status(null_termination, it, s);
+ }
+ for (i = 0; i < s->untracked.nr; i++) {
+ struct string_list_item *it;
+
+ it = &(s->untracked.items[i]);
+ short_untracked(null_termination, it, s);
+ }
+}
+
int cmd_status(int argc, const char **argv, const char *prefix)
{
struct wt_status s;
static int null_termination, shortstatus;
- int i;
unsigned char sha1[20];
static struct option builtin_status_options[] = {
OPT__VERBOSE(&verbose),
@@ -1003,25 +1024,9 @@ int cmd_status(int argc, const char **argv, const char *prefix)
s.is_initial = get_sha1(s.reference, sha1) ? 1 : 0;
wt_status_collect(&s);
- if (shortstatus) {
- for (i = 0; i < s.change.nr; i++) {
- struct wt_status_change_data *d;
- struct string_list_item *it;
-
- it = &(s.change.items[i]);
- d = it->util;
- if (d->stagemask)
- short_unmerged(null_termination, it, &s);
- else
- short_status(null_termination, it, &s);
- }
- for (i = 0; i < s.untracked.nr; i++) {
- struct string_list_item *it;
-
- it = &(s.untracked.items[i]);
- short_untracked(null_termination, it, &s);
- }
- } else {
+ if (shortstatus)
+ short_print(&s, null_termination);
+ else {
s.verbose = verbose;
if (s.relative_paths)
s.prefix = prefix;
--
1.6.4.2.418.g1a1d3.dirty
^ permalink raw reply related
* [PATCH/RFC 2/6] docs: note that status configuration affects only long format
From: Jeff King @ 2009-09-05 8:52 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090905084809.GA13073@coredump.intra.peff.net>
The short format does not respect any of the usual status.*
configuration.
Signed-off-by: Jeff King <peff@peff.net>
---
Combined with the --short/--porcelain distinction introduced later in
the series, should short perhaps respect status.relativePaths and
status.submoduleSummary? Which would mean replacing this patch with ones
to make those things work. :)
Documentation/git-status.txt | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index b5939d6..fd71a7a 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -109,13 +109,13 @@ compatibility) and `color.status.<slot>` configuration variables
to colorize its output.
If the config variable `status.relativePaths` is set to false, then all
-paths shown are relative to the repository root, not to the current
-directory.
+paths shown in the long format are relative to the repository root, not
+to the current directory.
If `status.submodulesummary` is set to a non zero number or true (identical
-to -1 or an unlimited number), the submodule summary will be enabled and a
-summary of commits for modified submodules will be shown (see --summary-limit
-option of linkgit:git-submodule[1]).
+to -1 or an unlimited number), the submodule summary will be enabled for
+the long format and a summary of commits for modified submodules will be
+shown (see --summary-limit option of linkgit:git-submodule[1]).
SEE ALSO
--------
--
1.6.4.2.418.g1a1d3.dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox