The documentation of '-A' is very confusing for someone who doesn't
already know what it does. In particular, it describes the option's
meaning by reference to that of '-u', but it's no more similar to the
latter than it is to the default behavior. Describe it directly (and
in a way that uses the
If take_worktree_changes is true, then the logic around
option_with_implicit_dot ensures argc is positive by this point.
So require_pathspec never has an effect.
Signed-off-by: Greg Price
---
builtin/add.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/builtin/add.c b/bui
On Tue, Mar 05, 2013 at 07:45:22AM -0800, Junio C Hamano wrote:
> Heiko Voigt writes:
>
> >> + if test -z "$force"
> >> + then
> >> + git rm -n "$sm_path" ||
> >> + die "$(eval_gettext "Submodule work tree
> >> '
"Philip Oakley" writes:
> Given that many folk appear to trip up with their rebase mindset, does
> this suggest that a few tweaks to the manual may be in order to stop
> such misunderstandings?
Perhaps.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
From: "Junio C Hamano"
Sent: Tuesday, March 05, 2013 9:35 PM
Dale Worley writes:
From: Junio C Hamano
I think this is to be expected for "git rebase", as it does not even
look at merges. It is a way to find non-merge commits that haven't
been applied yet, and apply them to the upstream to
The new option "--follow-tags" tells "git push" to push annotated
tags that are missing from the other side and that can be reached by
the history that is otherwise pushed out.
For example, if you are using the "simple", "current", or "upstream"
push, you would ordinarily push the history leading
Signed-off-by: Junio C Hamano
---
commit.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/commit.c b/commit.c
index d12e799..b4512ab 100644
--- a/commit.c
+++ b/commit.c
@@ -876,8 +876,7 @@ int in_merge_bases_many(struct commit *commit, int
nr_reference, struct commit *
clear_commit_marks(struct commit *, unsigned) only can clear flag
bits starting from a single commit; introduce an API to allow
feeding an array of commits, so that flag bits can be cleared from
commits reachable from any of them with a single traversal.
Signed-off-by: Junio C Hamano
---
commit.
Similar to in_merge_bases(commit, other) that returns true when
commit is an ancestor (i.e. in the merge bases between the two) of
the other commit, in_merge_bases_many(commit, n_other, other[])
checks if commit is an ancestor of any of the other[] commits.
Signed-off-by: Junio C Hamano
---
comm
The primary change since the last round is that it pushes out only
annotated tags that are missing from the other side.
Junio C Hamano (4):
commit.c: add clear_commit_marks_many()
commit.c: add in_merge_bases_many()
commit.c: use clear_commit_marks_many() in in_merge_bases_many()
push: --f
Thanks to everyone. The information was useful.
On 24 February 2013 21:31, Shawn Pearce wrote:
> On Sun, Feb 24, 2013 at 8:58 AM, Thomas Koch wrote:
>> Yuri Mikhailov:
>>> Dear Git community,
>>>
>>> I am a Software Developer and I have been using git for a while.
>>> Currently my company is loo
From: "Gene Thomas [DATACOM]"
Sent: Tuesday, March 05, 2013 1:05 AM
Philip,
Thanks for your reply.
The original branch is not 'destroyed', rather the pointer to the
previous tip is within the logs.
Is that the 'git log' log or internal logs? Are you sure? There
doesn't appear to be a
In "reflog expire" we were not clearing the REACHABLE bit from
objects reachable from the tip of refs we marked earlier.
Signed-off-by: Junio C Hamano
---
builtin/reflog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/reflog.c b/builtin/reflog.c
index b3c9e27..ef56e
Dale Worley writes:
>> From: Junio C Hamano
>>
>> I think this is to be expected for "git rebase", as it does not even
>> look at merges. It is a way to find non-merge commits that haven't
>> been applied yet, and apply them to the upstream to create a new
>> linear history.
>
> I disagree. "g
On Tue, Mar 05, 2013 at 10:14:42PM +0100, Jose Garcia Juanino wrote:
> Is there any hook in Git similar to start-commit subversion hook? The
> requirements would be:
>
> 1- A hook on the server side (as pre-receive)
> 2- It will execute the actions *before* the begin of transaction
> (pre-receive
> From: Junio C Hamano
>
> I think this is to be expected for "git rebase", as it does not even
> look at merges. It is a way to find non-merge commits that haven't
> been applied yet, and apply them to the upstream to create a new
> linear history.
I disagree. "git rebase" is not characterized
On Tue, Mar 5, 2013 at 3:51 PM, Jens Lehmann wrote:
> Am 05.03.2013 19:34, schrieb Junio C Hamano:
>> Eric Cousineau writes:
>>> ...
>> I am not entirely convinced we would want --include-super in the
>> first place, though. It does not belong to "submodule foreach";
>> it is doing something _ou
Hello,
Is there any hook in Git similar to start-commit subversion hook? The
requirements would be:
1- A hook on the server side (as pre-receive)
2- It will execute the actions *before* the begin of transaction
(pre-receive hook needs the references already pushed before).
For example, it would
On 03/05/2013 07:47 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> I'm also not sure how useful those really are in practice. I have not
>> used "union" myself ever. And in the example that started this thread, I
>> find the use of "union" slightly dubious.
>
> Yeah, I do not think anybody s
Am 05.03.2013 19:34, schrieb Junio C Hamano:
> Eric Cousineau writes:
>
>> Would these be the correct behaviors of Heiko's implementation?
>
> I do not think Heiko already has an implementation, but let's try to
> see how each example makes sense.
>
>> git submodule foreach # Empty command, pre
On Tue, Mar 05, 2013 at 11:17:11AM -0800, Junio C Hamano wrote:
> I may have tentatively tagged the tip of 'master' as v1.8.2 in my
> private repository, started the integration testing, but may not be
> confident enough to push out the branch nor the tag yet. I may have
> an experimental topic t
Jeff King writes:
> Yeah, I think that is another sensible variant. It does not really
> "backfill" in the way that Junio's patch does (e.g., if you forgot to
> push out v1.6 to a remote 2 weeks ago and now you are pushing out v1.7,
> Junio's patch will magically fill it in).
I may have tentativ
Jeff King writes:
> I'm also not sure how useful those really are in practice. I have not
> used "union" myself ever. And in the example that started this thread, I
> find the use of "union" slightly dubious.
Yeah, I do not think anybody sane used "union" outside toy examples.
IIRC, it was origi
Eric Cousineau writes:
> Would these be the correct behaviors of Heiko's implementation?
I do not think Heiko already has an implementation, but let's try to
see how each example makes sense.
> git submodule foreach # Empty command, pre-order
> git submodule foreach --pre-order # Same behavior
On Tue, Mar 05, 2013 at 12:49:57PM +0100, Michael Haggerty wrote:
> > One obvious alternative is only to push annotated tags with this
> > feature. That has the downside of not matching fetch's behavior, as well
> > as withholding the feature from people whose workflow uses only
> > unannotated ta
On Tue, Mar 05, 2013 at 10:15:20AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > But I wonder if fetching and pushing are different in that respect. You
> > are (usually) fetching from a public publishing point, and it is assumed
> > that whatever is there is useful for sharing. The onl
Jeff King writes:
> But I wonder if fetching and pushing are different in that respect. You
> are (usually) fetching from a public publishing point, and it is assumed
> that whatever is there is useful for sharing. The only reason to limit
> it is to save time transferring objects the user does n
On Tue, Mar 05, 2013 at 07:44:13AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > I think the merge will produce the results you are looking for. This
> > would have to be configurable, though, as it is a regression for
> > existing users of "union", which would want the duplicate-line
>
On Tue, Mar 05, 2013 at 02:44:41PM +, Ævar Arnfjörð Bjarmason wrote:
> Change the semantics of "git --help" to show the help for the
> command is aliased to, instead of just saying:
>
> `git ' is aliased to `'
>
> E.g. if you have "checkout" aliased to "co" you won't get:
>
> $ gi
On Tue, Mar 05, 2013 at 07:58:45AM -0800, Junio C Hamano wrote:
> > This will find anything under refs/tags, including annotated and
> > non-annotated tags. I wonder if it is worth making a distinction. In
> > many workflows, unannotated tags should not be leaked out to public
> > repos. But becau
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Matthieu Moy writes:
> Commit fea16b47b60 (Fri Jan 11 19:48:43 2013, Manlio Perillo,
> git-completion.bash: add support for path completion), introduced a new
> __gitcomp_file function that uses the bash builtin "compgen". The
> function was redefined for ZSH in the deprecated section of
> git-co
"H.Merijn Brand" writes:
> A single word that is (already) known to git as being a valid command
> to do --help with. I which case I fully agree.
Just to insist on "that is known to git as being a valid command".
Compare:
$ git foo --help
`git foo' is aliased to `bar'
with
$ git foo --help
N
Ævar Arnfjörð Bjarmason writes:
> No objection to the patch in principle though? I.e. not showing you
> what the alias points to.
I am not interested enough to even strongly object to such a change,
because it is not reasonable to react with a "I know!" to the output
of "git co --help", i.e. "'g
On Tue, Mar 5, 2013 at 10:09 AM, Junio C Hamano wrote:
> Heiko Voigt writes:
>
>> On Mon, Mar 04, 2013 at 03:00:45PM -0800, Junio C Hamano wrote:
>>> So if you want a single boolean to toggle between the current
>>> behaviour and the other one, it would be --post-order. But you may
>>> at least
On Tue, Mar 5, 2013 at 5:16 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> Change the semantics of "git --help" to show the help for the
>> command is aliased to, instead of just saying:
>>
>> `git ' is aliased to `'
>>
>> E.g. if you have "checkout" aliased to "co" you w
Ævar Arnfjörð Bjarmason writes:
> Change the semantics of "git --help" to show the help for the
> command is aliased to, instead of just saying:
>
> `git ' is aliased to `'
>
> E.g. if you have "checkout" aliased to "co" you won't get:
>
> $ git co --help
> `git co' is aliased to `
Michael Weiser writes:
> On Tue, Nov 27, 2012 at 05:30:04PM +0100, Michael Weiser wrote:
>
>> Support determining the binaries' installation path at runtime even if
>> called without any path components (i.e. via search path). Implement
>> fallback to compiled-in prefix if determination fails or
Heiko Voigt writes:
> On Mon, Mar 04, 2013 at 03:00:45PM -0800, Junio C Hamano wrote:
>> So if you want a single boolean to toggle between the current
>> behaviour and the other one, it would be --post-order. But you may
>> at least want to consider pros and cons of allowing users to give
>> two
On Tue, 05 Mar 2013 16:42:52 +0100, Johannes Sixt
wrote:
> Am 3/5/2013 15:44, schrieb Ævar Arnfjörð Bjarmason:
> > Change the semantics of "git --help" to show the help for the
> > command is aliased to, instead of just saying:
> >
> > `git ' is aliased to `'
> >
> > E.g. if you have "che
Jeff King writes:
> Should this be called "--follow-tags"? That makes more sense to me, as
> you are catching all tags.
Perhaps. We are sending all zero-or-more relevant tags, so I agree
that plural form is more appropriate. I have a doubt about
"follow", though; inertia made me use "follow",
Heiko Voigt writes:
>> +if test -z "$force"
>> +then
>> +git rm -n "$sm_path" ||
>> +die "$(eval_gettext "Submodule work tree
>> '\$sm_path' contains local modifications; use '-f' to discard them")"
>
Jeff King writes:
> I think the merge will produce the results you are looking for. This
> would have to be configurable, though, as it is a regression for
> existing users of "union", which would want the duplicate-line
> suppression (or maybe not; it will only catch such duplicates at the
> beg
Am 3/5/2013 15:44, schrieb Ævar Arnfjörð Bjarmason:
> Change the semantics of "git --help" to show the help for the
> command is aliased to, instead of just saying:
>
> `git ' is aliased to `'
>
> E.g. if you have "checkout" aliased to "co" you won't get:
>
> $ git co --help
> `git
Nope, it was a bug in my pre-commit hook. See the other response to this
message.
Robert Irelan | Server Systems | Epic | (608) 271-9000
-Original Message-
From: Torsten Bögershausen [mailto:tbo...@web.de]
Sent: Tuesday, March 05, 2013 4:41 AM
To: Robert Irelan
Cc: git@vger.kernel.org
Yes, you're correct, it was a bug in my pre-commit hook. Thanks!
For posterity, the issue is that I had the following line:
git diff -z --cached --name-only | egrep -z '\.(pl|pm|t)$' | \
while read -d'' -r f; do ...
In Bash, when `read` is passed the `-d` option with a zero-lengt
rab...@rabbit.us wrote on Mon, 04 Mar 2013 10:29 +1100:
> I was tinkering with a massive git repository (actually a bup
> repository, but it is a standard valid git repo underneath). While
> validating that a repack ran succesfully I executed the command:
>
> git rev-list --objects --all > rev.
Change the semantics of "git --help" to show the help for the
command is aliased to, instead of just saying:
`git ' is aliased to `'
E.g. if you have "checkout" aliased to "co" you won't get:
$ git co --help
`git co' is aliased to `checkout'
But will instead get the manpage for gi
Commit d8cf908c (config.mak.in: remove unused definitions) removed
exec_prefix = @exec_prefix@
from config.mak.in, because nobody directly used ${exec_prefix}, but
overlooked that other autoconf definitions could indirectly expand that
variable.
For example the following snippet from config.
Duy Nguyen writes:
> - # Not currently on any branch.
> + # Detached at $ONTO
Without the context, I don't think "Detached" alone says something to
the user. "Detached HEAD at ..." would IMHO be clearer and at least give
the user enough keywords to search the web/doc for an explanation.
Hello,
On Tue, Nov 27, 2012 at 05:30:04PM +0100, Michael Weiser wrote:
> Support determining the binaries' installation path at runtime even if
> called without any path components (i.e. via search path). Implement
> fallback to compiled-in prefix if determination fails or is impossible.
I see t
On 03/05/2013 09:22 AM, Jeff King wrote:
> On Mon, Mar 04, 2013 at 04:54:39PM -0800, Junio C Hamano wrote:
> [...]
> This will find anything under refs/tags, including annotated and
> non-annotated tags. I wonder if it is worth making a distinction. In
> many workflows, unannotated tags should not
OK new try. This
- no longer requires 1/5 (i'll resend full series later when the
wanted behavior is found)
- shows either "detached from" or "detached at". We could even do "4
commits from detached point XXX", like we do "5 commits ahead of
upstream". But I'm not sure if we should do that.
On 04.03.13 19:15, Robert Irelan wrote:
> Hello all:
>
> This is my first time posting to this mailing list, but it appears to
> me, through a Google search, that this is where you go to report what
> might be bugs. I'm not sure if this is a bug or not, but it is
> mysterious to me.
>
> My git re
2013/3/5 David Aguilar :
> On Mon, Mar 4, 2013 at 7:47 AM, Jari Pennanen wrote:
>> I'm actually aware of that. Problem is the normal .gitignore files
>> must *not* be used in the second GIT_DIR at all, in my case it's for
>> syncing so I need to sync almost all files (including stuff inside
>> .gi
On Mon, Mar 4, 2013 at 7:47 AM, Jari Pennanen wrote:
> 2013/3/4 Matthieu Moy :
>> There is already core.excludesfile, which does not replace the usual
>> .gitignore but comes in addition. The common use is a user-wide ignore
>> file, not a per-directory one.
>
> I'm actually aware of that. Problem
> In a usual set-up, an access to git@server:javier/pfc will first
> locate the home directory for the user "git" (the token before "@"),
> and then its subdirectory javier/pfc, e.g. /home/git/javier/pfc,
> while an access to server:javier/pfc will first locate the home
> directory of whatever user
On Tue, Mar 05, 2013 at 04:03:26AM -0500, Jeff King wrote:
> You might be able to get by with a version of the "union" driver that
> asks the 3-way merge driver to be less aggressive about shrinking the
> conflict blocks. For example, with this patch to git:
>
> diff --git a/ll-merge.c b/ll-merge
On Mon, Mar 04, 2013 at 05:46:48PM +0100, David Krmpotic wrote:
> We started working on a .NET app and the XML project file (.csproj)
> got corrupted (a few closing tag missing).
>
> 79
> 80 SlovaricaForm.cs
> 81+
> 82+ Form
> 83+
> 84+
> 85
Commit fea16b47b60 (Fri Jan 11 19:48:43 2013, Manlio Perillo,
git-completion.bash: add support for path completion), introduced a new
__gitcomp_file function that uses the bash builtin "compgen". The
function was redefined for ZSH in the deprecated section of
git-completion.bash, but not in the new
On Mon, Mar 04, 2013 at 04:54:39PM -0800, Junio C Hamano wrote:
>This is primarily to scratch my own itch; after tagging an rc or
>final release, I've been doing
>
> git push k.org v1.8.2
> git push k.org
>
>and the first step can easily be forgotten. With
>
> g
Hi,
wrong mailing list for Windows questions. This is the correct one:
http://groups.google.com/group/msysgit
On Mon, Mar 04, 2013 at 04:43:27PM -0700, J.V. wrote:
> What is the best way to host a shared git repo on a Windows 2008
> box? I would like to create a repo on the 2008 box (that every
62 matches
Mail list logo
