* 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: [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: [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: 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] 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: [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: 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 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: 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: 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
* [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: [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
* [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
* 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
* 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
* 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: [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: 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: 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: submodule-summary
From: Jens Lehmann @ 2009-10-14 21:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vfx9lbtpf.fsf_-_@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> 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.
Right, will do.
> 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.
Good point. (Personally i like the options --submodule=shortlog and
--submodule=twoline. Because IMHO --submodule=summary could make
people expect similar output to git submodule summary, no?).
Thanks for your feedback, will send new patches soon.
^ permalink raw reply
* Re: git-commit feature request: pass editor command line options
From: Miklos Vajna @ 2009-10-14 22:12 UTC (permalink / raw)
To: Matthew Cline; +Cc: git
In-Reply-To: <200910141303.01485.matt@nightrealms.com>
[-- Attachment #1: Type: text/plain, Size: 648 bytes --]
On Wed, Oct 14, 2009 at 01:03:01PM -0700, Matthew Cline <matt@nightrealms.com> wrote:
> 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.
Then rebase, tag, add -e and even commit --amend would use core.editor,
while commit alone would use commit.editor, right?
A minor confusion would be that git commit --amend would not use
commit.editor. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.5
From: Jakub Narebski @ 2009-10-14 22:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wfi1fya.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> The latest feature release GIT 1.6.5 is available at the usual
> places:
>
> http://www.kernel.org/pub/software/scm/git/
>
> git-1.6.5.tar.{gz,bz2} (source tarball)
> git-htmldocs-1.6.5.tar.{gz,bz2} (preformatted docs)
> git-manpages-1.6.5.tar.{gz,bz2} (preformatted docs)
>
> The RPM binary packages for a few architectures are found in:
>
> RPMS/$arch/git-*-1.6.5-1.fc9.$arch.rpm (RPM)
>
> This cycle took a bit longer than I hoped, but here it is. We already
> have some new features cooking in 'next', and I expect we may be able to
> have 1.6.6 by the end of the year.
Compiling git from source RPM git-1.6.5-1.fc9.src.rpm using
$ rpmbuild --rebuild git-1.6.5-1.fc9.src.rpm
fails with the following error:
SUBDIR perl
/usr/bin/perl Makefile.PL PREFIX='/usr'
Only one of PREFIX or INSTALL_BASE can be given. Not both.
make[1]: *** [perl.mak] Error 2
make: *** [perl/perl.mak] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.53174 (%build)
Compiling git from source with
$ make prefix=/home/local/git \
bindir=/home/local/git \
gitexecdir=/home/local/git \
template_dir=/home/local/git \
GIT_PYTHON_DIR=/home/local/git
gives the same error.
It might matter that I am using modern Perl way of installing Perl
modules locally, via local::lib, with ~/perl5/.modulebuildrc
containing
install --install_base /home/jnareb/perl5
and I have
export MODULEBUILDRC="$HOME/perl5/.modulebuildrc"
export PERL_MM_OPT="INSTALL_BASE=$HOME/perl5"
Doing
$ unset PERL_MM_OPT
before compiling (from SRPMS) made compilation pass this stage,
and finally succeed.
I guess that perl/Makefile (or rather the file that generates it)
should unset PERL_MM_OPT, or use INSTALL_BASE as DESTDIR rather
than fiddling with PREFIX.
But I am not a Perl hacker
------------------------------------------------------------
perl, v5.8.6
ExtUtils::MakeMaker 6.54 (local)
ExtUtils::MakeMaker 6.17 (global)
export MODULEBUILDRC="$HOME/perl5/.modulebuildrc"
export PERL_MM_OPT="INSTALL_BASE=$HOME/perl5"
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] git add -e documentation: rephrase note
From: Miklos Vajna @ 2009-10-14 22:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The original note probably wanted to suggest "edit the patch with care",
but actually suggested just editing the first characters on certain
lines, which is a pretty bad suggestion.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/git-add.txt | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 45ebf87..daa1add 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -86,9 +86,8 @@ OPTIONS
edit it. After the editor was closed, adjust the hunk headers
and apply the patch to the index.
+
-*NOTE*: Obviously, if you change anything else than the first character
-on lines beginning with a space or a minus, the patch will no longer
-apply.
+*NOTE*: Obviously, if you change the first characters of the lines or
+lines beginning with a space or a minus, the patch will no longer apply.
-u::
--update::
--
1.6.4
^ permalink raw reply related
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Junio C Hamano @ 2009-10-14 22:34 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Daniel Barkalow, Jay Soffian, git
In-Reply-To: <alpine.LFD.2.00.0910141647390.20122@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> 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.
No, I do not want an expert mode. I can probably live with "per session"
setting, that makes me decide to set or not set it when I detach, though.
^ permalink raw reply
* why no "ignore" command on git
From: Ralf Thielow @ 2009-10-14 22:35 UTC (permalink / raw)
To: git
Hello,
why does git don't have an "ignore" command, to ignore some files or
directories all the time.
In many project file structures you have IDE specified project files
or directories which
should not be tracked on git. All the time git says that you can add
these files, this is not
usable if you want to add many files with the "git add ." command.
I read on some pages by a google search that you can create
a ".gitignore" directory or something like that. But you had to do
this manually.
why there is no "ignore" command on git?
best regards
Ralf
^ 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