* 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: [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 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 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 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: [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: [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: [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: 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: 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: 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: [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: [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: 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: [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: 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: creation of empty branches
From: Andrew Ardill @ 2012-11-14 12:54 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: git
In-Reply-To: <CAB9Jk9CaBECT7c_M9HvCbB8mFYGvdsmq_jFW4DF4NCO8Narnmw@mail.gmail.com>
On 14 November 2012 21:10, Angelo Borsotti <angelo.borsotti@gmail.com> wrote:
> ... why should git
> branch master issue an error while git checkout does not? I have the
> impression that also git branch should not issue an error in this
> case.
>
Just to help a little, let's first define:
- An empty file in refs/heads is a broken head.
- A non-existent file in refs/heads is an empty branch. Most
references to empty branches are probably mistakes.
- If HEAD points to an empty branch it is in 'root commit' or 'orphan'
mode. A commit made in such a mode first creates the root or orphan
commit object, and then creates the branch head in refs/heads pointing
to that object.
As I understand it, git branch and git checkout without a start point
defined are both intended to create a new branch and point it to the
current HEAD. Checkout will additionally reset HEAD to point to the
new branch, rather than whatever it was pointing to before (which will
normally be either a direct or indirect reference to a commit object).
The problem is that the behaviour when HEAD points to empty branch is
undefined, and this situation is seen to occur when there are no
commit objects at all, in an empty repository. This will also happen
when a branch has been checked out in orphan mode.
Since git branch has the default behaviour to create a branch 'in the
background' it makes sense to fail when trying to create a new branch
this way from an empty branch. The error message should be improved to
handle this edge case in a nicer way. If we allow for renaming empty
branches (described below) then the message can be even more helpful.
Instead of
fatal: Not a valid object name: 'master'.
perhaps
fatal: Cannot create branch 'foo' from empty branch 'master'. To
rename 'master' use 'git branch -m master foo'.
git checkout -b changes the current branch, and so it does make sense
to allow renaming an empty branch, which is the current behaviour.
However, note that currently when HEAD points to an empty branch, 'git
checkout -b foo HEAD' fails because HEAD is an invalid reference.
Obviously some special logic has been added or a very odd bug has
appeared. Perhaps it is most useful to continue to error out on any
reference explicitly listed on the command line as the start point
that points to an empty branch, unless it is pointed to by HEAD. Thus
we would only make HEAD point to a new empty branch when the start
point is omitted or when it matches the current empty branch HEAD
points to.
It would be useful to extend this renaming of empty branches to the
branch commands, and 'git branch -m' is a perfect fit for this from a
user perspective.
So explicitly, I am proposing the following behaviour changes:
When trying to create a new branch without specifying a start point,
if HEAD points to an empty branch, error with a more useful message
that assumes the user might want to rename the empty branch.
When trying to create a new branch whilst specifying an empty branch
as the start point,
if HEAD points to the same empty branch that is listed as the start
point, error with a more useful message that assumes the user might
want to rename the empty branch.
otherwise error due to invalid ref
When checking out a new branch without specifying a start point,
if HEAD points to an empty branch then HEAD should be pointed to the
new branch, which will also be empty.
When checking out a new branch whilst specifying an empty branch as
the start point,
if HEAD points to the same empty branch that is listed as the start
point, HEAD should be pointed to the new, empty branch
otherwise error due to invalid ref
When moving to a new branch without specifying an old branch,
if HEAD points to an empty branch then HEAD should be pointed to the
new branch, which will also be empty.
When moving to a new branch whilst specifying an empty branch as the old branch,
if HEAD points to the same empty branch that is listed as the old
branch, HEAD should be pointed to the new, empty branch
otherwise error due to invalid ref
Note that since HEAD points to an empty branch there should be no
conflicts with the working directory or the index, so leave them
unchanged.
Some examples that might help:
~$ git init test
~$ cd test
~/test (master)$ git branch foo
fatal: Cannot create branch 'foo' from empty branch 'master'. To
rename 'master' use 'git branch -m master foo'.
~/test (master)$ git checkout -b foo
~/test (foo)$ git checkout -b bar fo
fatal: Not a valid object name: 'fo'.
~/test (foo)$ git checkout -b bar foo
~/test (bar)$ git branch -m foo
~/test (foo)$ git branch -m fo bar
error: refname refs/heads/fo not found
fatal: Branch rename failed
~/test (foo)$ git branch -m foo bar
~/test (bar)$
I wouldn't mind trying to code this up at the moment, but as I don't
have heaps of time if someone else feels like it go ahead (assuming
it's a good suggestion of course!).
Regards,
Andrew Ardill
^ permalink raw reply
* RE: Unable to compile Git on HP-UX B.11.31 U ia64
From: Quintin Ronan @ 2012-11-14 11:31 UTC (permalink / raw)
To: Stefano Lattarini; +Cc: git@vger.kernel.org
In-Reply-To: <50A37FAD.1030901@gmail.com>
Hello Stefano,
Thank you for your quick answer. You are right, HP-UX have a gmake executable :
#gmake --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for ia64-hp-hpux11.31
I will try to use this instead of make
Cordialement,
Ronan QUINTIN
TMA EAI - Division Telecom & Media
Sopra group.
Centre Espace Performance - Batiment S
35769 St Grégoire
Phone : +33 (0)2 23 25 34 71
ronan.quintin@sopragroup.com - www.sopragroup.com
Ce message peut contenir des informations confidentielles dont la divulgation est à ce titre rigoureusement interdite en l'absence d'autorisation explicite de l'émetteur. Dans l'hypothèse où vous auriez reçu par erreur ce message, merci de le renvoyer à l’émetteur et de détruire toute copie.
Pensez à l’environnement avant d’imprimer.
-----Message d'origine-----
De : Stefano Lattarini [mailto:stefano.lattarini@gmail.com]
Envoyé : mercredi 14 novembre 2012 12:26
À : Quintin Ronan
Cc : git@vger.kernel.org
Objet : Re: Unable to compile Git on HP-UX B.11.31 U ia64
On 11/14/2012 12:18 PM, Quintin Ronan wrote:
> Hello,
>
> I’m trying to compile git 1.7 on a HPUX server using make.
> The ./configure worked well :
>
> [SNIP]
>
> But when i run make (with –d) it simply doesn’t work with a message
> which isn’t really helpfull :
>
> [SNIP]
> Make: line 313: syntax error. Stop.
>
> Can you help me ?
>
The Git build system requires GNU make, but it seems to me you are using
your system native make instead. That won't work. It might be the case
GNU make is installed on your system, but is named something like 'gmake'
or 'gnumake' rather than just 'make'. What happens if you run the
following?
$ gmake --version
$ gnumake --version
If GNU make is not installed on your system, you can download the latest
version from here:
<http://ftp.gnu.org/gnu/make/make-3.82.tar.gz>
For more information about GNU make:
<http://www.gnu.org/software/make/>
HTH,
Stefano
^ permalink raw reply
* Re: Unable to compile Git on HP-UX B.11.31 U ia64
From: Stefano Lattarini @ 2012-11-14 11:25 UTC (permalink / raw)
To: Quintin Ronan; +Cc: git@vger.kernel.org
In-Reply-To: <30295_1352891883_50A37DEB_30295_18278_1_67156E3FC2DDE6479DE35C159B9C2B582C59CEE6@wptxexmbx03.ptx.fr.sopra>
On 11/14/2012 12:18 PM, Quintin Ronan wrote:
> Hello,
>
> I’m trying to compile git 1.7 on a HPUX server using make.
> The ./configure worked well :
>
> [SNIP]
>
> But when i run make (with –d) it simply doesn’t work with a message
> which isn’t really helpfull :
>
> [SNIP]
> Make: line 313: syntax error. Stop.
>
> Can you help me ?
>
The Git build system requires GNU make, but it seems to me you are using
your system native make instead. That won't work. It might be the case
GNU make is installed on your system, but is named something like 'gmake'
or 'gnumake' rather than just 'make'. What happens if you run the
following?
$ gmake --version
$ gnumake --version
If GNU make is not installed on your system, you can download the latest
version from here:
<http://ftp.gnu.org/gnu/make/make-3.82.tar.gz>
For more information about GNU make:
<http://www.gnu.org/software/make/>
HTH,
Stefano
^ permalink raw reply
* Unable to compile Git on HP-UX B.11.31 U ia64
From: Quintin Ronan @ 2012-11-14 11:18 UTC (permalink / raw)
To: git@vger.kernel.org
Hello,
I’m trying to compile git 1.7 on a HPUX server using make. The ./configure worked well :
configure: Setting lib to 'lib' (the default)
configure: Will try -pthread then -lpthread to enable POSIX Threads.
configure: CHECKS for site configuration
configure: CHECKS for programs
checking for cc... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... no
checking whether cc accepts -g... no
checking for cc option to accept ISO C89... none needed
checking for inline... __inline
checking if linker supports -R... no
checking if linker supports -Wl,-rpath,... no
checking if linker supports -rpath... no
configure: WARNING: linker does not support runtime path to dynamic libraries
checking for gar... no
checking for ar... ar
checking for gtar... no
checking for tar... tar
checking for gnudiff... no
checking for gdiff... no
checking for diff... diff
checking for asciidoc... no
configure: CHECKS for libraries
checking for SHA1_Init in -lcrypto... yes
checking for curl_global_init in -lcurl... no
checking for XML_ParserCreate in -lexpat... no
checking for iconv in -lc... yes
checking for deflateBound in -lz... no
checking for socket in -lc... yes
checking for inet_ntop... yes
checking for inet_pton... yes
checking for hstrerror... no
checking for hstrerror in -lresolv... no
checking for basename in -lc... yes
checking for gettext in -lc... no
checking how to run the C preprocessor... cc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking libintl.h usability... no
checking libintl.h presence... no
checking for libintl.h... no
configure: CHECKS for header files
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking sys/poll.h usability... yes
checking sys/poll.h presence... yes
checking for sys/poll.h... yes
checking for inttypes.h... (cached) yes
checking for old iconv()... no
configure: CHECKS for typedefs, structures, and compiler characteristics
checking for socklen_t... yes
checking for struct dirent.d_ino... yes
checking for struct dirent.d_type... no
checking for struct sockaddr_storage... yes
checking for struct addrinfo... yes
checking for getaddrinfo... yes
checking for library containing getaddrinfo... none required
checking whether the platform regex can handle null bytes... no
checking whether system succeeds to read fopen'ed directory... yes
checking whether snprintf() and/or vsnprintf() return bogus value... yes
configure: CHECKS for library functions
checking libgen.h usability... yes
checking libgen.h presence... yes
checking for libgen.h... yes
checking paths.h usability... no
checking paths.h presence... no
checking for paths.h... no
checking libcharset.h usability... no
checking libcharset.h presence... no
checking for libcharset.h... no
checking for locale_charset in -liconv... no
checking for locale_charset in -lcharset... no
checking for strcasestr... no
checking for strtok_r... yes
checking for library containing strtok_r... none required
checking for fnmatch... yes
checking for library containing fnmatch... none required
checking whether the fnmatch function supports the FNMATCH_CASEFOLD GNU extension... no
checking for memmem... no
checking for strlcpy... no
checking for uintmax_t... yes
checking for strtoumax... yes
checking for library containing strtoumax... none required
checking for setenv... yes
checking for library containing setenv... none required
checking for unsetenv... yes
checking for library containing unsetenv... none required
checking for mkdtemp... no
checking for mkstemps... no
checking for initgroups... yes
checking for library containing initgroups... none required
checking Checking for POSIX Threads with '-mt'... yes
configure: creating ./config.status
config.status: creating config.mak.autogen
config.status: executing config.mak.autogen commands
But when i run make (with –d) it simply doesn’t work with a message which isn’t really helpfull :
Make: line 313: syntax error. Stop.
setvar: $ = $ noreset = 0 envflg = 0 Mflags = 040101
Reading "=" type args on command line.
Reading internal rules.
setvar: MAKE = make noreset = 0 envflg = 0 Mflags = 040101
setvar: YACC = yacc noreset = 0 envflg = 0 Mflags = 040101
setvar: YFLAGS = noreset = 0 envflg = 0 Mflags = 040101
setvar: LEX = lex noreset = 0 envflg = 0 Mflags = 040101
setvar: LFLAGS = noreset = 0 envflg = 0 Mflags = 040101
setvar: LD = ld noreset = 0 envflg = 0 Mflags = 040101
setvar: LDFLAGS = noreset = 0 envflg = 0 Mflags = 040101
setvar: CC = cc noreset = 0 envflg = 0 Mflags = 040101
setvar: FC = f90 noreset = 0 envflg = 0 Mflags = 040101
setvar: PC = pc noreset = 0 envflg = 0 Mflags = 040101
setvar: CFLAGS = -O noreset = 0 envflg = 0 Mflags = 040101
setvar: PFLAGS = -O noreset = 0 envflg = 0 Mflags = 040101
setvar: FFLAGS = -O noreset = 0 envflg = 0 Mflags = 040101
setvar: RFLAGS = -O noreset = 0 envflg = 0 Mflags = 040101
setvar: AS = as noreset = 0 envflg = 0 Mflags = 040101
setvar: ASFLAGS = noreset = 0 envflg = 0 Mflags = 040101
setvar: ARFLAGS = -rv noreset = 0 envflg = 0 Mflags = 040101
setvar: GET = get noreset = 0 envflg = 0 Mflags = 040101
setvar: GFLAGS = noreset = 0 envflg = 0 Mflags = 040101
setvar: CXXFLAGS = -O noreset = 0 envflg = 0 Mflags = 040101
setvar: CXX = CC noreset = 0 envflg = 0 Mflags = 040101
setvar: CXX = aCC noreset = 0 envflg = 0 Mflags = 040101
setvar: SCCSFLAGS = noreset = 0 envflg = 0 Mflags = 040101
setvar: SCCSGETFLAGS = -s noreset = 0 envflg = 0 Mflags = 040101
Reading environment.
setvar: _ = /usr/bin/make noreset = 0 envflg = -1 Mflags = 040005
setvar: MANPATH = /usr/share/man/%L:/usr/share/man:/usr/contrib/man/%L:/usr/contrib/man:/usr/local/man/%L:/usr/local/man:/opt/ipf/man:/opt/samba/man:/opt/samba/WTEC_Support_Tools/man:/opt/samba/cfsm_man:/opt/cifsclient/share/man:/opt/openssl/man:/opt/openssl/prngd/man:/opt/wbem/share/man:/opt/graphics/common/man:/opt/amgr/man:/opt/amgr/man/%L:/opt/sec_mgmt/share/man:/opt/drd/share/man/%L:/opt/drd/share/man:/opt/dsau/man:/opt/resmon/share/man/%L:/opt/resmon/share/man:/opt/gnome/man:/opt/perf/man/%L:/opt/perf/man:/opt/ignite/share/man/%L:/opt/ignite/share/man:/usr/contrib/kwdb/share/man:/opt/perl_32/man:/opt/perl_64/man:/opt/prm/man/%L:/opt/prm/man:/opt/sfmdb/pgsql/man:/opt/sfm/share/man:/opt/swm/share/man/%L:/opt/swm/share/man:/opt/sec_mgmt/share/man/%L:/opt/ssh/share/man:/opt/swa/share/man/%L:/opt/swa/share/man:/opt/VRTS/man:/opt/gwlm/man/%L:/opt/gwlm/man:/opt/hpvm/man/%L:/opt/hpvm/share/man/%L:/opt/VRTS/man noreset = 0 envflg = -1 Mflags = 040005
setvar: SSH_TTY = /dev/pts/0 noreset = 0 envflg = -1 Mflags = 040005
setvar: PATH = /usr/sbin:/usr/bin:/usr/ccs/bin:/usr/contrib/bin:/usr/contrib/Q4/bin:/opt/perl/bin:/opt/ipf/bin:/opt/nettladm/bin:/opt/fcms/bin:/opt/wbem/bin:/opt/wbem/sbin:/opt/sas/bin:/opt/graphics/common/bin:/usr/bin/X11:/usr/contrib/bin/X11:/opt/sec_mgmt/bastille/bin:/opt/drd/bin:/opt/dsau/bin:/opt/dsau/sbin:/opt/resmon/bin:/opt/gnome/bin:/opt/perf/bin:/opt/ignite/bin:/usr/contrib/kwdb/bin:/opt/perl_32/bin:/opt/perl_64/bin:/opt/prm/bin:/opt/sfm/bin:/opt/swm/bin:/opt/sec_mgmt/spc/bin:/opt/ssh/bin:/opt/swa/bin:/opt/hpsmh/bin:/opt/gwlm/bin:/opt/hpvm/bin:/opt/gvsd/bin:/sbin:/usr/local/bin/:/home/root:/opt/VRTSgab:/opt/VRTSllt:/opt/VRTSvcs/bin:/usr/local/pa20_32/bin:/usr/local/pa20_64/bin:/opt/hpjmeter/bin noreset = 0 envflg = -1 Mflags = 040005
setvar: COLUMNS = 204 noreset = 0 envflg = -1 Mflags = 040005
setvar: EDITOR = vi noreset = 0 envflg = -1 Mflags = 040005
setvar: HISTFILE = /root/.sh_history/.sh_history.pts0 noreset = 0 envflg = -1 Mflags = 040005
setvar: LOGNAME = root noreset = 0 envflg = -1 Mflags = 040005
setvar: MAIL = /var/mail/root noreset = 0 envflg = -1 Mflags = 040005
setvar: SFTP_UMASK = noreset = 0 envflg = -1 Mflags = 040005
setvar: ERASE = ^H noreset = 0 envflg = -1 Mflags = 040005
setvar: PS1 = obux071:[VM]:$PWD\# noreset = 0 envflg = -1 Mflags = 040005
setvar: SFTP_PERMIT_CHOWN = 1 noreset = 0 envflg = -1 Mflags = 040005
setvar: USER = root noreset = 0 envflg = -1 Mflags = 040005
setvar: HOME = /root noreset = 0 envflg = -1 Mflags = 040005
setvar: SSH_CONNECTION = 10.174.53.132 2322 10.238.22.79 22 noreset = 0 envflg = -1 Mflags = 040005
setvar: SSH_CLIENT = 10.174.53.132 2322 22 noreset = 0 envflg = -1 Mflags = 040005
setvar: TERM = xterm noreset = 0 envflg = -1 Mflags = 040005
setvar: PWD = /root/git/git-1.7.12.4 noreset = 0 envflg = -1 Mflags = 040005
setvar: TZ = MET-1METDST noreset = 0 envflg = -1 Mflags = 040005
setvar: SFTP_PERMIT_CHMOD = 1 noreset = 0 envflg = -1 Mflags = 040005
setvar: LINES = 53 noreset = 0 envflg = -1 Mflags = 040005
setvar: PROJECTDIR = noreset = 0 envflg = 0 Mflags = 040001
setvar: SHELL = /usr/bin/sh noreset = 0 envflg = 0 Mflags = 040001
Reading Makefile
(Ignoring)Include file: "GIT-VERSION-FILE"
Make: line 313: syntax error. Stop.
Can you help me ?
Cordialement,
Ronan QUINTIN
TMA EAI - Division Telecom & Media
Sopra group.
Centre Espace Performance - Batiment S
35769 St Grégoire
Phone : +33 (0)2 23 25 34 71
ronan.quintin@sopragroup.com - www.sopragroup.com
Ce message peut contenir des informations confidentielles dont la divulgation est à ce titre rigoureusement interdite en l'absence d'autorisation explicite de l'émetteur. Dans l'hypothèse où vous auriez reçu par erreur ce message, merci de le renvoyer à l’émetteur et de détruire toute copie.
Pensez à l’environnement avant d’imprimer.
^ permalink raw reply
* Re: push branch descriptions
From: Ramkumar Ramachandra @ 2012-11-14 10:33 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: git
In-Reply-To: <CAB9Jk9ABenaj=R0a6OW2GCsin8PdDCW3ZbuQbu6G0jnGG3s+sA@mail.gmail.com>
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.
Ram
^ permalink raw reply
* creation of empty branches
From: Angelo Borsotti @ 2012-11-14 10:10 UTC (permalink / raw)
To: git
Hi,
the man page of git checkout does not describe the behavior of
git-checkout when asked to create empty branches. E.g.:
$ git init myrepo
$ cd myrepo
$ git checkout -b newbranch
the last command actually changes only the HEAD. It displays no output
telling the user that no switch to a new branch is done. Moreover, it
can be entered again without receiving any error message (unlike the
creation ot non-empty branches, which is instead rejected).
I would suggest to add to the DESCRIPTION, after the paragraph: "If -b
is given ...":
"If the repository does not contain any branch, no new branch is
created, but the HEAD is set to refer to it."
Moreover, it is often reported (e.g. in the progit book) that git
checkout -b is equivalent to git branch; git checkout, and this is
true when nonempty branches are created, but it is not when the
repository is empty:
$ git init myrepo
$ cd myrepo
$ git branch master
fatal: Not a valid object name: 'master'.
however:
$ git checkout -b master
.... no error
This seems quite strange and difficult to understand: why should git
branch master issue an error while git checkout does not? I have the
impression that also git branch should not issue an error in this
case.
-Angelo Borsotti
^ permalink raw reply
* Re: Git does not understand absolute Win'dos' path
From: Johannes Sixt @ 2012-11-14 9:45 UTC (permalink / raw)
To: Martin Lichtin; +Cc: git@vger.kernel.org
In-Reply-To: <1352884329.28981.YahooMailNeo@web162504.mail.bf1.yahoo.com>
Am 11/14/2012 10:12, schrieb Martin Lichtin:
> Maven's release plugin prepares a call Git like in this example:
>
> cmd.exe /X /C "git commit --verbose -F
> C:\cygwin\tmp\maven-scm-915771020.commit pom.xml"
>
> Git doesn't seem to understand the -F argument and treats it like a
> relative path (relative to the repository root):
>
> $ cmd.exe /X /C "git commit --verbose -F C:\cygwin\tmp\commit pom.xml"
> fatal: could not read log file 'mytestdir/C:\cygwin\tmp\commit': No
> such file or directory
According to the code, this should not happen if you are using msysgit.
For this reason, I guess you are using Cygwin git. Right?
I don't know what Cygwin programs are supposed to do if they receive an
argument that looks like a Windows style absolute path.
OTOH, it could be argued that Maven should not treat a Cygwin program like
a DOS program, and it should pass the path in the POSIXy form
/c/cygwin/tmp/commit or /tmp/commit.
-- Hannes
^ permalink raw reply
* Re: Notes in format-patch
From: Michael J Gruber @ 2012-11-14 9:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7vfw4de5oc.fsf@alter.siamese.dyndns.org>
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. Do you have an empty note?
I'm not getting any (origin/next+your patch).
The fact that we don't usually have that empty line was the reason why I
preferred to have no empty line between the --- and the "Note:".
Michael
^ permalink raw reply
* Git does not understand absolute Win'dos' path
From: Martin Lichtin @ 2012-11-14 9:12 UTC (permalink / raw)
To: git@vger.kernel.org
Hi
Maven's release plugin prepares a call Git like in this example:
cmd.exe /X /C "git commit --verbose -F C:\cygwin\tmp\maven-scm-915771020.commit pom.xml"
Git doesn't seem to understand the -F argument and treats it like a relative path (relative to the repository root):
$ cmd.exe /X /C "git commit --verbose -F C:\cygwin\tmp\commit pom.xml"
fatal: could not read log file 'mytestdir/C:\cygwin\tmp\commit': No such file or directory
^ 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