From: "Ramkumar Ramachandra"
Sent: Monday, April 08, 2013 10:03 PM
This is going nowhere. You're stuck at making the current submodule
system work, not answering my questions, diverting conversation,
repeatedly asking the same stupid questions, labelling everything that
I say "subjective", and
Sivaram Kannan writes:
> Hi,
>
> I am using git with Gitlab/Gitolite configuration. Git version is
> 1.7.9.5 in Ubuntu 12.04. There has been a consistent git crash
> recently and have attached the /var/crash/_usr_lib_git-core_
> git.1001.crash file.
>
> The crash output is pasted in the following
Hello
is there some way to know how far you are within a rebase when the rebase is
interupted by a conflict other than the message given by git rebase when it was
interrupted ?
I would have expected a git rebase --status or something similar...
Regards
Jérémy Rosen
fight key loggers
Signed-off-by: Felipe Contreras
---
contrib/completion/git-completion.bash | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 93eba46..d257b90 100644
--- a/contrib/completion/git-completi
On Wed, Apr 10, 2013 at 2:57 AM, Felipe Contreras
wrote:
> There's no functional reason for those, the only purpose they are
> supposed to serve is to say "we don't provide any words here", but even
> for that it's not used consitently.
s/consitently/consistently/
> Signed-off-by: Felipe Contrer
On Wed, Apr 10, 2013 at 2:57 AM, Felipe Contreras
wrote:
> The functionality we use from compgen is not much, we can do the same
> manually, with drastical improvements in speed, specially when dealing
s/drastical/drastic/
s/specially/especially/
> with only a few words.
>
> This patch also has
On Wed, Apr 10, 2013 at 2:57 AM, Felipe Contreras
wrote:
> There's no point in calling a separate function that is only used in one
> place. Specially considering that there's no need to call compgen, and
s/Specially/Especially/
> we traverse the words ourselves both in __gitcompadd, and __gitco
On 09.04.2013 at 23:59, Jürgen Kreileder wrote:
> Jakub Narębski writes:
>
>> On 08.04.2013, Junio C Hamano wrote:
>>> j...@blackdown.de (Jürgen Kreileder) writes:
>>>
Fixes the encoding for several _plain actions and for text/* and */*+xml
blobs.
Signed-off-by: Jürgen Kreil
On Wed, Apr 10, 2013 at 5:10 AM, Eric Sunshine wrote:
> s/specially/especially/
http://www.merriam-webster.com/dictionary/specially
--
Felipe Contreras
--
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
On Wed, Apr 10, 2013 at 06:07:33AM -0500, Felipe Contreras wrote:
> On Wed, Apr 10, 2013 at 5:10 AM, Eric Sunshine
> wrote:
> > s/specially/especially/
>
> http://www.merriam-webster.com/dictionary/specially
But see also:
http://www.merriam-webster.com/dictionary/especially
which notes "i
On Wed, Apr 10, 2013 at 06:13:06AM -0400, Eric Sunshine wrote:
> On Wed, Apr 10, 2013 at 2:57 AM, Felipe Contreras
> wrote:
> > we traverse the words ourselves both in __gitcompadd, and __gitcomp_1.
>
> s/ourselves/ourself/
Huh? "we traverse ... ourselves" is correct since "ourselves" is
associ
Jeff King peff.net> writes:
>
> I'm trying to track down a protocol bug that happens with shallow clones
> over smart-http. As far as I can tell, the bug has existed in all
> versions.
>
> You can reproduce it using the attached repository, which is a shallow
> clone of https://github.com/miles
Tom wrote:
> git pull --depth=9
Unrelated nit: we now have git fetch --unshallow.
--
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-info.html
The problem occurs to me also when I want to "deepen" a shallow clone of
MediaWiki via https://
git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git
git pull --depth=9
fatal: git fetch-pack: expected shallow list.
Perhaps it helps someone to find the reason.
UPDATE:
Th
Junio C Hamano wrote:
> diff --git a/Documentation/glossary-content.txt
> b/Documentation/glossary-content.txt
> index f928b57..69c90d1 100644
> --- a/Documentation/glossary-content.txt
> +++ b/Documentation/glossary-content.txt
> @@ -100,9 +100,22 @@ to point at the new commit.
>
> [[def_deta
Jonathan Nieder wrote:
> git push origin korg -- master; # push master to 2 remotes
> git push -- master next; # push two refs to default remote
> git push origin -- master; # push master to origin, more explicitly
> git push origin korg --; # push default refspec to
Jeff King wrote:
> git push --remote=host:some/path
>
> if we are willing to break the existing syntax. Though your proposal
> does have the benefit of breaking only one particular syntax which is
> (I'm guessing) less frequently used. But we'd still need the usual
> deprecation period, I think.
Junio C Hamano wrote:
> And I also misread "we currently don't handle" above as "but we
> really should allow adding d/f when d is at the top of the working
> tree of another project", but that was not what you meant to say.
> Instead, "We do not notice such a bad case in today's code yet" was
> wh
Junio C Hamano wrote:
> One can have symlinks to anywhere all one wants. We track symlinks.
> [...]
Yes, I know. We store symlinks as blobs containing one line, the path
to the file, without a trailing newline. And we have a mode for it to
distinguish it from regular files.
What I meant is:
On 03.04.13 16:28, Jeff King wrote:
> On Wed, Apr 03, 2013 at 07:54:02AM +0200, Torsten Bögershausen wrote:
>
>> Running make inside contrib/remote-helpers fails in "test-lint-duplicates"
>>
>> This was because the regexp checking for duplicate numbers strips everything
>> after the first "-" in t
Running make inside contrib/remote-helpers may fail in "test-lint-duplicates"
This was because the regexp checking for duplicate numbers strips everything
after the first "-" in the filename, including the prefix.
As a result, 2 pathnames like
"/contrib/remote-helpers/test-XX.sh" and
"/co
I have set of items with two attributes, , and would like to
keep them in some data structure in such a way that it is efficient
to (1) add a new item to the data structure, and (2) pick an item in
a specific order. There can be multiple items that share the same
value for X, or Y, or both X and Y,
Jakub Narębski writes:
> Junio C Hamano wrote:
>
>> diff --git a/Documentation/glossary-content.txt
>> b/Documentation/glossary-content.txt
>> index f928b57..69c90d1 100644
>> --- a/Documentation/glossary-content.txt
>> +++ b/Documentation/glossary-content.txt
>> @@ -100,9 +100,22 @@ to point at
Since GMail is SSL capable there is no need to set sslverify to false, the
example using it may confuse readers that it's needed since it's also used in
the previous example configurations, too
Signed-off-by: Barbu Paul - Gheorghe
---
Documentation/git-imap-send.txt | 1 -
1 file changed, 1 dele
On 04/10/2013 04:40 PM, Junio C Hamano wrote:
I have set of items with two attributes, , and would like to
keep them in some data structure in such a way that it is efficient
to (1) add a new item to the data structure, and (2) pick an item in
a specific order. There can be multiple items that sh
"...à¹à¸à¹à¸¡à¸²à¹à¸à¸¢à¸à¸¹à¸à¹à¸à¸à¸à¹à¸² มีà¹à¸¡à¸ à¸à¸³à¹à¸¡à¸¡à¸µà¹à¸¡à¸à¸à¸¢à¹à¸²à¸à¸à¸µà¹ à¸à¸³à¹à¸¡à¸à¸°à¸à¸¶à¸à¹à¸¡à¸à¸à¸µà¹à¸¥à¸à¸¡à¸²à¹à¸«à¹à¹à¸à¹
à¸à¹à¹à¸à¸¢à¹à¸à¹à¸¢à¸´à¸à¹à¸£à¸·à¹à¸à¸à¸à¸²à¸£à¸à¸³à¸à¸ à¸à¹à¸¡à¸²à¸à¸£à¸²à¸£à¸
On Wed, Apr 10, 2013 at 06:52:51PM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > git push --remote=host:some/path
> >
> > if we are willing to break the existing syntax. Though your proposal
> > does have the benefit of breaking only one particular syntax which is
> > (I'm guessing)
On Wed, Apr 10, 2013 at 04:14:34PM +0200, Torsten Bögershausen wrote:
> > test-lint-duplicates:
> > - @dups=`echo $(T) | tr ' ' '\n' | sed 's/-.*//' | sort | uniq -d` && \
> > + @dups=`echo $(T) | tr ' ' '\n' | \
> > + sed -e 's,.*/,,' -e 's/\(t[0-9][0-9][0-9][0-9]\)-.*/\1/' | \
> >
On Wed, Apr 10, 2013 at 04:22:57PM +0200, Torsten Bögershausen wrote:
> Running make inside contrib/remote-helpers may fail in "test-lint-duplicates"
>
> This was because the regexp checking for duplicate numbers strips everything
> after the first "-" in the filename, including the prefix.
>
>
Ramkumar Ramachandra writes:
> Exactly. Yeah, I don't think you patch makes sense as a standalone
> anyway.
Yes, it was purely a preparatory step.
--
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 ht
Jeff King writes:
> On Tue, Apr 09, 2013 at 06:19:01PM -0700, Junio C Hamano wrote:
>
>> >git push -- master next; # push two refs to default remote
>>
>> ... or default "push remote" if there is one, I presume?
>>
>> As you are giving what to push, I am assuming that
>> branch.$name.remote
Jeff King writes:
> On Tue, Apr 09, 2013 at 04:13:32PM -0700, Jonathan Nieder wrote:
>
>> Random idea: today you can do
>>
>> git push origin master; # push branch master to remote origin
>> git push --multiple origin korg; # push default refspec to 2 remotes
>
> Can we do "git push --
Am 10.04.2013 01:08, schrieb Junio C Hamano:
> Jens Lehmann writes:
>
>> diff --git a/submodule.c b/submodule.c
>> index 975bc87..eba9b42 100644
>> --- a/submodule.c
>> +++ b/submodule.c
>> @@ -1001,3 +1001,67 @@ int merge_submodule(unsigned char result[20], const
>> char *path,
>> ...
>> +i
Am 08.04.2013 20:36, schrieb BJ Hargrave:
> Git 1.8.2.1 includes commit bd54cf17 - archive: handle commits with
> an empty tree
>
> Test 2 of t5004-archive-corner-cases, "tar archive of empty tree is
> empty", fails on Mac OS X 10.8.3 (with XCode 4.6.1) since the tar
> command exits with return co
W dniu 07.04.2013 05:02, Trenton D. Adams pisze:
> On that first page that shows up, it shows the .git folder. It would
> be kind of nice if it shared out both the git repo and the actual
> current project files. I frequently have stuff I'd like to see in a
> web browser, and even requires one (
On Wed, Apr 10, 2013 at 09:37:01AM -0700, Junio C Hamano wrote:
> > The missing case 4 is obviously:
> >
> > dst=missing, refs=present
> > ...
> > Do you want to explain your thinking? I'm guessing it has to do with the
> > fact that choosing branch.*.remote is about trying to push to the
> > co
On Wed, Apr 10, 2013 at 09:38:26AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Tue, Apr 09, 2013 at 04:13:32PM -0700, Jonathan Nieder wrote:
> >
> >> Random idea: today you can do
> >>
> >>git push origin master; # push branch master to remote origin
> >>git push --multipl
Make it a bit clearer that --worktree-attributes is about files in the
working tree (checked out files, possibly changed) and not the current
working directory ($PDW). Link to the ATTRIBUTES section, which has
more details.
Reported-by: Amit Bakshi
Signed-off-by: Rene Scharfe
---
Does this help
Michael Campbell wrote:
> My company is moving from CVS to git in a few weeks (and we have a
> training class scheduled with the github folks).
>
> That said our CI/build guys have already got gitorious set up (we get
> to it through ssh with ssh keys and one "git" user on the server)
Note that
If a file's case is changed on rename (Foo -> foo), rebase
fails on Windows because the file already exists.
The change is safe, because if working directory is not clean
rebase fails before checking out.
---
git-rebase.sh |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git
Jeremy Rosen writes:
> is there some way to know how far you are within a rebase when the
> rebase is interupted by a conflict other than the message given by
> git rebase when it was interrupted ?
I do not think there is a "git $anything" command to do that, but in
the meantime you could "cat .
Junio C Hamano writes:
> I have set of items with two attributes, , and would like to
> keep them in some data structure in such a way that it is efficient
> to (1) add a new item to the data structure, and (2) pick an item in
> a specific order. There can be multiple items that share the same
>
On Wed, Apr 10, 2013 at 7:35 AM, John Keeping wrote:
> On Wed, Apr 10, 2013 at 06:13:06AM -0400, Eric Sunshine wrote:
>> On Wed, Apr 10, 2013 at 2:57 AM, Felipe Contreras
>> wrote:
>> > we traverse the words ourselves both in __gitcompadd, and __gitcomp_1.
>>
>> s/ourselves/ourself/
>
> Huh? "we
Executes checkout without -q
---
git-submodule.sh | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..f7964ad 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,11 +5,11 @@
# Copyright (c) 2007
W dniu 10.04.2013 16:45, Junio C Hamano pisze:
> Jakub Narębski writes:
>
>> Junio C Hamano wrote:
>>
>>> diff --git a/Documentation/glossary-content.txt
>>> b/Documentation/glossary-content.txt
>>> index f928b57..69c90d1 100644
>>> --- a/Documentation/glossary-content.txt
>>> +++ b/Documentatio
On Wed, Apr 10, 2013 at 1:49 PM, René Scharfe
wrote:
> Make it a bit clearer that --worktree-attributes is about files in the
> working tree (checked out files, possibly changed) and not the current
> working directory ($PDW). Link to the ATTRIBUTES section, which has
s/PDW/PWD/
> more details.
Barbu Paul - Gheorghe writes:
> Since GMail is SSL capable there is no need to set sslverify to false, the
> example using it may confuse readers that it's needed since it's also used in
> the previous example configurations, too
>
> Signed-off-by: Barbu Paul - Gheorghe
> ---
Thanks.
While rem
On Wed, Apr 10, 2013 at 09:08:50AM -0700, rh wrote:
> > which should show both program names. Git invokes git-remote-* based
> > on the URL you fed it. So if you are seeing a segfault in
> > git-remote-http, presumably you fed it an http URL (which may still
> > execute SSL code if it redirects to
Jeff King writes:
>> With the branch.$name.remote, the user tells us "When I am on this
>> branch, I want to talk to this remote". When you did
>>
>> git push -- master next ;# case #4
>>
>> on branch maint, branch.maint.remote should not come into play.
>
> I understand that's your posit
René Scharfe writes:
> Make it a bit clearer that --worktree-attributes is about files in the
> working tree (checked out files, possibly changed) and not the current
> working directory ($PDW). Link to the ATTRIBUTES section, which has
> more details.
>
> Reported-by: Amit Bakshi
> Signed-off-
Am 10.04.2013 01:47, schrieb Ken Ismert:
>
> I bumped into the UTF-16 display problem with Git Extensions running on top
> of msysGit. After lots of searching and experimenting, I came up with a
> solution that works for me.
>
> Note: Please see questions below.
>
> This method is for MSysGit
On Wed, Apr 10, 2013 at 11:54:34AM -0700, Junio C Hamano wrote:
> > If branch.$name.remote is "when I am on this branch, I want to talk to
> > this remote", that rule is not be impacted by the presence of refspecs
> > at all.
>
> So running the above while on 'maint' will send master and next to
On OSX Tcl/Tk application windows are created behind all
the applications down the stack of windows. This is very
annoying, because once a gitk window appears, it's the
downmost window and switching to it is pain.
The patch is trivial: if we are on OSX, emulate Cmd-Shift-TAB
key event, so that th
Currently, humanization of downloaded size is done in the same
function as text formatting in 'process.c'. This is an issue if anyone
else wants to use this.
Separate text formatting from size simplification and make the function
public in strbuf so that it can easily be used by other clients.
We
Use the new humanize() function to print loose objects size, pack size,
and garbage size in verbose mode, or loose objects size in regular mode.
This patch doesn't change the way anything is displayed when the option
is not used.
Also update the documentation.
Signed-off-by: Antoine Pelisse
---
On Wed, Apr 10, 2013 at 02:51:14PM -0400, Jeff King wrote:
> As for why dmesg reports git-remote-http, I'm not sure. If you "strace
> -f" the command, you can see that git is running git-remote-https. Why
> the kernel chooses to report "git-remote-http", I don't know; you'd have
> to look into how
The prev message was garbled :( Here is the correct patch (I hope).
On OSX Tcl/Tk application windows are created behind all
the applications down the stack of windows. This is very
annoying, because once a gitk window appears, it's the
downmost window and switching to it is pain.
The patch is t
On Mon, Apr 8, 2013 at 12:13 PM, Felipe Contreras
wrote:
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -731,6 +722,26 @@ def do_export(parser):
> if peer:
> parser.repo.push(peer, force=False)
>
> +# handle bookmarks
> +for b
On Mon, Apr 8, 2013 at 12:13 PM, Felipe Contreras
wrote:
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -625,6 +625,10 @@ def parse_commit(parser):
> if merge_mark:
> get_merge_files(repo, p1, p2, files)
>
> +# Check if the ref is
Junio C Hamano writes:
> Jeremy Rosen writes:
>
>> is there some way to know how far you are within a rebase when the
>> rebase is interupted by a conflict other than the message given by
>> git rebase when it was interrupted ?
>
> I do not think there is a "git $anything" command to do that, bu
Jeff King wrote:
> On Wed, Apr 10, 2013 at 11:54:34AM -0700, Junio C Hamano wrote:
>> > If branch.$name.remote is "when I am on this branch, I want to talk to
>> > this remote", that rule is not be impacted by the presence of refspecs
>> > at all.
>>
>> So running the above while on 'maint' will se
Ramkumar Ramachandra wrote:
> Otherwise, I think we're consistent. git push master; pushes the
> refspec master (with no explicit : counterpart) to the "default
> place to push to" (either depending on which branch I am, or global).
> I think Junio was mixing up refspecs with refs (branches, and h
Jakub Narębski writes:
> P.S. From some StackOverflow questions the connection between "(no
> branch)" and detached HEAD is not clear for git newbies...
If _that_ is the problem you are really trying to address, the
output from recent Git already says "(detached from xx)" or
something, so I
Felipe Contreras writes:
> On Mon, Apr 8, 2013 at 12:13 PM, Felipe Contreras
> wrote:
>
>> --- a/contrib/remote-helpers/git-remote-hg
>> +++ b/contrib/remote-helpers/git-remote-hg
>
>> @@ -731,6 +722,26 @@ def do_export(parser):
>> if peer:
>> parser.repo.push(peer, force=False)
>>
Antoine Pelisse wrote:
> Separate text formatting from size simplification and make the function
> public in strbuf so that it can easily be used by other clients.
>
> We now can use strbuf_humanize() for both downloaded size and download
> speed calculation.
Sounds like a good thing to do.
>
On Thu, Apr 11, 2013 at 01:01:33AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > On Wed, Apr 10, 2013 at 11:54:34AM -0700, Junio C Hamano wrote:
> >> > If branch.$name.remote is "when I am on this branch, I want to talk to
> >> > this remote", that rule is not be impacted by the presen
Ramkumar Ramachandra wrote:
> git push -- master next; pushes to my current branch's
> branch..pushremote? Isn't that a disaster?
Actually, branch..pushremote already breaks the current design
in a way, as Junio pointed out in a different email: a push.default
set to anything except "current" is
On Wed, Apr 10, 2013 at 12:16:25PM -0700, rh wrote:
> > > This returns no error on the command line and produced the segfault
> > > reported by the kernel. git clone returns immediately.
> >
> > It does correctly report a failed exit code. The lack of message is
> > because git assumes that the h
Antoine Pelisse writes:
> Currently, humanization of downloaded size is done in the same
> function as text formatting in 'process.c'. This is an issue if anyone
> else wants to use this.
>
> Separate text formatting from size simplification and make the function
> public in strbuf so that it can
On Wed, Apr 10, 2013 at 9:43 PM, Jonathan Nieder wrote:
> Antoine Pelisse wrote:
>>One of the drawbacks is that speed will now look like
>> this when download is stalled: "0 bytes/s" instead of "0 KiB/s".
>
> At first glance that is neither obviously a benefit nor obviously a
>
Am 10.04.2013 20:24, schrieb Orgad Shaneh:
> Executes checkout without -q
Nice, looks like you picked the proposal I made last September:
http://permalink.gmane.org/gmane.comp.version-control.git/204747
The change is looking good, but you still need to document the
new option in Documentation/g
Ramkumar Ramachandra wrote:
> Ramkumar Ramachandra wrote:
>> git push -- master next; pushes to my current branch's
>> branch..pushremote? Isn't that a disaster?
>
> Actually, branch..pushremote already breaks the current design
> in a way
I don't see a big problem here, actually. What's so wro
On Thu, Apr 11, 2013 at 01:23:57AM +0530, Ramkumar Ramachandra wrote:
> Ramkumar Ramachandra wrote:
> > git push -- master next; pushes to my current branch's
> > branch..pushremote? Isn't that a disaster?
>
> Actually, branch..pushremote already breaks the current design
> in a way, as Junio po
Jeff King wrote:
> Maybe. But no more so than the current:
>
> git push
>
> which may also push master and next to the same remote.
I would argue that this was not really a problem in practice, until I
introduced branch..pushremote.
Let us imagine that I was working on artagnon/git.git (remote:
When 'git submodule add/update' is run there is no output during
checkout. This can take a significant amount of time and it would
be nice if user could enable some feedback to see what's going on.
Add the -v/--verbose option to both add and update which suppresses
the -q normally given to checkou
On Wed, Apr 10, 2013 at 01:05:12PM -0700, Jonathan Nieder wrote:
> I don't see a big problem here, actually. What's so wrong with
> branch..remote affecting what "git push" does? If
> branch.crazy-feature.remote is my-personal-remote and I run
>
> git push
>
> and "[push] default = upstr
On Wed, Apr 10, 2013 at 9:57 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>> Currently, humanization of downloaded size is done in the same
>> function as text formatting in 'process.c'. This is an issue if anyone
>> else wants to use this.
>>
>> Separate text formatting from size simpli
On Wed, Apr 10, 2013 at 11:00 PM, Jens Lehmann wrote:
>
> Am 10.04.2013 20:24, schrieb Orgad Shaneh:
> > Executes checkout without -q
>
> Nice, looks like you picked the proposal I made last September:
> http://permalink.gmane.org/gmane.comp.version-control.git/204747
Took me a while, but I fin
Jeff King wrote:
> On Thu, Apr 11, 2013 at 01:23:57AM +0530, Ramkumar Ramachandra wrote:
>
>> Ramkumar Ramachandra wrote:
>> > git push -- master next; pushes to my current branch's
>> > branch..pushremote? Isn't that a disaster?
>>
>> Actually, branch..pushremote already breaks the current design
On Thu, Apr 11, 2013 at 01:35:34AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > Maybe. But no more so than the current:
> >
> > git push
> >
> > which may also push master and next to the same remote.
>
> I would argue that this was not really a problem in practice, until I
> intro
Jeff King writes:
> If we changed push.default=matching to ignore branch.*.remote, then that
> would be consistent, and would probably be safer over all. It is a
> regression, but I doubt that anybody was using branch.*.remote for this;
> it really only makes sense with the "upstream" mode.
True
On Thu, Apr 11, 2013 at 01:49:54AM +0530, Ramkumar Ramachandra wrote:
> > Right, the example above might include multiple remotes if pushremote is
> > respected. Or it might not come up with an answer at all for a tag.
> > If you do:
> >
> > git push -- v1.2.3 master
> >
> > where does v1.2.3 go
Ramkumar Ramachandra writes:
> As the author of branch..pushremote, I apologize for not having
> caught this earlier. I've been using push.default = current for a
> long time, and don't often think about the other settings.
Possibly, but I do not know it is such a big issue.
On the other hand,
The goal is to propose a structure for storing and pre-merging pairs of commits.
Data-structure
==
We could use a note ref to store the pre-merge information. Each commit
would be annotated with a blob containing the list of pre-merges (one
sha1 per line with sha1 pointing to a merge
Jeff King wrote:
> On Thu, Apr 11, 2013 at 01:35:34AM +0530, Ramkumar Ramachandra wrote:
>
>> Jeff King wrote:
>> > Maybe. But no more so than the current:
>> >
>> > git push
>> >
>> > which may also push master and next to the same remote.
>>
>> I would argue that this was not really a problem i
On Tue, Apr 09, 2013 at 01:12:47PM -0400, Jeff King wrote:
> On Tue, Apr 09, 2013 at 07:45:53AM +0200, Magnus Therning wrote:
>
>> I've been trying to set up git-http-backend+lighttpd. I've managed
>> to set up anonymous read-only access, and I then successfully
>> configured authentication for b
On Tue, Apr 09, 2013 at 02:24:26PM +0200, Jakub Narębski wrote:
> On 09.04.2013, Magnus Therning wrote:
>
> > I've been trying to set up git-http-backend+lighttpd. I've managed to
> > set up anonymous read-only access, and I then successfully configured
> > authentication for both read and write.
Jeff King wrote:
> On Thu, Apr 11, 2013 at 01:49:54AM +0530, Ramkumar Ramachandra wrote:
>> Huh, why? Simply because he specified master alongside it? How can
>> we infer what you said in a consistent system?
>
> That's kind of my point. Why would they put two refs together in a
> single push com
Ramkumar Ramachandra wrote:
> Jeff King wrote:
>> If we are not going to break the existing behavior, I think it can be
>> argued that consistency and simplicity of the rules is important, so the
>> user can predict what will happen. But the more we discuss, the more I
>> think we should simply cha
On Thu, Apr 11, 2013 at 02:25:59AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > On Thu, Apr 11, 2013 at 01:49:54AM +0530, Ramkumar Ramachandra wrote:
> >> Huh, why? Simply because he specified master alongside it? How can
> >> we infer what you said in a consistent system?
> >
> > T
When moving a submodule which uses a gitfile to point to the git directory
stored in .git/modules/ of the superproject two changes must be made
to make the submodule work: the .git file and the core.worktree setting
must be adjusted to point from work tree to git directory and back.
Achieve that b
Jeff King wrote:
> But I think all of this discussion just reinforces my point. We do not
> have to agree on what the user intended. But the fact that we do not
> agree means that out of a sample size of 2 users, we have 2 different
> things the user expects to happen. If we choose a behavior and s
I think this topic is close to being done, so I just wanted to move it
along.
[1/2]: transport-helper: report errors properly
This is Felipe's v4 patch with the adjustments I suggested in
review. It explains more in the commit message, and should fix
Thomas's valgrind failures (it c
From: Felipe Contreras
If a push fails because the remote-helper died (with
fast-export), the user does not see any error message. We do
correctly die with a failed exit code, as we notice that the
helper has died while reading back the ref status from the
helper. However, we don't print any mess
When we try to read from a remote-helper and get EOF or an
error, we print a message indicating that the helper died.
However, users may not know that a remote helper was in use
(e.g., when using git-over-http), or even what a remote
helper is.
Let's print the name of the helper (e.g., "git-remote
Junio C Hamano wrote:
> On the other hand, a good thing is that the remote.pushdefault makes
> perfect sense whether you use the upstream mode or the matching
> mode. I vaguely recall that I kept telling you that the overall
> default should be there and per-branch stuff can come later if/as
> nee
Ramkumar Ramachandra wrote:
>My point is that we should have "sane"
> defaults, and fine-grained configurability so that uses who disagree
> can maintain their own configs.
I don't agree with this principle. I like a tool that behaves sanely
with little work and t
On Wed, Apr 10, 2013 at 2:15 PM, Jeff King wrote:
> From: Felipe Contreras
>
> If a push fails because the remote-helper died (with
> fast-export), the user does not see any error message. We do
> correctly die with a failed exit code, as we notice that the
> helper has died while reading back th
Jeff King wrote:
> On Wed, Apr 10, 2013 at 01:05:12PM -0700, Jonathan Nieder wrote:
>> git push
>>
>> and "[push] default = upstream", then it is obvious what the user
>> wanted to happen. But what about when "[push] default = matching"?
>> Which of the following behaviors is correct?
>>
>>
Jonathan Nieder wrote:
> When people disagree about sane defaults, that's a sign that we didn't
> understand the problem well. Often more thinking can lead to a
> simpler answer.
Okay, let's see if we can all agree.
In a different email, you wrote:
>git push master
> ...
> a) Error: you
1 - 100 of 154 matches
Mail list logo
