Felipe Contreras writes:
> ...for me
> it's more important that 'git fetch' works sanely (patch #1), and I
> don't like the proposed patch, but I can't think of anything better.
I do not like that either, but I haven't formed a firm opinion on it
yet.
--
To unsubscribe from this list: send the l
On Thu, May 16, 2013 at 12:36 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> It doesn't make sense to push to the upstream branch, so create new
>> configurations for the notion of 'downstream' branch, which is basically
>> the branch to push to by default.
>
> It doesn't? That depend
Hi,
I think the discussion might work better via ML than GitHub.
This is the full glossary of git's de.po as it would look
like with (hopefully) all the changes included that have been
discussed here. Still without any reasoning for decisions
(except HEAD).
Thanks for reading.
+Basic repository
On 05/16/2013 05:47 AM, Jeff King wrote:
>> I probably would have separated the rest of the patch, which is a pure
>> refactoring, from this last chunk, which is a functional change. But
>> that's just me.
>
> Yeah, I go back and forth on whether it is better to have strict
> refactors followed b
Felipe Contreras writes:
> It doesn't make sense to push to the upstream branch, so create new
> configurations for the notion of 'downstream' branch, which is basically
> the branch to push to by default.
It doesn't? That depends.
To people coming from (and people who are still using) central
David Aguilar writes:
> On Wed, May 15, 2013 at 5:39 PM, Junio C Hamano wrote:
>> David Aguilar writes:
>>
>>> Mac OS X 10.8 Mountain Lion warns that HMAC_Init() and friends
>>> are deprecated. Detect the COMMON_CRYPTO_FOR_OPENSSL definition
>>
>> Ahh, I think you meant to use that name but fo
On Mon, May 13, 2013 at 04:29:34AM +0200, Michael Haggerty wrote:
> > This patch introduces a "stat_validity" struct which
> > encapsulates the concept of checking the stat-freshness of a
> > file. It is implemented on top of "struct cache_entry" to
> > reuse the logic about which stat entries to
On Mon, May 13, 2013 at 12:56:05AM +0200, Michael Haggerty wrote:
> > + * This should be called from resolve_ref_unsafe when a loose ref cannot be
> > + * accessed; err must represent the errno from the last attempt to access
> > the
> > + * loose ref, and the other options are forwarded from
>
On Wed, May 15, 2013 at 5:22 PM, Philip Oakley wrote:
> Sound a reasonable idea. On some patches I was working on I had to [chose
> to] add a tag for the base which made it easier to rebase later.
And was the 'upstream' branch somehow not appropriate for some reason?
--
Felipe Contreras
--
To
Signed-off-by: Felipe Contreras
---
git-pull.sh | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 75297c7..b207df2 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -166,9 +166,7 @@ error_on_no_merge_candidates () {
op_prep=with
It doesn't make sense to push to the upstream branch, so create new
configurations for the notion of 'downstream' branch, which is basically
the branch to push to by default.
The upstream branch is remote+merge, the downstream branch is
pushremote+push.
[branch "master"]
remote = orig
'git fetch .' makes no sense, so let's keep using the default ('origin')
when the current branch's remote is '.'.
Also update 'git pull' so that pulling works the same way as before.
Signed-off-by: Felipe Contreras
---
git-pull.sh | 9 -
remote.c| 2 +-
2 files changed, 9 insertions
Hi,
After thinking a bit more about, I think the current 'upstream' branch serves
most of the purposes; actually tracks an upstream branch; makes sense to rebase
onto that, makes sense to fetch from that remote, merge, and pull.
The only job it doesn't make sense to use the 'upstream' branch for
On Sun, May 12, 2013 at 11:41:45AM +0200, Thomas Rast wrote:
> >> We miss an opportunity to update "refs/remotes/origin/master"
> >> (or whatever the user has configured). Some users find this
> >> confusing, because they would want to do further comparisons
> >> against the old state of the remot
On Mon, May 13, 2013 at 04:57:55PM +0200, Michael J Gruber wrote:
> > I don't think that it is a property of the file itself. That is, you do
> > not say "foo files are inherently uninteresting to git-show, and
> > therefore we always convert them, whereas bar files do not have that
> > property'.
On Wed, May 15, 2013 at 5:36 PM, Junio C Hamano wrote:
> David Aguilar writes:
>
>> Mac OS X 10.8 Mountain Lion prints warnings when building git:
>>
>> warning: 'SHA1_Init' is deprecated
>> (declared at /usr/include/openssl/sha.h:121)
>>
>> Silence the warnings by using the CommonCry
On Wed, May 15, 2013 at 5:39 PM, Junio C Hamano wrote:
> David Aguilar writes:
>
>> Mac OS X 10.8 Mountain Lion warns that HMAC_Init() and friends
>> are deprecated. Detect the COMMON_CRYPTO_FOR_OPENSSL definition
>
> Ahh, I think you meant to use that name but forgot to adjust the
> symbol you
On Wed, May 15, 2013 at 05:29:51PM -0700, Junio C Hamano wrote:
> If you were on 'frotz' branch before you checked out your current
> branch, "git merge @{-1}~22" means the same as "git merge frotz~22".
>
> The strbuf_branchname() function, when interpret_branch_name() gives
> up resolving "@{-1}
On 15 May 2013, at 15:32, Johannes Sixt wrote:
> Am 5/15/2013 10:40, schrieb Luc Bourhis:
>> I work on a case insensitive filesystem and I have core.ignorecase set to
>> true.
>> ...
>> So I thought it was a job for git filter-branch, ...
>>
>> However because of those two blobs, I have:
>>
>
David Aguilar writes:
> Mac OS X 10.8 Mountain Lion warns that HMAC_Init() and friends
> are deprecated. Detect the COMMON_CRYPTO_FOR_OPENSSL definition
Ahh, I think you meant to use that name but forgot to adjust the
symbol you use in the patch ;-)
I'll queue with s/COMMON_DIGEST_FOR_OPENSSL/
David Aguilar writes:
> Mac OS X 10.8 Mountain Lion prints warnings when building git:
>
> warning: 'SHA1_Init' is deprecated
> (declared at /usr/include/openssl/sha.h:121)
>
> Silence the warnings by using the CommonCrytpo SHA-1
> functions for SHA1_Init(), SHA1_Update(), and SHA1_Fi
If you were on 'frotz' branch before you checked out your current
branch, "git merge @{-1}~22" means the same as "git merge frotz~22".
The strbuf_branchname() function, when interpret_branch_name() gives
up resolving "@{-1}~22" fully, returns "frotz" and tells the caller
that it only resolved "@{-
On Wed, May 15, 2013 at 4:42 PM, Junio C Hamano wrote:
> Here are the topics that have been cooking. Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'.
>
> We are past -rc2 and haven't seen any regression reported since the
> feature f
Mac OS X 10.8 Mountain Lion warns that HMAC_Init() and friends
are deprecated. Detect the COMMON_CRYPTO_FOR_OPENSSL definition
and use CommonCrypto's HMAC functions to eliminate the warnings.
Signed-off-by: David Aguilar
---
Changes since last time: None.
imap-send.c | 10 ++
1 file ch
Mac OS X 10.8 Mountain Lion prints warnings when building git:
warning: 'SHA1_Init' is deprecated
(declared at /usr/include/openssl/sha.h:121)
Silence the warnings by using the CommonCrytpo SHA-1
functions for SHA1_Init(), SHA1_Update(), and SHA1_Final().
Add a NO_COMMON_DIGEST_F
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
We are past -rc2 and haven't seen any regression reported since the
feature freeze started, which may be a good sign (the coming release
is perf
On Wed, May 15, 2013 at 6:14 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> Exactly the same as 'git pull' does right now.
>
> You set
>
> [branch 'foobar']
> base = refs/heads/master
>
> then 'git pull [--rebase]' will go to 'origin' due to the default,
> but t
On Wed, May 15, 2013 at 5:50 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> I however am not yet convinced if that direction is what you really
>> want go in, though. What should your 'git pull' on that branch do,
>> for example?
>>
>> When you are on foobar and want to integrate with t
Felipe Contreras writes:
> Exactly the same as 'git pull' does right now.
You set
[branch 'foobar']
base = refs/heads/master
then 'git pull [--rebase]' will go to 'origin' due to the default,
but then what branch from the 'origin' are you integrating with?
Do you mean
On Wed, May 15, 2013 at 5:20 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> The 'base' branch will be set each time you create a branch from another;
>> 'git checkout -b foobar master' sets 'master' as the 'base' of 'foobar'.
>
> "git checkout -t -b foobar mastee" would instead set 'up
Junio C Hamano writes:
> I however am not yet convinced if that direction is what you really
> want go in, though. What should your 'git pull' on that branch do,
> for example?
>
> When you are on foobar and want to integrate with the branch you
> based your work on (i.e. local 'master'), you ca
Describe how 'add' sets the submodule's logical name, which is used in
the configuration entry names.
Clarify that 'init' only sets up the configuration entries for
submodules that have already been added elsewhere. Describe that
arguments limit the submodules that are configured.
Signed-off-by
From: "Felipe Contreras"
Sent: Wednesday, May 15, 2013 9:34 PM
Hi,
I've been using Git from the start, but only lately have I forced
myself to configure upstream branches for all my branches, and I've
found a few things more convenient, but others completely contrary to
what I expected.
Inconv
Felipe Contreras writes:
> The 'base' branch will be set each time you create a branch from another;
> 'git checkout -b foobar master' sets 'master' as the 'base' of 'foobar'.
"git checkout -t -b foobar mastee" would instead set 'upstream' of
'foobar' to the branch 'master' of remote '.' (the cu
Hi,
I've been using Git from the start, but only lately have I forced
myself to configure upstream branches for all my branches, and I've
found a few things more convenient, but others completely contrary to
what I expected.
Inconvenient:
Before, I used to do 'git fetch' to simply fetch from 'or
Hi,
I've been using Git from the start, but only lately have I forced myself to
configure upstream branches for all my branches, and I've found a few things
more convenient, but others completely contrary to what I expected.
Inconvenient:
Before, I used to do 'git fetch' to simply fetch from 'or
This parameter is equivalent to the parameter --parents on svn cp commands
and is useful for non-standard repository layouts.
Signed-off-by: Tobias Schulte
---
Documentation/git-svn.txt|5
git-svn.perl | 19 +++-
t/t9167-git-svn-cmd-
On 15.05.2013 04:35, Eric Wong wrote:
>> +if (!eval{$ctx->ls($parent, 'HEAD', 0)}) {
>> +mk_parent_dirs($ctx, $parent);
>> +print "Creating parent folder ${parent} ...\n";
>> +$ctx->mkdir($parent)
>> +unless $_dry_run;
>
> The newline is
Johan Herland wrote:
> Unfortunately, using "refs/remotes/%1/%*" instead of "refs/remotes/%*"
> breaks a number of git-svn tests which puts refs directly within
> refs/remotes/, and then does things like "git reset --hard trunk"
> (expecting trunk -> refs/remotes/trunk, which the refs/remotes/%1/%
On Wed, May 15, 2013 at 2:40 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> Felipe Contreras wrote:
>>> When force_push is disabled, we need to turn the argument to True.
>
> With your follow-up clarification, here is what ended up in the log
> message:
>
> remote-hg: fix new branc
On Wed, May 15, 2013 at 1:32 PM, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>>> We should be honest and say what we are doing: "it will make things
>>> easier for majority while making it less convenient for minority".
>>
>> I thought this was what I did, but your first complain was I was
>>
Felipe Contreras writes:
> Felipe Contreras wrote:
>> When force_push is disabled, we need to turn the argument to True.
With your follow-up clarification, here is what ended up in the log
message:
remote-hg: fix new branch creation
When a user creates a new branch with git:
$ g
Matthijs Kooijman writes:
>> Could you explain why you think it hides the real problem, and what
>> kind of future enhancement may break it?
> I think the differences is mostly in the locality of the fix. In my
> proposed patch, the no_pre_delete flag is never set on an interesting
> line because
Matthieu Moy writes:
>> We should be honest and say what we are doing: "it will make things
>> easier for majority while making it less convenient for minority".
>
> I thought this was what I did, but your first complain was I was
> mentionning the majority, and you are now suggesting something a
Jiang Xin writes:
> These two patches enhance relative_path() in path.c, so that function
> relative_path() will return real relative path, not a path strip off
> the prefix.
>
> The 2nd patch is a bit aggressive, it refactor all related functions,
> remove unnecessary arguments: len and/or prefi
Junio C Hamano writes:
> Now, realize that after switching the default, these "few people"
> have to live with distracting (or unreadable) output. Because these
> people are minority, their websearch "disable colors in git" will by
> definition have smaller number of hits than "enable colors in
Hi Junio,
> Could you explain why you think it hides the real problem, and what
> kind of future enhancement may break it?
I think the differences is mostly in the locality of the fix. In my
proposed patch, the no_pre_delete flag is never set on an interesting
line because it is checked in the lin
Hi
My primary goal was to understand better what are the real problems
that we might have with the way we use git cvsimport, so I was not
asking about the guarantee of the cvsimport to import things
correctly, but if there is a guarantee the import will result in
completely broken history. IF ther
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> I think you are missing the entire point, which is not "is anyone
>> harmed?"
>
> Again, it is. If the new default is really harmful for too many people,
> then documentations will have to mention how to fix it.
>
> And really, I do not forsee a
When a deletion is followed by exactly 3 (or whatever the number of
context lines) unchanged lines, followed by another change, the combined
diff output would hide the first deletion, resulting in a malformed
diff.
This happened because the 3 lines before each change are painted
interesting, but a
Junio C Hamano writes:
> I think you are missing the entire point, which is not "is anyone
> harmed?"
Again, it is. If the new default is really harmful for too many people,
then documentations will have to mention how to fix it.
And really, I do not forsee any newbie-oriented starting with "he
On 2013-05-15 09.11, David Aguilar wrote:
> Mac OS X 10.8 Mountain Lion prints warnings when building git:
>
> warning: 'SHA1_Init' is deprecated
> (declared at /usr/include/openssl/sha.h:121)
>
> Silence the warnings by using the CommonCrytpo SHA-1
> functions for SHA1_Init(), SHA1_U
Matthijs Kooijman writes:
> Hi Junio,
>
>> I think the coalescing of two adjacent hunks into one is painting
>> leading lines "interesting to show context but not worth showing
>> deletion before it" incorrectly.
> Yup, that seems to be the case.
>
>> Does this patch fix the issue?
>
> Yes, it fi
Matthieu Moy writes:
>> The above two paragraphs do not make a good justification [*1*].
>> The former can just as easily websearch for "enable colours in git"
>
> I disagree: I do not know anyone who would be really harmed by colors
> ...
I actually am one of them (light cyan or green on white
Hi Junio,
> I think the coalescing of two adjacent hunks into one is painting
> leading lines "interesting to show context but not worth showing
> deletion before it" incorrectly.
Yup, that seems to be the case.
> Does this patch fix the issue?
Yes, it fixes the issue. However, I think that this
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> Matthieu Moy writes:
>>
>>> diff --git a/builtin/config.c b/builtin/config.c
>>> index 000d27c..ecfceca 100644
>>> --- a/builtin/config.c
>>> +++ b/builtin/config.c
>>> @@ -316,7 +316,7 @@ static void get_color(const char *def_color)
>>>
>>>
On Wednesday 2013-05-15 17:31, Holger Hellmuth (IKS) wrote:
>>>
>>> I actually had the '-' in there too until I tried to look up "Zip-Datei"
>>> in the Duden. While I don't get the leading '.' (I cannot remember having
>>> seen that anywhere, AFAIK the file extensions are always used without the
>
Matthijs Kooijman writes:
> $ git diff-tree -p -c HEAD
> d945a51b6ca22e6e8e550c53980d026f11b05158
> diff --combined file
> index 3404f54,0eab113..e8c8c18
> --- a/file
> +++ b/file
> @@@ -1,7 -1,5 +1,6 @@@
> +LEFT
> BASE2
> BASE3
> BASE4
> - BASE5
> + BASE5MODIFIED
> BASE6
>
> Here, the h
The meaning of get_colorbool_found and get_diff_color_found is "the
config value if found, and -1 otherwise", but get_color_ui_found had a
slightly different meaning, as it has the value 0 (which corresponds to
the default value from the user point of view) when color.ui is unset.
Make get_color_u
Most users seem to like having colors enabled, and colors can help
beginners to understand the output of some commands (e.g. notice
immediately the boundary between commits in the output of "git log").
Many tutorials tell the users to set color.ui=auto as a very first step,
which tend to indicate
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> diff --git a/builtin/config.c b/builtin/config.c
>> index 000d27c..ecfceca 100644
>> --- a/builtin/config.c
>> +++ b/builtin/config.c
>> @@ -316,7 +316,7 @@ static void get_color(const char *def_color)
>>
>> static int get_colorbool_found;
>>
On Wed, May 15, 2013 at 08:42:39AM -0700, Junio C Hamano wrote:
> Matthieu Moy writes:
>
> > Many tutorials tell the users to set color.ui=auto as a very first step.
> > These tutorials would benefit from skiping this step and starting the
> > real Git manipualtions earlier. Other beginners do no
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Many tutorials tell the users to set color.ui=auto as a very first step.
>> These tutorials would benefit from skiping this step and starting the
>> real Git manipualtions earlier. Other beginners do not know about
>> color.ui=auto, and may not
Matthieu Moy writes:
> diff --git a/builtin/config.c b/builtin/config.c
> index 000d27c..ecfceca 100644
> --- a/builtin/config.c
> +++ b/builtin/config.c
> @@ -316,7 +316,7 @@ static void get_color(const char *def_color)
>
> static int get_colorbool_found;
> static int get_diff_color_found;
>
Hi folks,
> $ git diff-tree -p -c HEAD
> d945a51b6ca22e6e8e550c53980d026f11b05158
> diff --combined file
> index 3404f54,0eab113..e8c8c18
> --- a/file
> +++ b/file
> @@@ -1,7 -1,5 +1,6 @@@
> +LEFT
> BASE2
> BASE3
> BASE4
> - BASE5
> + BASE5MODIFIED
> BASE6
I found the spot in the code wh
Matthieu Moy writes:
> Many tutorials tell the users to set color.ui=auto as a very first step.
> These tutorials would benefit from skiping this step and starting the
> real Git manipualtions earlier. Other beginners do not know about
> color.ui=auto, and may not discover it by themselves, hence
Am 15.05.2013 15:14, schrieb Jan Engelhardt:
On Wednesday 2013-05-15 14:27, Jens Lehmann wrote:
While it's spoken Packdatei, the way to actually write it is
.pack-Datei or ".pack"-Datei.
I actually had the '-' in there too until I tried to look up "Zip-Datei"
in the Duden. While I don't get
Since there is a enhanced version of relative_path() in path.c,
remove duplicate counterpart path_relative() in quote.c.
Also refactor related functions, remove unnecessary arguments:
len and/or prefix_len.
Signed-off-by: Jiang Xin
---
builtin/clean.c| 18 +++---
builtin/grep.c
Original design of relative_path() is simple, just strip the prefix
(*base) from the abosolute path (*abs). In most cases, we need a real
relative path, such as: ../foo, ../../bar. That's why there is another
reimplementation (path_relative()) in quote.c.
Refactor relative_path() in path.c to retu
2013/5/15 Junio C Hamano :
> Jiang Xin writes:
>
>> +/*
>> + * Give path as relative to prefix.
>> + *
>> + * This function is a combination of path_relative (in quote.c) and
>> + * relative_path (in path.c)
>> + */
>> +static const char *path_relative(const char *in, const char *prefix)
>> +{
>>
Johan Herland writes:
> On Wed, May 15, 2013 at 9:39 AM, Johan Herland wrote:
>> On Wed, May 15, 2013 at 8:45 AM, Michael Haggerty
>> wrote:
>>> "refs/remotes/%1/%2" (or "refs/remotes/%1/%*") might be a nice way to
>>> imply that the rule should only be attempted if the input has at least
>>>
2013/5/15 Junio C Hamano :
> Jiang Xin writes:
>
>> 2013/5/15 Junio C Hamano :
@@ -242,11 +287,6 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
continue; /* Yup, this one exists unmerged */
}
-
Jiang Xin writes:
> 2013/5/15 Junio C Hamano :
>>> @@ -242,11 +287,6 @@ int cmd_clean(int argc, const char **argv, const char
>>> *prefix)
>>> continue; /* Yup, this one exists unmerged */
>>> }
>>>
>>> - /*
>>> - * we might ha
Hi folks,
while trying to parse git diff-tree output, I found out that in some
cases it appears to generate an incorrect diff (AFAICT). I orginally
found this in a 5-way merge commit in the Linux kernel, but managed to
reduce this to something a lot more managable (an ordinary 2-way merge
on a 6-l
Most users seem to like having colors enabled, and colors can help
beginners to understand the output of some commands (e.g. notice
immediately the boundary between commits in the output of "git log").
Many tutorials tell the users to set color.ui=auto as a very first step.
These tutorials would b
On Wed, May 15, 2013 at 9:39 AM, Johan Herland wrote:
> On Wed, May 15, 2013 at 8:45 AM, Michael Haggerty
> wrote:
>> "refs/remotes/%1/%2" (or "refs/remotes/%1/%*") might be a nice way to
>> imply that the rule should only be attempted if the input has at least
>> two components, whereas somethi
Am 5/15/2013 10:40, schrieb Luc Bourhis:
> I work on a case insensitive filesystem and I have core.ignorecase set to
> true.
> ...
> So I thought it was a job for git filter-branch, ...
>
> However because of those two blobs, I have:
>
> ~> git status
> # modified: .../fourCircles.py
>
>
Most users seem to like having colors enabled, and colors can help
beginners to understand the output of some commands (e.g. notice
immediately the boundary between commits in the output of "git log").
Many tutorials tell the users to set color.ui=auto as a very first step.
These tutorials would b
On 05/15/2013 02:09 PM, Matthieu Moy wrote:
> Most users seem to like having colors enabled, and colors can help
> beginners to understand the output of some commands (e.g. notice
> immediately the boundary between commits in the output of "git log").
>
> Many tutorials tell the users to set color
On Wednesday 2013-05-15 14:27, Jens Lehmann wrote:
>>
>> While it's spoken Packdatei, the way to actually write it is
>> .pack-Datei or ".pack"-Datei.
>
>I actually had the '-' in there too until I tried to look up "Zip-Datei"
>in the Duden. While I don't get the leading '.' (I cannot remember hav
On Wed, May 15, 2013 at 2:09 PM, Matthieu Moy wrote:
> Signed-off-by: Matthieu Moy
Reviewed and supported-by: Johan Herland
...Johan
--
Johan Herland,
www.herland.net
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
Mor
On Tue, May 14, 2013 at 7:34 PM, Junio C Hamano wrote:
> Phil Hord writes:
>
>> I imagine it with --date-order and whatnot.
>
> Perhaps modeled after this one.
>
> git for-each-ref \
> --format='%(refname:short) %(subject)'
> --sort='-committerdate' refs/heads/
>
Nice. I had
Am 15.05.2013 13:56, schrieb Jan Engelhardt:
> On Wednesday 2013-05-15 13:26, Jens Lehmann wrote:
>> but I believe "Packdatei" would be a much better translation (especially as
>> the translation of "pack(verb)" is "packen"). I find it natural that a file
>> with the extension ".pack" is named Pack
Most users seem to like having colors enabled, and colors can help
beginners to understand the output of some commands (e.g. notice
immediately the boundary between commits in the output of "git log").
Many tutorials tell the users to set color.ui=auto as a very first step.
These tutorials would b
On Wednesday 2013-05-15 13:26, Jens Lehmann wrote:
>
>Hmm, I rather tend towards using "Repository" instead of "Archiv" too, as
>"Archiv" can mean anything from a tar-file to a git repository
It's exactly the reasoning I made in my git-glossary.txt sample
(of which the reasoning apparently has no
Am 15.05.2013 12:23, schrieb Holger Hellmuth (IKS):
> Am 14.05.2013 19:51, schrieb Ralf Thielow:
>> - repository = Projektarchiv
>> - bare repository = bloßes Projektarchiv
>> + repository = Projektarchiv, (or just Repository?)
>> + bare repository = bloßes Projektarchiv (-||-), (reines, pures Repo
On Wed, May 15, 2013 at 10:50:25AM +0100, John Keeping wrote:
> On Wed, May 15, 2013 at 11:34:41AM +0200, Matthieu Moy wrote:
> > Antoine's answer is correct. In addition, I'd say that you may want to
> > enable color in the output to make it clearer (the @@ ... @@ part would
> > be colored, but no
Am 14.05.2013 19:51, schrieb Ralf Thielow:
- repository = Projektarchiv
- bare repository = bloßes Projektarchiv
+ repository = Projektarchiv, (or just Repository?)
+ bare repository = bloßes Projektarchiv (-||-), (reines, pures Repository)
I would vote for Repository or if it needs to be trans
On Wed, May 15, 2013 at 5:03 AM, Matthieu Moy
wrote:
> John Keeping writes:
>
>> I wonder if that should be the default. I've advised a lot of people to
>> turn it on and it seems to me that a user is much more likely to go
>> looking for a "turn color off" option than realise that color is an
>
John Keeping writes:
> I wonder if that should be the default. I've advised a lot of people to
> turn it on and it seems to me that a user is much more likely to go
> looking for a "turn color off" option than realise that color is an
> option at all.
I'd love to see this by default, yes. Maybe
On Wed, May 15, 2013 at 11:34:41AM +0200, Matthieu Moy wrote:
> Antoine's answer is correct. In addition, I'd say that you may want to
> enable color in the output to make it clearer (the @@ ... @@ part would
> be colored, but not the function name):
>
> git config --global color.ui auto
I wond
Hi,
I work on a case insensitive filesystem and I have core.ignorecase set to true.
I have a series of troublesome commits and here is what git cat-file -p shows
me:
...
100644 blob 99... fourCircles.py
100644 blob 97... fourcircles.py
...
The content of those slightly differ:
---
Antoine Pelisse writes:
> On Wed, May 15, 2013 at 8:52 AM, eric liou wrote:
>> Thank you for the quick reply.
>> But this line is not correct: "@@ -4,5 +4,6 @@ int a = 1;"
Antoine's answer is correct. In addition, I'd say that you may want to
enable color in the output to make it clearer (the @
On Wed, May 15, 2013 at 8:45 AM, Michael Haggerty wrote:
> On 05/14/2013 04:24 PM, Johan Herland wrote:
>> I am not sure why we would want "refs/remotes/%1/%2" instead of
>> "refs/remote/%*". Maybe I've been staring at this for too long, but I
>> find the latter shorter and more descriptive and th
On Wed, May 15, 2013 at 8:52 AM, eric liou wrote:
> Thank you for the quick reply.
> But this line is not correct: "@@ -4,5 +4,6 @@ int a = 1;"
Oh OK, I see.
Git tries to name the function where the changes take place. This is
purely informative.
In your example, you don't have any function so of
Mac OS X 10.8 Mountain Lion warns that HMAC_Init() and friends
are deprecated. Detect the COMMON_CRYPTO_FOR_OPENSSL definition
and use CommonCrypto's HMAC functions to eliminate the warnings.
Signed-off-by: David Aguilar
---
Changes since last time:
This version re-uses the existing COMMON_CRYP
Mac OS X 10.8 Mountain Lion prints warnings when building git:
warning: 'SHA1_Init' is deprecated
(declared at /usr/include/openssl/sha.h:121)
Silence the warnings by using the CommonCrytpo SHA-1
functions for SHA1_Init(), SHA1_Update(), and SHA1_Final().
COMMON_DIGEST_FOR_OPENSS
97 matches
Mail list logo
