Duy Nguyen writes:
> On Mon, Jun 3, 2019 at 4:29 PM Christian Couder
> wrote:
>>
>> On Sun, Jun 2, 2019 at 7:38 PM Drew DeVault wrote:
>> >
>> > This flag would behave similarly to git apply --check, or in other words
>> > would exit with a nonzero status if the patch is not applicable without
On Mon, Jun 3, 2019 at 4:29 PM Christian Couder
wrote:
>
> On Sun, Jun 2, 2019 at 7:38 PM Drew DeVault wrote:
> >
> > This flag would behave similarly to git apply --check, or in other words
> > would exit with a nonzero status if the patch is not applicable without
> > actually applying the patc
On Sun, Jun 2, 2019 at 7:38 PM Drew DeVault wrote:
>
> This flag would behave similarly to git apply --check, or in other words
> would exit with a nonzero status if the patch is not applicable without
> actually applying the patch otherwise.
`git am` uses the same code as `git apply` to apply pa
Hi,
Matthew DeVore wrote:
> On 2019/05/09, at 11:00, Jonathan Tan wrote:
>> - Supporting any combination of filter means that we have more to
>> implement and test, especially if we want to support more filters in
>> the future. In particular, the different filters (e.g. blob, tree)
>> have d
> On 2019/05/09, at 11:00, Jonathan Tan wrote:
>
> Thanks for the numbers. Let me think about it some more, but I'm still
> reluctant to introduce multiple filter support in the protocol and the
> implementation for the following reasons:
Correction to the original command - I was tweaking it
On 2019-05-09 11:51 AM, Emily Shaffer wrote:
> I'm still not sure I see the value of the extra header proposed here.
> I'd appreciate an explanation of how you think it would be used, Drew.
I'm not just thinking about your run of the mill mail reader, but also
mail readers which are aware of git a
Drew DeVault wrote:
> --in-reply-to=ask doesn't exist, that's what I'm looking to add. This
> convenient storage mechanism is exactly what I'm talking about. Sorry
> for the confusion.
Using Net::NNTP to query NNTP servers using ->xover([recent-ish
range]) to scan for Message-IDs and Subjects mat
On Thu, May 09, 2019 at 12:50:25PM -0400, Drew DeVault wrote:
> On 2019-05-08 5:19 PM, Emily Shaffer wrote:
> > What I think might be useful (and what I was hoping you were going to
> > talk about when I saw the subject line) would be if the Message-Id is
> > conveniently stored during `git send-e
> > On 2019/05/07, at 11:34, Jonathan Tan wrote:
> >
> > To get an enumeration of available objects, don't you need to use only
> > "blob:none"? Combining filters (once that's implemented) will get all
> > objects only up to a certain depth.
> >
> > Combining "tree:" and "blob:none" would allow us
On 2019-05-08 5:19 PM, Emily Shaffer wrote:
> What I think might be useful (and what I was hoping you were going to
> talk about when I saw the subject line) would be if the Message-Id is
> conveniently stored during `git send-email` on v1 and somehow saved in a
> useful place in order to apply to
On Wed, May 08, 2019 at 07:10:13PM -0400, Drew DeVault wrote:
> I want to gather some thoughts about this. Say you've written a patch
> series and are getting ready to send a -v2. If you set
> --in-reply-to=ask, it'll show you a list of emails you've recently sent,
> and their subject lines, and as
> On 2019/05/07, at 11:34, Jonathan Tan wrote:
>
> To get an enumeration of available objects, don't you need to use only
> "blob:none"? Combining filters (once that's implemented) will get all
> objects only up to a certain depth.
>
> Combining "tree:" and "blob:none" would allow us to reduc
> > My main question is: we can get the same list of objects (in the form of
> > tree objects) if we fetch with "blob:none" filter. Admittedly, we will
> > get extra data (file names, etc.) - if the extra bandwidth saving is
> > necessary, this should be called out. (And some of the savings will be
Matthew DeVore wrote:
> On 2019/05/06, at 12:46, Jonathan Nieder wrote:
>> Ah, interesting. When this was discussed before, the proposal has been
>> that the client can say "have" anyway. They don't have the commit and
>> all referenced objects, but they have the commit and a *promise* that
>>
> On 2019/05/06, at 12:46, Jonathan Nieder wrote:
>
> Hi,
>
> Jonathan Tan wrote:
>> Matthew DeVore wrote:
>
>>> I'm considering implementing a feature in the Git protocol which would
>>> enable efficient and accurate object negotiation when the client is a
>>> partial clone. I'd like to ref
On Mon, May 6, 2019 at 12:28 PM Jonathan Tan wrote:
>
> > I'm considering implementing a feature in the Git protocol which would
> > enable efficient and accurate object negotiation when the client is a
> > partial clone. I'd like to refine and get some validation of my
> > approach before I start
Hi,
Jonathan Tan wrote:
> Matthew DeVore wrote:
>> I'm considering implementing a feature in the Git protocol which would
>> enable efficient and accurate object negotiation when the client is a
>> partial clone. I'd like to refine and get some validation of my
>> approach before I start to write
> I'm considering implementing a feature in the Git protocol which would
> enable efficient and accurate object negotiation when the client is a
> partial clone. I'd like to refine and get some validation of my
> approach before I start to write any code, so I've written a proposal
> for anyone int
Hi,
Matthew DeVore wrote:
> I'm considering implementing a feature in the Git protocol which would
> enable efficient and accurate object negotiation when the client is a
> partial clone. I'd like to refine and get some validation of my
> approach before I start to write any code, so I've written
I have a deal for you
Ævar Arnfjörð Bjarmason writes:
> This seems like a reasonable idea, until such time as someone submits
> patches to implement this in git you can do this with some invocation of
> GNU parallel -k, i.e. operate on N remotes in parallel, and use the -k
> option to buffer up all their output and pr
On Wed, Feb 06 2019, Victor Porton wrote:
> I experienced a slowdown in Git pushing when I push to more than one server.
>
> I propose:
>
> Run push to several servers in parallel.
>
> Not to mix the output, nevertheless serialize the output, that is for
> example cache the output of the second
Hello,
Compliment of the day to you. I am Mrs. Elodie, I am sending this brief
letter to solicit your partnership to transfer $5.5 million US Dollars into
your account for investment in your country. I shall send you more information
and procedures when I receive positive response from you.
Thank
On Tue, Jun 13, 2017 at 8:55 AM, Marc Branchaud wrote:
> On 2017-06-13 10:41 AM, Marc Branchaud wrote:
>>
>>
>> So I like your refs/tracking proposal, and hope that it aims for mirroring
>> a remote's refs, to eventually replace refs/remotes entirely.
>
>
> To be extra-clear:
>
> I think a refs/tr
On 2017-06-13 10:41 AM, Marc Branchaud wrote:
So I like your refs/tracking proposal, and hope that it aims for
mirroring a remote's refs, to eventually replace refs/remotes entirely.
To be extra-clear:
I think a refs/tracking hierarchy that starts with notes and maybe some
other bits is a g
On 2017-06-12 06:58 PM, Jacob Keller wrote:
Hi,
There's no actual code yet, (forgive me), but I've been thinking back
to a while ago about attempting to find a way to share things like
refs/notes, and similar refs which are usually not shared across a
remote.
By default, those refs are not prop
On 05/03/2017 09:29 PM, Junio C Hamano wrote:
Jonathan Tan writes:
I see the semantics as "don't write what you already have", where
"have" means what you have in local storage, but if you extend "have"
to what upstream has, then yes, you're right that this changes
(ignoring shallow clones).
Jonathan Tan writes:
> I see the semantics as "don't write what you already have", where
> "have" means what you have in local storage, but if you extend "have"
> to what upstream has, then yes, you're right that this changes
> (ignoring shallow clones).
>
> This does remove a resistance that we
On 05/02/2017 11:32 AM, Ævar Arnfjörð Bjarmason wrote:
On Tue, May 2, 2017 at 7:21 PM, Jonathan Tan wrote:
On Mon, May 1, 2017 at 6:41 PM, Junio C Hamano wrote:
Jonathan Tan writes:
On 05/01/2017 04:29 PM, Junio C Hamano wrote:
Jonathan Tan writes:
Thanks for your comments. If you're r
On Tue, May 2, 2017 at 7:21 PM, Jonathan Tan wrote:
> On Mon, May 1, 2017 at 6:41 PM, Junio C Hamano wrote:
>> Jonathan Tan writes:
>>
>>> On 05/01/2017 04:29 PM, Junio C Hamano wrote:
Jonathan Tan writes:
> Thanks for your comments. If you're referring to the codepath
> invol
On Mon, May 1, 2017 at 6:41 PM, Junio C Hamano wrote:
> Jonathan Tan writes:
>
>> On 05/01/2017 04:29 PM, Junio C Hamano wrote:
>>> Jonathan Tan writes:
>>>
Thanks for your comments. If you're referring to the codepath
involving write_sha1_file() (for example, builtin/hash-object ->
>>
Jonathan Tan writes:
> On 05/01/2017 04:29 PM, Junio C Hamano wrote:
>> Jonathan Tan writes:
>>
>>> Thanks for your comments. If you're referring to the codepath
>>> involving write_sha1_file() (for example, builtin/hash-object ->
>>> index_fd or builtin/unpack-objects), that is fine because
>>>
On 05/01, Jonathan Tan wrote:
> On 05/01/2017 04:29 PM, Junio C Hamano wrote:
> >Jonathan Tan writes:
> >
> >>Thanks for your comments. If you're referring to the codepath
> >>involving write_sha1_file() (for example, builtin/hash-object ->
> >>index_fd or builtin/unpack-objects), that is fine bec
On 05/01/2017 04:29 PM, Junio C Hamano wrote:
Jonathan Tan writes:
Thanks for your comments. If you're referring to the codepath
involving write_sha1_file() (for example, builtin/hash-object ->
index_fd or builtin/unpack-objects), that is fine because
write_sha1_file() invokes freshen_packed_o
Jonathan Tan writes:
> Thanks for your comments. If you're referring to the codepath
> involving write_sha1_file() (for example, builtin/hash-object ->
> index_fd or builtin/unpack-objects), that is fine because
> write_sha1_file() invokes freshen_packed_object() and
> freshen_loose_object() dire
On 04/30/2017 08:57 PM, Junio C Hamano wrote:
One thing I wonder is what the performance impact of a change like
this to the codepath that wants to see if an object does _not_ exist
in the repository. When creating a new object by hashing raw data,
we see if an object with the same name already
Jonathan Tan writes:
> In order to determine the code changes in sha1_file.c necessary, I
> investigated the following:
> (1) functions in sha1_file that take in a hash, without the user
> regarding how the object is stored (loose or packed)
> (2) functions in sha1_file that operate on pac
On 04/21/2017 09:41 AM, Kevin David wrote:
Hi Jonathan,
Sorry for the delayed response - other work got in the way, unfortunately!
No worries!
I am envisioning (1a) as described in Jeff Hostetler's e-mail [1] ("a
pre-command or hook to identify needed blobs and pre-fetch them before
allowing
Hi Jonathan,
Sorry for the delayed response - other work got in the way, unfortunately!
Kevin
-Original Message-
From: Jonathan Tan [mailto:jonathanta...@google.com]
Sent: Thursday, April 13, 2017 4:13 PM
>> I know we're considering server behavior here, but how large do you generally
On 04/12/2017 03:02 PM, Kevin David wrote:
Hi Jonathan,
I work on the network protocols for the GVFS project at Microsoft.
I shared a couple thoughts and questions below.
Thanks for your reply!
I know we're considering server behavior here, but how large do you generally
expect these blob-wa
@vger.kernel.org; Mark Thomas ; Jeff Hostetler
Subject: Re: Proposal for "fetch-any-blob Git protocol" and server design
+cc Ben Peart, who sent
"[RFC] Add support for downloading blobs on demand" to the list recently.
This proposal here seems like it has the same goal, so may
+cc Ben Peart, who sent
"[RFC] Add support for downloading blobs on demand" to the list recently.
This proposal here seems like it has the same goal, so maybe your review
could go a long way here?
Thanks,
Stefan
On Tue, Mar 14, 2017 at 3:57 PM, Jonathan Tan wrote:
> As described in "Background"
On 03/16/2017 02:17 PM, Junio C Hamano wrote:
Yeah, the example was solely to see how the system was to be
extended, as one of the selling point of the proposal was:
> === Endpoint support for forward compatibility
>
> This "server" endpoint requires that the first line be understood
Jonathan Tan writes:
> On 03/15/2017 10:59 AM, Junio C Hamano wrote:
>> ...
>> but I am wondering how you would extend the proposed system to do
>> so. Would you add "fetch-size-limited-blob-in-tree-pack" that runs
>> parallel to "fetch-blob-pack" request? Would you add a new type of
>> request
On 03/15/2017 10:59 AM, Junio C Hamano wrote:
By "SHA-1s for which it wants blobs", you mean that "want" only
allows one exact blob object name? I think it is necessary to
support that mode of operation as a base case, and it is a good
starting point.
When you know
- you have a "partial" clon
Jonathan Tan writes:
> == Design
>
> A new endpoint "server" is created. The client will send a message in
> the following format:
>
>
> fbp-request = PKT-LINE("fetch-blob-pack")
> 1*want
> flush-pkt
> want = PKT-LINE("want" SP obj-id)
>
>
> The client may se
Dearest all,
am sorry my previous message did not enter the list (cross my fingers this
will). I won't be pasting it verbatim because shame on me it leaked zombie
processes (but that part got silently dropped out by kind Paul).
In case anyone could be interested in the topic, and because a thor
Hi Uxio,
On Thu, Sep 08, 2016 at 03:41:29PM +0200, Uxío Prego wrote:
> Hello, please forgive me for not introducing me.
>
> +---+
> |Description|
> +---+
>
> Patch for showing all stashes in `gitk`.
>
> +---+
> |The problem|
> +---+
>
> Being `gitk` one of the b
Jeff King writes:
> You might do better to stick a shim script in your $PATH to just
> intercept the calls to git. Hacky, but it would probably solve your
> problem with a minimal amount of code.
I recently learned about http://repo.or.cz/git.git/bundles which
is a very nicely done set of instru
Ho mappu,
On Sun, 17 Jul 2016, mappu wrote:
> Right now it's possible to git clone a repository over http, and git
> clone a bundle from the local filesystem, but it's not possible to git
> clone a bundle hosted on http.
>
> Would it be possible to allow this in the future? Hopefully it's only a
On Sun, Jul 17, 2016 at 04:41:54PM +1200, mappu wrote:
> Right now it's possible to git clone a repository over http, and git clone a
> bundle from the local filesystem, but it's not possible to git clone a
> bundle hosted on http.
>
> Would it be possible to allow this in the future? Hopefully i
Junio C Hamano wrote:
> > Secondly, and harder to get around, the filename passed to the clean
> > filter is not necessarily a path to the actual existing file that is
> > being cleaned.
>
> Either one of us is confused. I was talking about updating the
> current "clean" implementation without ch
Junio C Hamano wrote:
> The smudge happens to be the last to run, so it is quite true that
> it can say "Hey Git, I've written it out already".
>
> I didn't check all codepaths to ensure that we won't need the
> smudged result in core at all, but I am guessing you did so before
> making this propo
Joey Hess writes:
> Junio C Hamano wrote:
>> This side, I do not think we even need a new variant. We can just
>> update the code to interact with "clean" so that it the writer to
>> the pipe ignores SIGPIPE, detects EPIPE on write(2), says "ah, the
>> other end does not need the full input to p
Junio C Hamano wrote:
> This side, I do not think we even need a new variant. We can just
> update the code to interact with "clean" so that it the writer to
> the pipe ignores SIGPIPE, detects EPIPE on write(2), says "ah, the
> other end does not need the full input to produce its output". The
>
Joey Hess writes:
> The clean filter has to consume the whole file content on stdin;
> not reading it all will make git think the clean filter failed.
> But, git-annex often doesn't need to read the whole content of a
> work-tree file in order to clean it.
This side, I do not think we even need
Joey Hess writes:
> I'm using smudge/clean filters in git-annex now, and it's not been an
> entirely smooth fit between the interface and what git-annex wants
> to do.
>
> The clean filter has to consume the whole file content on stdin;
> not reading it all will make git think the clean filter fa
Hi again,
just wanted to tell that I have created a solution by doing a few lines
of scripting:
git-cstash
```
#/bin/sh
git commit -m 'temporary, will be stashed soon'
git stash --include-untracked
git reset HEAD^1
git stash
git stash pop stash@{1}
```
Le 2015-04-22 11:25, Johannes Schindeli
Hi,
the
```sh
git add config_real.xml
git stash -k
git reset
```
is not very well suited because the -k option to keep the index.
However, the index will still be put inside the stash.
So what you propose is equivalent to:
```sh
git stash
git stash apply stash@\{0\}
git checkout --config
Hi Edgar,
On 2015-04-22 10:30, edgar.h...@netapsys.fr wrote:
> When you have a lot of unstaged files, and would like to test what
> happens if you undo some of the changes that you think are unecessary,
> you would rather keep a copy of those changes somewhere.
>
> For example
>
> Changed but n
On 06/05/2014 04:51 PM, Robert Dailey wrote:
> I've never contributed to the Git project before. I'm a Windows user,
> so I use msysgit, but I'd be happy to install linux just so I can help
> implement this feature if everyone feels it would be useful.
>
> Right now AFAIK, there is no way to prune
Robert Dailey writes:
> ... Having git clean up tags
> automatically would really help with this, even though you may not
> feel it's the responsibility of Git. It's more of a usability issue,
I agree with "Having ... help with this". I did not say at all that
it is not something Git should and
On Thu, Jun 5, 2014 at 3:50 PM, Junio C Hamano wrote:
> I think you need to explain what you mean by "prune" a lot better
> than what you are doing in your message to be understood by others.
>
> After seeing the above two commands, my *guess* of what you want to
> do is to remove any of your loca
Robert Dailey writes:
> I've never contributed to the Git project before. I'm a Windows user,
> so I use msysgit, but I'd be happy to install linux just so I can help
> implement this feature if everyone feels it would be useful.
>
> Right now AFAIK, there is no way to prune tags through Git. The
by "per folder" I meant, "for each subtree"
On Thu, Mar 13, 2014 at 5:43 PM, John Butterfield wrote:
>> A subtree biding can change over time, but .git/config is about
> recording information that do not change depending on what tree you
> are looking at, so there is an impedance mismatch---stori
> A subtree biding can change over time, but .git/config is about
recording information that do not change depending on what tree you
are looking at, so there is an impedance mismatch---storing that
information in .git/config is probably a wrong way to go about it.
I see. How about a .gitsubtrees
John Butterfield writes:
> Has there been any talk about adding a stub for git subtrees in .git/config?
I do not think so, and that is probably for a good reason.
A subtree biding can change over time, but .git/config is about
recording information that do not change depending on what tree you
On Mon, 09 Sep 2013 22:48:42 +, Niels Basjes wrote:
...
> However I can imagine that a malicious opensource coder can create a
> github repo and try to hack the computer of a contributer via those
> scripts. So having such scripts is a 'bad idea'.
Given that half the repos out there are cloned
On 09/10/2013 02:18 AM, Niels Basjes wrote:
> As we all know the hooks ( in .git/hooks ) are not cloned along with
> the code of a project.
> Now this is a correct approach for the scripts that do stuff like
> emailing the people responsible for releases or submitting the commit
> to a CI system.
Hi,
On Tue, Sep 10, 2013 at 12:18 AM, Ramkumar Ramachandra
wrote:
> Niels Basjes wrote:
>> As we all know the hooks ( in .git/hooks ) are not cloned along with
>> the code of a project.
>> Now this is a correct approach for the scripts that do stuff like
>> emailing the people responsible for rel
Niels Basjes wrote:
> As we all know the hooks ( in .git/hooks ) are not cloned along with
> the code of a project.
> Now this is a correct approach for the scripts that do stuff like
> emailing the people responsible for releases or submitting the commit
> to a CI system.
More often than not, mai
On Mon, Sep 9, 2013 at 11:13 PM, Hilco Wijbenga
wrote:
> On 9 September 2013 13:48, Niels Basjes wrote:
>> So I propose the following new feature:
>>
>> 1) A scripting language is put inside git. Perhaps a version of python
>> or ruby or go or ... (no need for a 'new' language)
>
> That sounds ni
On 9 September 2013 13:48, Niels Basjes wrote:
> If those scripts were how ever written in a language that is build
> into the git program and the script are run in such a way that they
> can only interact with the files in the local git (and _nothing_
> outside of that) this would be solved.
Tha
On Mon, Mar 18, 2013 at 02:30:23PM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > I don't think you can avoid the 3-step problem and retain the safety in
> > the general case. Forgetting implementation details for a minute, you
> > have either a 1-step system:
> >
> > 1. Fetch and st
Jeff King wrote:
> I don't think you can avoid the 3-step problem and retain the safety in
> the general case. Forgetting implementation details for a minute, you
> have either a 1-step system:
>
> 1. Fetch and start using config from the remote.
>
> which is subject to fetching and executing ma
On Tue, Mar 12, 2013 at 01:01:08AM +0530, Ramkumar Ramachandra wrote:
> > But it was pointed out that you could also just do:
> >
> > $ git config include.ref upstream-config
> > $ git show origin/config ;# make sure it looks reasonable
> > $ git show origin/config >.git/upstream-config
> >
Jeff King wrote:
> On Tue, Feb 19, 2013 at 05:34:43PM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra
>> wrote:
>> > Hi,
>> >
>> > I have this itch where I want to share my remotes config between
>> > machines. In my fork, I should be able to specify
On Tue, Feb 19, 2013 at 05:34:43PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra
> wrote:
> > Hi,
> >
> > I have this itch where I want to share my remotes config between
> > machines. In my fork, I should be able to specify where my upstream
> > sour
On Tue, Feb 19, 2013 at 9:25 AM, Ramkumar Ramachandra
wrote:
> Hi,
>
> I have this itch where I want to share my remotes config between
> machines. In my fork, I should be able to specify where my upstream
> sources are, so remotes get set up automatically when I clone. There
> are also other th
Ramkumar Ramachandra writes:
> Thomas Rast wrote:
>> Ramkumar Ramachandra writes:
>>> There are also other things in .git/config that would be nice to
>>> share, like whether to do a --word-diff (why isn't it a configuration
>>> variable yet?)
>>
>> Because that would break pretty much every scr
On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra
wrote:
> Hi,
>
> I have this itch where I want to share my remotes config between
> machines. In my fork, I should be able to specify where my upstream
> sources are, so remotes get set up automatically when I clone. There
> are also other th
Thomas Rast wrote:
> Ramkumar Ramachandra writes:
>
>> I have this itch where I want to share my remotes config between
>> machines. In my fork, I should be able to specify where my upstream
>> sources are, so remotes get set up automatically when I clone.
>
> Note that you need to carefully pick
Ramkumar Ramachandra writes:
> I have this itch where I want to share my remotes config between
> machines. In my fork, I should be able to specify where my upstream
> sources are, so remotes get set up automatically when I clone.
Note that you need to carefully pick only certain bits of the co
Ramkumar Ramachandra writes:
> Jonathan Nieder wrote:
>> Ramkumar Ramachandra wrote:
>>
>>> And yes, a regular `git push origin refs/for/master` is just retarded.
>>
>> The usual incantation is "git push gerrit HEAD:refs/for/master". Is
>> the code review creation push that uses a different bran
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> [remote "origin"]
>> url = ... where Ram fetches and pulls from ...
>> pushurl = ... where Ram pushes to ...
>> fetch = refs/heads/*:refs/remotes/*
>> updateTrackOnPush
Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>
>> And yes, a regular `git push origin refs/for/master` is just retarded.
>
> The usual incantation is "git push gerrit HEAD:refs/for/master". Is
> the code review creation push that uses a different branchname from
> the branch the integrator
Michael J Gruber wrote:
> Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
>> Jonathan Nieder writes:
>>> "Wait, why did the remote rewind?"
>>
>> Oh, I am very well aware of that glitch.
>>
>> "git push" has this hack to pretend as if the pusher immediately
>> turned around and fetched from
Junio C Hamano wrote:
> [remote "origin"]
> url = ... where Ram fetches and pulls from ...
> pushurl = ... where Ram pushes to ...
> fetch = refs/heads/*:refs/remotes/*
> updateTrackOnPush = no
>
> Then "git fetch" (or "git pul
Junio C Hamano wrote:
> Jeff King writes:
>
>> We have the problem now that new users do not necessarily understand the
>> matching strategy, or why it is useful, and get confused. When we move
>> to "simple", we may be switching to a world where the early part of the
>> learning curve is more gen
Michael J Gruber writes:
> Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
>> Jonathan Nieder writes:
>>
>>> "Wait, why did the remote rewind?"
>>
>> Oh, I am very well aware of that glitch.
>>
>> "git push" has this hack to pretend as if the pusher immediately
>> turned around and fetch
Michael J Gruber writes:
> As for the triangle remote, I really think we should clean up the
> situation regarding push, pushurlinsteadof and the various different and
> inconclusive output formats of "git remote" (with or without "-v", with
> or without a remote name) first, before introducing y
Jeff King writes:
> We have the problem now that new users do not necessarily understand the
> matching strategy, or why it is useful, and get confused. When we move
> to "simple", we may be switching to a world where the early part of the
> learning curve is more gentle for those users, but they
Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
> Jonathan Nieder writes:
>
>> "Wait, why did the remote rewind?"
>
> Oh, I am very well aware of that glitch.
>
> "git push" has this hack to pretend as if the pusher immediately
> turned around and fetched from the remote.
>
> It shouldn't
On Thu, Feb 07, 2013 at 10:45:07PM -0800, Junio C Hamano wrote:
> To support a triangular arrangement well, there may need some
> thinking on what $branch@{upstream} means. The original intent of
> the upstream mode specified for "push.default" is push the result
> back to what you based your wor
Jonathan Nieder writes:
> "Wait, why did the remote rewind?"
Oh, I am very well aware of that glitch.
"git push" has this hack to pretend as if the pusher immediately
turned around and fetched from the remote.
It shouldn't have been made to do so unconditionally; instead it
should have been de
Junio C Hamano wrote:
> I'd actually see this as Gerrit being weird.
>
> If it wants to quarantine a commit destined to the "master" branch,
> couldn't it just let people push to "master" and then internally
> update "for/master" instead?
It is because pushing doesn't update refs/heads/master. I
Junio C Hamano writes:
> I think the triangle
> arrangement where you want to have "this is where I fetch from and
> integrate with, and that is where I publish" is more common among
> the Git users these days.
Another thing to know about is that the recent move to change the
behaviour of
On Thu, Feb 07, 2013 at 10:08:48PM -0800, Junio C Hamano wrote:
> How best to express the triangle is somewhat tricky, but I think it
> is sensible to say you have "origin" that points to your upstream
> (i.e. me), and "peff" that points to your publishing point, in other
> words, make it explicit
Jeff King writes:
> On Thu, Feb 07, 2013 at 09:44:59PM +0530, Ramkumar Ramachandra wrote:
>
>> This has been annoying me for a really long time, but I never really
>> got around to scratching this particular itch. I have a very common
>> scenario where I fork a project on GitHub. I have two con
On Thu, Feb 07, 2013 at 09:44:59PM +0530, Ramkumar Ramachandra wrote:
> This has been annoying me for a really long time, but I never really
> got around to scratching this particular itch. I have a very common
> scenario where I fork a project on GitHub. I have two configured
> remotes: origin
1 - 100 of 117 matches
Mail list logo
