* Re: [PATCHv3 3/4] git-status: show short sequencer state
From: Phil Hord @ 2012-11-13 23:50 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: <50A13C9A.8070108@cisco.com>
Phil Hord wrote:
> Junio C Hamano wrote:
>> Phil Hord <hordp@cisco.com> writes:
>>
>>> State token strings which may be emitted and their meanings:
>>> merge a merge is in progress
>>> am an am is in progress
>>> am-is-empty the am patch is empty
>>> rebase a rebase is in progress
>>> rebase-interactive an interactive rebase is in progress
>>> cherry-pick a cherry-pick is in progress
>>> bisect a bisect is in progress
>>> conflicted there are unresolved conflicts
>>> commit-pending a commit operation is waiting to be completed
>>> splitting interactive rebase, commit is being split
>>>
>>> I also considered adding these tokens, but I decided it was not
>>> appropriate since these changes are not sequencer-related. But
>>> it is possible I am being too short-sighted or have chosen the
>>> switch name poorly.
>>> changed-index Changes exist in the index
>>> changed-files Changes exist in the working directory
>>> untracked New files exist in the working directory
>> I tend to agree; unlike all the normal output from "status -s" that
>> are per-file, the above are the overall states of the working tree.
>>
>> It is just that most of the "overall states" look as if they are
>> dominated by "sequencer states", but that is only because you chose
>> to call states related to things like "am" and "bisect" that are not
>> sequencer states as such.
>>
>> It probably should be called the tree state, working tree state, or
>> somesuch.
> I think you are agreeing that I chose the switch name poorly, right?
>
> 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.
I'm happy to make that official and use --tokens and -T, but I suspect a
more appropriate name is available.
Phil
^ permalink raw reply
* Re: [PATCH v3 0/5] push: update remote tags only with force
From: Drew Northup @ 2012-11-13 23:58 UTC (permalink / raw)
To: Chris Rorvick
Cc: git, Angelo Borsotti, Michael Haggerty, Philip Oakley,
Johannes Sixt, Kacper Kornet, Jeff King, Felipe Contreras,
Junio C Hamano
In-Reply-To: <1352693288-7396-1-git-send-email-chris@rorvick.com>
On Sun, Nov 11, 2012 at 11:08 PM, Chris Rorvick <chris@rorvick.com> wrote:
> Minor changes since from v2 set.
.....
> An email thread initiated by Angelo Borsotti did not come to a
> consensus on how push should behave with regard to tag references.
Minor Nit: Without the link to gmane it is an exercise left to the
reviewer to find that you're talking about this thread:
http://thread.gmane.org/gmane.comp.version-control.git/208354
Cheers.
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: Fwd: [PATCH] Add tcsh-completion support to contrib by using git-completion.bash
From: SZEDER Gábor @ 2012-11-14 0:09 UTC (permalink / raw)
To: Marc Khouzam; +Cc: git
In-Reply-To: <CAFj1UpFd9X8Jq5o7B4m35i=merBDvOo4NOtwth=UnG2S5X_rGw@mail.gmail.com>
Hi,
I've got two more comments.
On Mon, Nov 12, 2012 at 03:07:46PM -0500, Marc Khouzam wrote:
> @@ -2481,3 +2483,52 @@ __git_complete gitk __gitk_main
> if [ Cygwin = "$(uname -o 2>/dev/null)" ]; then
> __git_complete git.exe __git_main
> fi
> +
> +# Method that will output the result of the completion done by
> +# the bash completion script, so that it can be re-used in another
> +# context than the bash complete command.
> +# It accepts 1 to 2 arguments:
> +# 1: The command-line to complete
> +# 2: The index of the word within argument #1 in which the cursor is
> +# located (optional). If parameter 2 is not provided, it will be
> +# determined as best possible using parameter 1.
> +_git_complete_with_output ()
We differentiate between _git_whatever() and __git_whatever()
functions. The former performs completion for the 'whatever' git
command/alias, the latter is a completion helper function. This
is a helper function, so it should begin with double underscores.
> +{
> + # Set COMP_WORDS to the command-line as bash would.
> + COMP_WORDS=($1)
> +
> + # Set COMP_CWORD to the cursor location as bash would.
> + if [ -n "$2" ]; then
A while ago the completion script was made 'set -u'-clean. (If 'set
-u' is enabled, then it's an error to access undefined variables).
I'm not sure how many people are out there who'd use this script for
tcsh while having 'set -u' in their profile... probably not that
many. Still, I think it would be great to keep it up.
Here $2 would be undefined, so accessingit it would cause an error
under those semantincs. Please use ${2-} instead (use empty string
when undefined).
> +if [ -n "$1" ] ; then
Same here.
> + # If there is an argument, we know the script is being executed
> + # so go ahead and run the _git_complete_with_output function
> + _git_complete_with_output "$1" "$2"
And here.
Thanks
Gábor
^ permalink raw reply
* Re: [PATCH] Add tcsh-completion support to contrib by using git-completion.bash
From: SZEDER Gábor @ 2012-11-14 0:11 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Marc Khouzam, git
In-Reply-To: <CAMP44s3imos4DksroRkZ3K6una5H916gvtqttJQna8yGG8XhsQ@mail.gmail.com>
On Tue, Nov 13, 2012 at 07:31:45PM +0100, Felipe Contreras wrote:
> On Mon, Nov 12, 2012 at 9:07 PM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
> > + # Call _git() or _gitk() of the bash script, based on the first
> > + # element of the command-line
> > + _${COMP_WORDS[0]}
>
> You might want to use __${COMP_WORDS[0]}_main instead.
That wouldn't work. __git_main() doesn't set up the
command-line-specific variables, but the wrapper around it does.
> > +# Make the script executable if it is not
> > +if ( ! -x ${__git_tcsh_completion_script} ) then
> > + chmod u+x ${__git_tcsh_completion_script}
> > +endif
>
> Why not just source it?
The goal is to re-use a Bash script to do completion in tcsh. They
are two different breeds, tcsh doesn't grok bash. So sourcing the
completion script is not an option, but we can still run it via Bash
and use it's results.
^ permalink raw reply
* [PATCH] completion: remove 'help' duplicate from porcelain commands
From: SZEDER Gábor @ 2012-11-14 0:49 UTC (permalink / raw)
To: Marc Khouzam, git, Junio C Hamano; +Cc: felipe.contreras
In-Reply-To: <20121113234636.GS12052@goldbirke>
The list of all git commands is computed from the output of 'git help
-a', which already includes 'help', so there is no need to explicitly
add it once more when computing the list of porcelain commands.
Note that 'help' wasn't actually offered twice because of this,
because Bash filters duplicates from possible completion words.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
> > > Does the git completion script returns any duplicates at all?
> >
> > It does. 'help' is returned twice for example.
>
> Right. Now that you mentioned it, I remember I noticed it a while
> ago, too. I even wrote a patch to fix it, but not sure what became of
> it. Will try to dig it up.
Here it is. It turns out I wrote it in May this year, but according to
gmane and my mailbox never sent it out.
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index bc0657a2..b7b1a834 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -585,7 +585,7 @@ __git_list_porcelain_commands ()
{
local i IFS=" "$'\n'
__git_compute_all_commands
- for i in "help" $__git_all_commands
+ for i in $__git_all_commands
do
case $i in
*--*) : helper pattern;;
--
1.8.0.128.g441b4b3
^ permalink raw reply related
* Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
From: Mark Levedahl @ 2012-11-14 1:18 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: Jeff King, git
In-Reply-To: <50A2B14C.9040608@web.de>
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?
> /Torsten
>
>
>
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.
Mark
^ permalink raw reply
* Re: Bug? Subtree merge seems to choke on trailing slashes.
From: Jack O'Connor @ 2012-11-14 2:17 UTC (permalink / raw)
To: git
In-Reply-To: <CA+6di1m7OCMjahP9sN3NcYdxLRRi4vmttFa5=pnHrgKp=E4+jQ@mail.gmail.com>
Do I have the right list for bug reports? Apologies if not.
On Tue, Nov 6, 2012 at 5:58 PM, Jack O'Connor <oconnor663@gmail.com> wrote:
>
> I'm summarizing from here:
> http://stackoverflow.com/questions/5904256/git-subtree-merge-into-a-deeply-nested-subdirectory
>
> Quick repro:
> 1) I do an initial subtree merge in what I think is the standard way
> (http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html).
> My prefix is simply "test/".
> 2) I try to merge more upstream changes on top of that with the
> following command:
> git merge --strategy-option=subtree='test/' $upstream_stuff
> 3) Git fails with an obscure error:
> fatal: entry not found in tree daf4d0f0a20b8b6ec007be9fcafeac84a6eba4f0
>
> If I remove the trailing slash from the command in step 2, it works just fine:
> git merge --strategy-option=subtree='test' $upstream_stuff
>
> Note in the error message above, there's a double space after "entry".
> Is it looking for a tree with an empty name? Did my trailing slash
> imply a directory named empty-string?
>
> Thanks for your help.
>
> -- Jack O'Connor
^ permalink raw reply
* Re: [PATCH] Add tcsh-completion support to contrib by using git-completion.bash
From: Marc Khouzam @ 2012-11-14 3:36 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, SZEDER Gábor
In-Reply-To: <CAMP44s3imos4DksroRkZ3K6una5H916gvtqttJQna8yGG8XhsQ@mail.gmail.com>
Thanks for the review. I wasn't aware that you were doing
a similar effort for zsh.
On Tue, Nov 13, 2012 at 1:31 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Mon, Nov 12, 2012 at 9:07 PM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
>
>> this patch allows tcsh-users to get the benefits of the awesome
>> git-completion.bash script. It could also help other shells do the same.
>
> Maybe you can try to take a look at the same for zsh:
> http://article.gmane.org/gmane.comp.version-control.git/208173
Cool. The major difference is that (as Gábor mentioned) zsh understands bash
syntax but tcsh does not. tcsh doesn't even allow to define
functions. So we have
to take a different approach to get the bash completion script to be
used by tcsh.
>> ---
>> contrib/completion/git-completion.bash | 53 +++++++++++++++++++++++++++++++-
>> contrib/completion/git-completion.tcsh | 34 ++++++++++++++++++++
>> 2 files changed, 86 insertions(+), 1 deletions(-)
>> create mode 100755 contrib/completion/git-completion.tcsh
>>
>> diff --git a/contrib/completion/git-completion.bash
>> b/contrib/completion/git-completion.bash
>> index be800e0..6d4b57a 100644
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -1,4 +1,6 @@
>> -#!bash
>> +#!/bin/bash
>> +# The above line is important as this script can be executed when used
>> +# with another shell such as tcsh
>> #
>> # bash/zsh completion support for core Git.
>> #
>> @@ -2481,3 +2483,52 @@ __git_complete gitk __gitk_main
>> if [ Cygwin = "$(uname -o 2>/dev/null)" ]; then
>> __git_complete git.exe __git_main
>> fi
>> +
>> +# Method that will output the result of the completion done by
>> +# the bash completion script, so that it can be re-used in another
>> +# context than the bash complete command.
>> +# It accepts 1 to 2 arguments:
>> +# 1: The command-line to complete
>> +# 2: The index of the word within argument #1 in which the cursor is
>> +# located (optional). If parameter 2 is not provided, it will be
>> +# determined as best possible using parameter 1.
>> +_git_complete_with_output ()
>> +{
>> + # Set COMP_WORDS to the command-line as bash would.
>> + COMP_WORDS=($1)
>> +
>> + # Set COMP_CWORD to the cursor location as bash would.
>> + if [ -n "$2" ]; then
>> + COMP_CWORD=$2
>> + else
>> + # Assume the cursor is at the end of parameter #1.
>> + # We must check for a space as the last character which will
>> + # tell us that the previous word is complete and the cursor
>> + # is on the next word.
>> + if [ "${1: -1}" == " " ]; then
>> + # The last character is a space, so our
>> location is at the end
>> + # of the command-line array
>> + COMP_CWORD=${#COMP_WORDS[@]}
>> + else
>> + # The last character is not a space, so our
>> location is on the
>> + # last word of the command-line array, so we
>> must decrement the
>> + # count by 1
>> + COMP_CWORD=$((${#COMP_WORDS[@]}-1))
>> + fi
>> + fi
>> +
>> + # Call _git() or _gitk() of the bash script, based on the first
>> + # element of the command-line
>> + _${COMP_WORDS[0]}
>
> You might want to use __${COMP_WORDS[0]}_main instead.
>
>> +
>> + # Print the result that is stored in the bash variable ${COMPREPLY}
>> + for i in ${COMPREPLY[@]}; do
>> + echo "$i"
>> + done
>> +}
>> +
>> +if [ -n "$1" ] ; then
>> + # If there is an argument, we know the script is being executed
>> + # so go ahead and run the _git_complete_with_output function
>> + _git_complete_with_output "$1" "$2"
>> +fi
>
> Why do you need this function in this file? You can very easily add
> this function to git-completion.tcsh.
tcsh does not allow to define functions, so it is not aware of any
of the git-completion.bash functions. So, git-completion.tcsh
cannot call anything from git-completion.bash.
>> diff --git a/contrib/completion/git-completion.tcsh
>> b/contrib/completion/git-completion.tcsh
>> new file mode 100755
>> index 0000000..7b7baea
>> --- /dev/null
>> +++ b/contrib/completion/git-completion.tcsh
>> @@ -0,0 +1,34 @@
>> +#!tcsh
>> +#
>> +# tcsh completion support for core Git.
>> +#
>> +# Copyright (C) 2012 Marc Khouzam <marc.khouzam@gmail.com>
>> +# Distributed under the GNU General Public License, version 2.0.
>> +#
>> +# This script makes use of the git-completion.bash script to
>> +# determine the proper completion for git commands under tcsh.
>> +#
>> +# To use this completion script:
>> +#
>> +# 1) Copy both this file and the bash completion script to your
>> ${HOME} directory
>> +# using the names ${HOME}/.git-completion.tcsh and
>> ${HOME}/.git-completion.bash.
>> +# 2) Add the following line to your .tcshrc/.cshrc:
>> +# source ${HOME}/.git-completion.tcsh
>> +
>> +# One can change the below line to use a different location
>> +set __git_tcsh_completion_script = ${HOME}/.git-completion.bash
>> +
>> +# Check that the user put the script in the right place
>> +if ( ! -e ${__git_tcsh_completion_script} ) then
>> + echo "ERROR in git-completion.tcsh script. Cannot find:
>> ${__git_tcsh_completion_script}. Git completion will not work."
>> + exit
>> +endif
>> +
>> +# Make the script executable if it is not
>> +if ( ! -x ${__git_tcsh_completion_script} ) then
>> + chmod u+x ${__git_tcsh_completion_script}
>> +endif
>
> Why not just source it?
>
>> +complete git 'p/*/`${__git_tcsh_completion_script} "${COMMAND_LINE}"
>> | sort | uniq`/'
>> +complete gitk 'p/*/`${__git_tcsh_completion_script} "${COMMAND_LINE}"
>> | sort | uniq`/'
>
> This seems to be very different from bash's 'complete'. I wonder if
> the 'complete' commands in the original script cause any problems.
> Maybe only if you source it, but then again, I would expect a warning
> or something when you run it.
If you source the script under tcsh it will fail miserably because the bash
syntax is very different. But when you run it, it runs under the bash shell
so everything will work fine. The 'complete' command in the bash script
will run, but will only affect the temporary bash shell that was started
to run the script. Useless but harmless.
> But you can use the trick I did with zsh so you can source it:
>
> complete ()
> {
> # do nothing
> return 0
> }
>
> . "$script"
This is pretty cool. Function overriding in shell scripts! tcsh doesn't
even have functions, so that trick is out of its league :)
Thanks
Marc
^ permalink raw reply
* Re: Fwd: [PATCH] Add tcsh-completion support to contrib by using git-completion.bash
From: Marc Khouzam @ 2012-11-14 4:26 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git, felipe.contreras
In-Reply-To: <20121113234636.GS12052@goldbirke>
On Tue, Nov 13, 2012 at 6:46 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:
> Hi,
>
> On Tue, Nov 13, 2012 at 03:12:44PM -0500, Marc Khouzam wrote:
>> >> +if [ -n "$1" ] ; then
>> >> + # If there is an argument, we know the script is being executed
>> >> + # so go ahead and run the _git_complete_with_output function
>> >> + _git_complete_with_output "$1" "$2"
>> >
>> > Where does the second argument come from? Below you run this script
>> > as '${__git_tcsh_completion_script} "${COMMAND_LINE}"', i.e. $2 is
>> > never set. Am I missing something?
>>
>> This second argument is optional and, if present, will be put in
>> $COMP_CWORD. If not present, $COMP_CWORD must be computed
>> from $1. Also see comment above _git_complete_with_output ().
>> tcsh does not provide me with this information, so I cannot make use of it.
>> However, I thought it would be more future-proof to allow it for other shells
>> which may have that information.
>>
>> It is not necessary for tcsh, so I can remove if you prefer?
>
> I see. I read those comments and understood what it is about. I was
> just surprised that the code is there to make use of it, yet it's not
> specified when invoking that function.
>
> Since it's a trivial piece of code, I would say let's keep it. Could
> you please add a sentence about it (that it's for possible future
> users and it's not used at the moment) to the commit message for
> future reference?
Will do.
>> >> +complete git 'p/*/`${__git_tcsh_completion_script} "${COMMAND_LINE}"
>> >> | sort | uniq`/'
>> >> +complete gitk 'p/*/`${__git_tcsh_completion_script} "${COMMAND_LINE}"
>> >> | sort | uniq`/'
>> >
>> > Is the 'sort | uniq' really necessary? After the completion function
>> > returns Bash automatically sorts the elements in COMPREPLY and removes
>> > any duplicates. Doesn't tcsh do the same? I have no idea about tcsh
>> > completion.
>>
>> On my machine, tcsh does not remove duplicates. It does sort the results
>> but that is done after I've run 'uniq', which is too late. I'm not
>> happy about this
>> either, but the other option is to improve git-completion.bash to
>> avoid duplicates,
>> which seemed less justified.
>
> Ok. Then keep it for the time being, and we'll see what we can do to
> avoid those duplicates.
Thanks.
>> > Does the git completion script returns any duplicates at all?
>>
>> It does. 'help' is returned twice for example.
>
> Right. Now that you mentioned it, I remember I noticed it a while
> ago, too. I even wrote a patch to fix it, but not sure what became of
> it. Will try to dig it up.
Thanks for already posting the patch.
>> Also, when completing 'git checkout ' in the git repo, I can see multiple
>> 'todo' branches, as well as 'master', 'pu', 'next', etc.
>>
>> You can actually try it without tcsh by running my proposed version of
>> git-completion.bash like this:
>>
>> cd git/contrib/completion
>> bash git-completion.bash "git checkout " | sort | uniq --repeated
>
> Interesting, I can't reproduce. Are the duplicates also there, if you
> start a bash, source git-completion.bash, and run __git_refs ?
Running __git_refs does not show the duplicates, but running
__git refs '' 1
does show them.
That second parameter causes __git_refs to
"use the guess heuristic employed by checkout for tracking branches"
I don't quite understand this, but what I can see is that my remote
branches GitHub/master and origin/master each cause another
'master' to be listed:
$ __git_refs '' 1|grep master
master
GitHub/master
origin/master
master
master
All fixes are done and I'll post a second version of the patch
as soon as I can figure out the formatting properly.
Thanks again
Marc
^ permalink raw reply
* [PATCH] config: don't segfault when given --path with a missing value
From: Carlos Martín Nieto @ 2012-11-14 4:50 UTC (permalink / raw)
To: git
When given a variable without a value, such as '[section] var' and
asking git-config to treat it as a path, git_config_pathname returns
an error and doesn't modify its output parameter. show_config assumes
that the call is always successful and sets a variable to indicate
that vptr should be freed. In case of an error however, trying to do
this will cause the program to be killed, as it's pointing to memory
in the stack.
Set the must_free_vptr flag depending on the return value of
git_config_pathname so it's accurate.
---
builtin/config.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index 442ccc2..60220d5 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -129,8 +129,7 @@ static int show_config(const char *key_, const char *value_, void *cb)
else
sprintf(value, "%d", v);
} else if (types == TYPE_PATH) {
- git_config_pathname(&vptr, key_, value_);
- must_free_vptr = 1;
+ must_free_vptr = !git_config_pathname(&vptr, key_, value_);
} else if (value_) {
vptr = value_;
} else {
--
1.8.0.316.g291341c
^ permalink raw reply related
* Re: [PATCH v3 0/5] push: update remote tags only with force
From: Chris Rorvick @ 2012-11-14 6:29 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras
In-Reply-To: <CAEUsAPYvrR6WsVWCvwoEWA21gzL6Sib0sTyx-c_2tH=8ni69yQ@mail.gmail.com>
resending to list ...
On Tue, Nov 13, 2012 at 3:20 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Chris Rorvick <chris@rorvick.com> writes:
>
>> Minor changes since from v2 set. Reposting primarily because I mucked
>> up the Cc: list (again) and hoping to route feedback to the appropriate
>> audience.
>>
>> This patch set can be divided into two sets:
>>
>> 1. Provide useful advice for rejected tag references.
>>
>> push: return reject reasons via a mask
>> push: add advice for rejected tag reference
>>
>> Recommending a merge to resolve a rejected tag update seems
>> nonsensical since the tag does not come along for the ride. These
>> patches change the advice for rejected tags to suggest using
>> "push -f".
>
> Below, I take that you mean by "tag reference" everything under
> refs/tags/ (not limited to "annotated tag objects", but also
> lightweight tags).
Yes.
> Given that the second point below is to strongly discourage updating
> of existing any tag, it might be even better to advise *not* to push
> tags in the first place, instead of destructive "push -f", no?
That does seem like a better idea. Read the full manual page to
figure out how to force the update if that's what you want to do--the
advice should not suggest something exceptional.
>> 2. Require force when updating tag references, even on a fast-forward.
>>
>> push: flag updates
>> push: flag updates that require force
>> push: update remote tags only with force
>>
>> An email thread initiated by Angelo Borsotti did not come to a
>> consensus on how push should behave with regard to tag references.
>
> I think the original motivation of allowing fast-forward updates to
> tags was for people who wanted to have "today's recommended version"
> tag that can float from day to day. I tend to think that was a
> misguided notion and it is better implemented with a tip of a
> branch (iow, I personally am OK with the change to forbid tag
> updates altogether, without --force).
>
>> I think a key point is that you currently cannot be sure your push
>> will not clobber a tag (lightweight or not) in the remote.
>
> "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/*? I
initially went this route based on some feedback in the original
thread, but being that specific broke a couple tests in t5516 (i.e.,
pushing to refs/remotes/origin/master and another into refs/tmp/*.)
My initial thought was that I'd broken something and I need to modify
the patch, but now I think I should just modify those tests. Branches
are restricted to refs/heads/* (if I understand correctly), so
allowing fast-forwards when pushing should be limited to this
hierarchy, too.
Thanks,
Chris
^ permalink raw reply
* push branch descriptions
From: Angelo Borsotti @ 2012-11-14 7:20 UTC (permalink / raw)
To: git
Hi
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?
-Angelo Borsotti
^ permalink raw reply
* merge --squash detects a nonexistent error
From: Angelo Borsotti @ 2012-11-14 7:26 UTC (permalink / raw)
To: git
Hello,
I have got a case in which merge --squash issues an error that does
not exist. I hope I am wrong, though.
Consider the following example:
rm -rf public.git
rm -rf private
git init --bare public.git
git clone public.git private
cd private
touch f1; git add f1; git commit -m A
git checkout -b b1
touch f2; git add f2; git commit -m B
git checkout master
git checkout -b b2
touch f3; git add f3; git commit -m C
git checkout master
git checkout -b b3
touch f4; git add f4; git commit -m D
--- at this point we have
A (f1) master
|--B (f1,f2) b1
|--C (f1,f3) b2
`--D (f1,f4) *b3
git merge --squash b1
git merge --squash b2
The first merge adds f2 to the workspace, which then contains f1, f2 and f4.
The second merge should add f3, and instead it complains:
error: Your local changes to the following files would be overwritten by merge:
f2
Please, commit your changes or stash them before you can merge.
Aborting
Why should it overwrite f2, and with what?
-Angelo Borsotti
^ permalink raw reply
* How to setup gitweb with categories
From: frank.jakop @ 2012-11-14 7:50 UTC (permalink / raw)
To: git
Hello,
I'm trying to setup a gitweb frontend with categorized projects. I already
have a plain project list running an changed my gitweb.conf so that it
contains
our $projects_list_group_categories = "1";
our $project_list_default_category = "foo";
I'd now expect all projects to be shown under the category "foo", but upon
reload nothing happens on the web page.
Can anyone tell me what's wrong?
Best regards
Frank
^ permalink raw reply
* Re: [PATCH v3 0/5] push: update remote tags only with force
From: Kacper Kornet @ 2012-11-14 8:19 UTC (permalink / raw)
To: Chris Rorvick
Cc: Junio C Hamano, git, Angelo Borsotti, Drew Northup,
Michael Haggerty, Philip Oakley, Johannes Sixt, Jeff King,
Felipe Contreras
In-Reply-To: <CAEUsAPZtF-L5J_g1L5d44BKveoAnJ81PatX94fFS4FM=iW33KA@mail.gmail.com>
On Wed, Nov 14, 2012 at 12:29:14AM -0600, Chris Rorvick wrote:
> >> 2. Require force when updating tag references, even on a fast-forward.
> >> push: flag updates
> >> push: flag updates that require force
> >> push: update remote tags only with force
> >> An email thread initiated by Angelo Borsotti did not come to a
> >> consensus on how push should behave with regard to tag references.
> > I think the original motivation of allowing fast-forward updates to
> > tags was for people who wanted to have "today's recommended version"
> > tag that can float from day to day. I tend to think that was a
> > misguided notion and it is better implemented with a tip of a
> > branch (iow, I personally am OK with the change to forbid tag
> > updates altogether, without --force).
> >> I think a key point is that you currently cannot be sure your push
> >> will not clobber a tag (lightweight or not) in the remote.
> > "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/*? I
> initially went this route based on some feedback in the original
> thread, but being that specific broke a couple tests in t5516 (i.e.,
> pushing to refs/remotes/origin/master and another into refs/tmp/*.)
> My initial thought was that I'd broken something and I need to modify
> the patch, but now I think I should just modify those tests. Branches
> are restricted to refs/heads/* (if I understand correctly), so
> allowing fast-forwards when pushing should be limited to this
> hierarchy, too.
What about notes? I think they should be treated in the same way as
branches. My impression is that tags are exceptional in this respect.
--
Kacper
^ 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
* 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
* 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
* 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: 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
* 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: 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
* 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: 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: 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
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