* Re: .git/index
From: Jon Smirl @ 2009-03-25 18:03 UTC (permalink / raw)
To: Julian Phillips; +Cc: Git Mailing List
In-Reply-To: <alpine.LNX.2.00.0903251749270.11062@reaper.quantumfyre.co.uk>
On Wed, Mar 25, 2009 at 1:52 PM, Julian Phillips
<julian@quantumfyre.co.uk> wrote:
> On Wed, 25 Mar 2009, Jon Smirl wrote:
>
>> I pushed a repo up to my server. I want to view this repo with gitweb
>> but it is not visible in my project list like my other projects. I
>> suspect this is because the newly pushed repo is missing .git/index. I
>> ran update-server-info on the repo and that didn't create .git/index.
>> What command builds this index?
>
> .git/index is the default name used for what is commonly referred to as the
> staging area these days. It's only needed when you have a work tree, and is
> expected to be absent from a bare repository.
>
> A more likely cause for a repository to not be picked up by gitweb is file
> permissions.
It needed to be added to the gitweb projects file.
>
> --
> Julian
>
> ---
> <MFGolfBal> rit/ara: There's something really demented about UNIX
> underwear...
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)
From: Junio C Hamano @ 2009-03-25 18:06 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: git
In-Reply-To: <20090324111645.GA6084@pvv.org>
Finn Arne Gangstad <finnag@pvv.org> writes:
> On Tue, Mar 24, 2009 at 02:13:18AM -0700, Junio C Hamano wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>> > $ git push --dry-run sf.net
>> > warning: ...
>> > warning: You can specify what action you want to take in this case, and
>> > warning: avoid seeing this message again, by configuring 'push.default' to:
>> >...
>> > warning: 'current' : Push the current branch
>> > fatal: 'sf.net' does not appear to be a git repository
>> > fatal: The remote end hung up unexpectedly
>> >
>> > The final, most important error messages are dwarfed out by the warning
>> > that talks about setting configuration on the remote that does not even
>> > exist.
>
> I actually agree, but that final error is printed in a very ugly
> place! It would require some surgery to pause the warning until we
> figure out that sf.net is not a valid remote in the current setup.
>
> get_refs_via_connect->connect_setup->git_connect-> .. fork()s .., runs
> "sh -c git-receive-pack 'sf.net'" (which prints the first error)
> and get_remote_heads->packet_read_line->safe_read() dumps the final error
> and dies.
>
> Is there any reason why remote_get needs to return a valid remote for
> a value like "sf.net"? If it didn't, the error message would be even
> better, and not complain about a "remote end".
Yeah, you could work around by special casing colon-less ones as you
suggested, but I do not think it is worth it.
Instead of "sf.net", the example could have been
git-core.git.sourceforge.net:/gitroot/gut-core
which looks like a perfectly valid push destination, but it has a typo in
the pathname, and the remote end will hang up unexpectedly in such a case,
too. I do not think remote_get() is a wrong thing to blame; in that
codepath you simply do not know.
If you want to remove warning when we will eventually go "fatal", the way
to do so is to remember you need to issue a warning but defer it until you
actually start telling the other end in do_send_pack(), or something like
that.
I do not think we would want nor need to go that route. This warning is
about a local configuration that applies to _all_ remotes, and setting the
configuration once will squelch it for future push to any remotes. Giving
the warning even for an _incorrect_ remote is not wrong per-se.
Issuing the warning at first looked incorrect to me, but it warns exactly
about what the patch that added the warning messages wanted to warn about:
If you did not misspell the name of the remote or the URL, you would
have triggered the default "matching refs" semantics, but you may not
have meant to do so, hence we are warning. If you want to change the
default, here is how. If you find this message irritating, you can
squelch it this way.
In this particular case, I _did_ want the default matching refs semantics,
so it was irritating whether I had the last two "fatal" lines or not. But
the point of your patch was to help new people for the cost of irritating
people like me (once), so...
^ permalink raw reply
* reverting initial commit
From: Pascal Obry @ 2009-03-25 18:12 UTC (permalink / raw)
To: git list
Starting a new project I create a new repo and added some files for the
initial revision of the project, something like:
mkdir repo.git
cd repo.git
git init
touch file
git add file
git ci -m "initial revision"
Now one file was not meant to be committed, I wanted to revert this commit:
git reset HEAD^
fatal: ambiguous argument 'HEAD^': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions
I understand that HEAD^ does not exist, is there a way to do that?
Thanks,
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* [PATCH] Grammar fixes to "merge" and "patch-id" docs
From: Wincent Colaiuta @ 2009-03-25 18:23 UTC (permalink / raw)
To: git; +Cc: gitster, Wincent Colaiuta
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
Just a few grammar glitches that caught my eye while
perusing some man pages.
Documentation/git-merge.txt | 2 +-
Documentation/git-patch-id.txt | 2 +-
Documentation/merge-strategies.txt | 14 +++++++-------
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index cc0d30f..427ad90 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -41,7 +41,7 @@ include::merge-strategies.txt[]
If you tried a merge which resulted in a complex conflicts and
-would want to start over, you can recover with 'git-reset'.
+want to start over, you can recover with 'git-reset'.
CONFIGURATION
-------------
diff --git a/Documentation/git-patch-id.txt b/Documentation/git-patch-id.txt
index 477785e..253fc0f 100644
--- a/Documentation/git-patch-id.txt
+++ b/Documentation/git-patch-id.txt
@@ -20,7 +20,7 @@ IOW, you can use this thing to look for likely duplicate commits.
When dealing with 'git-diff-tree' output, it takes advantage of
the fact that the patch is prefixed with the object name of the
-commit, and outputs two 40-byte hexadecimal string. The first
+commit, and outputs two 40-byte hexadecimal strings. The first
string is the patch ID, and the second string is the commit ID.
This can be used to make a mapping from patch ID to commit ID.
diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
index 1276f85..ee7f754 100644
--- a/Documentation/merge-strategies.txt
+++ b/Documentation/merge-strategies.txt
@@ -3,15 +3,15 @@ MERGE STRATEGIES
resolve::
This can only resolve two heads (i.e. the current branch
- and another branch you pulled from) using 3-way merge
+ and another branch you pulled from) using a 3-way merge
algorithm. It tries to carefully detect criss-cross
merge ambiguities and is considered generally safe and
fast.
recursive::
- This can only resolve two heads using 3-way merge
- algorithm. When there are more than one common
- ancestors that can be used for 3-way merge, it creates a
+ This can only resolve two heads using a 3-way merge
+ algorithm. When there is more than one common
+ ancestor that can be used for 3-way merge, it creates a
merged tree of the common ancestors and uses that as
the reference tree for the 3-way merge. This has been
reported to result in fewer merge conflicts without
@@ -22,11 +22,11 @@ recursive::
pulling or merging one branch.
octopus::
- This resolves more than two-head case, but refuses to do
- complex merge that needs manual resolution. It is
+ This resolves the more than two-heads case, but refuses to do
+ a complex merge that needs manual resolution. It is
primarily meant to be used for bundling topic branch
heads together. This is the default merge strategy when
- pulling or merging more than one branches.
+ pulling or merging more than one branch.
ours::
This resolves any number of heads, but the result of the
--
1.6.2.1
^ permalink raw reply related
* Re: reverting initial commit
From: Jacob Helwig @ 2009-03-25 18:20 UTC (permalink / raw)
To: pascal; +Cc: git list
In-Reply-To: <49CA7428.70400@obry.net>
On Wed, Mar 25, 2009 at 11:12, Pascal Obry <pascal@obry.net> wrote:
>
> Starting a new project I create a new repo and added some files for the
> initial revision of the project, something like:
>
> mkdir repo.git
> cd repo.git
> git init
> touch file
> git add file
> git ci -m "initial revision"
>
> Now one file was not meant to be committed, I wanted to revert this commit:
>
> git reset HEAD^
>
> fatal: ambiguous argument 'HEAD^': unknown revision or path not in the
> working tree.
> Use '--' to separate paths from revisions
>
> I understand that HEAD^ does not exist, is there a way to do that?
>
> Thanks,
> Pascal.
>
> --
>
> --|------------------------------------------------------
> --| Pascal Obry Team-Ada Member
> --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
> --|------------------------------------------------------
> --| http://www.obry.net - http://v2p.fr.eu.org
> --| "The best way to travel is by means of imagination"
> --|
> --| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
>
> --
> 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
>
You want "git filter-branch". Probably something like:
git filter-branch --index-filter 'git rm --cached --ignore-unmatched
FILE_TO_REMOVE' -- --all
This will remove FILE_TO_REMOVE from all commits across all branches.
-Jacob
^ permalink raw reply
* Re: reverting initial commit
From: Junio C Hamano @ 2009-03-25 18:26 UTC (permalink / raw)
To: pascal; +Cc: git list
In-Reply-To: <49CA7428.70400@obry.net>
Pascal Obry <pascal@obry.net> writes:
> Starting a new project I create a new repo and added some files for the
> initial revision of the project, something like:
>
> mkdir repo.git
> cd repo.git
> git init
> touch file
> git add file
> git ci -m "initial revision"
>
> Now one file was not meant to be committed, I wanted to revert this commit:
That's not even an revert. Can't you simply amend it away?
$ git rm not-this-file
$ git commit --amend
^ permalink raw reply
* Re: reverting initial commit
From: Jacob Helwig @ 2009-03-25 18:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: pascal, git list
In-Reply-To: <7v1vsl4fxo.fsf@gitster.siamese.dyndns.org>
On Wed, Mar 25, 2009 at 11:26, Junio C Hamano <gitster@pobox.com> wrote:
> Pascal Obry <pascal@obry.net> writes:
>
>> Starting a new project I create a new repo and added some files for the
>> initial revision of the project, something like:
>>
>> mkdir repo.git
>> cd repo.git
>> git init
>> touch file
>> git add file
>> git ci -m "initial revision"
>>
>> Now one file was not meant to be committed, I wanted to revert this commit:
>
> That's not even an revert. Can't you simply amend it away?
>
> $ git rm not-this-file
> $ git commit --amend
> --
> 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
>
This is obviously the easier way. (Or a rebase --interactive) I've
just got filter-branch on the brain, because of a git conversion.
^ permalink raw reply
* Re: [PATCH] Grammar fixes to "merge" and "patch-id" docs
From: Junio C Hamano @ 2009-03-25 18:33 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <1238005422-7647-1-git-send-email-win@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> If you tried a merge which resulted in a complex conflicts and
> -would want to start over, you can recover with 'git-reset'.
> +want to start over, you can recover with 'git-reset'.
Reads Ok to me either way...
> diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
> index 1276f85..ee7f754 100644
> --- a/Documentation/merge-strategies.txt
> +++ b/Documentation/merge-strategies.txt
> @@ -3,15 +3,15 @@ MERGE STRATEGIES
>
> resolve::
> This can only resolve two heads (i.e. the current branch
> - and another branch you pulled from) using 3-way merge
> + and another branch you pulled from) using a 3-way merge
> algorithm. It tries to carefully detect criss-cross
Hmph, would that be an 'a' or 'the'?
> recursive::
> - This can only resolve two heads using 3-way merge
> - algorithm. When there are more than one common
> - ancestors that can be used for 3-way merge, it creates a
> + This can only resolve two heads using a 3-way merge
> + algorithm. When there is more than one common
> + ancestor that can be used for 3-way merge, it creates a
Do you need an article before the latter "3-way merge", perhaps "the"?
> @@ -22,11 +22,11 @@ recursive::
> pulling or merging one branch.
>
> octopus::
> - This resolves more than two-head case, but refuses to do
> - complex merge that needs manual resolution. It is
> + This resolves the more than two-heads case, but refuses to do
> + a complex merge that needs manual resolution. It is
Perhaps "resolves cases with more than two heads" is easier to read?
^ permalink raw reply
* Re: reverting initial commit
From: Pascal Obry @ 2009-03-25 18:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7v1vsl4fxo.fsf@gitster.siamese.dyndns.org>
Junio C Hamano a écrit :
> That's not even an revert.
Right.
> Can't you simply amend it away?
>
> $ git rm not-this-file
> $ git commit --amend
Right, I've done that. But the fact that un-committing the initial
commit was not possible seemed strange to me. At least the error message
should be clearer, don't you think?
Thanks.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Reference for git.git release process
From: Raman Gupta @ 2009-03-25 18:32 UTC (permalink / raw)
To: git
Hi I'm relatively new to git and I've been reading the git.git notes
about how git itself is maintained, as I'm interested in using a
similar workflow. I've read the MaintNotes document, the
howto/maintain-git.txt addendum, and Documentation/gitworkflows.txt.
I believe I understand reasonably well the concepts presented in those
three documents. However, those documents have a lot of detail about
the development process, but not much about the release process.
One question about the dev process:
1) I don't see any topic branches available in git.git. Are these
generally kept in a private repo and/or shared between individual
developer's public repositories?
Some questions about the release process:
1) After a release is made (master is tagged with vX.Y.Z), is the
maint branch deleted and recreated from the new release tag? e.g.
git branch -d maint
git branch maint master
2) MaintNotes states:
"After a feature release is made from "master", however, "next" will
be rebuilt from the tip of "master" using the surviving topics"
Does this mean:
git branch -d next
git checkout -b next master
git merge ai/topic1_to_cook_in_next
git merge ai/topic2_to_cook_in_next
...
Lastly, I note that the gitk --all representation of a repository
maintained in this way is very difficult to follow (at least for me)
because of all the merging. Are there some canned gitk invocations
that can be used to make the visualization of the integration and
topic branches more intuitive?
Thank you all very much for an excellent tool.
Cheers,
Raman
^ permalink raw reply
* Re: reverting initial commit
From: Junio C Hamano @ 2009-03-25 18:40 UTC (permalink / raw)
To: pascal; +Cc: git list
In-Reply-To: <49CA799A.6020807@obry.net>
Pascal Obry <pascal@obry.net> writes:
> Junio C Hamano a écrit :
>> That's not even an revert.
>
> Right.
>
>> Can't you simply amend it away?
>>
>> $ git rm not-this-file
>> $ git commit --amend
>
> Right, I've done that. But the fact that un-committing the initial
> commit was not possible seemed strange to me. At least the error message
> should be clearer, don't you think?
"You said HEAD^ but there is no such thing? What are you talking about?"
That sounds clear enough to me, but if you have a patch to improve it,
please send it in.
^ permalink raw reply
* Re: [PATCH 2/5] Document details of transport function APIs
From: Daniel Barkalow @ 2009-03-25 18:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmyb95vky.fsf@gitster.siamese.dyndns.org>
On Wed, 25 Mar 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> >> > + * If, in the process, the transport determines that the
> >> > + * remote side actually responded to the push by updating the
> >> > + * ref to a different value, the transport should modify the
> >> > + * new_sha1 in the ref. (Note that this is a matter of the
> >> > + * remote accepting but rewriting the change, not rejecting it
> >> > + * and reporting that a different update had already taken
> >> > + * place)
> >> > + **/
> >>
> >> It this even a sane thing to allow? How would it interact with the
> >> "pretend we immediately turned around and fetched them into the remote
> >> tracking branches" local updates we usually do?
> >
> > We already allow a git server to rewrite refs with a hook when it gets
> > them, and we record the pre-rewriting value. This allows the transport to
> > propagate the post-rewriting value back (if it can get it), and we'd
> > update the tracking branches with what the server actually did instead of
> > what we asked it to (i.e., we do what we would do if we really did turn
> > around and fetch them immediately).
>
> But how are you guaranteeing that objects necessary to complete the
> history the remote end re-written are already available on the local end?
> Do you have a reverse object transfer phase now in send-pack protocol?
The current send-pack protocol wouldn't be able to use this feature (I
don't think it can even report the replacement hashes, so there's little
danger of that).
The foreign VCS transport would actually reimport the objects (in the
process of discovering the hash), so that's fine.
> Otherwise I am afraid that you are corrupting the local repository.
It wouldn't be any different from fetch() reporting success when it hadn't
actually succeeded, but I think it would be worth being explicit here that
you can't simply report the other end's hash if you may not have it.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 3/5] Add option for using a foreign VCS
From: Daniel Barkalow @ 2009-03-25 18:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhc1h5vkt.fsf@gitster.siamese.dyndns.org>
On Wed, 25 Mar 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> >> > - if (!prefixcmp(url, "rsync:")) {
> >> > + if (remote && remote->foreign_vcs) {
> >> > + } else if (!prefixcmp(url, "rsync:")) {
> >>
> >> if (...) {
> >> ; /* empty */
> >> } else ...
> >
> > I don't think I've ever tried writing an empty block for git before. It's
> > braces containing a semicolon and comment? (Of course, the reason I wrote
> > this one this way is so that the next patch could put two "+" lines in
> > there and have no "-" lines)
>
> Wasn't a serious "this has to be the final style" suggestion, but more
> about "what do you mean by this? are you going to add more code here in
> the later round?" question.
Ah, yes, I do intend to add code there subsequently, and this is just a
placeholder so that it returns a correctly-constructed struct which
doesn't support any operations until those operations are added.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 3/5] Add option for using a foreign VCS
From: Junio C Hamano @ 2009-03-25 18:58 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0903251442200.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Wed, 25 Mar 2009, Junio C Hamano wrote:
>
>> Daniel Barkalow <barkalow@iabervon.org> writes:
>>
>> >> > - if (!prefixcmp(url, "rsync:")) {
>> >> > + if (remote && remote->foreign_vcs) {
>> >> > + } else if (!prefixcmp(url, "rsync:")) {
>> >>
>> >> if (...) {
>> >> ; /* empty */
>> >> } else ...
>> >
>> > I don't think I've ever tried writing an empty block for git before. It's
>> > braces containing a semicolon and comment? (Of course, the reason I wrote
>> > this one this way is so that the next patch could put two "+" lines in
>> > there and have no "-" lines)
>>
>> Wasn't a serious "this has to be the final style" suggestion, but more
>> about "what do you mean by this? are you going to add more code here in
>> the later round?" question.
>
> Ah, yes, I do intend to add code there subsequently, and this is just a
> placeholder so that it returns a correctly-constructed struct which
> doesn't support any operations until those operations are added.
Ah, OK, thanks.
In that case, I would say:
if (...) {
; /* empty for now */
} else ... {
or even more explicit:
if (...) {
/*
* NEEDSWORK: later when we activate nitfol,
* add code to let gostak distim the doshes here.
*/
;
} else ... {
to allow people to grep for NEEDSWORK would be more appropriate.
^ permalink raw reply
* Re: [PATCH] Grammar fixes to "merge" and "patch-id" docs
From: Wincent Colaiuta @ 2009-03-25 19:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vocvp310v.fsf@gitster.siamese.dyndns.org>
El 25/3/2009, a las 19:33, Junio C Hamano escribió:
> Wincent Colaiuta <win@wincent.com> writes:
>
>> If you tried a merge which resulted in a complex conflicts and
>> -would want to start over, you can recover with 'git-reset'.
>> +want to start over, you can recover with 'git-reset'.
>
> Reads Ok to me either way...
"tried" is in the past preterit, so the second verb, the one after the
"and", should be "want" due to concordance. "would want" is not
actually wrong, but it is bad form. It is a common mistake among non-
native speaker to use "would" when it's not required in cases like
this, probably due to confusion with the pattern "If X, I would
Y" (but note that there's no "and" in that case).
(Speaking as a native English-speaker and part-time English teacher,
who this very week has been teaching classes about modal verbs like
"would".)
>> diff --git a/Documentation/merge-strategies.txt b/Documentation/
>> merge-strategies.txt
>> index 1276f85..ee7f754 100644
>> --- a/Documentation/merge-strategies.txt
>> +++ b/Documentation/merge-strategies.txt
>> @@ -3,15 +3,15 @@ MERGE STRATEGIES
>>
>> resolve::
>> This can only resolve two heads (i.e. the current branch
>> - and another branch you pulled from) using 3-way merge
>> + and another branch you pulled from) using a 3-way merge
>> algorithm. It tries to carefully detect criss-cross
>
> Hmph, would that be an 'a' or 'the'?
Doesn't really matter, IMO, but some kind of article is required
there. If there is literally only one 3-way merge algorithm in
computer science, then "the" would be best. I chose "a" because I was
thinking of it as "Git's interpretation of the 3-way merge algorithm".
>> recursive::
>> - This can only resolve two heads using 3-way merge
>> - algorithm. When there are more than one common
>> - ancestors that can be used for 3-way merge, it creates a
>> + This can only resolve two heads using a 3-way merge
>> + algorithm. When there is more than one common
>> + ancestor that can be used for 3-way merge, it creates a
>
> Do you need an article before the latter "3-way merge", perhaps "the"?
Probably wouldn't hurt.
>> @@ -22,11 +22,11 @@ recursive::
>> pulling or merging one branch.
>>
>> octopus::
>> - This resolves more than two-head case, but refuses to do
>> - complex merge that needs manual resolution. It is
>> + This resolves the more than two-heads case, but refuses to do
>> + a complex merge that needs manual resolution. It is
>
> Perhaps "resolves cases with more than two heads" is easier to read?
Yes, I agree.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] format-patch: add arbitrary email headers
From: Junio C Hamano @ 2009-03-25 19:11 UTC (permalink / raw)
To: Michael Hendricks; +Cc: git
In-Reply-To: <1237996712-61859-1-git-send-email-michael@ndrix.org>
Michael Hendricks <michael@ndrix.org> writes:
> format-patch supports the format.headers configuration for adding
> arbitrary email headers to the patches it outputs. This patch adds
> support for a --header argument which makes the same feature available
> from the command line. This is useful when the content of custom
> email headers must change from branch to branch.
How should this interact with the configuration variable?
Typically we allow command line options to override the matching config
variable, so that people can say "here are the settings I ordinarily use"
in the config file, and say "but I do not want the usual values to take
effect for this particular invocation; please use these _instead_" with
command line options.
Note that the above question is "how should this interact"; not "how does
this interact". I can see you chose to make this cumulative in your patch
and the documentaiton.
I am asking if that is what the users want, overriding is preferred, or
perhaps another option to clear extra headers (say, "--no-extra-headers")
is necessary to allow both.
> diff --git a/builtin-log.c b/builtin-log.c
> index c7a5772..35701a7 100644
> --- a/builtin-log.c
> +++ b/builtin-log.c
> @@ -918,6 +918,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
> cover_letter = 1;
> else if (!strcmp(argv[i], "--no-binary"))
> no_binary_diff = 1;
> + else if (!prefixcmp(argv[i], "--header="))
> + add_header( argv[i] + 9 );
No extra SP immediately after ( and before ), please.
^ permalink raw reply
* Re: [PATCH] avoid possible overflow in delta size filtering computation
From: Nicolas Pitre @ 2009-03-25 19:17 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: Junio C Hamano, git
In-Reply-To: <86bprptvcx.fsf@broadpark.no>
On Wed, 25 Mar 2009, Kjetil Barvik wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > On Wed, 25 Mar 2009, Kjetil Barvik wrote:
> >
> >> So, it seems that this patch almost fixed the issue. But notice that
> >> the pack file was 10 bytes larger for the --depth=95000 case.
> >>
> >> I made a small perl script to compare the output from 'git verify-pack
> >> -v' of the 2 idx/pack files, and found the following difference(1)
> >> (first line from --depth=20000 case, second from --depth=95000):
> >>
> >> fe0a6f3e971373590714dbafd087b235ea60ac00 tree 9 19 18921247 731 96a3ec5789504e6d0f90c99fb1937af1ebd58e2d
> >> fe0a6f3e971373590714dbafd087b235ea60ac00 tree 20 29 18921247 730 12e560f7fb28558b15e3a2008fba860f9a4b2222
> >
> > OK. Apparently, a different base object for that one delta was chosen
> > between those two runs.
> >
> > Is your machine SMP?
>
> kjetil ~$ uname -a
> Linux localhost 2.6.28.4 #26 SMP PREEMPT Tue Feb 10 17:07:14 CET 2009
> i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux
Here you go. If you want a perfectly deterministic repacking, you'll
have to force the pack.threads config option to 1.
Nicolas
^ permalink raw reply
* Re: [PATCH 4/5] Draft of API for git-vcs-*, transport.c code to use it.
From: Daniel Barkalow @ 2009-03-25 19:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbprp5vko.fsf@gitster.siamese.dyndns.org>
On Wed, 25 Mar 2009, Junio C Hamano wrote:
> Suppose a project used to use subversion, but it migrated to git (not an
> unheard-of scenario these days, I hope). The git repository now is the
> authoritative one, all the development happens on this side.
>
> But in order to help:
>
> - people who have established their workflow to follow the project
> (e.g. not necessarily contributing anything back, but just doing
> regular "svn update");
>
> - people who have leftover local changes from the subversion days; and
>
> - other project infrastracture (e.g. trac) that the project hasn't
> managed to interface to the new git repository yet;
>
> the project decides to keep feeding recent updates to the subversion
> repository that used to be authoritative, even though it is now declared
> read-only (i.e. the only update comes from the git end).
Actually, this is easy: just configure the git repo to not fetch anything
from the no-longer-authoritative subversion repository. git-vcs-svn would
waste a bunch of time reimporting what it exported, but it wouldn't
actually do anything with it (since it doesn't even have tracking refs to
update). It could, of course, be optimized to avoid reimporting if it
doesn't need to.
> My understanding is that the above scenario would not work if git-vcs-svn
> rewrites commits when git exports to svn, and existing git-svn two-way
> interface using its "dcommit" may have exactly the same issue.
>
> The reason I brought this up was to involve people who have already faced
> this issue with git-svn in the discussion to see if we can avoid it by
> doing somethink similar to clever tricks they are using in their git-svn
> workflow, if there are some. Perhaps your paragraph below may be one of
> those clever tricks, but there may be others.
The harder problem is that you can only push history that the remote
system will be able to represent. In the same way that git wants your push
to be a fast-forward, svn wants your push to not contain any merges (and
p4 and svn both want your push to not contain parallel development
pushed to a single branch). Rewriting the history to conform to the
destination's requirements is most of what dcommit does, I believe.
I think that, in this use case, the right thing is to have a config option
for git-vcs-svn to tell it to collapse the problematic commits (or maybe
collapse all commits in a push). That would make the svn history export
like the reflog, which is all linear and simple anyway, and probably
sufficient for the above users of the old repository.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Reference for git.git release process
From: Junio C Hamano @ 2009-03-25 19:30 UTC (permalink / raw)
To: Raman Gupta; +Cc: git
In-Reply-To: <49CA78BF.2020101@fastmail.fm>
Raman Gupta <rocketraman@fastmail.fm> writes:
> One question about the dev process:
>
> 1) I don't see any topic branches available in git.git. Are these
> generally kept in a private repo and/or shared between individual
> developer's public repositories?
I do not answer "generally" part, but in git.git, I do not publish heads
of individual topic branches. I could, but simply I don't, because that
has been the way I've operated so far, and I am too lazy to change my
configuration. Also I suspect it would make my life more cumbersome
because I have to prune stale topics from the public repositories from
time to time.
> Some questions about the release process:
>
> 1) After a release is made (master is tagged with vX.Y.Z), is the
> maint branch deleted and recreated from the new release tag? e.g.
>
> git branch -d maint
> git branch maint master
It is rather:
git checkout maint
git merge master
which should be the same because the merge should fast-forward, but an
advantage is that it would keep the reflog of 'maint'.
In addition, you can keep older maintenance track around, i.e.
git branch maint-X.Y.(Z-1) maint
git checkout maint
git merge master
so that maintenance releases for even older codebase _could_ be issued
_if_ necessary.
> 2) MaintNotes states:
>
> "After a feature release is made from "master", however, "next" will
> be rebuilt from the tip of "master" using the surviving topics"
>
> Does this mean:
>
> git branch -d next
> git checkout -b next master
> git merge ai/topic1_to_cook_in_next
> git merge ai/topic2_to_cook_in_next
That is more-or-less correct, even though I'd actually do either
git branch -f next master
or
git checkout next
git reset --hard master
instead of deleting and recreating.
^ permalink raw reply
* Re: [PATCH 4/5] Draft of API for git-vcs-*, transport.c code to use it.
From: Junio C Hamano @ 2009-03-25 19:40 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0903251446180.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Wed, 25 Mar 2009, Junio C Hamano wrote:
>
>> Suppose a project used to use subversion, but it migrated to git (not an
>> unheard-of scenario these days, I hope). The git repository now is the
>> authoritative one, all the development happens on this side.
>>
>> But in order to help:
>>
>> - people who have established their workflow to follow the project
>> (e.g. not necessarily contributing anything back, but just doing
>> regular "svn update");
>>
>> - people who have leftover local changes from the subversion days; and
>>
>> - other project infrastracture (e.g. trac) that the project hasn't
>> managed to interface to the new git repository yet;
>>
>> the project decides to keep feeding recent updates to the subversion
>> repository that used to be authoritative, even though it is now declared
>> read-only (i.e. the only update comes from the git end).
>
> Actually, this is easy: just configure the git repo to not fetch anything
> from the no-longer-authoritative subversion repository. git-vcs-svn would
> waste a bunch of time reimporting what it exported, but it wouldn't
> actually do anything with it (since it doesn't even have tracking refs to
> update). It could, of course, be optimized to avoid reimporting if it
> doesn't need to.
I am afraid that won't fly; my comment that started this subthread was not
about your "import" but was about your "export" part. It is about sending
the git branch to the other end, which is allowed to rewrite what we send
and force us to modify our history.
^ permalink raw reply
* Re: reverting initial commit
From: Giuseppe Bilotta @ 2009-03-25 19:45 UTC (permalink / raw)
To: git
In-Reply-To: <8c9a060903251133x33749041oc2a5152097da0ae8@mail.gmail.com>
On Wednesday 25 March 2009 19:33, Jacob Helwig wrote:
> On Wed, Mar 25, 2009 at 11:26, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> That's not even an revert. Can't you simply amend it away?
>>
>> $ git rm not-this-file
>> $ git commit --amend
>
> This is obviously the easier way. (Or a rebase --interactive)
Actually, rebase --interactive cannot be used to amend the first commit.
This is something that has hit me a couple of times when I realised, after
the second or third commit, that I needed to fix the first one. I found
the fastest way in this case to be to just format-patch all but the first
commit, reset --hard to the first commit, amend, and git am what I format-
patched.
I wish there was a way to tell rebase -i to go back to the first commit,
inclusive, but the two or three times I've tried hacking at it I never
managed to come to anything useful 8-/
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* [PATCH] builtin-push.c: Fix typo: "anythig" -> "anything"
From: Kevin Ballard @ 2009-03-25 20:09 UTC (permalink / raw)
To: git; +Cc: Kevin Ballard, Junio C Hamano
---
builtin-push.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 97db700..2eabcd3 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -73,7 +73,7 @@ static const char *warn_unconfigured_push_msg[] = {
"",
"You can specify what action you want to take in this case, and",
"avoid seeing this message again, by configuring 'push.default' to:",
- " 'nothing' : Do not push anythig",
+ " 'nothing' : Do not push anything",
" 'matching' : Push all matching branches (default)",
" 'tracking' : Push the current branch to whatever it is tracking",
" 'current' : Push the current branch"
--
1.6.2.1.471.g682837
^ permalink raw reply related
* [RFC GSoC 2009: git-submodule for multiple, active developers on active trees]
From: P Baker @ 2009-03-25 20:14 UTC (permalink / raw)
To: git
Greetings, I've been working on this for a while, but figured I'd send
it out while I've still got some time left before I submit it!
Any comments/questions would be welcome, as I'd really love to spend a
summer working on git.
Abstract:
This project focuses on upgrading git-submodule to manage code
created in external projects in ways that allow users to safely branch
and merge that code without loss of data or routine merge conflicts.
This will incorporate some changes made on the ‘pu’ branch, but will
also include making substantial changes to git-submodule underlying
code.
Content:
git-submodule is currently a good tool designed to allow developers to
leverage the work of others by incorporating external code into a
project. However, its implementation is underdeveloped as most core
users/developers are not heavy users of the application. In contrast
to much of the rest of the project, these holes create usage problems
when git does not act according to developers’ expectations. This
project would devote a summer of work to filling in the gaps so that
git-submodules contains the features necessary to fully exploit its
potential to track, update and edit external codebases incorporated
into a super-project.
As opposed to “remotes,” which also incorporate external code into a
project, submodules maintain the distinct nature of code and separate
the projects’ history. This is perfect for the intended nature of
“embedding foreign repositories in dedicated subdirectories of the
source tree.” For example, managing plug-ins within a larger,
standalone project that depends on the plug-ins. However, the
shortcomings of git-submodule create headaches for developers
attempting to use git and might prevent its adoption among those
developers not willing to either create laborious workarounds or
explicitly create manual management techniques.
Adding the features to fully enable git-submodule would allow heavy
users of projects built on other actively developed projects to use
git to manage this interaction in intuitive and predictable ways.
Adding this feature set would give current users a desired tool, boost
git’s credibility by providing a common feature among revision
systems, make git’s adoption for new and existing projects easier and,
as a result, likely boost git’s usage.
This project will consist of several stages: an initial community
based design review and investigation of specific requirements;
specifying and documenting the planned changes; writing and debugging
the code and related tests; and finally merging it into a public
release. The tentative timeline is:
End of May – Conclusively finish the public discussion regarding where
git-submodules needs to go
Beginning of June – Produce final specifications (including method stubs)
Middle of July – Finish active code and test development
End of July – Merge code into production release, fix public submitted bugs
Middle of August – Prepare code for final release and finish
user-facing documentation
This timeline should allow adequate flexibility while establishing
deadlines that ensure that the project will be completed in a timely
and efficient manner.
A few specific changes that this project will likely include are:
*use .git instead of .gitmodules
*move objects of submodules into .git/ directory
*git submodule update --init should initialize nested levels of submodules
*protect changes in local submodules when doing “git submodule update”
These changes, compiled from feature requests on the git mailing list
and formulated in response to blog posts regarding git-submodule’s
issues, are representative of the full list of changes. Most
development will need to occur within git-submodules.sh, without
changing much plumbing, however, other files might be affected by more
substantial changes.
While git-submodule is stable and operational, it is not widely
updated and has not seen much change beyond bug-fixes. After reaching
its current feature complete status, the last time a feature of any
novelty was included in a public release was August 2008. However,
some work has already been started on the ‘pu’ branch, which will need
to be reviewed and probably incorporated into this project. At the
conclusion of the project, one metric by which to evaluate its success
will be its acceptance in online communities. The final goal is to
make git a top-tier version control system in its management of
external code repositories.
My main usage of git started when managing a summer project as an
intern that had many of the requirements that make git-submodule
problematic: built in Ruby on Rails and dependent on other plug-ins,
some of which were managed in SVN. Even though the Ruby on Rails
community has popularized within itself the use of sub-modules to
manage plug-ins and quite a bit has been written on the topic, a
significant portion end either in frustration or convoluted
work-arounds. The problems and extremely confusing nature of
git-submodule led me to give up on it altogether (an unfortunately
common occurrence), and manage the code and updates to it by hand.
I currently am finishing my sophomore year as an Electrical Engineer
at the University of Pennsylvania (and dual-majoring in the Wharton
School of Business). I started to develop professionally when I took a
year off between high school and college to work for a small firm in
Silicon Valley, California developing diagnostic imaging software for
quality assurance and research on their products. Last summer I
developed an Ruby on Rails-based engine to test user-designed
investment strategies for QED Benchmark, a boutique hedge fund.
Thanks,
Phill Baker
^ permalink raw reply
* [PATCH] builtin-push.c: Fix typo: "anythig" -> "anything"
From: Kevin Ballard @ 2009-03-25 20:14 UTC (permalink / raw)
To: git; +Cc: Kevin Ballard, Junio C Hamano
Signed-off-by: Kevin Ballard <kevin@sb.org>
---
I forgot to add the Signed-off-by on my previous email.
builtin-push.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 97db700..2eabcd3 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -73,7 +73,7 @@ static const char *warn_unconfigured_push_msg[] = {
"",
"You can specify what action you want to take in this case, and",
"avoid seeing this message again, by configuring 'push.default' to:",
- " 'nothing' : Do not push anythig",
+ " 'nothing' : Do not push anything",
" 'matching' : Push all matching branches (default)",
" 'tracking' : Push the current branch to whatever it is tracking",
" 'current' : Push the current branch"
--
1.6.2.1.471.g682837
^ permalink raw reply related
* [PATCH 1/2] t7005-editor: Use $SHELL_PATH in the editor scripts
From: Johannes Sixt @ 2009-03-25 20:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The test sets up various shell scripts and uses them as commit message
editors. On Windows, we need a shebang line in order to recognize the
files as executable shell scripts. This adds it.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
This one and the next patch can go on top of js/windows-tests.
Or you again pull from
git://repo.or.cz/git/mingw/j6t.git for-junio
-- Hannes
t/t7005-editor.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/t/t7005-editor.sh b/t/t7005-editor.sh
index 2f8404a..e83bc8f 100755
--- a/t/t7005-editor.sh
+++ b/t/t7005-editor.sh
@@ -7,6 +7,7 @@ test_description='GIT_EDITOR, core.editor, and stuff'
for i in GIT_EDITOR core_editor EDITOR VISUAL vi
do
cat >e-$i.sh <<-EOF
+ #!$SHELL_PATH
echo "Edited by $i" >"\$1"
EOF
chmod +x e-$i.sh
--
1.6.2.1.224.g2225f
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox