* Re: git-commit feature request: pass editor command line options
From: Jeff King @ 2009-10-14 21:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, Matthew Cline, git
In-Reply-To: <7vvdihdc4f.fsf@alter.siamese.dyndns.org>
On Wed, Oct 14, 2009 at 12:11:28PM -0700, Junio C Hamano wrote:
> > Hmm, what is the use-case when using an option --foo is useful when
> > creating a commit, but not useful when crating a tag?
> >
> > Apart from introducing inconsistency...
>
> Not between commit and tag, but I can see you may want to auto-wrap for
> log message but forbid auto-wrap when editing rebase insn sheet during
> "rebase -i".
I think most people who want that just have their editor automagically
recognize the different situations based on the file name or contents. I
don't think the original author is wrong to want to be able to use
command-line options to do so, but if he is using a common editor like
vim or emacs, I think such autodetection has already been written.
-Peff
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Nicolas Pitre @ 2009-10-14 20:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Jay Soffian, git
In-Reply-To: <7v7huxbtbk.fsf@alter.siamese.dyndns.org>
On Wed, 14 Oct 2009, Junio C Hamano wrote:
> Nicolas Pitre <nico@fluxnic.net> writes:
>
> > On Wed, 14 Oct 2009, Daniel Barkalow wrote:
> >
> >> On Wed, 14 Oct 2009, Jay Soffian wrote:
> >>
> >> > $ git commit -m "blah"
> >> > Cannot commit while not on any branch. Please use git commit -b <branch> to
> >> > specify the name of a new branch to commit to, or use git commit -f to
> >> > force a detached commit.
> >>
> >> The difference is that some experienced users depend on being able to
> >> commit while not on a branch, and want to not get a warning for every
> >> commit while not on a branch.
> >
> > I assume that the -f would silence any warning?
>
> It won't help to alleviate my irritation if I need to give -f to each and
> every invocation of "git commit" while detached, though.
Agreed. Presumably some expert mode config would imply -f
automatically.
Nicolas
^ permalink raw reply
* Re: [msysgit? bug] crlf double-conversion on win32
From: Eric Raible @ 2009-10-14 20:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vfx9lersc.fsf@alter.siamese.dyndns.org>
On Wed, Oct 14, 2009 at 11:47 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Obviously, I am not seriously suggesting "--hard-without-cached-stat-info"
> as the name of this mode of operation, and you need to come up with a
> better one.
Since we already have --soft and --hard, how about --throbbing?
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Junio C Hamano @ 2009-10-14 20:42 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Daniel Barkalow, Jay Soffian, Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0910141616530.20122@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> On Wed, 14 Oct 2009, Daniel Barkalow wrote:
>
>> On Wed, 14 Oct 2009, Jay Soffian wrote:
>>
>> > $ git commit -m "blah"
>> > Cannot commit while not on any branch. Please use git commit -b <branch> to
>> > specify the name of a new branch to commit to, or use git commit -f to
>> > force a detached commit.
>>
>> The difference is that some experienced users depend on being able to
>> commit while not on a branch, and want to not get a warning for every
>> commit while not on a branch.
>
> I assume that the -f would silence any warning?
It won't help to alleviate my irritation if I need to give -f to each and
every invocation of "git commit" while detached, though.
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Daniel Barkalow @ 2009-10-14 20:37 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jay Soffian, Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0910141616530.20122@xanadu.home>
On Wed, 14 Oct 2009, Nicolas Pitre wrote:
> On Wed, 14 Oct 2009, Daniel Barkalow wrote:
>
> > On Wed, 14 Oct 2009, Jay Soffian wrote:
> >
> > > $ git commit -m "blah"
> > > Cannot commit while not on any branch. Please use git commit -b <branch> to
> > > specify the name of a new branch to commit to, or use git commit -f to
> > > force a detached commit.
> >
> > The difference is that some experienced users depend on being able to
> > commit while not on a branch, and want to not get a warning for every
> > commit while not on a branch.
>
> I assume that the -f would silence any warning?
I suppose; I don't know if that would be acceptable to the relevant users.
It would certainly require script changes, but that's not an issue for
1.7.0, presumably.
I personally normally use the order:
$ git checkout origin/master
(change stuff, test)
$ git checkout -b my-topic
$ git commit
So I only care about detaching, not committing while detached, and I'm not
the right person to ask.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* submodule-summary
From: Junio C Hamano @ 2009-10-14 20:34 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Git Mailing List
In-Reply-To: <4AD61880.4040600@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Dscho condensed his initial patch with the interdiff you mentioned,
> additionally silenced a compiler warning and activated --first-parent.
> This follows as patch 1/4. Patches 2/4 to 4/4 contain my two bugfixes
> and the testcase i copied from submodule summary while adapting it to
> the changes of the output format.
I think 2 and 3 should be squashed into the first one. I do not see any
good reason for keeping initial "oops that was wrong" etched in stone,
once the review process has revealed obvious bugs and reasonable fixes
have been given to them. If the original author re-spun a v2 patch, that
is the normal thing that happens.
I am not happy with the option name --submodule-summary, by the way.
Naming this option --submodule-summary shows the confusion between this
series being the _latest_ great invention and this series being the _last_
great invention. I'd freely grant the former but would like to avoid the
latter.
I have this nagging suspicion that we should leave the door open for later
addition of --submodule=full that actually gives the patch text for the
entire aggregated tree, perhaps recursively. People may want to add even
more other useful modes that we do not think of right now. It would be
better to name this --submodule=shortlog or something.
If users like the shortlog mode (or the full mode) very much, perhaps the
current default output, which shows the differences between two commit
object names, can become a --submodule=summary (or --submodule=twoline)
mode later, and the shortlog mode could become the default.
> The remaining differences from the output shown by submodule summary are:
>
> 1) git diff shows only two dots for a fast forward (submodule summary
> always shows three)
> 2) git diff shows "Submodule" instead of a single '*' in the first line
> 3) git diff doesn't add a newline after each shortlog
> 4) submodule summary prints out the number of shortlog entries, this
> version does not
> 5) submodule summary can limit the number of shortlog lines, git diff
> can't do that right now
> 6) When files are replaced by a submodules or vice versa, git diff
> generates an extra hunk for the deleted/added file and one saying
> "(new submodule)"/"(submodule deleted)"
>
>> The output format needs to be described better here and also in
>> Documentation/diff-format.txt.
>
> Will do when it is clear which of the 6 differences should be fixed and
> which can stay.
Thanks.
^ permalink raw reply
* [PATCHv2] gitweb: linkify author/committer names with search
From: Stephen Boyd @ 2009-10-14 20:24 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Wincent Colaiuta
In-Reply-To: <1255486344-11891-1-git-send-email-bebarino@gmail.com>
It's nice to search for an author by merely clicking on their name in
gitweb. This is usually faster than selecting the name, copying the
selection, pasting it into the search box, selecting between
author/committer and then hitting enter.
Linkify the avatar icon in log/shortlog view because the icon is directly
adjacent to the name and thus more related. The same is not true
when in commit/tag view where the icon is farther away.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
This is based off next now that Giuseppe's patch is there.
Changes since v1:
* CSS hack has been cleaned up to only remove the link border from
avatar icons when actually linked.
* Checking for search capability to avoid generating search links (Wincent)
* Linking of name and email are separate in commit/commitdiff/tag views
The last one I figured I'd throw in because I'm doing it again.
gitweb/gitweb.css | 4 ++++
gitweb/gitweb.perl | 33 ++++++++++++++++++++++++++++-----
2 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 8faa94e..50067f2 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -32,6 +32,10 @@ img.avatar {
vertical-align: middle;
}
+a.list img.avatar {
+ border-style: none;
+}
+
div.page_header {
height: 25px;
padding: 8px;
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0c71ee8..6325b97 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1625,6 +1625,22 @@ sub git_get_avatar {
}
}
+sub format_search_author {
+ my $searchtext = shift;
+ my $searchtype = shift;
+ my $displaytext = shift;
+ my $have_search = gitweb_check_feature('search');
+ if ($have_search) {
+ return $cgi->a({-href => href(action=>"search", hash=>$hash,
+ searchtext=>$searchtext,
+ searchtype=>$searchtype), class=>"list"},
+ $displaytext);
+
+ } else {
+ return $displaytext;
+ }
+}
+
# format the author name of the given commit with the given tag
# the author name is chopped and escaped according to the other
# optional parameters (see chop_str).
@@ -1633,8 +1649,10 @@ sub format_author_html {
my $co = shift;
my $author = chop_and_escape_str($co->{'author_name'}, @_);
return "<$tag class=\"author\">" .
- git_get_avatar($co->{'author_email'}, -pad_after => 1) .
- $author . "</$tag>";
+ format_search_author($co->{'author_name'}, "author",
+ git_get_avatar($co->{'author_email'}, -pad_after => 1) .
+ $author) .
+ "</$tag>";
}
# format git diff header line, i.e. "diff --(git|combined|cc) ..."
@@ -3433,10 +3451,11 @@ sub git_print_authorship {
my $co = shift;
my %opts = @_;
my $tag = $opts{-tag} || 'div';
+ my $author = $co->{'author_name'};
my %ad = parse_date($co->{'author_epoch'}, $co->{'author_tz'});
print "<$tag class=\"author_date\">" .
- esc_html($co->{'author_name'}) .
+ format_search_author($author, "author", esc_html($author)) .
" [$ad{'rfc2822'}";
print_local_time(%ad) if ($opts{-localtime});
print "]" . git_get_avatar($co->{'author_email'}, -pad_before => 1)
@@ -3455,8 +3474,12 @@ sub git_print_authorship_rows {
@people = ('author', 'committer') unless @people;
foreach my $who (@people) {
my %wd = parse_date($co->{"${who}_epoch"}, $co->{"${who}_tz"});
- print "<tr><td>$who</td><td>" . esc_html($co->{$who}) . "</td>" .
- "<td rowspan=\"2\">" .
+ print "<tr><td>$who</td><td>" .
+ format_search_author($co->{"${who}_name"}, $who,
+ esc_html($co->{"${who}_name"})) . " " .
+ format_search_author($co->{"${who}_email"}, $who,
+ esc_html("<" . $co->{"${who}_email"} . ">")) .
+ "</td><td rowspan=\"2\">" .
git_get_avatar($co->{"${who}_email"}, -size => 'double') .
"</td></tr>\n" .
"<tr>" .
--
1.6.5.94.gcd2f3
^ permalink raw reply related
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Nicolas Pitre @ 2009-10-14 20:18 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Jay Soffian, Junio C Hamano, git
In-Reply-To: <alpine.LNX.2.00.0910141509200.32515@iabervon.org>
On Wed, 14 Oct 2009, Daniel Barkalow wrote:
> On Wed, 14 Oct 2009, Jay Soffian wrote:
>
> > $ git commit -m "blah"
> > Cannot commit while not on any branch. Please use git commit -b <branch> to
> > specify the name of a new branch to commit to, or use git commit -f to
> > force a detached commit.
>
> The difference is that some experienced users depend on being able to
> commit while not on a branch, and want to not get a warning for every
> commit while not on a branch.
I assume that the -f would silence any warning?
Nicolas
^ permalink raw reply
* [RFC PATCH] implement sample post-checkout hook to checkout new/unchanged submodules
From: Heiko Voigt @ 2009-10-14 20:12 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Peter Krefting, Git Mailing List
In-Reply-To: <4AD5F0B1.4000507@web.de>
Currently gits default behaviour is not to recursively update submodules
when they are unchanged in the working copy. This hook implements this
by comparing whether the current HEAD in the submodule is the same as
recorded in the commit we are coming from. It then initializes or
updates the submodule as necessary.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
On Wed, Oct 14, 2009 at 05:39:29PM +0200, Jens Lehmann wrote:
> Peter Krefting schrieb:
> > Jens Lehmann:
> >
> >> just calling "git submodule update" every time you want the submodule
> >> to be updated according to the state committed in the superproject
> >> will do the trick (but keep in mind that all referenced commits have
> >> to be accessible in the local clone of your submodule, so you might
> >> have to do a fetch there once in a while).
>
> BTW: unless you use the -N or --no-fetch option, git submodule update
> will do the fetch for you.
>
>
> > Is it possible to automate this from a hook or something else?
>
> Yep, you can use the post-checkout hook for that, just put a "git
> submodule update" in it.
Incidentially I have just been working on such a hook. Here is a patch
that implements it as a sample hook.
I tested most cases, but I have not worked with it productively so it
might have strange results in some cases. One I already found is that
post-checkout is not called after a merge so you need to add a
submodule update there as well.
cheers Heiko
templates/hooks--post-checkout.sample | 50 +++++++++++++++++++++++++++++++++
1 files changed, 50 insertions(+), 0 deletions(-)
create mode 100644 templates/hooks--post-checkout.sample
diff --git a/templates/hooks--post-checkout.sample b/templates/hooks--post-checkout.sample
new file mode 100644
index 0000000..9ffffa0
--- /dev/null
+++ b/templates/hooks--post-checkout.sample
@@ -0,0 +1,50 @@
+#!/bin/sh
+
+# if this is a file checkout we do nothing
+flag=$3
+if [ ! $flag ]
+then
+ exit 0
+fi
+
+# if this is the initial checkout also intialize submodules
+if [ $1 == "0000000000000000000000000000000000000000" ]; then
+ git submodule init
+ git submodule update
+ # after initial checkout we are done now
+ exit 0
+fi
+
+# update all submodules that where not modified beforehand
+# or did not exist
+prev_sha1=$1
+new_sha1=$2
+
+git ls-tree $new_sha1 | grep ^160000 |cut -f2 |
+while read submodule
+do
+ prev_submodule_sha1=$(git ls-tree $prev_sha1 |
+ grep " $submodule$" | cut -f1 | cut -d' ' -f3)
+ curr_submodule_sha1=$(cd "$submodule"; git rev-parse HEAD \
+ 2>/dev/null)
+
+ if [ -z "$prev_submodule_sha1" ]
+ then
+ git submodule init "$submodule"
+ git submodule update "$submodule"
+ continue
+ fi
+
+ if [ "$prev_submodule_sha1" = "$curr_submodule_sha1" ]
+ then
+ if [ -z "$(git config submodule."$submodule".url)" ]
+ then
+ git submodule init "$submodule"
+ fi
+
+ if [ "$(git diff $prev_sha1 $new_sha1 -- "$submodule")" ]
+ then
+ git submodule update "$submodule"
+ fi
+ fi
+done
--
1.6.5.rc1.12.gc72fe
^ permalink raw reply related
* Re: git-commit feature request: pass editor command line options
From: Matthew Cline @ 2009-10-14 20:03 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20091014172337.GE6115@genesis.frugalware.org>
On Wednesday 14 October 2009 10:23:38 am Miklos Vajna wrote:
> Hmm, what is the use-case when using an option --foo is useful when
> creating a commit, but not useful when crating a tag?
In my case, it's using a commit template which starts with a comment, so I
want to move the cursor down to the line below the comment.
^ permalink raw reply
* Re: Changing branches in supermodule does not affect submodule?
From: Junio C Hamano @ 2009-10-14 20:02 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List, Jens Lehmann
In-Reply-To: <alpine.DEB.2.00.0910140728420.16100@ds9.cixit.se>
Peter Krefting <peter@softwolves.pp.se> writes:
> Basically, I would like it to update all the submodules to the state
> recorded in the commit I move to, if they were in a clean state before
> I moved. I do not want it to change states if I do something like
>
> cd submodule
> # do some changes
> git commit
> cd ..
> git checkout -b newbranch
>
> because there I want the commit I made to the submodule to be recorded
> on the new branch I created. But then it was in a dirty state before I
> created the branch anyway, so that shouldn't be a problem.
My understanding is that the primary reason "git checkout $another_branch"
does not touch submodules (other than updating the commit object name
bound in the index in the superproject) is because we did not know what
people would want to happen when submodule support was introduced.
Now people have used submodules for a while, we can update this. I think
modelling the behaviour after how normal blobs are updated upon branch
switching would make sense.
So let's step back a bit and review what happens to a normal blob upon
branch switching. There are three cases for a path while switching
branches from A to B:
#1 The path is the same between A and B. In this case, whatever you have
for path in the index and in the work tree stay the same. Your local
modification is carried across branch switching.
This is already what we do with submodules. In cases #2 and #3 below,
path is different between A and B.
#2 You do not have any change to the path in either the index nor in the
work tree. The path is updated to B's version in the index and also
what you have in the work tree matches it.
Note that if B lacks the path, it is _removed_ from both the index and
the work tree.
#3 You have a change to the path in the index or in the work tree. The
branch switch is refused if the index does not match what is in B.
I think this also is already what we do with submodules.
With a reasonable definition of "have a change in the work tree" for a
submodule path, we can define a reasonable behaviour for updating the
submodules when a different branch is checked out in the superproject.
For a regular blob, having a change in the work tree is that the object
recorded in HEAD (in the superproject) is different from what you have in
the work tree. What should the definition be for a submodule?
The HEAD (in the submodule), the index (in the submodule) and the work
tree (in the submodule) form the "state" of what you have in the path, and
that corresponds to the "work tree state". So I think we can say that
there is no change in the work tree for a submodule at path P if all of
the following holds:
- the HEAD in the submodule matches the commit recorded for the path P
in the HEAD in the superproject;
- the index in the submodule matches the HEAD in the submodule; and
- the work tree in the submodule matches the index in the submodule.
With this definition, you should be able to patch "git checkout" to
recurse into the submodule directory for case #2.
As to the implementation, I'd suggest:
- the check between the submodule HEAD and what the superproject records
in the HEAD (the first condition above) be done inside the main process
(because we already have a working check for #3 to refuse branch
switching, I think it would be easier to implement this check by
comparison between the submodule HEAD and the superproject index).
- the check between the index and the HEAD in the submodule and the check
between the index and the work tree in the submodule (the second and
the third conditions above) be done in a subprocess that runs something
like "git status" via the run_command() interface; and
- the actual recursive checkout to happen in a subprocess that runs
another instance of "git checkout" via the run_command() interface.
There is one caveat. The potential removal of the work tree path in #2
may not be desirable for a submodule path, even if you do not have any
change to it (i.e. both the index and the work tree in the submodule match
the HEAD in the submodule), as you may have untracked files you would
rather want to keep in the submodule work tree.
^ permalink raw reply
* Re: [PATCH v3 3/8] imap-send: use run-command API for tunneling
From: Johannes Sixt @ 2009-10-14 19:58 UTC (permalink / raw)
To: kusmabite; +Cc: msysgit, git
In-Reply-To: <40aa078e0910131327q682c7044x854fec4de60b0c43@mail.gmail.com>
On Dienstag, 13. Oktober 2009, Erik Faye-Lund wrote:
> If I were to fix this, I'd prefer not using sh at all on Windows. I've
> seen that connect.c doesn't prepend "/bin/sh -c" at all, requiring
> tunnels to be self-contained scripts or native binaries, unless I'm
> mistaken. I'm not sure if this works at all on Windows, though. I just
> think that the assumption that sh is the shell that is going to run
> the tunnel is wrong to make, especially on Windows.
>
> I'm really unsure if it's worth the hassle.
We already depend on the existence of a Bourne shell for our scripted
commands. There are already more places in the code that run "sh"
than "/bin/sh".
-- Hannes
^ permalink raw reply
* Re: git hang with corrupted .pack
From: Nicolas Pitre @ 2009-10-14 18:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Andy Isaacson, git
In-Reply-To: <20091014180302.GL9261@spearce.org>
On Wed, 14 Oct 2009, Shawn O. Pearce wrote:
> Junio, can you please squash this in?
>
> diff --git a/t/t5303-pack-corruption-resilience.sh b/t/t5303-pack-corruption-resilience.sh
> index 5132d41..5f6cd4f 100755
> --- a/t/t5303-pack-corruption-resilience.sh
> +++ b/t/t5303-pack-corruption-resilience.sh
> @@ -275,4 +275,13 @@ test_expect_success \
> git cat-file blob $blob_2 > /dev/null &&
> git cat-file blob $blob_3 > /dev/null'
>
> +test_expect_success \
> + 'corrupting header to have too small output buffer fails unpack' \
> + 'create_new_pack &&
> + git prune-packed &&
> + printf "\262\001" | do_corrupt_object $blob_1 0 &&
> + test_must_fail git cat-file blob $blob_1 > /dev/null &&
> + test_must_fail git cat-file blob $blob_2 > /dev/null &&
> + test_must_fail git cat-file blob $blob_3 > /dev/null'
> +
> test_done
>
> --
I confirm this test without the fix reproduces the infinite loop (and
does stall the test suite).
Nicolas
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Junio C Hamano @ 2009-10-14 19:31 UTC (permalink / raw)
To: Jay Soffian
Cc: Johannes Schindelin, Jeff King, Thomas Rast, Euguess,
Mikael Magnusson, Matthieu Moy, git, Johannes Sixt
In-Reply-To: <76718490910140549l4a6b4f60je64d1b71a1a33d1d@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> What if instead we do something like this:
>
> $ git checkout v1.5.5
> Note: moving to 'v1.5.5' which isn't a local branch
> If you want to create a new branch from this checkout, you may do so
> (now or later) by using -b with the checkout command again. Example:
> git checkout -b <new_branch_name>
> HEAD is now at 1d2375d... GIT 1.5.5
> $ [edit foo.c]
> $ git add foo.c
> $ git commit -m "edited some file"
> Cannot commit to v1.5.5. Please use git commit -b <branch> to specify
> the name of a new branch to commit to, or use git commit --detach to
> force a detached commit.
>
> So we modify git to, by default, no longer allow creating a commit
> while detached or on a branch that cannot be committed to.
I'd probably object to such a change if there is no easy way to turn it
off per session (that means "expert mode" configuration variable, or a
command line option per "git commit" invocation, are not a viable escape
hatch), as I do it all the time, while reworking on an existing series.
E.g.
$ git checkout $(git merge-base master topic)
$ work on redoing topic
- cherry-picking parts from topic~$n
- editing
- committing
$ git show-branch HEAD topic
$ git branch -f topic
is a very common sequence of how I personally work, at day-job and also
while maintaining git itself.
I probably would not mind such a change if I can say "I am detaching now
in order to build on a non-branch. Do not bother me with unwarranted and
misguided helpfulness until I am done" once upfront when I perform the
first checkout.
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Daniel Barkalow @ 2009-10-14 19:15 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, git
In-Reply-To: <76718490910141156g440ee455t2e1db72ad72b7049@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1717 bytes --]
On Wed, 14 Oct 2009, Jay Soffian wrote:
> On Wed, Oct 14, 2009 at 12:44 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > $ git commit
> > You've been sightseeing "origin/master". The commit can't change that
> > value, so your commit isn't held in any branch. If you want to create
> > a branch to hold it, here's how.
> >
> > "git checkout origin/master" should be similar in complexity to
> > "svn checkout -r 8655"; the difference is that svn won't let you
> > commit then and git will but you'll need to understand the
> > implications if you do so. If you don't commit (because you don't want
> > to make any changes, because you don't think it would be possible, or
> > because you don't want to worry about what would happen), there's no
> > meaningful difference, and you don't need to be told.
>
> Huh, I hadn't seen this message before I wrote in a reply to
> "builtin-checkout: suggest creating local branch" that we do the
> following at commit, which I think is what you're suggesting:
>
> $ git commit -m "blah"
> Cannot commit while not on any branch. Please use git commit -b <branch> to
> specify the name of a new branch to commit to, or use git commit -f to
> force a detached commit.
The difference is that some experienced users depend on being able to
commit while not on a branch, and want to not get a warning for every
commit while not on a branch.
> I'm not sure that requires the complexity of remembering how the user
> got detached though?
What matters there is actually whether we got to the present state by
committing or not. It's also relevant to telling the user what they've got
checked out that isn't a branch.
-Daniel
*This .sif left intentionally blank*
^ permalink raw reply
* Re: git-commit feature request: pass editor command line options
From: Junio C Hamano @ 2009-10-14 19:11 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Matthew Cline, git
In-Reply-To: <20091014172337.GE6115@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Tue, Oct 13, 2009 at 09:58:51PM -0700, Matthew Cline <matt@nightrealms.com> wrote:
>>
>> I'd like to be able to have git-commit pass the commit-message editor command
>> line options which aren't passed to the editor for other usages. Right now
>> I have "co" aliased to "!sh -c 'GIT_EDITOR=git-commit-editor git commit'",
>> where git-commit-editor is a wrapper around my editor-of-choice which passes
>> the editor the command line options I want, but it'd be simpler and cleaner
>> if I could just set "commit.editor_options=-BAR". Or even let there be a
>> separate editor for commits, so I could do "core.editor=foo" and
>> "commit.editor=foo -BAR".
>
> Hmm, what is the use-case when using an option --foo is useful when
> creating a commit, but not useful when crating a tag?
>
> Apart from introducing inconsistency...
Not between commit and tag, but I can see you may want to auto-wrap for
log message but forbid auto-wrap when editing rebase insn sheet during
"rebase -i".
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: add global config section
From: Junio C Hamano @ 2009-10-14 19:10 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Felipe Contreras, git, J. Bruce Fields, Jonathan Nieder
In-Reply-To: <4AD5F7BE.9000704@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Well, Junio certainly is authoritative, and I don't want to risk any bad
Even though I usually call them "configuration variables", I do not
consider myself authoritative in this particular issue, as I did not care
about the wording myself that much. It is not like we have two (or three)
distinct concepts that the user need to be aware of among configuration
variable/option(/setting). In other words, I never thought consistently
sticking to one variant matters that much for this particular case, and
I've used the word very casually and interchangeably, but except in one
specific context---see below.
I am open to be corrected by Documentation/glossary.txt and other sources.
> 2d2465c (Add documentation for git-config-set, 2005-11-17)
>
> is the origin of that doc for git-config. I'm not just claiming it
> myself. That commit introduced "option", uses it in all but one place,
> and this never changed since then! [The ratio went up from 6:1 to 40:5]
> I have no objection to changing this established notion, but established
> it is. I haven't tracked down the use of option vs. variable in other
> places than git-config.txt and its predecessors.
I am Ok with calling them "configuration options", and I am also Ok with
calling them just "options" when it is clear from the context that we are
talking about configuration file.
The _only_ thing I deliberately do is to avoid calling them configuration
"options" when discussing "command line options override what you have in
the configuration file", but even there I would use "settings" and
"variables" interchangeably. E.g. both of these are fine with me:
The settings in your .git/config file will give the default when there
is no command line option given.
vs
The variables in your .git/config file will give the default when
there is no command line option given.
but personally I think it would make it less easier to follow if you
changed these "settings/variables" to "options".
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Jay Soffian @ 2009-10-14 18:56 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.2.00.0910140037570.32515@iabervon.org>
On Wed, Oct 14, 2009 at 12:44 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> $ git commit
> You've been sightseeing "origin/master". The commit can't change that
> value, so your commit isn't held in any branch. If you want to create
> a branch to hold it, here's how.
>
> "git checkout origin/master" should be similar in complexity to
> "svn checkout -r 8655"; the difference is that svn won't let you
> commit then and git will but you'll need to understand the
> implications if you do so. If you don't commit (because you don't want
> to make any changes, because you don't think it would be possible, or
> because you don't want to worry about what would happen), there's no
> meaningful difference, and you don't need to be told.
Huh, I hadn't seen this message before I wrote in a reply to
"builtin-checkout: suggest creating local branch" that we do the
following at commit, which I think is what you're suggesting:
$ git commit -m "blah"
Cannot commit while not on any branch. Please use git commit -b <branch> to
specify the name of a new branch to commit to, or use git commit -f to
force a detached commit.
I'm not sure that requires the complexity of remembering how the user
got detached though?
j.
^ permalink raw reply
* Re: [msysgit? bug] CRLF in info/grafts causes parse error
From: Junio C Hamano @ 2009-10-14 18:51 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <ecf590a0d9e21f480529f64e465825c5.squirrel@intranet.linagora.com>
"Yann Dirson" <ydirson@linagora.com> writes:
> When creating an info/grafts under windows, one typically gets a CRLF file.
> Then:
>
> * gitk loudly complains about "bad graft data"
> * "git log > /dev/null" does not report any problem
> * "git log > foo" does report the problem on sdterr, but exit code is still 0
>
> Recreating the graft as a LF file (eg with "echo" or "printf") causes the
> graft to be properly interpreted.
I do not see any reason to forbid trailing CR at the end of the line (for
that matter, any trailing whitespaces) in the said file.
How about doing this?
commit.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/commit.c b/commit.c
index fedbd5e..0db2124 100644
--- a/commit.c
+++ b/commit.c
@@ -132,8 +132,8 @@ struct commit_graft *read_graft_line(char *buf, int len)
int i;
struct commit_graft *graft = NULL;
- if (buf[len-1] == '\n')
- buf[--len] = 0;
+ while (isspace(buf[len-1]))
+ buf[--len] = '\0';
if (buf[0] == '#' || buf[0] == '\0')
return NULL;
if ((len + 1) % 41) {
^ permalink raw reply related
* Re: [msysgit? bug] crlf double-conversion on win32
From: Junio C Hamano @ 2009-10-14 18:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Eric Raible, git
In-Reply-To: <alpine.DEB.1.00.0910141601580.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> So I started some time ago to code a "git checkout --fix-crlf", but I
> am not really happy with the user interface. I think that Git should
> realize itself that something went wrong with the line endings. If I say
> "git reset --hard", it is just a bug in Git when it insists afterwards
> that the files are modified.
I tend to agree. "git reset --hard-without-cached-stat-info" that ignores
the cached stat information while it does the equivalent of the usual
"reset --hard" may be a reasonably safe and usable alternative for
"checkout --fix-crlf". When people see "reset --hard...", it will tell
them that this is about matching the index and the work tree with the
named commit, as opposed to "checkout", so enhancing "reset" would make
more sense, I think.
Obviously, I am not seriously suggesting "--hard-without-cached-stat-info"
as the name of this mode of operation, and you need to come up with a
better one. But it is better than "--crlf", as it is not limited to the
crlf conversion that brings the inconsistency you will be resetting away.
It arises from any silent invalidation of the cached stat optimization
after you touch attributes and config.
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Jeff King @ 2009-10-14 18:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Daniel Barkalow, git
In-Reply-To: <7vljjdese3.fsf@alter.siamese.dyndns.org>
On Wed, Oct 14, 2009 at 11:34:44AM -0700, Junio C Hamano wrote:
> >> AFAIR we still remember HEAD to be a symlink.
> >
> > I think that has been abandoned for detached HEAD (that is, if you
> > support only symlinked HEAD, then you cannot detach at all). But I might
> > be wrong. It has been a while since I looked at that code.
>
> If I understand what Daniel is doing correctly, the idea is to keep this
> extra information only while the HEAD is detached, no? "HEAD itself
> could be a symlink" is an irrelevant issue, isn't it?
Right. That is what I was trying to say, but somehow it didn't come out
very clearly.
-Peff
^ permalink raw reply
* [PATCH 4/4] add tests for git diff --submodule-summary
From: Jens Lehmann @ 2009-10-14 18:32 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4AD61880.4040600@web.de>
Copied from the submodule summary test and changed to reflect the
differences in the output of git diff --submodule-summary.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
t/t4041-diff-submodule-summary.sh | 206 +++++++++++++++++++++++++++++++++++++
1 files changed, 206 insertions(+), 0 deletions(-)
create mode 100755 t/t4041-diff-submodule-summary.sh
diff --git a/t/t4041-diff-submodule-summary.sh b/t/t4041-diff-submodule-summary.sh
new file mode 100755
index 0000000..dbb19eb
--- /dev/null
+++ b/t/t4041-diff-submodule-summary.sh
@@ -0,0 +1,206 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Jens Lehmann, based on t7401 by Ping Yin
+#
+
+test_description='Summary support for submodules implemented in git diff
+
+This test tries to verify the sanity of --submodule-summary option of git diff.
+'
+
+. ./test-lib.sh
+
+add_file () {
+ sm=$1
+ shift
+ owd=$(pwd)
+ cd "$sm"
+ for name; do
+ echo "$name" > "$name" &&
+ git add "$name" &&
+ test_tick &&
+ git commit -m "Add $name"
+ done >/dev/null
+ git rev-parse --verify HEAD | cut -c1-7
+ cd "$owd"
+}
+commit_file () {
+ test_tick &&
+ git commit "$@" -m "Commit $*" >/dev/null
+}
+
+test_create_repo sm1 &&
+add_file . foo >/dev/null
+
+head1=$(add_file sm1 foo1 foo2)
+
+test_expect_success 'added submodule' "
+ git add sm1 &&
+ git diff-index -p --submodule-summary HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 0000000...$head1 (new submodule)
+EOF
+"
+
+commit_file sm1 &&
+head2=$(add_file sm1 foo3)
+
+test_expect_success 'modified submodule(forward)' "
+ git diff-index -p --submodule-summary HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head1..$head2:
+ > Add foo3
+EOF
+"
+
+test_expect_success 'modified submodule(forward)' "
+ git diff --submodule-summary >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head1..$head2:
+ > Add foo3
+EOF
+"
+
+commit_file sm1 &&
+cd sm1 &&
+git reset --hard HEAD~2 >/dev/null &&
+head3=$(git rev-parse --verify HEAD | cut -c1-7) &&
+cd ..
+
+test_expect_success 'modified submodule(backward)' "
+ git diff-index -p --submodule-summary HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head2..$head3 (rewind):
+ < Add foo3
+ < Add foo2
+EOF
+"
+
+head4=$(add_file sm1 foo4 foo5) &&
+head4_full=$(GIT_DIR=sm1/.git git rev-parse --verify HEAD)
+test_expect_success 'modified submodule(backward and forward)' "
+ git diff-index -p --submodule-summary HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head2...$head4:
+ > Add foo5
+ > Add foo4
+ < Add foo3
+ < Add foo2
+EOF
+"
+
+commit_file sm1 &&
+mv sm1 sm1-bak &&
+echo sm1 >sm1 &&
+head5=$(git hash-object sm1 | cut -c1-7) &&
+git add sm1 &&
+rm -f sm1 &&
+mv sm1-bak sm1
+
+test_expect_success 'typechanged submodule(submodule->blob), --cached' "
+ git diff --submodule-summary --cached >actual &&
+ diff actual - <<-EOF
+Submodule sm1 41fbea9...0000000 (submodule deleted)
+diff --git a/sm1 b/sm1
+new file mode 100644
+index 0000000..9da5fb8
+--- /dev/null
++++ b/sm1
+@@ -0,0 +1 @@
++sm1
+EOF
+"
+
+test_expect_success 'typechanged submodule(submodule->blob)' "
+ git diff --submodule-summary >actual &&
+ diff actual - <<-EOF
+diff --git a/sm1 b/sm1
+deleted file mode 100644
+index 9da5fb8..0000000
+--- a/sm1
++++ /dev/null
+@@ -1 +0,0 @@
+-sm1
+Submodule sm1 0000000...$head4 (new submodule)
+EOF
+"
+
+rm -rf sm1 &&
+git checkout-index sm1
+test_expect_success 'typechanged submodule(submodule->blob)' "
+ git diff-index -p --submodule-summary HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head4...0000000 (submodule deleted)
+diff --git a/sm1 b/sm1
+new file mode 100644
+index 0000000..$head5
+--- /dev/null
++++ b/sm1
+@@ -0,0 +1 @@
++sm1
+EOF
+"
+
+rm -f sm1 &&
+test_create_repo sm1 &&
+head6=$(add_file sm1 foo6 foo7)
+test_expect_success 'nonexistent commit' "
+ git diff-index -p --submodule-summary HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head4...$head6 (commits not present)
+EOF
+"
+
+commit_file
+test_expect_success 'typechanged submodule(blob->submodule)' "
+ git diff-index -p --submodule-summary HEAD >actual &&
+ diff actual - <<-EOF
+diff --git a/sm1 b/sm1
+deleted file mode 100644
+index $head5..0000000
+--- a/sm1
++++ /dev/null
+@@ -1 +0,0 @@
+-sm1
+Submodule sm1 0000000...$head6 (new submodule)
+EOF
+"
+
+commit_file sm1 &&
+rm -rf sm1
+test_expect_success 'deleted submodule' "
+ git diff-index -p --submodule-summary HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head6...0000000 (submodule deleted)
+EOF
+"
+
+test_create_repo sm2 &&
+head7=$(add_file sm2 foo8 foo9) &&
+git add sm2
+
+test_expect_success 'multiple submodules' "
+ git diff-index -p --submodule-summary HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head6...0000000 (submodule deleted)
+Submodule sm2 0000000...$head7 (new submodule)
+EOF
+"
+
+test_expect_success 'path filter' "
+ git diff-index -p --submodule-summary HEAD sm2 >actual &&
+ diff actual - <<-EOF
+Submodule sm2 0000000...$head7 (new submodule)
+EOF
+"
+
+commit_file sm2
+test_expect_success 'given commit' "
+ git diff-index -p --submodule-summary HEAD^ >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head6...0000000 (submodule deleted)
+Submodule sm2 0000000...$head7 (new submodule)
+EOF
+"
+
+test_done
--
1.6.5.4.g707c
^ permalink raw reply related
* Re: What's cooking in git.git (Oct 2009, #02; Sun, 11)
From: Jens Lehmann @ 2009-10-14 18:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vfx9pmhae.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> * js/diff-verbose-submodule (2009-10-04) 1 commit.
> - Add the --submodule-summary option to the diff option family
>
> Dscho sounded like he has some corrections after list comments, but I did
> not pick up his interdiff in the middle.
Dscho condensed his initial patch with the interdiff you mentioned,
additionally silenced a compiler warning and activated --first-parent.
This follows as patch 1/4. Patches 2/4 to 4/4 contain my two bugfixes
and the testcase i copied from submodule summary while adapting it to
the changes of the output format.
The remaining differences from the output shown by submodule summary are:
1) git diff shows only two dots for a fast forward (submodule summary
always shows three)
2) git diff shows "Submodule" instead of a single '*' in the first line
3) git diff doesn't add a newline after each shortlog
4) submodule summary prints out the number of shortlog entries, this
version does not
5) submodule summary can limit the number of shortlog lines, git diff
can't do that right now
6) When files are replaced by a submodules or vice versa, git diff
generates an extra hunk for the deleted/added file and one saying
"(new submodule)"/"(submodule deleted)"
> The output format needs to be described better here and also in
> Documentation/diff-format.txt.
Will do when it is clear which of the 6 differences should be fixed and
which can stay.
Jens Lehmann (3):
fix indentation depth for git diff --submodule-summary
fix output for deleted submodules in git diff --submodule-summary
add tests for git diff --submodule-summary
Johannes Schindelin (1):
Add the --submodule-summary option to the diff option family
Documentation/diff-options.txt | 4 +
Makefile | 2 +
diff.c | 14 +++
diff.h | 3 +
submodule.c | 113 ++++++++++++++++++++
submodule.h | 8 ++
t/t4041-diff-submodule-summary.sh | 206 +++++++++++++++++++++++++++++++++++++
7 files changed, 350 insertions(+), 0 deletions(-)
create mode 100644 submodule.c
create mode 100644 submodule.h
create mode 100755 t/t4041-diff-submodule-summary.sh
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Junio C Hamano @ 2009-10-14 18:34 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <20091014153934.GA3680@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Oct 14, 2009 at 12:33:22PM +0200, Johannes Schindelin wrote:
>
>> > > +char *get_detached_head_string(void)
>> > > +{
>> > > + char *filename = git_path("DETACH_NAME");
>> > > + struct stat st;
>> > > + if (stat(filename, &st) || !S_ISREG(st.st_mode))
>> > > + return NULL;
>> > > + struct strbuf buf = STRBUF_INIT;
>> > > + strbuf_read_file(&buf, filename, st.st_size);
>> > > + strbuf_trim(&buf);
>> > > + return strbuf_detach(&buf, 0);
>> > > +}
>> >
>> > Would it hurt to tuck this information into HEAD itself, as we already
>> > put arbitrary text into FETCH_HEAD?
>>
>> AFAIR we still remember HEAD to be a symlink.
>
> I think that has been abandoned for detached HEAD (that is, if you
> support only symlinked HEAD, then you cannot detach at all). But I might
> be wrong. It has been a while since I looked at that code.
If I understand what Daniel is doing correctly, the idea is to keep this
extra information only while the HEAD is detached, no? "HEAD itself
could be a symlink" is an irrelevant issue, isn't it?
^ permalink raw reply
* [PATCH 1/4] Add the --submodule-summary option to the diff option family
From: Jens Lehmann @ 2009-10-14 18:30 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4AD61880.4040600@web.de>
Now you can see the submodule summaries inlined in the diff, instead of
not-quite-helpful SHA-1 pairs.
The format imitates what "git submodule summary" shows.
To do that, <path>/.git/objects/ is added to the alternate object
databases (if that directory exists).
This option was requested by Jens Lehmann at the GitTogether in Berlin.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/diff-options.txt | 4 ++
Makefile | 2 +
diff.c | 14 +++++
diff.h | 3 +
submodule.c | 113 ++++++++++++++++++++++++++++++++++++++++
submodule.h | 8 +++
6 files changed, 144 insertions(+), 0 deletions(-)
create mode 100644 submodule.c
create mode 100644 submodule.h
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 9276fae..5fcc5a8 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -87,6 +87,10 @@ endif::git-format-patch[]
Show only names and status of changed files. See the description
of the `--diff-filter` option on what the status letters mean.
+--submodule-summary::
+ Instead of showing pairs of commit names, list the commits in that
+ commit range in the same style as linkgit:git-submodule[1].
+
--color::
Show colored diff.
diff --git a/Makefile b/Makefile
index fea237b..2356de4 100644
--- a/Makefile
+++ b/Makefile
@@ -452,6 +452,7 @@ LIB_H += sideband.h
LIB_H += sigchain.h
LIB_H += strbuf.h
LIB_H += string-list.h
+LIB_H += submodule.h
LIB_H += tag.h
LIB_H += transport.h
LIB_H += tree.h
@@ -550,6 +551,7 @@ LIB_OBJS += sideband.o
LIB_OBJS += sigchain.o
LIB_OBJS += strbuf.o
LIB_OBJS += string-list.o
+LIB_OBJS += submodule.o
LIB_OBJS += symlinks.o
LIB_OBJS += tag.o
LIB_OBJS += trace.o
diff --git a/diff.c b/diff.c
index e1be189..bcf2f77 100644
--- a/diff.c
+++ b/diff.c
@@ -13,6 +13,7 @@
#include "utf8.h"
#include "userdiff.h"
#include "sigchain.h"
+#include "submodule.h"
#ifdef NO_FAST_WORKING_DIRECTORY
#define FAST_WORKING_DIRECTORY 0
@@ -1453,6 +1454,17 @@ static void builtin_diff(const char *name_a,
const char *a_prefix, *b_prefix;
const char *textconv_one = NULL, *textconv_two = NULL;
+ if (DIFF_OPT_TST(o, SUMMARIZE_SUBMODULES) &&
+ (!one->mode || S_ISGITLINK(one->mode)) &&
+ (!two->mode || S_ISGITLINK(two->mode))) {
+ const char *del = diff_get_color_opt(o, DIFF_FILE_OLD);
+ const char *add = diff_get_color_opt(o, DIFF_FILE_NEW);
+ show_submodule_summary(o->file, one ? one->path : two->path,
+ one->sha1, two->sha1,
+ del, add, reset);
+ return;
+ }
+
if (DIFF_OPT_TST(o, ALLOW_TEXTCONV)) {
textconv_one = get_textconv(one);
textconv_two = get_textconv(two);
@@ -2640,6 +2652,8 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
DIFF_OPT_CLR(options, ALLOW_TEXTCONV);
else if (!strcmp(arg, "--ignore-submodules"))
DIFF_OPT_SET(options, IGNORE_SUBMODULES);
+ else if (!strcmp(arg, "--submodule-summary"))
+ DIFF_OPT_SET(options, SUMMARIZE_SUBMODULES);
/* misc options */
else if (!strcmp(arg, "-z"))
diff --git a/diff.h b/diff.h
index 6616877..9019f6f 100644
--- a/diff.h
+++ b/diff.h
@@ -66,6 +66,9 @@ typedef void (*diff_format_fn_t)(struct diff_queue_struct *q,
#define DIFF_OPT_DIRSTAT_CUMULATIVE (1 << 19)
#define DIFF_OPT_DIRSTAT_BY_FILE (1 << 20)
#define DIFF_OPT_ALLOW_TEXTCONV (1 << 21)
+
+#define DIFF_OPT_SUMMARIZE_SUBMODULES (1 << 23)
+
#define DIFF_OPT_TST(opts, flag) ((opts)->flags & DIFF_OPT_##flag)
#define DIFF_OPT_SET(opts, flag) ((opts)->flags |= DIFF_OPT_##flag)
#define DIFF_OPT_CLR(opts, flag) ((opts)->flags &= ~DIFF_OPT_##flag)
diff --git a/submodule.c b/submodule.c
new file mode 100644
index 0000000..129583b
--- /dev/null
+++ b/submodule.c
@@ -0,0 +1,113 @@
+#include "cache.h"
+#include "submodule.h"
+#include "dir.h"
+#include "diff.h"
+#include "commit.h"
+#include "revision.h"
+
+int add_submodule_odb(const char *path)
+{
+ struct strbuf objects_directory = STRBUF_INIT;
+ struct alternate_object_database *alt_odb;
+
+ strbuf_addf(&objects_directory, "%s/.git/objects/", path);
+ if (!is_directory(objects_directory.buf))
+ return -1;
+
+ /* avoid adding it twice */
+ for (alt_odb = alt_odb_list; alt_odb; alt_odb = alt_odb->next)
+ if (alt_odb->name - alt_odb->base == objects_directory.len &&
+ !strncmp(alt_odb->base, objects_directory.buf,
+ objects_directory.len))
+ return 0;
+
+ alt_odb = xmalloc(objects_directory.len + 42 + sizeof(*alt_odb));
+ alt_odb->next = alt_odb_list;
+ strcpy(alt_odb->base, objects_directory.buf);
+ alt_odb->name = alt_odb->base + objects_directory.len;
+ alt_odb->name[2] = '/';
+ alt_odb->name[40] = '\0';
+ alt_odb->name[41] = '\0';
+ alt_odb_list = alt_odb;
+ prepare_alt_odb();
+ return 0;
+}
+
+void show_submodule_summary(FILE *f, const char *path,
+ unsigned char one[20], unsigned char two[20],
+ const char *del, const char *add, const char *reset)
+{
+ struct rev_info rev;
+ struct commit *commit, *left = left, *right;
+ struct commit_list *merge_bases, *list;
+ const char *message = NULL;
+ struct strbuf sb = STRBUF_INIT;
+ static const char *format = " %m %s";
+ int fast_forward = 0, fast_backward = 0;
+
+ if (add_submodule_odb(path))
+ message = "(not checked out)";
+ else if (is_null_sha1(one))
+ message = "(new submodule)";
+ else if (is_null_sha1(two))
+ message = "(submodule deleted)";
+ else if (!(left = lookup_commit_reference(one)) ||
+ !(right = lookup_commit_reference(two)))
+ message = "(commits not present)";
+
+ if (!message) {
+ init_revisions(&rev, NULL);
+ setup_revisions(0, NULL, &rev, NULL);
+ rev.left_right = 1;
+ rev.first_parent_only = 1;
+ left->object.flags |= SYMMETRIC_LEFT;
+ add_pending_object(&rev, &left->object, path);
+ add_pending_object(&rev, &right->object, path);
+ merge_bases = get_merge_bases(left, right, 1);
+ if (merge_bases) {
+ if (merge_bases->item == left)
+ fast_forward = 1;
+ else if (merge_bases->item == right)
+ fast_backward = 1;
+ }
+ for (list = merge_bases; list; list = list->next) {
+ list->item->object.flags |= UNINTERESTING;
+ add_pending_object(&rev, &list->item->object,
+ sha1_to_hex(list->item->object.sha1));
+ }
+ if (prepare_revision_walk(&rev))
+ message = "(revision walker failed)";
+ }
+
+ strbuf_addf(&sb, "Submodule %s %s..", path,
+ find_unique_abbrev(one, DEFAULT_ABBREV));
+ if (!fast_backward && !fast_forward)
+ strbuf_addch(&sb, '.');
+ strbuf_addf(&sb, "%s", find_unique_abbrev(two, DEFAULT_ABBREV));
+ if (message)
+ strbuf_addf(&sb, " %s\n", message);
+ else
+ strbuf_addf(&sb, "%s:\n", fast_backward ? " (rewind)" : "");
+ fwrite(sb.buf, sb.len, 1, f);
+
+ if (!message) {
+ while ((commit = get_revision(&rev))) {
+ strbuf_setlen(&sb, 0);
+ if (commit->object.flags & SYMMETRIC_LEFT) {
+ if (del)
+ strbuf_addstr(&sb, del);
+ }
+ else if (add)
+ strbuf_addstr(&sb, add);
+ format_commit_message(commit, format, &sb,
+ rev.date_mode);
+ if (reset)
+ strbuf_addstr(&sb, reset);
+ strbuf_addch(&sb, '\n');
+ fprintf(f, "%s", sb.buf);
+ }
+ clear_commit_marks(left, ~0);
+ clear_commit_marks(right, ~0);
+ }
+ strbuf_release(&sb);
+}
diff --git a/submodule.h b/submodule.h
new file mode 100644
index 0000000..4c0269d
--- /dev/null
+++ b/submodule.h
@@ -0,0 +1,8 @@
+#ifndef SUBMODULE_H
+#define SUBMODULE_H
+
+void show_submodule_summary(FILE *f, const char *path,
+ unsigned char one[20], unsigned char two[20],
+ const char *del, const char *add, const char *reset);
+
+#endif
--
1.6.5.4.g707c
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox