* Re: [PATCH 3/7] contrib/subtree: Add --unannotate
From: Junio C Hamano @ 2013-01-08 18:45 UTC (permalink / raw)
To: David A. Greene; +Cc: git, James Nylen
In-Reply-To: <1357646997-28675-4-git-send-email-greened@obbligato.org>
"David A. Greene" <greened@obbligato.org> writes:
> diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt
> index c5bce41..75aa690 100644
> --- a/contrib/subtree/git-subtree.txt
> +++ b/contrib/subtree/git-subtree.txt
> @@ -198,6 +198,21 @@ OPTIONS FOR split
> git subtree tries to make it work anyway, particularly
> if you use --rejoin, but it may not always be effective.
>
> +--unannotate=<annotation>::
> + This option is only valid for the split command.
> +
> + When generating synthetic history, try to remove the prefix
> + <annotation> from each commit message (using bash's "strip
> + shortest match from beginning" command, which supports
> + globbing). This makes sense if you format library commits
> + like "library: Change something or other" when you're working
> + in your project's repository, but you want to remove this
> + prefix when pushing back to the library's upstream repository.
> + (In this case --unannotate='*: ' would work well.)
> +
> + Like --annotate, you need to use the same <annotation>
> + whenever you split, or you may run into problems.
I think this paragraph inherits existing breakage from the beginning
of time, but I do not think the above will format the second and
subsequent paragraphs correctly.
I've applied all seven patches in the series with minor fix-ups, and
will merge it to 'pu'.
Thanks.
^ permalink raw reply
* troublesome branch name in remote repo causes .git/config inconsistency in cloned repo
From: Pavel Pospíšil @ 2013-01-08 18:30 UTC (permalink / raw)
To: git
Hi,
I think I came across a bug. I use git version 1.7.10.4 on Ubuntu
12.10. I haven't tried to find out if it's a known bug.
Reproduction scenario:
1. create a git repo:
$ mkdir -p tmp/bezdek
$ cd tmp/bezdek/
$ echo "*.swp" > .gitignore
$ git init
$ git add .
$ git commit -m "Initial commit"
2. clone the "remote" repo:
$ cd ../..
$ mkdir -p tmp/cloned
$ git clone ../bezdek/
3. create the troublesome branch in the "remote" repo
$ cd ../bezdek
$ git checkout -b
MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek
$ echo "*.bak" >> .gitignore
$ git add .
$ git commit -m "Some changes"
4. pull and checkout to the
MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek
branch in the cloned repo
$ cd ../cloned/bezdek
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = /home/pospispa/tmp/tmp/cloned/../bezdek/
[branch "master"]
remote = origin
merge = refs/heads/master
$ git pull
remote: Counting objects: 5, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 33% (1/3)
Unpacking objects: 66% (2/3)
Unpacking objects: 100% (3/3)
Unpacking objects: 100% (3/3), done.
From /home/pospispa/tmp/tmp/cloned/../bezdek
* [new branch]
MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek
-> origin/MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek
Already up-to-date.
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = /home/pospispa/tmp/tmp/cloned/../bezdek/
[branch "master"]
remote = origin
merge = refs/heads/master
$ git checkout MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek
fatal: bad config file line 12 in .git/config
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = /home/pospispa/tmp/tmp/cloned/../bezdek/
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek"]
remote = origin
I think that the problem may be with the branch name length. I think
that git branch allows to created branches with very long names,
however, such long name are not allowed in .git/config or the git
checkout <very-long-remote-branch-name> has some problems with it.
I recovered from this problem in this way:
1. deleted last two lines in tmp/cloned/bezdek/.git/config file and
deleted index and working tree
$ git reset HEAD *
$ git checkout -- *
2. renamed the troublesome branch in "remote" repo:
$ cd ../../bezdek
$ git branch -m
MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek
MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek
3. pull from "remote" to cloned again
$ cd ../cloned/bezdek
$ git pull
From /home/pospispa/tmp/tmp/cloned/../bezdek
* [new branch]
MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek ->
origin/MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek
Already up-to-date.
$ git branch -r
origin/HEAD -> origin/master
origin/MCRD0106586-CR00023206-Configuration-management-of-MCO-shall-be-integrated-with-AMS-2.0-current-cm-config.xml-file-from-Peter-Bezdek
origin/MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek
origin/master
$ git checkout MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek
Branch MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek
set up to track remote branch
MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek
from origin.
Switched to a new branch
'MCRD0106586-CR00023206-current-cm-config.xml-file-from-Peter-Bezdek'
Best regards,
Pavel Pospisil
^ permalink raw reply
* Re: [PATCH 2/7] contrib/subtree: Use %B for Split Subject/Body
From: Junio C Hamano @ 2013-01-08 18:29 UTC (permalink / raw)
To: David A. Greene; +Cc: git, Techlive Zheng
In-Reply-To: <1357646997-28675-3-git-send-email-greened@obbligato.org>
"David A. Greene" <greened@obbligato.org> writes:
> From: Techlive Zheng <techlivezheng@gmail.com>
>
> Use %B to format the commit message and body to avoid an extra newline
> if a commit only has a subject line.
>
> Signed-off-by: Techlive Zheng <techlivezheng@gmail.com>
>
> Signed-off-by: David A. Greene <greened@obbligato.org>
> ---
This time (only), I'll try to fix them up at my end, but please
check your toolchain, find out where the extra blank line between
S-o-b: lines we see above come from, and fix that, so that I won't
have to do so again.
> contrib/subtree/git-subtree.sh | 6 +++++-
> contrib/subtree/t/t7900-subtree.sh | 15 +++++++++++++++
> 2 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
> index 920c664..5341b36 100755
> --- a/contrib/subtree/git-subtree.sh
> +++ b/contrib/subtree/git-subtree.sh
> @@ -296,7 +296,11 @@ copy_commit()
> # We're going to set some environment vars here, so
> # do it in a subshell to get rid of them safely later
> debug copy_commit "{$1}" "{$2}" "{$3}"
> - git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%s%n%n%b' "$1" |
> + # Use %B rather than %s%n%n%b to handle the special case of a
> + # commit that only has a subject line. We don't want to
> + # introduce a newline after the subject, causing generation of
> + # a new hash.
> + git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%B' "$1" |
The new format template is fine, but I do not think the comment
should be there. It does not give any useful information to people
who are reading the end result of applying this patch and is useful
only in the context of comparing the old and new templates, iow, it
belongs to the commit log message.
> (
> read GIT_AUTHOR_NAME
> read GIT_AUTHOR_EMAIL
> diff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/t7900-subtree.sh
> index 6cf9fb9..3f17f55 100755
> --- a/contrib/subtree/t/t7900-subtree.sh
> +++ b/contrib/subtree/t/t7900-subtree.sh
> @@ -74,6 +74,10 @@ test_expect_success 'add sub1' '
> git branch -m master subproj
> '
>
> +# Save this hash for testing later.
> +
> +subdir_hash=`git rev-parse HEAD`
> +
> test_expect_success 'add sub2' '
> create sub2 &&
> git commit -m "sub2" &&
> @@ -211,6 +215,17 @@ test_expect_success 'check split with --branch' '
> check_equal ''"$(git rev-parse splitbr1)"'' "$spl1"
> '
>
> +test_expect_success 'check hash of split' '
> + spl1=$(git subtree split --prefix subdir) &&
> + undo &&
> + git subtree split --prefix subdir --branch splitbr1test &&
> + check_equal ''"$(git rev-parse splitbr1test)"'' "$spl1"
We'd need to clean up these no-op '' from this, but not doing so in
this patch is perfectly fine (and is even preferred).
> + git checkout splitbr1test &&
> + new_hash=$(git rev-parse HEAD~2) &&
> + git checkout mainline &&
> + check_equal ''"$new_hash"'' "$subdir_hash"
> +'
> +
> test_expect_success 'check split with --branch for an existing branch' '
> spl1=''"$(git subtree split --annotate='"'*'"' --prefix subdir --onto FETCH_HEAD --message "Split & rejoin" --rejoin)"'' &&
> undo &&
Thanks.
^ permalink raw reply
* Re: submodule name and path
From: W. Trevor King @ 2013-01-08 18:29 UTC (permalink / raw)
To: 乙酸鋰; +Cc: git
In-Reply-To: <CAHtLG6TuHtk2P3w70-vUVGkdrv7R3VWyMzkGA4sr=G8xiSuEjA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 921 bytes --]
On Wed, Jan 09, 2013 at 02:17:42AM +0800, 乙酸鋰 wrote:
> In doc, "submodule name" is not clearly mentioned?
> What is the purpose of "submodule name"?
> Must be same as "submodule path"?
> "submodule path" can be repeated, while "submodule name" unique?
The submodule name starts out the same as the submodule path, but the
name stays constant through submodule moves, replacements, etc. The
constant name is useful because out-of-tree configuration (e.g. stuff
in .git/config and .git/modules/) won't have to adjust to submodule
renames (except for core.worktree in .git/modules/*/config).
See:
http://article.gmane.org/gmane.comp.version-control.git/49621
http://article.gmane.org/gmane.comp.version-control.git/206659
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4] git-completion.bash: add support for path completion
From: Manlio Perillo @ 2013-01-08 18:28 UTC (permalink / raw)
To: John Keeping
Cc: Marc Khouzam, Junio C Hamano, git@vger.kernel.org,
szeder@ira.uka.de, felipe.contreras@gmail.com
In-Reply-To: <20130108180518.GO6440@serenity.lan>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 08/01/2013 19:05, John Keeping ha scritto:
> [...]
>>
>> After some searching, I found how this is supposed to be done.
>> It is possible to use the -o filenames option to tell Bash completion
>> that "the compspec generates filenames, so it can perform any
>> filename-specific processing".
>>
>> Unfortunately this option must be passed to the complete builtin
>> command, and we can not do this, since the comspec not always contains
>> filenames.
>
> You should also be able to pass it to 'compopt' during completion in
> order to change the behaviour for only the current completion.
>
Thanks, compopt is what I wanted.
I was reading an old Bash manual (for Bash 3.1), and compopt is only
available starting from Bash 4.0.
I will do some test, being careful to not break the code for Bash < 4.0
and the other supported shells.
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDsZVgACgkQscQJ24LbaUQlAACdGbhOuGICCYFwkRTPJla+3JGT
EcQAoINEGvdwtOz1QFbAA4FqoI3c7VSa
=5Oqw
-----END PGP SIGNATURE-----
^ permalink raw reply
* submodule name and path
From: 乙酸鋰 @ 2013-01-08 18:17 UTC (permalink / raw)
To: git
Hi,
In doc, "submodule name" is not clearly mentioned?
What is the purpose of "submodule name"?
Must be same as "submodule path"?
"submodule path" can be repeated, while "submodule name" unique?
^ permalink raw reply
* Re: [PATCH v4] git-completion.bash: add support for path completion
From: John Keeping @ 2013-01-08 18:05 UTC (permalink / raw)
To: Manlio Perillo
Cc: Marc Khouzam, Junio C Hamano, git@vger.kernel.org,
szeder@ira.uka.de, felipe.contreras@gmail.com
In-Reply-To: <50EC5D41.6030209@gmail.com>
On Tue, Jan 08, 2013 at 06:54:09PM +0100, Manlio Perillo wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Il 05/01/2013 21:23, Marc Khouzam ha scritto:
>> [...]
>> 4- Completion choices include their entire path, which is not what bash does by default. For example:
>>> cd git/contrib
>>> ls completion/git-<tab>
>> git-completion.bash git-completion.tcsh git-completion.zsh git-prompt.sh
>> but
>>> git rm completion/git-<tab>
>> completion/git-completion.bash completion/git-completion.tcsh completion/git-completion.zsh completion/git-prompt.sh
>> notice the extra 'completion/' before each completion. This can get pretty large when completing with
>> many directory prefixes. The current tcsh completion has the same problem which I couldn't fix. However, I am
>> not sure if it can be fixed for bash.
>>
>> I personally don't think this is regression, just an slight annoyance.
>>
>
> After some searching, I found how this is supposed to be done.
> It is possible to use the -o filenames option to tell Bash completion
> that "the compspec generates filenames, so it can perform any
> filename-specific processing".
>
> Unfortunately this option must be passed to the complete builtin
> command, and we can not do this, since the comspec not always contains
> filenames.
You should also be able to pass it to 'compopt' during completion in
order to change the behaviour for only the current completion.
John
^ permalink raw reply
* Re: [PATCH] remote-hg: Fix biridectionality -> bidirectionality typos
From: Junio C Hamano @ 2013-01-08 18:10 UTC (permalink / raw)
To: W. Trevor King
Cc: Felipe Contreras, git, Jeff King, Sverre Rabbelier,
Johannes Schindelin, Ilari Liusvaara, Daniel Barkalow,
Michael J Gruber
In-Reply-To: <20130108175001.GG4662@odin.tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> On Tue, Jan 08, 2013 at 09:32:07AM -0800, Junio C Hamano wrote:
>> Thanks; didn't Documentation/SubmittingPatches ask you not to do PGP
>> multipart but send patches in plain text?
>
> Gah. I need to tell myself to reread that every time I send a patch
> :p.
No need to worry; thanks for a patch---applied to 'maint'.
^ permalink raw reply
* Re: [PATCH v4] git-completion.bash: add support for path completion
From: Manlio Perillo @ 2013-01-08 17:54 UTC (permalink / raw)
To: Marc Khouzam
Cc: Junio C Hamano, git@vger.kernel.org, szeder@ira.uka.de,
felipe.contreras@gmail.com
In-Reply-To: <E59706EF8DB1D147B15BECA3322E4BDC0681FA@eusaamb103.ericsson.se>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 05/01/2013 21:23, Marc Khouzam ha scritto:
> [...]
> 4- Completion choices include their entire path, which is not what bash does by default. For example:
>> cd git/contrib
>> ls completion/git-<tab>
> git-completion.bash git-completion.tcsh git-completion.zsh git-prompt.sh
> but
>> git rm completion/git-<tab>
> completion/git-completion.bash completion/git-completion.tcsh completion/git-completion.zsh completion/git-prompt.sh
> notice the extra 'completion/' before each completion. This can get pretty large when completing with
> many directory prefixes. The current tcsh completion has the same problem which I couldn't fix. However, I am
> not sure if it can be fixed for bash.
>
> I personally don't think this is regression, just an slight annoyance.
>
After some searching, I found how this is supposed to be done.
It is possible to use the -o filenames option to tell Bash completion
that "the compspec generates filenames, so it can perform any
filename-specific processing".
Unfortunately this option must be passed to the complete builtin
command, and we can not do this, since the comspec not always contains
filenames.
> [...]
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDsXUEACgkQscQJ24LbaURMlgCdEyeSRTRktKtGuDxq4HX1meWt
IV4AmwS6wasCip+1u4vS2FwG8AlXXB7r
=pN8F
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] remote-hg: Fix biridectionality -> bidirectionality typos
From: W. Trevor King @ 2013-01-08 17:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: Felipe Contreras, git, Jeff King, Sverre Rabbelier,
Johannes Schindelin, Ilari Liusvaara, Daniel Barkalow,
Michael J Gruber
In-Reply-To: <7vboczfunc.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 253 bytes --]
On Tue, Jan 08, 2013 at 09:32:07AM -0800, Junio C Hamano wrote:
> Thanks; didn't Documentation/SubmittingPatches ask you not to do PGP
> multipart but send patches in plain text?
Gah. I need to tell myself to reread that every time I send a patch
:p.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Moving (renaming) submodules, recipe/script
From: W. Trevor King @ 2013-01-08 17:48 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Jonathan Nieder, Git, Peter Collingbourne
In-Reply-To: <50EC536D.8050606@web.de>
[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]
On Tue, Jan 08, 2013 at 06:12:13PM +0100, Jens Lehmann wrote:
> Am 08.01.2013 15:32, schrieb W. Trevor King:
> > The Git directory for the
> > submodule stays in .git/modules/submod-1/ (good), but the worktree in
> > .git/modules/submod-1/config still points to ../../../submod-1 (bad).
>
> You'll not only have to update the gitfile but also the core.worktree
> setting in the repo. Sorry I missed that when you posted your script.
My git-submodule-mv.sh script does update core.worktree. The problem
is that `git checkout`, `git merge`, etc. do not.
> > This means that submodule moves are possible, but anyone trying to
> > share them between several repositories (or trying to rebase across
> > the move within their own repository) is in for a world of suffering
> > ;). I'm not sure how this should be addressed, but I didn't see
> > anything handling it in Jens' new series.
>
> If you adjust core.worktree properly you'll just have the old
> submodule work tree lying around (just like you do after you rm'd
> it) and everything apart from that should just work.
>
> As I mentioned that will be fixed by recursive submodule checkout.
> I'll see if I can polish my preliminary branch so that interested
> people can play around with it if anyone is interested.
Sounds like a fix will be in here. I'll definitely help put the
branch through its paces ;).
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] clone: forbid --bare --separate-git-dir <dir>
From: Junio C Hamano @ 2013-01-08 17:45 UTC (permalink / raw)
To: Jens Lehmann
Cc: Duy Nguyen, Jonathan Nieder, git, Heiko Voigt, Manlio Perillo,
W. Trevor King
In-Reply-To: <50EC543D.5090100@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Am 08.01.2013 15:16, schrieb Duy Nguyen:
>> On Sun, Jan 06, 2013 at 02:19:48AM -0800, Jonathan Nieder wrote:
>>> Unfortunately we forgot to forbid the --bare
>>> --separate-git-dir combination. In practice, we know no one
>>> could be using --bare with --separate-git-dir because it is
>>> broken in the following way: <explanation here>. So it is
>>> safe to make good on our mistake and forbid the combination,
>>> making the command easier to explain.
>>>
>>> I don't know what would go in the <explanation here> blank above,
>>> though. Is it possible that some people are relying on this option
>>> combination?
>>
>> I can't say it's broken in what way. Maybe it's easier to just support
>> this case, it's not much work anyway. Jens, maybe squash this to your
>> original patch?
>
> I'd be fine with that, though my gut feeling is that this should
> be a patch of its own (My patch handles the git dir, your's handles
> a work tree issue).
I agree that these are totally unrelated issues.
After all, Jonathan's suggestion to forbid it was because the
combination does not make sense and does not have practical uses,
and forbidding it would make the command easier to explain than
leaving it accepted from the command line. If you choose to go in
the opposite direction and make "clone --bare --separate-git-dir" do
something useful, it should be explained very well in the
documentation part of the patch why such a combination is a good
idea, and in what situation the behaviour is useful and the user may
want to consider using it, I think.
^ permalink raw reply
* Re: git push --recurse-submodules=on-demand with submodule push tag
From: Jens Lehmann @ 2013-01-08 17:33 UTC (permalink / raw)
To: 乙酸鋰; +Cc: git
In-Reply-To: <CAHtLG6TDqqG09WBkuWzGeWUGog6GOrWQZZtbF5xx_m4ishvzyQ@mail.gmail.com>
Am 08.01.2013 17:35, schrieb 乙酸鋰:
> In superproject, can I call git push --recurse-submodules=on-demand
> that pushes submodule with the submodule's tags?
As that seems to call a plain "git push" in the submodule I think
the tags won't be pushed by this command.
> Very often I change version and tag the submodule
> and change version and tag the superproject at the same time.
Won't "git submodule foreach 'git push --tags'" do what you want?
^ permalink raw reply
* Re: [PATCH] remote-hg: Fix biridectionality -> bidirectionality typos
From: Junio C Hamano @ 2013-01-08 17:32 UTC (permalink / raw)
To: W. Trevor King
Cc: Felipe Contreras, git, Jeff King, Sverre Rabbelier,
Johannes Schindelin, Ilari Liusvaara, Daniel Barkalow,
Michael J Gruber
In-Reply-To: <20130108154737.GA4662@odin.tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
>
> I was looking for one of my older messages to the Git list, and I
> found this, which seems to have fallen through the cracks:
Thanks; didn't Documentation/SubmittingPatches ask you not to do PGP
multipart but send patches in plain text?
> On Wed, Nov 28, 2012 at 03:23:20PM -0500, W. Trevor King wrote:
>> I'm not sure if this is the most recent patch iteration for this
>> feature, but I just saw this typo in `pu`.
>>
>> On Sun, Nov 04, 2012 at 03:13:29AM +0100, Felipe Contreras wrote:
>> > +# Commits are modified to preserve hg information and allow biridectionality.
>> ^^^^^^^^
>> s/biridectionality/bidirectionality/
>
> This fixes that instance (which has since landed in master) and
> another similar typo.
>
> contrib/remote-helpers/git-remote-hg | 2 +-
> contrib/remote-helpers/test-hg-bidi.sh | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
> index 016cdad..c700600 100755
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -31,7 +31,7 @@ import urllib
> # hg:
> # Emulate hg-git.
> # Only hg bookmarks are exported as git branches.
> -# Commits are modified to preserve hg information and allow biridectionality.
> +# Commits are modified to preserve hg information and allow bidirectionality.
> #
>
> NAME_RE = re.compile('^([^<>]+)')
> diff --git a/contrib/remote-helpers/test-hg-bidi.sh b/contrib/remote-helpers/test-hg-bidi.sh
> index a94eb28..1d61982 100755
> --- a/contrib/remote-helpers/test-hg-bidi.sh
> +++ b/contrib/remote-helpers/test-hg-bidi.sh
> @@ -6,7 +6,7 @@
> # https://bitbucket.org/durin42/hg-git/src
> #
>
> -test_description='Test biridectionality of remote-hg'
> +test_description='Test bidirectionality of remote-hg'
>
> . ./test-lib.sh
^ permalink raw reply
* Re: [PATCH] upload-pack: only accept commits from "shallow" line
From: Junio C Hamano @ 2013-01-08 17:27 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1357644756-18205-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> We only allow cuts at commits, not arbitrary objects. upload-pack will
> fail eventually in register_shallow if a non-commit is given with a
> generic error "Object %s is a %s, not a commit". Check it early and
> give a more accurate error.
>
> This should never show up in an ordinary session. It's for buggy
> clients, or when the user manually edits .git/shallow.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
Thanks. I agree with you that while this is not wrong per-se, this
will not matter in real life.
> upload-pack.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/upload-pack.c b/upload-pack.c
> index 6142421..95d8313 100644
> --- a/upload-pack.c
> +++ b/upload-pack.c
> @@ -603,6 +603,8 @@ static void receive_needs(void)
> object = parse_object(sha1);
> if (!object)
> die("did not find object for %s", line);
> + if (object->type != OBJ_COMMIT)
> + die("invalid shallow object %s", sha1_to_hex(sha1));
> object->flags |= CLIENT_SHALLOW;
> add_object_array(object, NULL, &shallows);
> continue;
^ permalink raw reply
* Re: [PATCH] git clone depth of 0 not possible.
From: Junio C Hamano @ 2013-01-08 17:24 UTC (permalink / raw)
To: Stefan Beller
Cc: Duy Nguyen, Jonathan Nieder, schlotter, Ralf.Wildenhues, git
In-Reply-To: <50EC2DE5.2050704@googlemail.com>
Stefan Beller <stefanbeller@googlemail.com> writes:
> On 01/08/2013 03:28 PM, Duy Nguyen wrote:
>> On Tue, Jan 8, 2013 at 2:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Speaking of --depth, I think in Git 2.0 we should fix the semantics
>>> of "deepening" done with "git fetch".
>>
>> Speaking of 2.0, we should support depth per ref. Well we don't have
>> to wait until 2.0 because we could just add shallow2 extension to the
>> pack protocol. We should also apply depth to new refs when fetching
>> them the first time.
>
> Would this mean I could do something along?
> $ git clone --since v1.8.0 git://github.com/gitster/git.git
>
> So tags would be allowed as anchors?
As the end-user facing UI, I think it would be much easier to use
for users who want to get only the recent part of history that is
relevant to their development if you allowed them to ask "starting
from this one, I do not care anything older than that" with such an
interface. The current "count how many more generations you want"
interface is crazy in that it forces you to count what you have not
even seen; I suspect the only reason it was done in such a hacky
manner was implementation expediency.
At the syntax level, however, I do not think we can use --since
there, because the keyword has a very different meaning already.
I personally do not think "depth per ref" deserves "it would be nice
to support in 2.0", let alone "2.0 *should* support", label. Some
may find it an interesting mental exercise to think about corner
cases it will introduce and have to deal with (e.g. you ask 100 from
master and 2 from maint, but maint is behind master by less than
100---what should happen?), but I do not particularly see any
practical use cases, and I highly doubt that there is much value in
bringing in extra complexity such a "feature" requires to do it
right.
^ permalink raw reply
* Re: Understanding When to Use Branches
From: Konstantin Khomoutov @ 2013-01-08 17:08 UTC (permalink / raw)
To: gw1500; +Cc: git@vger.kernel.org
In-Reply-To: <50EC232D.90009@yahoo.com>
On Tue, 08 Jan 2013 08:46:21 -0500
gw1500 <wtriker.ffe@gmail.com> wrote:
> As a git noobie I am beginning get get my head around git's version
> control philosophy. I am now trying to understand the purposes of
> branches or rather when to use them. In my case I have a Java
> application under version control with git. I am planning to port it
> into a mobile app. Is that an appropriate use of branches or should it
> be created as a new repository? What is the relationship between the
> same source code in different branches? Do changes to code in one
> branch get ported to another branch somehow or do all changes then
> have to be made twice? The documentation tells how to branch but not
> the general philosophy behind it from a best practices standpoint.
> Thanks in advance for any insight.
Supposedly you should start with the chapter on branching in
The Book [1] and then read two classic blog posts [2, 3] describing two
different branching models. The branching models described there are
not the only two possible models to use with Git, but they are different
enough to give you a good overview of possibilities.
Note that mere googling for "git branching model" would yield a fair
number of blog posts on people's pet branching models; these two
documents just appear to be more "classic" than others.
If you have difficulty to even grasping the concept of branches and [1]
feeld hard to digest, try first reading "The Git Parable" [4] which, I
think, is the friendliest possible introduction to the basics of DVCS,
branching included.
1. http://git-scm.com/book/en/Git-Branching
2. http://nvie.com/posts/a-successful-git-branching-model/
3. http://scottchacon.com/2011/08/31/github-flow.html
4. http://tom.preston-werner.com/2009/05/19/the-git-parable.html
^ permalink raw reply
* Re: [PATCH] clone: forbid --bare --separate-git-dir <dir>
From: Jens Lehmann @ 2013-01-08 17:15 UTC (permalink / raw)
To: Duy Nguyen
Cc: Jonathan Nieder, git, Junio C Hamano, Heiko Voigt, Manlio Perillo,
W. Trevor King
In-Reply-To: <20130108141650.GA18637@lanh>
Am 08.01.2013 15:16, schrieb Duy Nguyen:
> On Sun, Jan 06, 2013 at 02:19:48AM -0800, Jonathan Nieder wrote:
>> Unfortunately we forgot to forbid the --bare
>> --separate-git-dir combination. In practice, we know no one
>> could be using --bare with --separate-git-dir because it is
>> broken in the following way: <explanation here>. So it is
>> safe to make good on our mistake and forbid the combination,
>> making the command easier to explain.
>>
>> I don't know what would go in the <explanation here> blank above,
>> though. Is it possible that some people are relying on this option
>> combination?
>
> I can't say it's broken in what way. Maybe it's easier to just support
> this case, it's not much work anyway. Jens, maybe squash this to your
> original patch?
I'd be fine with that, though my gut feeling is that this should
be a patch of its own (My patch handles the git dir, your's handles
a work tree issue). But I don't care much either way, what do others
think?
> -- 8< --
> diff --git a/builtin/clone.c b/builtin/clone.c
> index 8d23a62..c8b09ad 100644
> --- a/builtin/clone.c
> +++ b/builtin/clone.c
> @@ -375,6 +375,7 @@ static void clone_local(const char *src_repo, const char *dest_repo)
>
> static const char *junk_work_tree;
> static const char *junk_git_dir;
> +static const char *junk_git_file;
> static pid_t junk_pid;
>
> static void remove_junk(void)
> @@ -392,6 +393,8 @@ static void remove_junk(void)
> remove_dir_recursively(&sb, 0);
> strbuf_reset(&sb);
> }
> + if (junk_git_file)
> + unlink(junk_git_file);
> }
>
> static void remove_junk_on_signal(int signo)
> @@ -772,6 +775,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
>
> set_git_dir_init(git_dir, real_git_dir, 0);
> if (real_git_dir) {
> + if (option_bare)
> + junk_git_file = git_dir;
> git_dir = real_git_dir;
> junk_git_dir = real_git_dir;
> }
> diff --git a/t/t5600-clone-fail-cleanup.sh b/t/t5600-clone-fail-cleanup.sh
> index 4435693..231bc8a 100755
> --- a/t/t5600-clone-fail-cleanup.sh
> +++ b/t/t5600-clone-fail-cleanup.sh
> @@ -49,4 +49,14 @@ test_expect_success 'failed clone --separate-git-dir should not leave any direct
> rmdir foo/.git/objects.bak
> '
>
> +test_expect_success 'failed clone --separate-git-dir --bare should not leave any directories' '
> + mkdir foo/.git/objects.bak/ &&
> + mv foo/.git/objects/* foo/.git/objects.bak/ &&
> + test_must_fail git clone --bare --separate-git-dir gitdir foo baaar &&
> + test_must_fail test -e gitdir &&
> + test_must_fail test -e baaar &&
> + mv foo/.git/objects.bak/* foo/.git/objects/ &&
> + rmdir foo/.git/objects.bak
> +'
> +
> test_done
> -- 8< --
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Moving (renaming) submodules, recipe/script
From: Jens Lehmann @ 2013-01-08 17:12 UTC (permalink / raw)
To: W. Trevor King; +Cc: Jonathan Nieder, Git, Peter Collingbourne
In-Reply-To: <20130108143214.GA3755@odin.tremily.us>
Am 08.01.2013 15:32, schrieb W. Trevor King:
> On Mon, Jan 07, 2013 at 07:59:53AM +0100, Jens Lehmann wrote:
>> Am 07.01.2013 02:39, schrieb Jonathan Nieder:
>>> (just cc-ing Jens and Peter, who might be interested)
>>
>> I´m currently working on teaching mv to move submodules and intend
>> to send those patches to the list after finishing submodule deinit.
>> Please see
>> https://github.com/jlehmann/git-submod-enhancements/commits/mv-submodules
>> for the current state of this series.
>
> Thinking about this a bit more, I'm not clear on how out-of-tree
> updates (i.e. worktree in .git/modules/*/config) propogated during
> branch checkouts (merges, rebases, etc.). I just got a broken rebase
> trying to move a trivial patch back before the submodule move, and Git
> was confused about what had happened to the submodules. Here's a
> simple script that illustrates the problem:
>
> #!/bin/sh
> rm -rf a b c
> mkdir a
> (cd a
> git init
> echo a > README
> git add README
> git commit -am 'a'
> )
> git clone a b
> (cd b
> git submodule add ../a submod-1
> git commit -am 'add submodule at submod-1'
> )
> git clone b c
> (cd c
> git submodule update --init
> )
> (cd b
> git-submodule-mv.sh submod-1 submod-2
> git commit -am 'move submodule from submod-1 to submod-2'
> )
> (cd c
> git pull
> ls -d .git/modules/*
> cat .git/modules/submod-1/config
> ls -a submod*
> )
>
> The end result is that `c` gets the `.gitmodules` path updates and new
> gitlinked directory from the submodule move in `b` (using my
> git-submodule-mv.sh posted earlier in this thread), but `submod-1` is
> left lying around (because Git doesn't know that it can remove
> submod-1/.git and submod-1/README).
That's just what current git does with removed submodules (but my
recursive submodule update series will handle that just fine).
> The Git directory for the
> submodule stays in .git/modules/submod-1/ (good), but the worktree in
> .git/modules/submod-1/config still points to ../../../submod-1 (bad).
You'll not only have to update the gitfile but also the core.worktree
setting in the repo. Sorry I missed that when you posted your script.
> This means that submodule moves are possible, but anyone trying to
> share them between several repositories (or trying to rebase across
> the move within their own repository) is in for a world of suffering
> ;). I'm not sure how this should be addressed, but I didn't see
> anything handling it in Jens' new series.
If you adjust core.worktree properly you'll just have the old
submodule work tree lying around (just like you do after you rm'd
it) and everything apart from that should just work.
As I mentioned that will be fixed by recursive submodule checkout.
I'll see if I can polish my preliminary branch so that interested
people can play around with it if anyone is interested.
^ permalink raw reply
* git push --recurse-submodules=on-demand with submodule push tag
From: 乙酸鋰 @ 2013-01-08 16:35 UTC (permalink / raw)
To: git
Hi,
In superproject, can I call git push --recurse-submodules=on-demand
that pushes submodule with the submodule's tags?
Very often I change version and tag the submodule
and change version and tag the superproject at the same time.
^ permalink raw reply
* Re: [PATCH] wincred: improve compatibility with windows versions
From: Karsten Blees @ 2013-01-08 16:20 UTC (permalink / raw)
To: kusmabite; +Cc: git, msysgit, Jeff King
In-Reply-To: <CABPQNSYcOrOZJd0vK=4ESC4qPpcj7RRdhVt3R0dAE-ouhOb5YA@mail.gmail.com>
Am 04.01.2013 22:57, schrieb Erik Faye-Lund:
> On Fri, Jan 4, 2013 at 9:28 PM, Karsten Blees <karsten.blees@gmail.com> wrote:
>> On WinXP, the windows credential helper doesn't work at all (due to missing
>> Cred[Un]PackAuthenticationBuffer APIs). On Win7, the credential format used
>> by wincred is incompatible with native Windows tools (such as the control
>> panel applet or 'cmdkey.exe /generic'). These Windows tools only set the
>> TargetName, UserName and CredentialBlob members of the CREDENTIAL
>> structure (where CredentialBlob is the UTF-16-encoded password).
>>
>> Remove the unnecessary packing / unpacking of the password, along with the
>> related API definitions, for compatibility with Windows XP.
>>
>> Don't use CREDENTIAL_ATTRIBUTEs to identify credentials for compatibility
>> with Windows credential manager tools. Parse the protocol, username, host
>> and path fields from the credential's target name instead.
>>
>> While we're at it, optionally accept CRLF (instead of LF only) to simplify
>> debugging in bash / cmd.
>>
>> Signed-off-by: Karsten Blees <blees@dcon.de>
>> ---
>>
>> Hi,
>>
>> I tried the windows credential helper yesterday and found that it doesn't work on XP at all, and doesn't work properly in combination with Win7 credential manager tools. So here's a patch that reduces it to the functionality provided / expected by Windows.
>>
>> @Erik, Jeff: Please let me know if I'm missing something and the use of Cred[Un]PackAuthenticationBuffer or CREDENTIAL_ATTRIBUTEs actually served a useful purpose.
>>
>
> The only reason why I used Cred[Un]PackAuthenticationBuffer, were that
> I wasn't aware that it was possible any other way. I didn't even know
> there was a Windows Credential Manager in Windows XP.
>
I believe the Cred* API was introduced in Win2k. The XP control panel applet supports domain credentials only, but cmdkey.exe from Windows Server 2003 can be used on XP to manage generic credentials.
> The credential attributes were because they were convenient, and I'm
> not sure I understand what you mean about the Win7 credential manager
> tools. I did test my code with it - in fact, it was a very useful tool
> for debugging the helper.
>
> Are you referring to the credentials not *looking* like normal
> HTTP-credentials?
No, I was referring to creating / editing git credentials with Windows tools manually. For example, changing your password in control panel removes all credential attributes, so the current wincred won't find them any longer...same for git credentials created e.g. via 'cmdkey /generic:git:http://me@example.com /user:me /pass:secret'.
The 'puzzling' part is that those credentials *look* exactly the same as if created by wincred, but they don't work. And wincred isn't exactly verbose in its error messages :-)
> But, if we do any of these changes, does this mean I will lose my
> existing credentials? It's probably not a big deal, but it's worth a
> mention, isn't it?
>
Yes, existing stored credentials are lost after this patch. Will add a note to the commit message.
We _could_ try to detect the old format, but I don't think it's worth the trouble.
>> @@ -67,20 +61,14 @@ typedef struct _CREDENTIALW {
>> #define CRED_MAX_ATTRIBUTES 64
>>
>> typedef BOOL (WINAPI *CredWriteWT)(PCREDENTIALW, DWORD);
>> -typedef BOOL (WINAPI *CredUnPackAuthenticationBufferWT)(DWORD, PVOID, DWORD,
>> - LPWSTR, DWORD *, LPWSTR, DWORD *, LPWSTR, DWORD *);
>> typedef BOOL (WINAPI *CredEnumerateWT)(LPCWSTR, DWORD, DWORD *,
>> PCREDENTIALW **);
>> -typedef BOOL (WINAPI *CredPackAuthenticationBufferWT)(DWORD, LPWSTR, LPWSTR,
>> - PBYTE, DWORD *);
>> typedef VOID (WINAPI *CredFreeT)(PVOID);
>> typedef BOOL (WINAPI *CredDeleteWT)(LPCWSTR, DWORD, DWORD);
>>
>> static HMODULE advapi, credui;
>
> Perhaps get rid of credui also?
>
Good catch
>> static CredWriteWT CredWriteW;
>> -static CredUnPackAuthenticationBufferWT CredUnPackAuthenticationBufferW;
>> static CredEnumerateWT CredEnumerateW;
>> -static CredPackAuthenticationBufferWT CredPackAuthenticationBufferW;
>> static CredFreeT CredFree;
>> static CredDeleteWT CredDeleteW;
>>
>> @@ -88,74 +76,64 @@ static void load_cred_funcs(void)
>> {
>> /* load DLLs */
>> advapi = LoadLibrary("advapi32.dll");
>> - credui = LoadLibrary("credui.dll");
>> - if (!advapi || !credui)
>> + if (!advapi)
>> die("failed to load DLLs");
>
> It's not multiple DLLs any more, so perhaps "failed to load
> advapi32.dll" instead?
>
Certainly
>> -static char target_buf[1024];
>> -static char *protocol, *host, *path, *username;
>> -static WCHAR *wusername, *password, *target;
>> +static WCHAR *wusername, *password, *protocol, *host, *path, target[1024];
>>
>> -static void write_item(const char *what, WCHAR *wbuf)
>> +static void write_item(const char *what, LPCWSTR wbuf, int wlen)
>> {
>> char *buf;
>> - int len = WideCharToMultiByte(CP_UTF8, 0, wbuf, -1, NULL, 0, NULL,
>> + int len = WideCharToMultiByte(CP_UTF8, 0, wbuf, wlen, NULL, 0, NULL,
>> FALSE);
>> buf = xmalloc(len);
>>
>> - if (!WideCharToMultiByte(CP_UTF8, 0, wbuf, -1, buf, len, NULL, FALSE))
>> + if (!WideCharToMultiByte(CP_UTF8, 0, wbuf, wlen, buf, len, NULL, FALSE))
>> die("WideCharToMultiByte failed!");
>>
>> printf("%s=", what);
>> - fwrite(buf, 1, len - 1, stdout);
>> + fwrite(buf, 1, len, stdout);
>> putchar('\n');
>> free(buf);
>> }
>>
>
> When the password-blob is simply UTF-16 encoded, are the
> zero-termination not included? That's the reason for this change,
> right?
>
Yes, the Windows tools store the password without trailing \0.
>> -static int match_attr(const CREDENTIALW *cred, const WCHAR *keyword,
>> - const char *want)
>> +static int match_part(LPCWSTR *ptarget, LPCWSTR want, LPCWSTR delim)
>> {
>> - int i;
>> - if (!want)
>> - return 1;
>> -
>> - for (i = 0; i < cred->AttributeCount; ++i)
>> - if (!wcscmp(cred->Attributes[i].Keyword, keyword))
>> - return !strcmp((const char *)cred->Attributes[i].Value,
>> - want);
>> -
>> - return 0; /* not found */
>> + LPCWSTR start = *ptarget;
>> + LPCWSTR end = *delim ? wcsstr(start, delim) : start + wcslen(start);
>> + int len = end ? end - start : wcslen(start);
>> + /* update ptarget if we either found a delimiter or need a match */
>> + if (end || want)
>> + *ptarget = end ? end + wcslen(delim) : start + len;
>> + return !want || (!wcsncmp(want, start, len) && !want[len]);
>> }
>>
>
> I'm a bit tired now, but I'm having a hard time reading this code.
> Right now it seems it's a bit too ternary-expression heavy for my
> taste, though.
>
OK, I'll flesh that out a bit. Perhaps a few more comments wouldn't hurt either.
>> static int match_cred(const CREDENTIALW *cred)
>> {
>> - return (!wusername || !wcscmp(wusername, cred->UserName)) &&
>> - match_attr(cred, L"git_protocol", protocol) &&
>> - match_attr(cred, L"git_host", host) &&
>> - match_attr(cred, L"git_path", path);
>> + LPCWSTR target = cred->TargetName;
>> + if (wusername && wcscmp(wusername, cred->UserName))
>> + return 0;
>> +
>> + return match_part(&target, L"git", L":") &&
>> + match_part(&target, protocol, L"://") &&
>> + match_part(&target, wusername, L"@") &&
>> + match_part(&target, host, L"/") &&
>> + match_part(&target, path, L"");
>> }
>>
>
> Ugh, it feels a bit wrong to store and verify the username twice. Do
> we really have to?
>
> The target needs to be unique, even if two different usernames are
> stored for the same site under the same conditions. So probably. It
> just doesn't feel quite right.
>
I don't really see why you would need several usernames to connect to the same target. I can imagine different credentials for reading / writing, but then the protocol would usually be different as well, wouldn't it? (e.g. http vs. ssh)
One of my interim solutions was to remove the username part from the URL entirely. That enabled me to change credentials in control panel (including the username), and wincred would use them. However, that version failed the 'helper can store multiple users' test, so I ended up with storing / checking username twice.
>> @@ -165,44 +143,15 @@ static void get_credential(void)
>> /* search for the first credential that matches username */
>> for (i = 0; i < num_creds; ++i)
>> if (match_cred(creds[i])) {
>> - cred = creds[i];
>> + write_item("username", creds[i]->UserName,
>> + wcslen(creds[i]->UserName));
>> + write_item("password",
>> + (LPCWSTR)creds[i]->CredentialBlob,
>> + creds[i]->CredentialBlobSize / sizeof(WCHAR));
>> break;
>> }
>> - if (!cred)
>> - return;
>> -
>> - CredUnPackAuthenticationBufferW(0, cred->CredentialBlob,
>> - cred->CredentialBlobSize, NULL, &user_buf_size, NULL, NULL,
>> - NULL, &pass_buf_size);
>> -
>> - user_buf = xmalloc(user_buf_size * sizeof(WCHAR));
>> - pass_buf = xmalloc(pass_buf_size * sizeof(WCHAR));
>> -
>> - if (!CredUnPackAuthenticationBufferW(0, cred->CredentialBlob,
>> - cred->CredentialBlobSize, user_buf, &user_buf_size, NULL, NULL,
>> - pass_buf, &pass_buf_size))
>> - die("CredUnPackAuthenticationBuffer failed");
>>
>> CredFree(creds);
>> -
>> - /* zero-terminate (sizes include zero-termination) */
>> - user_buf[user_buf_size - 1] = L'\0';
>> - pass_buf[pass_buf_size - 1] = L'\0';
>> -
>> - write_item("username", user_buf);
>> - write_item("password", pass_buf);
>> -
>> - free(user_buf);
>> - free(pass_buf);
>> -}
>
> Nice!
>
>> -
>> -static void write_attr(CREDENTIAL_ATTRIBUTEW *attr, const WCHAR *keyword,
>> - const char *value)
>> -{
>> - attr->Keyword = (LPWSTR)keyword;
>> - attr->Flags = 0;
>> - attr->ValueSize = strlen(value) + 1; /* store zero-termination */
>> - attr->Value = (LPBYTE)value;
>> }
>>
>> static void store_credential(void)
>> @@ -215,40 +164,18 @@ static void store_credential(void)
>> if (!wusername || !password)
>> return;
>>
>> - /* query buffer size */
>> - CredPackAuthenticationBufferW(0, wusername, password,
>> - NULL, &auth_buf_size);
>> -
>> - auth_buf = xmalloc(auth_buf_size);
>> -
>> - if (!CredPackAuthenticationBufferW(0, wusername, password,
>> - auth_buf, &auth_buf_size))
>> - die("CredPackAuthenticationBuffer failed");
>> -
>> cred.Flags = 0;
>> cred.Type = CRED_TYPE_GENERIC;
>> cred.TargetName = target;
>> cred.Comment = L"saved by git-credential-wincred";
>> - cred.CredentialBlobSize = auth_buf_size;
>> - cred.CredentialBlob = auth_buf;
>> + cred.CredentialBlobSize = (wcslen(password)) * sizeof(WCHAR);
>> + cred.CredentialBlob = (LPVOID)password;
>> cred.Persist = CRED_PERSIST_LOCAL_MACHINE;
>> - cred.AttributeCount = 1;
>> - cred.Attributes = attrs;
>> + cred.AttributeCount = 0;
>> + cred.Attributes = NULL;
>> cred.TargetAlias = NULL;
>> cred.UserName = wusername;
>>
>> - write_attr(attrs, L"git_protocol", protocol);
>> -
>> - if (host) {
>> - write_attr(attrs + cred.AttributeCount, L"git_host", host);
>> - cred.AttributeCount++;
>> - }
>> -
>> - if (path) {
>> - write_attr(attrs + cred.AttributeCount, L"git_path", path);
>> - cred.AttributeCount++;
>> - }
>> -
>> if (!CredWriteW(&cred, 0))
>> die("CredWrite failed");
>> }
>
> Nice.
>
>> @@ -284,10 +211,13 @@ static void read_credential(void)
>>
>> while (fgets(buf, sizeof(buf), stdin)) {
>> char *v;
>> + int len = strlen(buf);
>> + /* strip trailing CR / LF */
>> + while (len && strchr("\r\n", buf[len - 1]))
>> + buf[--len] = 0;
>>
>> - if (!strcmp(buf, "\n"))
>> + if (!*buf)
>> break;
>> - buf[strlen(buf)-1] = '\0';
>>
>> v = strchr(buf, '=');
>> if (!v)
>
> I think this part deserves a separate patch, no?
>
Sigh...I thought I could get away without doing a patch series :-)
>> @@ -295,13 +225,12 @@ static void read_credential(void)
>> *v++ = '\0';
>>
>> if (!strcmp(buf, "protocol"))
>> - protocol = xstrdup(v);
>> + protocol = utf8_to_utf16_dup(v);
>> else if (!strcmp(buf, "host"))
>> - host = xstrdup(v);
>> + host = utf8_to_utf16_dup(v);
>> else if (!strcmp(buf, "path"))
>> - path = xstrdup(v);
>> + path = utf8_to_utf16_dup(v);
>> else if (!strcmp(buf, "username")) {
>> - username = xstrdup(v);
>> wusername = utf8_to_utf16_dup(v);
>> } else if (!strcmp(buf, "password"))
>> password = utf8_to_utf16_dup(v);
>
> So, you need the strings as UTF-16 instead so you can match against them...
>
Exactly
>> @@ -330,22 +259,20 @@ int main(int argc, char *argv[])
>> return 0;
>>
>> /* prepare 'target', the unique key for the credential */
>> - strncat(target_buf, "git:", sizeof(target_buf));
>> - strncat(target_buf, protocol, sizeof(target_buf));
>> - strncat(target_buf, "://", sizeof(target_buf));
>> - if (username) {
>> - strncat(target_buf, username, sizeof(target_buf));
>> - strncat(target_buf, "@", sizeof(target_buf));
>> + wcscpy(target, L"git:");
>> + wcsncat(target, protocol, ARRAY_SIZE(target));
>> + wcsncat(target, L"://", ARRAY_SIZE(target));
>> + if (wusername) {
>> + wcsncat(target, wusername, ARRAY_SIZE(target));
>> + wcsncat(target, L"@", ARRAY_SIZE(target));
>> }
>> if (host)
>> - strncat(target_buf, host, sizeof(target_buf));
>> + wcsncat(target, host, ARRAY_SIZE(target));
>> if (path) {
>> - strncat(target_buf, "/", sizeof(target_buf));
>> - strncat(target_buf, path, sizeof(target_buf));
>> + wcsncat(target, L"/", ARRAY_SIZE(target));
>> + wcsncat(target, path, ARRAY_SIZE(target));
>> }
>>
>> - target = utf8_to_utf16_dup(target_buf);
>> -
>
> ...Which means that you are composing a UTF-16 target directly rather
> than ASCII. Looks sane.
>
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: GIT get corrupted on lustre
From: Eric Chamberland @ 2013-01-08 16:11 UTC (permalink / raw)
To: Brian J. Murrell; +Cc: git
In-Reply-To: <50D870A0.90205@interlinx.bc.ca>
On 12/24/2012 10:11 AM, Brian J. Murrell wrote:
> Have you tried adding a "-q" to the git command line to quiet down git's
> "feedback" messages?
>
Ok, I have modified my crontab to use "-q" and I will wait to see if the
problem occurs from now.
> I discovered other oddities with using git on Lustre which I described
> in this thread:
>
> http://thread.gmane.org/gmane.comp.version-control.git/208886
>
> I found that by simply disabling the feedback (which disables the
> copious SIGALRM processing) I could alleviate the issue.
>
> I wonder if your issues are more of the same.
>
> I filed Lustre bug LU-2276 about it at:
>
> http://jira.whamcloud.com/browse/LU-2276
Thank you for these informations. I see the bug is unresolved!...
Eric
^ permalink raw reply
* Re: Moving (renaming) submodules, recipe/script
From: W. Trevor King @ 2013-01-08 15:59 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Jonathan Nieder, Git, Peter Collingbourne
In-Reply-To: <20121023220955.GA30442@odin.tremily.us>
[-- Attachment #1: Type: text/plain, Size: 1500 bytes --]
On Tue, Jan 08, 2013 at 09:32:14AM -0500, W. Trevor King wrote:
> Thinking about this a bit more, I'm not clear on how out-of-tree
> updates (i.e. worktree in .git/modules/*/config) propogated during
> branch checkouts (merges, rebases, etc.).
Actually, I don't understand why storing `worktree` in
.git/modules/*/config is useful at all…. This may be related to my
lack of clarity on the "why can't we have multiple working directories
checked out at the same time" issue:
On Tue, Oct 23, 2012 at 06:09:55PM -0400, W. Trevor King wrote:
> On Tue, Oct 23, 2012 at 10:57:57PM +0200, Jens Lehmann wrote:
> > Am 22.10.2012 14:37, schrieb W. Trevor King:
> > > but cloning a remote repository (vs. checking out a local branch)
> > > seems to be baked into the submodule implementation. Should I be
> > > thinking about generalizing git-submodule.sh, or am I looking under
> > > the wrong rock? My ideal syntax would be something like
> > >
> > > $ git submodule add -b c --local dir-for-c/
> >
> > But then we'd have to be able to have two (or more) work trees using
> > the same git directory, which current submodule code can't.
>
> And that's the problem I'm trying to solve ;).
Can someone with a better feeling for why this won't work. Is is just
that there's only one `.git/HEAD`?
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] remote-hg: Fix biridectionality -> bidirectionality typos
From: W. Trevor King @ 2013-01-08 15:47 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Jeff King, Sverre Rabbelier,
Johannes Schindelin, Ilari Liusvaara, Daniel Barkalow,
Michael J Gruber
In-Reply-To: <20121128202320.GA22522@odin.tremily.us>
[-- Attachment #1: Type: text/plain, Size: 1850 bytes --]
Signed-off-by: W. Trevor King <wking@tremily.us>
---
I was looking for one of my older messages to the Git list, and I
found this, which seems to have fallen through the cracks:
On Wed, Nov 28, 2012 at 03:23:20PM -0500, W. Trevor King wrote:
> I'm not sure if this is the most recent patch iteration for this
> feature, but I just saw this typo in `pu`.
>
> On Sun, Nov 04, 2012 at 03:13:29AM +0100, Felipe Contreras wrote:
> > +# Commits are modified to preserve hg information and allow biridectionality.
> ^^^^^^^^
> s/biridectionality/bidirectionality/
This fixes that instance (which has since landed in master) and
another similar typo.
contrib/remote-helpers/git-remote-hg | 2 +-
contrib/remote-helpers/test-hg-bidi.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index 016cdad..c700600 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -31,7 +31,7 @@ import urllib
# hg:
# Emulate hg-git.
# Only hg bookmarks are exported as git branches.
-# Commits are modified to preserve hg information and allow biridectionality.
+# Commits are modified to preserve hg information and allow bidirectionality.
#
NAME_RE = re.compile('^([^<>]+)')
diff --git a/contrib/remote-helpers/test-hg-bidi.sh b/contrib/remote-helpers/test-hg-bidi.sh
index a94eb28..1d61982 100755
--- a/contrib/remote-helpers/test-hg-bidi.sh
+++ b/contrib/remote-helpers/test-hg-bidi.sh
@@ -6,7 +6,7 @@
# https://bitbucket.org/durin42/hg-git/src
#
-test_description='Test biridectionality of remote-hg'
+test_description='Test bidirectionality of remote-hg'
. ./test-lib.sh
--
1.8.1.151.g32238ae
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: [PATCH] git clone depth of 0 not possible.
From: Duy Nguyen @ 2013-01-08 14:45 UTC (permalink / raw)
To: Stefan Beller
Cc: Junio C Hamano, Jonathan Nieder, schlotter, Ralf.Wildenhues, git
In-Reply-To: <50EC2DE5.2050704@googlemail.com>
On Tue, Jan 8, 2013 at 9:32 PM, Stefan Beller
<stefanbeller@googlemail.com> wrote:
> On 01/08/2013 03:28 PM, Duy Nguyen wrote:
>> On Tue, Jan 8, 2013 at 2:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Speaking of --depth, I think in Git 2.0 we should fix the semantics
>>> of "deepening" done with "git fetch".
>>
>> Speaking of 2.0, we should support depth per ref. Well we don't have
>> to wait until 2.0 because we could just add shallow2 extension to the
>> pack protocol. We should also apply depth to new refs when fetching
>> them the first time.
>>
>
> Would this mean I could do something along?
> $ git clone --since v1.8.0 git://github.com/gitster/git.git
>
> So tags would be allowed as anchors?
No. This is what I had in mind:
git clone --branch=master --depth=2 git.git # get branch master with depth 2
git fetch --depth=10 origin next # get branch next with depth 10
# master's depth remains 2
git fetch origin # get (new) branch 'pu' with default depth 2
But your case is interesting. We could specify --depth=v1.8.0.. or
even --depth=v1.8.0~200.. (200 commits before v1.8.0). Somebody may
even go crazy and make --depth=v1.6.0..v1.8.0 work. --depth is
probably not the right name anymore. Any SHA-1 would be allowed as
anchor. But I think we need to wait for reachability bitmap feature to
come first so that we can quickly verify the anchor is reachable from
the public refs.
--
Duy
^ 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