* Re: [PATCH] Use dashless git commands in setgitperms.perl
From: Todd Zullinger @ 2008-09-22 11:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7v4p4b7gjr.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Todd Zullinger <tmz@pobox.com>
---
contrib/hooks/setgitperms.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Junio C Hamano wrote:
> The patch is wrong on one point, and should be unnecessary.
>
> First of all, you do not understand what "." does in shell ;-)
> That is the "wrong" part.
Ugh, that was embarrassing to miss (bad enough to miss it on my own,
but worse to not notice it after Jakub questioned it).
> About the "unnecessary" part, a hook should run under an environment
> where exec-path is already added to the $PATH, so it should be able
> to find git-sh-setup just fine without your change.
>
> But I think the politically correct way would be:
>
> #!/bin/sh
> PATH=$(git --exec-path):$PATH
> SUBDIRECTORY_OK=1 . git-sh-setup
> $GIT_DIR/hooks/setgitperms.perl -r
>
> especially if we envision that somebody may run the script by
> itself, not from the hook.
Since that chunk is only in a comment explaining what to add to the
hook the user wants to run this script from, it seems like that really
is unnecessary.
I was in fact running .git/hooks/setgitperms.perl directly (to create
an initial .gitmeta file) which is why I noticed it used git-*
commands and was failing. Using "git " makes that work for me.
> The change to the perl script should not be strictly necessary
> (because this is expected to be run from a hook), but to set a
> better example, I think it is a good idea to do these s/git-/git /
> substitutions.
Sounds good. Here is a patch with just those changes.
diff --git a/contrib/hooks/setgitperms.perl b/contrib/hooks/setgitperms.perl
index dab7c8e..a577ad0 100644
--- a/contrib/hooks/setgitperms.perl
+++ b/contrib/hooks/setgitperms.perl
@@ -50,7 +50,7 @@ if ((@ARGV < 0) || !GetOptions(
)) { die $usage; }
die $usage unless ($read_mode xor $write_mode);
-my $topdir = `git-rev-parse --show-cdup` or die "\n"; chomp $topdir;
+my $topdir = `git rev-parse --show-cdup` or die "\n"; chomp $topdir;
my $gitdir = $topdir . '.git';
my $gitmeta = $topdir . '.gitmeta';
@@ -155,7 +155,7 @@ elsif ($read_mode) {
open (OUT, ">$gitmeta.tmp") or die "Could not open $gitmeta.tmp for writing: $!\n";
}
- my @files = `git-ls-files`;
+ my @files = `git ls-files`;
my %dirs;
foreach my $path (@files) {
--
1.6.0.2
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Careful. We don't want to learn from this.
-- Calvin
^ permalink raw reply related
* Re: ignoring files/directories in git
From: Andreas Ericsson @ 2008-09-22 11:53 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: Dmitry Potapov, mwolfe38, git
In-Reply-To: <48D77643.1090908@panasas.com>
Boaz Harrosh wrote:
> Dmitry Potapov wrote:
>> On Mon, Sep 22, 2008 at 10:37:00AM +0300, Boaz Harrosh wrote:
>>> I have 1.6.0.1 I compiled here, and it has the same problem. So it is
>>> a very recent fix
>> I certainly tested 1.6.0.1 and does not have this problem, and it was
>> fixed a long time ago:
>>
>> ===
>> commit d6b8fc303b389b026f2bf9918f6f83041488989b
>> Author: Junio C Hamano <gitster@pobox.com>
>> Date: Thu Jan 31 01:17:48 2008 -0800
>>
>> gitignore(5): Allow "foo/" in ignore list to match directory "foo"
>>
>> A pattern "foo/" in the exclude list did not match directory
>> "foo", but a pattern "foo" did. This attempts to extend the
>> exclude mechanism so that it would while not matching a regular
>> file or a symbolic link "foo". In order to differentiate a
>> directory and non directory, this passes down the type of path
>> being checked to excluded() function.
>>
>> A downside is that the recursive directory walk may need to run
>> lstat(2) more often on systems whose "struct dirent" do not give
>> the type of the entry; earlier it did not have to do so for an
>> excluded path, but we now need to figure out if a path is a
>> directory before deciding to exclude it. This is especially bad
>> because an idea similar to the earlier CE_UPTODATE optimization
>> to reduce number of lstat(2) calls would by definition not apply
>> to the codepaths involved, as (1) directories will not be
>> registered in the index, and (2) excluded paths will not be in
>> the index anyway.
>> ===
>>
>> The patch is included in 1.5.5.
>>
>> Dmitry
>> --
>
> Ok I found it. Regular subdirectories it works as you said,
> but soft-link to a folder does not. Sorry for the noise i didn't
> realize that in my test it was a simlink and not a full directory.
>
> Please don't fix it if it will hurt performance, I'm happy with
> current solution as it is. Just maybe a small addition to the
> .gitignore documentation perhaps.
>
It wouldn't hurt performance (noticeably) to change the lstat()
call to a stat() call. It's slightly more work for the kernel,
but assuming you don't have tens of thousands of symlinks it
really won't make a difference. I'm not sure what other things
would break from using stat() instead of lstat() in the exclude
matching code though, so it's not so simple as just replacing
it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [CORRECTION] Git-1.6.0.2-preview20080921 on Windows
From: Frederik Hohlfeld @ 2008-09-22 10:18 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0809220939140.20111@ds9.cixit.se>
Hi
Peter Krefting <peter <at> softwolves.pp.se> writes:
>
> Steffen Prohaska:
>
> > Git-1.6.0.2-preview20080921 for Windows is available at
> > http://code.google.com/p/msysgit/downloads
>
> Thank you!
>
> After installing and running some simple tests (some command line
> commands, git gui, gitk), everything seems to be working just fine.
Do I understand it right, that this is also without working git-svn (or maybe
even without git-svn at all)?
Thanks anyway to the msysgit people for the new Windows build.
Frederik Hohlfeld
^ permalink raw reply
* Re: ignoring files/directories in git
From: Dmitry Potapov @ 2008-09-22 12:19 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: mwolfe38, git
In-Reply-To: <48D77643.1090908@panasas.com>
On Mon, Sep 22, 2008 at 01:41:07PM +0300, Boaz Harrosh wrote:
>
> Ok I found it. Regular subdirectories it works as you said,
> but soft-link to a folder does not.
Why should it? Git does not follow symbolic links regardless whether
they point to files or directories. In fact, Git does extra checks to
avoid something like: symlink-to-dir/normal-file to be added as a
normal file. There was some discussion about it a couple months ago
("Not going beyond symbolic links").
Dmitry
^ permalink raw reply
* Re: [PATCH] git-remote: do not use user input in a printf format string
From: Johannes Schindelin @ 2008-09-22 12:41 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <1222081405-12113-1-git-send-email-johannes.sixt@telecom.at>
Hi,
On Mon, 22 Sep 2008, Johannes Sixt wrote:
> 'git remote show' substituted the remote name into a string that was
> later used as a printf format string. If a remote name contains a printf
> format specifier like this:
>
> $ git remote add foo%sbar .
>
> then the command
>
> $ git remote show foo%sbar
>
> would print garbage (if you are lucky) or crash. This fixes it.
Thanks,
Dscho
^ permalink raw reply
* Re: What's cooking in gitweb (20 Sep 2008)
From: Jakub Narebski @ 2008-09-22 12:43 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Lea Wiemann
In-Reply-To: <cb7bb73a0809211322q5aa6d8ex88651aa33a6c2688@mail.gmail.com>
Giuseppe Bilotta wrote:
> > 1. "gitweb pathinfo improvements" by Giuseppe Bilotta
[...]
> > Need some refinement, especially with respect to _generating_
> > path_info URLs inside gitweb. Some patches (2 and 5) does not
> > need correction, and probably should be sent as separate series.
> > Author promised to resend series, if I remember correctly.
>
> I'll resend the whole series (plus an additional patch to fix an
> aesthetical issue I found recently) as soon as I fix the url
> generation for the dotted filename corner case (which by re-reading
> the past emails seemed to be the only significant issue, correct?).
I think it was the only significant issue (besides the fact that
two mentioned patches could be in separate series). To be more
exact the issue was with generating gitweb URLs for sets of
parameters which cannot be represented as path_info URL. One
example was filename with '..' in it, which cannot be used in
the following path_info form:
$hash_parent_base:$file_parent..$hash_base:$filename
but it can be used in 'no name change' form
$hash_parent_base..$hash_base:$filename
This requires fallback to 'query' form URL.
Other example was branch name with the same name as one of gitweb
actions, which require action to be stated explicitly even if it
is default action and otherwise could be omitted.
> Should be shortly.
I see that it is now. Thanks.
> > 2. "[PATCH] gitweb: shortlog now also obeys $hash_parent"
> > by Giuseppe Bilotta
[...]
> > More important fact is that I'd very much like for _all_ log-like
> > views (perhaps with exception of feeds: Atom and RSS) to implement
> > this feature. This could be done by either doing it all in the same
> > commit, doing commit series changing 'shortlog', 'log' and 'history'
> > separately, or what I would prefer actually, to refactor generation
> > of log-like views to use single worker/engine subroutine.
>
> I agree that refactoring is probably the best idea. It will also take
> me some more time ;)
But it has the advantage of making it easier to add more log-like
views, like 'log' like view for the 'history' view, i.e. --pretty=full
like view with path limiting.
I have thought about doing the refactoring (it is/was on my long-term
TODO list for gitweb), but I haven't even found good way to code it,
to be flexible but not too generalized. Callbacks, perhaps?
> BTW, I haven't heard from Lea, so can I just assume that my patches
> don't touch any of her caching improvements?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Re* [RFC/PATCH] extend meaning of "--root" option to index comparisons
From: Jeff King @ 2008-09-22 13:15 UTC (permalink / raw)
To: Anatol Pomozov; +Cc: Junio C Hamano, sverre, Git Mailing List
In-Reply-To: <3665a1a00809210858r1c494d22p77b5e9964c06424e@mail.gmail.com>
On Sun, Sep 21, 2008 at 08:58:30AM -0700, Anatol Pomozov wrote:
> revision is broken (like we have a junk in the HEAD file) from the
> case when "branch is not created yet" (which is part of normal
> workflow).
>
> What about following algorithm. HEAD points to ref and ref is not
> created yet. Additional check could be
> a) there are no other refs
> or/and b) object database is empty
I don't think those things have to do with "branch not created yet".
They are about "repository has no branches".
The only thing that indicates you a branch has not been created is the
absence of that ref. So you really have two situations there:
1. a symref like HEAD points to a branch that does not exist
2. the user inputs a ref-name that does not exist
In the former, that means we are on a branch that hasn't been created
yet (which generally does mean a new repo, but it's possible to reach
this state in other ways). Or it means somebody made a mistake when they
updated the symref.
In the latter, it _could_ mean that we are interested in a branch yet to
be born, but in general we consider it to mean the user made a typo.
-Peff
^ permalink raw reply
* Re: Re* [RFC/PATCH] extend meaning of "--root" option to index comparisons
From: Jeff King @ 2008-09-22 13:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Anatol Pomozov, sverre, Git Mailing List
In-Reply-To: <7v63opz66t.fsf@gitster.siamese.dyndns.org>
On Sun, Sep 21, 2008 at 11:48:10AM -0700, Junio C Hamano wrote:
> > What about index comparisons? What should an index comparison to a
> > branch yet-to-be-born look like? Right now it is an error.
>
> It should be an error, because that is _not_ even an comparison. At least
> at diff-index level.
>
> The diff wrapper UI could do something different, though. And an obvious
> thing to do is to give a fake creation event.
So is that an implicit endorsement of my "diff --cached --root" patch,
which does exactly that?
> The current output feels perfectly sensible to me.
>
> $ mkdir d; cd d; tar xf .../t.tar; git init; git add .
> $ git diff --cached
> fatal: No HEAD commit to compare with (yet)
Sure. I don't think any behavior should be changed without a "please
treat branch-to-be-born as an empty tree" flag.
> The alternative is no different from "find . -type f | xargs cat" from the
> point of view of reviewability. To make sure you have what you want in
Interesting comparison. The find example you give has a problem if there
are no files. But my patch is more akin to adding a --no-run-if-empty
flag to xargs here.
> By allowing an auto-fallback to the comparison with an empty tree object,
> you are giving these possibilities:
>
> $ git diff --cached --stat
> $ git diff --cached --name-only
>
> but the latter is already available from ls-files anyway, and the former
> does not feel so interesting.
I didn't think we are introducing any new possibilities anyway, since
one can always just compare against the empty tree manually (though I
think "git diff --cached --stat" might be useful for a "status"-like
script).
The advantage is saving callers from having to do two _different_ things
for the initial and regular commit cases.
And for interactive users, seeing the error and saying "Oh, I really
would like to see the diff against the empty tree, but I can't remember
the SHA-1 of the empty tree" (though for that, I have also been running
with a fake ref "EMPTY" which is just simpler to remember). So instead
they can just repeat the command with "--root".
> In exchange, we lose the reminder to the user that this is a creation
> event. An interactive user (remember, I am not talking about diff-index
> here, but diff front-end) may want to treat it specially perhaps by being
> extra careful. If there were no downsides like this in "fall back to
> comparing with an empty tree" approach, I wouldn't hesitate to agree it is
> a good idea, though.
You seem to be arguing against doing this by default, which I am not
really advocating (to be honest, I am not 100% sure I am advocating
"diff --cached --root", but this discussion is helping me sort out the
positives and negatives). It only makes sense to me with an extra flag
that explicitly says "and if there is no HEAD, do this fallback."
> To this, I am inclined to agree. We could do something like the attached
> patch, but there is a caveat.
I do think this approach makes sense (and it mirrors what I just
explained in my last mail to Anatol, which is that we are really talking
about identifying non-existent branches in symrefs).
But I agree there will be a big fallout as we break many of the callers
who expect the barfing. I can try to look at some of the implications,
but expect a delay there from me due to real life concerns.
> + } else if (!revs->require_valid_def &&
> + !strcmp(revs->def, "HEAD") &&
> + resolve_ref(revs->def, sha1, 0, &flag) &&
> + (flag & REF_ISSYMREF)) {
I wonder if this should be restricted to HEAD and not simply all
symrefs. The thing we are really pointing out is that something points
to a non-existing ref, and because that something is on disk and not
typed in by the user, we are assuming it is not just a mistake.
The only other example I can think of is a refs/remotes/$foo/HEAD, which
we might access via "$foo", can point to an unborn branch.
But maybe it is best to be conservative at first and stick with "HEAD".
-Peff
^ permalink raw reply
* Re: [ANNOUNCE] TopGit v0.3
From: Petr Baudis @ 2008-09-22 15:27 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: martin f krafft, git
In-Reply-To: <1222074825.6698.13.camel@heerbeest>
On Mon, Sep 22, 2008 at 11:13:45AM +0200, Jan Nieuwenhuizen wrote:
> On zo, 2008-09-21 at 16:24 +0200, Petr Baudis wrote:
>
> > The problem is that you can undo the merge content, but not the history
> > information. So this revert can e.g. propagate even into branches which
> > still *should* depend on the other branch, you get into trouble when you
> > want to make your branch depend on the other one anyway, etc.
>
> Ah, yes. I see. Does this mean that functionality for easy adding and
> removing dependencies/patches from a branch can only be provided through
> some sort of [unpublishable] patch based mechanism like stgit?
>
> Possibly we'd need a kind of setup where stgit-like patch branches
> can be "finalized" into topgit branches. Hmm.
Do you really expect you will need this kind of functionality often,
though? Adding dependencies is easy, and note that removing whole topic
branches or deleting dependencies that were merged upstream _is_ doable.
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: [PATCH 3/3] git abbref-ref: new porcelain for abbreviate_ref()
From: Shawn O. Pearce @ 2008-09-22 15:32 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Junio C Hamano, git, szeder
In-Reply-To: <1222074591-26548-3-git-send-email-bert.wesarg@googlemail.com>
Bert Wesarg <bert.wesarg@googlemail.com> wrote:
> This gives direct access to the abbreviate_ref() function. The operation
> mode defaults to the core.warnambiguousrefs value, like the refname:short
> format, but can be explicitly changed with the --{,no}-strict option.
>
> The bash completion script utilizes this new command.
And it slows down too, doesn't it? Now we are doing a fork per
branch during completion. Yikes. Didn't you just post a series
about making completion faster?
> Junio, if this is not a porcelain, tell me.
IMHO its plumbing. Porcelain is used by a human. Plumbing is the
bits needed to make human interfaces.
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 93f0881..7f002c0 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -112,9 +112,9 @@ __git_ps1 ()
> fi
>
> if [ -n "$1" ]; then
> - printf "$1" "${b##refs/heads/}$r"
> + printf "$1" "$(git abbrev-ref $b)$r"
> else
> - printf " (%s)" "${b##refs/heads/}$r"
> + printf " (%s)" "$(git abbrev-ref $b)$r"
> fi
> fi
> }
> @@ -162,7 +162,7 @@ __git_heads ()
> case "$is_hash,$i" in
> y,*) is_hash=n ;;
> n,*^{}) is_hash=y ;;
> - n,refs/heads/*) is_hash=y; echo "${i#refs/heads/}" ;;
> + n,refs/heads/*) is_hash=y; echo "$(git abbrev-ref $i)" ;;
> n,*) is_hash=y; echo "$i" ;;
> esac
> done
> @@ -180,7 +180,7 @@ __git_tags ()
> case "$is_hash,$i" in
> y,*) is_hash=n ;;
> n,*^{}) is_hash=y ;;
> - n,refs/tags/*) is_hash=y; echo "${i#refs/tags/}" ;;
> + n,refs/tags/*) is_hash=y; echo "$(git abbrev-ref $i)" ;;
> n,*) is_hash=y; echo "$i" ;;
> esac
> done
> @@ -199,9 +199,9 @@ __git_refs ()
> case "$is_hash,$i" in
> y,*) is_hash=n ;;
> n,*^{}) is_hash=y ;;
> - n,refs/tags/*) is_hash=y; echo "${i#refs/tags/}" ;;
> - n,refs/heads/*) is_hash=y; echo "${i#refs/heads/}" ;;
> - n,refs/remotes/*) is_hash=y; echo "${i#refs/remotes/}" ;;
> + n,refs/tags/*) is_hash=y; echo "$(git abbrev-ref $i)" ;;
> + n,refs/heads/*) is_hash=y; echo "$(git abbrev-ref $i)" ;;
> + n,refs/remotes/*) is_hash=y; echo "$(git abbrev-ref $i)" ;;
> n,*) is_hash=y; echo "$i" ;;
> esac
> done
> @@ -222,7 +222,7 @@ __git_refs_remotes ()
> case "$is_hash,$i" in
> n,refs/heads/*)
> is_hash=y
> - echo "$i:refs/remotes/$1/${i#refs/heads/}"
> + echo "$i:refs/remotes/$1/$(git abbrev-ref $i)"
> ;;
> y,*) is_hash=n ;;
> n,*^{}) is_hash=y ;;
--
Shawn.
^ permalink raw reply
* Re: [TopGit PATCH] prev/next/tsort: commands to explore dependencies
From: Petr Baudis @ 2008-09-22 15:36 UTC (permalink / raw)
To: Bert Wesarg; +Cc: git
In-Reply-To: <1221818101-14333-1-git-send-email-bert.wesarg@googlemail.com>
Hi,
On Fri, Sep 19, 2008 at 11:55:00AM +0200, Bert Wesarg wrote:
> I hacked 3 commands to explore the dependencies of TopGit patches:
thanks, the idea of all three commands is good,
> I) tg prev [NAME]
> outputs the dependencies of NAME
>
> II) tg next [NAME]
> outputs patches that depends on NAME
but I think it would be cleaner to add this functionality to
tg info...
> III) tg tsort [PATTERN]
> outputs a topological order of all patches starting with PATTERN
...and tg summary (overally, to have a tree view of branches).
> diff --git a/tg-tsort.sh b/tg-tsort.sh
> new file mode 100644
> index 0000000..8a7376a
> --- /dev/null
> +++ b/tg-tsort.sh
..snip..
> + printf "%s\t%q\n" "${dep_rev}" "${dep}" >&3
> + printf "%s\t%s\n" "${topic_rev}" "${dep_rev}"
%q?
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: [TopGit PATCH] tg-patch: add From/Date: line to header and print to file
From: Petr Baudis @ 2008-09-22 15:39 UTC (permalink / raw)
To: Bert Wesarg; +Cc: git
In-Reply-To: <1221818101-14333-2-git-send-email-bert.wesarg@googlemail.com>
On Fri, Sep 19, 2008 at 11:55:01AM +0200, Bert Wesarg wrote:
> To make this more similar to git format-patch, I added a 'From' and
> a 'Date:' header and let 'tg patch' print to a file (which is shown as output).
>
> Regards
> Bert
>
> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
I dislike the anyway completely bogus From line. If you want mbox
format, you should call (hypothetical) tg mail. Also, IMHO Date: should
be simply always printed at the end of the header, it's distracting if
it is higher.
Also, the writing to file is confusing to me. What are you trying to
achieve? If you want to export patches, why not use 'tg export' which
already has this functionality? To me, 'tg patch' is basically
equivalent of 'git show' for the whole branch.
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: [PATCH 3/3] git abbref-ref: new porcelain for abbreviate_ref()
From: Junio C Hamano @ 2008-09-22 15:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Bert Wesarg, git, szeder
In-Reply-To: <20080922153222.GD3669@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Bert Wesarg <bert.wesarg@googlemail.com> wrote:
>> This gives direct access to the abbreviate_ref() function. The operation
>> mode defaults to the core.warnambiguousrefs value, like the refname:short
>> format, but can be explicitly changed with the --{,no}-strict option.
>>
>> The bash completion script utilizes this new command.
>
> And it slows down too, doesn't it? Now we are doing a fork per
> branch during completion. Yikes. Didn't you just post a series
> about making completion faster?
>
>> Junio, if this is not a porcelain, tell me.
>
> IMHO its plumbing. Porcelain is used by a human. Plumbing is the
> bits needed to make human interfaces.
Shawn is right.
I wouldn't be taking this patch to add a new command, but I suspect that
this could be an option to rev-parse that is similar to --symbolic.
Teach SHOW_SYMBOLIC_SHORTEST to builtin-rev-parse.c::show_rev(), teach the
parser cmd_rev_parse() a new option --symbolic-abbrev and you are done,
right?
By the way, I found it amusing to see Cc: lines _after_ three dashes to
control send-email --- nice trick I didn't think of ;-)
^ permalink raw reply
* Re: [CORRECTION] Git-1.6.0.2-preview20080921 on Windows
From: Johan Herland @ 2008-09-22 15:56 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, msysGit
In-Reply-To: <691F01A6-CA78-46DA-8388-C8339A3F0F04@zib.de>
On Sunday 21 September 2008, Steffen Prohaska wrote:
> Git-1.6.0.2-preview20080921 for Windows is available at
>
> [...]
This version fails for me when trying to use the bundled ssh.exe. I get
a dialog saying:
This application has failed to start because msys-crypto-0.9.8.dll
was not found. Re-installing the application may fix the problem.
I get this both when starting ssh manually, and when started from
e.g. "git clone".
Before installing the above version, I _uninstalled_ the previous
version. If i _don't_ uninstall the previous version, and instead
install this one on top of the old one, everything seems to work
correctly.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [PATCH RFC 3/6] Docs: send-email usage text much sexier
From: Michael Witten @ 2008-09-22 15:58 UTC (permalink / raw)
To: git
In-Reply-To: <1222099095-50360-2-git-send-email-mfwitten@mit.edu>
All of the descriptions are aligned, and no
line is greater than 78 columns.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
git-send-email.perl | 94 +++++++++++++++++++++++++++------------------------
1 files changed, 50 insertions(+), 44 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index d390364..b86a3f3 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -40,74 +40,80 @@ sub usage {
print <<EOT;
git send-email [options] <file | directory>...
Options:
- --from Specify the "From:" line of the email to be sent.
+ --from Specify the "From:" line of the email to be sent.
- --to Specify the primary "To:" line of the email.
+ --to Specify the primary "To:" line of the email.
- --cc Specify an initial "Cc:" list for the entire series
- of emails.
+ --cc Specify an initial "Cc:" list for the entire series
+ of emails.
- --cc-cmd Specify a command to execute per file which adds
- per file specific cc address entries
+ --cc-cmd Specify a command to execute per file which adds
+ per file specific cc address entries
- --bcc Specify a list of email addresses that should be Bcc:
- on all the emails.
+ --bcc Specify a list of email addresses that should be
+ Bcc: on all the emails.
- --compose Use \$GIT_EDITOR, core.editor, \$EDITOR, or \$VISUAL to edit
- an introductory message for the patch series.
+ --compose Use \$GIT_EDITOR, core.editor, \$EDITOR, or
+ \$VISUAL to edit an introductory message for the
+ patch series.
- --subject Specify the initial "Subject:" line.
- Only necessary if --compose is also set. If --compose
- is not set, this will be prompted for.
+ --subject Specify the initial "Subject:" line. Only necessary
+ if --compose is also set. If --compose is not set,
+ this will be prompted for.
- --in-reply-to Specify the first "In-Reply-To:" header line.
- Only used if --compose is also set. If --compose is not
- set, this will be prompted for.
+ --in-reply-to Specify the first "In-Reply-To:" header line. Only
+ used if --compose is also set. If --compose is not
+ set, this will be prompted for.
- --[no-]chain-reply-to If set, the replies will all be to the previous
- email sent, rather than to the first email sent.
- Defaults to on.
+ --[no-]chain-reply-to If set, the replies will all be to the previous
+ email sent, rather than to the first email sent.
+ Defaults to on.
--[no-]signed-off-by-cc Automatically add email addresses that appear in
- Signed-off-by: or Cc: lines to the cc: list. Defaults to on.
+ Signed-off-by: or Cc: lines to the cc: list.
+ Defaults to on.
- --identity The configuration identity, a subsection to prioritise over
- the default section.
+ --identity The configuration identity to use.
- --smtp-server If set, specifies the outgoing SMTP server to use.
- Defaults to localhost. Port number can be specified here with
- hostname:port format or by using --smtp-server-port option.
+ --smtp-server If set, specifies the outgoing SMTP server to use.
+ Defaults to localhost. Port number can be
+ specified here with hostname:port format or by
+ using --smtp-server-port option.
- --smtp-server-port Specify a port on the outgoing SMTP server to connect to.
+ --smtp-server-port Specify a port on the outgoing SMTP server to
+ connect to.
- --smtp-user The username for SMTP-AUTH.
+ --smtp-user The username for SMTP-AUTH.
- --smtp-pass The password for SMTP-AUTH.
+ --smtp-pass The password for SMTP-AUTH.
- --smtp-encryption Specify 'tls' for STARTTLS encryption, or 'ssl' for SSL.
- Any other value disables the feature.
+ --smtp-encryption Specify 'tls' for STARTTLS encryption, or 'ssl' for
+ SSL. Any other value disables the feature.
- --smtp-ssl Synonym for '--smtp-encryption=ssl'. Deprecated.
+ --smtp-ssl Synonym for '--smtp-encryption=ssl'. Deprecated.
- --suppress-cc Suppress the specified category of auto-CC. The category
- can be one of 'author' for the patch author, 'self' to
- avoid copying yourself, 'sob' for Signed-off-by lines,
- 'cccmd' for the output of the cccmd, or 'all' to suppress
- all of these.
+ --suppress-cc Suppress the specified category of auto-CC. The
+ category can be one of 'author' for the patch
+ author, 'self' to avoid copying yourself, 'sob'
+ for Signed-off-by lines, 'cccmd' for the output
+ of the cccmd, or 'all' to suppress all of these.
+ (Note: Linus uses 'self' and 'sob' interchangeably)
- --[no-]suppress-from Suppress sending emails to yourself. Defaults to off.
+ --[no-]suppress-from Suppress sending emails to yourself. Defaults to
+ off.
- --[no-]thread Specify that the "In-Reply-To:" header should be set on all
- emails. Defaults to on.
+ --[no-]thread Specify that the "In-Reply-To:" header should be
+ set on all emails. Defaults to on.
- --quiet Make git-send-email less verbose. One line per email
- should be all that is output.
+ --quiet Make git-send-email less verbose. One line per
+ email should be all that is output.
- --dry-run Do everything except actually send the emails.
+ --dry-run Do everything except actually send the emails.
- --envelope-sender Specify the envelope sender used to send the emails.
+ --envelope-sender Specify the envelope sender used to send the
+ emails.
- --no-validate Don't perform any sanity checks on patches.
+ --no-validate Don't perform any sanity checks on patches.
EOT
exit(1);
--
1.6.0.2.302.ge6cbd1
^ permalink raw reply related
* [PATCH RFC 1/6] Docs: send-email's usage text and man page mention same options
From: Michael Witten @ 2008-09-22 15:58 UTC (permalink / raw)
To: git
Specifically, boolean options are now listed in the form
--[no-]option
and both forms of documentation now consistently use
--[no-]signed-off-by-cc
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 21 +++++++++++++--------
git-send-email.perl | 8 ++++----
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 3c3e1b0..9b31626 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -40,8 +40,7 @@ The --cc option must be repeated for each user you want on the cc list.
Output of this command must be single email address per line.
Default is the value of 'sendemail.cccmd' configuration value.
---chain-reply-to::
---no-chain-reply-to::
+--[no-]chain-reply-to::
If this is set, each email will be sent as a reply to the previous
email sent. If disabled with "--no-chain-reply-to", all emails after
the first will be sent as replies to the first email sent. When using
@@ -66,8 +65,7 @@ The --cc option must be repeated for each user you want on the cc list.
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
---signed-off-by-cc::
---no-signed-off-by-cc::
+--[no-]signed-off-by-cc::
If this is set, add emails found in Signed-off-by: or Cc: lines to the
cc list.
Default is the value of 'sendemail.signedoffcc' configuration value;
@@ -146,8 +144,7 @@ user is prompted for a password while the input is masked for privacy.
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
---suppress-from::
---no-suppress-from::
+--[no-]suppress-from::
If this is set, do not add the From: address to the cc: list.
Default is the value of 'sendemail.suppressfrom' configuration value;
if that is unspecified, default to --no-suppress-from.
@@ -163,8 +160,7 @@ user is prompted for a password while the input is masked for privacy.
if that is unspecified, default to 'self' if --suppress-from is
specified, as well as 'sob' if --no-signed-off-cc is specified.
---thread::
---no-thread::
+--[no-]thread::
If this is set, the In-Reply-To header will be set on each email sent.
If disabled with "--no-thread", no emails will have the In-Reply-To
header set.
@@ -183,6 +179,15 @@ user is prompted for a password while the input is masked for privacy.
variable; if that is unspecified, choosing the envelope sender is left
to your MTA.
+--no-validate::
+ Don't perform any sanity checks on patches.
+ Currently, validation means the following:
++
+--
+ * Warn of patches that contain lines longer than 998 characters; this
+ is due to SMTP limits as described by http://www.ietf.org/rfc/rfc2821.txt.
+--
+
--to::
Specify the primary recipient of the emails generated.
Generally, this will be the upstream maintainer of the
diff --git a/git-send-email.perl b/git-send-email.perl
index d2fd899..9f56162 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -64,11 +64,11 @@ Options:
Only used if --compose is also set. If --compose is not
set, this will be prompted for.
- --chain-reply-to If set, the replies will all be to the previous
+ --[no-]chain-reply-to If set, the replies will all be to the previous
email sent, rather than to the first email sent.
Defaults to on.
- --signed-off-cc Automatically add email addresses that appear in
+ --[no-]signed-off-by-cc Automatically add email addresses that appear in
Signed-off-by: or Cc: lines to the cc: list. Defaults to on.
--identity The configuration identity, a subsection to prioritise over
@@ -95,9 +95,9 @@ Options:
'cccmd' for the output of the cccmd, or 'all' to suppress
all of these.
- --suppress-from Suppress sending emails to yourself. Defaults to off.
+ --[no-]suppress-from Suppress sending emails to yourself. Defaults to off.
- --thread Specify that the "In-Reply-To:" header should be set on all
+ --[no-]thread Specify that the "In-Reply-To:" header should be set on all
emails. Defaults to on.
--quiet Make git-send-email less verbose. One line per email
--
1.6.0.2.302.ge6cbd1
^ permalink raw reply related
* [PATCH RFC 5/6] Docs: send-email: change --no-validate to boolean --[no-]validate
From: Michael Witten @ 2008-09-22 15:58 UTC (permalink / raw)
To: git
In-Reply-To: <1222099095-50360-4-git-send-email-mfwitten@mit.edu>
There is also now a configuration variable:
sendemail[.<identity>].validate
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 9 +++++++--
git-send-email.perl | 10 ++++++----
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 6031eb7..fe53e9b 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -189,14 +189,16 @@ user is prompted for a password while the input is masked for privacy.
variable; if that is unspecified, choosing the envelope sender is left
to your MTA.
---no-validate::
- Don't perform any sanity checks on patches.
+--[no-]validate::
+ Perform sanity checks on patches.
Currently, validation means the following:
+
--
* Warn of patches that contain lines longer than 998 characters; this
is due to SMTP limits as described by http://www.ietf.org/rfc/rfc2821.txt.
--
++
+This option can be set with sendemail[.<identity>].validate; default to --validate
CONFIGURATION
@@ -249,6 +251,9 @@ sendemail.smtpencryption::
sendemail.smtpssl::
Legacy boolean that sets 'smtpencryption=ssl' if enabled.
+sendemail.validate::
+ Boolean override for --[no-]validate.
+
Author
------
Written by Ryan Anderson <ryan@michonline.com>
diff --git a/git-send-email.perl b/git-send-email.perl
index b86a3f3..8bc204f 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -113,7 +113,8 @@ Options:
--envelope-sender Specify the envelope sender used to send the
emails.
- --no-validate Don't perform any sanity checks on patches.
+ --[no-]validate Perform any sanity checks on patches.
+ Default to on.
EOT
exit(1);
@@ -195,7 +196,7 @@ my ($quiet, $dry_run) = (0, 0);
my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_encryption);
my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
-my ($no_validate);
+my ($validate);
my (@suppress_cc);
my %config_bool_settings = (
@@ -203,6 +204,7 @@ my %config_bool_settings = (
"chainreplyto" => [\$chain_reply_to, 1],
"suppressfrom" => [\$suppress_from, undef],
"signedoffcc" => [\$signed_off_cc, undef],
+ "validate" => [\$validate, 1],
);
my %config_settings = (
@@ -269,7 +271,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
"thread!" => \$thread,
- "no-validate" => \$no_validate,
+ "validate!" => \$validate,
);
unless ($rc) {
@@ -422,7 +424,7 @@ for my $f (@ARGV) {
}
}
-if (!$no_validate) {
+if ($validate) {
foreach my $f (@files) {
unless (-p $f) {
my $error = validate_patch($f);
--
1.6.0.2.302.ge6cbd1
^ permalink raw reply related
* [PATCH RFC 6/6] Docs: send-email: --chain_reply_to -> --[no-]chain-reply-to
From: Michael Witten @ 2008-09-22 15:58 UTC (permalink / raw)
To: git
In-Reply-To: <1222099095-50360-5-git-send-email-mfwitten@mit.edu>
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index fe53e9b..76a525a 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -228,7 +228,7 @@ sendemail.bcc::
Email address (or alias) to always bcc.
sendemail.chainreplyto::
- Boolean value specifying the default to the '--chain_reply_to'
+ Boolean value specifying the default to the '--[no-]chain-reply-to'
parameter.
sendemail.smtpserver::
--
1.6.0.2.302.ge6cbd1
^ permalink raw reply related
* [PATCH RFC 2/6] Docs: send-email usage cleanup 1
From: Michael Witten @ 2008-09-22 15:58 UTC (permalink / raw)
To: git
In-Reply-To: <1222099095-50360-1-git-send-email-mfwitten@mit.edu>
The usage text mainly uses spaces to layout the text,
so I replaced the few tabs that exit with spaces.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
git-send-email.perl | 36 ++++++++++++++++++------------------
1 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 9f56162..d390364 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -51,25 +51,25 @@ Options:
per file specific cc address entries
--bcc Specify a list of email addresses that should be Bcc:
- on all the emails.
+ on all the emails.
--compose Use \$GIT_EDITOR, core.editor, \$EDITOR, or \$VISUAL to edit
- an introductory message for the patch series.
+ an introductory message for the patch series.
--subject Specify the initial "Subject:" line.
Only necessary if --compose is also set. If --compose
- is not set, this will be prompted for.
+ is not set, this will be prompted for.
--in-reply-to Specify the first "In-Reply-To:" header line.
Only used if --compose is also set. If --compose is not
- set, this will be prompted for.
+ set, this will be prompted for.
--[no-]chain-reply-to If set, the replies will all be to the previous
- email sent, rather than to the first email sent.
- Defaults to on.
+ email sent, rather than to the first email sent.
+ Defaults to on.
--[no-]signed-off-by-cc Automatically add email addresses that appear in
- Signed-off-by: or Cc: lines to the cc: list. Defaults to on.
+ Signed-off-by: or Cc: lines to the cc: list. Defaults to on.
--identity The configuration identity, a subsection to prioritise over
the default section.
@@ -85,29 +85,29 @@ Options:
--smtp-pass The password for SMTP-AUTH.
--smtp-encryption Specify 'tls' for STARTTLS encryption, or 'ssl' for SSL.
- Any other value disables the feature.
+ Any other value disables the feature.
--smtp-ssl Synonym for '--smtp-encryption=ssl'. Deprecated.
--suppress-cc Suppress the specified category of auto-CC. The category
- can be one of 'author' for the patch author, 'self' to
- avoid copying yourself, 'sob' for Signed-off-by lines,
- 'cccmd' for the output of the cccmd, or 'all' to suppress
- all of these.
+ can be one of 'author' for the patch author, 'self' to
+ avoid copying yourself, 'sob' for Signed-off-by lines,
+ 'cccmd' for the output of the cccmd, or 'all' to suppress
+ all of these.
--[no-]suppress-from Suppress sending emails to yourself. Defaults to off.
--[no-]thread Specify that the "In-Reply-To:" header should be set on all
- emails. Defaults to on.
+ emails. Defaults to on.
- --quiet Make git-send-email less verbose. One line per email
- should be all that is output.
+ --quiet Make git-send-email less verbose. One line per email
+ should be all that is output.
- --dry-run Do everything except actually send the emails.
+ --dry-run Do everything except actually send the emails.
- --envelope-sender Specify the envelope sender used to send the emails.
+ --envelope-sender Specify the envelope sender used to send the emails.
- --no-validate Don't perform any sanity checks on patches.
+ --no-validate Don't perform any sanity checks on patches.
EOT
exit(1);
--
1.6.0.2.302.ge6cbd1
^ permalink raw reply related
* [PATCH RFC 4/6] Docs: send-email: Option order the same in man page and usage text
From: Michael Witten @ 2008-09-22 15:58 UTC (permalink / raw)
To: git
In-Reply-To: <1222099095-50360-3-git-send-email-mfwitten@mit.edu>
The man page seems to have listed the options in alphabetical order,
while the usage text used what I would consider an `intuitive' order
that groups related items and presents them in the order peopl think
when writing an email.
The manual page has been updated to mirror this order.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 77 +++++++++++++++++++-------------------
1 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 9b31626..6031eb7 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -24,10 +24,19 @@ OPTIONS
-------
The options available are:
---bcc::
- Specify a "Bcc:" value for each email.
+--from::
+ Specify the sender of the emails. This will default to
+ the value GIT_COMMITTER_IDENT, as returned by "git var -l".
+ The user will still be prompted to confirm this entry.
+
+--to::
+ Specify the primary recipient of the emails generated.
+ Generally, this will be the upstream maintainer of the
+ project involved.
+ Default is the value of the 'sendemail.to' configuration value;
+ if that is unspecified, this will be prompted for.
+
-The --bcc option must be repeated for each user you want on the bcc list.
+The --to option must be repeated for each user you want on the to list.
--cc::
Specify a starting "Cc:" value for each email.
@@ -40,23 +49,19 @@ The --cc option must be repeated for each user you want on the cc list.
Output of this command must be single email address per line.
Default is the value of 'sendemail.cccmd' configuration value.
---[no-]chain-reply-to::
- If this is set, each email will be sent as a reply to the previous
- email sent. If disabled with "--no-chain-reply-to", all emails after
- the first will be sent as replies to the first email sent. When using
- this, it is recommended that the first file given be an overview of the
- entire patch series.
- Default is the value of the 'sendemail.chainreplyto' configuration
- value; if that is unspecified, default to --chain-reply-to.
+--bcc::
+ Specify a "Bcc:" value for each email.
++
+The --bcc option must be repeated for each user you want on the bcc list.
--compose::
Use $GIT_EDITOR, core.editor, $VISUAL, or $EDITOR to edit an
introductory message for the patch series.
---from::
- Specify the sender of the emails. This will default to
- the value GIT_COMMITTER_IDENT, as returned by "git var -l".
- The user will still be prompted to confirm this entry.
+--subject::
+ Specify the initial subject of the email thread.
+ Only necessary if --compose is also set. If --compose
+ is not set, this will be prompted for.
--in-reply-to::
Specify the contents of the first In-Reply-To header.
@@ -65,16 +70,21 @@ The --cc option must be repeated for each user you want on the cc list.
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
+--[no-]chain-reply-to::
+ If this is set, each email will be sent as a reply to the previous
+ email sent. If disabled with "--no-chain-reply-to", all emails after
+ the first will be sent as replies to the first email sent. When using
+ this, it is recommended that the first file given be an overview of the
+ entire patch series.
+ Default is the value of the 'sendemail.chainreplyto' configuration
+ value; if that is unspecified, default to --chain-reply-to.
+
--[no-]signed-off-by-cc::
If this is set, add emails found in Signed-off-by: or Cc: lines to the
cc list.
Default is the value of 'sendemail.signedoffcc' configuration value;
if that is unspecified, default to --signed-off-by-cc.
---quiet::
- Make git-send-email less verbose. One line per email should be
- all that is output.
-
--identity::
A configuration identity. When given, causes values in the
'sendemail.<identity>' subsection to take precedence over
@@ -139,16 +149,6 @@ user is prompted for a password while the input is masked for privacy.
--smtp-ssl::
Legacy alias for '--smtp-encryption=ssl'.
---subject::
- Specify the initial subject of the email thread.
- Only necessary if --compose is also set. If --compose
- is not set, this will be prompted for.
-
---[no-]suppress-from::
- If this is set, do not add the From: address to the cc: list.
- Default is the value of 'sendemail.suppressfrom' configuration value;
- if that is unspecified, default to --no-suppress-from.
-
--suppress-cc::
Specify an additional category of recipients to suppress the
auto-cc of. 'self' will avoid including the sender, 'author' will
@@ -159,6 +159,12 @@ user is prompted for a password while the input is masked for privacy.
Default is the value of 'sendemail.suppresscc' configuration value;
if that is unspecified, default to 'self' if --suppress-from is
specified, as well as 'sob' if --no-signed-off-cc is specified.
+ (Note: Linus uses 'self' and 'sob' interchangeably).
+
+--[no-]suppress-from::
+ If this is set, do not add the From: address to the cc: list.
+ Default is the value of 'sendemail.suppressfrom' configuration value;
+ if that is unspecified, default to --no-suppress-from.
--[no-]thread::
If this is set, the In-Reply-To header will be set on each email sent.
@@ -167,6 +173,10 @@ user is prompted for a password while the input is masked for privacy.
Default is the value of the 'sendemail.thread' configuration value;
if that is unspecified, default to --thread.
+--quiet::
+ Make git-send-email less verbose. One line per email should be
+ all that is output.
+
--dry-run::
Do everything except actually send the emails.
@@ -188,15 +198,6 @@ user is prompted for a password while the input is masked for privacy.
is due to SMTP limits as described by http://www.ietf.org/rfc/rfc2821.txt.
--
---to::
- Specify the primary recipient of the emails generated.
- Generally, this will be the upstream maintainer of the
- project involved.
- Default is the value of the 'sendemail.to' configuration value;
- if that is unspecified, this will be prompted for.
-+
-The --to option must be repeated for each user you want on the to list.
-
CONFIGURATION
-------------
--
1.6.0.2.302.ge6cbd1
^ permalink raw reply related
* [PATCH] Fix submodule sync with relative submodule URLs
From: Johan Herland @ 2008-09-22 16:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Aguilar, Mark Levedahl
Signed-off-by: Johan Herland <johan@herland.net>
---
git-submodule.sh | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 1c39b59..92be0fe 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -634,6 +634,14 @@ cmd_sync()
do
name=$(module_name "$path")
url=$(git config -f .gitmodules --get submodule."$name".url)
+
+ # Possibly a url relative to parent
+ case "$url" in
+ ./*|../*)
+ url=$(resolve_relative_url "$url") || exit
+ ;;
+ esac
+
if test -e "$path"/.git
then
(
--
1.6.0.1.400.gd2470
^ permalink raw reply related
* Re: [PATCH 1/3] for-each-ref: utilize core.warnambiguousrefs for strict refname:short format
From: Junio C Hamano @ 2008-09-22 16:27 UTC (permalink / raw)
To: Bert Wesarg; +Cc: git, szeder, Shawn O. Pearce
In-Reply-To: <1222074591-26548-1-git-send-email-bert.wesarg@googlemail.com>
Bert Wesarg <bert.wesarg@googlemail.com> writes:
> diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
> index 9b44092..e7b7712 100644
> --- a/builtin-for-each-ref.c
> +++ b/builtin-for-each-ref.c
> @@ -571,7 +571,7 @@ static void gen_scanf_fmt(char *scanf_fmt, const char *rule)
> /*
> * Shorten the refname to an non-ambiguous form
> */
> -static char *get_short_ref(struct refinfo *ref)
> +static void get_short_ref(struct refinfo *ref, int strict, char **short_ref)
> {
> int i;
> static char **scanf_fmts;
As far as I can tell this changing of function signature does not help its
existing caller nor the function's implementation.
Why? And especially why do this in a patch that does something else?
^ permalink raw reply
* Re: [PATCH 3/3] git abbref-ref: new porcelain for abbreviate_ref()
From: Bert Wesarg @ 2008-09-22 16:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git, szeder
In-Reply-To: <20080922153222.GD3669@spearce.org>
On Mon, Sep 22, 2008 at 17:32, Shawn O. Pearce <spearce@spearce.org> wrote:
> Bert Wesarg <bert.wesarg@googlemail.com> wrote:
>> This gives direct access to the abbreviate_ref() function. The operation
>> mode defaults to the core.warnambiguousrefs value, like the refname:short
>> format, but can be explicitly changed with the --{,no}-strict option.
>>
>> The bash completion script utilizes this new command.
>
> And it slows down too, doesn't it? Now we are doing a fork per
> branch during completion. Yikes. Didn't you just post a series
> about making completion faster?
No, correctness was and is my concern, so this patch fits well into this.
Bert
^ permalink raw reply
* Re: [PATCH 3/3] git abbref-ref: new porcelain for abbreviate_ref()
From: Bert Wesarg @ 2008-09-22 16:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git, szeder
In-Reply-To: <7vtzc8xjiv.fsf@gitster.siamese.dyndns.org>
On Mon, Sep 22, 2008 at 17:55, Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
>> Bert Wesarg <bert.wesarg@googlemail.com> wrote:
>>> This gives direct access to the abbreviate_ref() function. The operation
>>> mode defaults to the core.warnambiguousrefs value, like the refname:short
>>> format, but can be explicitly changed with the --{,no}-strict option.
>>>
>>> The bash completion script utilizes this new command.
>>
>> And it slows down too, doesn't it? Now we are doing a fork per
>> branch during completion. Yikes. Didn't you just post a series
>> about making completion faster?
>>
>>> Junio, if this is not a porcelain, tell me.
>>
>> IMHO its plumbing. Porcelain is used by a human. Plumbing is the
>> bits needed to make human interfaces.
>
> Shawn is right.
>
> I wouldn't be taking this patch to add a new command, but I suspect that
> this could be an option to rev-parse that is similar to --symbolic.
>
> Teach SHOW_SYMBOLIC_SHORTEST to builtin-rev-parse.c::show_rev(), teach the
> parser cmd_rev_parse() a new option --symbolic-abbrev and you are done,
> right?
>
You are probably right, that this small functionality could fit into
an existing program.
But I haven't look for one.
> By the way, I found it amusing to see Cc: lines _after_ three dashes to
> control send-email --- nice trick I didn't think of ;-)
The only problem is, that git format-patch outputs '---\n'
unconditionally, so I had to remove the second one by hand.
Bert
>
>
>
>
^ permalink raw reply
* Re: What's cooking in gitweb (20 Sep 2008)
From: Giuseppe Bilotta @ 2008-09-22 16:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Lea Wiemann
In-Reply-To: <200809221443.38689.jnareb@gmail.com>
On Mon, Sep 22, 2008 at 2:43 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Giuseppe Bilotta wrote:
>>
>> I'll resend the whole series (plus an additional patch to fix an
>> aesthetical issue I found recently) as soon as I fix the url
>> generation for the dotted filename corner case (which by re-reading
>> the past emails seemed to be the only significant issue, correct?).
>
> I think it was the only significant issue (besides the fact that
> two mentioned patches could be in separate series). To be more
> exact the issue was with generating gitweb URLs for sets of
> parameters which cannot be represented as path_info URL. One
> example was filename with '..' in it, which cannot be used in
> the following path_info form:
> $hash_parent_base:$file_parent..$hash_base:$filename
> but it can be used in 'no name change' form
> $hash_parent_base..$hash_base:$filename
> This requires fallback to 'query' form URL.
This is fixed in the resend.
> Other example was branch name with the same name as one of gitweb
> actions, which require action to be stated explicitly even if it
> is default action and otherwise could be omitted.
Generated urls now _always_ contain the action
>> > 2. "[PATCH] gitweb: shortlog now also obeys $hash_parent"
>> > by Giuseppe Bilotta
> [...]
>> > More important fact is that I'd very much like for _all_ log-like
>> > views (perhaps with exception of feeds: Atom and RSS) to implement
>> > this feature. This could be done by either doing it all in the same
>> > commit, doing commit series changing 'shortlog', 'log' and 'history'
>> > separately, or what I would prefer actually, to refactor generation
>> > of log-like views to use single worker/engine subroutine.
>>
>> I agree that refactoring is probably the best idea. It will also take
>> me some more time ;)
>
> But it has the advantage of making it easier to add more log-like
> views, like 'log' like view for the 'history' view, i.e. --pretty=full
> like view with path limiting.
>
> I have thought about doing the refactoring (it is/was on my long-term
> TODO list for gitweb), but I haven't even found good way to code it,
> to be flexible but not too generalized. Callbacks, perhaps?
Actually, the only reason I mentioned it would take time was to
explain why _that_ patch wouldn't be resent 'shortly' by me. I need to
study the log/shortlog/history code better to get an idea of what
might be a good refactoring strategy :)
--
Giuseppe "Oblomov" Bilotta
^ 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