* [PATCH] Fix usage of carets in git-rev-parse(1)
From: Jonas Fonseca @ 2005-10-05 23:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alan Chandler, git
In-Reply-To: <7v7jcrh7wu.fsf@assigned-by-dhcp.cox.net>
... but using a {caret} attribute.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Junio C Hamano <junkio@cox.net> wrote Wed, Oct 05, 2005:
> Alan Chandler <alan@chandlerfamily.org.uk> writes:
>
> > "A suffix ~<n> to a revision parameter means the commit object that is
> > the <n>th generation grand-parent of the named commit object, following only
> > the first parent. I.e. rev~3 is equivalent to rev^ which is equivalent to
> > rev11^1."
> >
> > Why is rev~3 equivalent to rev^, surely it is equivalent to rev^^^
> >
> > Why is rev~3 equivalent to rev11^1, should that not be rev^1^1^1
>
> Sorry, for not knowing how to do that properly in Asciidoc ;-).
I think something like the following will do ...
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -7,6 +7,9 @@
# Show GIT link as: <command>(<section>); if section is defined, else just show
# the command.
+[attributes]
+caret=^
+
ifdef::backend-docbook[]
[gitlink-inlinemacro]
{0%{target}}
@@ -19,3 +22,5 @@ ifdef::backend-xhtml11[]
[gitlink-inlinemacro]
<a href="{target}.html">{target}{0?({0})}</a>
endif::backend-xhtml11[]
+
+
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -54,13 +54,13 @@ OPTIONS
`git-diff-\*`).
--not::
- When showing object names, prefix them with '^' and
- strip '^' prefix from the object names that already have
+ When showing object names, prefix them with '{caret}' and
+ strip '{caret}' prefix from the object names that already have
one.
--symbolic::
Usually the object names are output in SHA1 form (with
- possible '^' prefix); this option makes them output in a
+ possible '{caret}' prefix); this option makes them output in a
form as close to the original input as possible.
@@ -93,22 +93,23 @@ what is called an 'extended SHA1' syntax
happen to have both heads/master and tags/master, you can
explicitly say 'heads/master' to tell GIT which one you mean.
-* A suffix '^' to a revision parameter means the first parent of
- that commit object. '^<n>' means the <n>th parent (i.e.
- 'rev^'
- is equivalent to 'rev^1'). As a special rule,
- 'rev^0' means the commit itself and is used when 'rev' is the
+* A suffix '{caret}' to a revision parameter means the first parent of
+ that commit object. '{caret}<n>' means the <n>th parent (i.e.
+ 'rev{caret}'
+ is equivalent to 'rev{caret}1'). As a special rule,
+ 'rev{caret}0' means the commit itself and is used when 'rev' is the
object name of a tag object that refers to a commit object.
* A suffix '~<n>' to a revision parameter means the commit
object that is the <n>th generation grand-parent of the named
commit object, following only the first parent. I.e. rev~3 is
- equivalent to rev^^^ which is equivalent to rev^1^1^1.
+ equivalent to rev{caret}{caret}{caret} which is equivalent to\
+ rev{caret}1{caret}1{caret}1.
-'git-rev-parse' also accepts a prefix '^' to revision parameter,
+'git-rev-parse' also accepts a prefix '{caret}' to revision parameter,
which is passed to 'git-rev-list'. Two revision parameters
concatenated with '..' is a short-hand for writing a range
-between them. I.e. 'r1..r2' is equivalent to saying '^r1 r2'
+between them. I.e. 'r1..r2' is equivalent to saying '{caret}r1 r2'
Author
--
Jonas Fonseca
^ permalink raw reply
* Re: clone: I'm only doing a max of 256 requests
From: Junio C Hamano @ 2005-10-05 23:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510051541300.31407@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> No, just change the "MAX_NEEDS" define from 256 to some larger value.
>
> There's no real reason for the limit, except that maybe we should have
> some dynamic allocation for this.
If somebody is asking for more than say 20 refs, even if the
repository is mature and has 1000 point releases tagged, it
might not make that much of a difference if we ship everything
back instead of being selective, especially when the downloader
said "I do not have anything", i.e. initial cloning.
So after the 'rev-list --all' patch, I was actually going to
suggest reducing MAX_NEEDS, to say 47 (another arbitrary
number), and maybe making MAX_HAS side dynamic to hold more refs
for the stop list.
Also it may be worthwhile to teach upload-pack.c::got_sha1() to
notice when the other side says he has one object and we know
that object is reachable from another object he already said he
has, and choose not to use the older object on the has_sha1[]
list. The "have" list from fetch-pack tends to come from newer
to older, so this would save has_sha1[] array entries from being
consumed by older commits when we know about the commits he has
near the tip of the same branch.
^ permalink raw reply
* Re: Confused as to the correct syntax
From: Junio C Hamano @ 2005-10-05 23:54 UTC (permalink / raw)
To: git
In-Reply-To: <200510060033.51010.alan@chandlerfamily.org.uk>
Alan Chandler <alan@chandlerfamily.org.uk> writes:
>> Sorry, for not knowing how to do that properly in Asciidoc ;-).
>>
>> The source to the man page and HTML page reads like this:
>>
>> * A suffix '~<n>' to a revision parameter means the commit
>> object that is the <n>th generation grand-parent of the named
>> commit object, following only the first parent. I.e. rev~3 is
>> equivalent to rev^^^ which is equivalent to rev^1^1^1.
>
> No the HTML page is screwed up too.
I know. The source reads like above, is what I said. Help from
Asciidoc savvy people is very welcomed.
^ permalink raw reply
* Re: [PATCH] Fall back to three-way merge when applying a patch.
From: Junio C Hamano @ 2005-10-06 0:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510050725510.31407@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> ... Although I would actually prefer to be able to try against
> a specific named release (not "all named tags" first).
That makes sense, given that you know better than the tool can
possibly guess, especially from the performance point of view.
What's interesting is that from the correctness point of view,
it should not make that much of a difference which base tree
happens to be picked -- if the base tree is wildly different
from your current HEAD, most of that wild difference will be
carried over intact to the result of patch application for paths
and parts of the files the patch does not touch. Three-way
merge notices that and your "changes" from the base tree win.
> Quite often, the reason it doesn't apply is that I already have that patch
> through a git merge (or because I applied that patch earlier through
> another person), in which case I don't even try to merge it, I just delete
> that email too, and just do "git-applymbox" again.
Thanks. So in short, you do not even need '-c' option, but just
trim the mbox you feed to applymbox and re-run it.
While I was experimenting with the git-am (only in 'pu' branch,
and still marked as "do not use"), I noticed that it does the
right thing on an already applied patch. It fails to apply,
finds an appropriate base and then notices the result of the
patch application is already contained in the HEAD ;-).
^ permalink raw reply
* Re: [PATCH] Fix usage of carets in git-rev-parse(1)
From: Junio C Hamano @ 2005-10-06 0:06 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Alan Chandler, git
In-Reply-To: <20051005234222.GA19292@diku.dk>
Jonas Fonseca <fonseca@diku.dk> writes:
> ... but using a {caret} attribute.
>
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Thanks. This seems to fix it. Applied and pushed out (but not
in time for just released 0.99.8b).
^ permalink raw reply
* [PATCH] gitk: Add "Refs" menu
From: Pavel Roskin @ 2005-10-06 0:38 UTC (permalink / raw)
To: git, Paul Mackerras
Hello, Paul!
This patch adds "Refs" menu to gitk. It makes all branches, tags and
other ref objects appear as menu items. Selecting one of the items
selects the corresponding line in the view.
Known limitation: it's only possible to go to the refs present in the
current view. Otherwise, gitk would have to re-run git-rev-list.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -285,6 +285,7 @@ proc readrefs {} {
}
}
readotherrefs refs {} {tags heads}
+ setrefsmenu
}
proc readotherrefs {base dname excl} {
@@ -538,6 +539,62 @@ proc makewindow {} {
$rowctxmenu add command -label "Write commit to file" -command writecommit
}
+proc gotocommit_menu {sha1} {
+ global idline
+
+ if {[info exists idline($sha1)]} {
+ selectline $idline($sha1) 1
+ return
+ } else {
+ # Should we re-run git-rev-list?
+ error_popup "$sha1 is not in the current view"
+ }
+}
+
+proc setrefsmenu {} {
+ global headids tagids otherrefids
+
+ if {[winfo exists .bar.refs]} {
+ foreach w [winfo children .bar.refs] {
+ destroy $w
+ }
+ .bar.refs delete 1 3
+ } else {
+ .bar add cascade -label "Refs" -menu .bar.refs
+ menu .bar.refs
+ }
+
+ set refids [lsort -unique [concat [array names headids]]]
+ if {[llength $refids] > 0} {
+ .bar.refs add cascade -label "Branches" -menu .bar.refs.heads
+ menu .bar.refs.heads
+ foreach v $refids {
+ .bar.refs.heads add command -label $v \
+ -command "gotocommit_menu $headids($v)"
+ }
+ }
+
+ set refids [lsort -unique [concat [array names tagids]]]
+ if {[llength $refids] > 0} {
+ .bar.refs add cascade -label "Tags" -menu .bar.refs.tags
+ menu .bar.refs.tags
+ foreach v $refids {
+ .bar.refs.tags add command -label $v \
+ -command "gotocommit_menu $tagids($v)"
+ }
+ }
+
+ set refids [lsort -unique [concat [array names otherrefids]]]
+ if {[llength $refids] > 0} {
+ .bar.refs add cascade -label "Other" -menu .bar.refs.other
+ menu .bar.refs.other
+ foreach v $refids {
+ .bar.refs.other add command -label $v \
+ -command "gotocommit_menu $otherrefids($v)"
+ }
+ }
+}
+
# when we make a key binding for the toplevel, make sure
# it doesn't get triggered when that key is pressed in the
# find string entry widget.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH]: gitk: different shape for other refs
From: Pavel Roskin @ 2005-10-06 1:44 UTC (permalink / raw)
To: Paul Mackerras, git
Hello!
It's not unfriendly to distinguish heads and other refs only by color.
Not everybody can distinguish green and blue. This patch changes the
shape used for other refs to "tabs" with five corners.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -939,15 +939,17 @@ proc drawtags {id x xt y1} {
$canv bind $t <1> [list showtag $tag 1]
set rowtextx($idline($id)) [expr {$xr + $linespc}]
} else {
- # draw a head or other ref
if {[incr nheads -1] >= 0} {
- set col green
+ # draw a head
+ set xl [expr $xl - $delta/2]
+ $canv create polygon $x $yt $xr $yt $xr $yb $x $yb \
+ -width 1 -outline black -fill green -tags tag.$id
} else {
- set col "#ddddff"
+ # draw other ref
+ $canv create polygon $x [expr $yt + $delta] $xl $yt \
+ $xr $yt $xr $yb $x $yb \
+ -width 1 -outline black -fill "#ddddff" -tags tag.$id
}
- set xl [expr $xl - $delta/2]
- $canv create polygon $x $yt $xr $yt $xr $yb $x $yb \
- -width 1 -outline black -fill $col -tags tag.$id
}
set t [$canv create text $xl $y1 -anchor w -text $tag \
-font $mainfont -tags tag.$id]
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] Fall back to three-way merge when applying a patch.
From: Eric W. Biederman @ 2005-10-06 1:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vslvfcy0g.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> ... Although I would actually prefer to be able to try against
>> a specific named release (not "all named tags" first).
>
> That makes sense, given that you know better than the tool can
> possibly guess, especially from the performance point of view.
>
> What's interesting is that from the correctness point of view,
> it should not make that much of a difference which base tree
> happens to be picked -- if the base tree is wildly different
> from your current HEAD, most of that wild difference will be
> carried over intact to the result of patch application for paths
> and parts of the files the patch does not touch. Three-way
> merge notices that and your "changes" from the base tree win.
There is another workable strategy. Modify git-diff-xxx to report
the sha1 of the tree, or the sha1's of the files the patch applies to.
And make that information available to git-apply. I don't how often
it would help but it has the possibility of letting the tools know
exactly what the patch applied against.
A rational for why this would work is that is that a kernel repository
is large, and unless objects/alternatives can be made to work across
servers there will be people who can use git for development but can't
host a repository that can be pulled from. Especially for a small
patch.
Using sha1's for context before merging should be able to give you a
whole lot more machine verifiable context with just a little bit of work.
Eric
^ permalink raw reply
* [PATCH] gitk: use UTF-8 encoding
From: Pavel Roskin @ 2005-10-06 2:12 UTC (permalink / raw)
To: git, Paul Mackerras
gitk should try to use UTF-8 encoding for system operations, such as
reading and writing files and git output.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -3726,6 +3726,7 @@ set colors {green red blue magenta darkg
catch {source ~/.gitk}
+catch {encoding system utf-8}
set namefont $mainfont
if {$boldnames} {
lappend namefont bold
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] Fall back to three-way merge when applying a patch.
From: Linus Torvalds @ 2005-10-06 2:18 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Junio C Hamano, git
In-Reply-To: <m1mzln9zi1.fsf@ebiederm.dsl.xmission.com>
On Wed, 5 Oct 2005, Eric W. Biederman wrote:
>
> There is another workable strategy. Modify git-diff-xxx to report
> the sha1 of the tree, or the sha1's of the files the patch applies to.
Not workable.
It fundamentally only works for the first patch in a series. After that,
the rest will be based off a version that the recipient simply doesn't
have (well, if it's the _tree_ SHA1, and the recipient has no other
patches, then they'll match, but that case is uninteresting, since it's
the trivial case that you always get right by just applying the things in
the first place).
So you'd have to make it the base for the patch _series_, at a minimum.
And even that likely doesn't work very often. Any time you have a private
merge or some other patch in your tree, the recipient wouldn't be able to
parse it.
In practice, I've found that most often it's very trivially obvious _why_
a patch doesn't apply (I remember the "other patch" that happened to the
same file, or I just do a "git-whatchanged -p filename"), and it can be
useful to allow the person applying the patch to say "ok, try to apply it
against version xyz, and do a three-way merge".
But it really tends to be fairly rare.
Now obviously, some of that may be kernel-specific - a large part of the
lack of patch conflicts is that we over the years have actively tried to
set up the kernel sources so that people seldom step on each other (one
example is how we have all modules contain their own "init_module()" thing
and sortign it out in the linker - because the old init/main.c approach
was _very_ painful since everybody wanted to add lines to the same file).
So it may turn out that other projects might have different wishes for how
something like this would work. But I doubt it works very well to rely on
commit-level SHA1's - it's more likely to work if you try the "last few
tagged releases etc", since patches that don't apply are often against the
previous release (and if they don't apply there either, then it's probably
not worth fighting over anyway).
Linus
^ permalink raw reply
* [PATCH] gitk: Add "Refs" menu - revised
From: Pavel Roskin @ 2005-10-06 4:11 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
In-Reply-To: <1128559088.32103.8.camel@dv>
Hello!
This is an updated revision of the original patch. Unneeded concat has
been removed. Error message uses name, not SHA1 ID. If there is
information for the tag, it's displayed even in the ID is not in the
list. Thanks to Brett Schwarz for help.
---------------------------------
This patch adds "Refs" menu to gitk. It makes all branches, tags and
other ref objects appear as menu items. Selecting one of the items
selects the corresponding line in the view.
It's only possible to go to the refs present in the current view.
However, information for tags is shown even if the corresponding ID is
not available.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff -u b/gitk b/gitk
--- b/gitk
+++ b/gitk
@@ -285,6 +285,7 @@
}
}
readotherrefs refs {} {tags heads}
+ setrefsmenu
}
proc readotherrefs {base dname excl} {
@@ -538,6 +539,65 @@
$rowctxmenu add command -label "Write commit to file" -command writecommit
}
+proc gotocommit_menu {sha1 name} {
+ global idline tagids tagcontents
+
+ if {[info exists idline($sha1)]} {
+ selectline $idline($sha1) 1
+ } else {
+ # Should we re-run git-rev-list?
+ error_popup "$name is not in the current view"
+ }
+
+ if {[info exists tagcontents($name)]} {
+ showtag $name 1
+ }
+}
+
+proc setrefsmenu {} {
+ global headids tagids otherrefids
+
+ if {[winfo exists .bar.refs]} {
+ foreach w [winfo children .bar.refs] {
+ destroy $w
+ }
+ .bar.refs delete 1 3
+ } else {
+ .bar add cascade -label "Refs" -menu .bar.refs
+ menu .bar.refs
+ }
+
+ set refids [lsort -unique [array names headids]]
+ if {[llength $refids] > 0} {
+ .bar.refs add cascade -label "Branches" -menu .bar.refs.heads
+ menu .bar.refs.heads
+ foreach v $refids {
+ .bar.refs.heads add command -label $v \
+ -command [list gotocommit_menu $headids($v) $v]
+ }
+ }
+
+ set refids [lsort -unique [array names tagids]]
+ if {[llength $refids] > 0} {
+ .bar.refs add cascade -label "Tags" -menu .bar.refs.tags
+ menu .bar.refs.tags
+ foreach v $refids {
+ .bar.refs.tags add command -label $v \
+ -command [list gotocommit_menu $tagids($v) $v]
+ }
+ }
+
+ set refids [lsort -unique [array names otherrefids]]
+ if {[llength $refids] > 0} {
+ .bar.refs add cascade -label "Other" -menu .bar.refs.other
+ menu .bar.refs.other
+ foreach v $refids {
+ .bar.refs.other add command -label $v \
+ -command [list gotocommit_menu $otherrefids($v) $v]
+ }
+ }
+}
+
# when we make a key binding for the toplevel, make sure
# it doesn't get triggered when that key is pressed in the
# find string entry widget.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] Fall back to three-way merge when applying a patch.
From: Junio C Hamano @ 2005-10-06 4:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric W. Biederman, git
In-Reply-To: <Pine.LNX.4.64.0510051909390.31407@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> ... But I doubt it works very well to rely on
> commit-level SHA1's - it's more likely to work if you try the "last few
> tagged releases etc", since patches that don't apply are often against the
> previous release (and if they don't apply there either, then it's probably
> not worth fighting over anyway).
That is the heuristics git-applypatch in the proposed updates
branch tries to attempt. Recorded tree if exists (which is not
very interesting), last few commits from the current branch, and
then tagged releases.
Ideally, if we had the path following git-rev-list you talked
about, we could first ask git-apply the set of paths the patch
touches, and instead of trying every commits from the HEAD, try
only commits that touch one (or more) of the given paths.
Another possible git-rev-list enhancement that might be useful
is to pop commits not based on time but based on the depth from
branch heads. Then we could:
git-rev-list --depth-order --max-count=$N --all \
$(git-apply --show-files $patch | sed -e 's/^[^ ]* [^ ]* //p')
to obtain list of the last few commits that touch the paths
involved, in the order that is closer-to-tip first.
^ permalink raw reply
* Re: [PATCH] gitk: use UTF-8 encoding
From: Junio C Hamano @ 2005-10-06 4:19 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1128564768.32103.18.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> gitk should try to use UTF-8 encoding for system operations, such as
> reading and writing files and git output.
I agree about commit messages, but I am not so sure about the
file contents (aka user data). Is it possible to control them
separately?
^ permalink raw reply
* Re: [PATCH] gitk: use UTF-8 encoding
From: H. Peter Anvin @ 2005-10-06 5:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pavel Roskin, git
In-Reply-To: <7vvf0b9t0d.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
>
>>gitk should try to use UTF-8 encoding for system operations, such as
>>reading and writing files and git output.
>
> I agree about commit messages, but I am not so sure about the
> file contents (aka user data). Is it possible to control them
> separately?
>
git needs to be able to treat user data as arbitrary binary blobs.
However, if interpreting as text, UTF-8 is the right default, at least.
-hpa
^ permalink raw reply
* Re: [PATCH] Fall back to three-way merge when applying a patch.
From: Eric W. Biederman @ 2005-10-06 5:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0510051909390.31407@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Wed, 5 Oct 2005, Eric W. Biederman wrote:
>>
>> There is another workable strategy. Modify git-diff-xxx to report
>> the sha1 of the tree, or the sha1's of the files the patch applies to.
>
> Not workable.
>
> It fundamentally only works for the first patch in a series. After that,
> the rest will be based off a version that the recipient simply doesn't
> have (well, if it's the _tree_ SHA1, and the recipient has no other
> patches, then they'll match, but that case is uninteresting, since it's
> the trivial case that you always get right by just applying the things in
> the first place).
But what about the file sha1? The intuition is that you can
easily provide a lot more context in diffs and that the extra
context might be useful in merging patches. The part that gives
me how is when I look at if from a diff/patch perspective and
not from a git perspective.
> So you'd have to make it the base for the patch _series_, at a minimum.
>
> And even that likely doesn't work very often. Any time you have a private
> merge or some other patch in your tree, the recipient wouldn't be able to
> parse it.
True although in many cases people rework their diffs before sending
them out to avoid situations like the above.
> In practice, I've found that most often it's very trivially obvious _why_
> a patch doesn't apply (I remember the "other patch" that happened to the
> same file, or I just do a "git-whatchanged -p filename"), and it can be
> useful to allow the person applying the patch to say "ok, try to apply it
> against version xyz, and do a three-way merge".
Ah. I had missed that git-whatchanged can be given a filename that is
nice. One of the better kept secrets of git. That makes my whole
question worthwhile :)
> But it really tends to be fairly rare.
I don't know how rare it is. I have had a couple of patches in the last
week that I could successfully auto-merge between branches but the
diffs themselves would actually conflict.
> Now obviously, some of that may be kernel-specific - a large part of the
> lack of patch conflicts is that we over the years have actively tried to
> set up the kernel sources so that people seldom step on each other (one
> example is how we have all modules contain their own "init_module()" thing
> and sortign it out in the linker - because the old init/main.c approach
> was _very_ painful since everybody wanted to add lines to the same file).
>
> So it may turn out that other projects might have different wishes for how
> something like this would work. But I doubt it works very well to rely on
> commit-level SHA1's - it's more likely to work if you try the "last few
> tagged releases etc", since patches that don't apply are often against the
> previous release (and if they don't apply there either, then it's probably
> not worth fighting over anyway).
Agreed, commit level sha1 are not very interesting.
But if you happen to have at least the file level sha1 you can
actually know if the patch was against what you think it is against.
At one level you could make conflicts more common by dropping any patch
whose source file had the wrong sha1. At another level you could
test for the sha1 of the source file in the repository and know quickly
if there is something the patch applies cleanly too.
Walking through the list of commits and finding enough information to
merge the patch might still be prohibitive, but at least it is something
that could be automated, and the test to see if it interesting is
cheap.
Eric
^ permalink raw reply
* Re: [PATCH] gitk: use UTF-8 encoding
From: Pavel Roskin @ 2005-10-06 5:34 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, git
In-Reply-To: <4344AF8A.1040504@zytor.com>
On Wed, 2005-10-05 at 22:00 -0700, H. Peter Anvin wrote:
> Junio C Hamano wrote:
> > Pavel Roskin <proski@gnu.org> writes:
> >
> >>gitk should try to use UTF-8 encoding for system operations, such as
> >>reading and writing files and git output.
> >
> > I agree about commit messages, but I am not so sure about the
> > file contents (aka user data). Is it possible to control them
> > separately?
Yes. "encoding convertfrom" should do the trick. In some projects,
there may be files written in different encodings, such as gettext *.po
files. A patch updating several *.po files would have different parts
in different encodings.
I think gitk could have a submenu in the popup menu with the encodings
to chose from.
> git needs to be able to treat user data as arbitrary binary blobs.
> However, if interpreting as text, UTF-8 is the right default, at least.
I agree.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] Fall back to three-way merge when applying a patch.
From: Junio C Hamano @ 2005-10-06 7:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric W. Biederman, git
In-Reply-To: <Pine.LNX.4.64.0510051909390.31407@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> ... But I doubt it works very well to rely on
> commit-level SHA1's - it's more likely to work if you try the "last few
> tagged releases etc", since patches that don't apply are often against the
> previous release (and if they don't apply there either, then it's probably
> not worth fighting over anyway).
Yes. That is the current heuristics git-applypatch in the
proposed updates branch tries to attempt. Recorded tree if
exists (which is not very interesting), last few commits, and
then tagged releases.
Ideally, if we had the path following git-rev-list you talked
about, we could first ask git-apply the set of paths the patch
touches, and instead of trying every commits from the HEAD, try
only commits that touch one (or more) of the given paths.
Another possible git-rev-list enhancement that might be useful
is to pop commits not based on time but based on the depth from
branch heads. Then we could:
git-rev-list --depth-order --max-count=$N --all \
$(git-apply --show-files $patch | sed -e 's/^[^ ]* [^ ]* //p')
to obtain list of last few commits that touch the paths
involved, in the order that is closer-to-tip first. This would
give us set of more useful commits than the current behaviour.
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: Alex Riesen @ 2005-10-06 9:05 UTC (permalink / raw)
To: Git Mailing List; +Cc: Christopher Faylor, Junio C Hamano, H. Peter Anvin
In-Reply-To: <20051005202947.GA6184@trixie.casa.cgf.cx>
[-- Attachment #1: Type: text/plain, Size: 924 bytes --]
On 10/5/05, Christopher Faylor <me@cgf.cx> wrote:
> >Don't think so, but will check in about 10 hrs. The code in question
> >is in index.c, commit_index_file.
>
> Ok. Looks pretty simple. FWIW, I've just built git on windows and I
> don't see this behavior. For the most part, it "just works".
Thanks for the hint. There are open files involved (both index.lock and index).
I attach the patch which closes index.lock (this is not really needed, btw:
rename works even without closing index.lock) and unmaps the index
(a bit too intrusive). The patch fixes only update-index.c (the one I had
problems with), there probably are other places were the situation is alike.
I don't like the patch (and win32 at all; hence the offending comment),
so use it only unless there is no other possibility to workaround.
I specifically do not request its inclusion into official branch
(even though Junio is cc'ed).
[-- Attachment #2: unmap_active_cache.patch --]
[-- Type: application/xxxxx, Size: 1998 bytes --]
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: Alex Riesen @ 2005-10-06 10:07 UTC (permalink / raw)
To: Git Mailing List; +Cc: Christopher Faylor, Junio C Hamano, H. Peter Anvin
In-Reply-To: <81b0412b0510060205v4cd510c9wb4b06a3ed9242c8@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 399 bytes --]
On 10/6/05, Alex Riesen <raa.lkml@gmail.com> wrote:
> (a bit too intrusive). The patch fixes only update-index.c (the one I had
> problems with), there probably are other places were the situation is alike.
of course there are "other places". Please, try the attached patch instead.
For the record: the patch is supposed to help people with
"Unable to write new cachefile" kind of errors.
[-- Attachment #2: unmap_active_cache.patch --]
[-- Type: application/xxxxx, Size: 3608 bytes --]
^ permalink raw reply
* Re: your mail
From: Elfyn McBratney @ 2005-10-06 10:52 UTC (permalink / raw)
To: git; +Cc: Willem Swart
In-Reply-To: <11E379B4363F884A913C18A99C40976D1F4F35@simmail.adsintranet.corp>
[-- Attachment #1: Type: text/plain, Size: 701 bytes --]
On Wed, Oct 05, 2005 at 08:10:24AM +0200, Willem Swart wrote:
> subscribe git
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
s/unsubscribe/subscribe/g
Might want to re-send that to majordomo@vger.kernel.org ;)
Best,
Elfyn
--
Elfyn McBratney
Gentoo Developer/Perl Team Lead
beu/irc.freenode.net http://dev.gentoo.org/~beu/
+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc
PGP Key ID: 0x69DF17AD
PGP Key Fingerprint:
DBD3 B756 ED58 B1B4 47B9 B3BD 8D41 E597 69DF 17AD
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Write .editmsg in GIT_DIR to avoid being in git-status.
From: Santi Bejar @ 2005-10-06 13:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6griq8d.fsf@assigned-by-dhcp.cox.net>
2005/10/5, Junio C Hamano <junkio@cox.net>:
> Santi B^[.A^[Nijar <sbejar@gmail.com> writes:
>
> > It appears in the git-status output during a git-commit if you have
> > something in info/exclude.
>
> ... which does not worry me too much; you'll get used to it ;-).
>
I'm used too, but I don't think it's a 1.0 thing.
> > Also for .cmitmsg and .cmitchk to make git-commit work
> > in read-only working trees.
>
> If a working tree is read-only, I wonder what you are committing.
>
I keep my /etc modifications in git, and I want to commit as a user not as root.
> It might not be a bad idea to think about this a bit more before
> actually coding. You are moving things out of the working tree
> root level, which is a valid thing to do when worrying about a
> repository (or working tree) that you do not have write access
> to. We've had a fix similar to this for temporary files used by
> diff commands, which moved them to $TMPDIR or something like
> that. If the working tree root level is not writable for you,
> is it valid/reasonable to assume that $GIT_DIR is? Are there
> better places? E.g. perhaps $HOME/.gittmp/?
Yes, it was just quick. I think the best way would be to write to /tmp
but honor $TMPDIR.
>
> > ret="$?"
> > -rm -f .cmitmsg .editmsg .cmitchk
> > +rm -f "$GIT_DIR"/{.cmitmsg,.editmsg,.cmitchk}
>
> Please do not do "{a,b,c}". I think ksh can grok the rest of
> the git-commit.sh code, but not this.
OK.
^ permalink raw reply
* Re: clone: I'm only doing a max of 256 requests
From: Alex Riesen @ 2005-10-06 13:41 UTC (permalink / raw)
To: git; +Cc: Andy Isaacson, Linus Torvalds, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0510051541300.31407@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 391 bytes --]
On 10/6/05, Linus Torvalds <torvalds@osdl.org> wrote:
>
> git ls-remote http://www.linux-mips.org/pub/scm/linux.git | wc -l
>
Which, btw, failed for me, when I tried to run it home (which has no
.git in it yet).
Do the scripts git-ls-remote.sh and git-parse-remote.sh really need .git/...?
Just in case they don't, the attached patch removes the die("Not a git archive")
[-- Attachment #2: git-ls-remote.patch --]
[-- Type: application/xxxxx, Size: 599 bytes --]
^ permalink raw reply
* Re: [PATCH] Fall back to three-way merge when applying a patch.
From: Linus Torvalds @ 2005-10-06 14:35 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Junio C Hamano, git
In-Reply-To: <m1y8575i9y.fsf@ebiederm.dsl.xmission.com>
On Wed, 5 Oct 2005, Eric W. Biederman wrote:
>
> Ah. I had missed that git-whatchanged can be given a filename that is
> nice. One of the better kept secrets of git. That makes my whole
> question worthwhile :)
That's definitely not a secret - it was part of the whole point of
git-whatchanged. It's the native git version of "annotate", and I
personally find it much more useful.
It's not even just a filename. You can do
git-whatchanged -p drivers/scsi/ include/scsi
to limit the set to those two subdirectories. IOW, you can give
git-whatchanged an arbitrary list of individual pathnames or directory
names.
> But if you happen to have at least the file level sha1 you can
> actually know if the patch was against what you think it is against.
Yes, a file-level SHA1 may be useful. On the other hand, I suspect that by
that time (since you have to search for the version anyway) you might as
well have the "just try to apply the patch" approach. It's basically the
same search space.
Linus
^ permalink raw reply
* Re: clone: I'm only doing a max of 256 requests
From: Linus Torvalds @ 2005-10-06 14:39 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Andy Isaacson, Junio C Hamano
In-Reply-To: <81b0412b0510060641g3a3c6e02m6827370dd61b5ea6@mail.gmail.com>
On Thu, 6 Oct 2005, Alex Riesen wrote:
> On 10/6/05, Linus Torvalds <torvalds@osdl.org> wrote:
> >
> > git ls-remote http://www.linux-mips.org/pub/scm/linux.git | wc -l
> >
>
> Which, btw, failed for me, when I tried to run it home (which has no
> .git in it yet). Do the scripts git-ls-remote.sh and git-parse-remote.sh
> really need .git/...?
Good point. No they don't. You should be able to run "git ls-remote"
outside of a local git directory.
> Just in case they don't, the attached patch removes the die("Not a git archive")
Junio, please apply.
(It still wants the "git-sh-setup" part if only because it uses "die()" in
another place).
Linus
^ permalink raw reply
* Re: [PATCH] Fall back to three-way merge when applying a patch.
From: Eric W. Biederman @ 2005-10-06 14:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0510060731560.31407@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Wed, 5 Oct 2005, Eric W. Biederman wrote:
>>
>> Ah. I had missed that git-whatchanged can be given a filename that is
>> nice. One of the better kept secrets of git. That makes my whole
>> question worthwhile :)
>
> That's definitely not a secret - it was part of the whole point of
> git-whatchanged. It's the native git version of "annotate", and I
> personally find it much more useful.
>
> It's not even just a filename. You can do
>
> git-whatchanged -p drivers/scsi/ include/scsi
>
> to limit the set to those two subdirectories. IOW, you can give
> git-whatchanged an arbitrary list of individual pathnames or directory
> names.
Which probably means it's time for me to generate a patch to the
git-whatchanged documentation.
>> But if you happen to have at least the file level sha1 you can
>> actually know if the patch was against what you think it is against.
>
> Yes, a file-level SHA1 may be useful. On the other hand, I suspect that by
> that time (since you have to search for the version anyway) you might as
> well have the "just try to apply the patch" approach. It's basically the
> same search space.
Maybe.
After thinking about it I don't think you need to look through the
history to use it for a merge3 operation. As I recall merge3 only
looks at the base and the two derived versions of the file. If we
have the sha1 of the original in the git repository I think all we
need to compute is the diff between that sha1 the current version
file. And then apply the merge3 algorithm to combine the two sets of
changes.
Eric
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox