* Re: [RFC/PATCH v2] CodingGuidelines: add Python coding guidelines
From: Pete Wyckoff @ 2013-02-03 15:12 UTC (permalink / raw)
To: John Keeping; +Cc: Michael Haggerty, git
In-Reply-To: <20130201111634.GA2476@farnsworth.metanate.com>
john@keeping.me.uk wrote on Fri, 01 Feb 2013 11:16 +0000:
> On Fri, Feb 01, 2013 at 09:39:39AM +0100, Michael Haggerty wrote:
> > On 01/30/2013 09:31 PM, John Keeping wrote:
> > > On Wed, Jan 30, 2013 at 11:05:10AM +0100, Michael Haggerty wrote:
> > >> [...] maybe we should establish a small Python library of
> > >> compatibility utilities (like a small "six"). [...]
> > >> But I haven't had time to think of where to put such a library, how to
> > >> install it, etc.
> > >
> > > If we want to go that route, I think restructuring the
> > > "git_remote_helpers" directory and re-using its infrastructure for
> > > installing the "Git Python modules" would be the way to go. The
> > > directory structure would become something like this:
> > >
> > > git/
> > > `-- python/
> > > |-- Makefile # existing file pulled out of git_remote_helpers
> > > |-- < some new utility library >
> > > |-- git_remote_helpers
> > > | |-- __init__.py
> > > | |-- git
> > > | | |-- __init__.py
> > > | | |-- exporter.py
> > > | | |-- git.py
> > > | | |-- importer.py
> > > | | |-- non_local.py
> > > | | `-- repo.py
> > > | `-- util.py
> > > |-- setup.cfg # existing file pulled out of git_remote_helpers
> > > `-- setup.py # existing file pulled out of git_remote_helpers
> > >
> > >
> > > It looks like the GitPython project[1] as already taken the "git" module
> > > name, so perhaps we should use "git_core" if we do introduce a new
> > > module.
> > >
> > > [1] http://pypi.python.org/pypi/GitPython
> >
> > This sounds reasonable. But not all Python code will go under the
> > "python" subdirectory, right? For example, I am working on a Python
> > script that fits thematically under contrib/hooks.
>
> I was thinking of it as analagous with the "perl" directory that
> currently exists. So the "python" directory will contain library code
> but scripts can live wherever is most appropriate.
>
> One way of looking at it is: could the user want to have this installed
> for all available versions of Python? For a script, the answer is "no"
> because they will call it and it will just run. For libraries, you want
> them to be available with whatever Python interpreter you happen to be
> running (assuming that it is a version supported by the library).
>
> > OTOH (I'm thinking aloud here) it is probably a bad idea for a hook
> > script to depend on a Python module that is part of git itself. Doing
> > so would make the hook script depend on a particular version of git (or
> > at least a version with a compatible Python module). But users might be
> > reluctant to upgrade git just to install a hook script.
>
> I don't think such a dependency is a bad idea in the longer term. If a
> "Git Python library" is developed, then at some point most people who
> have Git installed will have some version of that library - it becomes a
> case of perhaps wanting to limit yourself to some subset of the library
> rather than just not using it.
>
> In fact, git_remote_helpers has been available since Git 1.7.0 and
> contains a lot of functionality that is more generic than its name
> suggests.
This library idea would be a great help; there are 100-odd calls
to git in git-p4, and we've had to deal with getting the arguments
and parsing correct. I'd happily switch to using git_core.
Probably some elements of GitPython can be used too. I'm not so
interested in the raw database manipulation, but the command
wrappers look reasonable.
-- Pete
^ permalink raw reply
* [PATCH] send-email: ignore files ending with ~
From: Alexandre Courbot @ 2013-02-03 14:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Alexandre Courbot
It certainly happened to a lot of people already: you carefully prepare
your set of patches, export them using format-patch --cover-letter,
write your cover letter, and send the set like this:
$ git send-email --to=somerenowneddeveloper --to=myfutureemployer
--cc=thismailinglistiwanttoimpress 00*
And of course since you think you know what you are doing, you just
answer 'a' at the first prompt to send all emails at once.
The next day, all these people are laughing at you because the editor
you used to write your cover letter saved a backup of the previous
version and they received two versions of it, including one containing
the familiar *** BLURB HERE *** (or potentially more humiliating stuff
if you used the buffer as a temporary scratch).
Let's save people's reputations by ignoring files ending with '~' in
send-email. There should be no reason to send such a file anyways.
Signed-off-by: Alexandre Courbot <gnurou@gmail.com>
---
git-send-email.perl | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index be809e5..4cc5855 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -548,7 +548,10 @@ while (defined(my $f = shift @ARGV)) {
sort readdir $dh;
closedir $dh;
} elsif ((-f $f or -p $f) and !check_file_rev_conflict($f)) {
- push @files, $f;
+ # Ignore backup files
+ if ($f !~ "~\$") {
+ push @files, $f;
+ }
} else {
push @rev_list_opts, $f;
}
--
1.8.1.1
^ permalink raw reply related
* [PATCH 3/3] builtin/apply: tighten (dis)similarity index parsing
From: John Keeping @ 2013-02-03 14:37 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse, John Keeping
In-Reply-To: <cover.1359901732.git.john@keeping.me.uk>
This was prompted by an incorrect warning issued by clang [1], and a
suggestion by Linus to restrict the range to check for values greater
than INT_MAX since these will give bogus output after casting to int.
In fact the (dis)similarity index is a percentage, so reject values
greater than 100.
[1] http://article.gmane.org/gmane.comp.version-control.git/213857
Signed-off-by: John Keeping <john@keeping.me.uk>
---
builtin/apply.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index 6c11e8b..4745e75 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -1041,15 +1041,17 @@ static int gitdiff_renamedst(const char *line, struct patch *patch)
static int gitdiff_similarity(const char *line, struct patch *patch)
{
- if ((patch->score = strtoul(line, NULL, 10)) == ULONG_MAX)
- patch->score = 0;
+ unsigned long val = strtoul(line, NULL, 10);
+ if (val <= 100)
+ patch->score = val;
return 0;
}
static int gitdiff_dissimilarity(const char *line, struct patch *patch)
{
- if ((patch->score = strtoul(line, NULL, 10)) == ULONG_MAX)
- patch->score = 0;
+ unsigned long val = strtoul(line, NULL, 10);
+ if (val <= 100)
+ patch->score = val;
return 0;
}
--
1.8.1.2
^ permalink raw reply related
* [PATCH 1/3] fix clang -Wtautological-compare with unsigned enum
From: John Keeping @ 2013-02-03 14:37 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse, John Keeping
In-Reply-To: <cover.1359901732.git.john@keeping.me.uk>
From: Antoine Pelisse <apelisse@gmail.com>
Create a GREP_HEADER_FIELD_MIN so we can check that the field value is
sane and silent the clang warning.
Clang warning happens because the enum is unsigned (this is
implementation-defined, and there is no negative fields) and the check
is then tautological.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
---
grep.c | 3 ++-
grep.h | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/grep.c b/grep.c
index 4bd1b8b..bb548ca 100644
--- a/grep.c
+++ b/grep.c
@@ -625,7 +625,8 @@ static struct grep_expr *prep_header_patterns(struct grep_opt *opt)
for (p = opt->header_list; p; p = p->next) {
if (p->token != GREP_PATTERN_HEAD)
die("bug: a non-header pattern in grep header list.");
- if (p->field < 0 || GREP_HEADER_FIELD_MAX <= p->field)
+ if (p->field < GREP_HEADER_FIELD_MIN ||
+ GREP_HEADER_FIELD_MAX <= p->field)
die("bug: unknown header field %d", p->field);
compile_regexp(p, opt);
}
diff --git a/grep.h b/grep.h
index 8fc854f..e4a1df5 100644
--- a/grep.h
+++ b/grep.h
@@ -28,7 +28,8 @@ enum grep_context {
};
enum grep_header_field {
- GREP_HEADER_AUTHOR = 0,
+ GREP_HEADER_FIELD_MIN = 0,
+ GREP_HEADER_AUTHOR = GREP_HEADER_FIELD_MIN,
GREP_HEADER_COMMITTER,
GREP_HEADER_REFLOG,
--
1.8.1.2
^ permalink raw reply related
* [PATCH 2/3] combine-diff: suppress a clang warning
From: John Keeping @ 2013-02-03 14:37 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse, John Keeping
In-Reply-To: <cover.1359901732.git.john@keeping.me.uk>
When compiling combine-diff.c, clang 3.2 says:
combine-diff.c:1006:19: warning: adding 'int' to a string does not
append to the string [-Wstring-plus-int]
prefix = COLONS + offset;
~~~~~~~^~~~~~~~
combine-diff.c:1006:19: note: use array indexing to silence this warning
prefix = COLONS + offset;
^
& [ ]
Suppress this by making the suggested change.
Signed-off-by: John Keeping <john@keeping.me.uk>
---
combine-diff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/combine-diff.c b/combine-diff.c
index bb1cc96..dba4748 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -1003,7 +1003,7 @@ static void show_raw_diff(struct combine_diff_path *p, int num_parent, struct re
offset = strlen(COLONS) - num_parent;
if (offset < 0)
offset = 0;
- prefix = COLONS + offset;
+ prefix = &COLONS[offset];
/* Show the modes */
for (i = 0; i < num_parent; i++) {
--
1.8.1.2
^ permalink raw reply related
* [PATCH 0/3] Make Git compile warning-free with Clang
From: John Keeping @ 2013-02-03 14:37 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse, John Keeping
The first two patches here were sent to the list before but seem to have
got lost in the noise [1][2]. The final one is new but was prompted by
discussion in the same thread.
After applying all of these patches, I don't see any warnings compiling
Git with Clang 3.2.
[1] http://article.gmane.org/gmane.comp.version-control.git/213817
[2] http://article.gmane.org/gmane.comp.version-control.git/213849
Antoine Pelisse (1):
fix clang -Wtautological-compare with unsigned enum
John Keeping (2):
combine-diff: suppress a clang warning
builtin/apply: tighten (dis)similarity index parsing
builtin/apply.c | 10 ++++++----
combine-diff.c | 2 +-
grep.c | 3 ++-
grep.h | 3 ++-
4 files changed, 11 insertions(+), 7 deletions(-)
--
1.8.1.2
^ permalink raw reply
* Feature request: Allow extracting revisions into directories
From: Robert Clausecker @ 2013-02-03 14:18 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 700 bytes --]
Hello!
git currently has the archive command that allows to save an arbitrary
revision into a tar or zip file. Sometimes it is useful to not save this
revision into an archive but to directly put all files into an arbitrary
directory. Currently this seems to be not possible to archive directly;
the only way I found to do it is to run git archive and then directly
unpack the archive into a directory.
git --git-dir REPO archive REVISION | tar x
It would be nice to have a command or simply a switch to git archive
that allows the user to put the files of REVISION into a directory
instead of making an archive.
Thank you very much for your help. Yours,
Robert Clausecker
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Getting started contributing.
From: Philip Oakley @ 2013-02-03 13:34 UTC (permalink / raw)
To: adamfraser; +Cc: git, Junio C Hamano
In-Reply-To: <7vd2whalax.fsf@alter.siamese.dyndns.org>
From: "Junio C Hamano" <gitster@pobox.com>
Sent: Sunday, February 03, 2013 7:49 AM
> adamfraser <adamfraser0@gmail.com> writes:
>
>> I've done a little searching and
>> haven't been able to find an official bug tracker for git is there
>> somewhere
>> I can find some bugs to help fix?
>
> You came to the right place. A new bug or regression is reported to
> this list, and it often is fixed (or often diagnosed as pebcak)
> fairly quickly by list regulars. Nobody maintains a bugzilla that
> is not maintained and is full of stale/invalid bug reports.
>
> The best contribution a new person can make is to use the software
> regularly and find issues. It is very hard to find real bugs that
> can easily be fixed by somebody totally new to the codebase in Git
> these days.
>
> On the other hand, there probably still are many loose ends. When a
> command is supposed to take only two arguments because taking more
> than three does not make any sense, for example, it has not been
> unusual for us to document the two-argument form of the command,
> reject if the user gives only one argument with an error message,
> but we simply ignore the third argument if the user mistakenly runs
> the command with three arguments, instead of erroring out (i.e. the
> code does not bother to help insane or too inexperienced users).
> That kind of things are hard to find by users experienced with Git
> exactly because they know running such a command with three or more
> arguments is nonsense, and they do not even try to make such a
> mistake. Still, it would be very nice to find and fix such issues.
>
A review of the git-user list
https://groups.google.com/forum/?fromgroups#!forum/git-users is one
place to discover some of the user issues and thinking about how to
address them. Or resurrect issues from this Git list. E.g. There are a
number of sub-module improvements available there.
If you have any Windows experience the MSysGit team
https://github.com/msysgit/msysgit is always looking for help on some of
the compatibility issues, e.g. where the Linux optimisations conflict
with the Windows approaches.
Another area is picking out documentation issues you have seen and
submitting patches for them, whether in the command man pages or in the
guides. On my 'todo' list is to make the `help` command actually list
the "Help me" (i.e. guides and articles) pages, not just the command man
pages.
I also had -
* Bulk move detection (when folk change/move upper level directory
names).
* add a .gitnevermerge option to stop private files you don't want in
'master' (or any other branch) to be merged
Philip
^ permalink raw reply
* Re: What's cooking in git.git (Feb 2013, #01; Fri, 1)
From: John Keeping @ 2013-02-03 13:02 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, git
In-Reply-To: <CAJDDKr6bPjKwe3NitvGCec2LyesY3yL=UtN85Bsox-bGWN=qeA@mail.gmail.com>
On Sun, Feb 03, 2013 at 04:13:22AM -0800, David Aguilar wrote:
> On Sat, Feb 2, 2013 at 9:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> > Regarding these two topics....
> >
> >> * da/mergetool-docs (2013-01-30) 7 commits
> >> - doc: generate a list of valid merge tools
> >> - mergetool--lib: list user configured tools in '--tool-help'
> >> - fixup! doc: generate a list of valid merge tools
> >> - fixup! mergetool--lib: add functions for finding available tools
> >> - mergetool--lib: add functions for finding available tools
> >> - mergetool--lib: improve the help text in guess_merge_tool()
> >> - mergetool--lib: simplify command expressions
> >> (this branch uses jk/mergetool.)
> >>
> >> Build on top of the clean-up done by jk/mergetool and automatically
> >> generate the list of mergetool and difftool backends the build
> >> supports to be included in the documentation.
> >>
> >> Will merge to 'next', after squashing the fixup! commits from John
> >> Keeping.
> >>
> >>
> >> * jk/mergetool (2013-01-28) 8 commits
> >> - mergetools: simplify how we handle "vim" and "defaults"
> >> - mergetool--lib: don't call "exit" in setup_tool
> >> - mergetool--lib: improve show_tool_help() output
> >> - mergetools/vim: remove redundant diff command
> >> - git-difftool: use git-mergetool--lib for "--tool-help"
> >> - git-mergetool: don't hardcode 'mergetool' in show_tool_help
> >> - git-mergetool: remove redundant assignment
> >> - git-mergetool: move show_tool_help to mergetool--lib
> >> (this branch is used by da/mergetool-docs.)
> >>
> >> Cleans up mergetool/difftool combo.
> >>
> >> This is looking ready for 'next'.
> >
> > Do the tips of these two topics look reasonable to both of you, or
> > are there anything you sent but I missed?
>
> It looks good to go. The additional "|| :" in the makefile is a nice
> touchup that made it more robust too.
Looks good to me as well.
John
^ permalink raw reply
* Re: What's cooking in git.git (Feb 2013, #01; Fri, 1)
From: David Aguilar @ 2013-02-03 12:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Keeping, git
In-Reply-To: <7vlib69cjh.fsf@alter.siamese.dyndns.org>
On Sat, Feb 2, 2013 at 9:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> Regarding these two topics....
>
>> * da/mergetool-docs (2013-01-30) 7 commits
>> - doc: generate a list of valid merge tools
>> - mergetool--lib: list user configured tools in '--tool-help'
>> - fixup! doc: generate a list of valid merge tools
>> - fixup! mergetool--lib: add functions for finding available tools
>> - mergetool--lib: add functions for finding available tools
>> - mergetool--lib: improve the help text in guess_merge_tool()
>> - mergetool--lib: simplify command expressions
>> (this branch uses jk/mergetool.)
>>
>> Build on top of the clean-up done by jk/mergetool and automatically
>> generate the list of mergetool and difftool backends the build
>> supports to be included in the documentation.
>>
>> Will merge to 'next', after squashing the fixup! commits from John
>> Keeping.
>>
>>
>> * jk/mergetool (2013-01-28) 8 commits
>> - mergetools: simplify how we handle "vim" and "defaults"
>> - mergetool--lib: don't call "exit" in setup_tool
>> - mergetool--lib: improve show_tool_help() output
>> - mergetools/vim: remove redundant diff command
>> - git-difftool: use git-mergetool--lib for "--tool-help"
>> - git-mergetool: don't hardcode 'mergetool' in show_tool_help
>> - git-mergetool: remove redundant assignment
>> - git-mergetool: move show_tool_help to mergetool--lib
>> (this branch is used by da/mergetool-docs.)
>>
>> Cleans up mergetool/difftool combo.
>>
>> This is looking ready for 'next'.
>
> Do the tips of these two topics look reasonable to both of you, or
> are there anything you sent but I missed?
It looks good to go. The additional "|| :" in the makefile is a nice
touchup that made it more robust too.
--
David
^ permalink raw reply
* Re: Getting started contributing.
From: Duy Nguyen @ 2013-02-03 9:54 UTC (permalink / raw)
To: adamfraser; +Cc: Junio C Hamano, git
In-Reply-To: <7vd2whalax.fsf@alter.siamese.dyndns.org>
On Sun, Feb 3, 2013 at 2:49 PM, Junio C Hamano <gitster@pobox.com> wrote:
> On the other hand, there probably still are many loose ends.
A few other things
- Mark more strings for translation (not as easy as it sounds, some
strings can't be translated)
- Color more in the output where it makes sense
- Stop/Warn the user from updating HEAD (e.g. checkout another
branch) while in the middle of a rebase (some makes sense, most is by
mistake)
PS. You are welcome to improve my two patches Junio mentioned. I don't
think it overlaps much with "git rebase --status" though. Printing the
remaining steps, or what patch being applied is not going to be done
by "git status".
--
Duy
^ permalink raw reply
* Re: Getting started contributing.
From: Junio C Hamano @ 2013-02-03 7:49 UTC (permalink / raw)
To: adamfraser; +Cc: git
In-Reply-To: <1359872508519-7576834.post@n2.nabble.com>
adamfraser <adamfraser0@gmail.com> writes:
> I've done a little searching and
> haven't been able to find an official bug tracker for git is there somewhere
> I can find some bugs to help fix?
You came to the right place. A new bug or regression is reported to
this list, and it often is fixed (or often diagnosed as pebcak)
fairly quickly by list regulars. Nobody maintains a bugzilla that
is not maintained and is full of stale/invalid bug reports.
The best contribution a new person can make is to use the software
regularly and find issues. It is very hard to find real bugs that
can easily be fixed by somebody totally new to the codebase in Git
these days.
On the other hand, there probably still are many loose ends. When a
command is supposed to take only two arguments because taking more
than three does not make any sense, for example, it has not been
unusual for us to document the two-argument form of the command,
reject if the user gives only one argument with an error message,
but we simply ignore the third argument if the user mistakenly runs
the command with three arguments, instead of erroring out (i.e. the
code does not bother to help insane or too inexperienced users).
That kind of things are hard to find by users experienced with Git
exactly because they know running such a command with three or more
arguments is nonsense, and they do not even try to make such a
mistake. Still, it would be very nice to find and fix such issues.
Thanks.
^ permalink raw reply
* Re: Getting started contributing.
From: Junio C Hamano @ 2013-02-03 7:40 UTC (permalink / raw)
To: adamfraser; +Cc: git
In-Reply-To: <1359872508519-7576834.post@n2.nabble.com>
adamfraser <adamfraser0@gmail.com> writes:
> I would like to start contributing to git and am looking for a small project
> idea to get started with. On the Small Project Ideas wiki
> <https://git.wiki.kernel.org/index.php/SmallProjectsIdeas> site there is a
> suggestion for adding a 'git rebase --status' command that sounds like it
> would be good for someone who has little knowledge of the code base.
I think the two patches Duy just posted tonight overlap with that
topic, and I suspect it would give the end users a better experience
to put the information in "git status" output rather than a separate
"git rebase" subcommand. Perhaps you can work with him to see what
other things his patch may have missed can be improved?
^ permalink raw reply
* Getting started contributing.
From: adamfraser @ 2013-02-03 6:21 UTC (permalink / raw)
To: git
Hi,
I would like to start contributing to git and am looking for a small project
idea to get started with. On the Small Project Ideas wiki
<https://git.wiki.kernel.org/index.php/SmallProjectsIdeas> site there is a
suggestion for adding a 'git rebase --status' command that sounds like it
would be good for someone who has little knowledge of the code base. Is this
project still wanted? Aside from that, I've done a little searching and
haven't been able to find an official bug tracker for git is there somewhere
I can find some bugs to help fix?
Apologies if this isn't the correct place to be posting.
Thanks
Adam Fraser
--
View this message in context: http://git.661346.n2.nabble.com/Getting-started-contributing-tp7576834.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH v3] status: show the branch name if possible in in-progress info
From: Nguyễn Thái Ngọc Duy @ 2013-02-03 5:53 UTC (permalink / raw)
To: git
Cc: Matthieu Moy, Jonathan Niedier, Junio C Hamano,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1359471493-32531-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
- avoid hardcoding SHA-1 in t7512
- I did not act on Junio's --format=%s idea because frankly I don't
care much about the "on 'xxx'" part. It was Matthieu's idea and he
did not make any comments on --format=%s
t/t7512-status-help.sh | 87 +++++++++++++++++++++++++++-------------------
wt-status.c | 94 ++++++++++++++++++++++++++++++++++++++++++++++----
wt-status.h | 2 ++
3 files changed, 142 insertions(+), 41 deletions(-)
diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
index b3f6eb9..51ab894 100755
--- a/t/t7512-status-help.sh
+++ b/t/t7512-status-help.sh
@@ -73,10 +73,11 @@ test_expect_success 'prepare for rebase conflicts' '
test_expect_success 'status when rebase in progress before resolving conflicts' '
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD^^) &&
test_must_fail git rebase HEAD^ --onto HEAD^^ &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently rebasing.
+ # You are currently rebasing branch '\''rebase_conflicts'\'' on '\''$ONTO'\''.
# (fix conflicts and then run "git rebase --continue")
# (use "git rebase --skip" to skip this patch)
# (use "git rebase --abort" to check out the original branch)
@@ -97,12 +98,13 @@ test_expect_success 'status when rebase in progress before resolving conflicts'
test_expect_success 'status when rebase in progress before rebase --continue' '
git reset --hard rebase_conflicts &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD^^) &&
test_must_fail git rebase HEAD^ --onto HEAD^^ &&
echo three >main.txt &&
git add main.txt &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently rebasing.
+ # You are currently rebasing branch '\''rebase_conflicts'\'' on '\''$ONTO'\''.
# (all conflicts fixed: run "git rebase --continue")
#
# Changes to be committed:
@@ -130,10 +132,11 @@ test_expect_success 'prepare for rebase_i_conflicts' '
test_expect_success 'status during rebase -i when conflicts unresolved' '
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short rebase_i_conflicts) &&
test_must_fail git rebase -i rebase_i_conflicts &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently rebasing.
+ # You are currently rebasing branch '\''rebase_i_conflicts_second'\'' on '\''$ONTO'\''.
# (fix conflicts and then run "git rebase --continue")
# (use "git rebase --skip" to skip this patch)
# (use "git rebase --abort" to check out the original branch)
@@ -154,11 +157,12 @@ test_expect_success 'status during rebase -i when conflicts unresolved' '
test_expect_success 'status during rebase -i after resolving conflicts' '
git reset --hard rebase_i_conflicts_second &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short rebase_i_conflicts) &&
test_must_fail git rebase -i rebase_i_conflicts &&
git add main.txt &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently rebasing.
+ # You are currently rebasing branch '\''rebase_i_conflicts_second'\'' on '\''$ONTO'\''.
# (all conflicts fixed: run "git rebase --continue")
#
# Changes to be committed:
@@ -182,10 +186,11 @@ test_expect_success 'status when rebasing -i in edit mode' '
FAKE_LINES="1 edit 2" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~2) &&
git rebase -i HEAD~2 &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently editing a commit during a rebase.
+ # You are currently editing a commit while rebasing branch '\''rebase_i_edit'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
#
@@ -206,11 +211,12 @@ test_expect_success 'status when splitting a commit' '
FAKE_LINES="1 edit 2 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git reset HEAD^ &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently splitting a commit during a rebase.
+ # You are currently splitting a commit while rebasing branch '\''split_commit'\'' on '\''$ONTO'\''.
# (Once your working directory is clean, run "git rebase --continue")
#
# Changes not staged for commit:
@@ -236,11 +242,12 @@ test_expect_success 'status after editing the last commit with --amend during a
FAKE_LINES="1 2 edit 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git commit --amend -m "foo" &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently editing a commit during a rebase.
+ # You are currently editing a commit while rebasing branch '\''amend_last'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
#
@@ -265,11 +272,12 @@ test_expect_success 'status: (continue first edit) second edit' '
FAKE_LINES="edit 1 edit 2 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git rebase --continue &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently editing a commit during a rebase.
+ # You are currently editing a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
#
@@ -285,12 +293,13 @@ test_expect_success 'status: (continue first edit) second edit and split' '
FAKE_LINES="edit 1 edit 2 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git rebase --continue &&
git reset HEAD^ &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently splitting a commit during a rebase.
+ # You are currently splitting a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (Once your working directory is clean, run "git rebase --continue")
#
# Changes not staged for commit:
@@ -311,12 +320,13 @@ test_expect_success 'status: (continue first edit) second edit and amend' '
FAKE_LINES="edit 1 edit 2 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git rebase --continue &&
git commit --amend -m "foo" &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently editing a commit during a rebase.
+ # You are currently editing a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
#
@@ -332,12 +342,13 @@ test_expect_success 'status: (amend first edit) second edit' '
FAKE_LINES="edit 1 edit 2 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git commit --amend -m "a" &&
git rebase --continue &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently editing a commit during a rebase.
+ # You are currently editing a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
#
@@ -353,13 +364,14 @@ test_expect_success 'status: (amend first edit) second edit and split' '
FAKE_LINES="edit 1 edit 2 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git commit --amend -m "b" &&
git rebase --continue &&
git reset HEAD^ &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently splitting a commit during a rebase.
+ # You are currently splitting a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (Once your working directory is clean, run "git rebase --continue")
#
# Changes not staged for commit:
@@ -380,13 +392,14 @@ test_expect_success 'status: (amend first edit) second edit and amend' '
FAKE_LINES="edit 1 edit 2 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git commit --amend -m "c" &&
git rebase --continue &&
git commit --amend -m "d" &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently editing a commit during a rebase.
+ # You are currently editing a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
#
@@ -402,14 +415,15 @@ test_expect_success 'status: (split first edit) second edit' '
FAKE_LINES="edit 1 edit 2 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git reset HEAD^ &&
git add main.txt &&
git commit -m "e" &&
git rebase --continue &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently editing a commit during a rebase.
+ # You are currently editing a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
#
@@ -425,15 +439,16 @@ test_expect_success 'status: (split first edit) second edit and split' '
FAKE_LINES="edit 1 edit 2 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git reset HEAD^ &&
git add main.txt &&
git commit --amend -m "f" &&
git rebase --continue &&
git reset HEAD^ &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently splitting a commit during a rebase.
+ # You are currently splitting a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (Once your working directory is clean, run "git rebase --continue")
#
# Changes not staged for commit:
@@ -454,15 +469,16 @@ test_expect_success 'status: (split first edit) second edit and amend' '
FAKE_LINES="edit 1 edit 2 3" &&
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git reset HEAD^ &&
git add main.txt &&
git commit --amend -m "g" &&
git rebase --continue &&
git commit --amend -m "h" &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently editing a commit during a rebase.
+ # You are currently editing a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
#
@@ -558,7 +574,7 @@ test_expect_success 'status when bisecting' '
git bisect good one_bisect &&
cat >expected <<-\EOF &&
# Not currently on any branch.
- # You are currently bisecting.
+ # You are currently bisecting branch '\''bisect'\''.
# (use "git bisect reset" to get back to the original branch)
#
nothing to commit (use -u to show untracked files)
@@ -577,10 +593,11 @@ test_expect_success 'status when rebase conflicts with statushints disabled' '
test_commit two_statushints main.txt two &&
test_commit three_statushints main.txt three &&
test_when_finished "git rebase --abort" &&
+ ONTO=$(git rev-parse --short HEAD^^) &&
test_must_fail git rebase HEAD^ --onto HEAD^^ &&
- cat >expected <<-\EOF &&
+ cat >expected <<-EOF &&
# Not currently on any branch.
- # You are currently rebasing.
+ # You are currently rebasing branch '\''statushints_disabled'\'' on '\''$ONTO'\''.
#
# Unmerged paths:
# both modified: main.txt
diff --git a/wt-status.c b/wt-status.c
index d7cfe8f..983e2f4 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -872,7 +872,14 @@ static void show_rebase_in_progress(struct wt_status *s,
struct stat st;
if (has_unmerged(s)) {
- status_printf_ln(s, color, _("You are currently rebasing."));
+ if (state->branch)
+ status_printf_ln(s, color,
+ _("You are currently rebasing branch '%s' on '%s'."),
+ state->branch,
+ state->onto);
+ else
+ status_printf_ln(s, color,
+ _("You are currently rebasing."));
if (advice_status_hints) {
status_printf_ln(s, color,
_(" (fix conflicts and then run \"git rebase --continue\")"));
@@ -882,17 +889,38 @@ static void show_rebase_in_progress(struct wt_status *s,
_(" (use \"git rebase --abort\" to check out the original branch)"));
}
} else if (state->rebase_in_progress || !stat(git_path("MERGE_MSG"), &st)) {
- status_printf_ln(s, color, _("You are currently rebasing."));
+ if (state->branch)
+ status_printf_ln(s, color,
+ _("You are currently rebasing branch '%s' on '%s'."),
+ state->branch,
+ state->onto);
+ else
+ status_printf_ln(s, color,
+ _("You are currently rebasing."));
if (advice_status_hints)
status_printf_ln(s, color,
_(" (all conflicts fixed: run \"git rebase --continue\")"));
} else if (split_commit_in_progress(s)) {
- status_printf_ln(s, color, _("You are currently splitting a commit during a rebase."));
+ if (state->branch)
+ status_printf_ln(s, color,
+ _("You are currently splitting a commit while rebasing branch '%s' on '%s'."),
+ state->branch,
+ state->onto);
+ else
+ status_printf_ln(s, color,
+ _("You are currently splitting a commit during a rebase."));
if (advice_status_hints)
status_printf_ln(s, color,
_(" (Once your working directory is clean, run \"git rebase --continue\")"));
} else {
- status_printf_ln(s, color, _("You are currently editing a commit during a rebase."));
+ if (state->branch)
+ status_printf_ln(s, color,
+ _("You are currently editing a commit while rebasing branch '%s' on '%s'."),
+ state->branch,
+ state->onto);
+ else
+ status_printf_ln(s, color,
+ _("You are currently editing a commit during a rebase."));
if (advice_status_hints && !s->amend) {
status_printf_ln(s, color,
_(" (use \"git commit --amend\" to amend the current commit)"));
@@ -923,16 +951,57 @@ static void show_bisect_in_progress(struct wt_status *s,
struct wt_status_state *state,
const char *color)
{
- status_printf_ln(s, color, _("You are currently bisecting."));
+ if (state->branch)
+ status_printf_ln(s, color,
+ _("You are currently bisecting branch '%s'."),
+ state->branch);
+ else
+ status_printf_ln(s, color,
+ _("You are currently bisecting."));
if (advice_status_hints)
status_printf_ln(s, color,
_(" (use \"git bisect reset\" to get back to the original branch)"));
wt_status_print_trailer(s);
}
+/*
+ * Extract branch information from rebase/bisect
+ */
+static void read_and_strip_branch(struct strbuf *sb,
+ const char **branch,
+ const char *path)
+{
+ unsigned char sha1[20];
+
+ strbuf_reset(sb);
+ if (strbuf_read_file(sb, git_path("%s", path), 0) <= 0)
+ return;
+
+ while (sb->len && sb->buf[sb->len - 1] == '\n')
+ strbuf_setlen(sb, sb->len - 1);
+ if (!sb->len)
+ return;
+ if (!prefixcmp(sb->buf, "refs/heads/"))
+ *branch = sb->buf + strlen("refs/heads/");
+ else if (!prefixcmp(sb->buf, "refs/"))
+ *branch = sb->buf;
+ else if (!get_sha1_hex(sb->buf, sha1)) {
+ const char *abbrev;
+ abbrev = find_unique_abbrev(sha1, DEFAULT_ABBREV);
+ strbuf_reset(sb);
+ strbuf_addstr(sb, abbrev);
+ *branch = sb->buf;
+ } else if (!strcmp(sb->buf, "detached HEAD")) /* rebase */
+ ;
+ else /* bisect */
+ *branch = sb->buf;
+}
+
static void wt_status_print_state(struct wt_status *s)
{
const char *state_color = color(WT_STATUS_HEADER, s);
+ struct strbuf branch = STRBUF_INIT;
+ struct strbuf onto = STRBUF_INIT;
struct wt_status_state state;
struct stat st;
@@ -947,17 +1016,28 @@ static void wt_status_print_state(struct wt_status *s)
state.am_empty_patch = 1;
} else {
state.rebase_in_progress = 1;
+ read_and_strip_branch(&branch, &state.branch,
+ "rebase-apply/head-name");
+ read_and_strip_branch(&onto, &state.onto,
+ "rebase-apply/onto");
}
} else if (!stat(git_path("rebase-merge"), &st)) {
if (!stat(git_path("rebase-merge/interactive"), &st))
state.rebase_interactive_in_progress = 1;
else
state.rebase_in_progress = 1;
+ read_and_strip_branch(&branch, &state.branch,
+ "rebase-merge/head-name");
+ read_and_strip_branch(&onto, &state.onto,
+ "rebase-merge/onto");
} else if (!stat(git_path("CHERRY_PICK_HEAD"), &st)) {
state.cherry_pick_in_progress = 1;
}
- if (!stat(git_path("BISECT_LOG"), &st))
+ if (!stat(git_path("BISECT_LOG"), &st)) {
state.bisect_in_progress = 1;
+ read_and_strip_branch(&branch, &state.branch,
+ "BISECT_START");
+ }
if (state.merge_in_progress)
show_merge_in_progress(s, &state, state_color);
@@ -969,6 +1049,8 @@ static void wt_status_print_state(struct wt_status *s)
show_cherry_pick_in_progress(s, &state, state_color);
if (state.bisect_in_progress)
show_bisect_in_progress(s, &state, state_color);
+ strbuf_release(&branch);
+ strbuf_release(&onto);
}
void wt_status_print(struct wt_status *s)
diff --git a/wt-status.h b/wt-status.h
index 236b41f..81e1dcf 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -79,6 +79,8 @@ struct wt_status_state {
int rebase_interactive_in_progress;
int cherry_pick_in_progress;
int bisect_in_progress;
+ const char *branch;
+ const char *onto;
};
void wt_status_prepare(struct wt_status *s);
--
1.8.1.1.459.g5970e58
^ permalink raw reply related
* [PATCH v2] branch: show rebase/bisect info when possible instead of "(no branch)"
From: Nguyễn Thái Ngọc Duy @ 2013-02-03 5:48 UTC (permalink / raw)
To: git; +Cc: Jonathan Niedier, Nguyễn Thái Ngọc Duy
In-Reply-To: <1359461574-24529-1-git-send-email-pclouds@gmail.com>
This prints more helpful info when HEAD is detached: is it detached
because of bisect or rebase? What is the original branch name in those
cases?
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
- Incorporate Jonathan's version of checking
- Show original branch name, e.g. "(rebasing foo)", when possible
builtin/branch.c | 40 +++++++++++++++++++++++++++++++++++++++-
t/t6030-bisect-porcelain.sh | 2 +-
2 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index ea6498b..40f20ad 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -550,6 +550,44 @@ static int calc_maxwidth(struct ref_list *refs)
return w;
}
+static char *get_head_description()
+{
+ struct stat st;
+ struct strbuf sb = STRBUF_INIT;
+ struct strbuf result = STRBUF_INIT;
+ int bisect = 0;
+ int ret;
+ if (!stat(git_path("rebase-merge"), &st) && S_ISDIR(st.st_mode))
+ ret = strbuf_read_file(&sb, git_path("rebase-merge/head-name"), 0);
+ else if (!access(git_path("rebase-apply/rebasing"), F_OK))
+ ret = strbuf_read_file(&sb, git_path("rebase-apply/head-name"), 0);
+ else if (!access(git_path("BISECT_LOG"), F_OK)) {
+ ret = strbuf_read_file(&sb, git_path("BISECT_START"), 0);
+ bisect = 1;
+ } else
+ return xstrdup(_("(no branch)"));
+
+ if (ret <= 0)
+ return xstrdup(bisect ? _("(bisecting)") : _("_(rebasing)"));
+
+ while (sb.len && sb.buf[sb.len - 1] == '\n')
+ strbuf_setlen(&sb, sb.len - 1);
+
+ if (bisect) {
+ unsigned char sha1[20];
+ if (!get_sha1_hex(sb.buf, sha1))
+ strbuf_addstr(&result, _("(bisecting)"));
+ else
+ strbuf_addf(&result, _("(bisecting %s)"), sb.buf);
+ } else {
+ if (!prefixcmp(sb.buf, "refs/heads/"))
+ strbuf_addf(&result, _("(rebasing %s)"), sb.buf + 11);
+ else
+ strbuf_addstr(&result, _("(rebasing)"));
+ }
+ strbuf_release(&sb);
+ return strbuf_detach(&result, NULL);
+}
static void show_detached(struct ref_list *ref_list)
{
@@ -557,7 +595,7 @@ static void show_detached(struct ref_list *ref_list)
if (head_commit && is_descendant_of(head_commit, ref_list->with_commit)) {
struct ref_item item;
- item.name = xstrdup(_("(no branch)"));
+ item.name = get_head_description();
item.width = utf8_strwidth(item.name);
item.kind = REF_LOCAL_BRANCH;
item.dest = NULL;
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 3e0e15f..90968d5 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -164,7 +164,7 @@ test_expect_success 'bisect start: existing ".git/BISECT_START" not modified if
cp .git/BISECT_START saved &&
test_must_fail git bisect start $HASH4 foo -- &&
git branch > branch.output &&
- test_i18ngrep "* (no branch)" branch.output > /dev/null &&
+ test_i18ngrep "* (bisecting other)" branch.output > /dev/null &&
test_cmp saved .git/BISECT_START
'
test_expect_success 'bisect start: no ".git/BISECT_START" if mistaken rev' '
--
1.8.1.1.459.g5970e58
^ permalink raw reply related
* Re: What's cooking in git.git (Feb 2013, #01; Fri, 1)
From: Junio C Hamano @ 2013-02-03 5:44 UTC (permalink / raw)
To: David Aguilar, John Keeping; +Cc: git
In-Reply-To: <7vwqur8z4s.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Regarding these two topics....
> * da/mergetool-docs (2013-01-30) 7 commits
> - doc: generate a list of valid merge tools
> - mergetool--lib: list user configured tools in '--tool-help'
> - fixup! doc: generate a list of valid merge tools
> - fixup! mergetool--lib: add functions for finding available tools
> - mergetool--lib: add functions for finding available tools
> - mergetool--lib: improve the help text in guess_merge_tool()
> - mergetool--lib: simplify command expressions
> (this branch uses jk/mergetool.)
>
> Build on top of the clean-up done by jk/mergetool and automatically
> generate the list of mergetool and difftool backends the build
> supports to be included in the documentation.
>
> Will merge to 'next', after squashing the fixup! commits from John
> Keeping.
>
>
> * jk/mergetool (2013-01-28) 8 commits
> - mergetools: simplify how we handle "vim" and "defaults"
> - mergetool--lib: don't call "exit" in setup_tool
> - mergetool--lib: improve show_tool_help() output
> - mergetools/vim: remove redundant diff command
> - git-difftool: use git-mergetool--lib for "--tool-help"
> - git-mergetool: don't hardcode 'mergetool' in show_tool_help
> - git-mergetool: remove redundant assignment
> - git-mergetool: move show_tool_help to mergetool--lib
> (this branch is used by da/mergetool-docs.)
>
> Cleans up mergetool/difftool combo.
>
> This is looking ready for 'next'.
Do the tips of these two topics look reasonable to both of you, or
are there anything you sent but I missed?
^ permalink raw reply
* Re: [PATCH] Honor configure's htmldir switch
From: Junio C Hamano @ 2013-02-03 4:50 UTC (permalink / raw)
To: Christoph Thompson; +Cc: git
In-Reply-To: <CA+7ShCqxDKHw0dzC6ASH=qpjG_MP-QZxOyMxQmoTKhXc7ZYHuA@mail.gmail.com>
Christoph Thompson <cjsthompson@gmail.com> writes:
[administrivia: why do you keep dropping git@vger from Cc???]
> I was under the impression that configure passed on the value of it's
> --htmldir switch by doing
> some substitution work like the following :
>
> sed 's|@htmldir@|$(htmldir)|g' config.mak.in > config.mak
The information flow goes more like this:
* configure.ac is used to generate the configure script with
autoconf;
* configure script is driven by the user and finds the system
characteristics and user's wish;
* what configure found out is used to generate config.mak.autogen,
using config.mak.in as a template; and then
* the primary Makefile reads config.mak.autogen if exists and then
config.mak if exists.
Note that use of ./configure is entirely optional for the build
system of Git. You can give parameters to make on its command line
(without having config.mak or config.mak.autogen), or you can give
these parameters in handwritten config.mak and just say "make".
You can also use ./configure to write some reasonable values in
config.mak.autogen, but if ./configure guesses things incorrrectly,
you can still override them in your handwritten config.mak exactly
because it is read after config.mak.autogen is read by Makefile.
^ permalink raw reply
* Re: [PATCH] Honor configure's htmldir switch
From: Junio C Hamano @ 2013-02-03 3:31 UTC (permalink / raw)
To: Christoph Thompson; +Cc: git
In-Reply-To: <CA+7ShCrB_1Q=aKw5sP5hLkM1o0v-P1WR5+1iL983X7WQCHP=oQ@mail.gmail.com>
Christoph Thompson <cjsthompson@gmail.com> writes:
> Will the --htmldir switch still work by exporting mandir and htmldir from
> the Makefile instead of
> config.mak.in ?
It should not make a difference where you export them from. Lets
see...
-- cut here -- >8 -- cut here --
$ cat >Makefile <<\EOF
# The default target of this Makefile is ...
all:
var1 = one
var2 = two
var5 = five
var7 = seven
var8 = eight
include config.mak
export var2 var4 var8
all:
env | grep '^var'
EOF
$ cat >config.mak <<\EOF
var3 = three
var4 = four
var6 = six
var7 = siete
var8 = ocho
export var1 var3 var7
EOF
$ make
env | grep '^var'
var1=one
var3=three
var2=two
var4=four
var7=siete
var8=ocho
-- cut here -- 8< -- cut here --
Everything behaves as I expect, I think.
^ permalink raw reply
* [RFC/PATCH] config.mak.in: remove unused definitions
From: Junio C Hamano @ 2013-02-03 1:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
When 5566771 (autoconf: Use autoconf to write installation
directories to config.mak.autogen, 2006-07-03) introduced support
for autoconf generated config.mak file, it added a few "export",
in addition to definitions of srcdir and VPATH.
These "export" logically does not belong there. The common make
variables like mandir, prefix, etc, should be exported to submakes
for people who use config.mak and people who use config.mak.autogen
the same way, so if we want to get these exported, that should be in
the main Makefile, no?
We do use mandir and htmldir in Documentation/Makefile, so let's
add export for them in the main Makefile instead.
We may eventually want to support VPATH, and srcdir may turn out to
be useful for that purpose, but right now nobody uses it, so it is
useless to define them in this file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* As everybody knows, I do not use autoconf/configure, so this may
be breaking things for those who do. Comments, objectsions, and
general education etc. are very much appreciated.
Makefile | 2 +-
config.mak.in | 7 -------
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/Makefile b/Makefile
index 731b6a8..e946402 100644
--- a/Makefile
+++ b/Makefile
@@ -384,7 +384,7 @@ lib = lib
# DESTDIR =
pathsep = :
-export prefix bindir sharedir sysconfdir gitwebdir localedir
+export prefix bindir sharedir mandir htmldir sysconfdir gitwebdir localedir
CC = cc
AR = ar
diff --git a/config.mak.in b/config.mak.in
index e8a9bb4..f87c18c 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -11,7 +11,6 @@ DIFF = @DIFF@
#INSTALL = @INSTALL@ # needs install-sh or install.sh in sources
prefix = @prefix@
-exec_prefix = @exec_prefix@
bindir = @bindir@
gitexecdir = @libexecdir@/git-core
datarootdir = @datarootdir@
@@ -19,9 +18,3 @@ template_dir = @datadir@/git-core/templates
sysconfdir = @sysconfdir@
mandir = @mandir@
-
-srcdir = @srcdir@
-VPATH = @srcdir@
-
-export exec_prefix mandir
-export srcdir VPATH
^ permalink raw reply related
* Re: [PATCH] Honor configure's htmldir switch
From: Junio C Hamano @ 2013-02-03 1:27 UTC (permalink / raw)
To: Christoph J. Thompson; +Cc: git
In-Reply-To: <20130202212504.GA16412@gmail.com>
"Christoph J. Thompson" <cjsthompson@gmail.com> writes:
> Honor autoconf's --htmldir switch. This allows relocating HTML docs
> straight from the configure script.
>
>
> Signed-off-by: Christoph J. Thompson <cjsthompson@gmail.com>
> ---
> config.mak.in | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/config.mak.in b/config.mak.in
> index e8a9bb4..d7c49cd 100644
> --- a/config.mak.in
> +++ b/config.mak.in
> @@ -19,6 +19,7 @@ template_dir = @datadir@/git-core/templates
> sysconfdir = @sysconfdir@
>
> mandir = @mandir@
> +htmldir = @htmldir@
>
> srcdir = @srcdir@
> VPATH = @srcdir@
Hmph, in the output of "git grep -e mandir config.mak.in", I see
export exec_prefix mandir
which makes me wonder if we should either export htmldir as well, or
drop mandir from the "export". Off-hand, I am not sure which is the
right way, but in either case the inconsistency disturbs me.
Thanks.
^ permalink raw reply
* [PATCH] Honor configure's htmldir switch
From: Christoph J. Thompson @ 2013-02-02 21:25 UTC (permalink / raw)
To: git
Honor autoconf's --htmldir switch. This allows relocating HTML docs
straight from the configure script.
Signed-off-by: Christoph J. Thompson <cjsthompson@gmail.com>
---
config.mak.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/config.mak.in b/config.mak.in
index e8a9bb4..d7c49cd 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -19,6 +19,7 @@ template_dir = @datadir@/git-core/templates
sysconfdir = @sysconfdir@
mandir = @mandir@
+htmldir = @htmldir@
srcdir = @srcdir@
VPATH = @srcdir@
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH] Handle path completion and colon for tcsh script
From: Junio C Hamano @ 2013-02-02 20:10 UTC (permalink / raw)
To: Marc Khouzam; +Cc: git@vger.kernel.org, manlio.perillo@gmail.com
In-Reply-To: <E59706EF8DB1D147B15BECA3322E4BDC09AA38@eusaamb103.ericsson.se>
Marc Khouzam <marc.khouzam@ericsson.com> writes:
> Recent enhancements to git-completion.bash provide
> intelligent path completion for git commands. Such
> completions do not add the '/' at the end of directories
> for recent versions of bash.
> ...
> Here is the update for tcsh completion which is needed to handle
> the cool new path completion feature just pushed to 'next'.
>
> Also, Manlio reported that tcsh completion was broken when using
> the colon, and this patch fixes the issue.
>
> I haven't quite figured out the process to indicate which branch
> a patch is meant for. Do I just mention it in the email?
Yes, instead of wondering "Do I mention it here?", saying "This
should come on top of Manlio's completion update." is good.
But I have to wonder if this is sweeping a problem under the rug.
Shouldn't the completion for bash users end completed directory name
with '/', even if we didn't have to worry about tcsh?
^ permalink raw reply
* [PATCH] Handle path completion and colon for tcsh script
From: Marc Khouzam @ 2013-02-02 19:43 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: manlio.perillo@gmail.com, gitster@pobox.com
Recent enhancements to git-completion.bash provide
intelligent path completion for git commands. Such
completions do not add the '/' at the end of directories
for recent versions of bash. However, the '/' is needed
by tcsh, so we must tell the bash script to append it
by using a compatibility method available for older
bash versions.
Also, tcsh does not handle the colon as a completion
separator so we remove it from the list of separators.
Signed-off-by: Marc Khouzam <marc.khouzam@ericsson.com>
---
Hi,
Here is the update for tcsh completion which is needed to handle
the cool new path completion feature just pushed to 'next'.
Also, Manlio reported that tcsh completion was broken when using
the colon, and this patch fixes the issue.
I haven't quite figured out the process to indicate which branch
a patch is meant for. Do I just mention it in the email? Or are all
patches meant for the 'pu' branch? In this case, 'pu' or 'next'
would be appropriate.
Thanks!
Marc
contrib/completion/git-completion.tcsh | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/contrib/completion/git-completion.tcsh b/contrib/completion/git-completion.tcsh
index 3e3889f..eaacaf0 100644
--- a/contrib/completion/git-completion.tcsh
+++ b/contrib/completion/git-completion.tcsh
@@ -52,6 +52,18 @@ cat << EOF > ${__git_tcsh_completion_script}
source ${__git_tcsh_completion_original_script}
+# Remove the colon as a completion separator because tcsh cannot handle it
+COMP_WORDBREAKS=\${COMP_WORDBREAKS//:}
+
+# For file completion, tcsh needs the '/' to be appended to directories.
+# By default, the bash script does not do that.
+# We can achieve this by using the below compatibility
+# method of the git-completion.bash script.
+__git_index_file_list_filter ()
+{
+ __git_index_file_list_filter_compat
+}
+
# Set COMP_WORDS in a way that can be handled by the bash script.
COMP_WORDS=(\$2)
--
1.8.1.367.g8e14972.dirty
^ permalink raw reply related
* Re: [PATCH 4/6] introduce a commit metapack
From: Junio C Hamano @ 2013-02-02 17:49 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, git, Duy Nguyen
In-Reply-To: <20130201094237.GE30644@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Jan 31, 2013 at 09:03:26AM -0800, Shawn O. Pearce wrote:
> ...
>> If we are going to change the index to support extension sections and
>> I have to modify JGit to grok this new format, it needs to be index v3
>> not index v2. If we are making index v3 we should just put index v3 on
>> the end of the pack file.
>
> I'm not sure what you mean by your last sentence here.
I am not Shawn, but here is a summary of what I think I discussed
with him in person, lest I forget.
You could imagine that a new pack system (from pack-objects,
index-pack down to read_packed_sha1() call) that works with a
packfile that
* is a single file, whose name is pack-$SHA1.$sfx (where $sfx
is something other than 'pack', perhaps);
* has the pack data stream, including the concluding checksum of
the stream contents at the end, at the beginning of the file; and
* has the index v3 data blob appended to the pack data stream.
The pack data is streamed over the wire exactly the same way,
interoperating with existing software. When receiving, the new
index-pack can read such a pack stream and add index at the end.
When re-indexing an existing pack (think: upgrading existing
packfiles from the current system), the index-pack can read from the
packfile and do what it does currently (notably, it knows where the
pack stream ends and can stop reading at that point, so even if you
feed the new pack to it, it will stop at the end of the pack data,
ignoring the index v3 already at the end of the input).
One potential advantage of using a single file, instead of the
primary .pack file with 3 (or 47) auxiliary files, is that it lets
you repack without having to deal with this sequence, which happens
currently when you repack:
* create a new .pack file and the corresponding auxiliary files
under temporary filename;
* move existing pack files that describe the same set of objects
away;
* rename these new files, one at a time, to their final name,
making sure that you rename .idx the last, because that happens
to be the key to the pack aware programs.
Instead you can rename only one thing (the new one) to the final
name (possibly atomically replacing the existing one). With the
current system, when you need to replace a pack with a new pack with
the same packname (e.g. you repack everything with a better pack
parameter in a repository that has everything packed into one),
there is a very small window other concurrent users will not find
the object data between the time when you rename the old ones away
and the time when you move the new ones in. The hairly logic
between "Ok we have prepared all new packfiles" and "End of pack
replacement" can be done with a single rename(2) of the new packfile
(which contains everything) to the final name, which atomically
replaces the old one.
This will become even safer if we picked $SHA1 (the name of the
packfile) to represent the hash of the whole thing, not the hash of
the sorted object names in the pack, as that will let us know there
is no need to even "replace" the files.
^ 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