On Windows, we do not have functions srandom() and random(). Use srand()
and rand(). These functions produce random numbers of lesser quality,
but for the purpose (a retry time-out) they are still good enough.
Signed-off-by: Johannes Sixt
---
There you have it: Look the other way for a while, and
On 5/21/2015 7:51 AM, Heiko Voigt wrote:
On Tue, May 19, 2015 at 02:29:55PM -0500, Robert Dailey wrote:
On Tue, May 19, 2015 at 5:44 AM, Heiko Voigt wrote:
On Mon, May 18, 2015 at 10:06:32AM -0500, Robert Dailey wrote:
Unfortunately I find it unintuitive and counter productive to perform
inli
Junio C Hamano wrote:
>
> > contrib/completion/git-completion.bash | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/contrib/completion/git-completion.bash
> > b/contrib/completion/git-completion.bash
> > index bfc74e9..3c00acd 100644
> > --- a/contrib/completion/git-completion.
On Fri, May 29, 2015 at 4:17 PM, Junio C Hamano wrote:
> By default, we should run clean-up after the editor we spawned gives
> us the edited result. Not adding one more LF after the template
> when it already ends with LF would not hurt, but an extra blank
> after the template material does not
On Fri, May 29, 2015 at 02:52:14PM -0700, Junio C Hamano wrote:
> > Currently we can do a = as part of the line after the first ref, such as
> >
> > symref=HEAD:refs/heads/master agent=git/2:2.4.0
> >
> > so I thought we want to keep this.
>
> I do not understand that statement.
>
> Capabili
On Fri, May 29, 2015 at 12:39:35PM -0700, Stefan Beller wrote:
> > I think this is the reverse case of next_capabilities in the upload-pack
> > side, so I'll make the reverse suggestion. :) Would it make things nicer
> > if both v1 and v2 parsed the capabilities into a string_list?
>
> Ok, I'll d
Stefan Beller writes:
>>> +Capability discovery (v2)
>>> +-
>>> ...
>>> + capability-list = *(capability) [agent LF] flush-pkt
>>> + capability = PKT-LINE("capability:" keyvaluepair LF)
>>> + agent= keyvaluepair LF
>>> + keyvaluepair = 1*(LC_
On Fri, May 29, 2015 at 1:35 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> @@ -1,11 +1,11 @@
>> Packfile transfer protocols
>> ===
>>
>> -Git supports transferring data in packfiles over the ssh://, git:// and
>> +Git supports transferring data in packfiles over
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-publi
Stefan Beller writes:
> @@ -1,11 +1,11 @@
> Packfile transfer protocols
> ===
>
> -Git supports transferring data in packfiles over the ssh://, git:// and
> +Git supports transferring data in packfiles over the ssh://, git://, http://
> and
When you have chance, can
Eric Sunshine writes:
> On Thu, May 28, 2015 at 2:22 PM, Junio C Hamano wrote:
>> Eric Sunshine writes:
>>
>>> Moreover, it lacks justification and explanation of why you consider
>>> the cleanup unnecessary. History [1] indicates that its application to
>>> -F but not -t was intentional.
>>>
>
Thomas Braun writes:
> Signed-off-by: Thomas Braun
> ---
>
> Hi,
>
> I added the sequencer commands for git revert. These are handy in case a git
> revert needs manual intervention.
This looks OK from a cursory read to me; asking opinions from those
who have touched the file in the recent past
Quentin Neill writes:
> Thanks for the thorough review!
> I have adjusted the commit messages and updated the documentation changes.
> I'm in trying to add tests, I'll probably have some issues but will
> post something that works soon.
Hi, I was sweeping my old mailbox for leftover bits, and no
On Tue, May 26, 2015 at 11:45 PM, Jeff King wrote:
> On Tue, May 26, 2015 at 03:01:10PM -0700, Stefan Beller wrote:
>
>> +void get_remote_capabilities(int in, char *src_buf, size_t src_len)
>> +{
>> + struct strbuf capabilities_string = STRBUF_INIT;
>> + for (;;) {
>> + int len
Marc Khouzam writes:
> Remove overriding of __git_index_file_list_filter
> since that method is no longer used in git-completion.bash.
> Overriding that method was needed before to get
> git-completion.bash to append a '/' to the end
> of directories; this does not seem to be needed anymore since
The term "index" is translated as "Staging-Area" to
not confuse beginners who don't know about Git's index.
Since the term "staging area" doesn't appear in original
Git messages (not even in the glossary) and "index" is a
well known term for experienced users, we should treat
"index" as a Git term
Noticed-by: Philip Oakley
Helped-by: Junio C Hamano
Signed-off-by: Stefan Beller
---
Moved information regarding the superproject from submodule to superproject,
and slightly reworded the superproject description.
Documentation/glossary-content.txt | 16
1 file changed, 16 in
Paul Tan writes:
> This is a re-roll of [1].
>
> This patch series improves test coverage of git-pull.sh, and is part of my
> GSoC project to rewrite git-pull into a builtin. Improving test coverage
> helps to prevent regressions that could occur due to the rewrite.
>
> Thanks Junio, Johannes and
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> Remi LESPINET writes:
>>
>>> Yes, that works if Foo is in an alias file, so that's clearly a bad
>>> example, I added quotes:
>>>
>>> git send-email --to='"Foo, Bar" '
>>
>> I'd further suggest replacing ", Bar" with something a bit more
>>
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> I recall "fetch --tags" was updated to become your "--tags-also" by
>> e66ef7ae (Merge branch 'mh/fetch-tags-in-addition-to-normal-refs',
>> 2013-12-12). Perhaps we should do the same on the push side.
>
> Would we still have a way to push tags
Junio C Hamano writes:
> Remi LESPINET writes:
>
>> Yes, that works if Foo is in an alias file, so that's clearly a bad
>> example, I added quotes:
>>
>> git send-email --to='"Foo, Bar" '
>
> I'd further suggest replacing ", Bar" with something a bit more
> realistic that people use in real
Junio C Hamano writes:
> I recall "fetch --tags" was updated to become your "--tags-also" by
> e66ef7ae (Merge branch 'mh/fetch-tags-in-addition-to-normal-refs',
> 2013-12-12). Perhaps we should do the same on the push side.
Would we still have a way to push tags only with this?
fetch and push
Stefan Beller writes:
>> So "Not a git repository" is the best Git can say.
>
> fatal: Permission denied while accessing .git directory
>
> does not imply we're having a git repository here at all, but rather
> sounds like "We wanted to check for you if this is a git repository,
> but we cannot d
Christian Neukirchen writes:
> I was just toying around, and it would have been cute.
>
>> Or didn't the alias work?
>
> It does. This seems to work just as well, and is easier:
Thanks; I was wondering if I gave something that was not portable or
something.
> git = !git
I'd call that th
On Fri, May 29, 2015 at 8:29 AM, Junio C Hamano wrote:
> Jonas Berlin writes:
>
>> Severity: Low
>> Impact: Confusion
>
> ;-)
>
>> Git version: 1.9.1
>>
>> If I don't have permissions to access the .git folder of a non-bare
>> git repository, I get the following output:
>>
>> fatal: Not a git r
Junio C Hamano writes:
> I recall "fetch --tags" was updated to become your "--tags-also" by
> e66ef7ae (Merge branch 'mh/fetch-tags-in-addition-to-normal-refs',
> 2013-12-12). Perhaps we should do the same on the push side.
builtin/push.c | 18 ++
1 file changed, 10 inserti
Junio C Hamano writes:
> Christian Neukirchen writes:
>
>> Junio C Hamano writes:
>>
>>> * You can help yourself with something like this, I suppose:
>>>
>>>[alias]
>>> git = "!sh -c 'exec git \"$@\"' -"
>>>
>>>but I personally feel that it is too ugly to live as part of our
>>>
Remi LESPINET writes:
> Yes, that works if Foo is in an alias file, so that's clearly a bad
> example, I added quotes:
>
> git send-email --to='"Foo, Bar" '
I'd further suggest replacing ", Bar" with something a bit more
realistic that people use in real life, e.g. ", Esq." or ", PhD"
(e.g
Eric Sunshine writes:
> wrote:
>
> validate_address_list(sanitize_address_list(
> split_address_list(@xx))
>
> That's pretty verbose, so introducing a new function to encapsulates
> that behavior might be reasonable.
Agreed, If you have any suggestion for the name of this function
Matthieu Moy writes:
> Perhaps a justification is that annotated tags are clearly meant to be
> public while lightweight tags can also be used as private bookmarks.
Ah, thanks. That makes perfect sense.
> In any case, the fact that it's been this way and documented this way
> since 2013 makes
Junio C Hamano writes:
> Remi Lespinet writes:
> Accept a list of emails separated by commas in flags --cc, --to
> and --bcc. Multiple addresses can already be given by using
> these options multiple times, but it is more convenient to allow
> cutting-and-pasting a list of addr
Thanks a lot for the discussion!
So I'll just fix it locally for me and we keep the state as is.
--
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
Duy Nguyen writes:
> On Tue, May 26, 2015 at 9:54 PM, Junio C Hamano wrote:
>> Duy Nguyen writes:
>>
>>> --unshallow::
>>> - If the source repository is complete, convert a shallow
>>> - repository to a complete one, removing all the limitations
>>> + If the source repository is co
Junio C Hamano writes:
> Yeah. I am not sure --tags-also is necessarily a good thing (I do
> not think "fetch --tags" is a good thing, either). If --follow-tags
> does not touch lightweight ones, that may be a bug we would want to
> fix. I did not mean to implement --follow-tags that way, and
Matthieu Moy writes:
> Guillaume Pages writes:
> ...
>> And during an interactive rebase:
>>
>> rebase in progress;
>
> This could even become "interactive rebase in progress".
>
> Most of the time, you're supposed to remember whether you ran "git
> rebase" with -i, but a typical use-case is whe
Christian Neukirchen writes:
> Junio C Hamano writes:
>
>> * You can help yourself with something like this, I suppose:
>>
>>[alias]
>> git = "!sh -c 'exec git \"$@\"' -"
>>
>>but I personally feel that it is too ugly to live as part of our
>>official suggestion, so please do n
Remi Galan Alfonso
writes:
> At first we wanted a clear indication about removing a commit in
> rebase -i. We didn't know about the noop command.
> - 'noop' does the same thing as 'drop' but for the user deleting a
>commit through 'noop' doesn't seem to be the proper way to use this
>com
Jonas Berlin writes:
> Severity: Low
> Impact: Confusion
;-)
> Git version: 1.9.1
>
> If I don't have permissions to access the .git folder of a non-bare
> git repository, I get the following output:
>
> fatal: Not a git repository (or any of the parent directories): .git
>
> Expected output:
Matthieu Moy writes:
> You did not provide any refspec (you provided but not
> ), hence --tags pushes only tags. So, this is the expected
> behavior.
Right.
> That said, we may want to add an option like --tags-also that would push
> tags _in addition_ to what would normally be pushed. --follo
Guillaume Pages writes:
> rebase in progress; onto d9d448a You are currently rebasing branch
> 'branche1' on 'd9d448a'. (fix conflicts and then run "git rebase
> --continue") (use "git rebase --skip" to skip this patch) (use "git
> rebase --abort" to check out the original branch) (5 commits app
At 10:38 +0200 29 May 2015, Christian Neukirchen wrote:
Junio C Hamano writes:
* You can help yourself with something like this, I suppose:
[alias]
git = "!sh -c 'exec git \"$@\"' -"
but I personally feel that it is too ugly to live as part of our
official suggestion, so p
Hi,
This is my pleasure to write this first message as git-multimail [1]
co-maintainer. git-multimail allows sending automatic notification
emails after a "git push". It was initially written by Michael Haggerty
as a greatly improved replacement for post-receive-email. Michael has been
a great dev
Guillaume Pages writes:
> Git version : 2.4.1.652.g8fd8657
>
> When we run git checkout -babar, we would expect an error message like
> "unknown switch 'a' " and we get "Switched to a new branch 'abar'".
Yes, the option-parser accepts sticked form (-bbranch) and unsticked (-b
branch). This is
Eric Sunshine writes:
> Paul Tan writes:
>
> >> Remi LESPINET writes:
> >> + tmp_name=${2-"temporary"}
> >
> > I don't think the quotes are required. Also, I don't feel good about
> > swapping the order of the arguments to git-checkout. (or making $2 an
> > optional argument). As the patc
Test that when --dry-run is provided to git-pull, it does not make any
changes, namely:
* --dry-run gets passed to git-fetch, so no FETCH_HEAD will be created
and no refs will be fetched.
* The index and work tree will not be modified.
Signed-off-by: Paul Tan
---
t/t5521-pull-options.sh | 1
Commit 19a7fcb (allow pull --rebase on branch yet to be born,
2009-08-11) special cases git-pull on an unborn branch in a different
code path such that git-pull --rebase is still valid even though there
is no HEAD yet.
This code path still ensures that there is no index in order not to lose
any st
Since b10ac50 (Fix pulling into the same branch., 2005-08-25), git-pull,
upon detecting that git-fetch updated the current head, will
fast-forward the working tree to the updated head commit.
Implement tests to ensure that the fast-forward occurs in such a case,
as well as to ensure that the user-
a8c9bef (pull: improve advice for unconfigured error case, 2009-10-05)
fully established the current advices given by git-pull for the
different cases where git-fetch will not have anything marked for merge:
1. We fetched from a specific remote, and a refspec was given, but it
ended up not fetc
When testing a fast-forward merge with git-pull, check to see if the
reflog action is "pull" with the arguments passed to git-pull.
While we are in the vicinity, remove the empty line as well.
Signed-off-by: Paul Tan
---
Notes:
v5:
* Loosen up the pattern used for search-and-replac
Since rebasing on top of multiple upstream branches does not make sense,
since 51b2ead (disallow providing multiple upstream branches to rebase,
pull --rebase, 2009-02-18), git-pull explicitly disallowed specifying
multiple branches in the rebase case.
Implement tests to ensure that git-pull fails
Many tests in t5520 used the following to test the contents of files:
test `cat file` = expected
or
test $(cat file) = expected
These 2 forms, however, will be affected by field splitting and,
depending on the value of $IFS, may be split into multiple arguments,
making the test
Commit d38a30d (Be more user-friendly when refusing to do something
because of conflict., 2010-01-12) introduced code paths to git-pull
which will error out with user-friendly advices if the user is in the
middle of a merge or has unmerged files.
Implement tests to ensure that git-pull will not ru
This is a re-roll of [1].
This patch series improves test coverage of git-pull.sh, and is part of my
GSoC project to rewrite git-pull into a builtin. Improving test coverage
helps to prevent regressions that could occur due to the rewrite.
Thanks Junio, Johannes and Stefan for the reviews last ro
On Fri, May 29, 2015 at 01:34:50PM +0200, Christian Couder wrote:
> >> +--get-name-regexp::
> >> + Like --get-regexp, but shows only matching variable names, not its
> >> + values.
> >
> > which makes it clear why it is needed. The distinction is purely
> > about the output, i.e. the valu
On Thu, May 28, 2015 at 9:20 PM, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
>> @@ -16,11 +16,12 @@ SYNOPSIS
>> 'git config' [] [type] [-z|--null] --get-all name [value_regex]
>> 'git config' [] [type] [-z|--null] --get-regexp name_regex
>> [value_regex]
>> 'git config' [] [type] [-z|--nul
On Tue, May 26, 2015 at 9:54 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> --unshallow::
>> - If the source repository is complete, convert a shallow
>> - repository to a complete one, removing all the limitations
>> + If the source repository is complete, convert all shallow
>
Hi Michael,
On 2015-05-29 11:53, Michael J Gruber wrote:
> Johannes Schindelin venit, vidit, dixit 26.05.2015 14:35:
>> For what it is worth, I tried my hand a couple of years ago at the project
>> to move git-new-workdir to use the `.git` *file* and alternates mechanisms,
>> but that does not w
On Fri, May 29, 2015 at 4:53 PM, Michael J Gruber
wrote:
> Isn't that basically the approach that "git checkout --to" is taking? Is
> that one "Windows proof"?
It should be.
> I've lost track of its status, though.
It should be fine to use as long as you don't do checkout --to on a
submodule. S
After this discussion I eventually agree that it would be better
upgrading git status than creating a new command.When people use git
status, it means that they need information to continue their work, so
if you don't even know that you are in a rebase, you will very likely
need information about t
Hi,
On Fri, May 29, 2015 at 5:52 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> * pt/pull-tests (2015-05-18) 8 commits
>> - t5520: check reflog action in fast-forward merge
>> - t5521: test --dry-run does not make any changes
>> - t5520: test --rebase failure on unborn branch with in
Git version : 2.4.1.652.g8fd8657
When we run git checkout -babar, we would expect an error message like
"unknown switch 'a' " and we get "Switched to a new branch 'abar'". We
are not sure since we don't entirely understand the syntax -b
which is shown in the documentation, but as average user
John Lee venit, vidit, dixit 27.05.2015 09:34:
> On Wed, 27 May 2015, Jeff King wrote:
>
>> If you are interested in looking further, see how the %patch_mode hash
>> is defined in git-add--interactive.perl. Specifically, note that "add
>> -p" is just one case: diff against the index and apply with
Johannes Schindelin venit, vidit, dixit 26.05.2015 14:35:
> Hi Paul,
>
> On 2015-05-26 14:20, Paul Smith wrote:
>> On Tue, 2015-05-26 at 11:53 +0200, Johannes Schindelin wrote:
>>> The biggest problem with `mklink` is that it is only supported on
>>> Windows Vista and later, while I really like to
Junio C Hamano writes:
> * You can help yourself with something like this, I suppose:
>
>[alias]
> git = "!sh -c 'exec git \"$@\"' -"
>
>but I personally feel that it is too ugly to live as part of our
>official suggestion, so please do not send a patch to add it as
>a buil
At first we wanted a clear indication about removing a commit in
rebase -i. We didn't know about the noop command.
- 'noop' does the same thing as 'drop' but for the user deleting a
commit through 'noop' doesn't seem to be the proper way to use this
command. Moreover 'noop' is not documented
Hi,
Severity: Low
Impact: Confusion
Git version: 1.9.1
If I don't have permissions to access the .git folder of a non-bare git
repository, I get the following output:
fatal: Not a git repository (or any of the parent directories): .git
Expected output:
fatal: Permission denied while acces
Every time we run "make", we update perl/PM.stamp, which
contains a list of all of the perl module files (if it's
updated, we need to rebuild perl/perl.mak, since the
Makefile will not otherwise know about the new files).
This means that every time "make" is run, we see:
GEN perl/PM.stamp
The rule for "git-instaweb" depends on "gitweb". This makes
no sense, because:
1. git-instaweb has no build-time dependency on gitweb; it
is a run-time dependency
2. gitweb is a directory that we want to recursively make
in. As a result, its recipe is marked .PHONY, which
cause
We force the GIT-BUILD-OPTIONS recipe to run every time
"make" is invoked. We must do this to catch new options
which may have come from the command-line or environment.
However, we actually update the file's timestamp each time
the recipe is run, whether anything changed or not. As a
result, any
Junio C Hamano wrote:
> li...@haller-berlin.de (Stefan Haller) writes:
>
> > I guess the next best solution would be to also have a pre-push hook
> > that performs the same checks again, just in case the bad code managed
> > to get past the pre-commit hook for some reason or other. This feels
>
I've noticed that running "make" on a fully-built git tree still builds
a lot of things:
$ make >/dev/null 2>&1 && make
GEN perl/PM.stamp
SUBDIR gitweb
GEN git-add--interactive
GEN git-difftool
GEN git-archimport
GEN git-cvsexportcommit
GEN git-cvsimport
71 matches
Mail list logo
