* [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
* Re: submodule-summary
From: Junio C Hamano @ 2009-10-14 22:42 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Git Mailing List
In-Reply-To: <4AD6423D.10307@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> 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?).
Well, _that_ is something we could fix in "git submodule", isn't it?
Right now, the only way "git submodule" command can summarize the changes
is by showing a left-right shortlog, but it wouldn't be so inconceivable
that somebody may come up with different and equally useful way to show
them, e.g. diffstat, and at that point, we would probably want to have
"git submodule summary --stat" or "git submodule summary --shortlog" (and
the default being --shortlog).
I am _not_ married to the naming "shortlog", by the way, and shortlog is
rather a bad name for it. Sorry for suggesting it; it is quite different
from the actual "git shortlog" command output (and no I am not suggesting
to make the output similar to shortlog), but rather is more similar to
"log --left-right --oneline". But I think you got the point.
^ permalink raw reply
* Re: why no "ignore" command on git
From: Scott Wiersdorf @ 2009-10-14 23:02 UTC (permalink / raw)
To: git
In-Reply-To: <42efdea40910141535g23a50b87p9b6c4a0fde7e842e@mail.gmail.com>
git does have a command to ignore files and directories: it's called
'emacs' (or 'vim' on some systems).
Seriously, the .gitignore file can contain a complex set of patterns
to ignore, and you can have .gitignore files at lower directories in a
hierarchy to override higher ones. This isn't something easily
contained in a simple command.
Scott
On Thu, Oct 15, 2009 at 12:35:23AM +0200, Ralf Thielow wrote:
> 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
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Scott Wiersdorf
<scott@perlcode.org>
^ permalink raw reply
* Re: [PATCH] git add -e documentation: rephrase note
From: Jeff King @ 2009-10-14 23:04 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <20091014222628.GK6115@genesis.frugalware.org>
On Thu, Oct 15, 2009 at 12:26:28AM +0200, Miklos Vajna wrote:
> 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.
The intent of "-e" is to pick and choose lines of the diff to apply, or
even to munge the lines. So it is safe to:
- remove lines with a '+' (don't stage the addition)
- munge any lines with a '+' (stage modified contents)
- add lines with a '+' (stage an addition)
- convert lines with a ' ' to '-' (stage removal)
- convert lines with a '-' to ' ' (don't stage removal)
It is a bad idea to:
- delete '-' lines
- delete ' ' lines
- add ' ' or '-' line
- munge the contents of ' ' or '-' lines
But that is just off the top of my head; perhaps others can come up with
corner cases where one of the safe things breaks.
> -*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.
So this is warning about changing or deleting ' ' or '-' lines, which is
good. But you can change the first characters of those lines, but only
by interchanging the two. So I think both the previous text and your
text don't cover all cases.
Maybe it makes sense instead to do a quick overview of what is OK and
what is not (like the list above).
-Peff
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Jeff King @ 2009-10-14 23:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Daniel Barkalow, Jay Soffian, git
In-Reply-To: <7vws2xa9lu.fsf@alter.siamese.dyndns.org>
On Wed, Oct 14, 2009 at 03:34:05PM -0700, Junio C Hamano wrote:
> > 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.
That makes the most sense to me. If "git checkout" could write metadata
into HEAD (or into DETACH_HEAD, as in Daniel's patch), then checkout
could record an "ok to commit" bit. And could also be used to change it
after the fact. E.g.:
$ git checkout --detach=commit origin/master
$ git commit ;# should be ok
$ git checkout --detach=examine origin/master
$ git commit ;# complain
$ git checkout --detach=commit HEAD
$ git commit ;# ok
I guess something like "rebase" should detach with "ok to commit", since
it is planning on attaching the commits later. I'm not sure about "git
bisect". I guess probably it should be "not ok to commit" to be on the
safe side, and then somebody can "git checkout --detach=commit" if they
want to.
-Peff
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Nicolas Pitre @ 2009-10-14 23:34 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Daniel Barkalow, Jay Soffian, git
In-Reply-To: <20091014230934.GC29664@coredump.intra.peff.net>
On Wed, 14 Oct 2009, Jeff King wrote:
> On Wed, Oct 14, 2009 at 03:34:05PM -0700, Junio C Hamano wrote:
>
> > > 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.
>
> That makes the most sense to me. If "git checkout" could write metadata
> into HEAD (or into DETACH_HEAD, as in Daniel's patch), then checkout
> could record an "ok to commit" bit. And could also be used to change it
> after the fact. E.g.:
>
> $ git checkout --detach=commit origin/master
> $ git commit ;# should be ok
>
> $ git checkout --detach=examine origin/master
> $ git commit ;# complain
> $ git checkout --detach=commit HEAD
> $ git commit ;# ok
>
> I guess something like "rebase" should detach with "ok to commit", since
> it is planning on attaching the commits later. I'm not sure about "git
> bisect". I guess probably it should be "not ok to commit" to be on the
> safe side, and then somebody can "git checkout --detach=commit" if they
> want to.
Whatever is done about this... I'm afraid Git will end up less useful as
operations that were possible before won't be anymore for "security's
sake" unless some obnoxious override mode is involved.
Isn't the reflog already dealing with the security issue by making sure
that nothing is "lost"?
Can't the user confusion be dealt with through some means other than
making the tool less flexible? I don't mind extra help message to be
displayed after a headless commit is made for example. But trying to
make the tool more friendly should perhaps come from better education
rather than added restrictions.
My thoughts only.
Nicolas
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Eric Raible @ 2009-10-14 23:52 UTC (permalink / raw)
To: git
In-Reply-To: <7v7huxbtbk.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster <at> pobox.com> writes:
> 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.
I'm missing something fundamental here, I think.
I simply don't see the advantage of branching after committing
over branching before committing.
At worst, a temporary is cheap, eh? So what is the value
of even allowing committing while HEAD is detached
(aside from the historical argument)?
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Junio C Hamano @ 2009-10-15 0:56 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Jeff King, Junio C Hamano, Daniel Barkalow, Jay Soffian, git
In-Reply-To: <alpine.LFD.2.00.0910141926170.20122@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> Can't the user confusion be dealt with through some means other than
> making the tool less flexible? I don't mind extra help message to be
> displayed after a headless commit is made for example. But trying to
> make the tool more friendly should perhaps come from better education
> rather than added restrictions.
>
> My thoughts only.
I actually share that but there apparently are people who have given up on
the education route.
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Jeff King @ 2009-10-15 1:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Daniel Barkalow, Jay Soffian, git
In-Reply-To: <7viqeha2zv.fsf@alter.siamese.dyndns.org>
On Wed, Oct 14, 2009 at 05:56:52PM -0700, Junio C Hamano wrote:
> Nicolas Pitre <nico@fluxnic.net> writes:
>
> > Can't the user confusion be dealt with through some means other than
> > making the tool less flexible? I don't mind extra help message to be
> > displayed after a headless commit is made for example. But trying to
> > make the tool more friendly should perhaps come from better education
> > rather than added restrictions.
> >
> > My thoughts only.
>
> I actually share that but there apparently are people who have given up on
> the education route.
I am personally undecided on this issue (my "this is the best option"
was the best of "a -f switch to commit, an 'expert' config option', or a
session-based option to commit").
But we really seem to have reached an impasse with how to proceed with
git ui.
People like Dscho are fed up with user complaints about parts of git
that can be unfriendly to new users. And I can understand that. There
_is_ a perception that git is hard for beginners to use, and I don't
think that perception is entirely without merit. We expect the user to
understand the basic concepts of git, like history graphs, named refs
versus detached heads, tracking refs, the index, etc.
At the same time, I think that is what many of us _like_ about git. It
is based around simple and powerful concepts, and it doesn't get in your
way when you want to use those concepts in a powerful and flexible
manner. And I can understand resistance to making those features hard or
inconvenient to access; detached HEADs were invented for a reason, and
we want to use them.
So what is the right way to mediate between those desires? We have tried
or suggested several options, including:
1. Educate users. Keep exposing them to the concepts, but make
messages more clear. Improve documentation. This is largely the
route taken with the index. Has it worked? I think there is still a
perception among new users that the index is confusing.
2. Use configuration options to differentiate behavior. This comes in
the form of the sometimes-requested "expert/beginner mode" option.
But it can also mean a config option for a specific behavior. The
argument against it I have seen is that it can make git
unpredictable for new versus old users. An old-timer helping a new
person is more out-of-touch with what the new person's setup will
do (which hurts when sitting at their terminal or when giving them
advice online).
3. Make a new porcelain interface that wraps the git plumbing. We have
seen some examples of this. Obviously cogito was the first, and it
has fallen by the wayside as people moved towards core git. That
may be an artifact of its timing, though, as core git was a rapidly
moving target, and power users wanted to use the new features. More
recently we've had 'eg'. I don't know how many people are using it,
but it is certainly not discussed on this list much. There are also
GUIs wrapping git. I think these are subject to the same argument
as (2), but even more so. An entirely new interface like 'eg' is
really splitting the user base. As a git old-timer, I can keep up
with what newbie options might impact git's behavior. But I haven't
a clue how to do anything in 'eg'.
4. Hide potentially dangerous behavior behind "-f" or similar options,
or make it even more inaccessible. We have done this with some
obviously dangerous cases, like "push -f" or "checkout -f", which
can throw away data. But I think in cases where the behavior is
simply confusing and not dangerous, we tend not to do this (at
least I couldn't think of any examples off the top of my head). The
obvious argument against it is that it inconveniences more
experienced users. Dscho advocated "the good of the many" versus
"the good of the few". And I can see some logic in that. At the
same time, open source is about scratching itches. Is anyone really
interested in doing something that makes our own itch worse?
Everytime you use it, won't you be thinking about scratching?
So I don't know what the solution is. And maybe this is just useless
pontificating. But I feel like we have this discussion over and over,
every few months, about a different feature. I wish there were some way
to fix that.
Out of ideas,
-Peff
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Nicolas Pitre @ 2009-10-15 3:08 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Daniel Barkalow, Jay Soffian, git
In-Reply-To: <20091015014737.GA9923@coredump.intra.peff.net>
On Wed, 14 Oct 2009, Jeff King wrote:
> On Wed, Oct 14, 2009 at 05:56:52PM -0700, Junio C Hamano wrote:
>
> > Nicolas Pitre <nico@fluxnic.net> writes:
> >
> > > Can't the user confusion be dealt with through some means other than
> > > making the tool less flexible? I don't mind extra help message to be
> > > displayed after a headless commit is made for example. But trying to
> > > make the tool more friendly should perhaps come from better education
> > > rather than added restrictions.
> > >
> > > My thoughts only.
> >
> > I actually share that but there apparently are people who have given up on
> > the education route.
>
> I am personally undecided on this issue (my "this is the best option"
> was the best of "a -f switch to commit, an 'expert' config option', or a
> session-based option to commit").
>
> But we really seem to have reached an impasse with how to proceed with
> git ui.
>
> People like Dscho are fed up with user complaints about parts of git
> that can be unfriendly to new users. And I can understand that.
People like Dscho have to grow a thicker skin then. There will _always_
be user complaints regardless of how balanced you try to make a UI.
> There _is_ a perception that git is hard for beginners to use, and I
> don't think that perception is entirely without merit. We expect the
> user to understand the basic concepts of git, like history graphs,
> named refs versus detached heads, tracking refs, the index, etc.
Sure. That's part of it, and beginners must get over with that
perception. Git is a professional tool and not a toy project anymore.
Like any professional grade tool, there is a greater effort needed from
beginners before being comfortable with the tool.
> At the same time, I think that is what many of us _like_ about git. It
> is based around simple and powerful concepts, and it doesn't get in your
> way when you want to use those concepts in a powerful and flexible
> manner. And I can understand resistance to making those features hard or
> inconvenient to access; detached HEADs were invented for a reason, and
> we want to use them.
Right. Removing features That _are_ being used sounds a bit backward.
Just because they happen to be confusing to beginners is not a good
justification to remove/cripple them IMHO.
> So what is the right way to mediate between those desires? We have tried
> or suggested several options, including:
>
> 1. Educate users. Keep exposing them to the concepts, but make
> messages more clear. Improve documentation. This is largely the
> route taken with the index. Has it worked? I think there is still a
> perception among new users that the index is confusing.
Well, New users won't be new forever. And Git is different from most
other SCMs. Eventually that difference is well understood by most
not-so-new-anymore Git users. Right now I have to deal with Perforce at
$work and I find it _terribly_ confusing and obnoxious to use. So it's
only a question of getting used to something different.
IMHO this patch proposed by Daniel about the detached head is probably a
good compromise. It makes "confusing" operations more verbose to give
new users a better feeling while keeping the flexibility intact. And
increased verbosity is less annoying than decreased flexibility.
Nicolas
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Wesley J. Landaker @ 2009-10-15 3:02 UTC (permalink / raw)
To: git
In-Reply-To: <1255383459.15646.10.camel@localhost>
On Monday 12 October 2009 15:37:39 Daniele Segato wrote:
> Il giorno lun, 12/10/2009 alle 01.28 -0400, sylvain@demarque.qc.ca ha
>
> scritto:
> > localhost / # git init
>
> I don't see the point of using git on the root directory :)
Just a comment: this might be of serious use in e.g. a chroot.
^ 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