* [PATCH] git-add.txt: fix formatting of --patch section
From: Stephen Boyd @ 2009-11-14 1:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Extra paragraphs should be prefixed with a plus sign.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
Documentation/git-add.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 45ebf87..e93e606 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -76,10 +76,10 @@ OPTIONS
work tree and add them to the index. This gives the user a chance
to review the difference before adding modified contents to the
index.
-
- This effectively runs ``add --interactive``, but bypasses the
- initial command menu and directly jumps to `patch` subcommand.
- See ``Interactive mode'' for details.
++
+This effectively runs `add --interactive`, but bypasses the
+initial command menu and directly jumps to the `patch` subcommand.
+See ``Interactive mode'' for details.
-e, \--edit::
Open the diff vs. the index in an editor and let the user
--
1.6.5.2.155.gbb47
^ permalink raw reply related
* Re: Resolving a merge conflict with git-svn
From: Daniele Segato @ 2009-11-14 0:58 UTC (permalink / raw)
To: Jens Kubieziel; +Cc: git
In-Reply-To: <76ee5f990911131630k41a91f70n5e717befb7693463@mail.gmail.com>
Il giorno sab, 14/11/2009 alle 01.30 +0100, Jens Kubieziel ha scritto:
> Hi,
>
> I recently came across a big conflict. Someone used Subversion and
> made a complete wrong commit. I did a 'git svn rebase' at some point
> and ran into the conflict. My goal at this point was to remove the
> wrong commit, but I found no way how to do it (git-revert needs a
> clean tree; git stash brought [fatal: git-write-tree: error building
> trees,Cannot save the current state]). What way would suggest to
> remove that wrong made commit and continue with the rebase?
I don't know if this could help but I tell you what I would do.
I would abort the conflicting rebase
"backing up" my branch by:
git checkout mybranch
git checkout -b mybranchBackup
then I would do a git reset --hard <last-committed-svn-commit>
at this point a:
git svn rebase
shouldn't give conflict since it should be a fast forward.
Then you should have two branch:
mybranch: which is SVN-up-to-date but has no one of your modification
mybranchBackup: which has an old SVN before the wrong commit but with
all your modifications...
at this point you can use git revert to revert the wrong commit into
your "mybranch".
and then you can cherry-pick all your modification from mybranchBackup
may be you could also been able to rebase upon it....
but I would do an interactive rebase to "see" what's going to do and
being able to control it
like:
git checkout mybranchBackup
git rebase -i mybranch
^ permalink raw reply
* Resolving a merge conflict with git-svn
From: Jens Kubieziel @ 2009-11-14 0:30 UTC (permalink / raw)
To: git
Hi,
I recently came across a big conflict. Someone used Subversion and
made a complete wrong commit. I did a 'git svn rebase' at some point
and ran into the conflict. My goal at this point was to remove the
wrong commit, but I found no way how to do it (git-revert needs a
clean tree; git stash brought [fatal: git-write-tree: error building
trees,Cannot save the current state]). What way would suggest to
remove that wrong made commit and continue with the rebase?
Thanks for any hints.
^ permalink raw reply
* GNU patch: new 2.6 release
From: Andreas Gruenbacher @ 2009-11-14 0:09 UTC (permalink / raw)
To: git
I am pleased to announce my first release of GNU patch,
available by anonymous FTP from:
ftp://ftp.gnu.org/gnu/patch/
The last release dates back to June 2004 with version 2.5.9. A new Savannah
project has been created with the new code repository and the bug-patch
mailing list archive at:
http://savannah.gnu.org/projects/patch
A lot of changes have accumulated since version 2.5.9. The following user
visible changes have been made:
* A regression test suite has been added ("make check").
* A --merge option has been added which will merge a patch file into
the original files similar to merge(1). See the patch(1) manual page for
documentation.
* Unless a file name has been specified on the command line, look only
for file names in the patch until one has been found. This prevents
patch from tripping over garbage that isn't a patch. When conforming
to POSIX, this behavior is turned off and patch will ask for a
file name when none is found.
* All reject files have file name headers now, which allows them to be used as
regular patches.
* When a patch file modifies the same file more than once, patch makes
sure it backs up the original version of the file rather than any
intermediary versions.
* In the above situation, if there are rejects in more than one of those
patches, they all go into the same reject file.
* When the file to be patched is specified on the command line, all patches
are applied to that file. (Previously, the first patch was applied to the
file specified on the command line, and the names of additional files to
patch were taken from header lines in the patch file.)
* The -r option now works correctly even if there are rejects in more than
one file. Use the - argument to discard rejects.
* Rejected hunks come out in unified diff format if the input patch was of
that format, otherwise in ordinary context diff form. Use the
--reject-format option to enforce either "context" or "unified" format.
Timestamps and the "diff -p" (--show-c-function) output are preserved.
Changed lines in context format reject files are correctly indicated
with '!' markers as the format defines. Added and removed lines are
still marked with '+' and '-', respectively.
* The file permissions of reject files are no longer set to match the files
they modify. Instead, they retain the default permissions. This is
consistent with reject files produced with the -r option.
* The --binary option disables the heuristic for stripping CRs from
line endings in patches. This allows to preserve CRs even in mangled
patches, or in patches generated on non-POSIX systems and without the
--binary option.
* Backup files for non-existing files are now created with default
permissions rather than with mode 0: backup files with mode 0 were
causing problems with applications which do not expect unreadable
files.
* The -B, -Y, and -z options (--prefix, --basename-prefix, --suffix) now
imply the simple version control mode, and can be combined.
* Patch rejects more malformed normal format commands and checks for trailing
garbage. It now recognizes ed commands without addresses.
* Change the default value of PATCH_GET to 0. (Previously, the default was 0
under POSIXLY_CORRECT and negative otherwise; this is causing problems
particularly with Perforce.)
* Handle missing timestamps better.
Please email bugs or suggestions to <bug-patch@gnu.org>. (Check the Savannah
project's bug tracker for a list of known issues.)
Thanks,
Andreas
^ permalink raw reply
* Re: [PATCH 1/3] gitweb: Refactor 'log' action generation, adding git_log_body()
From: Jakub Narebski @ 2009-11-13 23:59 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20091114081050.6117@nanako3.lavabit.com>
On Sat, 14 Nov 2009, Nanako Shiraishi wrote:
> Quoting Jakub Narebski <jnareb@gmail.com>
>
> > Put the main part of 'log' view generation into git_log_body,
> > similarly how it is done for 'shortlog' and 'history' views (and
> > also for 'tags' and 'heads' views).
> >
> > This is preparation for extracting common code between 'log',
> > 'shortlog' and 'history' actions.
> >
> > Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> > ---
> > This is pure refactoring: output should change.
>
> Did you mean "should not change"?
Yes, of course, it should be "output should not change" (as opposed
to later patches, which unify not only code but some of looks).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: Nanako Shiraishi @ 2009-11-13 23:10 UTC (permalink / raw)
To: Raman Gupta; +Cc: Nanako Shiraishi, git, trast, gitster
In-Reply-To: <4AFDE421.5050307@fastmail.fm>
Quoting Raman Gupta <rocketraman@fastmail.fm>
> Nanako Shiraishi wrote:
>> .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.
>
> I noticed you removed the discussion I added about the situation in
> which maint will *not* be a subset of master i.e. when the user has
> cherry-picked commits from other branches. This type of cherry-pick is
> described as a valid operation, though one to generally be avoided
> earlier in the man page. If we tell users that the occasional
> cherry-pick to maint is ok, then shouldn't we explain how that affects
> the release process?
It is irrelevant that you can cherry-pick to 'maint'.
You can, and Junio does, cherry-pick some commits from master to
maint from time to time. But even if you have such cherry-picked
commits on the maintenance branch, the result, with zero or more
other maintenance commits on top, is always merged back to the
master branch (you can look at "gitk origin/maint origin/master"
to see yourself).
So when Junio tags the release from the tip of the master branch,
it is a superset of the maintenace branch; it is irrelevant if
maint has some commits that are cherry-picked from master.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH 1/3] gitweb: Refactor 'log' action generation, adding git_log_body()
From: Nanako Shiraishi @ 2009-11-13 23:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <1258074134-27011-2-git-send-email-jnareb@gmail.com>
Quoting Jakub Narebski <jnareb@gmail.com>
> Put the main part of 'log' view generation into git_log_body,
> similarly how it is done for 'shortlog' and 'history' views (and
> also for 'tags' and 'heads' views).
>
> This is preparation for extracting common code between 'log',
> 'shortlog' and 'history' actions.
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> This is pure refactoring: output should change.
Did you mean "should not change"?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: Raman Gupta @ 2009-11-13 22:56 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, trast, gitster
In-Reply-To: <20091114071946.6117@nanako3.lavabit.com>
Nanako Shiraishi wrote:
> .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.
I noticed you removed the discussion I added about the situation in
which maint will *not* be a subset of master i.e. when the user has
cherry-picked commits from other branches. This type of cherry-pick is
described as a valid operation, though one to generally be avoided
earlier in the man page. If we tell users that the occasional
cherry-pick to maint is ok, then shouldn't we explain how that affects
the release process?
Cheers,
Raman
^ permalink raw reply
* 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
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