On Sat, 23 Mar 2013 16:32:47 +, Ben Walton
wrote:
> Hello,
Still failing in 1.8.2.1
> On Fri, Mar 22, 2013 at 7:57 PM, H.Merijn Brand wrote:
> > git-1.8.2, perl-5.16.3, File::Temp-0.23
> >
> > Without patch:
> >
> > $ git svn fetch
> > 'tempfile' can't be called as a method at
> > /pro/li
So far, all the users of the decoration API used decoration that
only grows and discarded at the end of the program execution.
Introduce for_each_decoration() that lets the caller iterate over
all defined decorations and use it to implement clear_decoration()
function.
Signed-off-by: Junio C Hama
Ever since 530e741c726a (Start preparing the API documents.,
2007-11-24) added a placeholder to describe the various APIs,
the decorate API was never documented.
Signed-off-by: Junio C Hamano
---
Documentation/technical/api-decorate.txt | 35 ++--
1 file changed, 33 i
On Sun, Apr 07, 2013 at 09:03:25PM -0500, Felipe Contreras wrote:
> > I'm still not very excited about this approach, as it is racy to detect
> > errors. E.g., there is nothing to say that the helper does not close the
> > pipe to fast-import prematurely and then die afterwards, leaving the
> > re
On Sun, Apr 7, 2013 at 7:51 PM, Jeff King wrote:
> On Sun, Apr 07, 2013 at 01:45:06AM -0600, Felipe Contreras wrote:
>
>> diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
>> index f387027..efe67e2 100755
>> --- a/t/t5801-remote-helpers.sh
>> +++ b/t/t5801-remote-helpers.sh
>> @@
At 20:06 -0400 07 Apr 2013, I wrote:
At 16:48 -0700 07 Apr 2013, Jonathan Nieder wrote:
Would it make sense for the message to say something like the
following?
fatal: alternate object store '/path/to/repo.git/objects' is not a
local directory
That would also avoid lying to the user
On Sun, Apr 07, 2013 at 10:21:33AM -0700, Junio C Hamano wrote:
> As to the order of comparison to match the order on the number line,
> e.g. write "0 < something" or "negative < 0" to let readers more
> easily visualize in what relation on the number line the quantity of
> each side of the compar
On Sun, Apr 07, 2013 at 01:45:06AM -0600, Felipe Contreras wrote:
> diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
> index f387027..efe67e2 100755
> --- a/t/t5801-remote-helpers.sh
> +++ b/t/t5801-remote-helpers.sh
> @@ -166,4 +166,23 @@ test_expect_success 'push ref with exist
At 16:51 -0700 07 Apr 2013, Jonathan Nieder wrote:
- char *ref_git;
+ char *ref_git, *repo;
[...]
+ repo = (char *)read_gitfile(mkpath("%s/.git", ref_git));
Why not make repo a "const char *" and avoid the cast? The above
would seem to make it too tempting to treat the ret
At 16:48 -0700 07 Apr 2013, Jonathan Nieder wrote:
Hi Aaron,
Thanks for the feedback.
Aaron Schrab wrote:
Do not report an argument to clone's --reference option is not a local
directory. Nothing checks for the actual directory so we have no way to
know if whether or not exists. Telling
On Sun, Apr 7, 2013 at 2:46 PM, Jonathan Nieder wrote:
> The remote helper infrastructure is certainly being unhelpful here. I
> wonder if transport-helper should just pass --signed-tag=strip and be
> done with it (leaving open the possibility of a capability to switch
> to --signed-tag=verbatim
The latest maintenance release Git v1.8.2.1 is now available at
the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
ad9f833e509ba31c83efe336fd3599e89a39394b git-1.8.2.1.tar.gz
bf4abd0e020d24ee47c64760e9fe4372c
A maintenance release Git v1.8.1.6 is now available at the
usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
135a4fd6c025ab16560694da110a1476a9b83de2 git-1.8.1.6.tar.gz
a9b004bf1b1922f09cb45a7a388bd452399db30c
Aaron Schrab wrote:
> --- a/builtin/clone.c
> +++ b/builtin/clone.c
> @@ -231,12 +231,19 @@ static void strip_trailing_slashes(char *dir)
>
> static int add_one_reference(struct string_list_item *item, void *cb_data)
> {
> - char *ref_git;
> + char *ref_git, *repo;
[...]
> + repo =
Hi Aaron,
Aaron Schrab wrote:
> Do not report an argument to clone's --reference option is not a local
> directory. Nothing checks for the actual directory so we have no way to
> know if whether or not exists. Telling the user that a directory doesn't
> exist when that isn't actually known may
Do not report an argument to clone's --reference option is not a local
directory. Nothing checks for the actual directory so we have no way to
know if whether or not exists. Telling the user that a directory doesn't
exist when that isn't actually known may lead him or her on the wrong
path to fin
Try reading gitfile files when processing --reference options to clone.
This will allow, among other things, using a submodule checked out with
a recent version of git as a reference repository without requiring the
user to have internal knowledge of submodule layout.
Signed-off-by: Aaron Schrab
This is a demonstration of a mildly-interesting security concern
relating to Git & git-filter-branch - not a vulnerability in Git
itself, just in the way it can be used. I thought it was interesting
to demonstrate that there is sometimes an avenue of attack for
recovering sensitive data that's been
Hi,
Simon Ruderich wrote:
> On Sun, Apr 07, 2013 at 12:46:23PM -0500, Felipe Contreras wrote:
>> +test_expect_success 'cover letter auto' '
>> +mkdir -p tmp &&
>> +test_when_finished "rm -rf tmp;
[...]
> I'm not sure if it's better to use test_when_finished with rm or
> just && rm -rf tmp
Hi,
John Keeping wrote:
> This adds a prefix string to any filename arguments encountered after it
> has been specified.
I assume this is a way of passing the prefix in? In that case, I
think a good UI would be
git rev-parse --prefix=Documentation/
That sounds like a useful thing and
Hi John,
John Keeping wrote:
> It appears to be impossible to push signed tags using a remote helper
> that supports only fast-export.
[...]
> fatal: Encountered signed tag 572a535454612a046e7dd7404dcca94d6243c788;
> use --signed-tag= to handle it.
> fatal: Error while running fas
Jonathan Nieder wrote:
> What's stopping the core object code of git parsing .gitmodules?
Nothing, except that it's perversely unnatural for object parsing code
to parse something outside the object store.
> What
> is the core object code?
parse_link_buffer(): the conventions have already been s
Christian Couder wrote:
> About generation numbers, please have a look at the thread leading to this
> message:
>
> http://thread.gmane.org/gmane.comp.version-control.git/177146/focus=177586
>
> In short, generation numbers were not such a good idea because there were
> already existing ways to get
Ramkumar Ramachandra wrote:
> It's about the core object code of git parsing links, as
> opposed to a fringe submodule.c/ submodule.sh parsing .gitmodules.
What's stopping the core object code of git parsing .gitmodules? What
is the core object code? How does this compare to other m
So, it turns out, `--reject` is not default for git-am / git-apply,
and has to be explicitly specified for the desired behaviour. Makes
no sense, if you ask me, and especially the below error message, which
tells you nothing about having to use `--reject`:
% git am ../grok-old-hg-git.git/00{27,28
John Keeping wrote:
> I do. I quite often use "git add -p" to sort things out and submodules
> currently fit into that seamlessly: I can add the submodule and then
> wait until later to commit it, without needing to either clone and
> remember to "submodule add" later or commit and play with rebas
The documentation says:
the output from the command omits entries that match the
tree.
But currently "added in branch1" and "removed in branch1" (both while
unchanged in branch2) do print output. Change this so that the
behaviour matches the documentation.
Signed-off-by: John K
On Mon, Apr 08, 2013 at 02:19:10AM +0530, Ramkumar Ramachandra wrote:
> Jens Lehmann wrote:
> > * A link object has no unstaged counterpart that a file easily
> > has. What would that mean for adding a submodule and then
> > unstaging it (or how could we add a submodule unstaged, like
> > you
Jens Lehmann wrote:
> * Easier coding, as we find all information in a single object.
It's not just the difference between a single location versus multiple
locations. It's about the core object code of git parsing links, as
opposed to a fringe submodule.c/ submodule.sh parsing .gitmodules.
When
Jens Lehmann wrote:
> Just to be sure: I think we agree that both approaches are capable
> of allowing all relevant use cases, because they store the same
> information?
Yes.
> Disclaimer: I am not opposed to the link object per se, but after
> all we are talking about severely changing user visi
Am 07.04.2013 20:44, schrieb Ramkumar Ramachandra:
> Jens Lehmann wrote:
>> The whole feature list is full of red herrings like this which
>> have nothing to do with the advantages of a new object, but talk
>> about UI issues which are easy to solve in both worlds.
>
> Really? git-submodule.sh wa
Am 07.04.2013 21:55, schrieb John Keeping:
> With the recent discussion, I wondered how hard it would be to add
> SUBDIRECTORY_OK=Yes to git-submodule.sh and it doesn't seem that bad.
>
> Note that this series currently lacks both tests and documentation
> updates. Also I have made no attempt to
John Keeping writes:
> Having re-read the manpage, I think you're right that we should just
> resolve the "both added identically" case cleanly, but I wonder whether
> some of the other cases should also be resolved cleanly.
>
> git-merge-tree(1) says:
>
> the output from the command omits en
Use the new rev-parse --filename-prefix option to process all paths
given to the submodule command, dropping the requirement that it be run
from the top-level of the repository.
Signed-off-by: John Keeping
---
git-submodule.sh | 7 +++
1 file changed, 7 insertions(+)
diff --git a/git-submod
This adds a prefix string to any filename arguments encountered after it
has been specified.
Signed-off-by: John Keeping
---
builtin/rev-parse.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index f267a1d..11501a4
With the recent discussion, I wondered how hard it would be to add
SUBDIRECTORY_OK=Yes to git-submodule.sh and it doesn't seem that bad.
Note that this series currently lacks both tests and documentation
updates. Also I have made no attempt to change the output from any
commands, so submodule pat
Hello,
Sunday 24 February 2013 22:44:14 rašė:
> Modestas Vainius writes:
> > Hello,
> >
> > Saturday 12 January 2013 06:25:21 rašė:
> >> On Sat, Jan 12, 2013 at 03:59:52PM +0200, Modestas Vainius wrote:
> >> > @@ -306,6 +311,11 @@ static CURL *get_curl_handle(void)
> >> >
> >> > if (cu
On Sun, Apr 07, 2013 at 12:46:23PM -0500, Felipe Contreras wrote:
> [snip]
>
> +test_expect_success 'cover letter auto' '
> + mkdir -p tmp &&
> + test_when_finished "rm -rf tmp;
> + git config --unset format.coverletter" &&
> +
> + git config format.coverletter auto &&
This reminds me of the commit generation numbers thread.
"But how can we determine ancestry?"
"Use the commit timestamp."
"But what if there are clock skews?"
"Put in a slop."
It breaks existing stuff, and it's hard to show any end-user benefit.
I fear this proposal will meet with the same fate.
> That aside; Does the package work if you reduce the security settings,
> install it and then reset the security settings to their default
> settings later? If so, I'd call that a reasonable workaround
It does. An even better workaround is to right-click (or Control-click)
on the installer and
Ramkumar Ramachandra wrote:
>> The only proposed change that seems to me to be impossible with the
>> current .gitmodules approach is the "submodule in a non-initialized
>> submodule" feature, but I've never seen anyone ask for that and it seems
>> likely to open a whole can of worms where the beha
On Sun, Apr 07, 2013 at 05:10:29PM +0200, Thomas Ackermann wrote:
> Signed-off-by: Thomas Ackermann
> ---
> [snip]
>
> [[def_object_name]]object name::
> - The unique identifier of an <>. The <>
> - of the object's contents using the Secure Hash Algorithm
> - 1 and usually represented
John Keeping wrote:
> With the clarifications Ram's provided in this thread, I think there are
> also some important regressions in functionality in his proposal (at
> least as it currently stands), particularly losing the .gitconfig
> overrides.
If we want the entire feature list in the very firs
On Sun, Apr 07, 2013 at 08:34:27PM +0200, Jens Lehmann wrote:
> The whole feature list is full of red herrings like this which
> have nothing to do with the advantages of a new object, but talk
> about UI issues which are easy to solve in both worlds.
With the clarifications Ram's provided in this
Thanks for suggestions,
I don't think there's any internal debugging that helps at this
point. Usually errors pointing to corruption are caused by a chain of
syscalls failing in some way, and the final error shows only the last
one, so strace() output is very interesting.
Right - a problem
Jens Lehmann wrote:
> Ram is plain wrong here (just like he is on "git rm" and "git mv",
> even though the latter is currently still in pu). This use case is
> handled by submodules for years now. Take a look at the "ignore"
> setting in .gitmodules which give you full control of the stat()s
> in s
John Keeping wrote:
> I can't see how this gets me a dirty working tree. Since the link needs
> to be stored somewhere, I assume it's in the index; so I can have staged
> changes, but not unstaged changes.
If you have changes in the index, your worktree is classified as
"dirty". See git-sh-setup
Am 07.04.2013 20:21, schrieb John Keeping:
> On Sun, Apr 07, 2013 at 11:37:02PM +0530, Ramkumar Ramachandra wrote:
>> John Keeping wrote:
>>> On Sun, Apr 07, 2013 at 10:52:50PM +0530, Ramkumar Ramachandra wrote:
3. Ability to have very many large submodule repositories without the
perform
Ramkumar Ramachandra wrote:
> You can't control the most fundamental thing, stat(): this is the
> primary killer of performance on a large worktree. There is currently
> no way to block stat(): new-style submodules offers a way to configure
> which submodules to block the stat() on.
Let me try to
On Sun, Apr 07, 2013 at 11:37:02PM +0530, Ramkumar Ramachandra wrote:
> John Keeping wrote:
> > On Sun, Apr 07, 2013 at 10:52:50PM +0530, Ramkumar Ramachandra wrote:
> >> Sure, I'll write it out for you from an end-user perspective:
> >
> > To play Devil's Advocate for a bit...
>
> Yes!
>
> >> 0.
John Keeping wrote:
> On Sun, Apr 07, 2013 at 10:52:50PM +0530, Ramkumar Ramachandra wrote:
>> Sure, I'll write it out for you from an end-user perspective:
>
> To play Devil's Advocate for a bit...
Yes!
>> 0. Great UI/UX. No more cd-to-toplevel, and a beautiful set of native
>> commands that ar
On Sun, Apr 7, 2013 at 12:22 PM, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>>> Wouldn't this work for both cases?
>>>
>>> % git -c format.coverletter=auto format-patch
>>
>> Then, what's the point in having a --cover-letter option?
>>
>> "git -c" is a good last-chance solution, but when we p
Hi,
I'm trying to convert/rebase about 40 local patches from an old
mercurial fork of OpenGrok (upstream used to use hg), to the new git
repository (upstream has recently switched to github).
What I decided to do is convert my old mercurial repo to git (by
pushing with py-hg-git to a git reposito
On Sun, Apr 7, 2013 at 12:22 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Sun, Apr 7, 2013 at 1:42 AM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
Some people always do --annotate, lets not force them to always type
that.
Signed-off-by: Felipe Cont
Felipe Contreras writes:
> - while ((waiting = waitpid(pid, &status, 0)) < 0 && errno == EINTR)
> - ; /* nothing */
> + /* First try the last status from check_command() */
> + if (cmd && cmd->last_status.valid) {
> + status = cmd->last_status.status;
> +
On Sun, Apr 07, 2013 at 10:52:50PM +0530, Ramkumar Ramachandra wrote:
> Sure, I'll write it out for you from an end-user perspective:
To play Devil's Advocate for a bit...
> 0. Great UI/UX. No more cd-to-toplevel, and a beautiful set of native
> commands that are consistent with the overall desi
Felipe Contreras writes:
> Otherwise transport-helper will continue checking for refs and other
> things what will confuse the user more.
> ---
Sign-off?
> git-remote-testgit| 11 +++
> t/t5801-remote-helpers.sh | 19 +++
> transport-helper.c| 8 +++
Now that the cover-letter code has been shuffled, we can do some
cleanups.
Signed-off-by: Felipe Contreras
---
builtin/log.c | 71 +--
1 file changed, 35 insertions(+), 36 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index cf09a
Also, add a new option: 'auto', so if there's more than one patch, the
cover letter is generated, otherwise it's not.
Signed-off-by: Felipe Contreras
---
Documentation/config.txt | 5 +
Documentation/git-format-patch.txt | 5 +++--
builtin/log.c | 32
OPT_BOOLEAN is deprecated, and this is what we want.
Signed-off-by: Felipe Contreras
---
builtin/log.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index cd942ee..488a254 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -99,9 +
Felipe Contreras writes:
> And to recover the information from the last run when running
> wait_or_whine().
>
> Signed-off-by: Felipe Contreras
> ---
The above says what the updated wait_or_whine() does (it returns the
state an earlier call to check_command() has already polled to
determine), b
By moving the part that relies on rev->pending earlier, where we are
already checking the special case where there's only one ref.
Signed-off-by: Felipe Contreras
---
builtin/log.c | 33 -
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/builtin/log
Some people always do --annotate, lets not force them to always type
that.
Signed-off-by: Felipe Contreras
---
Documentation/config.txt | 1 +
Documentation/git-send-email.txt | 5 +++--
git-send-email.perl | 7 ---
3 files changed, 8 insertions(+), 5 deletions(-)
diff
If we do it after the revision traversal we can be sure that this is
indeed a commit that will be processed (i.e. not a merge) and it's the
top most one (thus removing the NEEDSWORK comment, at least we show the
same as 'git diff --stat').
While we are at it, since we know there's nothing to gener
Hi,
Some comments have been addressed, tests have been added, and a bug fixed.
Also, after the reshuffling of code, cleanup possibilities are realized.
Felipe Contreras (6):
send-email: make annotate configurable
format-patch: improve head calculation for cover-letter
format-patch: refactor
Junio C Hamano writes:
> Lukas Fleischer writes:
>
>> While explicitly stating that the commit message in a prerequisite
>> line is optional,
>
> Good spotting. What e9ee84cf28b6 (bundle: allowing to read from an
> unseekable fd, 2011-10-13) meant to say was the SP was optional but
s/say was
Thomas Ackermann writes:
> Signed-off-by: Thomas Ackermann
It looks, at least to me, that the patch is about "give only
definitions for refspec and pathspec" removing other excessive
information that are better left to the real manual pages.
Subject: glossary: just define refspec and p
Thomas Ackermann writes:
> Signed-off-by: Thomas Ackermann
> ---
The readers of the history may still want to see "improve how"
explained in the log.
The name of the hash function is "SHA-1", not "SHA1".
Also to people who look up "object name" in the glossary,
the det
Thomas Ackermann writes:
> -[[def_dircache]]dircache::
> - You are *way* behind. See <>.
> -
> ...
> -[[def_ent]]ent::
> - Favorite synonym to "<>" by some total geeks. See
> - http://en.wikipedia.org/wiki/Ent_(Middle-earth) for an in-depth
> - explanation. Avoid this term, no
John Keeping wrote:
> So not a flag day, but still some point at which the repository
> transitions to "will not work with Git older than version X". And if
> you need to add a new submodule then you cannot delay that transition
> any longer.
Yes, that is true. I don't see any way out of this.
Felipe Contreras writes:
> On Sun, Apr 7, 2013 at 1:42 AM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> Some people always do --annotate, lets not force them to always type
>>> that.
>>>
>>> Signed-off-by: Felipe Contreras
>>> ---
>>
>> Sounds sensible; any tests to protect this fr
Matthieu Moy writes:
>> Wouldn't this work for both cases?
>>
>> % git -c format.coverletter=auto format-patch
>
> Then, what's the point in having a --cover-letter option?
>
> "git -c" is a good last-chance solution, but when we provide the same
> feature as a command-line option and as a config
Lukas Fleischer writes:
> While explicitly stating that the commit message in a prerequisite
> line is optional,
Good spotting. What e9ee84cf28b6 (bundle: allowing to read from an
unseekable fd, 2011-10-13) meant to say was the SP was optional but
we want to allow a tip bundled to have a commi
On Sun, Apr 07, 2013 at 10:12:28PM +0530, Ramkumar Ramachandra wrote:
> John Keeping wrote:
> > Meaning that every repository using submodules need to have a flag day
> > when all of the people using it switch to the new Git version at once?
>
> No, I would be totally against a migration that invo
On Sun, Apr 7, 2013 at 1:42 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> Some people always do --annotate, lets not force them to always type
>> that.
>>
>> Signed-off-by: Felipe Contreras
>> ---
>
> Sounds sensible; any tests to protect this from later breakages?
Given that annota
John Keeping wrote:
> Meaning that every repository using submodules need to have a flag day
> when all of the people using it switch to the new Git version at once?
No, I would be totally against a migration that involves a flag-day.
What I meant is that having old-style submodule side-by-side wi
On Sun, Apr 7, 2013 at 11:20 AM, Matthieu Moy
wrote:
> Felipe Contreras writes:
>
>> On Sun, Apr 7, 2013 at 9:50 AM, Matthieu Moy
>> wrote:
>>> Felipe Contreras writes:
>>>
So, I'm a user that does 'git format-patch --cover-letter=auto origin'
so I don't have the format.coverletter=au
Felipe Contreras writes:
> On Sun, Apr 7, 2013 at 9:50 AM, Matthieu Moy
> wrote:
>> Felipe Contreras writes:
>>
>>> So, I'm a user that does 'git format-patch --cover-letter=auto origin'
>>> so I don't have the format.coverletter=auto configuration. Why? Why am
>>> I not setting that configurat
On Sun, Apr 07, 2013 at 09:21:44PM +0530, Ramkumar Ramachandra wrote:
> I suspect you're overtly worried about the fallout of such a
> disruptive change. If so, you could've just said: "Ram, I like the
> idea. But what breakages do you estimate we'll have to deal with?"
> instead of attacking the
On Sun, Apr 7, 2013 at 9:50 AM, Matthieu Moy
wrote:
> Felipe Contreras writes:
>
>> So, I'm a user that does 'git format-patch --cover-letter=auto origin'
>> so I don't have the format.coverletter=auto configuration. Why? Why am
>> I not setting that configuration, and why am I running
>> --cover
I suspect you're overtly worried about the fallout of such a
disruptive change. If so, you could've just said: "Ram, I like the
idea. But what breakages do you estimate we'll have to deal with?"
instead of attacking the idea and repeatedly questioning its purpose.
So, I'll make a rough guess base
Hi,
it's a common problem[1,2,3] in Maven (Java) projects and probably in other
environments too: You have the version number of your project written in the
pom.xml. When one merges changes upwards from the maint branche to master, the
version numbers in maint and master are different and cause
Commit eff80a9 (Allow custom "comment char") introduced a custom
comment character for commit messages but didn't use it completely
in the tag signature part.
This commit fixes that.
Signed-off-by: Ralf Thielow
---
builtin/fmt-merge-msg.c | 12
1 file changed, 8 insertions(+), 4 de
Commit eff80a9 (Allow custom "comment char") introduced a custom
comment character for commit messages but forgot to use it in
people credits which can be a part of a commit message.
With this commit, the custom comment character is also used
in people credits.
Signed-off-by: Ralf Thielow
---
b
On Sun, Apr 07, 2013 at 01:53:15PM +0200, Lukas Fleischer wrote:
> While explicitly stating that the commit message in a prerequisite line
> is optional, we required all lines with 40 or more characters to contain
> a space after the object name, bailing out if a line consisted of an
> object name
Signed-off-by: Thomas Ackermann
---
Documentation/glossary-content.txt | 64 ++
1 file changed, 2 insertions(+), 62 deletions(-)
diff --git a/Documentation/glossary-content.txt
b/Documentation/glossary-content.txt
index 4dd0a52..f21678d 100644
--- a/Document
Signed-off-by: Thomas Ackermann
---
Documentation/glossary-content.txt | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/glossary-content.txt
b/Documentation/glossary-content.txt
index 5a7a486..4dd0a52 100644
--- a/Documentation/glossary-co
Signed-off-by: Thomas Ackermann
---
Documentation/glossary-content.txt | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/Documentation/glossary-content.txt
b/Documentation/glossary-content.txt
index eb7ba84..5a7a486 100644
--- a/Documentation/glossary-content.txt
+
This is a reroll of my patches for glossary-content.txt
with Junio's comments/suggestions included:
[PATCH 1/3] glossary: remove outdated/misleading/irrelevant entries
- keep entries for "directory" and "evil merge"
- keep comparison of "Git tag" to "Lisp tag"
[PATCH 2/3] glossary: improve descrip
On 04/07/2013 03:55 AM, David Foster wrote:
The default security settings on OS X 10.8 (Mountain Lion) disallow the
installation of unsigned packages, with no override.
Git/Mac 1.8.2 is not signed and therefore will not install without changing
the OS default security settings.
Sounds like an
Felipe Contreras writes:
> So, I'm a user that does 'git format-patch --cover-letter=auto origin'
> so I don't have the format.coverletter=auto configuration. Why? Why am
> I not setting that configuration, and why am I running
> --cover-letter=auto?
The command may well be ran from a script or
While stating that commit messages of prerequisites are optional in
bundles, we used to disallow prerequisite lines consisting of an object
name only. This behavior made `git bundle verify` and `git bundle
unbundle` reject bundles that contain prerequisites without any commit
message.
Add a test t
While explicitly stating that the commit message in a prerequisite line
is optional, we required all lines with 40 or more characters to contain
a space after the object name, bailing out if a line consisted of an
object name only. Fix this off-by-one error and only require lines with
more than 40
Your overall hostility is unappreciated. The burden of proof is on
me, while you calmly sit back and criticize anything that breaks the
current working state, and refuse to look at the implementation.
Anyway, here we go again.
Junio C Hamano wrote:
> Not at all. And please do not start _coding_.
On Fri, Apr 05, 2013 at 03:27:11PM -0700, Junio C Hamano wrote:
> * jk/merge-tree-added-identically (2013-03-27) 1 commit
> - merge-tree: fix "same file added in subdir"
>
> We would most likely want to change things the other way around.
>
> Expecting a reroll.
I was hoping to get some feedb
It appears to be impossible to push signed tags using a remote helper
that supports only fast-export. This is reported against gitifyhg[1]
but I think it is actually a Git issue.
[1] https://github.com/buchuki/gitifyhg/issues/59
I can reproduce the error using a trivial remote helper (run this i
Using grep "devel\s\+3:" to find at least one whitespace
is not portable on all grep versions:
Not all grep versions understand "\s" as a "whitespace".
The + as a qualifier for "one or more" is not a basic regular expression:
use egrep instead of grep.
Use a literal TAB followed by SPACE like this
On Sun, Apr 7, 2013 at 4:03 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> Users know how to count, if the default is no cover-letter, then doing
>> --cover-letter=auto is basically --cover-letter, unless they don't
>> know how to count and thought --cover-letter=auto would do somethin
On Sun, Apr 7, 2013 at 4:48 AM, Torsten Bögershausen wrote:
> Using grep "devel\s\+3:" to find at least one whitspace
s/whitspace/whitespace/
> is not portable on all grep versions:
> Not all grep versions understand "\s" as a "whitespace".
>
> Use a literal TAB followed by SPACE like this [ ]
Felipe Contreras writes:
> Users know how to count, if the default is no cover-letter, then doing
> --cover-letter=auto is basically --cover-letter, unless they don't
> know how to count and thought --cover-letter=auto would do something.
> The same is true is they configured coverletter=true.
T
1 - 100 of 119 matches
Mail list logo
