On Wed, May 15, 2013 at 3:37 AM, Torsten Bögershausen tbo...@web.de wrote:
Second,
I was able to do some testing.
The hanging is not 100% reproducable, and I had one hanging in Git 1.8.1
Turning the screen saver off in Win XP helps that the machine reacts,
and using process explorer showed
The output of git-diff is different from my expectation.
It may skip some lines of context.
For the case of the diff result attached here, a blank line and a line
with a leading slash is skipped.
Please check out the attached files for details.
Thanks.
ab.patch
Description: Binary data
int a =
On 05/15/2013 12:19 AM, Junio C Hamano wrote:
Eugene Sajine eugu...@gmail.com writes:
What if there are a lot of branches in the CVS repo? Is it guaranteed
to be broken after import?
Even though CVS repository can record branches in individual ,v
files, reconstructing per branch history
On Wed, May 15, 2013 at 8:23 AM, eric liou accw...@gmail.com wrote:
The output of git-diff is different from my expectation.
It may skip some lines of context.
git-diff is using a default of 3 lines of context above and below the changes.
In your example, there is only two lines of context
On 05/14/2013 04:24 PM, Johan Herland wrote:
On Mon, May 13, 2013 at 10:34 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Johan Herland jo...@herland.net writes:
Obviously, I named it '%1' since it expands into the _first_ component
of the
On Wed, May 15, 2013 at 7:32 AM, Nazri Ramliy ayieh...@gmail.com wrote:
Hi,
From git help grep:
--no-index
Search files in the current directory that is not managed by Git.
--untracked
In addition to searching in the tracked files in the working tree,
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().
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 dav...@gmail.com
---
Changes since last time:
This version re-uses the
On Wed, May 15, 2013 at 8:52 AM, eric liou accw...@gmail.com 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
On Wed, May 15, 2013 at 8:45 AM, Michael Haggerty mhag...@alum.mit.edu 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
Antoine Pelisse apeli...@gmail.com writes:
On Wed, May 15, 2013 at 8:52 AM, eric liou accw...@gmail.com 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
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 wonder
John Keeping j...@keeping.me.uk 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
On Wed, May 15, 2013 at 5:03 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
John Keeping j...@keeping.me.uk 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
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
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 not the
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 Repository)
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 not made
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
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 Packdatei
While
On Tue, May 14, 2013 at 7:34 PM, Junio C Hamano gits...@pobox.com wrote:
Phil Hord phil.h...@gmail.com writes:
I imagine it with --date-order and whatnot.
Perhaps modeled after this one.
git for-each-ref \
--format='%(refname:short) %(subject)'
--sort='-committerdate'
On Wed, May 15, 2013 at 2:09 PM, Matthieu Moy matthieu@imag.fr wrote:
Signed-off-by: Matthieu Moy matthieu@imag.fr
Reviewed and supported-by: Johan Herland jo...@herland.net
...Johan
--
Johan Herland, jo...@herland.net
www.herland.net
--
To unsubscribe from this list: send the line
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 having
seen
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
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
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
and git
On Wed, May 15, 2013 at 9:39 AM, Johan Herland jo...@herland.net wrote:
On Wed, May 15, 2013 at 8:45 AM, Michael Haggerty mhag...@alum.mit.edu
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
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
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
Jiang Xin worldhello@gmail.com writes:
2013/5/15 Junio C Hamano gits...@pobox.com:
@@ -242,11 +287,6 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
continue; /* Yup, this one exists unmerged */
}
- /*
-
2013/5/15 Junio C Hamano gits...@pobox.com:
Jiang Xin worldhello@gmail.com writes:
2013/5/15 Junio C Hamano gits...@pobox.com:
@@ -242,11 +287,6 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
continue; /* Yup, this one exists unmerged */
Johan Herland jo...@herland.net writes:
On Wed, May 15, 2013 at 9:39 AM, Johan Herland jo...@herland.net wrote:
On Wed, May 15, 2013 at 8:45 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
refs/remotes/%1/%2 (or refs/remotes/%1/%*) might be a nice way to
imply that the rule should only be
2013/5/15 Junio C Hamano gits...@pobox.com:
Jiang Xin worldhello@gmail.com 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,
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
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 worldhello@gmail.com
---
builtin/clean.c| 18
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 the
Matthieu Moy matthieu@imag.fr 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
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 where this is
Matthieu Moy matthieu@imag.fr 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
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@imag.fr 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
On Wed, May 15, 2013 at 08:42:39AM -0700, Junio C Hamano wrote:
Matthieu Moy matthieu@imag.fr 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
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@imag.fr 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
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
Matthijs Kooijman matth...@stdin.nl 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
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
dot), I'm not
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@imag.fr 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
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 matthieu@grenoble-inp.fr 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
Matthijs Kooijman matth...@stdin.nl 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
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(),
Junio C Hamano gits...@pobox.com 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
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
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com 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
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
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 line
Junio C Hamano gits...@pobox.com 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
Jiang Xin worldhello@gmail.com 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
Matthieu Moy matthieu@grenoble-inp.fr 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
Matthijs Kooijman matth...@stdin.nl 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
Felipe Contreras felipe.contre...@gmail.com 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
On Wed, May 15, 2013 at 1:32 PM, Junio C Hamano gits...@pobox.com wrote:
Matthieu Moy matthieu@grenoble-inp.fr 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
On Wed, May 15, 2013 at 2:40 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com 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
Johan Herland jo...@herland.net 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
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 confusing, I
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 tobias.schu...@gliderpilot.de
---
Documentation/git-svn.txt|5
git-svn.perl | 19
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
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
Felipe Contreras felipe.contre...@gmail.com 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
From: Felipe Contreras felipe.contre...@gmail.com
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
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
path arguments limit the submodules that are configured.
Junio C Hamano gits...@pobox.com 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
On Wed, May 15, 2013 at 5:20 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com 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
Felipe Contreras felipe.contre...@gmail.com 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
On Wed, May 15, 2013 at 5:50 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com 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
On Wed, May 15, 2013 at 6:14 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com 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
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
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
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 dav...@gmail.com
---
Changes since last time: None.
imap-send.c | 10
On Wed, May 15, 2013 at 4:42 PM, Junio C Hamano gits...@pobox.com 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
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 @{-1} part
David Aguilar dav...@gmail.com 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(),
David Aguilar dav...@gmail.com 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
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:
~ git status
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}~22
On Wed, May 15, 2013 at 5:39 PM, Junio C Hamano gits...@pobox.com wrote:
David Aguilar dav...@gmail.com 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
On Wed, May 15, 2013 at 5:36 PM, Junio C Hamano gits...@pobox.com wrote:
David Aguilar dav...@gmail.com 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
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'. You say
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 remote master,
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
'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 felipe.contre...@gmail.com
---
git-pull.sh | 9 -
remote.c| 2 +-
2
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
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 () {
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 =
On Wed, May 15, 2013 at 5:22 PM, Philip Oakley philipoak...@iee.org 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?
--
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 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 trust for a
David Aguilar dav...@gmail.com writes:
On Wed, May 15, 2013 at 5:39 PM, Junio C Hamano gits...@pobox.com wrote:
David Aguilar dav...@gmail.com 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
Felipe Contreras felipe.contre...@gmail.com 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
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 by
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
99 matches
Mail list logo
