Hi Dscho,
> On 23 Oct 2016, at 11:54, Johannes Schindelin
> wrote:
>
> Hi Junio,
>
> On Sat, 22 Oct 2016, Junio C Hamano wrote:
>
[...]
>> There isn't enough time to include this topic in the upcoming
>> release within the current https://tinyurl.com/gitCal calendar,
>> however, which places
> On 11 Mar 2016, at 00:04, Junio C Hamano wrote:
>
> A release candidate Git v2.8.0-rc2 is now available for testing
> at the usual places. It is comprised of 459 non-merge commits
> since v2.7.0, contributed by 60 people, 19 of which are new faces.
>
[...]
> Updates since v2.7
> ---
Hi there,
> On 15 Jan 2016, at 10:25, Johannes Schindelin
> wrote:
>
> Hi Mike,
>
> On Fri, 15 Jan 2016, Mike Hommey wrote:
>
>> Git-cinnabar is a git remote helper to interact with mercurial
>> repositories. It allows to clone, pull and push from/to mercurial remote
>> repositories, using gi
Hi Jose,
On 14.04.2015, at 18:44, Jose de Leon wrote:
> Hi All,
>
>
> I've got an interesting problem and the possible solutions I've found from
> searching google don't seem to work for us. In a nutshell, I need to combine
> multiple git repositories into single repository and preserve all
On 11.11.2014, at 23:51, Junio C Hamano wrote:
> Max Horn writes:
>
>> I did this because I was browsing the remote helper docs online quite a bit,
>> and was wishing for some more direct links between the pages. While I can
>> manyally edit the URL, it seems logi
In particular, git-fast-import and -export link to each
other, and gitremote-helpers links to existing remote
helpers, and vice versa. Also link to fast-import from the
remote helper spec, as this is relevant for remote helpers
using the fast-import format.
Signed-off-by: Max Horn
---
I did this
this as me admitting that he is right. I
don't care enough to try to keep up the flames *shrug*. In the end,
everybody here can interpret this in whichever way they like.
Ah well, OK, I can't resist one last retort to one point Felipe wrote:
On 24.04.2014, at 02:23, Felipe
On 23.04.2014, at 22:54, Felipe Contreras wrote:
> Max Horn wrote:
>> On 21.04.2014, at 22:37, Felipe Contreras wrote:
>>
>>> The remote-helpers in contrib/remote-helpers have proved to work, be
>>> reliable, and stable. It's time to move them out of cont
On 21.04.2014, at 22:37, Felipe Contreras wrote:
> The remote-helpers in contrib/remote-helpers have proved to work, be
> reliable, and stable. It's time to move them out of contrib, and be
> distributed by default.
Really? While I agree that git-remote-hg by now works quite well for basic
usa
On 11.04.2014, at 20:56, Felipe Contreras wrote:
> Max Horn wrote:
>> On 11.04.2014, at 17:21, Felipe Contreras wrote:
>>> Max Horn wrote:
>>>> On 11.04.2014, at 15:29, Felipe Contreras
>>>> wrote:
>>>>> Max Horn wrote:
>>>
>
On 11.04.2014, at 17:21, Felipe Contreras wrote:
> Max Horn wrote:
>> On 11.04.2014, at 15:29, Felipe Contreras wrote:
>>> Max Horn wrote:
>>>
>>> You don't think red represent an oldness in Git? Whereas green
>>> represents progress?
&
On 11.04.2014, at 17:39, Philippe Vaucher wrote:
>>> You don't think red represent an oldness in Git? Whereas green
>>> represents progress?
>>
>> No, I don't think that.
>>
>> Perhaps you think that, but if that is the case, it is based on your own
>> sociocultural background. Hey, and let's
On 11.04.2014, at 15:19, Holger Hellmuth wrote:
> Am 11.04.2014 13:08, schrieb Michael Haggerty:
>> On 04/09/2014 10:50 PM, Mahmoud Asshole wrote:
>>> [...]
>>
>> Please conduct your discussions here in a civil tone. It is both more
>> pleasant for all involved and also more likely to elicit a
On 11.04.2014, at 15:29, Felipe Contreras wrote:
> Max Horn wrote:
>> As for the logo, I think it's nice and simple,
>
> You don't think red represent an oldness in Git? Whereas green
> represents progress?
No, I don't think that.
Perhaps you think that, but
My two cents: I like git-scm.com quite a bit. As for the logo, I think it's
nice and simple, and based on experience I think that for every logo you'll
find people who object to it. E.g. the red color of the log on git-scm.com
looks great to me, while I dislike e.g. the color variation Felipe is
On 10.04.2014, at 19:28, Felipe Contreras wrote:
> Diego Lago wrote:
>> Commit attributes are custom commit extra headers the user can
>> add to the commit object.
>>
>> The motivation for this patch is that in my company we have a custom
>> continuous integration software that uses a custom fo
On 01.04.2014, at 15:15, Jeff King wrote:
> On Tue, Apr 01, 2014 at 10:07:03PM +0900, Mike Hommey wrote:
>
>>> For my own curiosity, how does this differ from what is in
>>> contrib/remote-helpers/git-remote-hg?
>>
>> contrib/remote-helpers/git-remote-hg does a local mercurial clone before
>>
On 28.03.2014, at 23:21, Junio C Hamano wrote:
[...]
> * ap/remote-hg-skip-null-bookmarks (2014-03-25) 1 commit
> (merged to 'next' on 2014-03-25 at a8cd922)
> + remote-hg: do not fail on invalid bookmarks
>
> Will merge to 'master'.
Just got back and had a chance to look at the patch you q
Hi Torsten,
On 21.03.2014, at 21:47, Torsten Bögershausen wrote:
> On 2014-03-21 12.36, Max Horn wrote:
> All tests passed :-),
Excellent.
> thanks from my side.
> comments inline, some are debatable
Thanks for having a close look and for the constructive feedback!
Unfortunat
some test cases for this issue.
Reported-by: Antoine Pelisse
Signed-off-by: Max Horn
---
This is a different fix than in my previous attempts. I thought
a bit more about the issue, and determined that the previous fix,
while working, was not really correct: It is wrong to
treat nullid bookmarks
reference.
Warn the user about the invalid reference, and continue the import,
instead of stopping right away.
Also add some test cases for this issue.
Reported-by: Antoine Pelisse
Signed-off-by: Max Horn
---
contrib/remote-helpers/git-remote-hg | 6 +
contrib/remote-helpers/test-hg.
> Am 19.03.2014 um 18:04 schrieb Junio C Hamano :
>
> Max Horn writes:
>
>>> On 17.03.2014, at 18:01, Junio C Hamano wrote:
>>>
>>> Torsten Bögershausen writes:
>>>
>>>>> On 2014-03-14 23.09, Junio C Hamano wrote:
all
three even?), and edit the message. But I'd like to properly attribute that you
discovered the issue, so perhaps I can add something like "Reported-by: Antoine
Pelisse" or so?
Max
>
> Thanks,
> Antoine
>
> On Wed, Mar 19, 2014 at 1:33 PM, Max Horn w
create the corresponding reference.
Warn the user about the invalid reference, and continue the import,
instead of stopping right away.
Signed-off-by: Antoine Pelisse
Signed-off-by: Max Horn
---
contrib/remote-helpers/git-remote-hg | 3 +++
1 file changed, 3 insertions(+)
diff --git a/contrib/remo
the preceding fix ignores it. This
would leave us in an inconsistent state. Avoid this by NOT ignoring
null bookmarks named 'master' or 'default' under suitable circumstances.
Signed-off-by: Max Horn
---
contrib/remote-helpers/git-remote-hg | 7 +--
1 file changed, 5 insert
Signed-off-by: Max Horn
---
contrib/remote-helpers/test-hg.sh | 48 +++
1 file changed, 48 insertions(+)
diff --git a/contrib/remote-helpers/test-hg.sh
b/contrib/remote-helpers/test-hg.sh
index a933b1e..8d01b32 100755
--- a/contrib/remote-helpers/test-hg.sh
On 19.03.2014, at 11:53, Max Horn wrote:
>
> On 17.03.2014, at 18:01, Junio C Hamano wrote:
>
>> Torsten Bögershausen writes:
>>
>>> On 2014-03-14 23.09, Junio C Hamano wrote:
>>>> * ap/remote-hg-skip-null-bookmarks (2014-01-02) 1 commit
>>
On 17.03.2014, at 18:01, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> On 2014-03-14 23.09, Junio C Hamano wrote:
>>> * ap/remote-hg-skip-null-bookmarks (2014-01-02) 1 commit
>>> - remote-hg: do not fail on invalid bookmarks
>>>
>>> Reported to break tests ($gmane/240005)
>>> Expe
On 10.03.2014, at 15:30, Shawn Pearce wrote:
> On Mon, Mar 10, 2014 at 4:00 AM, Michael Haggerty
> wrote:
>> I have started working on pluggable ref backends. In this email I
>> would like to share my plans and solicit feedback.
>
> Yay!
Yay, too!
> JGit already has pluggable ref backends,
On 04.03.2014, at 09:42, Tanay Abhra wrote:
[...]
> commit.c | 17 +
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/commit.c b/commit.c
> index 6bf4fe0..6c92acb 100644
> --- a/commit.c
> +++ b/commit.c
[...]
> @@ -566,14 +566,16 @@ static void record_author
On 03.03.2014, at 20:43, Junio C Hamano wrote:
> Tanay Abhra writes:
>
>> @@ -1193,9 +1194,9 @@ static void parse_gpg_output(struct signature_check
>> *sigc)
>> for (i = 0; i < ARRAY_SIZE(sigcheck_gpg_status); i++) {
>> const char *found, *next;
>>
>> -if (start
On 01.03.2014, at 00:26, Conley Owens wrote:
> $ git --version # This is just the git from MacPorts
> git version 1.8.5.5
> $ sw_vers
> ProductName:Mac OS X
> ProductVersion: 10.8.5
> BuildVersion: 12F45
I cannot reproduce this, neither with 1.8.5.5 nor with 1.9.0. I am also running
Mac
rite with zero" is necessary but is
>> probably not sufficient---it also may need to be able to tell us
>> what the final resulting commit of the push is, for example.
>
> So, here is what I'll queue (with forged s-o-b).
Thank you, I hereby declare the forged s-o-b as legit ;-
quot;
>
>It does not necessarily mean the update was *not* forced, when the
>helper did not say "forced update". When the helper does say so, we
>know the update is forced.
>
>A workaround to fix breakage introduced by the previous step,
>propose
On 20.02.2014, at 20:22, Junio C Hamano wrote:
> Max Horn writes:
>
>> On 19.02.2014, at 22:41, Junio C Hamano wrote:
>>
>>> * fc/transport-helper-fixes (2013-12-09) 6 commits
>>> - remote-bzr: support the new 'force' option
>>> - tes
On 19.02.2014, at 22:41, Junio C Hamano wrote:
> * fc/transport-helper-fixes (2013-12-09) 6 commits
> - remote-bzr: support the new 'force' option
> - test-hg.sh: tests are now expected to pass
> - transport-helper: check for 'forced update' message
> - transport-helper: add 'force' to 'export'
> Am 07.11.2013 um 00:28 schrieb Jonathan Nieder :
>
> Max Horn wrote:
>
>> Well, unlike suffixcmp, it is transitive, so it could be used for sorting.
>
> It is not antisymmetric.
>
>prefixcmp("foo", "foobar") < 0
>prefixcmp(&q
On 06.11.2013, at 23:17, Jonathan Nieder wrote:
> Hi,
>
> Christian Couder wrote:
>
>> Now has_suffix() returns 1 when the suffix is present and 0 otherwise.
>
> Ok. My only worry is that the function is less discoverable since
> its name is so different from prefixcmp(), which might cause s
+1 for the change. I find the resulting code easier to understand, too.
On 05.11.2013, at 05:57, Christian Couder wrote:
> As suffixcmp() should not be used as an ordering comparison function,
> and anything-cmp() ought to be usable as an ordering comparison function,
> suffixcmp() should be re
On 31.10.2013, at 20:53, Felipe Contreras wrote:
> On Thu, Oct 31, 2013 at 1:47 PM, Max Horn wrote:
>>
>> On 31.10.2013, at 20:41, Felipe Contreras wrote:
>>
>>> On Thu, Oct 31, 2013 at 1:29 PM, Max Horn wrote:
[...]
>>>
>>> That's
On 31.10.2013, at 20:41, Felipe Contreras wrote:
> On Thu, Oct 31, 2013 at 1:29 PM, Max Horn wrote:
>> Actually, I just noticed one thing that I *do* have a question about:
>>
>> On 31.10.2013, at 10:36, Felipe Contreras wrote:
>>
>>> Signed-off-by: F
Actually, I just noticed one thing that I *do* have a question about:
On 31.10.2013, at 10:36, Felipe Contreras wrote:
> Signed-off-by: Felipe Contreras
> ---
> builtin/fast-export.c | 14 ++
> t/t9350-fast-export.sh | 11 +++
> 2 files changed, 25 insertions(+)
>
> diff --g
On 31.10.2013, at 20:00, Junio C Hamano wrote:
> Felipe Contreras writes:
[...]
>
>>
>> If you want to be pedantic, this is the "reality":
>>
>>
>> D---E---F---G master
>>
>
> You are wrong again. The "reality" is more like this:
>
> origin/master i
On 31.10.2013, at 19:10, Junio C Hamano wrote:
> Max Horn writes:
>
>> On 31.10.2013, at 10:36, Felipe Contreras
>> wrote:
>>
>>> Hi,
>>>
>>> Here are the patches that allow transport helpers to be completely
>> transparent;
>&
On 31.10.2013, at 10:36, Felipe Contreras wrote:
> Signed-off-by: Felipe Contreras
> ---
> Documentation/git-fast-import.txt | 3 +++
> fast-import.c | 13 ++---
> t/t9300-fast-import.sh| 18 ++
> 3 files changed, 31 insertions(+), 3 deletio
On 31.10.2013, at 10:25, Felipe Contreras wrote:
> Most of these have been sent before, but were not applied for one reason or
> another.
All of these look fine and sensible to me. Some of the latter patches in the
series might be a bit subjective (e.g. I personally don't mind "yoda"
conditio
On 31.10.2013, at 10:36, Felipe Contreras wrote:
> Hi,
>
> Here are the patches that allow transport helpers to be completely
> transparent;
> renaming branches, deleting them, custom refspecs, --force, --dry-run,
> reporting forced update, everything works.
I looked through this patch series
I guess most other people keep out of this because they are sensible enough to
not feed the troll, and instead focus on useful things. But I can't help it, I
have to say this.
On 17.10.2013, at 23:44, Felipe Contreras wrote:
> Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> Junio C
On 17.10.2013, at 21:50, Junio C Hamano wrote:
> Felipe Contreras writes:
[...]
>
> However, since you asked, I would share a couple of comments
> regarding the index, cache and staging area.
>
> (1) "Staging area".
>
> The phrase "staging area" is not an everyday phrase or common CS
> lin
On 27.06.2013, at 12:17, John Szakmeister wrote:
> I wanted to look at some OpenWRT bits this morning and ran into an
> issue cloning the packages repository when setting up the package
> feed. The feeds script executes this under the hood:
>
> git clone --depth 1 git://nbd.name/packages.git
While I am not really interested in exchanging any further emails or any other
form of communication with Felipe, as I find his vitriolic style of
communication unbearable, I feel compelled to reply to a few points. I'll
probably regret this... anyway, I promise this will be my last mail in thi
On 04.04.2013, at 08:46, Felipe Contreras wrote:
> On Thu, Apr 4, 2013 at 12:42 AM, Felipe Contreras
> wrote:
>> On Wed, Apr 3, 2013 at 6:25 PM, Max Horn wrote:
>>> On 03.04.2013, at 03:31, Felipe Contreras wrote:
>>
>>>> I only learned about it recentl
On 03.04.2013, at 03:31, Felipe Contreras wrote:
> On Tue, Apr 2, 2013 at 4:23 PM, Max Horn wrote:
>>
>> On 02.04.2013, at 22:09, John Keeping wrote:
>>
>>> On Tue, Apr 02, 2013 at 01:02:49PM -0600, Felipe Contreras wrote:
>>>> Here is the next round
On 02.04.2013, at 22:09, John Keeping wrote:
> On Tue, Apr 02, 2013 at 01:02:49PM -0600, Felipe Contreras wrote:
>> Here is the next round of patches for remote-hg, some which have been
>> contributed through github.
>>
>> Fortunately it seems to be working for the most part, but there are some
On 11.03.2013, at 23:54, Andrew Wong wrote:
> On 3/11/13, Max Horn wrote:
>> Looking at the git config man page to check what each of my config settings
>> does, I discovered "trustctime". And adding
>> trustctime = false
>> to .git/config made th
On 11.03.2013, at 23:54, Andrew Wong wrote:
> On 3/11/13, Max Horn wrote:
>> Looking at the git config man page to check what each of my config settings
>> does, I discovered "trustctime". And adding
>> trustctime = false
>> to .git/config made th
On 11.03.2013, at 23:10, Andrew Wong wrote:
> On 3/11/13, Max Horn wrote:
>> PS: Just as a side note, I should mention that I have done tons of rebases
>> on various repositories on this very machine: same hard drive, same file
>> system; the git version of course has chan
On 11.03.2013, at 22:34, Andrew Wong wrote:
> On 3/11/13, Max Horn wrote:
>> So I tried this:
>>
>> git rebase branches/stable-4.6 # ... which leads to the error
>> git ls-files -m
>>
>> but got nothing. Perhaps you had something else in mind,
PS: Just as a side note, I should mention that I have done tons of rebases on
various repositories on this very machine: same hard drive, same file system;
the git version of course has changed over time, but as I already described, I
can reproduce the same issue with older git versions.
All I
On 11.03.2013, at 20:15, Andrew Wong wrote:
> On 3/10/13, Max Horn wrote:
>> I did run
>>
>> touch lib/*.* src/*.* && git update-index --refresh && git diff-files
>>
>> a couple dozen times (the "problematic" files where in src/ an
Sorry for taking so long to reply... :-/
On 09.03.2013, at 19:32, Andrew Wong wrote:
> On 03/09/13 06:26, Max Horn wrote:
>> It tends to fail in separate places, but eventually "stabilizes". E.g. I
>> just did a couple test rebases, and it failed twice in commit 14, t
On 08.03.2013, at 20:20, Andrew Wong wrote:
> On 3/8/13, Max Horn wrote:
>> Same result, it works fine.
>
> Just shooting in the dark here... I wonder if there's some background
> process running in OS X that's messing with the files/directories
> while rebase i
Am 08.03.2013 um 19:02 schrieb Andrew Wong :
> On 3/8/13, Max Horn wrote:
>> I tried this a dozen times, but 'git apply' failed to fail even once. No
>> surprise there, given that the patch that throws off rebase every time is
>> clean and simple. I am flabber
Am 08.03.2013 um 16:32 schrieb Andrew Wong :
> On 3/8/13, Max Horn wrote:
>> All in all, I suspect that Mac OS X and/or the filesystem (HFS+ with
>> journaling, not case sensitive (the default)) might be at fault. Still, this
>> is quite puzzling and annoying, and so I st
journaling, not case sensitive (the default)) might be at fault. Still, this is
quite puzzling and annoying, and so I still wonder if anybody has any insights
on this.
And: is this a known issue, I wonder?
Cheers,
Max
On 07.03.2013, at 11:16, Max Horn wrote:
> Recently I have observed v
Recently I have observed very strange failures in "git rebase" that cause it to
fail to work automatically in situations where it should trivially be able to
do so.
In case it matter, here's my setup: git 1.8.2.rc2.4.g7799588 (i.e. git.git
master branch) on Mac OS X. The repos clone is on a HFS
Hi there,
while trying to understand which parts of the author & committer identity are
mandatory (name, email, or both), I ended up in ident.c, looking at
ident_is_sufficient(), and to my surprise discovered that this seems to differ
between Windows (were both are mandatory) and everyone else:
On 30.01.2013, at 16:59, Sitaram Chamarty wrote:
> I'm curious... what's wrong with 'git checkout html' from the git repo
> and just browsing them using a web browser?
Hm, do you mean "make html", perhaps? At least I couldn't figure out what "git
checkout html" should do, but out of curiosity g
On 30.01.2013, at 12:54, John Keeping wrote:
> On Wed, Jan 30, 2013 at 12:46:47PM +0100, Max Horn wrote:
>> does anybody know a website where one can view that latest git
>> documentation? Here, "latest" means "latest release" (though being
>> also able t
Hi Sebastian,
On 30.01.2013, at 12:56, Sebastian Staudt wrote:
> Hello Max,
>
> git-scm.com is the best source and it's not outdated.
Then it seems you are using the word "outdated" in a different way than me
which I don't understand :-). Sure, it strives to be up-to-date, but fact is
that it
Hi,
does anybody know a website where one can view that latest git documentation?
Here, "latest" means "latest release" (though being also able to access it for
"next" would of course be a nice bonus, likewise for older versions). While I
do have those docs on my local machine, I would like to
Hi Jed, all,
On 28.01.2013, at 06:19, Jed Brown wrote:
> I'm working on an hg remote helper that uses git notes for the sha1
> revision, so that git users can more easily refer to specific commits
> when communicating with hg users.
For the record, I am also working on that very same thing; it
On 17.01.2013, at 20:29, Jay Vee wrote:
> When I do a git pull, I am getting a messages that changes to local
> files would be overwritten by a merge, but I have not changed these
> files locally at all, I have not opened them in my IDE.
> This happens every now and then.
>
> 1) Why does this h
On 16.01.2013, at 18:18, John Keeping wrote:
> On Wed, Jan 16, 2013 at 06:12:57PM +0100, Antoine Pelisse wrote:
>> FWIW, I also happen to have the warning:
>>
>> advice.c:69:2: warning: expression result unused [-Wunused-value]
>>error("'%s' is not possible because you have unmerged file
Signed-off-by: Max Horn
---
cache.h | 2 +-
git-compat-util.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index c257953..5c8440b 100644
--- a/cache.h
+++ b/cache.h
@@ -1148,7 +1148,7 @@ extern int check_repository_format_version(const char
Hi there,
I was just working on improving git-remote-helper.txt by documenting how remote
helper can signal error conditions to git. This lead me to notice a (to me)
surprising change in behavior between master and next that I traced back to
this patch series.
Specifically:
On 30.11.2012, at
On 15.01.2013, at 17:51, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Max Horn writes:
>> ...
>>> See also the discussion (yeah, this time a real one ;-) leading to this:
>>> https://github.com/felipec/git/issues/2
>>> ...
>
> If I
On 15.01.2013, at 17:05, Junio C Hamano wrote:
> Max Horn writes:
>
>> On 14.01.2013, at 19:14, Junio C Hamano wrote:
>>
>>> What is lacking from this description is why it even needs to work
>>> from a different working directory
>
> In your rew
On 15.01.2013, at 14:02, Max Horn wrote:
> Previously, when changing and committing an executable file, the file
> would loose its executable bit on the hg side. Likewise, symlinks ended
> up as "normal" files". This was not immediately apparent on the git side
> u
Previously, when changing and committing an executable file, the file
would loose its executable bit on the hg side. Likewise, symlinks ended
up as "normal" files". This was not immediately apparent on the git side
unless one did a fresh clone.
---
contrib/remote-helpers/git-remote-hg | 2 +-
On 14.01.2013, at 19:14, Junio C Hamano wrote:
> Max Horn writes:
>
>> From: Felipe Contreras
>>
>> Mercurial might convert the URL to something more appropriate, like an
>> absolute path.
>
> "What it is converted *TO*" is fairly clear with &q
From: Felipe Contreras
Mercurial might convert the URL to something more appropriate, like an
absolute path. Lets store that instead of the original URL, which won't
work from a different working directory if it's relative.
Suggested-by: Max Horn
Signed-off-by: Felipe Contreras
Sig
On 03.01.2013, at 21:53, Eric S. Raymond wrote:
> Michael Haggerty :
>> There are two good reasons that the output is written to two separate files:
>
> Those are good reasons to write to a pair of tempfiles, and I was able
> to deduce in advance most of what your explanation would be from the
>
hat nobody ever really can point to anything wrong
your said, I'll do you the favor by deconstructing one of the claims you made:
On 13.12.2012, at 20:06, Felipe Contreras wrote:
> On Thu, Dec 13, 2012 at 6:04 AM, Max Horn wrote:
>>
>> On 13.12.2012, at 11:08, Felipe Contreras
On 13.12.2012, at 11:08, Felipe Contreras wrote:
> On Thu, Dec 13, 2012 at 2:11 AM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>
New remote helper for bzr (v3). With minor fixes, this may be ready
for 'next'.
>>>
>>> What minor fixes?
>>
>> Lookng at the above (fixup), $gma
On 13.12.2012, at 00:13, Junio C Hamano wrote:
> Max Horn writes:
>
>> Of course I can also re-roll, if that is necessary/preferred.
>
> No, you can't. The topic has been cooking in 'next' for some days
> now already.
Ah, right, I somehow missed that :-
On 13.12.2012, at 00:00, Felipe Contreras wrote:
[...]
>>>
>>> I find all this text a bit confusing. First argument, second argument,
>>> etc. Personally, I would describe everything in the terms of alias
>>> (1st arg), and URL (2nd arg).
>>
>> Yeah, I also thought about that, but as above, del
On 12.12.2012, at 23:14, Felipe Contreras wrote:
> On Tue, Nov 27, 2012 at 5:03 PM, Max Horn wrote:
>
>> index 5ce4cda..9a7e583 100644
>> --- a/Documentation/git-remote-helpers.txt
>> +++ b/Documentation/git-remote-helpers.txt
>> @@ -35,6 +35,37 @@ transport proto
On 07.12.2012, at 22:52, Junio C Hamano wrote:
> Max Horn writes:
>
>> On 07.12.2012, at 20:09, Junio C Hamano wrote:
>>
>>> Except for a minor nit in 6/6; I think "defined options" should be
>>> "defined attributes".
>>&
On 07.12.2012, at 20:09, Junio C Hamano wrote:
> Max Horn writes:
>
>> Various remote helper capabilities and commands were not
>> documented, in particular 'export', or documented in a misleading
>> way (e.g. 'for-push' was listed as a ref attribute
On 30.11.2012, at 04:35, viresh kumar wrote:
> On 30 November 2012 09:03, Nicolas Pitre wrote:
>
>> Have a look at the .mailmap file in the top directory of your repo.
>
> Repeating what i said to David in other mail:
>
> I have my name there :)
>
> I thought using names with different case
On 28.11.2012, at 23:23, Felipe Contreras wrote:
> They have been marked as UNINTERESTING for a reason, lets respect that.
>
> Currently the first ref is handled properly, but not the rest:
>
> % git fast-export master ^uninteresting ^foo ^bar
All these refs are assumed to point to the same o
On 28.11.2012, at 07:38, Junio C Hamano wrote:
> Max Horn writes:
>
>> The configure script checks whether certain flags are required to use
>> pthreads. But it did not consider that *none* might be needed (as is the
>> case on Mac OS X). This lead to configure add
st, but
it does not seem worth the extra effort required for implementing and
testing such a solution, when this simple solution exists and works.
Signed-off-by: Max Horn
---
This is actually a revised version from my patch
"Change configure to check if pthreads are usable without any ex
Ouch. This one should *not* have been sent (the "[PATCH v2 6/6]" one is the
correct one). Very sorry :(. I'll triple check next time.
Max
On 28.11.2012, at 00:03, Max Horn wrote:
> The documentation was misleading in that it gave the impression that
> 'for-push' c
elt it was better to provide something than to do nothing
and only complain, as I did previously on this subject ;-).
Max Horn (6):
git-remote-helpers.txt: document invocation before input format
git-remote-helpers.txt: document missing capabilities
git-remote-helpers.txt: minor gram
In particular, document 'list for-push' separately from 'list', as
the former needs only be supported for the push/export
capabilities, and the latter only for fetch/import. Indeed, a
hypothetically 'push-only' helper would only need to support the
former, not the la
Signed-off-by: Max Horn
---
Documentation/git-remote-helpers.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt
b/Documentation/git-remote-helpers.txt
index db63541..7eb43d7 100644
--- a/Documentation/git-remote-helpers.txt
+++ b
the one hand, and the sections
'REF LIST ATTRIBUTES' and 'OPTIONS' on the other hand.
Signed-off-by: Max Horn
---
Documentation/git-remote-helpers.txt | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt
b
the one hand, and the sections
'REF LIST ATTRIBUTES' and 'OPTIONS' on the other hand.
Signed-off-by: Max Horn
---
Documentation/git-remote-helpers.txt | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt
b
1 - 100 of 126 matches
Mail list logo
