* Re: [PATCH] Update 'git remote' usage and man page to match.
From: Nanako Shiraishi @ 2009-11-13 22:19 UTC (permalink / raw)
To: Tim Henigan; +Cc: gitster, git
In-Reply-To: <32c343770911121715l7507b2d5j8c6cf8cccd1f1a61@mail.gmail.com>
Quoting Tim Henigan <tim.henigan@gmail.com> writes:
> This commit:
>
> 1) Removes documentation of '--verbose' from the synopsis portion
> of the usage string since it is a general option.
>
> 2) Removes the 'remote' option from 'git remote update' in the
> man page. This option had already been removed from the usage
> string in the code, but the man page was not updated to match.
>
> Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
> ---
The second change is good but why do you remove -v from the
synopsis section? Why is it a good idea? Manual pages for
many other commands list --verbose in their synopsis section.
^ permalink raw reply
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: Nanako Shiraishi @ 2009-11-13 22:19 UTC (permalink / raw)
To: rocketraman; +Cc: git, trast, gitster
In-Reply-To: <1258055164-11876-2-git-send-email-rocketraman@fastmail.fm>
Quoting rocketraman@fastmail.fm
> From: Raman Gupta <raman@rocketraman.com>
>
> The current man page does a reasonable job at describing branch management
> during the development process, but it does not contain any guidance as to
> how the branches are affected by releases.
>
> Add a basic introduction to the branch management undertaken during a
> git.git release, so that a reader may gain some insight into how the
> integration, maintenance, and topic branches are affected during the
> release transition, and is thus able to better design the process for their
> own project.
>
> Other release activities such as reviews, testing, and creating
> distributions are currently out of scope.
> ---
You are missing Signed-off-by: line.
Here are some corrections that can be applied on top of your change.
-- >8 --
Subject: [PATCH] Corrections to release management section in gitworkflows.txt
The maintenance branch is supposed to be a strict subset of the master
branch at all times. If you find out that this condition was violated
after you pushed a release from the master branch, it is too late.
Correcting that mistake will require redoing and retagging an already
published release.
In http://article.gmane.org/gmane.comp.version-control.git/132692, Junio
explained that the first step is:
- doubly make sure that there is nothing left in 'maint' that
is not in 'master';
to avoid that mistake. Explain the exact procedure in a recipe format,
and make sure it is done before the tip of the master branch is tagged.
Also use --ff-only when merging master into maint.
Rebuilding of 'next' must be done on 'next' branch; correct the
command sequence in the recipe.
Other minor clarifications in the text are also included in this change:
* Clarify "building documentation" a bit; the post-update hook
creates preformatted documentation pages.
* The latest documentation set uses "fast-forward", not "fast
forward".
* Call 'next' branch an integration branch, not a "testing" branch, to be
consistent with the Graduation section.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
Documentation/gitworkflows.txt | 57 +++++++++++++++++++++------------------
1 files changed, 31 insertions(+), 26 deletions(-)
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
index 7000930..b1c7ef3 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/gitworkflows.txt
@@ -216,8 +216,19 @@ Assuming you are using the merge approach discussed above, when you
are releasing your project you will need to do some additional branch
management work.
-Creating a release is easy. Since 'master' is tracking the commits
-that should go into the next feature release, simply tag the tip of
+Since 'master' is supposed to be always a superset of 'maint', you
+should first make sure that condition holds.
+
+.Make sure 'maint' fast-forwards to 'master'
+[caption="Recipe: "]
+=====================================
+git log master..maint
+=====================================
+
+There should be no commit listed from this command (otherwise, check
+out 'master' and merge 'maint' into it).
+
+Then you can tag the tip of
'master' with a tag indicating the release version.
.Release tagging
@@ -230,11 +241,15 @@ Similarly, for a maintenance release, 'maint' is tracking the commits
to be released. Therefore, simply replace 'master' above with
'maint'.
-Generally, you should push the new tag to a public git server (see
+You need to push the new tag to a public git server,
+at the same time you push the updated 'master' or 'maint',
+if you are making a maintenance release. (see
"DISTRIBUTED WORKFLOWS" below). This push makes the tag available to
others tracking your project. The push could also trigger a
post-update hook to perform release-related items such as building
-documentation.
+release tarballs and preformatted documentation pages. You may want
+to wait this push-out before you update your 'maint' branch (see the
+next section).
Maintenance branch management after a feature release
@@ -256,47 +271,37 @@ where X.Y.Z is the current release).
`git branch maint-X.Y.(Z-1) maint`
=====================================
-The 'maint' branch should now be fast forwarded to the newly released
+The 'maint' branch should now be fast-forwarded to the newly released
code so that maintenance fixes can be tracked for the current release:
.Update maint to new release
[caption="Recipe: "]
=====================================
-* `git checkout maint`
-* `git merge master`
+* `git checkout maint`
+* `git merge --ff-only master`
=====================================
-This 'should' fast forward 'maint' from 'master'. If it is not a fast
-forward, then 'maint' contained some commits that were not included on
+This should fast-forward 'maint' from 'master'. If it is not a
+fast-forward, then 'maint' contained some commits that were not included on
'master', which means that the recent feature release could be missing
-some fixes made on 'maint'. The exception is if there were any commits
-that were cherry-picked to 'maint' as described above in "Merging
-upwards". In this case, the merge will not be a fast forward.
-
-An alternative approach to updating the 'maint' branch, though one
-not used in git.git, is to rename the current 'maint' branch to track
-maintenance fixes for the older release and then to recreate 'maint'
-from 'master':
-
- $ git branch -m maint maint-X.Y.(Z-1)
- $ git branch maint master
-
-The latter step will create a new 'maint' branch based on 'master'. If
-commits were cherry-picked to 'maint', then this will create a new
-'maint' branch without a merge commit.
+some fixes made on 'maint'. If that happens, you need to go back to the
+previous "Branch management for a release" step. Correcting this mistake
+becomes messy if you have already pushed the release tag, and that is why
+you should wait until finishing this step before pushing the release out.
Branch management for next and pu after a feature release
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-After a feature release, the 'next' testing branch may optionally be
+After a feature release, the integration branch 'next' may optionally be
rewound and rebuilt from the tip of 'master' using the surviving
topics on 'next':
.Update maint to new release
[caption="Recipe: "]
=====================================
-* `git branch -f next master`
+* `git checkout next`
+* `git reset --hard master`
* `git merge ai/topic_in_next1`
* `git merge ai/topic_in_next2`
* ...
--
1.6.5.2.159.g67ee8
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* [PATCH] remote: Fix glibc error in ref_remove_duplicates
From: Julian Phillips @ 2009-11-13 21:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, git, Nicolas Pitre
In-Reply-To: <alpine.LFD.2.00.0911131152120.16711@xanadu.home>
In ref_remove_duplicates, when we encounter a duplicate and remove it
from the list we need to make sure that the prev pointer stays
pointing at the last entry and also skip over adding the just freed
entry to the string_list.
Previously fetch could crash with:
*** glibc detected *** git: corrupted double-linked list: ...
Also add a test to try and catch problems with duplicate removal in
the future.
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
---
Thanks to Rene for pointing me at the problem before I even looked at
it. Made it much easier to figure out what was going wrong. :)
remote.c | 2 ++
t/t5510-fetch.sh | 11 +++++++++++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/remote.c b/remote.c
index 4f9f0cc..002f790 100644
--- a/remote.c
+++ b/remote.c
@@ -754,6 +754,8 @@ void ref_remove_duplicates(struct ref *ref_map)
prev->next = ref_map->next;
free(ref_map->peer_ref);
free(ref_map);
+ ref_map = prev; // don't change the prev pointer.
+ continue;
}
item = string_list_insert(ref_map->peer_ref->name, &refs);
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index d13c806..169af1e 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -341,4 +341,15 @@ test_expect_success 'fetch into the current branch with --update-head-ok' '
'
+test_expect_success "should be able to fetch with duplicate refspecs" '
+ mkdir dups &&
+ cd dups &&
+ git init &&
+ git config branch.master.remote three &&
+ git config remote.three.url ../three/.git &&
+ git config remote.three.fetch +refs/heads/*:refs/remotes/origin/* &&
+ git config --add remote.three.fetch +refs/heads/*:refs/remotes/origin/* &&
+ git fetch three
+'
+
test_done
--
1.6.5.rc2
^ permalink raw reply related
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Nanako Shiraishi @ 2009-11-13 21:06 UTC (permalink / raw)
To: Michael J Gruber
Cc: Felipe Contreras, Jonathan Nieder, Junio C Hamano, git,
J. Bruce Fields, Hannu Koivisto, Jeff King, Wincent Colaiuta,
Matthias Lederhofer
In-Reply-To: <4AFBF18E.7070906@drmicha.warpmail.net>
Quoting Michael J Gruber <git@drmicha.warpmail.net>
> Regarding this specific patch series: I took part in the initial
> discussion, and got frustrated by the original poster's seemingly
> unwillingness to accept advice, so I left. I'm not drawing any general
> conclusions, and please don't take this as an ad hominem argument.
> Sometimes it's simply a matter of mismatching participants.
I didn't get myself involved in the follow-up discussion exactly
for the same reason.
> If you care to go back to that discussion you see that there is good
> reason for having both --cached and --index. They are different. "git
> help cli" explains this nicely.
The need to support both options in the same command (eg. apply) means
that anybody who says "I don't like 'index' nor 'cache'; why don't we
change them all to 'stage'" doesn't understand the issue.
But that doesn't mean "apply --cached" vs "apply --index" is the best
way to let the users specify which operation is requested. I don't
think Felipe seriously wants to change them to --gogo vs --dance, but
if he made a more constructive proposal, instead of making such a
comment whose intended effect is only to annoy people, we may see
an improved UI at the end. Proposing "--index-only" vs "--index-too"
or even "--stage-only" vs "--stage-too" would have helped him appear
to be more serious and constructive and I think your expression
"mismatching participants" was a great way to say this.
There was a similar discussion about "diff --cached". The command
compares two things and the current syntax relies on counting the
number of treeish on the command line to specify what these two things
are, and sometimes people are confused which way the comparison occurs.
* If you have two treeish, it compares the two treeish. Specifically,
it shows the change to make one treeish into the other treeish.
* If you have one treeish, it compares the treeish with working tree
or the index (it shows the change to make the treeish into working
tree or the index). You need --cached to choose the "index", and
this can safely be aliased to --staged.
* If you have zero treeish, it compares the index with working tree
(it shows the change to make the index into working tree).
But it is also possible to have an alternate syntax to explicitly say
what you are comparing with what. Perhaps these may make it unnecessary
to remember which way the comparison occurs:
git diff --tree-vs-staged HEAD
same as "git diff --cached HEAD"
git diff --staged-vs-tree HEAD
same as "git diff -R --cached HEAD"
git diff --staged-vs-working
same as "git diff"
git diff --working-vs-staged
same as "git diff -R"
git diff --tree-vs-working HEAD
same as "git diff HEAD"
git diff --working-vs-tree HEAD
same as "git diff -R HEAD"
If people like this as a concept we can introduce shorter way to spell
them, eg. "git diff --ts HEAD", etc.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] Speed up bash completion loading
From: Stephen Boyd @ 2009-11-13 20:43 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Kirill Smelkov, Sverre Rabbelier, Junio C Hamano, Shawn O. Pearce,
git
In-Reply-To: <20091113090343.GA5355@progeny.tock>
Jonathan Nieder wrote:
> On my slow laptop (P3 600MHz), system-wide bash completions take
> too much time to load (> 2s), and a significant fraction of this
> time is spent loading git-completion.bash:
>
[...]
> Suggested-by: Kirill Smelkov <kirr@mns.spb.ru>
> Cc: Shawn O. Pearce <spearce@spearce.org>
> Cc: Stephen Boyd <bebarino@gmail.com>
> Cc: Sverre Rabbelier <srabbelier@gmail.com>
> Cc: Junio C Hamano <junio@pobox.com>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
I was under the impression that setting variables during completion
meant they were lost at the end of the completion cycle. So to be safe I
put a 'sleep 5' in __git_list_porcelain_commands() and it only stalled
me once :-)
I see a small problem, but it can be fixed in another patch. git merge
-s <TAB><TAB> the first time when you're not in a git directory will
make git merge -s <TAB><TAB> after never complete correctly even in a
git directory. I guess this become more serious if git isn't in your
path initially and you do git <TAB><TAB> and then git becomes part of
your path and you try again. Here you lose porcelain completion. This is
probably never going to happen though, right?
Plus it seems that __git_all_commands is computed twice if I git
<TAB><TAB> and then git help <TAB><TAB> after. Can that be avoided?
Squashing this on top fixes the two typos you mentioned.
---->8----
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 7088ec7..6817953 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1082,7 +1082,7 @@ _git_help ()
;;
esac
__git_compute_all_commands
- __gitcomp "__git_all_commands
+ __gitcomp "$__git_all_commands
attributes cli core-tutorial cvs-migration
diffcore gitk glossary hooks ignore modules
repository-layout tutorial tutorial-2
@@ -1541,7 +1541,7 @@ _git_config ()
local pfx="${cur%.*}."
cur="${cur#*.}"
__git_compute_all_commands
- __gitcomp "__git_all_commands" "$pfx" "$cur"
+ __gitcomp "$__git_all_commands" "$pfx" "$cur"
return
;;
remote.*.*)
^ permalink raw reply related
* Re: Git in next is broken
From: Eric Raible @ 2009-11-13 20:20 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.2.00.0911131152120.16711@xanadu.home>
Nicolas Pitre <nico <at> fluxnic.net> writes:
> diff --git a/remote.c b/remote.c
> > index 4f9f0cc..6195a58 100644
> > --- a/remote.c
> > +++ b/remote.c
> > @@ -754,6 +754,8 @@ void ref_remove_duplicates(struct ref *ref_map)
> > prev->next = ref_map->next;
> > free(ref_map->peer_ref);
> > free(ref_map);
> > + ref_map = prev; // Keep the same prev.
> > + continue;
> > }
> >
This is one of those example where the comment is essentially useless.
Wouldn't something like "// Skip the freed item" be more useful?
- Eric
^ permalink raw reply
* Re: Warning while cloning remote repository
From: Johan 't Hart @ 2009-11-13 19:34 UTC (permalink / raw)
To: git
In-Reply-To: <117260.55181.qm@web94705.mail.in2.yahoo.com>
Shameem Ahamed schreef:
> Hi,
>
> I ran in to a warning message while cloning a remote repository.
>
> The message is
>
> warning: remote HEAD refers to nonexistent ref, unable to checkout.
>
> After the cloning i couldn't see any remote files. The .git folder is created successfully.
>
try
git checkout -t origin/master
on the clone.. Maybe its a workaround?
^ permalink raw reply
* [StGIT PATCH] allow --cc=myself to work again
From: Alex Chiang @ 2009-11-13 19:27 UTC (permalink / raw)
To: catalin.marinas; +Cc: Andrew Patterson, scameron, git
commit cd74a041 filtered duplicate email addresses, especially
with the --auto option.
However, it broke a common practice of cc'ing yourself on a
patch. [nb, I don't do this myself, but there are several legit
reasons]
This patch allows you to do something like:
stg mail --to=<someaddr> --cc=<myaddr> --auto <patch>
Under my testing, with <myaddr> in the Signed-off-by: path:
- we still do not send duplicates to <myaddr> (cd74a041 still holds)
- we do not Cc: <myaddr> unless explicitly specified with --cc=
I believe this is the behaviour that closest matches what a user
actually wants without sending multiple, annoying Cc:'s.
Signed-off-by: Alex Chiang <achiang@hp.com>
---
diff --git a/stgit/commands/mail.py b/stgit/commands/mail.py
index abd42e4..4b0ac7b 100644
--- a/stgit/commands/mail.py
+++ b/stgit/commands/mail.py
@@ -272,9 +272,8 @@ def __build_address_headers(msg, options, extra_cc = []):
cc_set = __update_header('Cc', cc_addr, to_set)
bcc_set = __update_header('Bcc', bcc_addr, to_set.union(cc_set))
- # --auto generated addresses, don't include the sender
- from_set = __update_header('From')
- __update_header('Cc', extra_cc_addr, to_set.union(bcc_set).union(from_set))
+ # --auto generated addresses
+ __update_header('Cc', extra_cc_addr, to_set.union(bcc_set))
# update other address headers
__update_header('Reply-To')
@@ -528,8 +527,11 @@ def __build_message(tmpl, patch, patch_nr, total_nr, msg_id, ref_id, options):
except Exception, ex:
raise CmdException, 'template parsing error: %s' % str(ex)
+ # Get signers, but filter sender from list. Results in:
+ # do not auto-cc the sender unless explicitly specified with --cc=
if options.auto:
extra_cc = __get_signers_list(descr)
+ extra_cc = list(set.symmetric_difference(set([sender]), set(extra_cc)))
else:
extra_cc = []
^ permalink raw reply related
* cherry-pick vs submodule, conflicts
From: Jeff Epler @ 2009-11-13 18:05 UTC (permalink / raw)
To: git
A fellow git user of mine encountered an unexpected problem cherry-
picking from one branch to another. The conflict was 'added by us: sub'
and I created a small program that leads to the same message.
#!/bin/bash
# This script demonstrates that it doesn't work to cherry-pick when some (not
# even touched) path is a submodule in HEAD but a regular subdirectory in the
# branch being picked from.
#
# Furthermore, when using 'git mergetool', the (desired?) action 'c'
# gives the error "fatal: unable to stat 'sub': No such file or directory".
#
# The behavior is essentially the same on
# git version 1.6.3.3
# git version 1.6.5.rc1.49.ge970
#
# maybe this is related to
# http://kerneltrap.org/mailarchive/git/2007/7/7/250935
# but the case must be extended to cover submodules?
set -e
BASEDIR=$(pwd)
rm -rf main sub &&
mkdir sub main &&
(cd sub && git init && touch y && git add y && git commit -my) &&
# make a submodule
cd ../main &&
git init &&
touch x; git add x &&
git commit -mx && # initial commit
git branch b &&
mkdir sub && # on master, make sub a subdir
touch sub/y; git add sub/y &&
git commit -my &&
echo 1 > x &&
git commit -mx1 -a && # and create a second commit
CHERRY=$(git rev-parse HEAD) && # which is a tasty cherry
git checkout b &&
git submodule add file://$BASEDIR/sub sub &&
git submodule update &&
git commit -my && # on brach, make sub a submodule
! git cherry-pick $CHERRY && # pull second commit from master
git status # what happened?
^ permalink raw reply
* Re: Git in next is broken
From: Nicolas Pitre @ 2009-11-13 16:54 UTC (permalink / raw)
To: Julian Phillips; +Cc: René Scharfe, git
In-Reply-To: <alpine.LNX.2.00.0911130910150.17726@reaper.quantumfyre.co.uk>
On Fri, 13 Nov 2009, Julian Phillips wrote:
> On Thu, 12 Nov 2009, Nicolas Pitre wrote:
>
> > Without the "ref_map = next" there is no change: glibc still complains
> > about corruption and abort the execution. With the "ref_map = next"
> > then git simply segfaults.
>
> I was half right about "ref_map = next", I had forgotten about setting prev in
> the for(...). For me, the following fixes it on MacOS (I don't have time to
> test on Linux right now):
>
> diff --git a/remote.c b/remote.c
> index 4f9f0cc..6195a58 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -754,6 +754,8 @@ void ref_remove_duplicates(struct ref *ref_map)
> prev->next = ref_map->next;
> free(ref_map->peer_ref);
> free(ref_map);
> + ref_map = prev; // Keep the same prev.
> + continue;
> }
>
> item = string_list_insert(ref_map->peer_ref->name, &refs);
Yep, this fixes it for me on Linux too. Please resend to Junio with my
ACK.
Nicolas
^ permalink raw reply
* Re: error while cloning a remote repository
From: Shawn O. Pearce @ 2009-11-13 15:10 UTC (permalink / raw)
To: Shameem Ahamed; +Cc: git
In-Reply-To: <811075.82054.qm@web94704.mail.in2.yahoo.com>
Shameem Ahamed <shameem.ahamed@yahoo.com> wrote:
> I ran in to a warning message while cloning a remote repository.
...
> warning: remote HEAD refers to nonexistent ref, unable to checkout.
>
Contact the repository owner and let them know. The error occurs because
their HEAD symbolic reference points to a branch that does not exist. They
can fix this by running `git symbolic-ref HEAD refs/heads/$branch` to point
at the correct default branch for their repository.
> After the cloning i couldn't see any remote files. The .git folder
> is created successfully.
I think you may be able to do:
$ git branch -r
$ git reset --hard $branch
where $branch is one of the origin/ names printed by branch -r.
Because the source repository didn't tell us what default branch name
you should use (it has a bad HEAD) I can't suggest what name, you'll
have to figure it out on your own, or ask the repository owner.
--
Shawn.
^ permalink raw reply
* Re: send an email with logs after push
From: michele @ 2009-11-13 14:18 UTC (permalink / raw)
To: git
In-Reply-To: <vpqocn6iu4l.fsf@bauges.imag.fr>
On Fri, 13 Nov 2009 11:42 +0100, "Matthieu Moy"
<Matthieu.Moy@grenoble-inp.fr> wrote:
> See also post-receive-email in git/contrib/hooks/, probably installed
Thank you for your suggestions. I've added a new post-receive hook using
the code from post-receive-email. The hook is executable and is placed
in the remote directory. The push is made from my local pc via ssh, but
after the push nothing seems to happen: the hook is not executed on the
server side. It does not depend from the code inside the hook: even the
unique "touch foobar" command does not work. Where do I have to look?
Thanks
^ permalink raw reply
* Re: Bug: "git svn clone" does not honor svn.authorsfile setting
From: Curt Sampson @ 2009-11-13 14:06 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <4AFA3D04.3050109@vilain.net>
On 2009-11-11 17:26 +1300 (Wed), Sam Vilain wrote:
> Does moving the line:
>
> command_oneline('config', 'svn.authorsfile', $_authors) if $_authors;
>
> Immediately prior to the "fetch_all" line before it fix the problem? It
> looks strange for it to set it afterwards...
That looks plausible to me, having had a quick look at the source, but
keep in mind I've already spent about 45 minutes debugging this problem
and figuring out how to file a bug report. I don't really have the time
at the moment to learn how to build and test new versions of git, unless
someone wants to walk me through it. I expect it would take rather less
time for someone in the know just to do the test.
cjs
--
Curt Sampson <cjs@starling-software.com> +81 90 7737 2974
Functional programming in all senses of the word:
http://www.starling-software.com
^ permalink raw reply
* Re: Bug: "git svn clone" does not honor svn.authorsfile setting
From: Curt Sampson @ 2009-11-13 14:02 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0911100524p2cf3f2ebp698ecb50fc53f8e9@mail.gmail.com>
On 2009-11-10 14:24 +0100 (Tue), Sverre Rabbelier wrote:
> Please don't. It is custom on the git list to always keep those who
> are involved in the conversation cc-ed, adding a Reply-to makes this
> difficult.
If you're running your list without munging Reply-to, congratulations
to you. I'll avoid it from now on on this list. However, it's the case
that for many, many lists out there, if I did not include myself in a
Reply-to, the list would set the Reply-to to the list, and most MUAs
would automatically exclude me from the reply.
cjs
--
Curt Sampson <cjs@starling-software.com> +81 90 7737 2974
Functional programming in all senses of the word:
http://www.starling-software.com
^ permalink raw reply
* Re: git status internals and line endings
From: Marc Strapetz @ 2009-11-13 11:01 UTC (permalink / raw)
To: kusmabite; +Cc: Jeff King, git
In-Reply-To: <40aa078e0911130104v6acdecedxf629c5ef35a62740@mail.gmail.com>
> In order to make changes to core.autocrlf effective, you need to
> delete .git/index and perform a hard reset:
> $ rm .git/index
> $ git reset --hard
This solved my problem. Thank you!
--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
Erik Faye-Lund wrote:
> On Fri, Nov 13, 2009 at 9:08 AM, Marc Strapetz
> <marc.strapetz@syntevo.com> wrote:
>>> Sounds like the core.autocrlf setting (see "git help config"), which I
>>> believe is set by default on Windows.
>> I have checked both $GIT_DIR/config and ~/.gitconfig and autocrlf has
>> not been set. I have then set autocrlf = false for the Windows
>> repository and still the file didn't show up as modified. On Linux, I've
>> added autocrlf = true (resp. autocrlf = input) for the repository and
>> still the file shows up as modified. Not that I don't like this
>> behavior, but I don't understand it :) Windows Git version is 1.6.5.1,
>> Linux version is 1.6.3.3.
>>
>
> In order to make changes to core.autocrlf effective, you need to
> delete .git/index and perform a hard reset:
> $ rm .git/index
> $ git reset --hard
>
> Did you do this before checking if the files were modified?
>
^ permalink raw reply
* Re: send an email with logs after push
From: Matthieu Moy @ 2009-11-13 10:42 UTC (permalink / raw)
To: Pascal Obry; +Cc: michele, git
In-Reply-To: <a2633edd0911130055y199955a2n93888b03c5f9b985@mail.gmail.com>
Pascal Obry <pascal@obry.net> writes:
> Michele,
>
>> Do you have any suggestion to implement this?
>
> I'm doing that. In the post-receive hook I have:
See also post-receive-email in git/contrib/hooks/, probably installed
somewhere like by your distro. In the .git/hooks/post-receive.sample
installed by default by "git init", this should be a matter of
uncommenting one line.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Warning while cloning remote repository
From: Shameem Ahamed @ 2009-11-13 10:20 UTC (permalink / raw)
To: git
Hi,
I ran in to a warning message while cloning a remote repository.
The message is
warning: remote HEAD refers to nonexistent ref, unable to checkout.
After the cloning i couldn't see any remote files. The .git folder is created successfully.
Regards,
Shameem
^ permalink raw reply
* Re: [PATCH] Speed up bash completion loading
From: Jonathan Nieder @ 2009-11-13 10:29 UTC (permalink / raw)
To: Stephen Boyd
Cc: Kirill Smelkov, Sverre Rabbelier, Junio C Hamano, Shawn O. Pearce,
git
In-Reply-To: <20091113090343.GA5355@progeny.tock>
Jonathan Nieder wrote:
> @@ -1545,7 +1540,8 @@ _git_config ()
> pager.*)
> local pfx="${cur%.*}."
> cur="${cur#*.}"
> - __gitcomp "$(__git_all_commands)" "$pfx" "$cur"
> + __git_compute_all_commands
> + __gitcomp "__git_all_commands" "$pfx" "$cur"
> return
> ;;
> remote.*.*)
s/__git_all_commands/\$__git_all_commands/
Yikes. Next patch I’ll let sit for a day.
Good night,
Jonathan
^ permalink raw reply
* git am and CRLF files
From: Stefan Naewe @ 2009-11-13 9:44 UTC (permalink / raw)
To: git
Hi there.
I have:
$ git version
git version 1.6.5.1.1367.gcd48
$ git config --get core.autocrlf
false
A repository with some UNIX (LF) and some Windows (CRLF) files.
(and no: I will not change the files. My editors handle CRLF and LF correctly)
My problem:
'git am' can't handle changes in CRLF files because the patch
gets converted (by git mailsplit) to contain only LF.
Which is wrong IMHO.
git-am on my msysgit version looks like this (lines: 214++)
<---------->
split_patches () {
case "$patch_format" in
mbox)
case "$rebasing" in
'')
keep_cr= ;;
?*)
keep_cr=--keep-cr ;;
esac
git mailsplit -d"$prec" -o"$dotest" -b $keep_cr -- "$@" > "$dotest/last" ||
clean_abort
;;
<---------->
The '--keep-cr' flags is passed to git mailsplit when git am is in 'rebasing' mode.
By looking through git-am I found that I can pass "--rebasing" to git am to get my
patch applied correctly.
But why is git am behaving that way ?
Puzzled,
Stefan
--
----------------------------------------------------------------
/dev/random says: I'm dangerous when I know what I'm doing.
^ permalink raw reply
* Re: git status internals and line endings
From: Peter Krefting @ 2009-11-13 9:40 UTC (permalink / raw)
To: Marc Strapetz; +Cc: Jeff King, Git Mailing List
In-Reply-To: <4AFD1414.6030907@syntevo.com>
Marc Strapetz:
>> Sounds like the core.autocrlf setting (see "git help config"), which I
>> believe is set by default on Windows.
> I have checked both $GIT_DIR/config and ~/.gitconfig and autocrlf has not
> been set.
It is usually set by default by the installer. Look at
%INSTALLDIR%\etc\gitconfig, it should contain
[core]
autoCRLF = true
among other things.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Git in next is broken
From: Julian Phillips @ 2009-11-13 9:14 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: René Scharfe, git
In-Reply-To: <alpine.LFD.2.00.0911122345450.16711@xanadu.home>
On Thu, 12 Nov 2009, Nicolas Pitre wrote:
> On Thu, 12 Nov 2009, Julian Phillips wrote:
>
>> On Thu, 12 Nov 2009, Ren? Scharfe wrote:
>>
>>> Nicolas Pitre schrieb:
>>>> Simply issuing a "git fetch" in my copy of git.git makes glibc complain
>>>> with this:
>>>>
>>>> *** glibc detected *** git: corrupted double-linked list:
>>>> 0x0000000000974180 ***
>>> Can't reproduce because I don't know how to create duplicate refs, but does
>>> the following help?
>
> Nope.
>
>>> remote.c | 2 ++
>>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/remote.c b/remote.c
>>> index 4f9f0cc..10cc985 100644
>>> --- a/remote.c
>>> +++ b/remote.c
>>> @@ -754,6 +754,8 @@ void ref_remove_duplicates(struct ref *ref_map)
>>> prev->next = ref_map->next;
>>> free(ref_map->peer_ref);
>>> free(ref_map);
>>> + ref_map = next;
>>
>> You don't need this line (this is taken care of in the for(...)).
>>
>>> + continue;
>>
>> Ack. This one however, you do need. Good catch.
>
> Without the "ref_map = next" there is no change: glibc still complains
> about corruption and abort the execution. With the "ref_map = next"
> then git simply segfaults.
>
> I simply have zero time to investigate the issue myself now
> unfortunately.
I was half right about "ref_map = next", I had forgotten about setting
prev in the for(...). For me, the following fixes it on MacOS (I don't
have time to test on Linux right now):
diff --git a/remote.c b/remote.c
index 4f9f0cc..6195a58 100644
--- a/remote.c
+++ b/remote.c
@@ -754,6 +754,8 @@ void ref_remove_duplicates(struct ref *ref_map)
prev->next = ref_map->next;
free(ref_map->peer_ref);
free(ref_map);
+ ref_map = prev; // Keep the same prev.
+ continue;
}
item = string_list_insert(ref_map->peer_ref->name, &refs);
--
Julian
---
C'est magnifique, mais ce n'est pas l'Informatique.
-- Bosquet [on seeing the IBM 4341]
^ permalink raw reply related
* Re: git status internals and line endings
From: Erik Faye-Lund @ 2009-11-13 9:04 UTC (permalink / raw)
To: Marc Strapetz; +Cc: Jeff King, git
In-Reply-To: <4AFD1414.6030907@syntevo.com>
On Fri, Nov 13, 2009 at 9:08 AM, Marc Strapetz
<marc.strapetz@syntevo.com> wrote:
>> Sounds like the core.autocrlf setting (see "git help config"), which I
>> believe is set by default on Windows.
>
> I have checked both $GIT_DIR/config and ~/.gitconfig and autocrlf has
> not been set. I have then set autocrlf = false for the Windows
> repository and still the file didn't show up as modified. On Linux, I've
> added autocrlf = true (resp. autocrlf = input) for the repository and
> still the file shows up as modified. Not that I don't like this
> behavior, but I don't understand it :) Windows Git version is 1.6.5.1,
> Linux version is 1.6.3.3.
>
In order to make changes to core.autocrlf effective, you need to
delete .git/index and perform a hard reset:
$ rm .git/index
$ git reset --hard
Did you do this before checking if the files were modified?
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: BUG: git rebase -i -p silently looses commits
From: Johannes Schindelin @ 2009-11-13 9:07 UTC (permalink / raw)
To: Greg Price; +Cc: Constantine Plotnikov, git
In-Reply-To: <1ac2d430911120957gecb6a27k4166016ef8498eab@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3910 bytes --]
Hi Greg,
On Thu, 12 Nov 2009, Greg Price wrote:
> On Wed, Nov 11, 2009 at 12:32 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > That is very interesting!
> >
> > However, for rebase-i-p to have a chance to be accepted, I think a few
> > things are necessary still (this is all from memory, so please take
> > everything with a grain of salt):
>
> Great, this is helpful, and it overlaps with my existing to-do list. I
> have a couple of questions.
>
> > - rework the mark stuff so that 'todo' works properly, and then change
> > the system to use ':<name>' style bookmarks.
>
> This is the biggest change I was going to suggest! Glad we're on the
> same page. To be clear, what I want to do here is
> - add a 'mark' command
> - emit 'mark' commands in the TODO generation for the target of each
> 'goto', and use them.
> Is that also what you had in mind?
Almost. I called it "bookmark" so that the abbreviated command does not
clash with "merge". And there are possible goto targets you have never
been at:
- A - B - C
\ /
D
If C is your HEAD, and you "rebase -i -p B", before cherry-picking D, you
have to "goto A".
So I strongly advise against trying to give all goto targets a name, just
the obvious one: onto (you do not need upstream, as all the commits which
have upstream as parent are supposed to be applied on top of onto anyway).
> > - fix that nasty bug which makes one revision not pass the tests (I
> > forgot which one, but it should be in the TODOs)
>
> Hmm. I see one TODO comment in your patches, and it doesn't sound like
> this. Is there a TODO somewhere else that I'm missing? Alternatively, I
> can always end up just running the tests on all the revisions and find
> out.
It should be in one commit message (something like WIP...).
> > - add proper handling for the case when a patch has been applied in
> > upstream already, but was not correctly identified as that by
> > --cherry-pick (well, this TODO is actually not really related to
> > rebase -i -p, but something I deeply care about)
>
> Hmm. I'll have to think about what the behavior could be here.
At the moment, it gives you the status (which is multiple pages long here,
due to untracked files that I am unwilling to move elsewhere) and then
"nothing to commit". You do not even see which commit was to be applied.
My plan was to detect that condition in the error case and _not_ output
what the cherry-pick printed, but a much more helpful message along the
lines
It appears "Bla bli blu" was already applied
For the exact message, I am sure all kinds of painters will want to help
you.
> For context, I think the issue you're referring to is that sometimes
> the patch-id changed, so that --cherry-pick doesn't identify the
> patch;
Correct.
> and then some later upstream patch has touched the same code again, so
> that there's a conflict when we try to apply the older patch.
No, that is not what I mean. I mean when more than one context line
changes. Then patch-ids will differ, but a 3-way merge will still succeed
in finding that there was actually no change.
> > Unfortunately, I am getting more and more deprived of Git time budget
> > these days, so that I cannot seem to find a few hours to at least
> > restart my efforts.
>
> Understood. I may have some time to work on this soon, we'll see. I
> think the priorities will be to
> - add "mark" as you say
> - add the "pause" command, to make it possible to amend a merge
> - write tests
> - fix a couple of bugs, track down the one you mentioned
> - write documentation
>
> At that point, and with the reordering you suggested, I think it will
> be ready to submit for inclusion.
>
> Further comments, and bug reports from anyone else using the
> development version, are welcome.
Thanks,
Dscho
P.S.: I am mostly off-line until Monday.
^ permalink raw reply
* Re: send an email with logs after push
From: Pascal Obry @ 2009-11-13 8:55 UTC (permalink / raw)
To: michele; +Cc: git
In-Reply-To: <1258101999.17624.1345023113@webmail.messagingengine.com>
Michele,
> Do you have any suggestion to implement this?
I'm doing that. In the post-receive hook I have:
<<
while read oldrev newrev ref; do
trac_post_receive_record_log "$oldrev" "$newrev" "$ref" gtest
send_mail_post_receive "$oldrev" "$newrev" "$ref" gtest \
pascal@obry.net another@here.com
done
>>
the trac_post_receive_record_log is to add log into trac bug tracker.
the send_mail_post_receive is to send a message to the recipients
listed. The 4th parameter is the name of the project.
The send_mail_post_receive function is:
function send_mail_post_receive() {
oldrev=$1
newrev=$2
ref=$3
MODULE="$4"
git log -p $oldrev..$newrev > $log
cat $log | mail -s "[$MODULE] $ref $oldrev..$newrev" $5 $6 $7 $8 $9
rm -fr $root
}
You'll find a set of hook helper routines there:
git clone http://repo.or.cz/r/git-scripts.git
Hope this helps!
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH] Speed up bash completion loading
From: Jonathan Nieder @ 2009-11-13 9:03 UTC (permalink / raw)
To: Stephen Boyd
Cc: Kirill Smelkov, Sverre Rabbelier, Junio C Hamano, Shawn O. Pearce,
git
In-Reply-To: <20091113085028.GA4804@progeny.tock>
On my slow laptop (P3 600MHz), system-wide bash completions take
too much time to load (> 2s), and a significant fraction of this
time is spent loading git-completion.bash:
$ time bash -c ". ./git-completion.bash" # hot cache, before this patch
real 0m0.509s
user 0m0.310s
sys 0m0.180s
Kirill noticed that most of the time is spent warming up
merge_strategy, all_command & porcelain_command caches.
Since git is not used in each and every interactive xterm, it
seems best to load completion support with cold caches, and then
load each needed thing lazily. This has most of the speed
advantage of pre-generating everything at build time, without the
complication of figuring out at build time what commands will be
available at run time.
The result is that loading completion is significantly faster
now:
$ time bash -c ". ./git-completion.bash" # cold cache, after this patch
real 0m0.171s
user 0m0.060s
sys 0m0.040s
Suggested-by: Kirill Smelkov <kirr@mns.spb.ru>
Cc: Shawn O. Pearce <spearce@spearce.org>
Cc: Stephen Boyd <bebarino@gmail.com>
Cc: Sverre Rabbelier <srabbelier@gmail.com>
Cc: Junio C Hamano <junio@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Jonathan Nieder wrote:
> Stephen Boyd wrote:
>> Ah ok. I think this proves even more that pregenerating the
>> completion is a bad idea. With dynamic population we don't have
>> these problems and it only takes 250ms more to load on a P3
>> 700Mhz.
>
> Hmm, 250 ms is a lot.
Here’s the real patch. Sorry about that.
Jonathan
contrib/completion/git-completion.bash | 67 +++++++++++++++----------------
1 files changed, 32 insertions(+), 35 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index e3ddecc..7088ec7 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -21,13 +21,7 @@
# 2) Added the following line to your .bashrc:
# source ~/.git-completion.sh
#
-# 3) You may want to make sure the git executable is available
-# in your PATH before this script is sourced, as some caching
-# is performed while the script loads. If git isn't found
-# at source time then all lookups will be done on demand,
-# which may be slightly slower.
-#
-# 4) Consider changing your PS1 to also show the current branch:
+# 3) Consider changing your PS1 to also show the current branch:
# PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '
#
# The argument to __git_ps1 will be displayed only if you
@@ -324,12 +318,8 @@ __git_remotes ()
done
}
-__git_merge_strategies ()
+__git_list_merge_strategies ()
{
- if [ -n "${__git_merge_strategylist-}" ]; then
- echo "$__git_merge_strategylist"
- return
- fi
git merge -s help 2>&1 |
sed -n -e '/[Aa]vailable strategies are: /,/^$/{
s/\.$//
@@ -339,8 +329,11 @@ __git_merge_strategies ()
p
}'
}
-__git_merge_strategylist=
-__git_merge_strategylist=$(__git_merge_strategies 2>/dev/null)
+
+__git_compute_merge_strategies ()
+{
+ : ${__git_merge_strategies=$(__git_list_merge_strategies)}
+}
__git_complete_file ()
{
@@ -474,27 +467,24 @@ __git_complete_remote_or_refspec ()
__git_complete_strategy ()
{
+ __git_compute_merge_strategies
case "${COMP_WORDS[COMP_CWORD-1]}" in
-s|--strategy)
- __gitcomp "$(__git_merge_strategies)"
+ __gitcomp "$__git_merge_strategies"
return 0
esac
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--strategy=*)
- __gitcomp "$(__git_merge_strategies)" "" "${cur##--strategy=}"
+ __gitcomp "$__git_merge_strategies" "" "${cur##--strategy=}"
return 0
;;
esac
return 1
}
-__git_all_commands ()
+__git_list_all_commands ()
{
- if [ -n "${__git_all_commandlist-}" ]; then
- echo "$__git_all_commandlist"
- return
- fi
local i IFS=" "$'\n'
for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
do
@@ -504,17 +494,17 @@ __git_all_commands ()
esac
done
}
-__git_all_commandlist=
-__git_all_commandlist="$(__git_all_commands 2>/dev/null)"
-__git_porcelain_commands ()
+__git_compute_all_commands ()
+{
+ : ${__git_all_commands=$(__git_list_all_commands)}
+}
+
+__git_list_porcelain_commands ()
{
- if [ -n "${__git_porcelain_commandlist-}" ]; then
- echo "$__git_porcelain_commandlist"
- return
- fi
local i IFS=" "$'\n'
- for i in "help" $(__git_all_commands)
+ __git_compute_all_commands
+ for i in "help" $__git_all_commands
do
case $i in
*--*) : helper pattern;;
@@ -595,8 +585,11 @@ __git_porcelain_commands ()
esac
done
}
-__git_porcelain_commandlist=
-__git_porcelain_commandlist="$(__git_porcelain_commands 2>/dev/null)"
+
+__git_compute_porcelain_commands ()
+{
+ : ${__git_porcelain_commands=$(__git_list_porcelain_commands)}
+}
__git_aliases ()
{
@@ -1088,7 +1081,8 @@ _git_help ()
return
;;
esac
- __gitcomp "$(__git_all_commands)
+ __git_compute_all_commands
+ __gitcomp "__git_all_commands
attributes cli core-tutorial cvs-migration
diffcore gitk glossary hooks ignore modules
repository-layout tutorial tutorial-2
@@ -1444,7 +1438,8 @@ _git_config ()
return
;;
pull.twohead|pull.octopus)
- __gitcomp "$(__git_merge_strategies)"
+ __git_compute_merge_strategies
+ __gitcomp "$__git_merge_strategies"
return
;;
color.branch|color.diff|color.interactive|\
@@ -1545,7 +1540,8 @@ _git_config ()
pager.*)
local pfx="${cur%.*}."
cur="${cur#*.}"
- __gitcomp "$(__git_all_commands)" "$pfx" "$cur"
+ __git_compute_all_commands
+ __gitcomp "__git_all_commands" "$pfx" "$cur"
return
;;
remote.*.*)
@@ -2142,7 +2138,8 @@ _git ()
--help
"
;;
- *) __gitcomp "$(__git_porcelain_commands) $(__git_aliases)" ;;
+ *) __git_compute_porcelain_commands
+ __gitcomp "$__git_porcelain_commands $(__git_aliases)" ;;
esac
return
fi
--
1.6.5.2
^ permalink raw reply related
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