On 12/27/18 3:55 PM, Jonathan Nieder wrote:
> Hi,
>
> H. Peter Anvin wrote:
>
>> [merge "version"]
>> name = Version file merge driver
>> driver = sort -V -r %O %A %B | head -1 > %A.tmp.1 && mv -f %A.tmp.1
>> %A
&g
The current definition for merge drivers require the output file %A to be
overwritten. When using a pipeline of Unix commands, this often results in %A
being truncated too early, requiring the user to add a temporary file managed
explicitly.
It would be far preferable if git could manage this; per
Right now, merge rules can get selected in .gitattributes, which is
version-controlled. However, there does not appear to be any way to *define*
custom merge rules which is version controlled.
There are a lot of different files which can benefit from custom merge rules,
especially ones that are in
On April 14, 2016 10:23:03 AM PDT, David Turner
wrote:
>On Wed, 2016-04-13 at 21:53 -0400, Theodore Ts'o wrote:
>> On Tue, Apr 12, 2016 at 07:15:34PM -0400, David Turner wrote:
>> >
>> > If SHA-1 is broken (in certain ways), someone *can* replace an
>> > arbitrary blob. GPG does not help in thi
On April 12, 2016 6:51:12 PM PDT, Duy Nguyen wrote:
>On Wed, Apr 13, 2016 at 5:38 AM, H. Peter Anvin wrote:
>> OK, I'm going to open this can of worms...
>>
>> At what point do we migrate from SHA-1?
>
>Brian Carlson has been slowly refactoring git code base, ab
On 04/12/16 18:03, Junio C Hamano wrote:
and so on. Of course trees don't have any space for this; they have a
fixed-length for the hash part of each record, which is basically:
NUL <20-byte-sha1>
So we'd probably need a "treev2" object type that gives room for an
algorithm byte (or we'd
On 04/12/16 16:00, Stefan Beller wrote:
On Tue, Apr 12, 2016 at 3:38 PM, H. Peter Anvin wrote:
OK, I'm going to open this can of worms...
At what point do we migrate from SHA-1? At this point the cryptoanalysis of
SHA-1 is most likely a matter of time.
And I thought the cryptogr
OK, I'm going to open this can of worms...
At what point do we migrate from SHA-1? At this point the
cryptoanalysis of SHA-1 is most likely a matter of time.
For existing repositories we will need to have a migration mechanism.
Since we can't modify objects without completely invalidating th
On 02/23/2016 01:49 PM, Eric W. Biederman wrote:
>
> So I could really respect a patch header line that said:
> tree abcdef0123456789...0123456789abcdef
>
> Where the numbers where the truncated tree hash before and after a patch
> was applied. That would seem to give a little bit of extra sanit
On February 23, 2016 12:35:12 PM PST, Junio C Hamano wrote:
>ebied...@xmission.com (Eric W. Biederman) writes:
>
>> Junio C Hamano writes:
>>
>>> It is valuable for a testing organization to say "We tested this
>>> series on top of version X. We know it works, we have tested on a
>>> lot more ha
On 02/23/16 01:17, Fengguang Wu wrote:
>
> However we are facing a new situation: in test robot POV, IMHO there
> are values to test exactly the same tree as the patch submitter.
> Otherwise the robot risks
>
> - false negative: failing to apply and test some patches
> - false positive: sending w
On 11/12/2013 09:45 AM, Junio C Hamano wrote:
> "H. Peter Anvin" writes:
>
>> On 11/10/2013 12:17 PM, Eric Wong wrote:
>>> "H. Peter Anvin" wrote:
>>>> When a remote server is unavailable or very slow, some git commands can
>>>>
On 11/10/2013 12:17 PM, Eric Wong wrote:
> "H. Peter Anvin" wrote:
>> When a remote server is unavailable or very slow, some git commands can
>> stall out indefinitely. It would be a very good thing if remote
>> commands -- but especially git fetch -- could be
When a remote server is unavailable or very slow, some git commands can
stall out indefinitely. It would be a very good thing if remote
commands -- but especially git fetch -- could be given a timeout.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a
Hi Shawn,
You wrote a really great protocol spec for the smart HTTP protocol back
in the day. It would be really great if it could be checked into the
git repository (updated if need be). Someone mentioned today trying to
reverse-engineer the protocol because of a lack of specs, and I was a
bit
Right now, there are events which can cause git fetch to hang forever.
This is really problematic in automatic use.
A git fetch --timeout which would exit with a nonzero exit code if no
forward progress is made would be really helpful.
-hpa
--
To unsubscribe from this list: send the line
On 08/10/2012 09:15 AM, Junio C Hamano wrote:
> "H. Peter Anvin" writes:
>
>> The users I am referring to generally have a --- line, rather than
>> a scissor, between the cover text and commit. Also, there is
>> (almost) always a From: line and subject at the t
The users I am referring to generally have a --- line, rather than a scissor,
between the cover text and commit. Also, there is (almost) always a From: line
and subject at the top of the patch proper.
Junio C Hamano wrote:
>Jeff King writes:
>
>> If I understand your issue, somebody is writi
anually.
I have tried git am --scissors and it doesn't seem to solve the problem.
Is there any other option which can be used to automatically process
such a patch?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To u
Martin Langhoff wrote:
On 9/7/05, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
This patch changes git-cvsimport-script so that it creates tag objects
instead of refs to commits, and adds an option, -u, to convert
underscores in branch and tag names to dots (since CVS doesn't al
H. Peter Anvin wrote:
So, C surely has its head updated? Does cg-update "fail" silently, or
does it utter anything?
C has its head updated, yes. cg-update says "Branches already fully
merged."
OK, now later in the day I could not reproduce this on another box.
Eith
Petr Baudis wrote:
Dear diary, on Tue, Sep 06, 2005 at 11:01:25PM CEST, I got a letter
where "H. Peter Anvin" <[EMAIL PROTECTED]> told me that...
I just found a bug in cogito-0.13, at least to the best of my
understanding of the situation.
Simplified, the problem looks like
Martin Langhoff wrote:
My style has always be to use tags for merges; tag the origin branch as
well as before and after on the receiving branch.
Do you move the tags with cvs tag -F? If that's the case, the data you
need to merge is lost... otherwise, you could hack an alternative
merge detec
Martin Langhoff wrote:
Tell me more about how you are trying the 'recognize merge'. It is a
pretty unsophisticated thing, as it trusts the commit message in the
first place. But when it works, it works.
Perhaps it would be good to know what it expects in the commit message?
My style has alwa
I just found a bug in cogito-0.13, at least to the best of my
understanding of the situation.
Simplified, the problem looks like this: two sides, A and B, pull from
repository C. The head of this pull we call 0.
Now commit 1 is added to A. B pulls commit 1 from A, not though C.
Later, A pu
H. Peter Anvin wrote:
H. Peter Anvin wrote:
This patch changes git-cvsimport-script so that it creates tag objects
instead of refs to commits, and adds an option, -u, to convert
underscores in branch and tag names to dots (since CVS doesn't allow
dots in branches and tags.)
Pullable
H. Peter Anvin wrote:
This patch changes git-cvsimport-script so that it creates tag objects
instead of refs to commits, and adds an option, -u, to convert
underscores in branch and tag names to dots (since CVS doesn't allow
dots in branches and tags.)
Pullable tree at master.kerne
This patch changes git-cvsimport-script so that it creates tag objects
instead of refs to commits, and adds an option, -u, to convert
underscores in branch and tag names to dots (since CVS doesn't allow
dots in branches and tags.)
Pullable tree at master.kernel.org:/home/hpa/git/cvsimport.git/
Junio C Hamano wrote:
But previous argument by Linus made in a distant (in git
timescale) past is now ingrained in my brain: "the additional
metadata" recorded at the commit time can only help us what we
envisioned in the past when the tool to record that metadata was
written. If we try to "tra
Linus Torvalds wrote:
It's a totally broken model. Really.
You think it solves issues, but it just creates more bugs and problems
than it solves.
Trust me. The whole point of git is that "content is the only thing that
matters", and that there isn't any other meta-data. If you break that
f
Junio C Hamano wrote:
1
/ \
0-2-3-5-7
\ /
4-6
It shouldn't matter to the merge at 7 if the 2-3 reorganization was done
locally, by applying a patch, or by merging.
There was another problem in my message that treated #3
specially. I did it that way primarily because I wanted to ha
Martin Langhoff wrote:
Probably should be hacked into cg-merge. When the merge reports a file
is missing, what happens? Does it leave a .rej file or anything?
The error message is:
MERGE ERROR: nfsmount/mount.c: Not handling case
3225ecdf8d172cda2a6ea5276af0d3edc566a0e7 -> ->
c02da9e576a5
Linus Torvalds wrote:
On Fri, 12 Aug 2005, H. Peter Anvin wrote:
Running it over ssh would be a good way to do authentication...
Well, if you have ssh as an option, you don't need git-daemon any more,
since the protocol that git-daemon does runs quite well over ssh on its
own...
Petr Baudis wrote:
In my tests, the git daemon was noticeably faster than ssh, if only
because the authentication actually tends to be a big part of the overhead
in small pulls.
Oh. Sounds nice, are there plans to run this on kernel.org too? (So far,
90% of my GIT network activity happens wi
Linus Torvalds wrote:
BTW, is the pack protocol flexible enough to be extended to support
pushing?
The _protocol_ could handle it, but you obviously need some kind of secure
authentication, and quite frankly, one of the selling points on git-daemon
right now is that it's all read-only and v
Sam Ravnborg wrote:
On Tue, Aug 02, 2005 at 03:15:19PM -0700, H. Peter Anvin wrote:
Anyone have any good scripts for taking patches in email and turning
them into git commits, preferrably while preserving the author information?
git-applymbox seems to be what you are looking for.
It was
Linus Torvalds wrote:
What I'd ask people to check is how comfortable for example kernel.org
would be to have one machine that runs this kind of service? I've tried
very hard to set it up so that it doesn't have any security issues: the
daemon can be run as "nobody", and it shouldn't ever eve
Petr Baudis wrote:
It _is_ unsafe for individual objects, and your packfile will be corrupt
if you break it in the middle and not have --whole-file turned on, I
assume. It would be ideal if we could make rsync allow resuming download
of the file if interrupted, but not under the final name but i
Petr Baudis wrote:
Yes, please do. I deprecated rsync a day before Linus "broke" http-pull.
It's un-deprecated again for now in the latest Cogito.
Presumably for packed repos you want to drop the --ignore-existing
--whole-file options I assume?
Also, pulling with cogito-0.12:
cg-clone -s
Alecs King wrote:
And as for bash, only gitdiff-do and gitlog.sh 'explicitly' use bash
instead of /bin/sh. On most Linux distros, /bin/sh is just a symbolic
link to bash. But not on some others. I found gitlsobj.sh could not
work using a plain /bin/sh on fbsd. To make life easier, i think it
mi
Linus Torvalds wrote:
So I'll see if I can turn the current fsck into a "convert into
uncompressed format", and do a nice clean format conversion.
Just let me know what you want to do, and I can trivially change the
conversion scripts I've already written to do what you want.
-hpa
-
To
Paul Dickson wrote:
Since 160-bits does not go into base64 evenly anyways, what happens if
you use 2^10 instead of 2^12 for the subdir names? That will be 1/4 the
directories of the base64 given above.
I was going to try one-character subdirs, so 2^6, but I haven't had a
chance to do that since I
David Lang wrote:
note that default configs of ext2 and ext3 don't qualify as sane
filesystems by this definition.
Not using dir_index *IS* insane.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at ht
I have set up /pub/scm/linux/kernel/git on kernel.org. Everyone who had
directories in /pub/linux/kernel/people now have directories in
/pub/scm/linux/kernel/git. For non-kernel trees it would probably be
better to have different trees, however; I also would like to request
that git itself is
Linus Torvalds wrote:
Ok, nobody really objected to the notion of leaving the kernel history
behind for now, and in fact most people seemed to basically agree. So with
that decided, the old kernel testing tree was actually perfectly ok,
except it had been build up with the old-style commit date han
Linus Torvalds wrote:
On Thu, 14 Apr 2005, bert hubert wrote:
It is too easy to get into a O(N^2) situation. Git may be able to deal with
it but you may hurt yourself when making backups, or if you ever want to
share your tree (possibly with yourself) over the network.
Even something as simple as
Linus Torvalds wrote:
Even something as simple as "ls -l" has been known to have O(n**2)
behaviour for big directories.
For filesystems with linear directories, sure. For sane filesystems, it
should have O(n log n).
-hpa
-
To unsubscribe from this list: send the line "unsubscribe git"
David Woodhouse wrote:
On Thu, 2005-04-14 at 12:42 -0700, Luck, Tony wrote:
This is a very good point ... but this still has problems with the
"git is a filesystem, not a SCM" mantra. Timezone comments don't
belong in the git inode.
Yeah, but really I'd want to see other serious users of it before
Petr Baudis wrote:
Cogito. "Git inside" can be the first slogan.
What about tig?
I like "Cogito"; it's a real name, plus it'd be a good use for the
otherwise-pretty-useless two-letter combination "cg".
-hpa
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a
bert hubert wrote:
That may be true :-), but from the "front lines" I can report that
directories with > 32000 or > 65000 entries is *asking* for trouble. There
is a whole chain of systems that need to get things right for huge
directories to work well, and it often is not that way.
Specifics, plea
Linus Torvalds wrote:
On Thu, 14 Apr 2005, H. Peter Anvin wrote:
Although Linus is correct in that an SCM doesn't *have* to handle this,
it really feels like shooting for mediocracy to me. We might as well
design it right from the beginning.
No. git is not an SCM. it's a filesystem d
David Woodhouse wrote:
Opinions? Dissent? We'd probably need to escape the filenames in some
way -- handwave over that for now.
For readability and simplicity I'd suggest using either URL-style %XX
escapes or octal \xxx escapes for anything bytes < 33, minus the escape
character.
Although Linus
Linus Torvalds wrote:
So why is "base64" worse than the stock one?
As mentioned, the "flat" version may be faster, but it really isn't an
option. 32000 objects is peanuts. Any respectable source tree may hit that
in a short time, and will break in horrible ways on many Linux
filesystems.
If it does
Linus Torvalds wrote:
I'll tell you why a flat object directory format simply isn't an option.
Hint: maximum directory size. It's limited by n_link, and it's almost
universally a 16-bit number on Linux (and generally artifically limited to
32000 entries).
In other words, if you ever expect to have
Out of curiosity, I cooked up a version of git which used a flat base32,
instead of base64, repository. The goal of this is, of course, to
provide for compatibility with case-deficient filesystems.
The answer is that the base32 format is measurably slower than base64,
with a cache-hot checkout
H. Peter Anvin wrote:
Actually, the subdirectory hack has the same effect, so you lose
regardless. Doesn't mean that you can't construct cases where the
subdirectory hack doesn't win, but I maintain that those are likely to
be artificial.
That should, of course, be "... wh
Christopher Li wrote:
But if you write a large number of random files, when htree has three
levels index. htree will suffer on the effect that it dirty random block
very quickly, most block get dirty only contain one or two new entries.
Ext3 will choke on it due to the limited journal size.
While n
57 matches
Mail list logo
