On Tue, Jan 7, 2014 at 10:32 AM, Brodie Rao 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 --std
Jonathan Nieder writes:
> 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/.mailfil
On Mon, Jan 06, 2014 at 06:47:58PM +0100, Francesco Pretto wrote:
> I'm really sorry, I thought this was already clear from the first
> patch iteration. I will go more in depth:
For me anyway, this extra detail is very helpful. Thanks :).
> Maintainer of "project1" also prepares a branch
> "proj
On Mon, Jan 6, 2014 at 7:32 PM, Brodie Rao 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 --stdi
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
Junio C Hamano 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 if there's
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
^[[1
2014/1/7 Junio C Hamano :
> 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..update' mode. Also "git-submodule.sh" already refers
to it and handles it correctl
2014/1/6 Junio C Hamano :
>
> 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 thought that was
>
On Mon, Jan 6, 2014 at 5:54 PM, Ramkumar Ramachandra 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 like Git
On Mon, Jan 6, 2014 at 11:05 PM, Stefan Zager 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 pthreads-emulator. I did send o
2014/1/7 Junio C Hamano :
> Francesco Pretto writes:
>
>> According to "Documentation/gitmodules.txt", 'checkout' is a valid
>> 'submodule..update' command.
>
> As you can see in the surrounding text, we call the value of
> submodule.*.update a "mode", not a command.
>
Ok.
>> Also "git-submodule
Francesco Pretto writes:
> According to "Documentation/gitmodules.txt", 'checkout' is a valid
> 'submodule..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 it correct
2014/1/7 Junio C Hamano :
> 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 merges and test
Jens Lehmann 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 not update th
2014/1/7 Francesco Pretto :
> To not break the existing behavior what it's really needed here, IMO,
> is a "submodule..attached" property that says two things:
> - at the first clone on "git submodule update" stay attached to
> "submodule..branch";
> - implies "--remote", as it's the only thing tha
Francesco Pretto writes:
> 2014/1/6 Junio C Hamano :
>>
>> - 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 takes a non trivial amo
Jeff King 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
>
2014/1/6 Junio C Hamano :
>
> - 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 majord...@vger.kernel
2014/1/6 Heiko Voigt :
>
> 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..remote=true, as I also suggested in the other email).
>
> That way the developer checking out a branch in flight does not even
> need to
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
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.
>
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.pushdefault"set to 'publish', you can expect
>
>
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
Ramkumar Ramachandra 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 at m
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
configurat
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 fo
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",
};
#de
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
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
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 wrote:
> On 2013-12-29 12.30, Antoine Pelisse wrote:
>> Mercurial can have bookmarks pointing to "nullid" (the empty root
>> rev
John Szakmeister 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 treating @{u} as that
"W. Trevor King" 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
> 'submodul
Jeff King 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 s
> 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. H
On Mon, Jan 6, 2014 at 3:42 PM, Jonathan Nieder 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 ref one
> ty
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
> > f
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
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
'gi
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)
>
Jeff King 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 6, 2014 at 3:18 PM, Jeff King 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 on
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
Jeff King 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 (and
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> - why is a single branch name sufficient?
>
> It does accept a , 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
Francesco Pretto writes:
> 2014/1/6 Heiko Voigt :
>> Could you describe something like this for your workflow? A complete
>> change lifecycle when a developer works, as you call it, "actively" in a
>> submodule?
>>
>
> I'm really sorry, I thought this was already clear from the first
> patch iterat
On Mon, Jan 06, 2014 at 08:37:49AM -0800, Junio C Hamano wrote:
> Jeff King 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.
>
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 ten
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 c
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 ""] inste
According to "Documentation/gitmodules.txt", 'checkout' is a valid
'submodule..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 value
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 sta
Junio C Hamano wrote:
> - why is a single branch name sufficient?
It does accept a , 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 simply d
Ramkumar Ramachandra 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 --abort w
Ramkumar Ramachandra 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 points.
- wh
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 re
Michael Haggerty 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
> ---
This step has an interaction with $gmane/239878 wher
Michael Haggerty 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 reality ;-)
The series
Michael Haggerty 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
> ---
> dir.c | 22 --
> 1 file changed, 16 insertions(+), 6 deletions(
Michael Haggerty 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 pack-refs
> --
Ok, applying the suggested modifications and resending shortly.
Thank you,
Francesco
2014/1/6 Junio C Hamano :
> Junio C Hamano writes:
>
>> "W. Trevor King" writes:
>>
>>> On Sun, Jan 05, 2014 at 03:50:48AM +0100, Francesco Pretto wrote:
+ case "$update_module" in
+
Dear Heiko, my replies below. I also take a couple excerpts from other
emails, as I prefer to not flame on different threads :) .
2014/1/6 Heiko Voigt :
> On Sun, Jan 05, 2014 at 10:46:11PM +0100, Francesco Pretto wrote:
>> It means he doesn't need to control other developers commit to be
>> check
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;
I'm
Junio C Hamano writes:
> "W. Trevor King" writes:
>
>> On Sun, Jan 05, 2014 at 03:50:48AM +0100, Francesco Pretto wrote:
>>> + case "$update_module" in
>>> + '')
>>> + ;; # Unset update mode
>>> + checkout | rebase |
On Mon, Jan 06, 2014 at 08:56:22AM -0800, Junio C Hamano wrote:
> Heiko Voigt 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 origin/mas
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 b
Signed-off-by: Ramkumar Ramachandra
---
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
--- a/contrib/completion/git-completion.bash
+++ b/cont
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, p
Thomas Ackermann 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 this rem
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 every
Hi,
This is inspired by merge.defaultToUpstream. Disclaimer: I have an
"fpm" alias for doing this (separate from "fp" for when I need to
generate patches against some other branch), which I'd like to get rid
of.
Thanks.
Ramkumar Ramachandra (2):
completion: complete format.coverLetter
format
Thomas Ackermann writes:
>
>> > 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 unl
Jiang Xin 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 http://vger.kernel.org/majordomo-in
Heiko Voigt writes:
> On Sun, Jan 05, 2014 at 10:27:19PM +0100, Francesco Pretto wrote:
>> 2014/1/5 W. Trevor King :
>> > 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
"W. Trevor King" 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 co
On Sun, Jan 05, 2014 at 05:12:56PM -0800, W. Trevor King wrote:
> On Sun, Jan 05, 2014 at 04:33:14PM -0800, W. Trevor King wrote:
> > The only people who would need *automatic* rebase recovery would be
> > superproject devs update-cloning the subproject. That's a small
> > enough cross-section tha
Jeff King 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
encoded
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
Jeff King 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 ask
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..branch is set, it *always* creates a new local
> > > branch of that name pointing to
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 s
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..branch):
$ git submod
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 ask you to send your repository,
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
On Sun, Jan 05, 2014 at 10:27:19PM +0100, Francesco Pretto wrote:
> 2014/1/5 W. Trevor King :
> > 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 an ini
On Mon, Jan 06, 2014 at 12:22:23AM +0100, Francesco Pretto wrote:
> 2014/1/5 Heiko Voigt :
> > 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 threats
On Sun, Jan 05, 2014 at 10:46:11PM +0100, Francesco Pretto wrote:
> 2014/1/5 Heiko Voigt :
> > 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 commits using
It's about to become a bit more complex.
Signed-off-by: Michael Haggerty
---
refs.c | 52 ++--
1 file changed, 30 insertions(+), 22 deletions(-)
diff --git a/refs.c b/refs.c
index 8a3d3ea..5bc01a7 100644
--- a/refs.c
+++ b/refs.c
@@ -2528,6 +2528,
If a directory vanishes while renaming the temporary reflog file,
retry (up to 3 times). This could happen if another process deletes
the directory created by safe_create_leading_directories() just before
we rename the file into the directory.
As far as I can tell, this race could not occur inter
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
---
sha1_file.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
d
Instead of returning magic integer values (which a couple of callers
go to the trouble of distinguishing), return values from an enum. Add
a docstring.
Signed-off-by: Michael Haggerty
---
builtin/init-db.c | 4 ++--
cache.h | 17 +++--
merge-recursive.c | 2 +-
sha1_file
Always restore the slash that we scribbled over at the end of the
loop, rather than also fixing it up at each premature exit from the
loop. This makes it harder to forget to do the cleanup as new paths
are added to the code.
Signed-off-by: Michael Haggerty
---
sha1_file.c | 22 +
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 no
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
---
refs.c | 13
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
---
refs.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 490525a
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
---
sha1_file.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 197766d..
If the input path has multiple slashes between path components (e.g.,
"foo//bar"), then the old code was breaking the path at the last
slash, not the first one. So in the above example, the second slash
was overwritten with NUL, resulting in the parent directory being
sought as "foo/".
When stat(
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 pack-refs
--all" tries to delete the loose refs an
1 - 100 of 112 matches
Mail list logo
