On 19.02.2014, at 22:41, Junio C Hamano gits...@pobox.com 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'
On 20.02.2014, at 20:22, Junio C Hamano gits...@pobox.com wrote:
Max Horn m...@quendi.de writes:
On 19.02.2014, at 22:41, Junio C Hamano gits...@pobox.com wrote:
* fc/transport-helper-fixes (2013-12-09) 6 commits
- remote-bzr: support the new 'force' option
- test-hg.sh: tests are now
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,
proposed by Max Horn.
It troubled me that it does not necessarily mean sounded
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 ;-)
Thanks.
-- 8 --
From: Max Horn m
On 01.03.2014, at 00:26, Conley Owens c...@android.com 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
On 03.03.2014, at 20:43, Junio C Hamano gits...@pobox.com wrote:
Tanay Abhra tanay...@gmail.com 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;
-
On 04.03.2014, at 09:42, Tanay Abhra tanay...@gmail.com 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
On 10.03.2014, at 15:30, Shawn Pearce spea...@spearce.org wrote:
On Mon, Mar 10, 2014 at 4:00 AM, Michael Haggerty mhag...@alum.mit.edu
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
On 17.03.2014, at 18:01, Junio C Hamano gits...@pobox.com wrote:
Torsten Bögershausen tbo...@web.de 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
On 19.03.2014, at 11:53, Max Horn m...@quendi.de wrote:
On 17.03.2014, at 18:01, Junio C Hamano gits...@pobox.com wrote:
Torsten Bögershausen tbo...@web.de 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
to
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 apeli...@gmail.com
Signed-off-by: Max Horn m...@quendi.de
---
contrib/remote-helpers/git-remote-hg | 3 +++
1 file changed, 3
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 m...@quendi.de
---
contrib/remote-helpers/git-remote-hg | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/contrib
Signed-off-by: Max Horn m...@quendi.de
---
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
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 m...@quendi.de wrote:
Fix the previous commit to workaround issues with edge
Am 19.03.2014 um 18:04 schrieb Junio C Hamano gits...@pobox.com:
Max Horn m...@quendi.de writes:
On 17.03.2014, at 18:01, Junio C Hamano gits...@pobox.com wrote:
Torsten Bögershausen tbo...@web.de writes:
On 2014-03-14 23.09, Junio C Hamano wrote:
* ap/remote-hg-skip-null-bookmarks
.
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 apeli...@gmail.com
Signed-off-by: Max Horn m...@quendi.de
---
contrib/remote-helpers/git-remote-hg | 6 +
contrib/remote
cases for this issue.
Reported-by: Antoine Pelisse apeli...@gmail.com
Signed-off-by: Max Horn m...@quendi.de
---
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
Hi Torsten,
On 21.03.2014, at 21:47, Torsten Bögershausen tbo...@web.de 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!
Unfortunately, I
On 01.04.2014, at 15:15, Jeff King p...@peff.net 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 10.04.2014, at 19:28, Felipe Contreras felipe.contre...@gmail.com 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
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
On 11.04.2014, at 15:29, Felipe Contreras felipe.contre...@gmail.com 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
On 11.04.2014, at 15:19, Holger Hellmuth hellm...@ira.uka.de 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
On 11.04.2014, at 17:39, Philippe Vaucher philippe.vauc...@gmail.com 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.
On 11.04.2014, at 17:21, Felipe Contreras felipe.contre...@gmail.com wrote:
Max Horn wrote:
On 11.04.2014, at 15:29, Felipe Contreras felipe.contre...@gmail.com wrote:
Max Horn wrote:
You don't think red represent an oldness in Git? Whereas green
represents progress?
No, I don't
On 11.04.2014, at 20:56, Felipe Contreras felipe.contre...@gmail.com wrote:
Max Horn wrote:
On 11.04.2014, at 17:21, Felipe Contreras felipe.contre...@gmail.com wrote:
Max Horn wrote:
On 11.04.2014, at 15:29, Felipe Contreras felipe.contre...@gmail.com
wrote:
Max Horn wrote:
You don't
On 21.04.2014, at 22:37, Felipe Contreras felipe.contre...@gmail.com 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
On 23.04.2014, at 22:54, Felipe Contreras felipe.contre...@gmail.com wrote:
Max Horn wrote:
On 21.04.2014, at 22:37, Felipe Contreras felipe.contre...@gmail.com wrote:
The remote-helpers in contrib/remote-helpers have proved to work, be
reliable, and stable. It's time to move them out
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 Contreras felipe.contre...@gmail.com wrote:
Max
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 m...@quendi.de
On 11.11.2014, at 23:51, Junio C Hamano gits...@pobox.com wrote:
Max Horn m...@quendi.de 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 logical
Hi there,
On 18.09.2012, at 14:40, Joachim Schmitz wrote:
From: Andreas Ericsson [mailto:a...@op5.se]
Sent: Tuesday, September 18, 2012 1:46 PM
To: Joachim Schmitz
Cc: git@vger.kernel.org
Subject: Re: Can git pull from a mercurial repository?
On 09/18/2012 01:22 PM, Joachim Schmitz
On 26.09.2012, at 09:38, Georgi Chorbadzhiyski wrote:
Around 09/25/2012 05:15 PM, Max Horn scribbled:
I think there is a lot of demand for a git-hg bridge, a way to seemlessly
access a Mercurial repository as if it was a git repository. A converse to
hg-git http://hg-git.github.com
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
On 11.11.2012, at 14:59, Felipe Contreras wrote:
People seeking for reference would find it useful.
Hm, I don't understand this commit message. Probably means I am just too dumb,
but since I am one of those people who would likely be seeking for reference, I
would really appreciate if it
On 11.11.2012, at 14:59, Felipe Contreras wrote:
Basically this is what we want:
== pull ==
testgit transport-helper
* export - import
# testgit.marks git.marks
== push ==
testgit transport-helper
On 11.11.2012, at 14:59, Felipe Contreras wrote:
It's way simpler. It exerceises the same features of remote helpers.
Typo: exerceises = exercises
Cheers,
Max
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo
On 11.11.2012, at 14:59, Felipe Contreras wrote:
When an object has already been exported (and thus is in the marks) it's
flagged as SHOWN, so it will not be exported again, even if in a later
time it's exported through a different ref.
We don't need the object to be exported again, but we
On 11.11.2012, at 22:22, Felipe Contreras wrote:
On Sun, Nov 11, 2012 at 9:49 PM, Max Horn m...@quendi.de wrote:
On 11.11.2012, at 14:59, Felipe Contreras wrote:
People seeking for reference would find it useful.
Hm, I don't understand this commit message. Probably means I am j git
On 15.11.2012, at 22:28, Eric S. Raymond wrote:
Some days ago I reported that I was attempting to write a tool that could
(a) take a git repo and unpack it into a tarball sequence plus a metadata log,
(b) reverse that operation, packing a tarball and log sequence into a repo.
Ah, I could
On 21.11.2012, at 06:08, Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Never mind that others have said that that's not the current interface
(I don't yet see why it would be a good interface after a transition,
but maybe it would be). Still, hopefully that clarifies the
I noticed a problem with remote helpers which is mainly about convenience, but
still annoying enough that I wish it could be resolved; but I'd like some input
on what the proper way would be...
Here is the issue: cloning with relative paths is problematic (if not broken)
when using
to provide something than to do nothing
and only complain, as I did previously on this subject ;-).
Max Horn (6):
Document invocation first, then input format
Document missing remote helper capabilities
Fix grammar
Rearrange the description of remote helper capabilities
Make clearer which
The documentation was misleading in that it gave the impression that
'for-push' could be used as a ref attribute in the output of the
'list' command. That is wrong.
Signed-off-by: Max Horn m...@quendi.de
---
Documentation/git-remote-helpers.txt | 13 -
1 file changed, 8 insertions
This also remove some duplication in the descriptions
(e.g. refspec was explained twice with similar level of detail)
Signed-off-by: Max Horn m...@quendi.de
---
Documentation/git-remote-helpers.txt | 134 +++
1 file changed, 56 insertions(+), 78 deletions(-)
diff
The 'export' and '(im|ex)port-marks' capabilities were not
documented at all
Signed-off-by: Max Horn m...@quendi.de
---
Documentation/git-remote-helpers.txt | 45 +---
1 file changed, 42 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-remote
Signed-off-by: Max Horn m...@quendi.de
---
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
to the invocation
style and then back to input related stuff.
Signed-off-by: Max Horn m...@quendi.de
---
Documentation/git-remote-helpers.txt | 62 ++--
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt
b/Documentation/git
In particular, document 'list for-push' separately from 'list',
as the former needs only be supported for the 'push' capability,
and the latter only for fetch/import/export. In particular,
a hypothetically 'push-only' helper only needs to support the
former, not the latter.
Signed-off-by: Max
On 27.11.2012, at 21:39, Junio C Hamano wrote:
Max Horn m...@quendi.de writes:
Subject: Re: [PATCH 3/6] Fix grammar
Please run git shortlog -200 --no-merges from the tip of your
topic branch before sending a series out, and see if you can
immediately identify what area each of your
Specifically, document the 'export' and '(im|ex)port-marks'
capabilities as well as the export command, which were
undocumented (but in active use).
Signed-off-by: Max Horn m...@quendi.de
---
Documentation/git-remote-helpers.txt | 45 +---
1 file changed, 42
the input format to the invocation
style and then back to input related stuff.
Signed-off-by: Max Horn m...@quendi.de
---
Documentation/git-remote-helpers.txt | 62 ++--
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt
ATTRIBUTES' and 'OPTIONS' on the other hand.
Signed-off-by: Max Horn m...@quendi.de
---
Documentation/git-remote-helpers.txt | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt
b/Documentation/git-remote-helpers.txt
index 023dcca
ATTRIBUTES' and 'OPTIONS' on the other hand.
Signed-off-by: Max Horn m...@quendi.de
---
Documentation/git-remote-helpers.txt | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt
b/Documentation/git-remote-helpers.txt
index 023dcca
This also remove some duplication in the descriptions
(e.g. refspec was explained twice with similar level of detail).
Signed-off-by: Max Horn m...@quendi.de
---
Documentation/git-remote-helpers.txt | 134 +++
1 file changed, 56 insertions(+), 78 deletions
Signed-off-by: Max Horn m...@quendi.de
---
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
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 latter.
Signed-off-by: Max Horn
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 grammar fix
git-remote
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' could be used as a ref attribute
On 28.11.2012, at 07:38, Junio C Hamano wrote:
Max Horn m...@quendi.de 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 adding -mt to the list
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
On 30.11.2012, at 04:35, viresh kumar wrote:
On 30 November 2012 09:03, Nicolas Pitre nicolas.pi...@linaro.org 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
On 07.12.2012, at 20:09, Junio C Hamano wrote:
Max Horn m...@quendi.de 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 understood by
git, which
On 07.12.2012, at 22:52, Junio C Hamano wrote:
Max Horn m...@quendi.de 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.
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git
On 12.12.2012, at 23:14, Felipe Contreras wrote:
On Tue, Nov 27, 2012 at 5:03 PM, Max Horn m...@quendi.de wrote:
index 5ce4cda..9a7e583 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -35,6 +35,37 @@ transport protocols, such as 'git-remote
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, deliberately did
On 13.12.2012, at 00:13, Junio C Hamano wrote:
Max Horn m...@quendi.de 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 :-/. Well, I guess it's at most
On 13.12.2012, at 11:08, Felipe Contreras wrote:
On Thu, Dec 13, 2012 at 2:11 AM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
New remote helper for bzr (v3). With minor fixes, this may be ready
for 'next'.
What minor fixes?
Lookng at
, 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 post...@quendi.de wrote:
On 13.12.2012, at 11:08, Felipe Contreras wrote:
On Thu, Dec 13, 2012 at 2:11 AM, Junio C Hamano gits
On 03.01.2013, at 21:53, Eric S. Raymond wrote:
Michael Haggerty mhag...@alum.mit.edu:
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
From: Felipe Contreras felipe.contre...@gmail.com
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 m...@quendi.de
Signed
On 14.01.2013, at 19:14, Junio C Hamano wrote:
Max Horn m...@quendi.de writes:
From: Felipe Contreras felipe.contre...@gmail.com
Mercurial might convert the URL to something more appropriate, like an
absolute path.
What it is converted *TO* is fairly clear with , like
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 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
unless one did a fresh clone.
Sorry
On 15.01.2013, at 17:05, Junio C Hamano wrote:
Max Horn m...@quendi.de 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 rewrite below, this is still lacking, I think
On 15.01.2013, at 17:51, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Max Horn m...@quendi.de writes:
...
See also the discussion (yeah, this time a real one ;-) leading to this:
https://github.com/felipec/git/issues/2
...
If I understand correctly, the $backend
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
Signed-off-by: Max Horn m...@quendi.de
---
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
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 files., me);
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
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 is
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
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 to access it for next would of course be a nice bonus
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 gave
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:
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+
+ with
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 very
Am 08.03.2013 um 16:32 schrieb Andrew Wong andrew.k...@gmail.com:
On 3/8/13, Max Horn m...@quendi.de 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
Am 08.03.2013 um 19:02 schrieb Andrew Wong andrew.k...@gmail.com:
On 3/8/13, Max Horn m...@quendi.de 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 flabbergasted
On 08.03.2013, at 20:20, Andrew Wong wrote:
On 3/8/13, Max Horn m...@quendi.de 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 is working... backup
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, then the
third time in commit 15
On 11.03.2013, at 20:15, Andrew Wong wrote:
On 3/10/13, Max Horn m...@quendi.de wrote:
I did run
touch lib/*.* src/*.* git update-index --refresh git diff-files
a couple dozen times (the problematic files where in src/ and lib), but
nothing happened. I just re-checked, and the rebase
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 22:34, Andrew Wong wrote:
On 3/11/13, Max Horn m...@quendi.de 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, though, but I am
not quite sure what
On 11.03.2013, at 23:10, Andrew Wong wrote:
On 3/11/13, Max Horn m...@quendi.de 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 changed over time
On 11.03.2013, at 23:54, Andrew Wong wrote:
On 3/11/13, Max Horn m...@quendi.de 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 the rebase work, every single time. Huh
On 11.03.2013, at 23:54, Andrew Wong wrote:
On 3/11/13, Max Horn m...@quendi.de 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 the rebase work, every single time. Huh
On 09.07.2012, at 16:50, Junio C Hamano wrote:
Max Horn m...@quendi.de writes:
The configure script checks whether certain flags / libraries are
required to use pthreads. But so far it did not consider the possibility
that no extra compiler flags are needed (as is the case on Mac OS X
On 09.07.2012, at 19:44, Junio C Hamano wrote:
Max Horn m...@quendi.de writes:
diff --git a/configure.ac b/configure.ac
index 4e9012f..d767ef3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1002,7 +1002,7 @@ if test -n $USER_NOPTHREAD; then
# -D_REENTRANT' or some such.
elif test -z
On 09.07.2012, at 21:23, Junio C Hamano wrote:
Max Horn m...@quendi.de writes:
would it be feasible for the purpose of
the check to tweak the definition of works used in the loop so that
it considers the warning as not working?
That would be possible, and probably a good idea
1 - 100 of 120 matches
Mail list logo
