* Re: Notes in format-patch
From: Junio C Hamano @ 2012-11-14 13:15 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Jeff King
In-Reply-To: <50A361BD.2010806@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Junio C Hamano venit, vidit, dixit 13.11.2012 19:09:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> ... and it is broken X-<.
>>>
>>> The blank line should be added before the diffstat, not after the
>>> notes message (t3307 shows a case where we give notes without
>>> diffstat, and we shouldn't be adding an extra blank line in that
>>> case.
>>
>> Second try.
>>
>> -- >8 --
>> Subject: format-patch: add a blank line between notes and diffstat
>>
>> The last line of the note text comes immediately before the diffstat
>> block, making the latter unnecessarily harder to view.
>>
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>> ---
>>
>> log-tree.c | 31 +++++++++++++++++++++----------
>> 1 file changed, 21 insertions(+), 10 deletions(-)
>
> Thanks, that patch works. I'm curious, though, where the empty line
> between the --- and your diffstat comes from.
The message you are responding to is *not* an output from
format-patch but was written in my MUA.
The way I work when I show "this should work" patch is to:
(1) Think, edit in my working tree, compile, eyeball "git diff HEAD",
think again, and test;
(2) Hit "Reply All" to the message I am going to give "this should
work" response to, and start composing the response;
(3) Run "git diff --stat -p HEAD" to have its output appended at
the end of the message I started to compose in the previous
step;
(4) Write everything that should come before the output I appended
in the previous step, i.e. "-- >8 --", in-body "Subject:", log,
sign-off, and three-dash lines;
(5) Send it out; and
(6) Run "git reset --hard" and move on.
The blank line was added in step (4), not step (3), which does not
even have any commit log message, as the patch does not come from
any existing commit. Later I may pick it up and apply to a topic
branch just like I do for patches from other people and that is the
point when such a patch becomes a commit for the first time.
^ permalink raw reply
* Re: [PATCH v3 0/5] push: update remote tags only with force
From: Junio C Hamano @ 2012-11-14 13:22 UTC (permalink / raw)
To: Chris Rorvick
Cc: git, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras
In-Reply-To: <CAEUsAPZtF-L5J_g1L5d44BKveoAnJ81PatX94fFS4FM=iW33KA@mail.gmail.com>
Chris Rorvick <chris@rorvick.com> writes:
>> "Do not update, only add new" may be a good feature, but at the same
>> time I have this suspicion that its usefulness may not necessarily
>> be limited to refs/tags/* hierarchy.
>>
>> I dunno.
>
> Are you suggesting allowing forwards for just refs/heads/*?
No, it is a nonsense to unconditionally forbid fast-forwards to refs
outside refs/heads/ hierarchy.
I was imagining a more general feature to allow the *user* to ask
Git not to fast-forward some refs (not limited to refs/tags/) during
a push.
If such a general feature were in place, you can think of your patch
as automatically making the user to ask Git not to fast-forward refs
in refs/tags/, which would be a mere special case of it.
And I was wondering if such a general feature makes sense.
^ permalink raw reply
* Re: bug? git format-patch -M -D then git am fails
From: Michael J Gruber @ 2012-11-14 13:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joe Perches, git, David Miller
In-Reply-To: <7vfw4dccm7.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 14.11.2012 00:22:
> Joe Perches <joe@perches.com> writes:
>
>> I don't believe that reversibility
>> is a really useful aspect of deletion patches
>> when there are known git repositories involved.
>
> You can read "reversibility" as "safety" if you want. We would want
> to make sure we know what we are deleting before deleting a path.
>
> The history that the receiver of such a patch has may have further
> changes that are relevant that the sender of the deletion patch did
> not know about, and removing the path in such a case would make the
> result inconsistent. If the sender did his work on top of the newer
> version with the change in the path, the sender's patch may still
> have deleted the path but would have had changes to other paths to
> compensate for the loss of that change.
>
Just in case someone wants to hack on this: To be safe, "git am" would
need to read the blob's sha1 from something like
diff --git a/Makefile b/Makefile
deleted file mode 100644
index 1b6d84d..0000000
and check that the file to be deleted matches.
Michael
^ permalink raw reply
* Re: [PATCHv3 3/4] git-status: show short sequencer state
From: Junio C Hamano @ 2012-11-14 13:29 UTC (permalink / raw)
To: Phil Hord
Cc: git, phil.hord, Jeff King, konglu, Matthieu Moy, Kong Lucien,
Duperray Valentin, Jonas Franck, Nguy Thomas
In-Reply-To: <50A2DCD7.4050909@cisco.com>
Phil Hord <hordp@cisco.com> writes:
>> Do you think '--tree-state' is an acceptable switch or do you have other
>> suggestions?
>
> I've been calling these 'tokens' myself. A token is a word-or-phrase I
> can parse easily with the default $IFS, for simpler script handling.
That name may be good for variables, but it is good only because you
as the implementor know what purpose the tokens are used for.
Instead of having to call them with a longer name, e.g. "state
tokens", only because you know that these tokens represent tree-wide
(as opposed to per-file) state, you can call them "tokens" in your
implementation (and in your head) without confusing yourself.
To the end users who should not care about the implementation
detail, it is not a good name at all. The UI should surface the
purpose, i.e. what these tokens are used for, (e.g. to represent
tree-wide state) more than the fact that you happened to represent
them with a single short word (i.e. "token").
So --show-tree-state, --include-tree-state-in-the-output or
something along that line that tells the user what the option is
about is more preferable than --token. After all, you may want to
use tokens to represent different kind of information in a later
topic that is not about a tree-wide state, and you will regret that
you used --token for this particular feature at that time.
^ permalink raw reply
* Re: [PATCHv3 3/4] git-status: show short sequencer state
From: Phil Hord @ 2012-11-14 13:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, phil.hord, Jeff King, konglu, Matthieu Moy, Kong Lucien,
Duperray Valentin, Jonas Franck, Nguy Thomas
In-Reply-To: <7vy5i4b9d8.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Phil Hord <hordp@cisco.com> writes:
>
>>> Do you think '--tree-state' is an acceptable switch or do you have other
>>> suggestions?
>> I've been calling these 'tokens' myself. A token is a word-or-phrase I
>> can parse easily with the default $IFS, for simpler script handling.
> That name may be good for variables, but it is good only because you
> as the implementor know what purpose the tokens are used for.
> Instead of having to call them with a longer name, e.g. "state
> tokens", only because you know that these tokens represent tree-wide
> (as opposed to per-file) state, you can call them "tokens" in your
> implementation (and in your head) without confusing yourself.
>
> To the end users who should not care about the implementation
> detail, it is not a good name at all. The UI should surface the
> purpose, i.e. what these tokens are used for, (e.g. to represent
> tree-wide state) more than the fact that you happened to represent
> them with a single short word (i.e. "token").
>
> So --show-tree-state, --include-tree-state-in-the-output or
> something along that line that tells the user what the option is
> about is more preferable than --token. After all, you may want to
> use tokens to represent different kind of information in a later
> topic that is not about a tree-wide state, and you will regret that
> you used --token for this particular feature at that time.
I don't think I would regret it at all. I do not expect to conflate the
word "tokens" with the meaning "show-tree-state". It only has this
meaning because it is part 'git status'. If I want to show a different
kind of tokens in the future, I think "--tokens" would still work fine
there. It would even have precedent.
Consider the usage:
git status # show work-tree status
git status --short # show short work-tree status
git status --tokens # show work-tree status in token form
In the future if someone adds a similar operation to another command,I
do not think it would be confusing if it had a similar result.
git log --tokens
git show-ref --tokens HEAD
But maybe "--tokens" has some better meaning that someone will want to
use in the future. I'm not married to it. But "git status" already
means "Show the working tree status". So "git status --show-tree-state"
sounds redundant or meaningless.
'git status' already recognizes switches --ignored and --branch, for
example, to add extra state information to the output. I want to add
"tree-state tokens" to the list. But I don't know a better name for them.
Perhaps "--show-tree-state" is sufficient. Still sounds redundant to me.
Phil
^ permalink raw reply
* Re: push branch descriptions
From: Michael J Gruber @ 2012-11-14 13:52 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Angelo Borsotti, git
In-Reply-To: <CALkWK0meYVEe8OezEU2Oe-dQSZuo0ETwxXq3qWXzopH7x3msJA@mail.gmail.com>
Ramkumar Ramachandra venit, vidit, dixit 14.11.2012 11:33:
> Hi,
>
> Angelo Borsotti wrote:
>> currently, there is no means to push a branch description to a remote
>> repository. It is possible to create a branch, but not to set its
>> description.
>> Would not be more correct to push also branch descriptions when
>> branches are pushed?
>
> Branch descriptions are currently stored in .git/config (see
> branch.<branchname>.description), and are hence intended to be local.
> But yes, it would be nice to have it synced with the remote- I have no
> clue how to make that possible though.
I find that nice, too, but back then I seemed to be the only one, "then"
being the time when I proposed (and implemented) branch notes as notes
(git notes) being attached to the (sha1 of the) branch name (or any
other refname). They are versioned/shareable/syncable just like notes
are. I had all of this working (git branch --notes display, git
format-patch --cover-letter and such); what was missing was a way to
attach/look-up notes for remote branches, which is related to our
current lack of default handling of remote notes refs. That's not a
fundamental problem, just a matter of agreeing about a proper default
setup for remote notes refs.
As I said, others preferred local branch descriptions (no git notes) in
config, and that's what is in git.git now.
Michael
^ permalink raw reply
* Re: push branch descriptions
From: Junio C Hamano @ 2012-11-14 13:57 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: git
In-Reply-To: <CAB9Jk9ABenaj=R0a6OW2GCsin8PdDCW3ZbuQbu6G0jnGG3s+sA@mail.gmail.com>
Angelo Borsotti <angelo.borsotti@gmail.com> writes:
> currently, there is no means to push a branch description to a remote
> repository. It is possible to create a branch, but not to set its
> description.
Correct. You have to go to the remote repository and run "git
branch --edit-description" there; there is currently no way to do
this remotely, which may be an issue, but...
> Would not be more correct to push also branch descriptions when
> branches are pushed?
... I do not think "git push" is the best place to do so, given the
inherently local nature of branches and branch descriptions.
Imagine the project creates a branch "magic" to enhance its system
with magic words. The description for the "magic" branch in the
project may say "support magic words" or something.
You and your friend are tasked to add a handful of magic words,
e.g. "xyzzy", "frotz" and "nitfol". You may start your work like so
on your "magic-xyzzy" branch:
$ git clone git://example.com/zork.git/
$ git checkout -b magic-xyzzy -t origin/magic
And you say something like "add xyzzy magic" in its branch
description.
$ git branch --edit-description magic-xyzzy
After finishing your work, you may push it
$ git push origin magic-xyzzy:magic
Should the description of the subtask "add xyzzy magic" overwrite
the purpose of the project wide "magic" branch "support magic words"?
Most likely not.
The local nature of the description becomes even more clear if you
imagine the case where the push at the last stage gets rejected due
to non-fast-forward error (in other words, your friend has already
pushed her support of the "frotz" magic to the "magic" branch.
In fact, you would normally not directly push your magic-xyzzy
branch to the magic branch, but you would do something like this
once you are done:
$ git checkout -b magic -t origin/magic
$ git pull origin ;# to update with her work
$ git merge magic-xyzzy
$ git push origin magic
And the last "merge" is where the description for your magic-xyzzy
is used to fill the commit log template for you to explain your
merge (that is, you are merging a branch whose description is "add
xyzzy magic"). There is no reason to propagate the description of
your magic-xyzzy topic to the description of shared magic branch
when you push, as this merge commit already records what the branch
that was merged was about.
So you could modify "git push" to set the branch description when
you push to create a branch remotely, but in general, "git push"
should not be updating the branch description with the description
of your local branch. This comes as a consequence of the fact that
the purpose of the branch in the remote central repository is, more
often than not, different from the purpose of the corresponding
branch in your repository.
It would conceptually be a lot cleaner to treat updating of remote
branch description as a separate "repository management" class of
operation, similar to setting the repository description stored in
$GIT_DIR/description.
^ permalink raw reply
* Re: push branch descriptions
From: Angelo Borsotti @ 2012-11-14 14:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr4nwb832.fsf@alter.siamese.dyndns.org>
Hi Junio,
> It would conceptually be a lot cleaner to treat updating of remote
> Ibranch description as a separate "repository management" class of
> Ioperation, similar to setting the repository description stored in
> I$GIT_DIR/description.
I agree, it should be a distinct operation. I was thinking that when
you have a remote bare repository, the normal way of adding contents
to it is to push to it, and thus also adding a description should be
done with some sort of pushing. Creating branches is also normally
done with a push (think how difficult it is to create a branch in a
bare repository when the HEAD is not set ...).
-Angelo
On 14 November 2012 14:57, Junio C Hamano <gitster@pobox.com> wrote:
> Angelo Borsotti <angelo.borsotti@gmail.com> writes:
>
>> currently, there is no means to push a branch description to a remote
>> repository. It is possible to create a branch, but not to set its
>> description.
>
> Correct. You have to go to the remote repository and run "git
> branch --edit-description" there; there is currently no way to do
> this remotely, which may be an issue, but...
>
>> Would not be more correct to push also branch descriptions when
>> branches are pushed?
>
> ... I do not think "git push" is the best place to do so, given the
> inherently local nature of branches and branch descriptions.
>
> Imagine the project creates a branch "magic" to enhance its system
> with magic words. The description for the "magic" branch in the
> project may say "support magic words" or something.
>
> You and your friend are tasked to add a handful of magic words,
> e.g. "xyzzy", "frotz" and "nitfol". You may start your work like so
> on your "magic-xyzzy" branch:
>
> $ git clone git://example.com/zork.git/
> $ git checkout -b magic-xyzzy -t origin/magic
>
> And you say something like "add xyzzy magic" in its branch
> description.
>
> $ git branch --edit-description magic-xyzzy
>
> After finishing your work, you may push it
>
> $ git push origin magic-xyzzy:magic
>
> Should the description of the subtask "add xyzzy magic" overwrite
> the purpose of the project wide "magic" branch "support magic words"?
> Most likely not.
>
> The local nature of the description becomes even more clear if you
> imagine the case where the push at the last stage gets rejected due
> to non-fast-forward error (in other words, your friend has already
> pushed her support of the "frotz" magic to the "magic" branch.
>
> In fact, you would normally not directly push your magic-xyzzy
> branch to the magic branch, but you would do something like this
> once you are done:
>
> $ git checkout -b magic -t origin/magic
> $ git pull origin ;# to update with her work
> $ git merge magic-xyzzy
> $ git push origin magic
>
> And the last "merge" is where the description for your magic-xyzzy
> is used to fill the commit log template for you to explain your
> merge (that is, you are merging a branch whose description is "add
> xyzzy magic"). There is no reason to propagate the description of
> your magic-xyzzy topic to the description of shared magic branch
> when you push, as this merge commit already records what the branch
> that was merged was about.
>
> So you could modify "git push" to set the branch description when
> you push to create a branch remotely, but in general, "git push"
> should not be updating the branch description with the description
> of your local branch. This comes as a consequence of the fact that
> the purpose of the branch in the remote central repository is, more
> often than not, different from the purpose of the corresponding
> branch in your repository.
>
> It would conceptually be a lot cleaner to treat updating of remote
> branch description as a separate "repository management" class of
> operation, similar to setting the repository description stored in
> $GIT_DIR/description.
^ permalink raw reply
* Re: [PATCH v3 0/5] push: update remote tags only with force
From: Angelo Borsotti @ 2012-11-14 14:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: Chris Rorvick, git, Drew Northup, Michael Haggerty, Philip Oakley,
Johannes Sixt, Kacper Kornet, Jeff King, Felipe Contreras
In-Reply-To: <7v390ccoak.fsf@alter.siamese.dyndns.org>
Hi Junio,
actually, I proposed to add a key in config files, e.g.
pushTagsNoChange to be set in the remote repo do disallow changes to
tags, similar to pushNonFastForward that disallows non-fastforward
changes to branches. I still have the impression that this is simple
and clear, and allows the owner of the remote repository to enforce
the policy s/he wants on her/his repository.
-Angelo
On 14 November 2012 14:22, Junio C Hamano <gitster@pobox.com> wrote:
> Chris Rorvick <chris@rorvick.com> writes:
>
>>> "Do not update, only add new" may be a good feature, but at the same
>>> time I have this suspicion that its usefulness may not necessarily
>>> be limited to refs/tags/* hierarchy.
>>>
>>> I dunno.
>>
>> Are you suggesting allowing forwards for just refs/heads/*?
>
> No, it is a nonsense to unconditionally forbid fast-forwards to refs
> outside refs/heads/ hierarchy.
>
> I was imagining a more general feature to allow the *user* to ask
> Git not to fast-forward some refs (not limited to refs/tags/) during
> a push.
>
> If such a general feature were in place, you can think of your patch
> as automatically making the user to ask Git not to fast-forward refs
> in refs/tags/, which would be a mere special case of it.
>
> And I was wondering if such a general feature makes sense.
>
>
>
>
^ permalink raw reply
* Re: [regression] Newer gits cannot clone any remote repos
From: Douglas Mencken @ 2012-11-14 16:19 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Torsten Bögershausen, Ramsay Jones, git
In-Reply-To: <m2pq3h9ll1.fsf@igel.home>
> I cannot reproduce the problem (on openSUSE 12.2).
You do need multiple CPU/multi-core machine, as I got it.
^ permalink raw reply
* Re: [regression] Newer gits cannot clone any remote repos
From: Andreas Schwab @ 2012-11-14 16:32 UTC (permalink / raw)
To: Douglas Mencken; +Cc: Torsten Bögershausen, Ramsay Jones, git
In-Reply-To: <CACYvZ7jwjVsW4=QSbxFVL8N269DE4=tv8_WvZ0gVOw6B+WLP=w@mail.gmail.com>
Douglas Mencken <dougmencken@gmail.com> writes:
>> I cannot reproduce the problem (on openSUSE 12.2).
>
> You do need multiple CPU/multi-core machine, as I got it.
Which is what I have.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 1/6] ident: make user_ident_explicitly_given private
From: Jonathan Nieder @ 2012-11-14 16:44 UTC (permalink / raw)
To: Jeff King
Cc: Felipe Contreras, git, Thomas Rast, Junio C Hamano,
Santi Béjar
In-Reply-To: <20121113164931.GA12626@sigill.intra.peff.net>
Jeff King wrote:
> There are no users of this global variable, as queriers
> go through the user_ident_sufficiently_given accessor.
> Let's make it private, which will enable further
> refactoring.
[...]
> --- a/cache.h
> +++ b/cache.h
> @@ -1149,10 +1149,6 @@ struct config_include_data {
> #define CONFIG_INCLUDE_INIT { 0 }
> extern int git_config_include(const char *name, const char *value, void *data);
>
> -#define IDENT_NAME_GIVEN 01
> -#define IDENT_MAIL_GIVEN 02
> -#define IDENT_ALL_GIVEN (IDENT_NAME_GIVEN|IDENT_MAIL_GIVEN)
> -extern int user_ident_explicitly_given;
> extern int user_ident_sufficiently_given(void);
In v1.5.6-rc0~56^2 (2008-05-04) "user_ident_explicitly_given" was
introduced as a global for communication between config, ident, and
builtin-commit. In v1.7.0-rc0~72^2 (2010-01-07) readers switched to
using the common wrapper user_ident_sufficiently_given(). After
v1.7.11-rc1~15^2~18 (2012-05-21) the var is only written in ident.c,
and the variable can finally be made static.
This patch finally does that, which is a nice way to make cache.h
easier to read and change less often.
For what it's worth,
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
^ permalink raw reply
* Re: [PATCH 3/6] var: accept multiple variables on the command line
From: Jonathan Nieder @ 2012-11-14 17:01 UTC (permalink / raw)
To: Jeff King; +Cc: Felipe Contreras, git, Thomas Rast, Junio C Hamano
In-Reply-To: <20121113165247.GC12626@sigill.intra.peff.net>
Jeff King wrote:
> This patch lets callers specify multiple variables, and
> prints one per line.
Yay!
[...]
> --- a/Documentation/git-var.txt
> +++ b/Documentation/git-var.txt
> @@ -9,11 +9,16 @@ git-var - Show a git logical variable
> SYNOPSIS
> --------
> [verse]
> -'git var' ( -l | <variable> )
> +'git var' ( -l | <variable>... )
>
> DESCRIPTION
> -----------
> -Prints a git logical variable.
> +Prints one or more git logical variables, separated by newlines.
> +
> +Note that some variables may contain newlines themselves
Maybe a -z option to NUL-terminate values would be useful some day.
> --- a/builtin/var.c
> +++ b/builtin/var.c
> @@ -73,8 +73,7 @@ static int show_config(const char *var, const char *value, void *cb)
>
> int cmd_var(int argc, const char **argv, const char *prefix)
> {
> - const char *val = NULL;
> - if (argc != 2)
> + if (argc < 2)
> usage(var_usage);
>
> if (strcmp(argv[1], "-l") == 0) {
What should happen if I pass "-l" followed by other arguments?
[...]
> --- /dev/null
> +++ b/t/t0007-git-var.sh
> @@ -0,0 +1,29 @@
> +#!/bin/sh
> +
> +test_description='basic sanity checks for git var'
> +. ./test-lib.sh
> +
> +test_expect_success 'get GIT_AUTHOR_IDENT' '
> + test_tick &&
> + echo "A U Thor <author@example.com> 1112911993 -0700" >expect &&
Do we need to hardcode the timestamp? Something like
test_cmp_filtered () {
expect=$1 actual=$2 &&
sed -e 's/[0-9][0-9]* [-+][0-9][0-9][0-9][0-9]/TIMESTAMP" \
<"$actual" >"$actual.filtered" &&
test_cmp "$expect" "$actual.filtered"
}
...
echo "A U Thor <author@example.com> $timestamp" >expect &&
git var GIT_AUTHOR_IDENT >actual &&
test_cmp_filtered expect actual
should make reordering tests a lot easier, though it has the downside
of not being able to catch a weird bug that would make the timestamp
out of sync with reality.
Hope that helps,
Jonathan
^ permalink raw reply
* Re: [PATCH 4/6] var: provide explicit/implicit ident information
From: Jonathan Nieder @ 2012-11-14 17:06 UTC (permalink / raw)
To: Jeff King; +Cc: Felipe Contreras, git, Thomas Rast, Junio C Hamano
In-Reply-To: <20121113165308.GD12626@sigill.intra.peff.net>
Jeff King wrote:
> Internally, we keep track of whether the author or committer
> ident information was provided by the user, or whether it
> was implicitly determined by the system. However, there is
> currently no way for external programs or scripts to get
> this information
What are the intended semantics? If my machine has /etc/mailname
filled out, is that an implicit identity? How about if I set the
EMAIL envvar but not GIT_COMMITTER_EMAIL?
If external scripts are going to start using this mechanism, they will
need answers to these questions to support users that run into
configuration problems. A few words on this in the documentation
could probably help.
On most machines I have the EMAIL envvar set explicitly, but in the
recent past I relied on /etc/mailname on some others, so I'm also
genuinely curious about the use case here (and too lazy to dig it up).
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH 5/6] Git.pm: teach "ident" to query explicitness
From: Jonathan Nieder @ 2012-11-14 17:12 UTC (permalink / raw)
To: Jeff King; +Cc: Felipe Contreras, git, Thomas Rast, Junio C Hamano
In-Reply-To: <20121113165320.GE12626@sigill.intra.peff.net>
Jeff King wrote:
> "git var" recently learned to report on whether an ident we
> fetch from it was configured explicitly or implicitly. Let's
> make that information available to callers of the ident
> function.
Sounds sensible. Quick nits:
[...]
> --- a/perl/Git.pm
> +++ b/perl/Git.pm
> @@ -737,7 +737,7 @@ sub remote_refs {
> }
>
>
> -=item ident ( TYPE | IDENTSTR )
> +=item ident ( TYPE | IDENTSTR [, options] )
>
> =item ident_person ( TYPE | IDENTSTR | IDENTARRAY )
>
> @@ -750,6 +750,10 @@ and either returns it as a scalar string or as an array with the fields parsed.
> Alternatively, it can take a prepared ident string (e.g. from the commit
> object) and just parse it.
>
> +If the C<explicit> option is set to 1, the returned array will contain an
> +additional boolean specifying whether the ident was configure explicitly by the
> +user.
s/configure/configured/
I'd suggest adding "See GIT_COMMITTER_EXPLICIT in git-var(1) for
details" to make the semantics crystal clear. What do you think?
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH 6/6] send-email: do not prompt for explicit repo ident
From: Jonathan Nieder @ 2012-11-14 17:18 UTC (permalink / raw)
To: Jeff King; +Cc: Felipe Contreras, git, Thomas Rast, Junio C Hamano
In-Reply-To: <20121113165327.GF12626@sigill.intra.peff.net>
Jeff King wrote:
> If git-send-email is configured with sendemail.from, we will
> not prompt the user for the "From" address of the emails.
> If it is not configured, we prompt the user, but provide the
> repo author or committer as a default. Even though we
> probably have a sensible value for the default, the prompt
> is a safety check in case git generated an incorrect
> implicit ident string.
I haven't read the code carefully, but this behavior sounds sensible,
so for what it's worth,
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
[...]
> The test scripts need to be adjusted to not expect a prompt
> for the sender, since they always have the author explicitly
> defined in the environment. Unfortunately, we cannot
> reliably test that prompting still happens in the implicit
> case, as send-email will produce inconsistent results
> depending on the machine config (if we cannot find a FQDN,
> "git var" will barf, causing us to exit early;
At first this sounded like a bug to me --- how could the user keep
working without the sysadmin intervening?
But then I remembered that the user can set her name and email in
.gitconfig and probably would want to in such a setup anyway.
When someone writes such a test, I think it could check that git
either prompts or writes a message advising to configure the user
email, no? Waiting until later for that seems fine to me, though.
Thanks,
Jonathan
^ permalink raw reply
* RE: push branch descriptions
From: Pyeron, Jason J CTR (US) @ 2012-11-14 17:21 UTC (permalink / raw)
To: git
In-Reply-To: <CAB9Jk9BN6vTnpPa8rv1Yumn2Os=XU=tEn3=j2QJJK1GpajY=VQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4409 bytes --]
> -----Original Message-----
> From: Angelo Borsotti
> Sent: Wednesday, November 14, 2012 9:51 AM
>
> Hi Junio,
>
> > It would conceptually be a lot cleaner to treat updating of remote
> > Ibranch description as a separate "repository management" class of
> > Ioperation, similar to setting the repository description stored in
> > I$GIT_DIR/description.
>
> I agree, it should be a distinct operation. I was thinking that when
> you have a remote bare repository, the normal way of adding contents
> to it is to push to it, and thus also adding a description should be
> done with some sort of pushing. Creating branches is also normally
> done with a push (think how difficult it is to create a branch in a
> bare repository when the HEAD is not set ...).
Only if the push were to create the branch...
> On 14 November 2012 14:57, Junio C Hamano <gitster@pobox.com> wrote:
> > Angelo Borsotti <angelo.borsotti@gmail.com> writes:
> >
> >> currently, there is no means to push a branch description to a
> remote
> >> repository. It is possible to create a branch, but not to set its
> >> description.
> >
> > Correct. You have to go to the remote repository and run "git
> > branch --edit-description" there; there is currently no way to do
> > this remotely, which may be an issue, but...
> >
> >> Would not be more correct to push also branch descriptions when
> >> branches are pushed?
> >
> > ... I do not think "git push" is the best place to do so, given the
> > inherently local nature of branches and branch descriptions.
> >
> > Imagine the project creates a branch "magic" to enhance its system
> > with magic words. The description for the "magic" branch in the
> > project may say "support magic words" or something.
> >
> > You and your friend are tasked to add a handful of magic words,
> > e.g. "xyzzy", "frotz" and "nitfol". You may start your work like so
> > on your "magic-xyzzy" branch:
> >
> > $ git clone git://example.com/zork.git/
> > $ git checkout -b magic-xyzzy -t origin/magic
And here the branch description should copy from origin/magic.
> >
> > And you say something like "add xyzzy magic" in its branch
> > description.
> >
> > $ git branch --edit-description magic-xyzzy
> >
And now it is edited
> > After finishing your work, you may push it
> >
> > $ git push origin magic-xyzzy:magic
> >
> > Should the description of the subtask "add xyzzy magic" overwrite
> > the purpose of the project wide "magic" branch "support magic words"?
> > Most likely not.
Never overwrite anything.
> >
> > The local nature of the description becomes even more clear if you
> > imagine the case where the push at the last stage gets rejected due
> > to non-fast-forward error (in other words, your friend has already
> > pushed her support of the "frotz" magic to the "magic" branch.
> >
> > In fact, you would normally not directly push your magic-xyzzy
> > branch to the magic branch, but you would do something like this
> > once you are done:
> >
> > $ git checkout -b magic -t origin/magic
> > $ git pull origin ;# to update with her work
> > $ git merge magic-xyzzy
> > $ git push origin magic
> >
> > And the last "merge" is where the description for your magic-xyzzy
> > is used to fill the commit log template for you to explain your
> > merge (that is, you are merging a branch whose description is "add
> > xyzzy magic"). There is no reason to propagate the description of
> > your magic-xyzzy topic to the description of shared magic branch
> > when you push, as this merge commit already records what the branch
> > that was merged was about.
> >
> > So you could modify "git push" to set the branch description when
> > you push to create a branch remotely, but in general, "git push"
> > should not be updating the branch description with the description
> > of your local branch. This comes as a consequence of the fact that
> > the purpose of the branch in the remote central repository is, more
> > often than not, different from the purpose of the corresponding
> > branch in your repository.
> >
But pulling such into a new branch should copy the description (unless explicitly set)
> > It would conceptually be a lot cleaner to treat updating of remote
> > branch description as a separate "repository management" class of
> > operation, similar to setting the repository description stored in
> > $GIT_DIR/description.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/5] push: update remote tags only with force
From: Junio C Hamano @ 2012-11-14 17:32 UTC (permalink / raw)
To: Angelo Borsotti
Cc: Chris Rorvick, git, Drew Northup, Michael Haggerty, Philip Oakley,
Johannes Sixt, Kacper Kornet, Jeff King, Felipe Contreras
In-Reply-To: <CAB9Jk9DAwaLw2bTqj5x_zxRcFqn7s=nmGi=Jc_SD38vFoszBZg@mail.gmail.com>
Angelo Borsotti <angelo.borsotti@gmail.com> writes:
> actually, I proposed to add a key in config files, e.g.
> pushTagsNoChange to be set in the remote repo do disallow changes to
> tags, similar to pushNonFastForward that disallows non-fastforward
> changes to branches. I still have the impression that this is simple
> and clear, and allows the owner of the remote repository to enforce
> the policy s/he wants on her/his repository.
That is an independent issue of deciding to accept or reject
receiving a push from outside, no? You can implement any such
policy in the pre-receive hook on the receiving end with a simple
and clear manner, instead of adding specific logic to enforce a
single hardcoded policy to the code that is flipped on with a
configuration variable.
In any case, I thought this series was about users who run "push"
voluntarily stopping themselves from pushing updates to tags that
may happen to fast-forward, so if we were to go with the
configuration route, the suggestion would be more like
[push]
updateNeedsForce = refs/tags/:refs/frotz/
or perhaps
[remote "origin"]
updateNeedsForce = refs/tags/:refs/frotz/
if we want to configure it per-remote, to specify that you would
need to say "--force" to update the refs in the listed hierarchies.
Then your patch series could become just the matter of declaring
that the value of push.updateNeedsForce, when unspecified, defaults
to "refs/tags/".
^ permalink raw reply
* Re: [PATCHv3 3/4] git-status: show short sequencer state
From: Junio C Hamano @ 2012-11-14 17:44 UTC (permalink / raw)
To: Phil Hord
Cc: git, phil.hord, Jeff King, konglu, Matthieu Moy, Kong Lucien,
Duperray Valentin, Jonas Franck, Nguy Thomas
In-Reply-To: <50A3A040.7040304@cisco.com>
Phil Hord <hordp@cisco.com> writes:
> Consider the usage:
>
> git status # show work-tree status
> git status --short # show short work-tree status
> git status --tokens # show work-tree status in token form
OK, your --tokens is more about *how* things are output, but it is
unclear how it would interact with --short. I had an impression
that you are basing your output on the short output, whose existing
record include "##" (that shows the branch names and states), and
"MM", "A " and friends (that show the per-file states), by adding
new record types that shows tree-wide states.
> But maybe "--tokens" has some better meaning that someone will want to
> use in the future. I'm not married to it. But "git status" already
> means "Show the working tree status". So "git status --show-tree-state"
> sounds redundant or meaningless.
I didn't mean to say that you have to spell out all these words;
"show" and "state" are redundant.
The important part is that unlike the existing "per-file" state the
"status" command is showing, the option is to add "tree-wide" state
to the output, and my suggestion was to pick a word that makes it
clear, rather than using "output is done using tokens" without
saying "what is being output in tokenized form".
^ permalink raw reply
* Re: push branch descriptions
From: Junio C Hamano @ 2012-11-14 17:58 UTC (permalink / raw)
To: Pyeron, Jason J CTR (US); +Cc: git
In-Reply-To: <871B6C10EBEFE342A772D1159D13208537AABCCA@umechphj.easf.csd.disa.mil>
"Pyeron, Jason J CTR (US)" <jason.j.pyeron.ctr@mail.mil> writes:
>> > Imagine the project creates a branch "magic" to enhance its system
>> > with magic words. The description for the "magic" branch in the
>> > project may say "support magic words" or something.
>> >
>> > You and your friend are tasked to add a handful of magic words,
>> > e.g. "xyzzy", "frotz" and "nitfol". You may start your work like so
>> > on your "magic-xyzzy" branch:
>> >
>> > $ git clone git://example.com/zork.git/
>> > $ git checkout -b magic-xyzzy -t origin/magic
>
> And here the branch description should copy from origin/magic.
I doubt it should. The purpose of the "magic" branch at the remote
in my example were to "support magic words" (without limiting which
magic words the project wants to support) and that is what the
description over there may say, while the purpose of the local
"magic-xyzzy" branch you create in order to add the support for
"xyzzy" magic is just one small subtask of it.
That is what I meant by "the inherently local nature of the branches
and branch descriptions". Git as a distributed system works well
exactly because what each repository has is inherently local, and
people can do whatever they want in their own repositories, while
allowing collaboration among participants by pulling and pushing
histories that share compatible (note: not necessarily "identical")
goals. "support magic words" being a superset of "add xyzzy magic"
is an example of this principle. They have different goals (and
that is why propagating the description of your "magic-xyzzy" to the
project global "magic" is a wrong thing to do), but from the point
of view of the project global "magic" branch, what your "magic-xyzzy"
branch wanted to do is compatible with its larger goal (and that is
why merging to "magic" from "magic-xyzzy" is a good thing, while
merging the other way is frowned upon in general).
^ permalink raw reply
* Re: [regression] Newer gits cannot clone any remote repos
From: Douglas Mencken @ 2012-11-14 18:01 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Torsten Bögershausen, Ramsay Jones, git
In-Reply-To: <mvmvcd8f8ml.fsf@g208.suse.de>
>>> I cannot reproduce the problem (on openSUSE 12.2).
>>
>> You do need multiple CPU/multi-core machine, as I got it.
>
> Which is what I have.
Then try to build *vanilla* git 1.8.0, not OpenSuSE's one (with a lot
of patches inside srcrpm).
^ permalink raw reply
* v1.8.0-150-gb0b00a3: Weird documentation for git-rm
From: Horst H. von Brand @ 2012-11-14 18:15 UTC (permalink / raw)
To: git; +Cc: gitster, Horst H. von Brand
The file Documentation/git-rm.txt says:
---8><---- 8><-------
Using ``git add -A''
~~~~~~~~~~~~~~~~~~~~
When accepting a new code drop for a vendor branch, you probably
want to record both the removal of paths and additions of new paths
as well as modifications of existing paths.
Typically you would first remove all tracked files from the working
tree using this command:
Submodules
~~~~~~~~~~
---8><---- 8><-------
I believe a command is missing here.
The explanation also leaves me scratching my head...
(In Fedora's git-1.7.7.6-1.fc16.x86_64 there is a command and some further
explanation).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
^ permalink raw reply
* [PATCH] docs: move submodule section
From: Matt Kraai @ 2012-11-14 18:49 UTC (permalink / raw)
To: git, gitster, Horst H. von Brand; +Cc: Matt Kraai
In-Reply-To: <201211141815.qAEIFTBi017644@netbook1.inf.utfsm.cl>
293ab15e ("submodule: teach rm to remove submodules unless they
contain a git directory", 2012-09-26) inserted the "Submodules"
section between a sentence describing a command and the command. Move
the "Submodules" section further down.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
Documentation/git-rm.txt | 30 +++++++++++++++---------------
1 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index 882cb11..262436b 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -107,21 +107,6 @@ as well as modifications of existing paths.
Typically you would first remove all tracked files from the working
tree using this command:
-Submodules
-~~~~~~~~~~
-Only submodules using a gitfile (which means they were cloned
-with a git version 1.7.8 or newer) will be removed from the work
-tree, as their repository lives inside the .git directory of the
-superproject. If a submodule (or one of those nested inside it)
-still uses a .git directory, `git rm` will fail - no matter if forced
-or not - to protect the submodule's history.
-
-A submodule is considered up-to-date when the HEAD is the same as
-recorded in the index, no tracked files are modified and no untracked
-files that aren't ignored are present in the submodules work tree.
-Ignored files are deemed expendable and won't stop a submodule's work
-tree from being removed.
-
----------------
git ls-files -z | xargs -0 rm -f
----------------
@@ -149,6 +134,21 @@ use the following command:
git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached
----------------
+Submodules
+~~~~~~~~~~
+Only submodules using a gitfile (which means they were cloned
+with a git version 1.7.8 or newer) will be removed from the work
+tree, as their repository lives inside the .git directory of the
+superproject. If a submodule (or one of those nested inside it)
+still uses a .git directory, `git rm` will fail - no matter if forced
+or not - to protect the submodule's history.
+
+A submodule is considered up-to-date when the HEAD is the same as
+recorded in the index, no tracked files are modified and no untracked
+files that aren't ignored are present in the submodules work tree.
+Ignored files are deemed expendable and won't stop a submodule's work
+tree from being removed.
+
EXAMPLES
--------
`git rm Documentation/\*.txt`::
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH] docs: move submodule section
From: Matt Kraai @ 2012-11-14 18:50 UTC (permalink / raw)
To: git, gitster, Horst H. von Brand
In-Reply-To: <1352918944-26606-1-git-send-email-kraai@ftbfs.org>
On Wed, Nov 14, 2012 at 10:49:04AM -0800, Matt Kraai wrote:
> 293ab15e ("submodule: teach rm to remove submodules unless they
> contain a git directory", 2012-09-26) inserted the "Submodules"
> section between a sentence describing a command and the command. Move
> the "Submodules" section further down.
>
> Signed-off-by: Matt Kraai <kraai@ftbfs.org>
Sorry, I amended the patch to include a Reported-by line but forgot to
reformat it before sending. It should have included:
Reported-by: "Horst H. von Brand" <vonbrand@inf.utfsm.cl>
--
Matt Kraai
https://ftbfs.org/kraai
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
From: Jeff King @ 2012-11-14 19:02 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Torsten Bögershausen, git
In-Reply-To: <50A2F17D.4010907@gmail.com>
On Tue, Nov 13, 2012 at 08:18:53PM -0500, Mark Levedahl wrote:
> On 11/13/2012 03:45 PM, Torsten Bögershausen wrote:
> >>* ml/cygwin-mingw-headers (2012-11-12) 1 commit
> >> - Update cygwin.c for new mingw-64 win32 api headers
> >>
> >> Make git work on newer cygwin.
> >>
> >> Will merge to 'next'.
> >(Sorry for late answer, I managed to test the original patch minutes before Peff merged it to pu)
> >(And thanks for maintaining git)
> >
> >Is everybody using cygwin happy with this?
> >
> >I managed to compile on a fresh installed cygwin,
> >but failed to compile under 1.7.7, see below.
> >Is there a way we can achieve to compile git both under "old" and "new" cygwin 1.7 ?
> >Or is this not worth the effort?
> >
> I found no version info defined that could be used to automatically
> switch between the old and current headers. You can always
>
> make V15_MINGW_HEADERS=1 ...
>
> to force using the old set if you do not wish to update your installation.
Should we keep the code change, then, but not flip the default (i.e.,
make people on the newer version opt into it)? I am not clear on how
common the newer include system is. Of course, auto-detecting would be
the ideal.
-Peff
^ 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