Hi Jiang,
this happens with all of my repo clones (I am using V1.8.5.2
on Windows and on Linux). Steps to reproduce:
mkdir repo_a cd repo_a git init .
echo 1foo git add foo git commit -m 1
cd ..
git clone repo_a repo_b
cd repo_a
echo 2foo git add foo git commit -m 2
cd ../repo_b
git
On 6 January 2014 01:24, Thomas Ackermann th.ac...@arcor.de wrote:
Hi Jiang,
this happens with all of my repo clones (I am using V1.8.5.2
on Windows and on Linux). Steps to reproduce:
mkdir repo_a cd repo_a git init .
echo 1foo git add foo git commit -m 1
cd ..
git clone repo_a
2014/1/6 Thomas Ackermann th.ac...@arcor.de:
Hi Jiang,
this happens with all of my repo clones (I am using V1.8.5.2
on Windows and on Linux). Steps to reproduce:
mkdir repo_a cd repo_a git init .
echo 1foo git add foo git commit -m 1
cd ..
git clone repo_a repo_b
cd repo_a
echo
Unfortunately that's not true. In repo_b your ref for origin/master
has not moved. It has remotely (meaning refs/heads/master in repo_a
has moved), but git status is not hitting the remote to find out; it
only looks at the local state. To see what I mean, run git fetch in
repo_b. Once you
This is v2 of changes [1] to remove some mkdir/rmdir races around
safe_create_leading_directories() and a couple of its callers. Thanks
to Jonathan Nieder for his thorough review of v1 and to Ramsay Jones
for pointing out a typo. I think I have addressed all of their
suggestions.
This patch
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
sha1_file.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index daacc0c..c9245a6 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -125,8 +125,7 @@ int safe_create_leading_directories(char
This makes it more obvious that values of st don't persist across
loop iterations.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
sha1_file.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sha1_file.c b/sha1_file.c
index c9245a6..cc9957e 100644
--- a/sha1_file.c
Add a new possible error result that can be returned by
safe_create_leading_directories() and
safe_create_leading_directories_const(): SCLD_VANISHED. This value
indicates that a file or directory on the path existed at one point
(either it already existed or the function created it), but then it
This doesn't seem to be a likely error, but we've got the counter
anyway, so we might as well use it for an added bit of safety.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/refs.c b/refs.c
index
If a file or directory that we are trying to remove disappears (e.g.,
because another process has pruned it), do not consider it an error.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
dir.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git
If opendir() fails on the top-level directory, it makes sense to try
to delete it anyway--but only if the failure was due to EACCES.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
dir.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/dir.c b/dir.c
index
If hold_lock_file_for_update() fails with errno==ENOENT, it might be
because somebody else (for example, a pack-refs process) has just
deleted one of the lockfile's ancestor directories. So if this
condition is detected, try again (up to 3 times).
Signed-off-by: Michael Haggerty
If safe_create_leading_directories() fails because a file along the
path unexpectedly vanished, try again from the beginning. Try at most
3 times.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/refs.c
Rename pos to next_component, because now it always points at the
next component of the path name that has to be processed.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
sha1_file.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/sha1_file.c
On 2013-12-29 12.30, Antoine Pelisse wrote:
Mercurial can have bookmarks pointing to nullid (the empty root
revision), while Git can not have references to it.
When cloning or fetching from a Mercurial repository that has such a
bookmark, the import will fail because git-remote-hg will not be
On Sun, Jan 05, 2014 at 10:46:11PM +0100, Francesco Pretto wrote:
2014/1/5 Heiko Voigt hvo...@hvoigt.net:
The following questions directly pop into my mind:
- What means the maintainer does not track the submodules sha1? Does
that mean the superproject always refers to submodule
On Mon, Jan 06, 2014 at 12:22:23AM +0100, Francesco Pretto wrote:
2014/1/5 Heiko Voigt hvo...@hvoigt.net:
Could you please extend the description of your use-case so we can
understand your goal better?
Maybe I found better words to explain you my goal: the current git
submodule use-case
On Sun, Jan 05, 2014 at 10:27:19PM +0100, Francesco Pretto wrote:
2014/1/5 W. Trevor King wk...@tremily.us:
On Sun, Jan 05, 2014 at 04:53:12AM +0100, Francesco Pretto wrote:
Also it could break some users that rely on the current behavior.
The current code always has a detached HEAD after
On Sun, Dec 22, 2013 at 09:55:23PM +, Ben Maurer wrote:
One issue with this approach is that it seems git-pack-index doesn't
perform as well with thin packs. git-index-pack uses a multi-threaded
approach to resolving the deltas. However, the multithreading only
works on deltas that are
On Sun, Dec 22, 2013 at 11:47:34AM -0800, Ben Maurer wrote:
Jeff King's bitmap branch appears to give a very substantial speedup.
After applying this branch, the counting objects phase is basically
free. However, I found that the compression phase still takes a
non-trivial amount of time.
Jeff King p...@peff.net writes:
On Fri, Jan 03, 2014 at 04:12:51PM -0500, Matt Burke wrote:
+ git init -q
+ git fetch -q -fu ../../../other '+refs/*:refs/*'
fatal: bad object 9b985fbe6a2b783c16756077a8be261c94b6c197
error: ../../../other did not send all necessary objects
I was going to
Hi Roman
git-svn: workaround for a bug in svn serf backend (2013-12-27 20:22:19
+)
Thanks!
Well thanks to you for finding and fixing this bug that really annoyed
me just before Christmas again. Your bug analysis proved my observation
that even a fresh checkout (as I suggested in my
On Sun, Jan 05, 2014 at 03:39:43PM -0800, W. Trevor King wrote:
On Sun, Jan 05, 2014 at 11:57:33PM +0100, Heiko Voigt wrote:
On Sun, Jan 05, 2014 at 01:24:58PM -0800, W. Trevor King wrote:
If submodule.name.branch is set, it *always* creates a new local
branch of that name pointing to the
Hi,
Thomas Ackermann wrote:
In repo_b your ref for origin/master
has not moved. It has remotely (meaning refs/heads/master in repo_a
has moved), but git status is not hitting the remote to find out; it
only looks at the local state.
[...]
But for the simple
On Mon, Jan 06, 2014 at 03:18:05PM +0100, Heiko Voigt wrote:
If you simply want to always checkout the development tip of some
project you could do something like this:
git submodule foreach 'git fetch git checkout origin/master'
Or (respecting submodule.name.branch):
$ git
Jeff King p...@peff.net writes:
We could probably teach index-pack an --assume-refs-are-thin
option to optimize for this case, and have fetch-pack/receive-pack pass
it whenever they know that delta-base-offset was negotiated.
I thought the existing negotiation merely means I understand offset
Heiko Voigt hvo...@hvoigt.net writes:
On Sun, Jan 05, 2014 at 10:27:19PM +0100, Francesco Pretto wrote:
2014/1/5 W. Trevor King wk...@tremily.us:
On Sun, Jan 05, 2014 at 04:53:12AM +0100, Francesco Pretto wrote:
Also it could break some users that rely on the current behavior.
The
W. Trevor King wk...@tremily.us writes:
On Sun, Jan 05, 2014 at 03:50:48AM +0100, Francesco Pretto wrote:
+case $update_module in
+'')
+;; # Unset update mode
+checkout | rebase | merge | none)
+
But for the simple use case where you only have a master
branch I consider it not really helpful and - at least for me -
misleading.
I see what you mean, and you're not the only one.
Git follows a rule of never contact another machine unless explicitly
asked to using a command such
Jiang Xin worldhello@gmail.com writes:
Please pull l10n update for maint branch. It can be merged to master
without conflict.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
A very common workflow for preparing patches involves working off a
topic branch and generating patches against 'master' to send off to the
maintainer. However, a plain
$ git format-patch -o outgoing
is a no-op on a topic branch, and the user has to remember to specify
'master' explicitly
Thomas Ackermann th.ac...@arcor.de writes:
Use asciidoc style 'article' instead of 'book' and change asciidoc title
level.
This removes blank first page and superfluous Part I page (there is no
Part II)
in pdf output. Also pdf size is decreased by this from 77 to 67 pages.
In html output
On Mon, Jan 06, 2014 at 04:47:39PM +0100, Heiko Voigt wrote:
On Sun, Jan 05, 2014 at 03:39:43PM -0800, W. Trevor King wrote:
On Sun, Jan 05, 2014 at 11:57:33PM +0100, Heiko Voigt wrote:
On Sun, Jan 05, 2014 at 01:24:58PM -0800, W. Trevor King wrote:
Thinking through this more, perhaps
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 51c2dd4..39b81f7 100644
---
Ramkumar Ramachandra wrote:
Ramkumar Ramachandra (2):
completion: complete format.coverLetter
format-patch: introduce format.defaultTo
Any thoughts on checkout.defaultTo? I have a com alias to checkout 'master'.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of
On Mon, Jan 06, 2014 at 08:56:22AM -0800, Junio C Hamano wrote:
Heiko Voigt hvo...@hvoigt.net writes:
Yes, why would you do a git pull in a submodule? Don't you want to do
something like
git checkout -t -b dev/my-topic origin/master
to start your development?
As long as
Hi,
On the latest git, I noticed that a rebase --onto doesn't abort
properly. Steps to reproduce:
# on some topic branch
$ git rebase --onto master @~10
^C # quickly!
$ git rebase --abort
# HEAD is still detached
I tried going back a few revisions, and the bug seems to be very old;
Junio C Hamano gits...@pobox.com writes:
W. Trevor King wk...@tremily.us writes:
On Sun, Jan 05, 2014 at 03:50:48AM +0100, Francesco Pretto wrote:
+ case $update_module in
+ '')
+ ;; # Unset update mode
+
Ok, applying the suggested modifications and resending shortly.
Thank you,
Francesco
2014/1/6 Junio C Hamano gits...@pobox.com:
Junio C Hamano gits...@pobox.com writes:
W. Trevor King wk...@tremily.us writes:
On Sun, Jan 05, 2014 at 03:50:48AM +0100, Francesco Pretto wrote:
+
Michael Haggerty mhag...@alum.mit.edu writes:
If safe_create_leading_directories() fails because a file along the
path unexpectedly vanished, try again (up to 3 times).
This can occur if another process is deleting directories at the same
time as we are trying to make them. For example, git
Michael Haggerty mhag...@alum.mit.edu writes:
If a file or directory that we are trying to remove disappears (e.g.,
because another process has pruned it), do not consider it an error.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
dir.c | 22 --
1 file
Michael Haggerty mhag...@alum.mit.edu writes:
If safe_create_leading_directories() fails because a file along the
path unexpectedly vanished, try again from the beginning. Try at most
3 times.
As the previous step bumped it from 3 to 4 without explanation, the
above no longer reflects
Michael Haggerty mhag...@alum.mit.edu writes:
Keep track of the position of the slash character independently of
pos, thereby making the purpose of each variable clearer and
working towards other upcoming changes.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
This step has an
Hi,
Ramkumar Ramachandra wrote:
a plain
$ git format-patch -o outgoing
is a no-op on a topic branch, and the user has to remember to specify
'master' explicitly everytime. Save the user the extra keystrokes by
introducing format.defaultTo
Not excited. Two reasons:
Ramkumar Ramachandra artag...@gmail.com writes:
A very common workflow for preparing patches involves working off a
topic branch and generating patches against 'master' to send off to the
maintainer. However, a plain
$ git format-patch -o outgoing
is a no-op on a topic branch,...
Two
Ramkumar Ramachandra artag...@gmail.com writes:
Hi,
On the latest git, I noticed that a rebase --onto doesn't abort
properly. Steps to reproduce:
# on some topic branch
$ git rebase --onto master @~10
^C # quickly!
$ git rebase --abort
# HEAD is still detached
I do not think
Junio C Hamano wrote:
- why is a single branch name sufficient?
It does accept a revision, so any form is allowed; but why would
anyone want that in a format.defaultTo? I'm not sure we want to impose
an artificial restriction on the configuration variable though.
- is it a better option to
Junio C Hamano wrote:
I do not think --abort was designed to abort an uncontrolled stop
like ^C in the first place.
Why not? All it requires is a reset --hard to
.git/rebase-apply/head-name, as usual, no?
To allow that kind of recovery, you
need to teach rebase to first record the state you
According to Documentation/gitmodules.txt, 'checkout' is a valid
'submodule.name.update' command. Also git-submodule.sh refers to
it and processes it correctly. Reflecting commit 'ac1fbb' to support
this syntax and also validate property values during 'update' command,
issuing an error if the
Jonathan Nieder wrote:
1. Most config settings are in noun form: e.g.,
[remote] pushDefault = foo. That makes their names easy to guess
and makes them easy to talk about: I set the default remote for
pushing by changing the remote.pushdefault setting.
'[url foo] insteadOf'
The Submodules section of the git mv documentation mentions what will
happen when a submodule with a gitfile gets moved with newer git. But it
doesn't talk about what happens when the user changes between commits
before and after the move, which does not update the work tree like using
the mv
On Mon, Jan 06, 2014 at 08:16:31AM -0800, Junio C Hamano wrote:
I was going to ask you to send your repository, but I can easily
reproduce here. I guess people don't run into it because it's uncommon
to fetch the whole refs/ namespace from a non-bare repo (and bare repos
do not tend to
On Mon, Jan 06, 2014 at 08:37:49AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
We could probably teach index-pack an --assume-refs-are-thin
option to optimize for this case, and have fetch-pack/receive-pack pass
it whenever they know that delta-base-offset was
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
- why is a single branch name sufficient?
It does accept a revision, so any form is allowed; but why would
anyone want that in a format.defaultTo? I'm not sure we want to impose
an artificial restriction on the
Jeff King p...@peff.net writes:
On Mon, Jan 06, 2014 at 08:16:31AM -0800, Junio C Hamano wrote:
I was going to ask you to send your repository, but I can easily
reproduce here. I guess people don't run into it because it's uncommon
to fetch the whole refs/ namespace from a non-bare repo
On Mon, Jan 06, 2014 at 12:06:51PM -0800, Junio C Hamano wrote:
Unless you set @{u} to this new configuration, in which case the
choice becomes dynamic depending on the current branch, but
- if that is the only sane choice based on the current branch, why
not use that as the default
On Mon, Jan 6, 2014 at 3:18 PM, Jeff King p...@peff.net wrote:
On Mon, Jan 06, 2014 at 12:06:51PM -0800, Junio C Hamano wrote:
Unless you set @{u} to this new configuration, in which case the
choice becomes dynamic depending on the current branch, but
- if that is the only sane choice based
Jeff King p...@peff.net writes:
On Mon, Jan 06, 2014 at 12:06:51PM -0800, Junio C Hamano wrote:
Unless you set @{u} to this new configuration, in which case the
choice becomes dynamic depending on the current branch, but
- if that is the only sane choice based on the current branch, why
On Mon, Jan 06, 2014 at 09:57:23AM -0500, Jeff King wrote:
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index c733379..0cff874 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -1402,6 +1402,19 @@ static void check_object(struct object_entry *entry)
John Szakmeister wrote:
I think in a
typical, feature branch-based workflow @{u} would be nearly useless.
I thought the idea of @{u} was that it represents which ref one
typically wants to compare the current branch to. It is used by
'git
On Mon, Jan 06, 2014 at 03:29:57PM -0500, John Szakmeister wrote:
Yeah, I had similar thoughts. I personally use branch.*.merge as
forkedFrom, and it seems like we are going that way anyway with things
like git rebase and git merge defaulting to upstream. But then there
is git push -u and
On Mon, Jan 06, 2014 at 12:38:30PM -0800, Junio C Hamano wrote:
I wonder if it is too late to try to clarify this dual usage. It kind of
seems like the push config is this is the place I publish to. Which,
in many workflows, just so happens to be the exact same as the place you
forked
On Mon, Jan 6, 2014 at 3:42 PM, Jonathan Nieder jrnie...@gmail.com wrote:
John Szakmeister wrote:
I think in a
typical, feature branch-based workflow @{u} would be nearly useless.
I thought the idea of @{u} was that it represents which
Sorry for the slow reply; I've been on vacation.
No worries.
When you build your bitmaps, do you set the pack.writeBitmapHashCache
option? We found that it makes a significant difference during the
compression phase, as otherwise git attempts deltas between random files
based on size. Here
Jeff King p...@peff.net writes:
On Mon, Jan 06, 2014 at 12:38:30PM -0800, Junio C Hamano wrote:
I wonder if it is too late to try to clarify this dual usage. It kind of
seems like the push config is this is the place I publish to. Which,
in many workflows, just so happens to be the exact
W. Trevor King wk...@tremily.us writes:
And wouldn't it make it unnecessary to have a new re-attach option
if such a mode that never have to detach is used?
I think so, but we currently don't have a never detached route for
folks that are cloning submodules via update (instead of via
John Szakmeister j...@szakmeister.net writes:
Am I missing something? If there is something other than @{u} to
represent this latter concept, I think `git push` should default to
that instead. But, at least with my current knowledge, that doesn't
exist--without explicitly saying so--or
Thanks for noticing,
I can reproduce at work, I will try to come-up with an improved version soon,
Cheers,
Antoine
On Mon, Jan 6, 2014 at 2:52 PM, Torsten Bögershausen tbo...@web.de wrote:
On 2013-12-29 12.30, Antoine Pelisse wrote:
Mercurial can have bookmarks pointing to nullid (the empty
On Mon, Jan 06, 2014 at 09:15:04PM +, Ben Maurer wrote:
Let me know how this patch does for you. My testing has been fairly
limited so far.
This patch looks like a much cleaner version :-). Works well for me,
but my test setup may not be great since I didn't get any errors from
Junio C Hamano wrote:
I meant a single branch as opposed to depending on what branch
you are sending out, you may have to use a different upstream
starting point, and a single format.defaultTo that does not read
what your HEAD currently points at may not be enough.
Unless you set @{u} to
Howdy,
Is there any policy on making static initializers thread-safe? I'm
working on an experimental patch to introduce threading, but I'm
running into a few non-thread-safe bits like this, in convert.c:
static const char *conv_attr_name[] = {
crlf, ident, filter, eol, text,
};
#define
Jeff King wrote:
Yeah, I had similar thoughts. I personally use branch.*.merge as
forkedFrom, and it seems like we are going that way anyway with things
like git rebase and git merge defaulting to upstream.
My issue with that is that I no idea where my branch is with respect
to my forked
It looks like for my repo the size win wasn't as big (~10%). Is it possible
that with the kernel test you got extremely lucky and there was some huge
binary blob that thin packing turned into a tiny delta?
The repo I'm testing with here isn't a typical codebase -- it is used to store
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
I meant a single branch as opposed to depending on what branch
you are sending out, you may have to use a different upstream
starting point, and a single format.defaultTo that does not read
what your HEAD currently points
Welcome to the first issue of What's cooking report for the new
year.
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
Junio C Hamano wrote:.
As I said in the different subthread, I am not convinced that you
would need the complexity of branch.*.forkedFrom. If you set your
upstream to the true upstream (not your publishing point), and
have remote.pushdefaultset to 'publish', you can expect
git push
John Szakmeister wrote:
Then where does it get pushed? Do you always specify where to save your work?
FWIW, I think the idea of treating @{u} as the eventual recipient of
your changes is good, but then it seems like Git is lacking the
publish my changes to this other branch concept.
Am I
On Mon, Jan 06, 2014 at 12:17:21PM -0800, Junio C Hamano wrote:
I am fine with rejecting it with a warning, but we should not then
complain that the other side did not send us the object, since we should
not be asking for it at all. I also do not see us complaining about the
funny ref
2014/1/6 Heiko Voigt hvo...@hvoigt.net:
I agree. If we were to support this more easily we could add a
configuration option so you can omit the --remote (i.e.:
submodule.name.remote=true, as I also suggested in the other email).
That way the developer checking out a branch in flight does not
2014/1/6 Junio C Hamano gits...@pobox.com:
- git-submodule.sh: support 'checkout' as a valid update mode
Need to pick up a rerolled one.
I resent it, can you see it?
Thank you,
Francesco
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Jeff King p...@peff.net writes:
Then we ask fetch_refs_via_pack to get the actual objects for us. And
it checks our refs again, with this call chain:
do_fetch
fetch_refs
transport_fetch_refs
fetch_refs_via_pack
fetch_pack
do_fetch_pack
Francesco Pretto ceztk...@gmail.com writes:
2014/1/6 Junio C Hamano gits...@pobox.com:
- git-submodule.sh: support 'checkout' as a valid update mode
Need to pick up a rerolled one.
I resent it, can you see it?
I know. I saw it and that is why I left the note to self.
The thing is, it
2014/1/7 Francesco Pretto cez...@gmail.com:
To not break the existing behavior what it's really needed here, IMO,
is a submodule.name.attached property that says two things:
- at the first clone on git submodule update stay attached to
submodule.name.branch;
- implies --remote, as it's the
Jens Lehmann jens.lehm...@web.de writes:
The Submodules section of the git mv documentation mentions what will
happen when a submodule with a gitfile gets moved with newer git. But it
doesn't talk about what happens when the user changes between commits
before and after the move, which does
2014/1/7 Junio C Hamano gits...@pobox.com:
The thing is, it takes a non trivial amount of time to run through a
single day's integration cycle, and any reroll that comes later in a
day once the cycle started may be too late for that day. Otherwise
I have to discard the the result of earlier
Francesco Pretto cez...@gmail.com writes:
According to Documentation/gitmodules.txt, 'checkout' is a valid
'submodule.name.update' command.
As you can see in the surrounding text, we call the value of
submodule.*.update a mode, not a command.
Also git-submodule.sh refers to
it and processes
2014/1/7 Junio C Hamano gits...@pobox.com:
Francesco Pretto cez...@gmail.com writes:
According to Documentation/gitmodules.txt, 'checkout' is a valid
'submodule.name.update' command.
As you can see in the surrounding text, we call the value of
submodule.*.update a mode, not a command.
Ok.
On Mon, Jan 6, 2014 at 11:05 PM, Stefan Zager sza...@google.com wrote:
Forwarding to msysgit for any guidance about win equivalents for
PTHREAD_MUTEX_INITIALIZER or __attribute__((constructor)).
As you've probably already guessed, PTHREAD_MUTEX_INITIALIZER isn't
supported in our
On Mon, Jan 6, 2014 at 5:54 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
John Szakmeister wrote:
Then where does it get pushed? Do you always specify where to save your
work?
FWIW, I think the idea of treating @{u} as the eventual recipient of
your changes is good, but then it seems
2014/1/6 Junio C Hamano gits...@pobox.com:
As long as origin/master contains the commit specified by the
superproject, that would work, but it may be a good thing to use a
mode of submodule.*.update that does not have to drop the user into
a detached state in the first place. I somehow
2014/1/7 Junio C Hamano gits...@pobox.com:
Sorry, but -ECANNOTPARSE.
A bird told me what -ECANNOTPARSE means. Tell me if this comment sounds better:
According to Documentation/gitmodules.txt, 'checkout' is a valid
'submodule.name.update' mode. Also git-submodule.sh already refers
to it and
On systems with lv configured as the preferred pager (i.e.,
DEFAULT_PAGER=lv at build time, or PAGER=lv exported in the
environment) git commands that use color show control codes instead of
color in the pager:
$ git diff
^[[1mdiff --git a/.mailfilter b/.mailfilter^[[m
Junio C Hamano gits...@pobox.com writes:
It's really not clear to me what the check in filter_refs was trying to
do. It dates all the way back to 1baaae5 (Make maximal use of the remote
refs, 2005-10-28), but there is not much explanation. I haven't dug into
the list around that time to see
This change ensures get_sha1_basic() doesn't try to resolve full hashes
as refs when ambiguous ref warnings are disabled.
This provides a substantial performance improvement when passing many
hashes to a command (like git rev-list --stdin) when
core.warnambiguousrefs is false. The check incurs 6
On Mon, Jan 6, 2014 at 7:32 PM, Brodie Rao bro...@sf.io wrote:
This change ensures get_sha1_basic() doesn't try to resolve full hashes
as refs when ambiguous ref warnings are disabled.
This provides a substantial performance improvement when passing many
hashes to a command (like git rev-list
95 matches
Mail list logo
