* [PATCH 4/7] "stg series" option to show patch summary descriptions
From: Chuck Lever @ 2005-11-29 22:09 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
In-Reply-To: <20051129220552.9885.41086.stgit@dexter.citi.umich.edu>
Optionally show each patch's short description when listing a series.
Signed-off-by: Chuck Lever <cel@netapp.com>
---
stgit/commands/series.py | 48 +++++++++++++++++++++++++++++++---------------
1 files changed, 32 insertions(+), 16 deletions(-)
diff --git a/stgit/commands/series.py b/stgit/commands/series.py
index 032b89e..a843307 100644
--- a/stgit/commands/series.py
+++ b/stgit/commands/series.py
@@ -33,12 +33,31 @@ prefixed with a '>'. Empty patches are p
options = [make_option('-b', '--branch',
help = 'use BRANCH instead of the default one'),
+ make_option('-d', '--description',
+ help = 'show a show description for each patch',
+ action = 'store_true'),
make_option('-e', '--empty',
help = 'check whether patches are empty '
'(much slower)',
action = 'store_true') ]
+def __get_description(patch):
+ """Extract and return a patch's short description
+ """
+ p = crt_series.get_patch(patch)
+ descr = p.get_description().strip()
+ descr_lines = descr.split('\n')
+ return descr_lines[0].rstrip()
+
+def __print_patch(patch, prefix, empty_prefix, length, options):
+ if options.empty and crt_series.empty_patch(patch):
+ prefix = empty_prefix
+ if options.description:
+ print prefix + patch.ljust(length) + ' | ' + __get_description(patch)
+ else:
+ print prefix + patch
+
def func(parser, options, args):
"""Show the patch series
"""
@@ -46,21 +65,18 @@ def func(parser, options, args):
parser.error('incorrect number of arguments')
applied = crt_series.get_applied()
+ unapplied = crt_series.get_unapplied()
+ patches = applied + unapplied
+
+ max_len = 0
+ if len(patches) > 0:
+ max_len = max([len(i) for i in patches])
+
if len(applied) > 0:
for p in applied [0:-1]:
- if options.empty and crt_series.empty_patch(p):
- print '0', p
- else:
- print '+', p
- p = applied[-1]
-
- if options.empty and crt_series.empty_patch(p):
- print '0>%s' % p
- else:
- print '> %s' % p
-
- for p in crt_series.get_unapplied():
- if options.empty and crt_series.empty_patch(p):
- print '0', p
- else:
- print '-', p
+ __print_patch(p, '+ ', '0 ', max_len, options)
+
+ __print_patch(applied[-1], '> ', '0>', max_len, options)
+
+ for p in unapplied:
+ __print_patch(p, '- ', '0 ', max_len, options)
^ permalink raw reply related
* [PATCH 1/7] Make "stg export" save the base commit in the output directory
From: Chuck Lever @ 2005-11-29 22:09 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
In-Reply-To: <20051129220552.9885.41086.stgit@dexter.citi.umich.edu>
When trying to apply a series of diffs that was exported from an StGIT
series, it can be convenient to know exactly which base commit the
patches apply to. Save that commit in a file patchdir/base.
Signed-off-by: Chuck Lever <cel@netapp.com>
---
stgit/commands/export.py | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/stgit/commands/export.py b/stgit/commands/export.py
index 0ef7d07..167a8d3 100644
--- a/stgit/commands/export.py
+++ b/stgit/commands/export.py
@@ -141,6 +141,10 @@ def func(parser, options, args):
tmpl = file(patch_tmpl).read()
break
+ # note the base commit for this series
+ write_string(os.path.join(dirname, 'base'), \
+ crt_series.get_patch(patches[0]).get_bottom())
+
patch_no = 1;
for p in patches:
pname = p
^ permalink raw reply related
* [PATCH 3/7] Align branch descriptions in output of "stg branch -l"
From: Chuck Lever @ 2005-11-29 22:09 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
In-Reply-To: <20051129220552.9885.41086.stgit@dexter.citi.umich.edu>
When printing branch descriptions, start descriptions in the same column.
Signed-off-by: Chuck Lever <cel@netapp.com>
---
stgit/commands/branch.py | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/stgit/commands/branch.py b/stgit/commands/branch.py
index c3f7944..ccf1f6b 100644
--- a/stgit/commands/branch.py
+++ b/stgit/commands/branch.py
@@ -63,7 +63,7 @@ options = [make_option('-c', '--create',
def __is_current_branch(branch_name):
return crt_series.get_branch() == branch_name
-def __print_branch(branch_name):
+def __print_branch(branch_name, length):
initialized = ' '
current = ' '
protected = ' '
@@ -76,8 +76,8 @@ def __print_branch(branch_name):
current = '>'
if branch.get_protected():
protected = 'p'
- print '%s %s%s\t%s\t%s' % (current, initialized, protected, branch_name, \
- branch.get_description())
+ print current + ' ' + initialized + protected + '\t' + \
+ branch_name.ljust(length) + ' | ' + branch.get_description()
def __delete_branch(doomed_name, force = False):
doomed = stack.Series(doomed_name)
@@ -138,10 +138,11 @@ def func(parser, options, args):
branches = os.listdir(os.path.join(git.get_base_dir(), 'refs', 'heads'))
branches.sort()
+ max_len = max([len(i) for i in branches])
print 'Available branches:'
for i in branches:
- __print_branch(i)
+ __print_branch(i, max_len)
return
elif options.protect:
^ permalink raw reply related
* [PATCH 5/7] Add facility to print short list of patches around 'top'
From: Chuck Lever @ 2005-11-29 22:09 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
In-Reply-To: <20051129220552.9885.41086.stgit@dexter.citi.umich.edu>
When working in the middle of a very long series, I often find it useful
to have a list of the patches right around the current patch. Add an
option to "stg series" called "--short" to provide this short list.
Signed-off-by: Chuck Lever <cel@netapp.com>
---
stgit/commands/series.py | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/stgit/commands/series.py b/stgit/commands/series.py
index a843307..ec1aaaf 100644
--- a/stgit/commands/series.py
+++ b/stgit/commands/series.py
@@ -39,6 +39,9 @@ options = [make_option('-b', '--branch',
make_option('-e', '--empty',
help = 'check whether patches are empty '
'(much slower)',
+ action = 'store_true'),
+ make_option('-s', '--short',
+ help = 'list just the patches around the topmost patch',
action = 'store_true') ]
@@ -66,6 +69,13 @@ def func(parser, options, args):
applied = crt_series.get_applied()
unapplied = crt_series.get_unapplied()
+
+ if options.short:
+ if len(applied) > 5:
+ applied = applied[-6:]
+ if len(unapplied) > 5:
+ unapplied = unapplied[:5]
+
patches = applied + unapplied
max_len = 0
^ permalink raw reply related
* [PATCH 0/7]
From: Chuck Lever @ 2005-11-29 22:05 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
These are road-tested and ready for your review.
+ export-saves-base | Make "stg export" save the base commit in the output directory
+ stg-in-subdirectories | Use git-rev-parse to find the local GIT repository
+ fix-branch-description | Align branch descriptions in output of "stg branch -l"
+ stg-series-description | "stg series" option to show patch summary descriptions
+ stg-series-short | Add facility to print short list of patches around 'top'
+ stg-branch-clone | Add a "--clone" option to "stg branch"
> series-directory | Use a separate directory for patches under each branch subdir
Before 0.8, you might also consider addressing the patch authorship issues
that come up when mailing out patches, as discussed on git@vger last week.
I've adjusted my patchmail.tmpl file as a workaround.
-- Chuck Lever
--
corporate: <cel at netapp dot com>
personal: <chucklever at bigfoot dot com>
^ permalink raw reply
* Re: [PATCH] Re: keeping remote repo checked out?
From: Daniel Barkalow @ 2005-11-29 21:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis, Linus Torvalds
In-Reply-To: <7vk6erfe3o.fsf@assigned-by-dhcp.cox.net>
On Tue, 29 Nov 2005, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > This seems maximally inconvenient. If you lose a race, you only find out
> > later, your reception branch is screwed up, and you have no way of finding
> > out in advance that this is going to happen?
>
> I am not sure what you mean by "your reception branch is screwed
> up". We _could_ rewind that reception branch after acceptance
> test fails but I did not mention that because I haven't thought
> it through.
>
> This was actually designed to reduce the chance of getting a
> race in the first place, so I am not sure if it makes things
> inconvenient.
>
> Alice and Bob starts out from the central repository commit O
> (for origin), and make progress independently. They have one
> commit on top of O each, A and B where A~1 === O and B~1 === O.
>
> Alice pushes first, the central repository has O and accepts
> because updating from O to A is a fast forward. Bob tries to
> push, and in the classic CVS-style shared repository setup in
> the tutorial, this is prevented because this is not a fast
> forward. Bob needs to first pull and merge A and B to create C
> (C^1 === B, C^2 === A) and push that. This succeeds.
>
> Instead, the approach allows you to choose to do the merge on
> the server side unattended, as part of the acceptance check.
>
> Alice pushes, and both her reception branch and the reception
> repository master becomes A (fast forward). When Bob pushes B
> to his reception branch, we attempt to pull it into reception
> repository master --- we do not have to fail this pull even if
> it is not a fast forward (we could choose to fail it). reception
> repository master becomes C which is a merge between A and B.
If the merge works automatically, then Bob can do it without any trouble.
If it doesn't work automatically, then Bob has to do it. But if Bob might
have to do a merge, he can't leave for the day until his commit has gone
all the way through, in which case he might as well do any merges while he
waits. In my mind, the critical issue for developers is time to success or
failure, and that's longer in your scheme. Perhaps a better idea is to
have a script on Bob's end react to failure of the push (due to not being
a fast-forward) by automatically pulling the thing that it's supposed to
merge with, and push again if it worked. (If it failed, Bob fixes it, and
then pushes again.)
> The result of this automerge needs to be checked for sanity, so
> before this C (new reception repository master) is pulled into
> the deployment repository, there is a validation step (this step
> can do things other than validation; e.g. making tarballs for
> distribution, automatic tagging). While all that is happening,
> other people can be pushing into their own reception branches,
> waiting for their turn. And we guarantee that what is moved to
> the deployment repository has been tested "clean" (depending on
> the quality of test, that is).
>
> If the central repository acceptance policy is simple enough,
> namely, if it takes whatever an individiual developer with push
> access says is good at the face value, then we do not need any
> of the above, and a simple "fast forward only" is good enough,
> far simpler to explain and understand.
>
> On the other hand, at places where management already has rules
> that require any update to the central repository to first pass
> a test suite, the acceptance test can take time to complete ---
> which enlarges the race window --- and more importantly when a
> push that passed a simple "fast forward only" rule fails, we
> somehow need to prevent that failed head from leaking out to the
> public. That is cumbersome to arrange if we only use a single
> reception branch.
I think the right thing is to only allow pushes after something passes
testing, probably be having people push to tags, which the test server
tests and then pushes to the common upstream. The developers have to wait
for the testing, but can go home when that passes.
I think there is the possibility for something really clever where, when
you try to submit, if there's something in the testing area, it rejects
you, you merge with the thing in the testing area, wait for the test ahead
of you to complete, and submit either the merge (if the previous thing
passed) or your original (if the previous thing failed). That way, you can
overlap the time that you spend waiting for the test farm to be free with
the time you spend merging against things that are getting in ahead of
you. (Of course, if the merge with the testing thing isn't automatic, you
might cancel it and do something else until you know whether that thing
will be rejected.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: linux @ 2005-11-29 21:40 UTC (permalink / raw)
To: junkio, pasky; +Cc: git, linux
In-Reply-To: <20051129103157.GW22159@pasky.or.cz>
I'm feeling slightly guilty about eliciting such a flood of help, but I'm
certainly leraning a lot. But there's one statement that, while I'm not
doubting it's accuracy, seems at odds with the mental model I'm building.
I must be misunderstanding something.
junkio wrote:
>> Okay, so git-update-index will overwrite a staged file with a
>> fresh stage-0 copy. And git-commit will refuse to commit
>> (to be precise, it'll stop at the git-write-tree stage) if there
>> are unresolved conflicts.
>
> Sorry, I was unclear that I was talking about end-user level
> tool. The update-index here is not about the conflict
> resolution in the index file read-tree documentation talks
> about. That has already been done when "merge" ran in the
> conflicting case. In the conflicting case, the working tree
> holds 3-way merge conflicting result, and the index holds HEAD
> version at stage0 for such a path. Hand resolving after
> update-index is to record what you eventually want to commit
> (i.e. you are not replacing higher stage entry in the index with
> stage0 entry -- you are replacing stage0 entry with another).
>
>> If you want to see the unmodified input files, you can find their
>> IDs with "git-ls-files -u" and then get a copy with "git-cat-file blob"
>> or "git-unpack-file". git-merge-index is basically a different way to
>> process the output of git-ls-files -u.
>
> Yes, in principle. But in practice you usually do not use these
> low level tools yourself. When git-merge returns with
> conflicting paths, most of them have already been collapsed into
> stage0 and git-ls-files --unmerged would not show. The only
> case I know of that you may still see higher stage entries in
> the index these days is merging paths with different mode bits.
> We used to leave higher stage entries when both sides added new
> file at the same path, but even that we show as merge from
> common these days.
And pasky reiterated:
> From the user POV, the main difference between Cogito and GIT merging
> is that:
>
> (i) Cogito tries to never leave the index "dirty" (i.e. containing
> unmerged entries), and instead all conflicts should propagate to the
> working tree, so that the user can resolve them without any further
> special tools. (What is lacking here is that Cogito won't proofcheck
> that you really resolved them all during a commit. That's a big TODO.
> But core GIT won't you warn about committing the classical << >> ==
> conflicts either.)
This seems odd to me. There's an alternate implementation that
I described that makes a lot more sense to me, based on my current
state of knowledge. Can someone explain why my idea is silly?
I'd imagine you'd consider user editing to be a last-resort merge
algorithm, but treat it like the other merges, and leave the file
staged while it's in progress.
Either git-checkout-index or something similar would "check out"
the staged file with CVS-style merge markers. And an eventual
git-update-index would replace the staged file with a stage-0,
just like git-merge-one-file does automatically.
"git-diff" could default to diffing against the stage-2 file to
produce the same reults as now, but you could also have an
option to diff against a different stage, which might be useful.
(This is another reason for my earlier comment that I don't think
the distinction between stage-0 and stage-2 is actually necessary.)
And git-write-tree would naturally stop you from committing with
unresolved conflicts. You could still commit the conflict
markers, but it would be a two-step process.
You'd have the simple principle that all merges start with git-read-tree
producing a staged file, and end with git-update-index collapsing
them when it's been resolved. (Or something like git-reset throwing
everything away.)
Having said all this, there's presumably a good reason why this is a
bad idea. Could someone enlighten me?
Thanks!
^ permalink raw reply
* [PATCH] gitk: add Update menu item.
From: Sven Verdoolaege @ 2005-11-29 21:15 UTC (permalink / raw)
To: Paul Mackerras, Junio C Hamano; +Cc: git
In-Reply-To: <20051123222003.GA16290MdfPADPa@greensroom.kotnet.org>
Update will redraw the commits if any commits have been added to any
of the selected heads. The new commits appear on the top.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
---
Junio noticed that my patch didn't work if you use path specifiers.
This update should fix this problem.
skimo
gitk | 176 +++++++++++++++++++++++++++++++++++++++++++++++++++++-------------
1 files changed, 142 insertions(+), 34 deletions(-)
applies-to: 4000f8b8d01ad35929972c07d98d89e2280cf3d3
f24c2e402dd592f5bd5047724da30a8a5e0115eb
diff --git a/gitk b/gitk
index 730ffd9..de5c8b1 100755
--- a/gitk
+++ b/gitk
@@ -16,8 +16,24 @@ proc gitdir {} {
}
}
+proc parse_args {rargs} {
+ global parsed_args
+
+ if [catch {
+ set parse_args [concat --default HEAD $rargs]
+ set parsed_args [split [eval exec git-rev-parse $parse_args] "\n"]
+ }] {
+ # if git-rev-parse failed for some reason...
+ if {$rargs == {}} {
+ set rargs HEAD
+ }
+ set parsed_args $rargs
+ }
+ return $parsed_args
+}
+
proc getcommits {rargs} {
- global commits commfd phase canv mainfont env
+ global oldcommits commits commfd phase canv mainfont env
global startmsecs nextupdate ncmupdate
global ctext maincursor textcursor leftover gitencoding
@@ -27,21 +43,13 @@ proc getcommits {rargs} {
error_popup "Cannot find the git directory \"$gitdir\"."
exit 1
}
+ set oldcommits {}
set commits {}
set phase getcommits
set startmsecs [clock clicks -milliseconds]
set nextupdate [expr {$startmsecs + 100}]
set ncmupdate 1
- if [catch {
- set parse_args [concat --default HEAD $rargs]
- set parsed_args [split [eval exec git-rev-parse $parse_args] "\n"]
- }] {
- # if git-rev-parse failed for some reason...
- if {$rargs == {}} {
- set rargs HEAD
- }
- set parsed_args $rargs
- }
+ set parsed_args [parse_args $rargs]
if [catch {
set commfd [open "|git-rev-list --header --topo-order --parents $parsed_args" r]
} err] {
@@ -59,9 +67,10 @@ proc getcommits {rargs} {
}
proc getcommitlines {commfd} {
- global commits parents cdate children
+ global oldcommits commits parents cdate children nchildren
global commitlisted phase nextupdate
global stopped redisplaying leftover
+ global canv
set stuff [read $commfd]
if {$stuff == {}} {
@@ -119,10 +128,18 @@ proc getcommitlines {commfd} {
set id [lindex $ids 0]
set olds [lrange $ids 1 end]
set cmit [string range $cmit [expr {$j + 1}] end]
+ if {$phase == "updatecommits"} {
+ $canv delete all
+ set oldcommits $commits
+ set commits {}
+ unset children
+ unset nchildren
+ set phase getcommits
+ }
lappend commits $id
set commitlisted($id) 1
parsecommit $id $cmit 1 [lrange $ids 1 end]
- drawcommit $id
+ drawcommit $id 1
if {[clock clicks -milliseconds] >= $nextupdate} {
doupdate 1
}
@@ -132,7 +149,7 @@ proc getcommitlines {commfd} {
set stopped 0
set phase "getcommits"
foreach id $commits {
- drawcommit $id
+ drawcommit $id 1
if {$stopped} break
if {[clock clicks -milliseconds] >= $nextupdate} {
doupdate 1
@@ -168,16 +185,9 @@ proc readcommit {id} {
parsecommit $id $contents 0 {}
}
-proc parsecommit {id contents listed olds} {
- global commitinfo children nchildren parents nparents cdate ncleft
+proc updatechildren {id olds} {
+ global children nchildren parents nparents ncleft
- set inhdr 1
- set comment {}
- set headline {}
- set auname {}
- set audate {}
- set comname {}
- set comdate {}
if {![info exists nchildren($id)]} {
set children($id) {}
set nchildren($id) 0
@@ -196,6 +206,19 @@ proc parsecommit {id contents listed old
incr ncleft($p)
}
}
+}
+
+proc parsecommit {id contents listed olds} {
+ global commitinfo cdate
+
+ set inhdr 1
+ set comment {}
+ set headline {}
+ set auname {}
+ set audate {}
+ set comname {}
+ set comdate {}
+ updatechildren $id $olds
set hdrend [string first "\n\n" $contents]
if {$hdrend < 0} {
# should never happen...
@@ -243,6 +266,9 @@ proc readrefs {} {
global tagids idtags headids idheads tagcontents
global otherrefids idotherrefs
+ foreach v {tagids idtags headids idheads otherrefids idotherrefs} {
+ catch {unset $v}
+ }
set refd [open [list | git-ls-remote [gitdir]] r]
while {0 <= [set n [gets $refd line]]} {
if {![regexp {^([0-9a-f]{40}) refs/([^^]*)$} $line \
@@ -292,7 +318,7 @@ proc error_popup msg {
tkwait window $w
}
-proc makewindow {} {
+proc makewindow {rargs} {
global canv canv2 canv3 linespc charspc ctext cflist textfont
global findtype findtypemenu findloc findstring fstring geometry
global entries sha1entry sha1string sha1but
@@ -302,6 +328,7 @@ proc makewindow {} {
menu .bar
.bar add cascade -label "File" -menu .bar.file
menu .bar.file
+ .bar.file add command -label "Update" -command [list updatecommits $rargs]
.bar.file add command -label "Reread references" -command rereadrefs
.bar.file add command -label "Quit" -command doquit
menu .bar.help
@@ -1416,8 +1443,9 @@ proc decidenext {{noread 0}} {
return $level
}
-proc drawcommit {id} {
+proc drawcommit {id reading} {
global phase todo nchildren datemode nextupdate revlistorder
+ global numcommits ncmupdate displayorder todo onscreen
global numcommits ncmupdate displayorder todo onscreen parents
if {$phase != "incrdraw"} {
@@ -1455,20 +1483,29 @@ proc drawcommit {id} {
}
}
}
- drawmore 1
+ drawmore $reading
}
proc finishcommits {} {
- global phase
+ global phase oldcommits commits
global canv mainfont ctext maincursor textcursor
+ global parents
- if {$phase != "incrdraw"} {
+ if {$phase == "incrdraw" || $phase == "removecommits"} {
+ foreach id $oldcommits {
+ lappend commits $id
+ updatechildren $id $parents($id)
+ drawcommit $id 0
+ }
+ set oldcommits {}
+ drawrest
+ } elseif {$phase == "updatecommits"} {
+ set phase {}
+ } else {
$canv delete all
$canv create text 3 3 -anchor nw -text "No commits selected" \
-font $mainfont -tags textitems
set phase {}
- } else {
- drawrest
}
. config -cursor $maincursor
settextcursor $textcursor
@@ -3595,9 +3632,6 @@ proc rereadrefs {} {
set ref($id) [listrefs $id]
}
}
- foreach v {tagids idtags headids idheads otherrefids idotherrefs} {
- catch {unset $v}
- }
readrefs
set refids [lsort -unique [concat $refids [array names idtags] \
[array names idheads] [array names idotherrefs]]]
@@ -3609,6 +3643,80 @@ proc rereadrefs {} {
}
}
+proc updatecommits {rargs} {
+ global commitlisted commfd phase
+ global startmsecs nextupdate ncmupdate
+ global idtags idheads idotherrefs
+ global leftover
+ global parsed_args
+ global canv
+ global oldcommits commits
+ global parents nchildren children ncleft
+
+ set old_args $parsed_args
+ parse_args $rargs
+
+ foreach id $old_args {
+ if {![regexp {^[0-9a-f]{40}$} $id]} continue
+ if {[info exists oldref($id)]} continue
+ set oldref($id) $id
+ lappend ignoreold "^$id"
+ }
+ foreach id $parsed_args {
+ if {![regexp {^[0-9a-f]{40}$} $id]} continue
+ if {[info exists ref($id)]} continue
+ set ref($id) $id
+ lappend ignorenew "^$id"
+ }
+
+ foreach a $old_args {
+ if {![info exists ref($a)]} {
+ lappend ignorenew $a
+ }
+ }
+
+ set phase updatecommits
+ set removed_commits [split [eval exec git-rev-list $ignorenew] "\n" ]
+ if {[llength $removed_commits] > 0} {
+ $canv delete all
+ set oldcommits {}
+ foreach c $commits {
+ if {[lsearch $c $removed_commits] < 0} {
+ lappend oldcommits $c
+ } else {
+ unset commitlisted($c)
+ }
+ }
+ set commits {}
+ unset children
+ unset nchildren
+ set phase removecommits
+ }
+
+ set args {}
+ foreach a $parsed_args {
+ if {![info exists oldref($a)]} {
+ lappend args $a
+ }
+ }
+
+ readrefs
+ if [catch {
+ set commfd [open "|git-rev-list --header --topo-order --parents $ignoreold $args" r]
+ } err] {
+ puts stderr "Error executing git-rev-list: $err"
+ exit 1
+ }
+ set startmsecs [clock clicks -milliseconds]
+ set nextupdate [expr $startmsecs + 100]
+ set ncmupdate 1
+ set leftover {}
+ fconfigure $commfd -blocking 0 -translation lf
+ fileevent $commfd readable [list getcommitlines $commfd]
+ . config -cursor watch
+ settextcursor watch
+}
+
proc showtag {tag isnew} {
global ctext cflist tagcontents tagids linknum
@@ -3704,6 +3812,6 @@ set redisplaying 0
set stuffsaved 0
set patchnum 0
setcoords
-makewindow
+makewindow $revtreeargs
readrefs
getcommits $revtreeargs
---
0.99.9.GIT
^ permalink raw reply related
* Re: Question about handling of heterogeneous repositories
From: Alex Riesen @ 2005-11-29 20:47 UTC (permalink / raw)
To: Petr Baudis, Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <20051127131147.GF22159@pasky.or.cz>
Petr Baudis, Sun, Nov 27, 2005 14:11:47 +0100:
> > > >For everyone who have an experience with ClearCase or Perforce (I'm
> > > >sorry for mentioning it) it is what the "mappings" are often used for:
> > > >a project is build together from different parts, which can be worked
> > > >on separately.
> > > >
> > > >I'm trying to introduce git at work, but have to prepare myself for
> > > >possible questions first, and this is one of them :)
>
> This is something e.g. Cogito wants to support, but does not yet.
> Patches welcome.
I wouldn't know what to patch, having no clear picture of the approach
myself, and especially when I don't feel safe using the solution. For
example, how do you go about moving/renaming files between subrepos?
Rename detection will not work, which will be unexpected...
BTW, how does git-mv behave for out-of-tree renaming? How about
inter-repo renaming (remove+add)?
> > > It would certainly be nicer to have git ignore directories that have the
> > > ".git" directory (so long as it's not the top of the repo, that is), but
> > > I haven't had the energy to fix that when there's already a solution
> > > that's simple enough and quite adequate.
> >
> > BTW, will something like "*/.git/*" in info/exclude work? IOW, does *
> > match a "/"?
>
> Nope, but try just '.git' - in case it is not a pathname but just a
> filename (or dirname, for that matter), it will recursively apply to all
> the subtrees.
well, it ignored the ".git"s in the subdirs, not _the_ subdirectories.
I think that can be helped by putting the directories themselves into
.gitignore lists.
^ permalink raw reply
* Re: [PATCH] SVN import: Use one log call
From: Junio C Hamano @ 2005-11-29 20:22 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.11.29.07.13.02.145977@smurf.noris.de>
Matthias Urlichs <smurf@smurf.noris.de> writes:
> One "svn log" (or its equivalent) per revision adds delay and server load.
> Instead, open two SVN connections -- one for the log, and one for the files.
Thanks, applied and pushed out.
BTW, I've never successfully managed to run svnimport from my
private svn repository. Admittedly the repository does not
follow the recommended layout and that probably is the major
cause (it started its life when svn documentation recommended
{trunk,branches,tags}/{projectA,projectB,projectC} layout.
{projectA,projectB,projectC}/{trunk,branches,tags} is the layout
they recommend these days, I think [*1*]).
It does not use any branches (it is primarily a random
collection of small throwaway scripts). The repository hosts
many unrelated pieces ("http://127.0.0.1/svn/private/" is the
root level of the repository), organized like this:
$ svn ls http://127.0.0.1/svn/private/
attic/
main/
tags/
main/ is the active one (trunk), and it has bunch of
unrelated subdirectories.
attic/ is where I prepared to "svn mv" things from main/ that
are no longer needed, but is empty.
tags/ have one tree that is a copy of one of the subtrees
under main/ from distant past.
I wanted to convert one of the subsubdirectory of main to git.
$ svn ls http://127.0.0.1/svn/private/main/sources/photocat
Makefile
Notes
cmdmason.pm
...
What is the svnimport command line I should give? Luckily, I do
not have "tags" or "branches" under private/main/sources/, so I
tried to cheat like this, hoping it would mistake "photocat" is the trunk of
"main/sources" project in the repository. No such luck.
$ cd /var/tmp && rm -fr try0 && mkdir try0 && cd try0
$ git svnimport -v -i -t photocat http://127.0.0.1/svn/private main/sources
1: Unrecognized path: /main/sources
1: Unrecognized path: /main/in-place
1: Unrecognized path: /main
...
1500: Unrecognized path: /main/sources/photocat/db/catalog.sql
1501: Unrecognized path: /main/sources/photocat/data/035-maribon-making.yaml
DONE; creating master branch
cp: cannot stat `/var/tmp/try0/.git/refs/heads/origin': No such file or directory
fatal: master: not a valid SHA1
$
If your answer is "your repository layout is too weird and
nonstandard, you are screwed", that is perfectly fine. I do not
want you to bend over backwards to butcher the import script to
support it, if it is too nonstandard. I already converted what
I wanted to convert manually already; history being linear
without branches, that was easy enough.
But I thought it would never hurt to ask ;-).
[Footnote]
*1*
http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-5-sect-6.1
shows two layouts, one with {trunk,tags,branches} at the top
level of each project, another with nested projects (if you look
at "utils" in the picture as a project with two subcomponents
"calc" and "calendar"), with {trunk,tags,branches} under each
subproject. I think the current code should import from
"calendar" or "calc" level just fine, but I wonder if we want to
support importing from "utils" level.
^ permalink raw reply
* Re: [PATCH] Re: keeping remote repo checked out?
From: Junio C Hamano @ 2005-11-29 19:28 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Petr Baudis, Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0511291157260.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> This seems maximally inconvenient. If you lose a race, you only find out
> later, your reception branch is screwed up, and you have no way of finding
> out in advance that this is going to happen?
I am not sure what you mean by "your reception branch is screwed
up". We _could_ rewind that reception branch after acceptance
test fails but I did not mention that because I haven't thought
it through.
This was actually designed to reduce the chance of getting a
race in the first place, so I am not sure if it makes things
inconvenient.
Alice and Bob starts out from the central repository commit O
(for origin), and make progress independently. They have one
commit on top of O each, A and B where A~1 === O and B~1 === O.
Alice pushes first, the central repository has O and accepts
because updating from O to A is a fast forward. Bob tries to
push, and in the classic CVS-style shared repository setup in
the tutorial, this is prevented because this is not a fast
forward. Bob needs to first pull and merge A and B to create C
(C^1 === B, C^2 === A) and push that. This succeeds.
Instead, the approach allows you to choose to do the merge on
the server side unattended, as part of the acceptance check.
Alice pushes, and both her reception branch and the reception
repository master becomes A (fast forward). When Bob pushes B
to his reception branch, we attempt to pull it into reception
repository master --- we do not have to fail this pull even if
it is not a fast forward (we could choose to fail it). reception
repository master becomes C which is a merge between A and B.
The result of this automerge needs to be checked for sanity, so
before this C (new reception repository master) is pulled into
the deployment repository, there is a validation step (this step
can do things other than validation; e.g. making tarballs for
distribution, automatic tagging). While all that is happening,
other people can be pushing into their own reception branches,
waiting for their turn. And we guarantee that what is moved to
the deployment repository has been tested "clean" (depending on
the quality of test, that is).
If the central repository acceptance policy is simple enough,
namely, if it takes whatever an individiual developer with push
access says is good at the face value, then we do not need any
of the above, and a simple "fast forward only" is good enough,
far simpler to explain and understand.
On the other hand, at places where management already has rules
that require any update to the central repository to first pass
a test suite, the acceptance test can take time to complete ---
which enlarges the race window --- and more importantly when a
push that passed a simple "fast forward only" rule fails, we
somehow need to prevent that failed head from leaking out to the
public. That is cumbersome to arrange if we only use a single
reception branch.
In case it was not obvious, the reception repository is meant to
be push-only, and all the fetching for public consumption are
meant to happen from the deployed repository "master". Most
importantly, reception branches in reception repository are not
to be pulled by individual developers.
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: Junio C Hamano @ 2005-11-29 18:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: linux, junkio, git
In-Reply-To: <20051129103157.GW22159@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> (ii) Cogito will handle trees with some local modifications better -
> basically any local modifications git-read-tree -m won't care about.
> I didn't read the whole conversation, so to reiterate: git-read-tree
> will complain when the index does not match the HEAD, but won't
> complain about modified files in the working tree if the merge is not
> going to touch them. Now, let's say you do this (output is visually
> only roughly or not at all resembling what would real tools tell you):
>
> $ ls
> a b c
> $ echo 'somelocalhack' >>a
> $ git merge "blah" HEAD remotehead
> File-level merge of 'b' and 'c'...
> Oops, 'b' contained local conflicts.
> Automatic merge aborted, fix up by hand.
> $ fixup b
> $ git commit
> Committed files 'a', 'b', 'c'.
>
> Oops. It grabbed your local hack and committed it along the merge.
Are you sure about this?
In the above sequence, after you touch a with 'somelocalhack',
there is no 'git update-index a', until you say 'git commit'
there, so I do not think that mixup is possible.
The "fixup b" step is actually two commands, so after merge
command, you would do:
$ edit b
$ git update-index b ;# mark that you are dealt with it
$ git commit ;# commits what is in index
After the above steps, "git diff" (that is working tree against
index) still reports your local change to "a", which were _not_
committed.
Maybe you were mistaken because Cogito tries to be nice to its
users and always does a moral equivalent of "git commit -a"
(unless the user tells you to commit only specific paths), but
you needed to special case merge resolution commit to make sure
that you exclude "a" in the above example? "git commit" does
not do "-a" by default, and it will stay that way, so I do not
think we do not have the "Oops" you described above.
"Oops" would happen only if you did "git commit -a" instead at
the last step.
^ permalink raw reply
* [PATCH] http-push cleanup
From: Nick Hengeveld @ 2005-11-29 17:33 UTC (permalink / raw)
To: git
The malloc patch from Jan Andres fixed the problem that was causing a
segfault when freeing the lock token, and Johannes Schindelin found
and fixed a problem when no URL is specified on the command line.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http-push.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
applies-to: 39ddd76c46b92ac971b2325acf9efecf443fbe6b
1510a5b7deec93abcf010aa867adf27ad7750293
diff --git a/http-push.c b/http-push.c
index bbb5118..56c2bb5 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1009,9 +1009,7 @@ static int unlock_remote(struct active_l
if (lock->owner != NULL)
free(lock->owner);
free(lock->url);
-/* Freeing the token causes a segfault...
free(lock->token);
-*/
free(lock);
return rc;
@@ -1274,6 +1272,9 @@ int main(int argc, char **argv)
break;
}
+ if (!remote->url)
+ usage(http_push_usage);
+
memset(remote_dir_exists, 0, 256);
http_init();
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] Re: keeping remote repo checked out?
From: Junio C Hamano @ 2005-11-29 17:31 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.11.29.13.39.01.958465@smurf.noris.de>
Matthias Urlichs <smurf@smurf.noris.de> writes:
> Hi, Junio C Hamano wrote:
>
>> When everything goes well, the daemon goes to treeP and pulls
>> from treeR's master into "deploy", which is checked out.
>
> Why do you need a separate tree for that? -EOVERKILL.
Yes that is overkill, but treeR is used for merge and the scheme
allows that merge to be real merge not just fast forwards ---
you need a checked out tree for that. We can use multiple
checked out tree sharing the same .git/ directory with separate
index files instead.
^ permalink raw reply
* Re: [PATCH] Re: keeping remote repo checked out?
From: Daniel Barkalow @ 2005-11-29 17:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis, Linus Torvalds
In-Reply-To: <7v8xv7lwlr.fsf@assigned-by-dhcp.cox.net>
On Mon, 28 Nov 2005, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> >> server$ git checkout production
> >> work$ git checkout master
> >> work$ git pull server production ;# merge into work's master
> >> work$ git push server master:receive_from_work
> >> server$ git pull . receive_from_work ;# merge into server's production
> >>
> >> and you make sure receive_from_work is not checked out on server
> >> (or production is never pushed into) and always do fast forward
> >> and nothing else.
> >
> > That's what I'm doing currently, actually (with work pushing to
> > "production", but server having checked out "deploy"), and I find it
> > annoying to have to do the pull each time and have a separate head. It
> > also means that, if the stuff on the server is set up as a hook, it'll
> > have to do the locking against concurrent changes to the working tree in
> > pull, which is much more complicated than checkout.
>
> This depends on what is on the checked-out working tree and how
> it is used, but one use pattern I was imagining was actually
> much more elaborate. I would set up two non-naked repositories
> on the server; let's call them treeR and treeP (reception and
> publish).
This is quite elaborate.
> Each work machine push into its own reception branch of treeR
> repository (so you have N reception branches for N workers). On
> the server machine, a daemon monitors the reception branch heads
> (inotify or idle poll loop looking at mtime; the details do not
> matter), and run the git pull into "master" of treeR. My daemon
> might want to forbid anything but fast forward for this pull, or
> might allow any clean merge. It compiles and runs testsuites
> next. If anything fails during the above process, the owner of
> the reception branch is notified about the failure; I might even
> want to forcibly rewind her reception branch in this case to
> "master" when this happens.
This seems maximally inconvenient. If you lose a race, you only find out
later, your reception branch is screwed up, and you have no way of finding
out in advance that this is going to happen? It's much nicer to have
people all push to a single branch, and tell them if they lose (i.e., the
change wouldn't be a fast-forward).
> When everything goes well, the daemon goes to treeP and pulls
> from treeR's master into "deploy", which is checked out. This
> procedure is the only thing that touches treeP, so this pull is
> guaranteed to be a fast forward.
>
> The serialization happens by having a single such daemon
> running; no need to worry about locking anymore.
I'm not sure what the big deal about locking is. We do locking for
updating everything else; I don't see a problem with having a lock for
when git updates the working tree, so long as it doesn't need to hold some
other lock as well at the same time (in which case we'd have to think
about lock ordering).
(Actually, adding CHECKED_OUT would also allow pulling the current branch
cleanly without all the special-casing in get-fetch.sh and git-pull.sh; it
would have the predictable effect of leaving your working tree not up to
date, but the ref it follows up to date, and the usual two-way merge in a
pull would obviously do the right thing. Or you could just fetch, find out
what will change with "git diff", and get the changes with "git
checkout". In general, it would fix aliasing problems between
refs/heads/* and HEAD.)
^ permalink raw reply
* Re: [PATCH] Fix typo in http-push.c
From: Johannes Schindelin @ 2005-11-29 16:40 UTC (permalink / raw)
To: Jan Andres; +Cc: git
In-Reply-To: <20051129133537.GA490@pitr.home.jan>
Hi,
On Tue, 29 Nov 2005, Jan Andres wrote:
> [...]
>
> + lock->token = xmalloc(strlen(ctx->cdata + 16) + 1);
>
> so as to account for the trailing NUL?
Of course! That's why I wanted to write "strlen(ctx->cdata + 15)", but I
fsck'ed up. Sorry.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Fix typo in http-push.c, take two
From: Jan Andres @ 2005-11-29 15:30 UTC (permalink / raw)
To: git
In-Reply-To: <20051129133537.GA490@pitr.home.jan>
Ok, so this is my final(?) proposal for the fix.
---
Fix a bug in handle_new_lock_ctx()'s memory allocation which may cause
segfaults.
Signed-off-by: Jan Andres <jandres@gmx.net>
---
diff --git a/http-push.c b/http-push.c
index 76c7886..bbb5118 100644
--- a/http-push.c
+++ b/http-push.c
@@ -784,7 +784,8 @@ static void handle_new_lock_ctx(struct x
strtol(ctx->cdata + 7, NULL, 10);
} else if (!strcmp(ctx->name, DAV_ACTIVELOCK_TOKEN)) {
if (!strncmp(ctx->cdata, "opaquelocktoken:", 16)) {
- lock->token = xmalloc(strlen(ctx->cdata - 15));
+ lock->token =
+ xmalloc(strlen(ctx->cdata + 16) + 1);
strcpy(lock->token, ctx->cdata + 16);
}
}
---
0.99.9.GIT
--
Jan Andres <jandres@gmx.net>
^ permalink raw reply related
* [PATCH] Fix typos and minor format issues.
From: jdl @ 2005-11-29 14:59 UTC (permalink / raw)
To: git
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Documentation/pull-fetch-param.txt | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
applies-to: 116ec987c167ce1489acbe8c1b6161e9e19344f1
6c335b09a1b8348eb750be4a86f1172e1f6d28ac
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
index 6413d52..b5b9792 100644
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -15,10 +15,10 @@
- ssh://host.xz/~/path/to/repo.git
===============================================================
+
- SSH Is the default transport protocol and also supports an
- scp-like syntax. Both syntaxes support username expansion,
- as does the native git protocol. The following three are
- identical to the last three above, respectively:
+SSH Is the default transport protocol and also supports an
+scp-like syntax. Both syntaxes support username expansion,
+as does the native git protocol. The following three are
+identical to the last three above, respectively:
+
===============================================================
- host.xz:/path/to/repo.git/
@@ -26,8 +26,8 @@
- host.xz:path/to/repo.git
===============================================================
+
- To sync with a local directory, use:
-
+To sync with a local directory, use:
++
===============================================================
- /path/to/repo.git/
===============================================================
@@ -113,7 +113,7 @@ on the remote branch, merge it into your
`git pull . remote-B`, while you are on `my-B` branch.
The common `Pull: master:origin` mapping of a remote `master`
branch to a local `origin` branch, which is then merged to a
-ocal development branch, again typically named `master`, is made
+local development branch, again typically named `master`, is made
when you run `git clone` for you to follow this pattern.
+
[NOTE]
---
0.99.9j
^ permalink raw reply related
* Re: [PATCH] Re: keeping remote repo checked out?
From: Matthias Urlichs @ 2005-11-29 13:39 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xv7lwlr.fsf@assigned-by-dhcp.cox.net>
Hi, Junio C Hamano wrote:
> When everything goes well, the daemon goes to treeP and pulls
> from treeR's master into "deploy", which is checked out.
Why do you need a separate tree for that? -EOVERKILL.
I just use a separate index file for the production tree (and a well-known
name in refs/heads that's associated with it, for which the commit hook
blocks updates).
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Nothing is so important that nothing else is important.
^ permalink raw reply
* ARCH: Failure to import visdn archive
From: Matthias Urlichs @ 2005-11-29 13:35 UTC (permalink / raw)
To: git
Bug in arch-import, or in the arch repository?
$ tla archives
daniele@orlandi.com--2005
http://repo.visdn.org/archives/daniele@orlandi.com--2005
$ /usr/bin/git-archimport -v daniele@orlandi.com--2005/isdn--devel--0.1
[...]
* Starting to work on daniele@orlandi.com--2005/isdn--devel--0.1--patch-4
patching file lapd/af_lapd.c
patching file lapd/tei_mgmt_nt.h
patching file lapd/tei_mgmt_te.h
can't find file to patch at input line 3 Perhaps you used the wrong -p or
--strip option? The text leading up to this was:
--------------------------
|--- orig/lapd/tei_mgmt.c
|+++ mod/lapd/tei_mgmt.c
--------------------------
File to patch: ^C
$ ls lapd/
af_lapd.c lapd.h lapd_user.h tei_mgmt_nt.c tei_mgmt_te.h
FEATURES lapd_inout.c Makefile tei_mgmt_nt.h TODO lapd_dev.c
lapd_proto.h tei_mgmt.h tei_mgmt_te.c vihai_isdn.h
NB: I hacked the script to use system() instead of backticks, so that
stdout doesn't get thrown away and people can actually see what breaks. :-/
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
"The worst criminals are not half so immoral as the creators and
perpetrators of the unquestionable hell of Christian theology"
[M.M. Mangasarian _Morality Without God_, 1913]
^ permalink raw reply
* Re: [PATCH] Re: keeping remote repo checked out?
From: Matthias Urlichs @ 2005-11-29 12:14 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0511290141220.25300@iabervon.org>
Hi, Daniel Barkalow wrote:
> That's what I'm doing currently, actually (with work pushing to
> "production", but server having checked out "deploy"), and I find it
> annoying to have to do the pull each time and have a separate head.
Why? I think "what's currently deployed" and "the latest commit on the
production branch" are two distinct concepts, and should be treated as
such.
That way, a clean push (update of PRODUCTION, controlled by the update
hook) and an update of DEPLOY (the fast-forward merge (unless you need
to roll back something) from your production branch, controlled by the
post-update hook) are also distinct, can be handled individually.
Personally I just use "git-read-tree -m -u deploy master && \
cat refs/heads/master > refs/heads/deploy" in the post-update trigger.
I don't care about HEAD at all; nobody is supposed to change that
directory manually anyway.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Bringing computers into the home won't change either one, but may
revitalize the corner saloon.
^ permalink raw reply
* Re: [PATCH] Fix typo in http-push.c
From: Jan Andres @ 2005-11-29 13:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511290923390.16927@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
On Tue, 29. Nov. 2005 at 09:24:47 +0100, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 29 Nov 2005, Jan Andres wrote:
>
> > - lock->token = xmalloc(strlen(ctx->cdata - 15));
> > + lock->token = xmalloc(strlen(ctx->cdata) - 15);
> > strcpy(lock->token, ctx->cdata + 16);
>
> Why not
>
> + lock->token = xmalloc(strlen(ctx->cdata + 16));
Looks more efficient indeed, but wouldn't we have to use
+ lock->token = xmalloc(strlen(ctx->cdata + 16) + 1);
so as to account for the trailing NUL?
Regards
--
Jan Andres <jandres@gmx.net>
^ permalink raw reply
* Re: git-send-mail in sh
From: Andreas Ericsson @ 2005-11-29 13:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v64qdxgiz.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>By "local" do you mean "local on Junio's laptop" or "local at cox.net"?
>>
>>"mail" uses the "local on Junio's laptop" SMTP server so he can
>>configure it any way he wants.
>
>
> I am puzzled. What if I do not run any SMTP server on the
> laptop and use ISP's SMTP server? Right now my ISP's SMTP
> server does not seem to require AUTH, so it is not an issue for
> me, though..
>
It uses whatever the /bin/mail program on your system uses. This is
usually done by spooling the mail for delivery by the local MTA which
doesn't have to listen to any ports anywhere (mutt and friends work the
same way).
Having an MTA installed is a requirement of the LSB. The /bin/mail
program requires that it's running, which the sendmail binary doesn't.
The sendmail binary is always shipped along with an MTA though, so to
get around having one at all one would have to re-implement the SMTP
protocol (which Mail::Sendmail does, but without authentication). I can
do that in C if you like. That way you can have support for SMTP over
SSL with all sorts of funny authentication mechanisms.
The good thing about using the local MTA is that you get that for free
with very thoroughly tested code and you only have to set it up once
rather than passing all the auth stuff repeatedly on the command-line
each time you want to submit a patch.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: use binmode(STDOUT) in git-status
From: Johannes Schindelin @ 2005-11-29 11:44 UTC (permalink / raw)
To: Tim O'Callaghan; +Cc: git
In-Reply-To: <20051129100550.GA2124@ELSAMSW37164>
Hi,
On Tue, 29 Nov 2005, Tim O'Callaghan wrote:
> [...] native windows support is going to be a bit tricky without Cygwin
> as you also need (ba)sh, sed, grep, etc.
... most notably, not to forget fork().
Hth,
Dscho
^ permalink raw reply
* Re: 'git commit' ignoring args?
From: Jeff Garzik @ 2005-11-29 11:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmnotwyr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Could it be that at some point after touching book.xml before
> running git commit you did update-index on it?
Not according to scrollback, no.
> -- >8 --
> Here is what I did to reproduce.
Unfortunately, I cannot reproduce the problem either :(
Oh well, as long as the facility works in general, I'll live to fight
another day :)
Jeff
^ 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