* [PATCH] doc: enhance git describe --tags help
From: Pierre Habouzit @ 2008-09-28 15:12 UTC (permalink / raw)
To: Erez Zilber; +Cc: git@vger.kernel.org, open-iscsi, spearce, Junio C Hamano
In-Reply-To: <20080928150318.GI5302@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 714 bytes --]
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
Documentation/git-describe.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index c4dbc2a..9cc8c2f 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -30,7 +30,8 @@ OPTIONS
--tags::
Instead of using only the annotated tags, use any tag
- found in `.git/refs/tags`.
+ found in `.git/refs/tags`. Though if an annotated tag is found in the
+ ancestry, it will always be preferred to lightweight tags.
--contains::
Instead of finding the tag that predates the commit, find
--
1.6.0.2.516.g12936.dirty
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* Re: mysterious error message
From: tom sgouros @ 2008-09-28 15:18 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, git
In-Reply-To: <20080926143726.GZ3669@spearce.org>
I have upgraded and the problem has disappeared. Many thanks for the
advice.
-tom
Shawn O. Pearce <spearce@spearce.org> wrote:
> tom sgouros <tomfool@as220.org> wrote:
> > > On Thu, 25 Sep 2008, Tom Sgouros wrote:
> > > > I receive the following error message when I try to do a 'git push':
> > > >
> > > > tomfool@toms-box:hpl$ git push
> > > > updating 'refs/heads/master'
> > > > from ad4ae7925d3dd23798e7c5b733d2d8f930f7410f
> > > > to 5b5f5fae014a4f3535fa10b0f6e28b4bf3225dc3
> > > > Also local refs/remotes/origin/master
> > > > Generating pack...
> > > > Done counting 10 objects.
> > > > Deltifying 10 objects...
> > > > error: pack-objects died with strange error
> > > > unpack eof before pack header was fully read
> > > > ng refs/heads/master n/a (unpacker error)
> > > > error: failed to push to 'ssh://tomfool@as220.org/home/tomfool/hpl.git'
> > > > tomfool@toms-box:hpl$
> > >
> > > I got this message when I tried to push a project with submodules to a
> > > server which had submodule-ignorant git installed. Maybe it's that?
> >
> > I'm not sure which versions are submodule-ignorant, but it's version
> > 1.5.3.6 on the pusher and version 1.5.4.5 on the server. I installed
> > git via the fink package manager. Could there be some other
> > incompatibility?
>
> This change came after 1.5.3.6 and I think its what you are
> tripping over:
>
> commit 481f0ee60eef2c34b891e5d04b7e6e5a955eedf4
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Sun Nov 11 23:35:23 2007 +0000
>
> Fix rev-list when showing objects involving submodules
>
> rev-list aborting because it cannot mark a submodule commit
> as uninteresting should cause pack-objects to abort too since
> the list of objects wasn't completely produced.
>
> That fix is in 1.5.3.7 or later.
>
> --
> Shawn.
>
--
------------------------
tomfool at as220 dot org
http://sgouros.com
http://whatcheer.net
^ permalink raw reply
* Re: having to pull twice
From: Thomas Rast @ 2008-09-28 15:26 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Shawn O. Pearce, Michael P. Soulier, git
In-Reply-To: <20080928151135.GF23137@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 782 bytes --]
Miklos Vajna wrote:
>
> Oh, the racy git problem. ;-)
>
> $ git reset --hard; touch foo; git merge side
IIUC, this is not the same as "racy git". The racy case is if you
manage to get a file changed immediately after its index entry was
updated, so that it will look unchanged. In this case, it's simply
the same file with a new mtime, which means it looks changed
superficially but still has the same contents.
Granted, you could call my test "racy" because it relies on 'make
install' taking at least one second, which by Moore's law should
happen sometime around 2019 ;-)
> Thanks for the reproducer, I'll write a proper testcase for this and try to
> provide a fix for it as well.
Thanks.
- Thomas
--
Thomas Rast
trast@student.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Implementation of a "textconv" filter for easy custom diff.
From: Jeff King @ 2008-09-28 16:11 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqd4io1tla.fsf@bauges.imag.fr>
On Sun, Sep 28, 2008 at 11:57:05AM +0200, Matthieu Moy wrote:
> > Neat. I started on something like this quite a while ago,
>
> Did you publish/send it anywhere?
No, I was waiting to clean it up and test it a bit more.
> Well, OTOH, one could argue that "blame" is based on diff-ing, and
> therefore it's natural to define a diff filter to tell how "blame"
> should work.
Yes, I would have made that argument. ;)
> > [diff "foo"]
> > xfuncname = "some regex"
> > binary = auto
>
> No sure that would actually be useful in real life, but it doesn't
> harm to have it. And the argument "better path forward for defining
> sets of diff tweaks" is a good one IMO.
Yes, I think currently most diff options supersede the decision about
whether or not it's binary (like textconv, in which you probably assume
the result is diff-able as text). xfuncname doesn't, but the example is
perhaps a bit contrived. So I do think of it as more of a way for future
expansion.
I seem to recall actually running into this as part of the textconv work
I was doing, but now I can't remember the exact details. So that's not
that compelling an argumen.t :)
-Peff
^ permalink raw reply
* Re: [PATCH] Implement a textconv filter for "git diff"
From: Jeff King @ 2008-09-28 16:12 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq8wtc1tf7.fsf@bauges.imag.fr>
On Sun, Sep 28, 2008 at 12:00:44PM +0200, Matthieu Moy wrote:
> Hmm, why not, and the textconv could be different (like comparing
> old:foo.doc with ./foo.odt).
Exactly.
> One has to be carefull not to call textconv for plumbing commands,
> since the generated patches are not applicable, and only for the eyes
> of the reader.
Right, but that is prevented by not loading the appropriate diff driver
config, I believe (and I didn't look closely at your implementation in
that respect, but I believe it is the same as mine, because both
porcelain and plumbing use the code in diff.c).
-Peff
^ permalink raw reply
* Re: [PATCH 6/8] Docs: Arranged config options in man page
From: Michael Witten @ 2008-09-28 19:03 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20080928031550.GA15696@sigill.intra.peff.net>
On 27 Sep 2008, at 10:15 PM, Jeff King wrote:
> On Sat, Sep 27, 2008 at 08:09:54PM -0500, Michael Witten wrote:
>
>> Signed-off-by: Michael Witten <mfwitten@mit.edu>
>> ---
>
> Arranged in what way? I assume alphabetized, but please make it clear
> in the commit message.
Fair enough; for whatever reason, I thought I had.
> Also, Junio is out of touch for a few weeks, so it probably makes
> sense
> to send your patches to Shawn Pearce <spearce@spearce.org> in the
> interim.
Indeed. I wish Junio had setup some kind of automatic reply.
> Also also, micronit: we usually use the imperative to describe patch
> changes (i.e., "arrange" instead of "arranged").
Then I shall comply.
^ permalink raw reply
* Re: [PATCH 7/8] Docs: send-email: Added all config variables to man end
From: Michael Witten @ 2008-09-28 19:03 UTC (permalink / raw)
To: Jeff King; +Cc: gitster, git
In-Reply-To: <20080928031822.GB15696@sigill.intra.peff.net>
On 27 Sep 2008, at 10:18 PM, Jeff King wrote:
> On Sat, Sep 27, 2008 at 08:09:55PM -0500, Michael Witten wrote:
>
>> Admittedly, I didn't take much pride in my work, but
>> I'm not trying to solve this problem.
>
> Remember that your commit message is supposed to be convincing us that
> your patch is worth applying. ;P
Well, I told the truth ;-)
> It seems like these are just mechanical "sendemail.foo is a default
> for
> --foo" additions.
They are indeed!
> Maybe it is better to simply make a note of that (or
> mention it in the --foo section).
Then it would be better to do away with all but
sendemail.aliasesfile
sendemail.aliasfile
which sounds OK with me.
^ permalink raw reply
* Re: [PATCH 3/8] Docs: send-email: Man page option ordering
From: Michael Witten @ 2008-09-28 19:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <gbne1a$8g2$1@ger.gmane.org>
On 28 Sep 2008, at 3:08 AM, Jakub Narebski wrote:
> Michael Witten wrote:
>
>> Now the man page lists the options in alphabetical
>> order (in terms of the 'main' part of an option's
>> name).
>
> I know it is a matter of taste, but I prefer having options
> on man page in functional order, grouped by function, perhaps
> with subsections to group them (c.f. git-rev-list man page).
See: http://marc.info/?l=git&m=122246885210923&w=2
^ permalink raw reply
* Re: [PATCH 8/8] Docs: config: send-email config options included
From: Michael Witten @ 2008-09-28 19:03 UTC (permalink / raw)
To: Jeff King; +Cc: gitster, git
In-Reply-To: <20080928032407.GC15696@sigill.intra.peff.net>
On 27 Sep 2008, at 10:24 PM, Jeff King wrote:
> On Sat, Sep 27, 2008 at 08:09:56PM -0500, Michael Witten wrote:
>
>> I just copied what is in the send-email man text.
>
> NAK, this makes things much worse by creating two places which must be
> updated with any changes. Shouldn't doing it the right way be as
> simple
> as something like the patch below?
I also think it is stupid, but I didn't quite understand what you
meant before (I must have been skimming).
Also, the surrounding config variable definitions didn't really make
it clear that I could (or should) include a file (I didn't even think
about it, especially given that I didn't understand your original
suggestion).
> Though it looks like imap.* simply says "See git-imap-send(1)" in
> config.txt, which would also be OK by me (and makes sense especially
> if
> we drop most of the sendemail.* description in favor of just
> mentioning
> the config option near the matching command-line option).
I agree! I think these separate config variable descriptions are
superfluous and dangerously subject to obsolescence; consider
what config.txt says:
> Note that this list is non-comprehensive and not necessarily complete.
> For command-specific variables, you will find a more detailed
> description
> in the appropriate manual page. You will find a description of non-
> core
> porcelain configuration variables in the respective porcelain
> documentation.
I think config.txt is not the place to put this stuff (though I've only
given it a quick glance), and include:: will just cause us to litter
the place with tool-config.txt include files, which looks yucky and is
subject to neglect.
^ permalink raw reply
* Re: [PATCH 1/8] Docs: send-email's usage text and man page mention same options
From: Michael Witten @ 2008-09-28 19:04 UTC (permalink / raw)
To: Miklos Vajna; +Cc: gitster, git
In-Reply-To: <20080928050828.GZ23137@genesis.frugalware.org>
On 28 Sep 2008, at 12:08 AM, Miklos Vajna wrote:
> On Sat, Sep 27, 2008 at 08:09:49PM -0500, Michael Witten <mfwitten@MIT.EDU
> > wrote:
>> Specifically, boolean options are now listed in the form
>>
>> --[no-]option
>>
>> and both forms of documentation now consistently use
>>
>> --[no-]signed-off-by-cc
>
> I don't think documenting --no-foo in the perl script itself is a good
> idea. See c3170a8 (git-merge: exclude unnecessary options from
> OPTIONS_SPEC, 2008-05-12) which removes --no-foo from git-merge as
> well.
>
> Of course the man page part makes sense.
I like that it's in the help usage text, because it makes it clear how
it should be used.
Besides, I basically removed the same kind of cruft that was removed
with c3170a8, but I still managed to include the same information.
^ permalink raw reply
* Re: [PATCH 8/8] Docs: config: send-email config options included
From: Jeff King @ 2008-09-28 19:06 UTC (permalink / raw)
To: Michael Witten; +Cc: gitster, git
In-Reply-To: <C0DC4F74-6157-44AE-A25A-4C74A415CDDA@mit.edu>
On Sun, Sep 28, 2008 at 02:03:59PM -0500, Michael Witten wrote:
>> Note that this list is non-comprehensive and not necessarily complete.
>> For command-specific variables, you will find a more detailed
>> description
>> in the appropriate manual page. You will find a description of non-core
>> porcelain configuration variables in the respective porcelain
>> documentation.
>
> I think config.txt is not the place to put this stuff (though I've only
> given it a quick glance), and include:: will just cause us to litter
> the place with tool-config.txt include files, which looks yucky and is
> subject to neglect.
Ah, I hadn't read that before. So yes, I agree that it should go into
git-send-email.txt. I do think putting a note (similar to the one for
imap.*) into config.txt would be a nice addition, but it is obviously
independent of your other changes.
-Peff
^ permalink raw reply
* Re: [PATCH 7/8] Docs: send-email: Added all config variables to man end
From: Jeff King @ 2008-09-28 19:08 UTC (permalink / raw)
To: Michael Witten; +Cc: gitster, git
In-Reply-To: <C886DB88-EA48-4608-A9DB-B8A11C1240B2@MIT.EDU>
On Sun, Sep 28, 2008 at 02:03:42PM -0500, Michael Witten wrote:
>> Maybe it is better to simply make a note of that (or
>> mention it in the --foo section).
>
> Then it would be better to do away with all but
>
> sendemail.aliasesfile
> sendemail.aliasfile
>
> which sounds OK with me.
Yes, that was exactly what I meant (but I hadn't bothered to see how
many, if any, options didn't directly correspond to a command line
option).
-Peff
^ permalink raw reply
* Re: strange "git clone" behavior wrt an active branch
From: Santi Béjar @ 2008-09-28 19:43 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Git Mailing List
In-Reply-To: <ee2a733e0809280623i30a9e298i30db2a84b8530d61@mail.gmail.com>
On Sun, Sep 28, 2008 at 3:23 PM, Leo Razoumov <slonik.az@gmail.com> wrote:
> On 9/28/08, Santi Béjar <santi@agolina.net> wrote:
>> On Sun, Sep 28, 2008 at 2:05 PM, Leo Razoumov <slonik.az@gmail.com> wrote:
>> > Hi All,
>> > I am using the latest stable version git-1.6.0.2.
>> >
>> > The man page for git-clone states explicitly that "git clone"
>> >
>> > " Clones a repository into a newly created directory, ...[snip]...
>> > and creates and checks out an initial branch equal to the
>> > cloned repository's currently active branch. "
>> >
>> > I noticed that while my active branch "My" happens to point to the
>> > same commit as the "master" the git clone will check out master
>> > instead of My (currently active branch). Is it a bug?
>> >
>>
>>
>> Currently it is only guessed which is the active branch (with a
>> preference for the master branch as it is the default), as the current
>> protocol does not allow transferring the ref links:
>
> This is quite unfortunate design decision.
This is not a design decision, git has evolved, not designed. The ref
links are younger than the transfer protocols.
> There can be any number of
> local branches referring to the same commit. Without being able to
> pick into .git/HEAD it is impossible to decide which of them is
> "active".
I'm sure patches are welcome.
>
> --Leo--
>
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Petr Baudis @ 2008-09-28 21:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200809281201.04161.jnareb@gmail.com>
On Sun, Sep 28, 2008 at 12:01:03PM +0200, Jakub Narebski wrote:
> On Thu, 25 Sep 2008, Jakub Narebski wrote:
>
> > This is yet another series of planned gitweb features. It expands more
> > on new user-visible features than on improving gitweb code (therefore
> > for example using Git.pm/Git::Repo, gitweb caching, and list form of
> > open for pipelines are not mentioned here).
>
> Below there are a few more features which were missing from the list:
>
> * Support for invoking gitweb.cgi (the compiled version) from command
> line to easy generate projects list in format used by gitweb,
> perhaps also to generate web feeds (RSS, Atom, OPML). It would
> probably require adding support for CLI parameters.
Or, for starters, just document the existing one. ;-)
REQUEST_METHOD=GET QUERY_STRING=a=opml gitweb/gitweb.cgi
> * gitweb-admin or gitwebmin; I guess best as separate script.
>
> Allow to set gitweb configuration, gitweb-related per-repository
> configuration (visibility, access, description, README, URLs,...).
> Perhaps also allow to set access permissions, delete/create
> branches, change denyFastForward, rename project, set alternates,
> etc.
I don't see this very useful for gitweb administrator, but more for
owners of particular projects shown by gitweb. That would be very
useful, yes!
> * Make gitweb use less dependent on understanding git terminology, like
> 'tree' -> 'browse' etc. (proposed by Pieter de Bie (Pieter) on #git,
> as "simplified interface", 2008-09-27T14:56+0200).
>
> 'tree' -> 'browse', 'blob' -> 'file' or 'show',
> 'snapshot' -> 'archive' or 'download', 'heads' -> 'branches'
> 'commit | commitdiff | tree | snapshot' -> 'show | browse' for heads
>
> Unfortunately there is no consensus on how such simpler terminology
> should look like...
Yes, I would be very careful here. I personally agree with 'snapshot' ->
'archive' and 'heads' -> 'branches', but I'm not comfortable with the
others at all.
> * Possibly: fallback to "user.name <user.email>" for repository owner
That would be good.
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* Re: [PATCH 3/8] Docs: send-email: Man page option ordering
From: Jakub Narebski @ 2008-09-29 0:10 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <FB3A852B-728F-4183-A5AF-BA8F8D995AD7@mit.edu>
On Sun, 28 Sep 2008 21:04, Michael Witten wrote:
> On 28 Sep 2008, at 3:08 AM, Jakub Narebski wrote:
>> Michael Witten wrote:
>>
>>> Now the man page lists the options in alphabetical
>>> order (in terms of the 'main' part of an option's
>>> name).
>>
>> I know it is a matter of taste, but I prefer having options
>> on man page in functional order, grouped by function, perhaps
>> with subsections to group them (c.f. git-rev-list man page).
>
> See: http://marc.info/?l=git&m=122246885210923&w=2
You meant the following comment by Jeff King?
peff> 4/6: I am not sure about making the order of options the same,
peff> the two formats serve different purposes. I think
peff> "git send-email --foo" should present the options based on
peff> commonality of use. You clearly got the usage wrong, so
peff> I think it is helping you to figure out quickly what you
peff> probably meant.
This agrees with Gnits (GNU Coding Standard expanded) about --help
http://www.gnu.org/software/womb/gnits/Help-Output.html#Help-Output
# When a program has many options, try regrouping options logically,
instead of listing them all alphabetically (say), as the mere
regrouping is a succint way to convey much information. Present each
group of options in its own subtable, suitably introduced by some few
words. Separate groups by white lines for making the overall structure
more easy to grasp by the reader. Here is an excerpt from a relatively
big `--help' output:
Main operation mode:
-t, --list list the contents of an archive
-x, --extract, --get extract files from an archive
-c, --create create a new archive
-d, --diff, --compare find differences between archive and file system
-r, --append append files to the end of an archive
-u, --update only append files newer than copy in archive
-A, --catenate append tar files to an archive
--concatenate same as -A
--delete delete from the archive (not on mag tapes!)
Device blocking:
-b, --blocking-factor=BLOCKS BLOCKS x 512 bytes per record
--record-size=SIZE SIZE bytes per record, multiple of 512
-i, --ignore-zeros ignore zeroed blocks in archive (means EOF)
-B, --read-full-records reblock as we read (for 4.2BSD pipes)
peff> The manpage, on the other hand, is a comprehensive reference
peff> and so should probably be alphabetized for easy reading.
I haven't found definitive guide or definitive suggestion whether
options in man page should be alphabetized or put in some functional
order. GNU Coding Standards doesn't say anything; at least I haven't
found anything on this topic.
First, git lacks structured texinfo documentation, so manpages serves
_both_ as reference, and _as learning tool_. For learning you would
want options grouped by function, perhaps sorted alphabetically in
group. If you want to find some option, you can always use search
and incremental search capabilities of manpages pager.
Second, large manpages with large number of options are usually divided
into sections, see git-rev-list(1) manpage, or rpmbuild(8) manpage. So
there is precedent for that. And I think it is good precedent.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 3/8] Docs: send-email: Man page option ordering
From: Jeff King @ 2008-09-29 0:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Michael Witten, git
In-Reply-To: <200809290210.33880.jnareb@gmail.com>
On Mon, Sep 29, 2008 at 02:10:31AM +0200, Jakub Narebski wrote:
> peff> The manpage, on the other hand, is a comprehensive reference
> peff> and so should probably be alphabetized for easy reading.
>
> [...]
>
> Second, large manpages with large number of options are usually divided
> into sections, see git-rev-list(1) manpage, or rpmbuild(8) manpage. So
> there is precedent for that. And I think it is good precedent.
I am not opposed to dividing it into sections, with options alphabetized
in each section, as long as the section divisions make sense (e.g., in
rev-list, an obvious section is "commit formatting options"). I just
didn't think we had enough here to bother subdividing.
Either way will be in improvement on the current status, which is
apparently random (it looks like it was probably alphabetized at one
point, and then new options were added to the end).
-Peff
^ permalink raw reply
* Re: [PATCH 1/6] gitweb: action in path with use_pathinfo
From: Jakub Narebski @ 2008-09-29 1:03 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Lea Wiemann, Junio C Hamano
In-Reply-To: <1222030663-22540-2-git-send-email-giuseppe.bilotta@gmail.com>
I'm sorry for the delay reviewing those patches.
On Sun, 21 Sep 2008, Giuseppe Bilotta wrote:
> When using path info, reduce the number of CGI parameters by embedding
> the action in the path. The typicial cgiweb path is thus
> $project/$action/$hash_base:$file_name or $project/$action/$hash
cgiweb?
>
> This is mostly backwards compatible with the old-style gitweb paths,
> except when $project/$branch was used to access a branch whose name
> matches a gitweb action.
I would also state that gitweb _generates_ such pathinfo links if
configured (or if coming from pahinfo URL), and that this change
allow to represent wider number of gitweb links (gitweb URLs) in
pathinfo form.
Also, from what I understand, generated pathinfo links now always
use action, so they are a tiny little bit longer.
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> gitweb/gitweb.perl | 109 ++++++++++++++++++++++++++++++++++------------------
> 1 files changed, 72 insertions(+), 37 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index da474d0..e783d12 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -488,6 +488,37 @@ if (defined $searchtext) {
> $search_regexp = $search_use_regexp ? $searchtext : quotemeta $searchtext;
> }
>
> +# dispatch
> +my %actions = (
> + "blame" => \&git_blame,
> + "blobdiff" => \&git_blobdiff,
> + "blobdiff_plain" => \&git_blobdiff_plain,
> + "blob" => \&git_blob,
> + "blob_plain" => \&git_blob_plain,
> + "commitdiff" => \&git_commitdiff,
> + "commitdiff_plain" => \&git_commitdiff_plain,
> + "commit" => \&git_commit,
> + "forks" => \&git_forks,
> + "heads" => \&git_heads,
> + "history" => \&git_history,
> + "log" => \&git_log,
> + "rss" => \&git_rss,
> + "atom" => \&git_atom,
> + "search" => \&git_search,
> + "search_help" => \&git_search_help,
> + "shortlog" => \&git_shortlog,
> + "summary" => \&git_summary,
> + "tag" => \&git_tag,
> + "tags" => \&git_tags,
> + "tree" => \&git_tree,
> + "snapshot" => \&git_snapshot,
> + "object" => \&git_object,
> + # those below don't need $project
> + "opml" => \&git_opml,
> + "project_list" => \&git_project_list,
> + "project_index" => \&git_project_index,
> +);
> +
This is as I understand simply moving %actions hash around?
Well, you could instead split hash declaration from defining it,
in the form of
my %actions = ();
...
%actions = (
...
);
but I guess moving declaration earlier is good solution.
> # now read PATH_INFO and use it as alternative to parameters
> sub evaluate_path_info {
> return if defined $project;
> @@ -512,6 +543,16 @@ sub evaluate_path_info {
> # do not change any parameters if an action is given using the query string
> return if $action;
> $path_info =~ s,^\Q$project\E/*,,;
> +
> + # next comes the action
> + $action = $path_info;
> + $action =~ s,/.*$,,;
I would use perhaps "$action = ($path_info =~ m!^([^/]+)/!;"
But that is Perl, so TIMTOWDI.
> + if (exists $actions{$action}) {
> + $path_info =~ s,^\Q$action\E/*,,;
> + } else {
> + $action = undef;
> + }
> +
I don't think you need quoting pattern metacharacters; valid actions
should not contain regexp metacharacters. Defensive programming?
> my ($refname, $pathname) = split(/:/, $path_info, 2);
> if (defined $pathname) {
> # we got "project.git/branch:filename" or "project.git/branch:dir/"
> @@ -525,10 +566,12 @@ sub evaluate_path_info {
> }
> $hash_base ||= validate_refname($refname);
> $file_name ||= validate_pathname($pathname);
> + $hash ||= git_get_hash_by_path($hash_base, $file_name);
I don't understand why you feel that you need to do this (this is
additional git command fork, as git_get_hash_by_path calls Git, to
be more exact it calls git-ls-tree (it could call git-rev-parse
instead). Moreover, I don't understand why you need to do this _here_,
instead of just before where you would have to have $hash variable set.
> } elsif (defined $refname) {
> # we got "project.git/branch"
> - $action ||= "shortlog";
> - $hash ||= validate_refname($refname);
> + $action ||= "shortlog";
> + $hash ||= validate_refname($refname);
> + $hash_base ||= validate_refname($refname);
> }
> }
> evaluate_path_info();
> @@ -624,8 +636,13 @@ sub href (%) {
> if ($params{-replay}) {
> while (my ($name, $symbol) = each %mapping) {
> if (!exists $params{$name}) {
> - # to allow for multivalued params we use arrayref form
> - $params{$name} = [ $cgi->param($symbol) ];
> + if ($cgi->param($symbol)) {
> + # to allow for multivalued params we use arrayref form
> + $params{$name} = [ $cgi->param($symbol) ];
> + } else {
> + no strict 'refs';
> + $params{$name} = $$name if $$name;
> + }
> }
> }
> }
What this change is about? And why this change is _here_, in this
commit? It is I think unrelated, and wrong change.
href(..., -replay=>1) is all about reusing current URL, perhaps with
a few parameters changed, like for example pagination links differ only
in page number param change. For example if we had only hb= and f=
parameters, -replay=>1 links should use only those, and not add h=
parameter because somewhere we felt that we need $hash to be calculated.
> @@ -636,10 +653,28 @@ sub href (%) {
This hunk is about generating pathinfo URL, isn't it?
You probably would want to change comment at the top of this part
of href() subroutine, namely
if ($use_pathinfo) {
# use PATH_INFO for project name
as you now try to use PATH_INFO for more than project name. Please do
not leave comments to get out of sync with the code.
> $href .= "/".esc_url($params{'project'}) if defined $params{'project'};
> delete $params{'project'};
>
> - # Summary just uses the project path URL
> - if (defined $params{'action'} && $params{'action'} eq 'summary') {
> + # Summary just uses the project path URL, any other action come next
> + # in the URL
> + if (defined $params{'action'}) {
> + $href .= "/".esc_url($params{'action'}) unless $params{'action'} eq 'summary';
> delete $params{'action'};
> }
> +
> + # next, we put either hash_base:file_name or hash
> + if (defined $params{'hash_base'}) {
> + $href .= "/".esc_url($params{'hash_base'});
> + if (defined $params{'file_name'}) {
> + $href .= ":".esc_url($params{'file_name'});
> + delete $params{'hash'} if $params{'hash'} eq git_get_hash_by_path($params{'hash_base'},$params{'file_name'});
First, this page has around 140 characters. That is too long, much too long.
Please try to wrap code around 80-characters.
Second, following Petr 'Pasky' Baudis suggestion of reducing complexity
and shortening gitweb URLs, we could unconditionally remove redundant
'hash' parameter if we have both 'hash_base' and 'file_name'
parameters. This would also simplify and speed up (lack of extra fork)
gitweb code.
> + delete $params{'file_name'};
> + } else {
> + delete $params{'hash'} if $params{'hash'} eq $params{'hash_base'};
> + }
> + delete $params{'hash_base'};
> + } elsif (defined $params{'hash'}) {
> + $href .= "/".esc_url($params{'hash'});
> + delete $params{'hash'};
> + }
O.K.... I think.
Did you test this, preferably also using Mechanize test, with gitweb
configuration turning path_info on by default.?
> }
>
> # now encode the parameters explicitly
Hmmm... now I am not so sure if it wouldn't be better to split this
patch in pathinfo parsing and pathinfo generation. The first part
would be obvious, the second part would be smaller and easier to review.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 2/6] gitweb: use_pathinfo filenames start with /
From: Jakub Narebski @ 2008-09-29 1:08 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Lea Wiemann, Junio C Hamano
In-Reply-To: <1222030663-22540-3-git-send-email-giuseppe.bilotta@gmail.com>
On Sun, 21 Sep 2008, Giuseppe Bilotta wrote:
> When using path info, make filenames start with a / (right after the :
> that separates them from the hash base). This minimal change allows
> relative navigation to work properly when viewing HTML files.
Good idea. Nitpick: instead of "using path info", perhaps "generating
path info URL"; this change is about gitweb link generation...
Did you check if gitweb strips leading '/' from filename?
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> gitweb/gitweb.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index e783d12..18da484 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -664,7 +664,7 @@ sub href (%) {
> if (defined $params{'hash_base'}) {
> $href .= "/".esc_url($params{'hash_base'});
> if (defined $params{'file_name'}) {
> - $href .= ":".esc_url($params{'file_name'});
> + $href .= ":/".esc_url($params{'file_name'});
> delete $params{'hash'} if $params{'hash'} eq git_get_hash_by_path($params{'hash_base'},$params{'file_name'});
> delete $params{'file_name'};
> } else {
> --
> 1.5.6.5
Is there reason why this change is separate (not squashed) from
previous commit?
--
Jakub Narebski
Poland
^ permalink raw reply
* interactive rebase not rebasing
From: Stephen Haberman @ 2008-09-29 4:50 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 2715 bytes --]
Hello,
Per the emails from me last week, I'm working in an environment with
shared topic branches and am trying to find a bullet-proof way for devs
to rebase their local commits after the topic branch has moved.
The easy approach would be to just let `git pull` create merge commits,
and I would have been done with this long ago, but I'm striving to get
rebasing to "just work" and avoid the ugliness of same-branch merge
commits. Cross-branch merge commits are cool, but not same-branch.
So, here's a crazy scenario we've ran into--a new release has hit
stable, with two devs working on the same topic branch, and both of them
merge. One wins, and the other has to rebase. Previously, this was
replaying commits, but with great tips from the list last week, `rebase
-i -p` is handling most scenarios.
However, not this one:
# A --C------ <-- origin/stable
# \ | \
# B -- D -- E -- F <-- origin/topic2
# \|
# g -- h <-- topic2
topic2 is a dev that has locally merged stable in g, moved on in h, is
ready to push, but another dev already merged stable in E, and also
committed F.
If we do a `git pull --no-rebase`, the result is:
# A --C------ <-- origin/stable
# \ | \
# B -- D -- E -- F <-- origin/topic2
# \| \
# g -- h ------- i <-- topic2
But i is a same-branch merge, and we'd rather rebase to something like:
# A --C------ <-- origin/stable
# \ \
# B -- D -- E -- F <-- origin/topic2
# \
# h' <-- topic2
(...maybe g' in there if g resolved stable conflicts differently
E did them. I'm not sure, I haven't gotten there yet.)
However, currently, `git rebase -i -p origin/topic2` results in:
# A --C------ <-- origin/stable
# \ | \
# B -- D -- E -- F <-- origin/topic2
# \|
# g -- h <-- topic2
Nothing has changed. g & h haven't moved...I can keep executing this
operation and the commits never make it on top of origin/topic2's F.
Frustratingly, if I run non-interactive rebase, it works perfectly. But
I've got other cases (see earlier posts) that do need the interactive
rebase. Personally, I could probably make do with trying each and
seeing what happened, but I'm really trying to find a bullet proof
command/alias/script for devs to run and have it "just work".
I've attached a test that sets up the DAG as above and currently passes
by asserting the not-desired/unchanged-DAG result. The assert for the
desired result is commented out at the end.
Am I correct in asserting this is some sort of bug in the interactive
rebase such that g & h are not ending up on top of F?
Thanks,
Stephen
[-- Attachment #2: t3404b.sh --]
[-- Type: text/x-sh, Size: 2680 bytes --]
#!/bin/sh
test_description='rebase interactive does not rebase'
. ./test-lib.sh
test_expect_success 'setup' '
echo "setup" >a &&
git add a &&
git commit -m "setup" &&
git clone ./. server &&
rm -fr server/.git/hooks &&
git remote add origin ./server &&
git config --add branch.master.remote origin &&
git config --add branch.master.merge refs/heads/master &&
git fetch &&
git checkout -b stable master &&
echo "setup.stable" >a &&
git commit -a -m "stable" &&
git push origin stable
'
#
# A --C------ <-- origin/stable
# \ | \
# B -- D -- E -- F <-- origin/topic2
# \| \
# g -- h ------- i <-- topic2
#
# Trying to push F..i
#
# merge-base(F, h) has two options: B and C
#
test_expect_success 'merging in stable with tricky double baserev does not fool the script' '
# B: start our topic2 branch, and share it
git checkout -b topic2 origin/stable &&
git config --add branch.topic2.merge refs/heads/topic2 &&
echo "commit B" >a.topic2 &&
git add a.topic2 &&
git commit -m "commit B created topic2" &&
git push origin topic2 &&
# C: now, separately, move ahead stable, and share it
git checkout stable
echo "commit C" >a &&
git commit -a -m "commit C moved stable" &&
git push origin stable &&
# D: have another client commit (in this case, it is the server, but close enough) moves topic2
cd server &&
git checkout topic2 &&
echo "commit D continuing topic2" >a.client2 &&
git add a.client2 &&
git commit -m "commit D by client2" &&
# E: the same other client merges the moved stable
git merge stable &&
# F: the same other client moves topic2 again
echo "commit F" >a.client2 &&
git commit -a -m "commit F by client2" &&
F_hash=$(git rev-parse HEAD) &&
cd .. &&
# g: now locally merge in the moved stable (even though our topic2 is out of date)
git checkout topic2 &&
git merge stable &&
g_hash=$(git rev-parse HEAD) &&
# h: advance local topic2
echo "commit H" >a.topic2 &&
git commit -a -m "commit H continues local fork" &&
h_hash=$(git rev-parse HEAD) &&
# i: make a new merge commit
git pull --no-rebase &&
i_hash=$(git rev-parse HEAD) &&
# Watch merge rejected as something that should get rebased
# ! git push origin topic2
test "$i_hash $h_hash $F_hash" = "$(git rev-list --parents --no-walk HEAD)"
# Now fix it the merge by rebasing it
git reset --hard ORIG_HEAD &&
GIT_EDITOR=: git rebase -i -p origin/topic2 &&
h2_hash=$(git rev-parse HEAD) &&
# Should be:
# test "$h2_hash $F_hash" = "$(git rev-list --parents --no-walk HEAD)"
# But is just:
test "$h_hash $g_hash" = "$(git rev-list --parents --no-walk HEAD)"
# Where did $F_hash go?
'
test_done
^ permalink raw reply
* [RFC 6/9] Docs: send-email: Remove unnecessary config variable description
From: Michael Witten @ 2008-09-29 5:08 UTC (permalink / raw)
To: git
In-Reply-To: <20080929003636.GA18552@coredump.intra.peff.net>
The config variables are mentioned within the descriptions of the
command line options with which they are associated.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 91 +++++++-------------------------------
1 files changed, 16 insertions(+), 75 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 6b62032..0d6ac4a 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -24,7 +24,8 @@ OPTIONS
The options available are:
--bcc::
- Specify a "Bcc:" value for each email.
+ Specify a "Bcc:" value for each email. Default is the value of
+ 'sendemail.bcc'.
+
The --bcc option must be repeated for each user you want on the bcc list.
@@ -85,9 +86,9 @@ The --cc option must be repeated for each user you want on the cc list.
all that is output.
--[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.
+ 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.
--smtp-encryption::
Specify the encryption to use, either 'ssl' or 'tls'. Any other
@@ -97,22 +98,13 @@ The --cc option must be repeated for each user you want on the cc list.
--smtp-pass::
Password for SMTP-AUTH. The argument is optional: If no
argument is specified, then the empty string is used as
- the password.
-+
-In place of this option, the following configuration variables
-can be specified:
-+
---
- * sendemail.smtppass
- * sendemail.<identity>.smtppass (see sendemail.identity).
---
-+
-However, --smtp-pass always overrides these variables.
+ the password. Default is the value of 'sendemail.smtppass',
+ however '--smtp-pass' always overrides this value.
+
Furthermore, passwords need not be specified in configuration files
or on the command line. If a username has been specified (with
---smtp-user or a configuration variable), but no password has been
-specified (with --smtp-pass or a configuration variable), then the
+'--smtp-user' or a 'sendemail.smtpuser'), but no password has been
+specified (with '--smtp-pass' or 'sendemail.smtppass'), then the
user is prompted for a password while the input is masked for privacy.
--smtp-server::
@@ -128,24 +120,15 @@ user is prompted for a password while the input is masked for privacy.
--smtp-server-port::
Specifies a port different from the default port (SMTP
servers typically listen to smtp port 25 and ssmtp port
- 465).
+ 465). This can be set with 'sendemail.smtpserverport'.
--smtp-ssl::
- Legacy alias for '--smtp-encryption=ssl'.
+ Legacy alias for '--smtp-encryption ssl'.
--smtp-user::
- Username for SMTP-AUTH. In place of this option, the following
- configuration variables can be specified:
-+
---
- * sendemail.smtpuser
- * sendemail.<identity>.smtpuser (see sendemail.identity).
---
-+
-However, --smtp-user always overrides these variables.
-+
-If a username is not specified (with --smtp-user or a
-configuration variable), then authentication is not attempted.
+ Username for SMTP-AUTH. Default is the value of 'sendemail.smtpuser';
+ if a username is not specified (with '--smtp-user' or 'sendemail.smtpuser'),
+ then authentication is not attempted.
--subject::
Specify the initial subject of the email thread.
@@ -191,18 +174,12 @@ The --to option must be repeated for each user you want on the to list.
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
+Default is the value of 'sendemail.validate'; if this is not set,
+default to '--validate'.
CONFIGURATION
-------------
-sendemail.identity::
- The default configuration identity. When specified,
- 'sendemail.<identity>.<item>' will have higher precedence than
- 'sendemail.<item>'. This is useful to declare multiple SMTP
- identities and to hoist sensitive authentication information
- out of the repository and into the global configuration file.
-
sendemail.aliasesfile::
To avoid typing long email addresses, point this to one or more
email aliases files. You must also supply 'sendemail.aliasfiletype'.
@@ -211,42 +188,6 @@ sendemail.aliasfiletype::
Format of the file(s) specified in sendemail.aliasesfile. Must be
one of 'mutt', 'mailrc', 'pine', or 'gnus'.
-sendemail.to::
- Email address (or alias) to always send to.
-
-sendemail.cccmd::
- Command to execute to generate per patch file specific "Cc:"s.
-
-sendemail.bcc::
- Email address (or alias) to always bcc.
-
-sendemail.chainreplyto::
- Boolean value specifying the default to the '--[no-]chain-reply-to'
- parameter.
-
-sendemail.smtpserver::
- Default SMTP server to use.
-
-sendemail.smtpserverport::
- Default SMTP server port to use.
-
-sendemail.smtpuser::
- Default SMTP-AUTH username.
-
-sendemail.smtppass::
- Default SMTP-AUTH password.
-
-sendemail.smtpencryption::
- Default encryption method. Use 'ssl' for SSL (and specify an
- appropriate port), or 'tls' for TLS. Takes precedence over
- 'smtpssl' if both are specified.
-
-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>
--
1.6.0.2.304.gdcf23.dirty
^ permalink raw reply related
* [RFC 7/9] send-email: Completely replace --signed-off-cc with --signed-off-by-cc
From: Michael Witten @ 2008-09-29 5:08 UTC (permalink / raw)
To: git
In-Reply-To: <1222664892-55810-1-git-send-email-mfwitten@mit.edu>
This breaks backwards compatibility, but so what---get off your
lazy arses and remove the cruft.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 2 +-
git-send-email.perl | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 0d6ac4a..8ffe525 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -87,7 +87,7 @@ The --cc option must be repeated for each user you want on the cc list.
--[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
+ cc list. Default is the value of 'sendemail.signedoffbycc' configuration
value; if that is unspecified, default to --signed-off-by-cc.
--smtp-encryption::
diff --git a/git-send-email.perl b/git-send-email.perl
index 3467cf1..4662d28 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -144,7 +144,7 @@ if ($@) {
my ($quiet, $dry_run) = (0, 0);
# Variables with corresponding config settings
-my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
+my ($thread, $chain_reply_to, $suppress_from, $signed_off_by_cc, $cc_cmd);
my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_encryption);
my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
my ($validate);
@@ -154,7 +154,7 @@ my %config_bool_settings = (
"thread" => [\$thread, 1],
"chainreplyto" => [\$chain_reply_to, 1],
"suppressfrom" => [\$suppress_from, undef],
- "signedoffcc" => [\$signed_off_cc, undef],
+ "signedoffbycc" => [\$signed_off_by_cc, undef],
"validate" => [\$validate, 1],
);
@@ -218,7 +218,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"cc-cmd=s" => \$cc_cmd,
"suppress-from!" => \$suppress_from,
"suppress-cc=s" => \@suppress_cc,
- "signed-off-cc|signed-off-by-cc!" => \$signed_off_cc,
+ "signed-off-by-cc!" => \$signed_off_by_cc,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
"thread!" => \$thread,
@@ -294,7 +294,7 @@ if ($suppress_cc{'all'}) {
# If explicit old-style ones are specified, they trump --suppress-cc.
$suppress_cc{'self'} = $suppress_from if defined $suppress_from;
-$suppress_cc{'sob'} = !$signed_off_cc if defined $signed_off_cc;
+$suppress_cc{'sob'} = !$signed_off_by_cc if defined $signed_off_by_cc;
# Debugging, print out the suppressions.
if (0) {
--
1.6.0.2.304.gdcf23.dirty
^ permalink raw reply related
* [RFC 9/9] Docs: send-email: Create logical groupings for man text
From: Michael Witten @ 2008-09-29 5:08 UTC (permalink / raw)
To: git
In-Reply-To: <1222664892-55810-3-git-send-email-mfwitten@mit.edu>
The options are partitioned into more digestible groups.
Within these groups, the options are sorted alphabetically.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 119 ++++++++++++++++++++++----------------
1 files changed, 69 insertions(+), 50 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 8ffe525..82f5056 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -19,9 +19,12 @@ The header of the email is configurable by command line options. If not
specified on the command line, the user will be prompted with a ReadLine
enabled interface to provide the necessary information.
+
OPTIONS
-------
-The options available are:
+
+Composing
+~~~~~~~~~
--bcc::
Specify a "Bcc:" value for each email. Default is the value of
@@ -34,46 +37,15 @@ The --bcc option must be repeated for each user you want on the bcc list.
+
The --cc option must be repeated for each user you want on the cc list.
---cc-cmd::
- Specify a command to execute once per patch file which
- should generate patch file specific "Cc:" entries.
- 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.
-
--compose::
Use $GIT_EDITOR, core.editor, $VISUAL, or $EDITOR to edit an
introductory message for the patch series.
---dry-run::
- Do everything except actually send the emails.
-
---envelope-sender::
- Specify the envelope sender used to send the emails.
- This is useful if your default address is not the address that is
- subscribed to a list. If you use the sendmail binary, you must have
- suitable privileges for the -f parameter. Default is the value of
- the 'sendemail.envelopesender' configuration variable; if that is
- unspecified, choosing the envelope sender is left to your MTA.
-
--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.
---identity::
- A configuration identity. When given, causes values in the
- 'sendemail.<identity>' subsection to take precedence over
- values in the 'sendemail' section. The default identity is
- the value of 'sendemail.identity'.
-
--in-reply-to::
Specify the contents of the first In-Reply-To header.
Subsequent emails will refer to the previous email
@@ -81,14 +53,30 @@ 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.
---quiet::
- Make git-send-email less verbose. One line per email should be
- all that is output.
+--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-]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.signedoffbycc' configuration
- value; if that is unspecified, default to --signed-off-by-cc.
+--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.
+
+
+Sending
+~~~~~~~
+
+--envelope-sender::
+ Specify the envelope sender used to send the emails.
+ This is useful if your default address is not the address that is
+ subscribed to a list. If you use the sendmail binary, you must have
+ suitable privileges for the -f parameter. Default is the value of
+ the 'sendemail.envelopesender' configuration variable; if that is
+ unspecified, choosing the envelope sender is left to your MTA.
--smtp-encryption::
Specify the encryption to use, either 'ssl' or 'tls'. Any other
@@ -130,10 +118,34 @@ user is prompted for a password while the input is masked for privacy.
if a username is not specified (with '--smtp-user' or 'sendemail.smtpuser'),
then authentication is not attempted.
---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.
+
+Automating
+~~~~~~~~~~
+
+--cc-cmd::
+ Specify a command to execute once per patch file which
+ should generate patch file specific "Cc:" entries.
+ 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.
+
+--identity::
+ A configuration identity. When given, causes values in the
+ 'sendemail.<identity>' subsection to take precedence over
+ values in the 'sendemail' section. The default identity is
+ the value of 'sendemail.identity'.
+
+--[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.signedoffbycc' configuration
+ value; if that is unspecified, default to --signed-off-by-cc.
--suppress-cc::
Specify an additional category of recipients to suppress the
@@ -157,13 +169,16 @@ user is prompted for a password while the input is masked for privacy.
header set. Default is the value of the 'sendemail.thread' configuration
value; if that is unspecified, default to --thread.
---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.
+
+Administering
+~~~~~~~~~~~~~
+
+--dry-run::
+ Do everything except actually send the emails.
+
+--quiet::
+ Make git-send-email less verbose. One line per email should be
+ all that is output.
--[no-]validate::
Perform sanity checks on patches.
@@ -180,6 +195,7 @@ default to '--validate'.
CONFIGURATION
-------------
+
sendemail.aliasesfile::
To avoid typing long email addresses, point this to one or more
email aliases files. You must also supply 'sendemail.aliasfiletype'.
@@ -188,6 +204,7 @@ sendemail.aliasfiletype::
Format of the file(s) specified in sendemail.aliasesfile. Must be
one of 'mutt', 'mailrc', 'pine', or 'gnus'.
+
Author
------
Written by Ryan Anderson <ryan@michonline.com>
@@ -195,10 +212,12 @@ Written by Ryan Anderson <ryan@michonline.com>
git-send-email is originally based upon
send_lots_of_email.pl by Greg Kroah-Hartman.
+
Documentation
--------------
Documentation by Ryan Anderson
+
GIT
---
Part of the linkgit:git[1] suite
--
1.6.0.2.304.gdcf23.dirty
^ permalink raw reply related
* [RFC 8/9] Docs: send-email: Create logical groupings for --help text
From: Michael Witten @ 2008-09-29 5:08 UTC (permalink / raw)
To: git
In-Reply-To: <1222664892-55810-2-git-send-email-mfwitten@mit.edu>
The options are partitioned into more digestible groups.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
git-send-email.perl | 61 ++++++++++++++++++++++++++++----------------------
1 files changed, 34 insertions(+), 27 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 4662d28..127acb7 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -39,33 +39,40 @@ package main;
sub usage {
print <<EOT;
git send-email [options] <file | directory>...
-Options:
- --identity <str> * Use the sendemail.<id> options.
- --from <str> * Email From:
- --envelope-sender <str> * Email envelope sender.
- --to <str> * Email To:
- --cc <str> * Email Cc:
- --cc-cmd <str> * Email Cc: via `<str> \$patch_path`
- --bcc <str> * Email Bcc:
- --subject <str> * Email "Subject:" (only if --compose).
- --compose * Open an editor for introduction.
- --in-reply-to <str> * First "In-Reply-To:" (only if --compose).
- --[no-]chain-reply-to * Chain In-Reply-To: fields. Default on.
- --[no-]thread * Use In-Reply-To: field. Default on.
- --[no-]signed-off-by-cc * Actually send to Cc: and Signed-off-by:
- addresses. Default on.
- --suppress-cc <str> * author, self, sob, cccmd, all.
- --[no-]suppress-from * Don't send email to self. Default off.
- --smtp-server <str:int> * Outgoing SMTP server to use. The port
- is optional. Default 'localhost'.
- --smtp-server-port <int> * Outgoing SMTP server port.
- --smtp-user <str> * The username for SMTP-AUTH.
- --smtp-pass <str> * The password for SMTP-AUTH; not necessary.
- --smtp-encryption <str> * tls or ssl; anything else disables.
- --smtp-ssl * Deprecated. Use '--smtp-encryption ssl'.
- --quiet * Output one line of info per email.
- --dry-run * Don't actually send the emails.
- --[no-]validate * Perform patch sanity checks. Default on.
+
+ Composing:
+ --from <str> * Email From:
+ --to <str> * Email To:
+ --cc <str> * Email Cc:
+ --bcc <str> * Email Bcc:
+ --subject <str> * Email "Subject:"
+ --in-reply-to <str> * Email "In-Reply-To:"
+ --compose * Open an editor for introduction.
+
+ Sending:
+ --envelope-sender <str> * Email envelope sender.
+ --smtp-server <str:int> * Outgoing SMTP server to use. The port
+ is optional. Default 'localhost'.
+ --smtp-server-port <int> * Outgoing SMTP server port.
+ --smtp-user <str> * Username for SMTP-AUTH.
+ --smtp-pass <str> * Password for SMTP-AUTH; not necessary.
+ --smtp-encryption <str> * tls or ssl; anything else disables.
+ --smtp-ssl * Deprecated. Use '--smtp-encryption ssl'.
+
+ Automating:
+ --identity <str> * Use the sendemail.<id> options.
+ --cc-cmd <str> * Email Cc: via `<str> \$patch_path`
+ --suppress-cc <str> * author, self, sob, cccmd, all.
+ --[no-]signed-off-by-cc * Send to Cc: and Signed-off-by:
+ addresses. Default on.
+ --[no-]suppress-from * Send to self. Default off.
+ --[no-]chain-reply-to * Chain In-Reply-To: fields. Default on.
+ --[no-]thread * Use In-Reply-To: field. Default on.
+
+ Administering:
+ --quiet * Output one line of info per email.
+ --dry-run * Don't actually send the emails.
+ --[no-]validate * Perform patch sanity checks. Default on.
EOT
exit(1);
--
1.6.0.2.304.gdcf23.dirty
^ permalink raw reply related
* Re: [PATCH] usage.c: remove unused functions
From: Lars Hjemli @ 2008-09-29 6:35 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Petr Baudis, Jonas Fonseca, Thomas Rast, Nanako Shiraishi,
Junio C Hamano, git
In-Reply-To: <20080925145134.GL3669@spearce.org>
On Thu, Sep 25, 2008 at 4:51 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Petr Baudis <pasky@suse.cz> wrote:
>> On Thu, Sep 25, 2008 at 01:48:37PM +0200, Thomas Rast wrote:
>> > Nanako Shiraishi wrote:
>> > > This removes three functions that are not used anywhere.
>> > [...]
>> > > -void set_usage_routine(void (*routine)(const char *err) NORETURN)
>> > > -void set_error_routine(void (*routine)(const char *err, va_list params))
>> > > -void set_warn_routine(void (*routine)(const char *warn, va_list params))
>> >
>> > These blame to the following commit:
>> >
>> > commit 39a3f5ea7c0352a530338d30d4e618f6b4db84e4
>> > Author: Petr Baudis <pasky@suse.cz>
>> >
>> > Customizable error handlers
> ...
>> > So apparently the intent was that they would only be used from outside
>> > Git. I don't know whether anyone still plans to do that, but they're
>> > certainly not "just" unused.
>>
>> I don't think it will be a big deal to remove these functions, though it
>> does feel like a little bit of a step backwards in the libgit efforts.
>> There are some programs that already link to Git, like CGit - I wonder
>> if some of them don't use them (CGit itself doesn't).
>
> IMHO these are useless for a "libgit". However both tig and
> cgit link to the non-existant libgit.a, so they may be using
> these routines. I've CC'd their authors and am not applying this
> particular change without an ACK from them.
Sorry for the late reply. And no, cgit doesn't use these functions and
I don't think that's going to change, so
Acked-by: Lars Hjemli <hjemli@gmail.com>
--
larsh
^ permalink raw reply
* Re: interactive rebase not rebasing
From: Andreas Ericsson @ 2008-09-29 6:42 UTC (permalink / raw)
To: Stephen Haberman; +Cc: git
In-Reply-To: <20080928235013.5c749c6e.stephen@exigencecorp.com>
Stephen Haberman wrote:
> Hello,
>
> Per the emails from me last week, I'm working in an environment with
> shared topic branches and am trying to find a bullet-proof way for devs
> to rebase their local commits after the topic branch has moved.
>
> The easy approach would be to just let `git pull` create merge commits,
> and I would have been done with this long ago, but I'm striving to get
> rebasing to "just work" and avoid the ugliness of same-branch merge
> commits. Cross-branch merge commits are cool, but not same-branch.
>
> So, here's a crazy scenario we've ran into--a new release has hit
> stable, with two devs working on the same topic branch, and both of them
> merge. One wins, and the other has to rebase. Previously, this was
> replaying commits, but with great tips from the list last week, `rebase
> -i -p` is handling most scenarios.
>
> However, not this one:
>
> # A --C------ <-- origin/stable
> # \ | \
> # B -- D -- E -- F <-- origin/topic2
> # \|
> # g -- h <-- topic2
>
> topic2 is a dev that has locally merged stable in g, moved on in h, is
> ready to push, but another dev already merged stable in E, and also
> committed F.
>
> If we do a `git pull --no-rebase`, the result is:
>
> # A --C------ <-- origin/stable
> # \ | \
> # B -- D -- E -- F <-- origin/topic2
> # \| \
> # g -- h ------- i <-- topic2
>
> But i is a same-branch merge, and we'd rather rebase to something like:
>
> # A --C------ <-- origin/stable
> # \ \
> # B -- D -- E -- F <-- origin/topic2
> # \
> # h' <-- topic2
>
> (...maybe g' in there if g resolved stable conflicts differently
> E did them. I'm not sure, I haven't gotten there yet.)
>
> However, currently, `git rebase -i -p origin/topic2` results in:
>
> # A --C------ <-- origin/stable
> # \ | \
> # B -- D -- E -- F <-- origin/topic2
> # \|
> # g -- h <-- topic2
>
> Nothing has changed. g & h haven't moved...I can keep executing this
> operation and the commits never make it on top of origin/topic2's F.
>
> Frustratingly, if I run non-interactive rebase, it works perfectly.
I can imagine. Since you don't want to preserve the merges in this
case, you shouldn't be using the -p flag.
In fact, for this particular scenario (assuming "h" is really the only
commit on topic2), you probably want to just cherry-pick that commit
into origin/topic2:
git checkout topic2
git reset --hard origin/topic2
git cherry-pick ORIG_HEAD
would work nicely for that. If topic2 and topic1 resolved merge
conflicts differently, cherry-picking topic2 will give conflicts again,
so they'll have to be resolved. rebase (without -p) will have the same
effect, ofcourse.
I don't think you can have a single command that does all the things
you want, because the possible differences in input makes it very nearly
impossible to always do "the right thing". For this case, you don't
want to preserve merges, so "git rebase" without -p does the right
thing. For that other case earlier this week, you wanted to preserve
merges, so "git rebase -p" does the right thing there. It's complex
to try to dwim things like that, and complexity will cause very weird
and surprising errors when it *does* fail.
Instead, I think you should give your developers some training in the
more advanced parts of git's integration tools and also look over
your workflow. Frequently merging 'master' into a topic is very rarely
the right thing to do. It's usually better to rebase the topic onto
master or cherry-pick relevant bugfixes from 'master' into the topic.
If two devs need to work on one topic, then that topic probably needs
breaking up into a sub-topic. However, sub-topics should never merge
'master' into them themselves; only 'topic'. Otherwise you'll get
more merges than work done.
> But
> I've got other cases (see earlier posts) that do need the interactive
> rebase. Personally, I could probably make do with trying each and
> seeing what happened, but I'm really trying to find a bullet proof
> command/alias/script for devs to run and have it "just work".
>
Or you could sit down and think about what you want to happen and then
run the appropriate command. ;-)
> I've attached a test that sets up the DAG as above and currently passes
> by asserting the not-desired/unchanged-DAG result. The assert for the
> desired result is commented out at the end.
>
Thanks for this. If all bug-reports had this, bugfixing would be a lot
easier. However, for this particular case, I'm not so sure it's a bug.
> Am I correct in asserting this is some sort of bug in the interactive
> rebase such that g & h are not ending up on top of F?
>
Assuming you're passing a correct input file to rebase -i; yes. At the
very least, "h" should be moved to the tip of origin/topic2.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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