* [JGIT PATCH 1/5] Add set to IntList
From: Johannes Schindelin @ 2009-09-03 10:46 UTC (permalink / raw)
To: git, spearce
In-Reply-To: <cover.1251974493u.git.johannes.schindelin@gmx.de>
Some applications may wish to modify an int list.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
.../tst/org/spearce/jgit/util/IntListTest.java | 21 ++++++++++++++++++++
.../src/org/spearce/jgit/util/IntList.java | 17 ++++++++++++++++
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/util/IntListTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/util/IntListTest.java
index c470d55..a7a12cd 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/util/IntListTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/util/IntListTest.java
@@ -144,6 +144,27 @@ public void testClear() {
}
}
+ public void testSet() {
+ final IntList i = new IntList();
+ i.add(1);
+ assertEquals(1, i.size());
+ assertEquals(1, i.get(0));
+
+ i.set(0, 5);
+ assertEquals(5, i.get(0));
+
+ try {
+ i.set(5, 5);
+ fail("accepted set of 5 beyond end of list");
+ } catch (ArrayIndexOutOfBoundsException e){
+ assertTrue(true);
+ }
+
+ i.set(1, 2);
+ assertEquals(2, i.size());
+ assertEquals(2, i.get(1));
+ }
+
public void testToString() {
final IntList i = new IntList();
i.add(1);
diff --git a/org.spearce.jgit/src/org/spearce/jgit/util/IntList.java b/org.spearce.jgit/src/org/spearce/jgit/util/IntList.java
index 0a84793..32d24fc 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/util/IntList.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/util/IntList.java
@@ -94,6 +94,23 @@ public void add(final int n) {
}
/**
+ * Assign an entry in the list.
+ *
+ * @param index
+ * index to set, must be in the range [0, {@link #size()}).
+ * @param n
+ * value to store at the position.
+ */
+ public void set(final int index, final int n) {
+ if (count < index)
+ throw new ArrayIndexOutOfBoundsException(index);
+ else if (count == index)
+ add(n);
+ else
+ entries[index] = n;
+ }
+
+ /**
* Pad the list with entries.
*
* @param toIndex
--
1.6.4.297.gcb4cc
^ permalink raw reply related
* [JGIT PATCH 0/5] jgit diff
From: Johannes Schindelin @ 2009-09-03 10:45 UTC (permalink / raw)
To: git, spearce
In-Reply-To: <alpine.DEB.1.00.0909030846230.8306@pacific.mpi-cbg.de>
This patch series provides a rudimentary, working implementation of "jgit
diff". It does not provide all modes of "git diff" -- by far! -- but it
is robust, and should provide a good starting point for further work.
Unfortunately, I lack the time to do proper profiling/benchmarking, but I
verified at least that it succeeds in recreating valid patches for all
commits in jgit.git with this script:
git rev-list HEAD |
sed '$d' |
while read commit
do
printf "\\r$commit "
(export GIT_INDEX_FILE=test-index &&
./jgit diff $commit^ $commit > test-patch &&
git read-tree $commit^ &&
git apply --cached test-patch &&
git diff --exit-code --cached $commit) || break
done
Johannes Schindelin (5):
Add set to IntList
Add Myers' algorithm to generate diff scripts
Add a test class for Myers' diff algorithm
Prepare RawText for diff-index and diff-files
Add the "jgit diff" command
.../services/org.spearce.jgit.pgm.TextBuiltin | 1 +
.../src/org/spearce/jgit/pgm/Diff.java | 133 +++++
.../tst/org/spearce/jgit/diff/MyersDiffTest.java | 103 ++++
.../tst/org/spearce/jgit/util/IntListTest.java | 21 +
.../src/org/spearce/jgit/diff/DiffFormatter.java | 2 +-
.../src/org/spearce/jgit/diff/MyersDiff.java | 515 ++++++++++++++++++++
.../src/org/spearce/jgit/diff/RawText.java | 28 +-
.../src/org/spearce/jgit/util/IntList.java | 17 +
8 files changed, 818 insertions(+), 2 deletions(-)
create mode 100644 org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/Diff.java
create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/diff/MyersDiffTest.java
create mode 100644 org.spearce.jgit/src/org/spearce/jgit/diff/MyersDiff.java
^ permalink raw reply
* Hosting Git repositories: how useful will git-gc be?
From: Matthieu Moy @ 2009-09-03 9:45 UTC (permalink / raw)
To: git
Hi,
I'm helping my sysadmin to set up some Git repository hosting via
gitosis. I'm trying to keep it as simple as possible.
A question: is it necessary/recommanded/useless to set up a cron job
doing a "git gc" in each repository? My understanding is that a push
through ssh will do some packing, is it correct? Does receiving a pack
trigger a "git gc --auto"?
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCHv2] git-config: Parse config files leniently
From: Michael J Gruber @ 2009-09-03 7:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vab1cfr6s.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 03.09.2009 09:00:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Currently, git config dies as soon as there is a parsing error. This is
>> especially unfortunate in case a user tries to correct config mistakes
>> using git config -e.
>>
>> Instead, issue a warning only and treat the rest of the line as a
>> comment (ignore it). This benefits not only git config -e users but
>> also everyone else.
>
> This changes the behaviour enough to break t3200-branch.sh, test #52.
>
> The test stuffs an invalid (but not syntactically incorrect) value used by
> "git branch" in the configuration and tries to make sure that "git branch"
> diagnoses the breakage, but it does not fail anymore with your patch.
>
> There are probably other breakages as well (e.g. t5304-prune.sh, test #5)
> but if you trace "git branch" under the debugger in the trash directory
> left after running t3200 with -i, it should be pretty obvious that your
> patch is utterly bogus. get_value() can return negative result after
> diagnosing a semantic problem with the value, and that is different from a
> syntax error that you would try to recover and continue, pretending you
> can ignore the remainder of the line as if it is a comment.
>
> Why was I CC'ed, if the patch wasn't even self tested?
Because
- not CC'ing you would have meant culling you from the existing CC,
- we've discussed v1 of this patch before,
- I asked in this patch (v2) whether to go for an alternative.
Since "git config -e" for broken config is not my itch at all, but the
reporter's, I'll stop my efforts after this response.
Michael
^ permalink raw reply
* Re: [PATCHv2] git-config: Parse config files leniently
From: Junio C Hamano @ 2009-09-03 7:00 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <f29b5893b7022f53d380504fe201303acd9ee3da.1251922441.git.git@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Currently, git config dies as soon as there is a parsing error. This is
> especially unfortunate in case a user tries to correct config mistakes
> using git config -e.
>
> Instead, issue a warning only and treat the rest of the line as a
> comment (ignore it). This benefits not only git config -e users but
> also everyone else.
This changes the behaviour enough to break t3200-branch.sh, test #52.
The test stuffs an invalid (but not syntactically incorrect) value used by
"git branch" in the configuration and tries to make sure that "git branch"
diagnoses the breakage, but it does not fail anymore with your patch.
There are probably other breakages as well (e.g. t5304-prune.sh, test #5)
but if you trace "git branch" under the debugger in the trash directory
left after running t3200 with -i, it should be pretty obvious that your
patch is utterly bogus. get_value() can return negative result after
diagnosing a semantic problem with the value, and that is different from a
syntax error that you would try to recover and continue, pretending you
can ignore the remainder of the line as if it is a comment.
Why was I CC'ed, if the patch wasn't even self tested?
^ permalink raw reply
* jgit diff, was Re: [JGIT] Request for help
From: Johannes Schindelin @ 2009-09-03 6:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nasser Grainawi, Git Mailing List
In-Reply-To: <20090903012207.GF1033@spearce.org>
Hi,
On Wed, 2 Sep 2009, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Wed, 2 Sep 2009, Nasser Grainawi wrote:
> >
> > > I'm looking to add 'git patch-id' to JGit and I could use a few
> > > pointers. I'm not very familiar with the JGit code base or Java, so
> > > please excuse any blatant oversights or unintelligent questions.
> > >
> > > First off, is there a "hacking JGit" document anywhere? One of those
> > > would be great right now.
> >
> > There have been some mails with details about JGit from Shawn (IIRC)
> > to this very list.
>
> Yea, for the most part I think we use Eclipse, and you just have to
> import JGit's top level directory into Eclipse as it comes with Eclipse
> project files. But I know some folks only use our Maven build (under
> jgit-maven/jgit) or use NetBeans. I have no idea how to import the
> project into the latter or configure its unit tests to run.
FWIW I use vim & shell most of the time (yes, even for JGit).
> > This is not really difficult in Java, however, it relies on a working
> > diff implementation (and IIRC my implementation has not yet been
> > integrated into JGit).
>
> Speaking of... where does that stand?
Same as where I left off. IOW it is a working implementation that saw
some testing, but I simply lack the time for performance tuning.
It should not be all that bad, though.
***goes looking at
http://repo.or.cz/w/jgit/dscho.git?a=shortlog;h=refs/heads/diff
***
Seems I misremembered a bit. Christian provided a patch to make it
compileable, but I think that I ran the script to verify that the diffs
are correct on jgit.git and IIRC it completed fine.
There is a project in my day-job, however, which eats all my time at the
moment (it is actually wrapping up a "succeeded" GSoC project where the
student -- *sigh* -- has gone away). So all I can do is to rebase to
current jgit.git's 's master, to run the script, and submit the current
patch series (valuing correctness over speed).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v6 5/6] fast-import: add option command
From: Sverre Rabbelier @ 2009-09-03 4:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Shawn O. Pearce, Johannes Schindelin, Git List, Ian Clatworthy,
Matt McClure, Miklos Vajna, Julian Phillips, vcs-fast-import-devs
In-Reply-To: <7vskf4px6j.fsf@alter.siamese.dyndns.org>
Heya,
On Thu, Sep 3, 2009 at 04:41, Junio C Hamano<gitster@pobox.com> wrote:
> If "option git something-unknown" is given, it is clear that the tool that
> generated the stream assumed that such an option exists in the importer;
> it might appear prudent to abort the operation.
>
> But what about "option hg something"?
I think we should assume that if we see 'option not-us foo' without a
preceeding 'feature not-us-option', the frontend does not require us
to understand the option (perhaps because they also specify 'option
git foo'.
> If that is the sensible thing to do, then we obviously should ignore
> "option hg anything", but at the same time we should ignore "option git
> we-do-not-know-what-it-does".
Perhaps, frontends could then use 'feature git-quiet-option' if it
wants to make sure it is supported.
> I think at least the function should be made conditional to die() if it
> was called from parse_argv() but simply ignore unknown if it was called
> from the input stream.
Makes sense, what do the fast-import devs think?
>> +static void parse_option(void)
>> +{
>> + char* option = command_buf.buf + 11;
>
> ERROR: "foo* bar" should be "foo *bar"
Ah, I thought I had fixed all of those, apologies.
> ERROR: do not use C99 // comments
> ERROR: do not use C99 // comments
Will fix in the next version (after we decide on what to do with
unknown git options).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v6 5/6] fast-import: add option command
From: Junio C Hamano @ 2009-09-03 2:41 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Shawn O. Pearce, Johannes Schindelin, Git List, Ian Clatworthy,
Matt McClure, Miklos Vajna, Julian Phillips, vcs-fast-import-devs
In-Reply-To: <1251914223-31435-6-git-send-email-srabbelier@gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Main difference with v5 is that the syntax is now 'option git ...'
> as per a discussion with the other fast-import devs. Other options,
> e.g. 'option hg' are ignored. Also fixed the docs to say that
> feature commands are allowed before git option commands.
Perhaps the other people have discussed and thought about this much deeper
than I have after seeing the above description, but what should the
semantics be when you see unknown options?
If "option git something-unknown" is given, it is clear that the tool that
generated the stream assumed that such an option exists in the importer;
it might appear prudent to abort the operation.
But what about "option hg something"?
It is an indication that the stream is meant to be used with the named
option if fed to Hg, but it does not say anything about what should happen
when used with other systems. If older versions of Hg that do not grok
the given option is expected to abort because they won't be able to change
the behaviour to obey the optional semantics demanded by the "option hg
something", what should the other VCS do?
Worrying about the above would be unnecessary, if you declare that it is
*entirely* optional to understand and obey "option", and ignoring them
does not result in a corrupt import at all. I think that is the intent
behind "option", as opposed to "feature", and is consistent with the fact
that the command line options can override the in-stream settings. In
other words, any in-stream instruction that changes the semantics of
stream to render it dangerous to be processed by older version of tools
would be expressed with "feature", not with "option".
If that is the sensible thing to do, then we obviously should ignore
"option hg anything", but at the same time we should ignore "option git
we-do-not-know-what-it-does".
But then, the call to die("Unsupported option: %s", option) at the end of
parse_one_option() is wrong, isn't it?
I think at least the function should be made conditional to die() if it
was called from parse_argv() but simply ignore unknown if it was called
from the input stream.
> diff --git a/fast-import.c b/fast-import.c
> index 9bf06a4..bad93dc 100644
> --- a/fast-import.c
> +++ b/fast-import.c
> @@ -2456,11 +2468,31 @@ static void parse_feature(void)
>
> if (!prefixcmp(feature, "date-format=")) {
> option_date_format(feature + 12);
> + } else if (!strcmp("git-options", feature)) {
> + options_enabled = 1;
> } else {
> die("This version of fast-import does not support feature %s.", feature);
> }
> }
>
> +static void parse_option(void)
> +{
> + char* option = command_buf.buf + 11;
ERROR: "foo* bar" should be "foo *bar"
> +
> + if (!options_enabled)
> + die("Got option command '%s' before options feature'", option);
> +
> + if (seen_non_option_command)
> + die("Got option command '%s' after non-option command", option);
> +
> + parse_one_option(option);
> +}
> +
> +static void parse_nongit_option(void)
> +{
> + // do nothing
ERROR: do not use C99 // comments
> @@ -2539,9 +2581,18 @@ int main(int argc, const char **argv)
> parse_progress();
> else if (!prefixcmp(command_buf.buf, "feature "))
> parse_feature();
> + else if (!prefixcmp(command_buf.buf, "option git "))
> + parse_option();
> + else if (!prefixcmp(command_buf.buf, "option "))
> + parse_nongit_option();
> else
> die("Unsupported command: %s", command_buf.buf);
> }
> +
> + // argv hasn't been parsed yet, do so
ERROR: do not use C99 // comments
^ permalink raw reply
* Re: [JGIT] Request for help
From: Shawn O. Pearce @ 2009-09-03 1:23 UTC (permalink / raw)
To: Nasser Grainawi; +Cc: Git Mailing List
In-Reply-To: <4A9EFFB1.9090501@codeaurora.org>
Nasser Grainawi <nasser@codeaurora.org> wrote:
> Should PatchId be a class on its own, or just a method within the Patch
> class?
Hmm, maybe a method on Patch is reasonable.
--
Shawn.
^ permalink raw reply
* Re: [JGIT] Request for help
From: Shawn O. Pearce @ 2009-09-03 1:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nasser Grainawi, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0909030157090.8306@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 2 Sep 2009, Nasser Grainawi wrote:
>
> > I'm looking to add 'git patch-id' to JGit and I could use a few
> > pointers. I'm not very familiar with the JGit code base or Java, so
> > please excuse any blatant oversights or unintelligent questions.
> >
> > First off, is there a "hacking JGit" document anywhere? One of those
> > would be great right now.
>
> There have been some mails with details about JGit from Shawn (IIRC) to
> this very list.
Yea, for the most part I think we use Eclipse, and you just have
to import JGit's top level directory into Eclipse as it comes with
Eclipse project files. But I know some folks only use our Maven
build (under jgit-maven/jgit) or use NetBeans. I have no idea how
to import the project into the latter or configure its unit tests
to run.
> > So far I'm just trying to define the inputs and outputs. On Shawn's
> > suggestion I'm planning on making it part of the org.spearce.jgit.patch
> > package. C Git patch-id very generically has an input of a 'patch', so
> > I'm thinking this implementation should use the Patch object.
>
> C Git patch-id takes a valid patch as input; I do not think that you want
> to use the Patch object.
I think we do want to use the Patch object. The Patch entity in
JGit is a parsed representation of the git diff or unified diff
structure. Its relatively easy to walk over, and all of the mess
about determining line type has already been done.
We'd probably want to do something that is a lot like the object
Patch as the output of our diff routine. A tool (e.g. Gerrit Code
Review) might only want the EditList for a given file, and not
really care about the actual formatted patch text, as it reformats
everything itself. I think patch-id computation is along those
same lines.
If we were to compute a patch-id off an InputStream we would probably
just send it through the Patch object first.
> This is not really difficult in Java, however, it relies on a working diff
> implementation (and IIRC my implementation has not yet been integrated
> into JGit).
Speaking of... where does that stand?
--
Shawn.
^ permalink raw reply
* Re: [PATCH v2] status: list unmerged files last
From: David Aguilar @ 2009-09-03 1:12 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090902175908.GA5998@coredump.intra.peff.net>
On Wed, Sep 02, 2009 at 01:59:08PM -0400, Jeff King wrote:
> On Wed, Sep 02, 2009 at 03:07:32AM -0700, David Aguilar wrote:
>
> > I agree with all of this but would also add that we can have
> > our cake and eat it too with respect to wanting to "keep
> > similar things together" and having "unmerged near bottom".
>
> Well, my point was that the "bottom" is not really cake, but I am not
> sure anyone else agrees.
>
> > No one has suggested this, so I figured I would.
> > What do you think about this layout?
> >
> > - untracked
> > - staged
> > - modified
> > - unmerged
>
> What about the current branch? Alternate author info? Tracking branch
> relationship? Should those be at the top or bottom?
>
> I dunno. Maybe it is just me being crotchety and hating change, but I
> like the current order (though swapping it below "updated" is fine with
> me).
Nah, you're right.
Being crotchety and hating change is a good thing here.
> If you want to know "what does commit --amend do", then shouldn't you be
> using "git commit --amend --dry-run" (which is what "git status" is now,
> but will not be in v1.7.0)?
>
> Are there other uses cases for arbitrary tree-ish's?
>
> > BTW is status -s intended to be something plumbing-like;
> > something we can build upon and expect to be stable?
> > I'm just curious because other commands have a --porcelain
> > option and I wasn't sure if this was the intent.
>
> We mentioned a --porcelain option in other discussion, but I don't think
> there is a patch. I would be in favor of --porcelain, even if it is
> currently identical to --short, because then it gives us freedom to
> diverge later (and in particular it gives us the freedom to let user
> configuration affect what is shown).
>
> -Peff
The only use case would be for --amend.
Which is why I asked about --porcelain; really what I want is
something like
git status --porcelain HEAD^
Rolling a patch to make --porcelain an alias for --short seems
like a good idea. If we want to support HEAD^ and HEAD^ only
then perhaps an --amend flag is useful.
The real crux of my question was about being able to script
it, which is why commit --dry-run is not enough.
--
David
^ permalink raw reply
* Re: [JGIT] Request for help
From: Johannes Schindelin @ 2009-09-03 0:04 UTC (permalink / raw)
To: Nasser Grainawi; +Cc: Git Mailing List, Shawn O. Pearce
In-Reply-To: <4A9EFFB1.9090501@codeaurora.org>
Hi,
On Wed, 2 Sep 2009, Nasser Grainawi wrote:
> I'm looking to add 'git patch-id' to JGit and I could use a few
> pointers. I'm not very familiar with the JGit code base or Java, so
> please excuse any blatant oversights or unintelligent questions.
>
> First off, is there a "hacking JGit" document anywhere? One of those
> would be great right now.
There have been some mails with details about JGit from Shawn (IIRC) to
this very list.
> So far I'm just trying to define the inputs and outputs. On Shawn's
> suggestion I'm planning on making it part of the org.spearce.jgit.patch
> package. C Git patch-id very generically has an input of a 'patch', so
> I'm thinking this implementation should use the Patch object.
C Git patch-id takes a valid patch as input; I do not think that you want
to use the Patch object.
FWIW a patch-id is nothing else than the SHA-1 of a diff where the "diff",
"index", "@@" lines and all the whitespace was removed.
This is not really difficult in Java, however, it relies on a working diff
implementation (and IIRC my implementation has not yet been integrated
into JGit).
Ciao,
Dscho
^ permalink raw reply
* [JGIT] Request for help
From: Nasser Grainawi @ 2009-09-02 23:28 UTC (permalink / raw)
To: Git Mailing List; +Cc: Shawn O. Pearce
Hello all,
I'm looking to add 'git patch-id' to JGit and I could use a few
pointers. I'm not very familiar with the JGit code base or Java, so
please excuse any blatant oversights or unintelligent questions.
First off, is there a "hacking JGit" document anywhere? One of those
would be great right now.
So far I'm just trying to define the inputs and outputs. On Shawn's
suggestion I'm planning on making it part of the org.spearce.jgit.patch
package. C Git patch-id very generically has an input of a 'patch', so
I'm thinking this implementation should use the Patch object. Looking at
that class it seems that has everything patch-id should need, so perhaps
that's the only input.
As far as output, C Git patch-id has the special feature to output the
commit-id along with the patch-id when it gets input in the format of
git-diff-tree. Should JGit do the same or just return the patch-id? I
don't know that this question even makes sense in the context of JGit
(since the commit-id is almost certainly available elsewhere and someone
calling 'getPatchId()' is likely only interested in the patch-id).
Should PatchId be a class on its own, or just a method within the Patch
class?
Thanks,
Nasser
^ permalink raw reply
* Git User's Survey 2009 partial summary, part 3 - last 10 questions (incl. getting help)
From: Jakub Narebski @ 2009-09-02 21:26 UTC (permalink / raw)
To: git
It is around month and a half since Git User's Survey 2009 was started
(it was started on 15 July 2009), which is a 3/4 of planned duration
time of the survey.
So I think this is time for third part partial summary of Git User's
Survey 2009. The previous parts can be found at
http://thread.gmane.org/gmane.comp.version-control.git/124599
Subject: Git User's Survey 2009 partial summary, part 1 -
- announcing survey, participation
Message-Id: <200907312246.12134.jnareb@gmail.com>
and
http://thread.gmane.org/gmane.comp.version-control.git/126153
Subject: Git User's Survey 2009 partial summary, part 2 -
- from first 10
Message-Id: <200908171224.44686.jnareb@gmail.com>
You can see summary of Git User's Survey 2009 responses (and make your
own analysis, optionally using provided set of filters) at the
following URL:
http://www.survs.com/shareResults?survey=2PIMZGU0&rndm=678J66QRA2
http://tinyurl.com/GitSurvey2009Analyze
After the survey ends (or earlier, if it is requested) the raw data
would be published on GitSurvey2009 page on Git Wiki in CSV and XLS
formats (like on http://git.or.cz/giwiki/GitSurvey2008).
........................................................
Total respondents: 3519
First response: Jul 15, 2009
Last response: Sep 01, 2009 (included in this analysis)
Open during: 56 days
Average time: 44 minutes
We have currently (status for 1 September 2009) around 3519 responses,
as compared to 3236 individual responses (including 21 responses in
'test' channel) for survey in 2008, 683 individual responses in 2007,
and around 117 responses in 2006.
20) Overall, how happy are you with Git?
(Choice - Single answer)
===========================================
Answer | resp [%] | resp [n]
-------------------------------------------
unhappy | 1% | 34
not so happy | 4% | 140
happy | 23% | 758
very happy | 52% | 1696
completely ecstatic | 20% | 650
----------------------+--------------------
Total respondents | 3278
Skipped this question | 241
===========================================
There were some complaints during planning stage of this year survey
that the answers for this question are not symmetric; nevertheless it
is set of answers that was used in previous survey(s), and it would
help comparing data with previous surveys to keep it as it is now.
Most responders are very happy with Git, and this answer seems to be a
center of responses. One should take into account that if one is
unhappy with Git, it is less likely that one would continue using it
(unless other circumstances would force using it, like the project one
contributes to using Git as DVCS of choice), thus less likely to be
Git user and to participate in this Git User's Survey. There can be
bias because it is _Git_ survey; it might be different if it was
generic survey about (distributed) version control systems.
21) In your opinion, which areas in Git need improvement?
Please state your preference.
(Matrix - Rating)
------------------------------------------------------------------------------
Area in Git | don't need | a little | some | much || Avg.
==============================================================================
user-interface | 428 - 14% | 882 - 28% | 1055 - 33% | 707 - 22% || 2.59
documentation | 340 - 11% | 946 - 30% | 1252 - 40% | 551 - 17% || 2.60
performance | 2167 - 69% | 660 - 21% | 174 - 6% | 46 - 1% || 1.33
more features | 1595 - 51% | 1007 - 32% | 360 - 11% | 53 - 2% || 1.55
tools (e.g. GUI) | 681 - 22% | 696 - 22% | 934 - 30% | 758 - 24% || 2.51
i18n[1] | 2184 - 69% | 398 - 13% | 225 - 7% | 89 - 3% || 1.27
------------------+-----------------------------------------------------------
Total respondents | 3155
Skipped | 364
==============================================================================
Footnotes:
~~~~~~~~~~
[1] Originally "localization (translation)", shortened to "i18n"
to reduce line length
Going by average rating, it is documentation (2.60) and user-interface
(2.59), and then tools (2.51) that needs improvements. Areas that
needs improvement 'much' are tools (24%), UI (22%) and documentation
(17%); the same set, different priority. Areas that needs 'some'
improvement are documentation (40%), then UI (33%) and tools (30%).
Areas that 'don't need' improvements are localization (translations)
and performance, both with around 69%, then 'more features' with 51%.
22) Did you participate in previous Git User's Surveys?
(Choice - Multiple answers)
=======================================================
Year | resp [%] | resp [n] || in year
-------------------------------------------------------
in 2006 | 11% | 88 || 117
in 2007 | 30% | 251 || 683
in 2008 | 97% | 801 || 3236
----------------------+--------------------------------
Total respondents | 823
Skipped this question | 2696
=======================================================
"In year" column refers to number of replies (number of responses) in
the Git User's Survey for given year. The percentage is calculated
relative to number of replies in this question, not to the total
number of responders.
======================================================
Year | resp | resp || in year
| / 3519 | / in year ||
------------------------------------------------------
in 2006 | 2.5% | 75.2% || 117
in 2007 | 7.1% | 36.8% || 683
in 2008 | 22.8% | 24.8% || 3236
======================================================
Without further analysis (and the data that we don't have) we can only
assume that 2006 survey (narrowly announced) was answered mainly by
hard-core Git users and contributors, which follow Git announcements
and participate in surveys.
Note that 2008 (previous) and 2009 (this one) surveys were announced
in slightly different ways: 2008 was announced on git mailing lists,
2009 was announced on blogs and hosting sites.
If you want to try to do further analysis, there are filters for this
answers one can use to analyze survey responses.
23) How do you compare the current version with the version
from one year ago?
(Choice - Single answer)
[FYI There is list of changes from year ago in the survey text]
===========================================
Answer | resp [%] | resp [n]
-------------------------------------------
better | 50% | 1385
no changes | 8% | 228
worse | 0% | 10
cannot say | 42% | 1162
----------------------+--------------------
Total respondents | 2785
Skipped this question | 734
===========================================
Most people (50%) think that Git improved since year ago; very few
(10 in 2785) think it is worse... but almost as many 'cannot say' (42%)
if it is better than year ago.
If we take 'cannot say' as indication that responder didn't use Git a
year ago, and that is the reason they cannot do comparison, it seems
that there are many new Git users participating in this survey.
24) How useful have you found the following forms of Git documentation?
(Matrix - One answer per row)
======================================================================
Documentation | never used | not useful | somewhat | is useful
----------------------------------------------------------------------
Git Wiki | 1138 - 36% | 135 - 4% | 1174 - 37% | 652 - 21%
on-line help | 404 - 13% | 100 - 3% | 1283 - 40% | 1351 - 43%
help in git | 249 - 8% | 199 - 6% | 1126 - 36% | 1560 - 49%
------------------+---------------------------------------------------
Total respondents | 3169
Skipped | 350
======================================================================
Least used form of documentation is Git Wiki (http://git.or.cz/gitwiki)
with 36% responders never using it, but those that use it feel that it
is somewhat useful to useful.
Both help distributed with Git (manpages, Git User's Manual, HOWTOs,
etc.) and on-line help (including but not limited to Git Community
Book, and tutorials and guides on Git homepage) are almost the same
useful, with help included in Git felt to be more useful than on-line
help (49% vs 43% is useful, 36% vs 40% only somewhat).
25) Have you tried to get help regarding Git from other people?
(Choice - Single answer)
This question, and questions following it were meant to be about
getting help from other people, rather than trying to find help by
self. From the set of "other (please specify)" answers for "help
channel" (which include among others many instances of "Google search"
or equivalent) it looks like it was not entirely clean.
===========================================
Answer | resp [%] | resp [n]
-------------------------------------------
Yes | 65% | 2082
No | 35% | 1121
----------------------+--------------------
Total respondents | 3203
Skipped this question | 316
===========================================
As you can see 2/3 responders tried to get help regarding Git from
other people.
26) If yes, did you get these problems resolved quickly
and to your liking?
(Choice - Single answer)
===========================================
Answer | resp [%] | resp [n]
-------------------------------------------
Yes | 63% | 1349
No | 6% | 122
Somewhat | 32% | 686
----------------------+--------------------
Total respondents | 2157 / 2082
Skipped this question | 1362
===========================================
Consistency check: 2082 people answered that they tried to get help
about Git from other people, but we have 2157 responses in this
question...
It looks like we have good community surrounding Git, if 2/3 Git
questions are resolved quickly and accurately, and only 6% couldn't
get quick and to their liking response.
27) What channel(s) did you use to request help?
(Choice - Multiple answers)
==============================================================
Channel | resp [%] | resp [n]
--------------------------------------------------------------
git mailing list (git@vger.kernel.org) | 12% | 261
"Git for Human Beings" Google Group | 2% | 48
IRC (#git) | 31% | 668
IRC (other, e.g. #github) | 10% | 221
request in blog post or on wiki[1] | 8% | 176
asking git guru/colleague | 58% | 1248
project mailing list, or IRC, or forum | 19% | 416
Twitter or other microblogging platform | 12% | 267
instant messaging (IM) like XMPP/Jabber | 19% | 413
StackOverflow[2] | 17% | 367
........................................|.....................
other (please specify) | 7% | 154
--------------------------------------------------------------
Total respondents | 2148 / 2082
Respondents who skipped this question | 1371
==============================================================
Footnotes:
~~~~~~~~~~
[1] Here I mainly meant asking a question on one's blog, and waiting
for response in comments, like e.g.
http://jjnapiorkowski.vox.com/library/post/migrating-to-git-from-subversion.html
or asking on Git Wiki (as if it was help forum), or on Talk page
of some other wiki (no example).
[2] StackOverflow is a community driven programming-related Q&A site
http://stackoverflow.com/questions/tagged/git
Most used 'channel' is to simply ask somebody better versed in Git
personally (58%), then is #git channel with usually fast real-time
response (31%). Git mailing list has only 12% of replies, below
(quite new) forums and project mailing lists (19% - wide category),
instant messaging (19%), and quite new StackOverflow (17%), and very
similar to microblogging platforms such as Twitter or Identi.ca (also
12%).
"Git for Human Beings" Google Group is rarely used, with only 2% of
responses...
As for "other (please specify)" response:
* There are some responses ("Internet search", "Google", a book) that
show that it was not entirely clear that the question was about
asking _other people_ for help regarding Git, not searching for help
oneself.
* Some responses (e.g. "colleagues") were variant of provided channel.
* Some responses were more detailed specification (description) of
channel used; examples include "#dri-devel on freenode",
"Rick (friend)", "IRC (channel of project using git)",
"Rotating my chair and asking", etc.
* And there were channels that were not included in the list of
provided answers (some because channel is rare, some because I
didn't think of such channel):
- GitHub mailing list / GitHub Google Group
- asking a guy who gave a talk about git at a conference
- messages through GitHub
- private email
- direct email with tutorial author
- msysGit mailing list / msysGit Google Group
- Server Fault (but Stack Overflow is on list)
- Specialists at the work office
Perhaps this question should be about all kinds of getting help, not
only about requesting (asking for) Git-related help? What do you
think?
When doing this analysis I have realized that we have survey question
about _requesting help_, but we don't have question about _providing
help_. Do you participate in Git mailing list? Are you present on
#git channel on FreeNode (or other IRC channel) and reply to
questions? Or perhaps you are editing Git Wiki (or at least remove
spam)? Do you post responses (answers) to questions tagged [git] on
Stack Overflow (and Server Fault and Superuser)? Are you considered
to be Git guru and/or go-to guy in questions related to Git by your
colleagues or/and co-workers?
The next question is a bit related, but is only about using specified
channels, which can include providing help in given channel, but
doesn't need to.
28) Which communication channel(s) do you use?
Do you read the mailing list, or watch IRC channel?
(Choice - Multiple answers)
==============================================================
Channel | resp [%] | resp [n]
--------------------------------------------------------------
git@vger.kernel.org (main) | 42% | 368
Git for Human Beings (Google Group) | 7% | 64
msysGit | 10% | 89
#git IRC channel | 54% | 473
#github or #gitorious IRC channel | 22% | 188
#revctrl IRC channel | 0% | 4
--------------------------------------------------------------
Total respondents | 868
Respondents who skipped this question | 2651
==============================================================
Note that percentage is relative to the (small) number of replies to
this question, not relative to the number of all responders.
Among listed channels, most commonly used are #git IRC channel on
FreeNode with 54%, and git mailing list (git@vger,kernel.org) with
42%. Third is #github and #gitorious IRC channels together, with 22%
or replies to this question.
--
Jakub Narebski
Git User's Survey will last till 15 September
http://tinyurl.comGitSurvey2009
^ permalink raw reply
* Re: [StGit PATCH] Import git show output easily
From: Catalin Marinas @ 2009-09-02 20:54 UTC (permalink / raw)
To: Gustav Hållberg; +Cc: Karl Hasselström, git
In-Reply-To: <a1e915350909021351l315358a0s9d8c076440bc0fb7@mail.gmail.com>
2009/9/2 Gustav Hållberg <gustav@gmail.com>:
> It would really rock if stg import could handle the regular patch "-p<N>" flag.
> In particular, I miss -p0 as some broken versioning systems default to
> such output.
It's probably just a matter of passing the right flag to git-apply.
I'll try to have a look before -rc3.
--
Catalin
^ permalink raw reply
* Re: [StGit PATCH] Import git show output easily
From: Gustav Hållberg @ 2009-09-02 20:51 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Hasselström, git
In-Reply-To: <20090902175039.21633.25294.stgit@pc1117.cambridge.arm.com>
Somewhat related:
It would really rock if stg import could handle the regular patch "-p<N>" flag.
In particular, I miss -p0 as some broken versioning systems default to
such output.
- Gustav
^ permalink raw reply
* [PATCHv2] git-config: Parse config files leniently
From: Michael J Gruber @ 2009-09-02 20:17 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vvdkmte4p.fsf@alter.siamese.dyndns.org>
Currently, git config dies as soon as there is a parsing error. This is
especially unfortunate in case a user tries to correct config mistakes
using git config -e.
Instead, issue a warning only and treat the rest of the line as a
comment (ignore it). This benefits not only git config -e users but
also everyone else.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Reported-by: David Reitter <david.reitter@gmail.com>
---
config.c | 80 ++++++++++++++++++++++++----------------------
t/t1303-wacky-config.sh | 3 +-
2 files changed, 44 insertions(+), 39 deletions(-)
So, after a business trip, vacation, ... I'm finally returning to this patch.
I addressed the echo/printf issue as suggested and clarified the commit message.
Regarding the global int for switching on/off lenient parsing: I reinstated my
v0 of the patch only to find out (again) that setup_git_directory_gently is the
problem here. We would have to turn on lenient parsing before we even know that
"-e" is supplied. So, the only option would be to have "git config" use lenient
parsing in all modes (edit/get/set) and have other git commands die fatally on
erroneous config.
So, here's v2 which has lenient config parsing for everyone because I don't see
a way to have it for "git config -e" only. If you prefer to have it for all of
"git config" only, that version is in another branch head now...
Cheers,
Michael
diff --git a/config.c b/config.c
index e87edea..5e0af5d 100644
--- a/config.c
+++ b/config.c
@@ -207,50 +207,54 @@ static int git_parse_file(config_fn_t fn, void *data)
static const unsigned char *utf8_bom = (unsigned char *) "\xef\xbb\xbf";
const unsigned char *bomptr = utf8_bom;
- for (;;) {
- int c = get_next_char();
- if (bomptr && *bomptr) {
- /* We are at the file beginning; skip UTF8-encoded BOM
- * if present. Sane editors won't put this in on their
- * own, but e.g. Windows Notepad will do it happily. */
- if ((unsigned char) c == *bomptr) {
- bomptr++;
+ while (!config_file_eof) {
+ for (;;) {
+ int c = get_next_char();
+ if (bomptr && *bomptr) {
+ /* We are at the file beginning; skip UTF8-encoded BOM
+ * if present. Sane editors won't put this in on their
+ * own, but e.g. Windows Notepad will do it happily. */
+ if ((unsigned char) c == *bomptr) {
+ bomptr++;
+ continue;
+ } else {
+ /* Do not tolerate partial BOM. */
+ if (bomptr != utf8_bom)
+ break;
+ /* No BOM at file beginning. Cool. */
+ bomptr = NULL;
+ }
+ }
+ if (c == '\n') {
+ if (config_file_eof)
+ return 0;
+ comment = 0;
continue;
- } else {
- /* Do not tolerate partial BOM. */
- if (bomptr != utf8_bom)
+ }
+ if (comment || isspace(c))
+ continue;
+ if (c == '#' || c == ';') {
+ comment = 1;
+ continue;
+ }
+ if (c == '[') {
+ baselen = get_base_var(var);
+ if (baselen <= 0)
break;
- /* No BOM at file beginning. Cool. */
- bomptr = NULL;
+ var[baselen++] = '.';
+ var[baselen] = 0;
+ continue;
}
- }
- if (c == '\n') {
- if (config_file_eof)
- return 0;
- comment = 0;
- continue;
- }
- if (comment || isspace(c))
- continue;
- if (c == '#' || c == ';') {
- comment = 1;
- continue;
- }
- if (c == '[') {
- baselen = get_base_var(var);
- if (baselen <= 0)
+ if (!isalpha(c))
+ break;
+ var[baselen] = tolower(c);
+ if (get_value(fn, data, var, baselen+1) < 0)
break;
- var[baselen++] = '.';
- var[baselen] = 0;
- continue;
}
- if (!isalpha(c))
- break;
- var[baselen] = tolower(c);
- if (get_value(fn, data, var, baselen+1) < 0)
- break;
+ warning("bad config file line %d in %s", config_linenr, config_file_name);
+ comment = 1;
}
- die("bad config file line %d in %s", config_linenr, config_file_name);
+ return -1;
}
static int parse_unit_factor(const char *end, unsigned long *val)
diff --git a/t/t1303-wacky-config.sh b/t/t1303-wacky-config.sh
index 080117c..0599d9f 100755
--- a/t/t1303-wacky-config.sh
+++ b/t/t1303-wacky-config.sh
@@ -44,7 +44,8 @@ LONG_VALUE=$(printf "x%01021dx a" 7)
test_expect_success 'do not crash on special long config line' '
setup &&
git config section.key "$LONG_VALUE" &&
- check section.key "fatal: bad config file line 2 in .git/config"
+ check section.key "warning: bad config file line 2 in .git/config
+warning: bad config file line 2 in .git/config"
'
test_done
--
1.6.4.2.395.ge3d52
^ permalink raw reply related
* Re: diff-files inconsistency with touched files
From: Jeff King @ 2009-09-02 19:28 UTC (permalink / raw)
To: James Spencer; +Cc: git
In-Reply-To: <4A9EAAF3.3000002@cam.ac.uk>
On Wed, Sep 02, 2009 at 06:27:15PM +0100, James Spencer wrote:
> $ git diff-files
> $ touch test
> $ git diff-files
> :100644 100644 9daeafb9864cf43055ae93beb0afd6c7d144bfa4
> 0000000000000000000000000000000000000000 M test
> $ git diff
> $ git diff-files
> $
>
> I don't understand why git diff-files reports a file is changed when
> that file is touched nor why running git diff changes this to (what I
> think is) the correct behaviour.
Git uses the stat information of a file to know whether what we have
cached in the index is up-to-date or not. So in the first diff-files, we
don't even have to look at the contents of "test"; we see that it hasn't
changed since the last time we looked at the contents, and that its
sha-1 matches what's in the index, so there is no diff.
By running "touch", you have changed the stat information, so we believe
there may be a difference. But we don't actually know what's _in_ the
new side, so we just print the null sha1 instead of the actual sha1
contents.
Diff-files _could_ refresh the cache each time it runs, but we
intentionally do not do that. Doing so is a little bit expensive, and
because diff-files is intended as a low-level tool for scripts, we give
the script the flexibility (and responsibility) of refreshing the cache
when it wants to. So you could do:
$ git update-index --refresh
$ git diff-files
and get clean output.
You see different behavior from "git diff" because it is meant for user
consumption and therefore refreshes the cache automatically at the
beginning of every run.
-Peff
^ permalink raw reply
* Re: [PATCH v2] status: list unmerged files last
From: Johannes Sixt @ 2009-09-02 19:19 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Jeff King, bill lam, git
In-Reply-To: <20090902100730.GA18226@gmail.com>
On Mittwoch, 2. September 2009, David Aguilar wrote:
> No one has suggested this, so I figured I would.
> What do you think about this layout?
>
> - untracked
> - staged
> - modified
> - unmerged
You forget that these things also appear in the commit message editor. In that
location, the important things must be at the *top*.
We can freely move the list of unmerged files because it will not appear in
the commit message editor. The current order of the other lists is sane, IMO.
-- Hannes
^ permalink raw reply
* Re: [PATCH v2] status: list unmerged files last
From: Mark Brown @ 2009-09-02 18:39 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090902180050.GB5998@coredump.intra.peff.net>
On Wed, Sep 02, 2009 at 02:00:50PM -0400, Jeff King wrote:
> Yeah, we already have --untracked-files=<no|normal|all> and a matching
> config variable. If there are cases people find useful, I don't see a
> reason why we can't make other sections configurable, too. I think it
> just somebody to write a patch for the behavior they think makes sense
> (or at the very least a concrete proposal).
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.
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #06; Sun, 30)
From: Peter Harris @ 2009-09-02 18:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vtyzmliai.fsf@alter.siamese.dyndns.org>
On Tue, Sep 1, 2009 at 12:51 PM, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> There is replacement series sent to git mailing list a little while
>> ago.
>
> Thanks; I've replaced and pushed them out on 'pu' for now. Will hopefully
> start merging earlier parts to 'next', but how widely is Hires available?
It was added to the Perl core in 5.8. Gitweb already depends on 5.8,
according to http://article.gmane.org/gmane.comp.version-control.git/83339
Peter Harris
^ permalink raw reply
* [JGIT PATCH 1/2] fixed error in whitespace handling of RefDatabase#readLine
From: Mark Struberg @ 2009-09-02 18:00 UTC (permalink / raw)
To: git, spearce; +Cc: Mark Struberg
jgit fails with "cannot checkout; no HEAD advertised by remote"
in guessHEAD on some repositories.
JGIT used to work on my test repo for the maven-scm-providers-git until a few weeks.
I tracked it down with git bisect and found commit
72b1f0d334729a49cc52e4762093148be62bea39 to be the bad one.
I glimpsed at the code and it appears that the new code in
RefDatabase#readLine is not Windows CR+LF aware.
(This hits me although I use Linux because our SVN at
apache.org seems to have it stored with CR+LF.)
Fixed by subsequently removing all Character.isWhitespaceChar() from the end of the buffer
Signed-off-by: Mark Struberg <struberg@yahoo.de>
---
.../src/org/spearce/jgit/lib/RefDatabase.java | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java b/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
index ba4b654..477dc62 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
@@ -500,8 +500,12 @@ private static String readLine(final File file)
int n = buf.length;
if (n == 0)
return null;
- if (buf[n - 1] == '\n')
+
+ // remove trailing whitespaces
+ while (n > 0 && Character.isWhitespace(buf[n - 1])) {
n--;
+ }
+
return RawParseUtils.decode(buf, 0, n);
}
--
1.6.2.5
^ permalink raw reply related
* [JGIT PATCH 2/2] improve the handling of empty lines
From: Mark Struberg @ 2009-09-02 18:00 UTC (permalink / raw)
To: git, spearce; +Cc: Mark Struberg
In-Reply-To: <1251914428-1687-1-git-send-email-struberg@yahoo.de>
Move the 'empty-line' check in RefDatabase#readLine down a bit after we removed all the whitespaces.
This way we consistently return null regardless if the line
is empty or if it does only contain whitespaces.
Signed-off-by: Mark Struberg <struberg@yahoo.de>
---
.../src/org/spearce/jgit/lib/RefDatabase.java | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java b/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
index 477dc62..acc835b 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
@@ -498,14 +498,15 @@ private static String readLine(final File file)
throws FileNotFoundException, IOException {
final byte[] buf = NB.readFully(file, 4096);
int n = buf.length;
- if (n == 0)
- return null;
// remove trailing whitespaces
while (n > 0 && Character.isWhitespace(buf[n - 1])) {
n--;
}
-
+
+ if (n == 0)
+ return null;
+
return RawParseUtils.decode(buf, 0, n);
}
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH v2] status: list unmerged files last
From: Jeff King @ 2009-09-02 18:00 UTC (permalink / raw)
To: Mark Brown; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090902124832.GC4012@sirena.org.uk>
On Wed, Sep 02, 2009 at 01:48:32PM +0100, Mark Brown wrote:
> It would be nice to be able to explicitly ask to suppress some of the
> output for cases where there's a lot of it and only a small part is
> interesting (like when resolving a large merge as mentioned earlier) - I
> often end up doing this by hand in those situations. I do agree that
> doing this by default would be surprising.
Yeah, we already have --untracked-files=<no|normal|all> and a matching
config variable. If there are cases people find useful, I don't see a
reason why we can't make other sections configurable, too. I think it
just somebody to write a patch for the behavior they think makes sense
(or at the very least a concrete proposal).
-Peff
^ permalink raw reply
* Re: [PATCH v2] status: list unmerged files last
From: Jeff King @ 2009-09-02 17:59 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090902100730.GA18226@gmail.com>
On Wed, Sep 02, 2009 at 03:07:32AM -0700, David Aguilar wrote:
> I agree with all of this but would also add that we can have
> our cake and eat it too with respect to wanting to "keep
> similar things together" and having "unmerged near bottom".
Well, my point was that the "bottom" is not really cake, but I am not
sure anyone else agrees.
> No one has suggested this, so I figured I would.
> What do you think about this layout?
>
> - untracked
> - staged
> - modified
> - unmerged
What about the current branch? Alternate author info? Tracking branch
relationship? Should those be at the top or bottom?
I dunno. Maybe it is just me being crotchety and hating change, but I
like the current order (though swapping it below "updated" is fine with
me).
> While I've got you guys.. I have a patch for the new 1.7
> status that makes it:
>
> git status [<tree-ish>] [--] [pathspec]
> (it adds support for tree-ish)
>
> I added that because I thought that the porcelain-ish short
> status output could be useful for "what does commit --amend
> do" from a script-writers' pov, and thus adding <tree-ish>
> enables git status -s HEAD^.
If you want to know "what does commit --amend do", then shouldn't you be
using "git commit --amend --dry-run" (which is what "git status" is now,
but will not be in v1.7.0)?
Are there other uses cases for arbitrary tree-ish's?
> BTW is status -s intended to be something plumbing-like;
> something we can build upon and expect to be stable?
> I'm just curious because other commands have a --porcelain
> option and I wasn't sure if this was the intent.
We mentioned a --porcelain option in other discussion, but I don't think
there is a patch. I would be in favor of --porcelain, even if it is
currently identical to --short, because then it gives us freedom to
diverge later (and in particular it gives us the freedom to let user
configuration affect what is shown).
-Peff
^ 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