Junio C Hamano :
> Roundtrip conversions may benefit from sub-second timestamps, but
> personally I think negative timestamps are more interesting and of
> practical use.
You mean, as in times before the Unix epoch 1970-01-01T00:00:00Z?
Interesting. I hadn't thought of that. I've never seen
On Wed, Nov 28, 2012 at 8:01 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> People who have been bitten by bugs from *your* tree or versions in
>>> 'next' do not count. When I said "no existing users", I was talking
>>> about the end users who need rock solid stable "releases" becaus
Christian Couder writes:
> All the python scripts except contrib/svn-fe/svnrdump_sim.py
> start with "#!/usr/bin/env python".
>
> This patch fix contrib/svn-fe/svnrdump_sim.py to do the same.
I suspect you need a bit more than that.
$ make git-p4
$ diff -u git-p4.py git-p4
shows you ho
Kacper Kornet writes:
> This way when only no-ff is specified all parsers should be happy. If
> reversed-order is specified together no-ff the "external" parser
> probably would fail. Which in my opinion is a good think at this point,
> as it can't correctly interpret MERGE_MODE anyway.
Amen to
Jeff King writes:
> There is room for new headers, and older versions of git will ignore
> them. You could add a new "committer-timestamp" field that elaborates on
> the timestamp included on the committer line. Newer versions of git
> would respect it, and older versions would fall back to using
Martin von Zweigbergk writes:
> On Tue, Nov 27, 2012 at 12:25 PM, Junio C Hamano wrote:
>> Martin von Zweigbergk writes:
>>
>>> simplify a lot of things (maybe I'm biased because of the things I
>>> have happened to work on?)
>>
>> Yes. Do not waste time on it.
>
> Yes, no way I would waste ti
Felipe Contreras writes:
>> People who have been bitten by bugs from *your* tree or versions in
>> 'next' do not count. When I said "no existing users", I was talking
>> about the end users who need rock solid stable "releases" because
>> tagged versions are the only ones they use.
>
> If users
Am 11/28/2012 0:00, schrieb Kacper Kornet:
> When the changes are pushed upstream, and in the meantime someone else
> updated upstream branch git advises to use git pull. This results in
> history:
>
> ---A---B---C--
> \ /
> D---E
The commit message will say:
Merge
It all started when a genius like glass jewelry brand
[url=http://www.swarovskischmuckohrringe.de/]swarovski steine[/url]
began.Property Swarovski Wattens, Austria, and has led his country's name is
known throughout the world. Who would have thought that as a young child
learn the skills Swarovksi
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 adding "-mt" to the list of
> flags (which does nothing on OS X except producing a warnin
---
I ended up rewriting most of the comment. The new version removes
inter-rule dependencies (e.g., rule 5 overrides rule 3) which I think
makes it more readable.
This patch applies on top of the latest patch series regarding
pushing tags. If will include this in a re-roll of that series if
th
- Original Message -
From: Michael Haggerty
Date: 11/25/2012 3:44 AM
* Startup time: Is the time to start the "X" interpreter prohibitive?
(On my computer, "python -c pass", which starts the Python
interpreter and does nothing, takes about 24ms.) This overhead would
be incurred
On Tue, Nov 27, 2012 at 06:18:00PM -0800, Junio C Hamano wrote:
> Kacper Kornet writes:
> > +--transpose-parents::
> > + Transpose the parents in the final commit. The change is made
> > + just before the commit so the meaning of 'our' and 'their'
> > + concepts remains the same (i.e. 'our'
On Tue, Nov 27, 2012 at 06:17:28PM -0800, Junio C Hamano wrote:
> Kacper Kornet writes:
> > Presently only one merge mode exists: non-fast-forward. But in future
> > the second one (transpose-parents) will be added, so the need to read
> > all lines of MERGE_MODE.
> > Signed-off-by: Kacper Korne
On Tue, Nov 27, 2012 at 11:32:16PM -0500, Jeff King wrote:
> $ check dot .
> error: Invalid path '.'
>
> $ check dotdot ..
> error: Updating '..' would lose untracked files in it
>
> $ check dotgit .git
> error: Updating '.git' would lose untracked files in it
>
> Interesting that w
On Wed, Nov 28, 2012 at 11:22:20AM +0700, Nguyen Thai Ngoc Duy wrote:
> > I don't think this is happening in the wild, but I did see somebody
> > playing around with libgit2 make such a tree (and it is easy to do with
> > git-mktree, of course).
> >
> > Technically one could use git with such a tr
Jeff King :
> Felipe suggested using git-notes to add the metadata, which I think is a
> reasonable first step. The git side of the code is already written, and
> the concept is nicely modularized away from the core of git. Nobody has
> to care about it but your importer, and anybody who wants to q
On Wed, Nov 28, 2012 at 9:27 AM, Jeff King wrote:
> A tree with meta-paths like '.' or '..' does not work well
> with git; the index will refuse to load it or check it out
> to the filesystem (and even if we did not have that safety,
> it would look like we were overwriting an untracked
> director
On Tue, Nov 27, 2012 at 10:47:00PM -0500, Eric S. Raymond wrote:
> Jeff King :
> > A much more compelling argument to me would be that you are doing some
> > bidirectional magic between git and svn, and you want to make make sure
> > that an svn->git->svn translation will result in the exact same
I noticed today I can't create a key starting with a number.
The source code[1] confirms this, but is this a bug or is it by design?
[1]: https://github.com/git/git/blob/master/config.c#L1265
--
Peter van der Does
GPG key: CB317D6E
IRC: Ganseki on irc.freenode.net
Twitter: @petervanderdoes
-
Jeff King :
> A much more compelling argument to me would be that you are doing some
> bidirectional magic between git and svn, and you want to make make sure
> that an svn->git->svn translation will result in the exact same bytes.
> Then the argument is still "because SVN has it", but at least it
Junio C Hamano :
> I won't worry about Python 3 yet; in what timeframe did Python's
> i18n/unicode support become usable? In 2.4, or 2.6?
Er, it depends on what you consider "usable".
Unicode integration turned out to have a lot messier edge cases than
anyone understood going in. First-cut supp
On Tue, Nov 27, 2012 at 10:14:46PM -0500, Peter van der Does wrote:
> I noticed today I can't create a key starting with a number.
>
> The source code[1] confirms this, but is this a bug or is it by design?
I don't recall ever discussing it. But what is it that you want to store
in a key startin
On Wed, Nov 28, 2012 at 4:22 AM, Jeff King wrote:
> On Wed, Nov 28, 2012 at 04:15:12AM +0100, Felipe Contreras wrote:
>
>> > We could improve the test in t5801, but it is nice to let people on such
>> > systems test it, as well. And the infrastructure might be useful if we
>> > ever acquire more b
On Tue, Nov 27, 2012 at 10:23:37PM -0500, Eric S. Raymond wrote:
> Jeff King :
> > But I really wonder if anybody actually cares about adding sub-second
> > timestamp support, or if it is merely "because SVN has it".
>
> There's actually one possible other reason to care. 1-second granularity
>
All the python scripts except contrib/svn-fe/svnrdump_sim.py
start with "#!/usr/bin/env python".
This patch fix contrib/svn-fe/svnrdump_sim.py to do the same.
Signed-off-by: Christian Couder
---
contrib/svn-fe/svnrdump_sim.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/c
Jeff King :
> But I really wonder if anybody actually cares about adding sub-second
> timestamp support, or if it is merely "because SVN has it".
There's actually one possible other reason to care. 1-second granularity
isn't quite fine enough to guarantee that a (committer, timestamp)
pair is a
On Wed, Nov 28, 2012 at 04:15:12AM +0100, Felipe Contreras wrote:
> > We could improve the test in t5801, but it is nice to let people on such
> > systems test it, as well. And the infrastructure might be useful if we
> > ever acquire more bash scripts.
> >
> > There's a fair bit of boilerplate, b
On Wed, Nov 28, 2012 at 4:11 AM, Jeff King wrote:
> On Tue, Nov 27, 2012 at 09:59:28PM -0500, Jeff King wrote:
>
>> > > Renaming of remote-testgit feels to be a mistake. It probably
>> > > should keep its source in remote-testgit.bash and generate it,
>> >
>> > Why generate it? There's nothing
I noticed today I can't create a key starting with a number.
The source code[1] confirms this, but is this a bug or is it by design?
[1]: https://github.com/git/git/blob/master/config.c#L1265
--
Peter van der Does
GPG key: CB317D6E
IRC: Ganseki on irc.freenode.net
Twitter: @petervanderdoes
-
On Wed, Nov 28, 2012 at 04:10:07AM +0100, Felipe Contreras wrote:
> >> Why generate it? There's nothing to generate. python's source code
> >> needs regeneration, bash's code doesn't.
> >
> > We fix up the #!-lines on all of the existing shell scripts (as well as
> > python and perl). Wouldn't we
On Tue, Nov 27, 2012 at 09:59:28PM -0500, Jeff King wrote:
> > > Renaming of remote-testgit feels to be a mistake. It probably
> > > should keep its source in remote-testgit.bash and generate it,
> >
> > Why generate it? There's nothing to generate. python's source code
> > needs regeneration,
On Wed, Nov 28, 2012 at 3:37 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> At this point, both have been cooking for a week or more in 'next',
>>> there is no existing users, they are on the fringe so breakages in
>>> them won't negatively affect anybody anyway. So it doesn't matter
On Wed, Nov 21, 2012 at 04:31:11AM +0100, Felipe Contreras wrote:
> On Wed, Nov 21, 2012 at 1:05 AM, Junio C Hamano wrote:
> > Here is a list of stalled topics I am having trouble deciding what
> > to do (the default is to dismiss them around feature freeze).
> >
> > * fc/fast-export-fixes (2012-
On Wed, Nov 28, 2012 at 12:28:58AM +0100, Heiko Voigt wrote:
> On Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote:
> > On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:
> > The v4 series leaves the remote branch amigious, but it helps you
> > point the local branch at the rig
Felipe Contreras writes:
>> At this point, both have been cooking for a week or more in 'next',
>> there is no existing users, they are on the fringe so breakages in
>> them won't negatively affect anybody anyway. So it doesn't matter
>> much if they are merged to 'master' and then fixed up with
Junio C Hamano writes:
> Felipe Contreras writes:
>
>> These are general fixes, some for old versions of bazaar, mercurial, and
>> python. Some of these have already been sent, but here they go alone so they
>> are not missed.
>>
>> The bazaar fixes are on top of the series v3 which is still not
A tree with meta-paths like '.' or '..' does not work well
with git; the index will refuse to load it or check it out
to the filesystem (and even if we did not have that safety,
it would look like we were overwriting an untracked
directory). For the same reason, it is difficult to create
such a tre
On Wed, Nov 28, 2012 at 3:02 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> These are general fixes, some for old versions of bazaar, mercurial, and
>> python. Some of these have already been sent, but here they go alone so they
>> are not missed.
>>
>> The bazaar fixes are on top of t
On Wed, Nov 28, 2012 at 2:56 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> OK. Both fc/remote-hg and fc/remote-bzr are slated for 'master'
>>> soonish, but I take the above to mean that fc/remote-hg is ready
>>> while it is better to wait for updates to fc/remote-bzr before
>>> merg
Kacper Kornet writes:
> +--transpose-parents::
> + Transpose the parents in the final commit. The change is made
> + just before the commit so the meaning of 'our' and 'their'
> + concepts remains the same (i.e. 'our' means current branch before
> + the merge).
> +
How does this
Kacper Kornet writes:
> Presently only one merge mode exists: non-fast-forward. But in future
> the second one (transpose-parents) will be added, so the need to read
> all lines of MERGE_MODE.
>
> Signed-off-by: Kacper Kornet
> ---
> builtin/commit.c | 12 ++--
> 1 file changed, 6 inser
On Wed, Nov 28, 2012 at 2:54 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> This is not just "just shuffle the die to make it explicit" but it
>>> does change the semantics; earlier ref->deletion was perfectly fine
>>> as long as data->refspecs is not given, but the new code always
>>
Felipe Contreras writes:
> These are general fixes, some for old versions of bazaar, mercurial, and
> python. Some of these have already been sent, but here they go alone so they
> are not missed.
>
> The bazaar fixes are on top of the series v3 which is still not in 'pu'.
Please stop then. Its
"Eric S. Raymond" writes:
> Junio C Hamano :
>> fsck_ident() in fsck.c rejects anything but " [1-9][0-9]* " after
>> the author and committer ident (i.e. the timestamp has to be
>> integral number of seconds since the epoch, not before it, nor
>> with fractional seconds).
>
> Is this architectura
"Eric S. Raymond" writes:
> I agree that 2.4 is still quite OK. I'm a little concerned that dropping that
> far back might store up some transition problems for the day we decide to
> make the jump to Python 3.
>
> On the other hand, I think gating features on RHEL5 might be
> excessively cautio
On Sun, Nov 25, 2012 at 10:24:59AM +0100, Felipe Contreras wrote:
> Suppose I have these branches:
>
> fc/feature-a
> fc/feature-b
> master
> next
>
> I want to show this: fc/feature-a fc/feature-b ^master ^next. I can do
> 'git log --branches=fc' to show the branches that begin with fc/
Felipe Contreras writes:
>> OK. Both fc/remote-hg and fc/remote-bzr are slated for 'master'
>> soonish, but I take the above to mean that fc/remote-hg is ready
>> while it is better to wait for updates to fc/remote-bzr before
>> merging it.
>
> I was waiting on both to be merged, let me see what
On Wed, Nov 28, 2012 at 2:39 AM, Marc Khouzam wrote:
> On Tue, Nov 27, 2012 at 12:16 PM, Junio C Hamano wrote:
>> The patch was linewrapped so I had to fix it up;
>
> Sorry about that. I don't know if it is gmail, or the fact that I use
> its web interface
> that causes these problems.
>
>> plea
Felipe Contreras writes:
>> This is not just "just shuffle the die to make it explicit" but it
>> does change the semantics; earlier ref->deletion was perfectly fine
>> as long as data->refspecs is not given, but the new code always
>> dies.
>>
>> If this semantic change is a good thing, please e
On Wed, Nov 28, 2012 at 02:22:09AM +0100, Felipe Contreras wrote:
> Sure, you will argue that we don't see the *real* issues, because they
> were fixed preemptively, but the fact of the matter is that we will
> never know. All we know is the reality we can observe, and the reality
> is that we hit
On Tue, Nov 27, 2012 at 12:16 PM, Junio C Hamano wrote:
> The patch was linewrapped so I had to fix it up;
Sorry about that. I don't know if it is gmail, or the fact that I use
its web interface
that causes these problems.
> please double check
> what will be queued on 'pu' to make sure that I
> -Original Message-
> From: Jeff King
> Sent: Tuesday, November 27, 2012 20:18
>
> On Tue, Nov 27, 2012 at 05:07:34PM -0800, Shawn O. Pearce wrote:
>
> > On Tue, Nov 27, 2012 at 4:26 PM, Felipe Contreras
> > wrote:
> > > On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond
> wrote:
> > >
On Wed, Nov 28, 2012 at 1:51 AM, Jeff King wrote:
> On Wed, Nov 28, 2012 at 01:10:34AM +0100, Felipe Contreras wrote:
>
>> > While "constant traffic" probably overstates the issue, these are not
>> > theoretical problems. I recall at least three cases in the last year
>> > or so where Git has seen
On Tue, Nov 27, 2012 at 05:07:34PM -0800, Shawn O. Pearce wrote:
> On Tue, Nov 27, 2012 at 4:26 PM, Felipe Contreras
> wrote:
> > On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond wrote:
> >> Shawn Pearce :
> >>> Well... if we added a fractional seconds to a commit, older versions
> >>> of Git wi
Felipe Contreras :
> % git cat-file -p HEAD
>
> You'll see exactly how git stores commits. Changing anything in there
> must be done carefully.
Oh, I've seen *that* before. Are you telling me the database
representation is actually textual?
--
http://www.catb.org/~esr/";>Eric S
On Tue, Nov 27, 2012 at 4:26 PM, Felipe Contreras
wrote:
> On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond wrote:
>> Shawn Pearce :
>>> Well... if we added a fractional seconds to a commit, older versions
>>> of Git will scream loudly and refuse to work with the new commit. That
>>> would create
So we don't create a clone unnecessarily.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 48 ---
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remot
At least as old as 2.0.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index f8919f4..6cdfac6 100755
--- a/
As Amit Bakshi reported, older versions of python (< 2.7) don't have
subprocess.check_output, so let's use subprocess.Popen directly as
suggested.
Suggested-by: Amit Bakshi
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 12
1 file changed, 8 insertions(+
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 07754bd..62c39db 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/
Hi,
These are general fixes, some for old versions of bazaar, mercurial, and
python. Some of these have already been sent, but here they go alone so they
are not missed.
The bazaar fixes are on top of the series v3 which is still not in 'pu'.
Felipe Contreras (4):
remote-hg: fix for files with
On Wed, Nov 28, 2012 at 01:10:34AM +0100, Felipe Contreras wrote:
> > While "constant traffic" probably overstates the issue, these are not
> > theoretical problems. I recall at least three cases in the last year
> > or so where Git has seen breakage with Solaris or Mac OS X because
> > of sed or
On Wed, Nov 28, 2012 at 12:32 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Mon, Nov 26, 2012 at 5:09 AM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras
wrote:
> This is a re-roll of the previous series to a
On Wed, Nov 28, 2012 at 12:19:04AM +0100, Jens Lehmann wrote:
> Am 26.11.2012 22:00, schrieb W. Trevor King:
> > From: "W. Trevor King"
> >
> > This allows users to override the .gitmodules value with a
> > per-repository value.
>
> [snip problems]. You should use the branch setting from .git/c
On Tue, Nov 27, 2012 at 06:30:17PM -0500, Aaron Schrab wrote:
> At 18:07 -0500 27 Nov 2012, Jeff King wrote:
> >PS I also think the OP's "sockpuppet creates innocuous bugfix" above is
> > easier said than done. We do not have SHA-1 collisions yet, but if
> > the md5 attacks are any indication,
On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond wrote:
> Shawn Pearce :
>> Well... if we added a fractional seconds to a commit, older versions
>> of Git will scream loudly and refuse to work with the new commit. That
>> would create a fork of Git.
>
> So much for that idea, I guess.
>
> Unless..
On Tue, 27 Nov 2012, Eric S. Raymond wrote:
Shawn Pearce :
Well... if we added a fractional seconds to a commit, older versions
of Git will scream loudly and refuse to work with the new commit. That
would create a fork of Git.
So much for that idea, I guess.
Unless..I don't know how git's da
On Wed, Nov 28, 2012 at 12:32 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Mon, Nov 26, 2012 at 5:09 AM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras
wrote:
> This is a re-roll of the previous series to a
On Tue, Nov 27, 2012 at 6:50 PM, Kevin O'Gorman wrote:
> I just converted a SourceForge CVS repo to git using cvs2svn. One
> directory in the result is named CVSROOT and everything would be fine,
> but I wan to know why gitk does not see it.
>
> Git itself does not report it either, but it lets m
Shawn Pearce :
> Well... if we added a fractional seconds to a commit, older versions
> of Git will scream loudly and refuse to work with the new commit. That
> would create a fork of Git.
So much for that idea, I guess.
Unless..I don't know how git's database representations work. Are they
ve
On Tue, Nov 27, 2012 at 6:00 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> Just shuffle the die() part to make it more explicit, and cleanup the
>> code-style.
>>
>> Signed-off-by: Felipe Contreras
>> ---
>> transport-helper.c | 7 +++
>> 1 file changed, 3 insertions(+), 4 delet
The context of the example to push into refs/remotes/satellite/
hierarchy of the other repository needs to be spelled out explicitly
for the value of this example to be fully appreciated. Make it so.
Signed-off-by: Junio C Hamano
---
Brandon Casey writes:
>> So refs are correct. The context is
On Tue, Nov 27, 2012 at 3:04 PM, Eric S. Raymond wrote:
> Junio C Hamano :
>> fsck_ident() in fsck.c rejects anything but " [1-9][0-9]* " after
>> the author and committer ident (i.e. the timestamp has to be
>> integral number of seconds since the epoch, not before it, nor
>> with fractional secon
This is still incomplete without a documentation for two scripts,
Meta/Reintegrate and Meta/cook (both are found on my 'todo' branch
and meant to be checked out in the Meta subdirectory of git.git),
that are meant to help the maintainer workflow but can be used by
interested parties, but the old wr
Felipe Contreras writes:
> On Mon, Nov 26, 2012 at 5:09 AM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras
>>> wrote:
This is a re-roll of the previous series to add support to fetch and push
special modes, and refactor some
At 18:07 -0500 27 Nov 2012, Jeff King wrote:
PS I also think the OP's "sockpuppet creates innocuous bugfix" above is
easier said than done. We do not have SHA-1 collisions yet, but if
the md5 attacks are any indication, the innocuous file will not be
completely clean; it will need to have
Hi,
On Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote:
> On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:
> The v4 series leaves the remote branch amigious, but it helps you
> point the local branch at the right hash so that future calls to
>
> $ git submodule foreach '
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 of
flags (which does nothing on OS X except producing a warning). This in
turn triggered
Am 26.11.2012 22:00, schrieb W. Trevor King:
> From: "W. Trevor King"
>
> This allows users to override the .gitmodules value with a
> per-repository value.
Your intentions makes lots of sense, but your patch does more than
that. Copying the branch setting into .git/config sets the initial
branc
The second version of patches introducing option to change order
of parents in merge commits. The changes in respect to the previous
version:
- I have divided the changes to the preparatory ones, which
only refactore the code without introducing new functionality, and
the commit which introduc
Presently only one merge mode exists: non-fast-forward. But in future
the second one (transpose-parents) will be added, so the need to read
all lines of MERGE_MODE.
Signed-off-by: Kacper Kornet
---
builtin/commit.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/
It is in preparation to introduce --transpose-parents option to
git-merge, when the content of MERGE_MODE will dictate how the
MERGE_HEAD is interpreted.
Signed-off-by: Kacper Kornet
---
builtin/commit.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin/com
When the changes are pushed upstream, and in the meantime someone else
updated upstream branch git advises to use git pull. This results in
history:
---A---B---C--
\ /
D---E
where B is the local commit. D, E are commits pushed by someone else
when the developer was wor
On Sat, Nov 24, 2012 at 10:09:31AM -0800, Shawn O. Pearce wrote:
> On Sat, Nov 24, 2012 at 3:12 AM, Michael Hirshleifer <111...@caltech.edu>
> wrote:
> > Evil Guy creates 2 files, 1 evil and 1 innocuous, with the same SHA-1
> > checksum (including Git header). Mr. Evil creates a local branch with
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
Junio C Hamano :
> fsck_ident() in fsck.c rejects anything but " [1-9][0-9]* " after
> the author and committer ident (i.e. the timestamp has to be
> integral number of seconds since the epoch, not before it, nor
> with fractional seconds).
Is this architecturally significant? It sounds like anot
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 is not the case). This patch series changes that, and
also address some other things in the remote h
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
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/D
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.
Also, explicitly point out the connection between the commands
'list' and 'options' on the one hand, and the sections
'REF LIST ATTRI
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.
Also, explicitly point out the connection between the commands
'list' and 'options' on the one hand, and the sections
'REF LIST ATTRI
This also remove some duplication in the descriptions
(e.g. refspec was explained twice with similar level of detail).
Signed-off-by: Max Horn
---
Documentation/git-remote-helpers.txt | 134 +++
1 file changed, 56 insertions(+), 78 deletions(-)
diff --git a/Docum
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
---
Documentation/git-remote-helpers.txt | 45 +---
1 file changed, 42 insertions(+), 3 del
In the distant past, the order things were documented was
'Invocation', 'Commands', 'Capabilities', ...
Then it was decided that before giving a list of Commands, there
should be an overall description of the 'Input format', which was
a wise decision. However, this description was put as the very
Fix the same issue as the previous one for "git diff --stat";
unmerged entries was doubly-counted.
Signed-off-by: Junio C Hamano
---
diff.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index 26ede82..374b235 100644
--- a/diff.c
+++ b/diff.c
@@ -1701,9
Shawn Pearce writes:
> JGit would fortunately ignore a floating point timestamp specification
> if given in a commit, but I don't know about other Git
> implementations... like say git. :-)
fsck_ident() in fsck.c rejects anything but " [1-9][0-9]* " after
the author and committer ident (i.e. the
Max Horn writes:
> If this is indeed it, would a commit message like
>
>git-remote-helper.txt: minor grammar fix
Perfect. Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kerne
Le mardi 27 novembre 2012 02:51:04 David Aguilar a écrit :
> On Tue, Nov 27, 2012 at 1:17 AM, Sitaram Chamarty
wrote:
> > On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar wrote:
> >> *cough* git-cola *cough*
> >>
> >> it runs everywhere. Yes, windows too. It's written in python.
> >> It's been a
> -Original Message-
> From: Eric S. Raymond
> Sent: Tuesday, November 27, 2012 3:48 PM
>
> Because I do a lot of work on repository conversion tools, I've had
> to learn a lot of detail about ontological mismatches between
> version-control systems - especially places where you lose metad
1 - 100 of 162 matches
Mail list logo
