* [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
* [PATCH v6 6/6] fast-import: test the new option command
From: Sverre Rabbelier @ 2009-09-02 17:57 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, Git List,
Ian Clatworthy <ian.cla
Cc: Sverre Rabbelier
In-Reply-To: <1251914223-31435-6-git-send-email-srabbelier@gmail.com>
Test three options (quiet and import/export-marks) and verify that the
commandline options override these.
Also make sure that a option command without a preceeding feature
git-options command is rejected and that non-git options are ignored.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
Tests updated to match the new 'option git' syntax. Also added a
test to ensure that an option command without a preceeding 'feature
git-options' is rejected and that non-git options are ignored.
t/t9300-fast-import.sh | 84 +++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 83 insertions(+), 1 deletions(-)
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 564ed6b..fb795bb 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -1089,7 +1089,7 @@ test_expect_success 'P: fail on blob mark in gitlink' '
test_must_fail git fast-import <input'
###
-### series R (feature)
+### series R (feature and option)
###
cat >input <<EOF
@@ -1108,4 +1108,86 @@ test_expect_success 'R: supported feature is accepted' '
git fast-import <input
'
+cat >input << EOF
+feature git-options
+option git quiet
+blob
+data 3
+hi
+
+EOF
+
+touch empty
+
+test_expect_success 'R: quiet option results in no stats being output' '
+ cat input | git fast-import 2> output &&
+ test_cmp empty output
+'
+
+cat >input << EOF
+feature git-options
+option git export-marks=git.marks
+blob
+mark :1
+data 3
+hi
+
+EOF
+
+test_expect_success \
+ 'R: export-marks option results in a marks file being created' \
+ 'cat input | git fast-import &&
+ grep :1 git.marks'
+
+test_expect_success \
+ 'R: export-marks options can be overriden by commandline options' \
+ 'cat input | git fast-import --export-marks=other.marks &&
+ grep :1 other.marks'
+
+cat >input << EOF
+feature git-options
+option git import-marks=marks.out
+option git export-marks=marks.new
+EOF
+
+test_expect_success \
+ 'R: import to output marks works without any content' \
+ 'cat input | git fast-import &&
+ test_cmp marks.out marks.new'
+
+cat >input <<EOF
+feature git-options
+option git import-marks=nonexistant.marks
+option git export-marks=marks.new
+EOF
+
+test_expect_success \
+ 'R: import marks uses the commandline marks file when the stream specifies one' \
+ 'cat input | git fast-import --import-marks=marks.out &&
+ test_cmp marks.out marks.new'
+
+cat >input <<EOF
+feature git-options
+EOF
+
+test_expect_success 'R: feature option is accepted' '
+ git fast-import <input
+'
+
+cat >input <<EOF
+option git quiet
+EOF
+
+test_expect_success \
+ 'R: option without preceeding feature command is rejected' \
+ 'test_must_fail git fast-import <input'
+
+cat >input <<EOF
+option non-existing-vcs non-existing-option
+EOF
+
+test_expect_success 'R: ignore non-git options' '
+ git fast-import <input
+'
+
test_done
--
1.6.4.16.g72c66.dirty
^ permalink raw reply related
* [PATCH v6 5/6] fast-import: add option command
From: Sverre Rabbelier @ 2009-09-02 17:57 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, Git List,
Ian Clatworthy <ian.cla
Cc: Sverre Rabbelier
In-Reply-To: <1251914223-31435-5-git-send-email-srabbelier@gmail.com>
This allows the frontend to specify any of the supported options as
long as no non-option command has been given. This way the
user does not have to include any frontend-specific options, but
instead she can rely on the frontend to tell fast-import what it
needs.
Also factor out parsing of argv and have it execute when we reach the
first non-option command, or after all commands have been read and
no non-option command has been encountered.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
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.
Documentation/git-fast-import.txt | 24 ++++++++++++
fast-import.c | 75 +++++++++++++++++++++++++++++++------
2 files changed, 87 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 1e293f2..f1c94b4 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -307,6 +307,11 @@ and control the current import process. More detailed discussion
Require that fast-import supports the specified feature, or
abort if it does not.
+`option`::
+ Specify any of the options listed under OPTIONS to change
+ fast-import's behavior to suit the frontend's needs. This command
+ is optional and is not needed to perform an import.
+
`commit`
~~~~~~~~
Create or update a branch with a new commit, recording one logical
@@ -829,6 +834,25 @@ it does not.
The <feature> part of the command may be any string matching
[a-zA-Z-] and should be understood by a version of fast-import.
+`option`
+~~~~~~~~
+Processes the specified option so that git fast-import behaves in a
+way that suits the frontend's needs.
+Note that options specified by the frontend are overridden by any
+options the user may specify to git fast-import itself.
+
+....
+ 'option' SP <option> LF
+....
+
+The `<option>` part of the command may contain any of the options
+listed in the OPTIONS section, without the leading '--' and is
+treated in the same way.
+
+Option commands must be the first commands on the input (not counting
+feature commands), to give an option command after any non-option
+command is an error.
+
Crash Reports
-------------
If fast-import is supplied invalid input it will terminate with a
diff --git a/fast-import.c b/fast-import.c
index 9bf06a4..bad93dc 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -292,6 +292,8 @@ static unsigned long branch_load_count;
static int failure;
static FILE *pack_edges;
static unsigned int show_stats = 1;
+static int global_argc;
+static const char **global_argv;
/* Memory pools */
static size_t mem_pool_alloc = 2*1024*1024 - sizeof(struct mem_pool);
@@ -349,6 +351,10 @@ static struct recent_command *rc_free;
static unsigned int cmd_save = 100;
static uintmax_t next_mark;
static struct strbuf new_data = STRBUF_INIT;
+static int options_enabled;
+static int seen_non_option_command;
+
+static void parse_argv(void);
static void write_branch_report(FILE *rpt, struct branch *b)
{
@@ -1700,6 +1706,12 @@ static int read_next_command(void)
if (stdin_eof)
return EOF;
+ if (!seen_non_option_command
+ && prefixcmp(command_buf.buf, "feature ")
+ && prefixcmp(command_buf.buf, "option ")) {
+ parse_argv();
+ }
+
rc = rc_free;
if (rc)
rc_free = rc->next;
@@ -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;
+
+ 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
+}
+
static int git_pack_config(const char *k, const char *v, void *cb)
{
if (!strcmp(k, "pack.depth")) {
@@ -2485,6 +2517,26 @@ static int git_pack_config(const char *k, const char *v, void *cb)
static const char fast_import_usage[] =
"git fast-import [--date-format=f] [--max-pack-size=n] [--depth=n] [--active-branches=n] [--export-marks=marks.file]";
+static void parse_argv(void)
+{
+ unsigned int i;
+
+ for (i = 1; i < global_argc; i++) {
+ const char *a = global_argv[i];
+
+ if (*a != '-' || !strcmp(a, "--"))
+ break;
+
+ parse_one_option(a + 2);
+ }
+ if (i != global_argc)
+ usage(fast_import_usage);
+
+ seen_non_option_command = 1;
+ if (input_file)
+ read_marks();
+}
+
int main(int argc, const char **argv)
{
unsigned int i;
@@ -2503,18 +2555,8 @@ int main(int argc, const char **argv)
avail_tree_table = xcalloc(avail_tree_table_sz, sizeof(struct avail_tree_content*));
marks = pool_calloc(1, sizeof(struct mark_set));
- for (i = 1; i < argc; i++) {
- const char *a = argv[i];
-
- if (*a != '-' || !strcmp(a, "--"))
- break;
-
- parse_one_option(a + 2);
- }
- if (i != argc)
- usage(fast_import_usage);
- if (input_file)
- read_marks();
+ global_argc = argc;
+ global_argv = argv;
rc_free = pool_alloc(cmd_save * sizeof(*rc_free));
for (i = 0; i < (cmd_save - 1); i++)
@@ -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
+ if (!seen_non_option_command)
+ parse_argv();
+
end_packfile();
dump_branches();
--
1.6.4.16.g72c66.dirty
^ permalink raw reply related
* [PATCH v6 4/6] fast-import: test the new feature command
From: Sverre Rabbelier @ 2009-09-02 17:57 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, Git List,
Ian Clatworthy <ian.cla
Cc: Sverre Rabbelier
In-Reply-To: <1251914223-31435-4-git-send-email-srabbelier@gmail.com>
Test that an unknown feature causes fast-import to abort, and that a
known feature is accepted.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
t/t9300-fast-import.sh | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 821be7c..564ed6b 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -1088,4 +1088,24 @@ INPUT_END
test_expect_success 'P: fail on blob mark in gitlink' '
test_must_fail git fast-import <input'
+###
+### series R (feature)
+###
+
+cat >input <<EOF
+feature no-such-feature-exists
+EOF
+
+test_expect_success 'R: abort on unsupported feature' '
+ test_must_fail git fast-import <input
+'
+
+cat >input <<EOF
+feature date-format=now
+EOF
+
+test_expect_success 'R: supported feature is accepted' '
+ git fast-import <input
+'
+
test_done
--
1.6.4.16.g72c66.dirty
^ permalink raw reply related
* [PATCH v6 2/6] fast-import: put marks reading in it's own function
From: Sverre Rabbelier @ 2009-09-02 17:56 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, Git List,
Ian Clatworthy <ian.cla
Cc: Sverre Rabbelier
In-Reply-To: <1251914223-31435-2-git-send-email-srabbelier@gmail.com>
All options do nothing but set settings, with the exception of the
--input-marks option. Delay the reading of the marks file till after
all options have been parsed.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
No change since v5.
fast-import.c | 73 ++++++++++++++++++++++++++++++++-------------------------
1 files changed, 41 insertions(+), 32 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index b904f20..812fcf0 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -315,6 +315,7 @@ static struct object_entry_pool *blocks;
static struct object_entry *object_table[1 << 16];
static struct mark_set *marks;
static const char *mark_file;
+static const char *input_file;
/* Our last blob */
static struct last_object last_blob = { STRBUF_INIT, 0, 0, 0 };
@@ -1643,6 +1644,42 @@ static void dump_marks(void)
}
}
+static void read_marks(void)
+{
+ char line[512];
+ FILE *f = fopen(input_file, "r");
+ if (!f)
+ die_errno("cannot read '%s'", input_file);
+ while (fgets(line, sizeof(line), f)) {
+ uintmax_t mark;
+ char *end;
+ unsigned char sha1[20];
+ struct object_entry *e;
+
+ end = strchr(line, '\n');
+ if (line[0] != ':' || !end)
+ die("corrupt mark line: %s", line);
+ *end = 0;
+ mark = strtoumax(line + 1, &end, 10);
+ if (!mark || end == line + 1
+ || *end != ' ' || get_sha1(end + 1, sha1))
+ die("corrupt mark line: %s", line);
+ e = find_object(sha1);
+ if (!e) {
+ enum object_type type = sha1_object_info(sha1, NULL);
+ if (type < 0)
+ die("object not found: %s", sha1_to_hex(sha1));
+ e = insert_object(sha1);
+ e->type = type;
+ e->pack_id = MAX_PACK_ID;
+ e->offset = 1; /* just not zero! */
+ }
+ insert_mark(mark, e);
+ }
+ fclose(f);
+}
+
+
static int read_next_command(void)
{
static int stdin_eof = 0;
@@ -2338,39 +2375,9 @@ static void parse_progress(void)
skip_optional_lf();
}
-static void option_import_marks(const char *input_file)
+static void option_import_marks(const char *marks)
{
- char line[512];
- FILE *f = fopen(input_file, "r");
- if (!f)
- die_errno("cannot read '%s'", input_file);
- while (fgets(line, sizeof(line), f)) {
- uintmax_t mark;
- char *end;
- unsigned char sha1[20];
- struct object_entry *e;
-
- end = strchr(line, '\n');
- if (line[0] != ':' || !end)
- die("corrupt mark line: %s", line);
- *end = 0;
- mark = strtoumax(line + 1, &end, 10);
- if (!mark || end == line + 1
- || *end != ' ' || get_sha1(end + 1, sha1))
- die("corrupt mark line: %s", line);
- e = find_object(sha1);
- if (!e) {
- enum object_type type = sha1_object_info(sha1, NULL);
- if (type < 0)
- die("object not found: %s", sha1_to_hex(sha1));
- e = insert_object(sha1);
- e->type = type;
- e->pack_id = MAX_PACK_ID;
- e->offset = 1; /* just not zero! */
- }
- insert_mark(mark, e);
- }
- fclose(f);
+ input_file = xstrdup(marks);
}
static void option_date_format(const char *fmt)
@@ -2495,6 +2502,8 @@ int main(int argc, const char **argv)
}
if (i != argc)
usage(fast_import_usage);
+ if (input_file)
+ read_marks();
rc_free = pool_alloc(cmd_save * sizeof(*rc_free));
for (i = 0; i < (cmd_save - 1); i++)
--
1.6.4.16.g72c66.dirty
^ permalink raw reply related
* [PATCH v6 3/6] fast-import: add feature command
From: Sverre Rabbelier @ 2009-09-02 17:57 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, Git List,
Ian Clatworthy <ian.cla
Cc: Sverre Rabbelier
In-Reply-To: <1251914223-31435-3-git-send-email-srabbelier@gmail.com>
This allows the fronted to require a specific feature to be supported
by the frontend, or abort.
Also add support for the first feature, date-format=.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
No longer RFC.
Documentation/git-fast-import.txt | 16 ++++++++++++++++
fast-import.c | 13 +++++++++++++
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index c2f483a..1e293f2 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -303,6 +303,10 @@ and control the current import process. More detailed discussion
standard output. This command is optional and is not needed
to perform an import.
+`feature`::
+ Require that fast-import supports the specified feature, or
+ abort if it does not.
+
`commit`
~~~~~~~~
Create or update a branch with a new commit, recording one logical
@@ -813,6 +817,18 @@ Placing a `progress` command immediately after a `checkpoint` will
inform the reader when the `checkpoint` has been completed and it
can safely access the refs that fast-import updated.
+`feature`
+~~~~~~~~~
+Require that fast-import supports the specified feature, or abort if
+it does not.
+
+....
+ 'feature' SP <feature> LF
+....
+
+The <feature> part of the command may be any string matching
+[a-zA-Z-] and should be understood by a version of fast-import.
+
Crash Reports
-------------
If fast-import is supplied invalid input it will terminate with a
diff --git a/fast-import.c b/fast-import.c
index 812fcf0..9bf06a4 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2450,6 +2450,17 @@ static void parse_one_option(const char *option)
}
}
+static void parse_feature(void)
+{
+ char *feature = command_buf.buf + 8;
+
+ if (!prefixcmp(feature, "date-format=")) {
+ option_date_format(feature + 12);
+ } else {
+ die("This version of fast-import does not support feature %s.", feature);
+ }
+}
+
static int git_pack_config(const char *k, const char *v, void *cb)
{
if (!strcmp(k, "pack.depth")) {
@@ -2526,6 +2537,8 @@ int main(int argc, const char **argv)
parse_checkpoint();
else if (!prefixcmp(command_buf.buf, "progress "))
parse_progress();
+ else if (!prefixcmp(command_buf.buf, "feature "))
+ parse_feature();
else
die("Unsupported command: %s", command_buf.buf);
}
--
1.6.4.16.g72c66.dirty
^ permalink raw reply related
* [PATCH v6 1/6] fast-import: put option parsing code in separate functions
From: Sverre Rabbelier @ 2009-09-02 17:56 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, Git List,
Ian Clatworthy <ian.cla
Cc: Sverre Rabbelier
In-Reply-To: <1251914223-31435-1-git-send-email-srabbelier@gmail.com>
Putting the options in their own functions increases readability of
the option parsing block and makes it easier to reuse the option
parsing code later on.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
No change since v5.
fast-import.c | 115 +++++++++++++++++++++++++++++++++++++--------------------
1 files changed, 75 insertions(+), 40 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 7ef9865..b904f20 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -291,6 +291,7 @@ static unsigned long branch_count;
static unsigned long branch_load_count;
static int failure;
static FILE *pack_edges;
+static unsigned int show_stats = 1;
/* Memory pools */
static size_t mem_pool_alloc = 2*1024*1024 - sizeof(struct mem_pool);
@@ -2337,7 +2338,7 @@ static void parse_progress(void)
skip_optional_lf();
}
-static void import_marks(const char *input_file)
+static void option_import_marks(const char *input_file)
{
char line[512];
FILE *f = fopen(input_file, "r");
@@ -2372,6 +2373,76 @@ static void import_marks(const char *input_file)
fclose(f);
}
+static void option_date_format(const char *fmt)
+{
+ if (!strcmp(fmt, "raw"))
+ whenspec = WHENSPEC_RAW;
+ else if (!strcmp(fmt, "rfc2822"))
+ whenspec = WHENSPEC_RFC2822;
+ else if (!strcmp(fmt, "now"))
+ whenspec = WHENSPEC_NOW;
+ else
+ die("unknown --date-format argument %s", fmt);
+}
+
+static void option_max_pack_size(const char *packsize)
+{
+ max_packsize = strtoumax(packsize, NULL, 0) * 1024 * 1024;
+}
+
+static void option_depth(const char *depth)
+{
+ max_depth = strtoul(depth, NULL, 0);
+ if (max_depth > MAX_DEPTH)
+ die("--depth cannot exceed %u", MAX_DEPTH);
+}
+
+static void option_active_branches(const char *branches)
+{
+ max_active_branches = strtoul(branches, NULL, 0);
+}
+
+static void option_export_marks(const char *marks)
+{
+ mark_file = xstrdup(marks);
+}
+
+static void option_export_pack_edges(const char *edges)
+{
+ if (pack_edges)
+ fclose(pack_edges);
+ pack_edges = fopen(edges, "a");
+ if (!pack_edges)
+ die_errno("Cannot open '%s'", edges);
+}
+
+static void parse_one_option(const char *option)
+{
+ if (!prefixcmp(option, "date-format=")) {
+ option_date_format(option + 12);
+ } else if (!prefixcmp(option, "max-pack-size=")) {
+ option_max_pack_size(option + 14);
+ } else if (!prefixcmp(option, "depth=")) {
+ option_depth(option + 6);
+ } else if (!prefixcmp(option, "active-branches=")) {
+ option_active_branches(option + 16);
+ } else if (!prefixcmp(option, "import-marks=")) {
+ option_import_marks(option + 13);
+ } else if (!prefixcmp(option, "export-marks=")) {
+ option_export_marks(option + 13);
+ } else if (!prefixcmp(option, "export-pack-edges=")) {
+ option_export_pack_edges(option + 18);
+ } else if (!prefixcmp(option, "force")) {
+ force_update = 1;
+ } else if (!prefixcmp(option, "quiet")) {
+ show_stats = 0;
+ } else if (!prefixcmp(option, "stats")) {
+ show_stats = 1;
+ } else {
+ die("Unsupported option: %s", option);
+ }
+}
+
static int git_pack_config(const char *k, const char *v, void *cb)
{
if (!strcmp(k, "pack.depth")) {
@@ -2398,7 +2469,7 @@ static const char fast_import_usage[] =
int main(int argc, const char **argv)
{
- unsigned int i, show_stats = 1;
+ unsigned int i;
git_extract_argv0_path(argv[0]);
@@ -2419,44 +2490,8 @@ int main(int argc, const char **argv)
if (*a != '-' || !strcmp(a, "--"))
break;
- else if (!prefixcmp(a, "--date-format=")) {
- const char *fmt = a + 14;
- if (!strcmp(fmt, "raw"))
- whenspec = WHENSPEC_RAW;
- else if (!strcmp(fmt, "rfc2822"))
- whenspec = WHENSPEC_RFC2822;
- else if (!strcmp(fmt, "now"))
- whenspec = WHENSPEC_NOW;
- else
- die("unknown --date-format argument %s", fmt);
- }
- else if (!prefixcmp(a, "--max-pack-size="))
- max_packsize = strtoumax(a + 16, NULL, 0) * 1024 * 1024;
- else if (!prefixcmp(a, "--depth=")) {
- max_depth = strtoul(a + 8, NULL, 0);
- if (max_depth > MAX_DEPTH)
- die("--depth cannot exceed %u", MAX_DEPTH);
- }
- else if (!prefixcmp(a, "--active-branches="))
- max_active_branches = strtoul(a + 18, NULL, 0);
- else if (!prefixcmp(a, "--import-marks="))
- import_marks(a + 15);
- else if (!prefixcmp(a, "--export-marks="))
- mark_file = a + 15;
- else if (!prefixcmp(a, "--export-pack-edges=")) {
- if (pack_edges)
- fclose(pack_edges);
- pack_edges = fopen(a + 20, "a");
- if (!pack_edges)
- die_errno("Cannot open '%s'", a + 20);
- } else if (!strcmp(a, "--force"))
- force_update = 1;
- else if (!strcmp(a, "--quiet"))
- show_stats = 0;
- else if (!strcmp(a, "--stats"))
- show_stats = 1;
- else
- die("unknown option %s", a);
+
+ parse_one_option(a + 2);
}
if (i != argc)
usage(fast_import_usage);
--
1.6.4.16.g72c66.dirty
^ permalink raw reply related
* [PATCH v6 0/6] fast-import: add new feature and mark command
From: Sverre Rabbelier @ 2009-09-02 17:56 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, Git List,
Ian Clatworthy <ian.cla
Incorperated comments and changed 'option foo' to 'option git foo'. I
think this is ready to be merged to next if there are no objections.
Sverre Rabbelier (6):
fast-import: put option parsing code in separate functions
fast-import: put marks reading in it's own function
fast-import: add feature command
fast-import: test the new feature command
fast-import: add option command
fast-import: test the new option command
Documentation/git-fast-import.txt | 40 ++++++
fast-import.c | 262 ++++++++++++++++++++++++++-----------
t/t9300-fast-import.sh | 102 ++++++++++++++
3 files changed, 327 insertions(+), 77 deletions(-)
^ permalink raw reply
* Re: [PATCH] clone: disconnect transport after fetching
From: Junio C Hamano @ 2009-09-02 17:55 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Jeff King, Junio C Hamano, git, Sverre Rabbelier,
Björn Steinbrink, Matthieu Moy, Sitaram Chamarty
In-Reply-To: <alpine.LNX.2.00.0909021228570.28290@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Wed, 2 Sep 2009, Jeff King wrote:
> ...
>> Signed-off-by: Jeff King <peff@peff.net>
>> ---
>> This was suggested by Daniel, so theoretically
>>
>> Acked-by: Daniel Barkalow <barkalow@iabervon.org>
>>
>> :)
>
> This is what I intended, so:
>
> Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Thanks, both.
^ permalink raw reply
* [StGit PATCH] Import git show output easily
From: Catalin Marinas @ 2009-09-02 17:50 UTC (permalink / raw)
To: Karl Hasselström, git
This patch modifies the import command to check for standard 'git show'
output and parse it accordingly.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
---
stgit/commands/common.py | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/stgit/commands/common.py b/stgit/commands/common.py
index d38d263..0d39148 100644
--- a/stgit/commands/common.py
+++ b/stgit/commands/common.py
@@ -355,6 +355,7 @@ def __parse_description(descr):
lasthdr = 0
end = len(descr_lines)
+ descr_strip = 0
# Parse the patch header
for pos in range(0, end):
@@ -374,12 +375,16 @@ def __parse_description(descr):
if subject:
break
# get the subject
- subject = descr_lines[pos]
+ subject = descr_lines[pos][descr_strip:]
+ if re.match('commit [\da-f]{40}$', subject):
+ # 'git show' output, look for the real subject
+ subject = ''
+ descr_strip = 4
lasthdr = pos + 1
# get the body
if lasthdr < end:
- body = reduce(lambda x, y: x + '\n' + y, descr_lines[lasthdr:], '')
+ body = '\n' + '\n'.join(l[descr_strip:] for l in descr_lines[lasthdr:])
return (subject + body, authname, authemail, authdate)
^ permalink raw reply related
* Re: What's cooking in git.git (Aug 2009, #06; Sun, 30)
From: Jakub Narebski @ 2009-09-02 17:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtyzmliai.fsf@alter.siamese.dyndns.org>
On Tue, 1 Sep 2009, 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?
Well, if someone wants to have _optional_ 'timed' feature, ha/she can
install Time::HiRes module. I think that it is not in Perl core, but
there are RPM and deb packages with Time::HiRes available in extras.
If module is not installed, then only 'timed' feature is not available.
P.S. "Naming is the hardest thing"; should this feature be named 'timed',
or do any of you have some better name for it?
P.P.S. Originally the part about "time to generate page" was for me to be
able to benchmark new code... but then I realized that benchmarking
'blame_incremental' view on single-core computer, where server process
and AJAX-y JavaScript competes for CPU doesn't a good benchmark make.
Still, this part can be useful.
--
Jakub Narebski
Poland
^ permalink raw reply
* diff-files inconsistency with touched files
From: James Spencer @ 2009-09-02 17:27 UTC (permalink / raw)
To: git
Hi,
I am puzzled by the following behaviour:
$ git --version
git version 1.6.4.2
$ 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.
Thanks in advance,
--James
^ permalink raw reply
* Re: [PATCH] clone: disconnect transport after fetching
From: Daniel Barkalow @ 2009-09-02 16:38 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, git, Sverre Rabbelier, Björn Steinbrink,
Matthieu Moy, Sitaram Chamarty
In-Reply-To: <20090902063647.GA29559@coredump.intra.peff.net>
On Wed, 2 Sep 2009, Jeff King wrote:
> The current code just leaves the transport in whatever state
> it was in after performing the fetch. For a non-empty clone
> over the git protocol, the transport code already
> disconnects at the end of the fetch.
>
> But for an empty clone, we leave the connection hanging, and
> eventually close the socket when clone exits. This causes
> the remote upload-pack to complain "the remote end hung up
> unexpectedly". While this message is harmless to the clone
> itself, it is unnecessarily scary for a user to see and may
> pollute git-daemon logs.
>
> This patch just explicitly calls disconnect after we are
> done with the remote end, which sends a flush packet to
> upload-pack and cleanly disconnects, avoiding the error
> message.
>
> Other transports are unaffected or slightly improved:
>
> - for a non-empty repo over the git protocol, the second
> disconnect is a no-op (since we are no longer connected)
>
> - for "walker" transports (like HTTP or FTP), we actually
> free some used memory (which previously just sat until
> the clone process exits)
>
> - for "rsync", disconnect is always a no-op anyway
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> This was suggested by Daniel, so theoretically
>
> Acked-by: Daniel Barkalow <barkalow@iabervon.org>
>
> :)
This is what I intended, so:
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
> As you can see from the commit message, I did a little extra hunting to
> make sure we are not going to impact any other code paths, and I am
> pretty sure we are fine.
Also, builtin-fetch already does the explicit disconnect, and commonly
exercises both the "we want something" and "we don't want anything" cases,
so any problems would have to be surprisingly clone-specific.
> builtin-clone.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-clone.c b/builtin-clone.c
> index 991a7ae..0f231d8 100644
> --- a/builtin-clone.c
> +++ b/builtin-clone.c
> @@ -580,8 +580,10 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
> option_no_checkout = 1;
> }
>
> - if (transport)
> + if (transport) {
> transport_unlock_pack(transport);
> + transport_disconnect(transport);
> + }
>
> if (!option_no_checkout) {
> struct lock_file *lock_file = xcalloc(1, sizeof(struct lock_file));
> --
> 1.6.4.2.401.ga275f.dirty
>
^ 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