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 "1">foo && git add foo && git commit -m "1"
cd ..
git clone repo_a repo_b
cd repo_a
echo "2">foo && git add foo && git commit -m "2"
On 6 January 2014 01:24, Thomas Ackermann 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 "1">foo && git add foo && git commit -m "1"
> cd ..
> git clone repo_
2014/1/6 Thomas Ackermann :
>
> 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 "1">foo && git add foo && git commit -m "1"
> cd ..
> git clone repo_a repo_b
> cd repo_a
> e
>
> 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. Onc
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 seri
Signed-off-by: Michael Haggerty
---
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 *path)
This makes it more obvious that values of "st" don't persist across
loop iterations.
Signed-off-by: Michael Haggerty
---
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
+++ b/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
d
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
---
refs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/refs.c b/refs.c
index 8de636e..490525a 100644
--- a/
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
safe_create_leading_directories_const() returns a non-zero value on
error. The old code at this calling site recognized a couple of
particular error values, and treated all other return values as
success. Instead, be more conservative: recognize the errors we are
interested in, but treat any othe
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(-)
diff --git a/dir.c b/dir.c
index 11e
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
---
dir.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/dir.c b/dir.c
index 23b6de4..11e1520 100644
--
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..
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
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 +
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
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
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
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
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: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 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 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 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 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
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
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
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
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
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
"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
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
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
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
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
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
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
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
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
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
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 |
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
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
+
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
> --
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 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:
> 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
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
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
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
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
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
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
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
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
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
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.
>
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
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
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
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 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
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 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
'gi
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
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 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
> 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
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
"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
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
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
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
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
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
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
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
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.pushdefault"set to 'publish', you can expect
>
>
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.
>
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
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
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
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
>
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
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
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 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
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
1 - 100 of 112 matches
Mail list logo
