* Re: git svn rebase does not call post-update hook
From: Thomas Koch @ 2008-09-25 7:25 UTC (permalink / raw)
To: Git Mailing List
I think, I've found a kind of answer to my question in this thread:
http://kerneltrap.org/mailarchive/git/2008/8/2/2791714
It says, IMHO, that it is not intended, to call a hook during git svn
rebase, since git svn commands are always operating on your local repo
and one could easily wrap these commands in a custom script to do
whatever necessary before or after the git svn command.
Am Tuesday 23 September 2008 15:45:46 schrieben Sie:
> Hi,
>
> I've followed a blogpost[1] on how to set up a GIT mirror of a SVN repo.
> It works just fine, only that I've called the post-update hook manually
> so far. It won't get called by "git svn rebase".
> Yes, it is executable.
> Yes, git svn rebase does fetch updates and rebases master.
>
> [1] http://gsocblog.jsharpe.net/archives/12
>
> Thanks for your bandwidth,
--
Thomas Koch, Software Developer
http://www.koch.ro
Young Media Concepts GmbH
Sonnenstr. 4
CH-8280 Kreuzlingen
Switzerland
Tel +41 (0)71 / 508 24 86
Fax +41 (0)71 / 560 53 89
Mobile +49 (0)170 / 753 89 16
Web www.ymc.ch
^ permalink raw reply
* Re: having to pull twice
From: Thomas Rast @ 2008-09-25 7:05 UTC (permalink / raw)
To: Shawn O. Pearce, Miklos Vajna; +Cc: Michael P. Soulier, git
In-Reply-To: <20080925010150.GI3669@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]
Shawn O. Pearce wrote:
> "Michael P. Soulier" <msoulier@digitaltorque.ca> wrote:
> > I'm finding this happening from time to time.
> >
> > soulierm@espresso:~/work/mitel-msl-tug$ git pull
> ...
> > error: Entry 'mitel-msl-tug.spec' not uptodate. Cannot merge.
[fixed by 'git status's index refresh]
>
> Time or dev/ino skew in the index file vs. what we read from stat.
>
> Running git-status rematched the index file to the working directory,
> and during that rematch it noticed the file wasn't actually modified.
This keeps coming up every week or so... maybe git-merge should
attempt to refresh the index automatically? Of course it's an
expensive operation, but if you really want to do the merge you have
to bite that bullet anyway.
Unfortunately I can't see an obvious place to do that---the above
message comes from unpack-trees.c, where changes would also affect
e.g. checkout.
On the other hand, as near as I can tell this is a regression in
builtin-merge. Miklos, do you know if/how this can be fixed?
- Thomas
--
Thomas Rast
trast@student.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [StGit] kha/{safe,experimental} updated
From: Karl Hasselström @ 2008-09-25 7:33 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal, Daniel White
In-Reply-To: <b0943d9e0809241548t32e8ac24n3ec88698fb907764@mail.gmail.com>
On 2008-09-24 23:48:08 +0100, Catalin Marinas wrote:
> 2008/9/21 Karl Hasselström <kha@treskal.com>:
>
> > Just pushed out the stack log stuff to kha/safe. It really should
> > be ready for wider use at this point, and it was getting tiresome
> > to keep rebasing it.
>
> Great work, I merged (most of) it. Many thanks.
Thanks.
> > One patch is still in experimental -- it depends on a new git
> > feature that isn't in any release yet.
> [...]
> > Read several objects at once with git cat-file --batch
>
> I skipped this one for now.
I was talking about kha/experimental~0 here; you're talking about
kha/safe~0, which is kha/experimental~1. But never mind.
> I'm using Ubuntu (Hardy) and the git version is 1.5.4.3. I would
> wait until we get at least a stable git release with this feature.
I'm using it too, but I always build my own git, so I never know what
version the system comes with ... but I see your point. I'll put that
patch back in kha/experimental for now.
> I haven't looked in detail but can we have a way to drop back to the
> old implementation if the option isn't available?
I guess in this case we could, since if the option exists, we can use
it. (The second patch is not so lucky; the flag exists since quite a
while, but lacks a feature in older gits.)
Since it's just a moderate speed-up in both cases, I'm kind of
inclined to just wait for relevant distributions to catch up, and
avoid all the hassle.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: stg 0.14.3 breakage on push after moving hunk
From: Karl Hasselström @ 2008-09-25 7:23 UTC (permalink / raw)
To: Yann Dirson; +Cc: Catalin Marinas, GIT list
In-Reply-To: <20080924232654.GY4985@nan92-1-81-57-214-146.fbx.proxad.net>
On 2008-09-25 01:26:54 +0200, Yann Dirson wrote:
> Just saw the following problem - ever saw that ?
>
> $ stg push
> Checking for changes in the working directory ... done
> Pushing patch "factorize" ... Traceback (most recent call last):
> File "/usr/bin/stg", line 43, in <module>
> main()
> File "/var/lib/python-support/python2.5/stgit/main.py", line 281, in main
> command.func(parser, options, args)
> File "/var/lib/python-support/python2.5/stgit/commands/push.py", line 102, in func
> push_patches(crt_series, patches, options.merged)
> File "/var/lib/python-support/python2.5/stgit/commands/common.py", line 202, in push_patches
> modified = crt_series.push_patch(p)
> File "/var/lib/python-support/python2.5/stgit/stack.py", line 1112, in push_patch
> git.merge(bottom, head, top, recursive = True)
> File "/var/lib/python-support/python2.5/stgit/git.py", line 790, in merge
> stages['2'][0], stages['3'][0]) != 0:
> File "/var/lib/python-support/python2.5/stgit/gitmergeonefile.py", line 268, in merge
> % path)
> TypeError: not all arguments converted during string formatting
No, but try this ...
diff --git a/stgit/gitmergeonefile.py b/stgit/gitmergeonefile.py
index c1af2f8..55b62db 100644
--- a/stgit/gitmergeonefile.py
+++ b/stgit/gitmergeonefile.py
@@ -264,7 +264,7 @@ def merge(orig_hash, file1_hash, file2_hash,
__conflict(path)
return 1
if file1_mode != file2_mode:
- out.error('File "s" added in both, permissions conflict'
+ out.error('File "%s" added in both, permissions conflict'
% path)
__conflict(path)
return 1
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply related
* Re: [PATCH 3/3] [FYI]git-gui: repo.or.cz-ish fork integration
From: Andreas Ericsson @ 2008-09-25 6:15 UTC (permalink / raw)
To: pasky; +Cc: git, spearce
In-Reply-To: <20080925000157.506352696@suse.cz>
pasky@suse.cz wrote:
[ a lot of stuff as an attachment ]
FWIW, I thoroughly like this idea and I'm very excited to see how
it'll work in op5's development environment.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: On Sponsor Notices
From: Andreas Ericsson @ 2008-09-25 6:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, spearce
In-Reply-To: <20080924225120.GL10544@machine.or.cz>
Petr Baudis wrote:
> Hi,
>
> to follow up a little on the "This patch has been sponsored by
> Novartis" messages - I have been on a summer internship at Novartis busy
> deploying Git and these patches (still quite a few more to come, mostly
> for gitweb) have been one of the main outputs of that work.
>
> However, I'm not sure if acknowledging the Novartis-originated patches
> in the log message like this is the best practice and we will understand
> if the maintainers will decide to strip these notices when applying the
> patches. Usually, this kind of acknowledgement is made by using
> "sponsored" email addresses, however mine will probably stop working
> shortly after I leave and the only way to read it is, shall we say,
> utmostly inconvenient. ;-) Now, Shawn has proposed 'Sponsored-by:' line
> at the header footer, which is also an interesting possibility.
>
I like the "Sponsored-by" idea. I work for a company that sponsors quite
a lot, and I thoroughly enjoy the idea that I can one day go to my boss
and say "hey, our company name is clearly visible here. We've sent this
many patches that got accepted upstream", and that other companies can
see that too.
As for the legal S-o-b stuff, I'd say a combination like this:
Sponsored-by: Example <contact@example.com>
Signed-off-by: Casper Intern (for Example) <random@real.com>
should work wonderfully. I know the guys holding the money like to see
the company name so it's a good thing to do to get a company to sponsor
development further, while the S-o-b marks the person responsible for
posting the patches to the project.
Just my €0.02.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [QGit] Some suggestion
From: Li Frank-B20596 @ 2008-09-25 5:24 UTC (permalink / raw)
To: git
In-Reply-To: <gbak2u$v9b$1@ger.gmane.org>
Can add below function at qgit?
===Difference other version===
1. user choose a commit,
2. right click
Check working dir
View patch
....
[Diff with other commit]
3. change icon +
4. user choose other commit
QGit show list of changed files.
click one files, call extern diff tool show difference.
=== file view ===
Can use different color to high light current commit change.
^ permalink raw reply
* Re: On Sponsor Notices
From: Nicolas Pitre @ 2008-09-25 2:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, spearce
In-Reply-To: <20080924225120.GL10544@machine.or.cz>
On Thu, 25 Sep 2008, Petr Baudis wrote:
> Hi,
>
> to follow up a little on the "This patch has been sponsored by
> Novartis" messages - I have been on a summer internship at Novartis busy
> deploying Git and these patches (still quite a few more to come, mostly
> for gitweb) have been one of the main outputs of that work.
>
> However, I'm not sure if acknowledging the Novartis-originated patches
> in the log message like this is the best practice and we will understand
> if the maintainers will decide to strip these notices when applying the
> patches. Usually, this kind of acknowledgement is made by using
> "sponsored" email addresses, however mine will probably stop working
> shortly after I leave and the only way to read it is, shall we say,
> utmostly inconvenient. ;-) Now, Shawn has proposed 'Sponsored-by:' line
> at the header footer, which is also an interesting possibility.
I'd suggest you do like some people working on the Linux kernel, i.e.
use your employer's email address for the Signed-off-by line but use
whatever address you prefer for the from/author line.
Nicolas
^ permalink raw reply
* Re: having to pull twice
From: Shawn O. Pearce @ 2008-09-25 1:01 UTC (permalink / raw)
To: Michael P. Soulier; +Cc: git
In-Reply-To: <fb6605670809241758r186eef51sc6ed6d334a64495d@mail.gmail.com>
"Michael P. Soulier" <msoulier@digitaltorque.ca> wrote:
> I'm finding this happening from time to time.
>
> soulierm@espresso:~/work/mitel-msl-tug$ git pull
...
> error: Entry 'mitel-msl-tug.spec' not uptodate. Cannot merge.
> soulierm@espresso:~/work/mitel-msl-tug$ git status
> # On branch master
> # Your branch is behind 'origin/master' by 4 commits, and can be fast-forwarded.
> #
> nothing to commit (working directory clean)
...
> That directory is mounted via NFS, and I'm curious as to
> whether some kind of time skew could be the problem. But
> then, if it is, why did it go away after the first pull?
Time or dev/ino skew in the index file vs. what we read from stat.
Running git-status rematched the index file to the working directory,
and during that rematch it noticed the file wasn't actually modified.
So it prints "nothing to commit" and the next pull works fine,
now that the stat data in the index matches the working directory.
--
Shawn.
^ permalink raw reply
* having to pull twice
From: Michael P. Soulier @ 2008-09-25 0:58 UTC (permalink / raw)
To: git
I'm finding this happening from time to time.
soulierm@espresso:~/work/mitel-msl-tug$ git pull
remote: Counting objects: 97, done.
remote: Compressing objects: 100% (54/54), done.
remote: Total 65 (delta 34), reused 0 (delta 0)
Unpacking objects: 100% (65/65), done.
From pa:git/mitel-msl-tug
92437d6..9c784c8 master -> origin/master
Updating 92437d6..9c784c8
error: Entry 'mitel-msl-tug.spec' not uptodate. Cannot merge.
soulierm@espresso:~/work/mitel-msl-tug$ git status
# On branch master
# Your branch is behind 'origin/master' by 4 commits, and can be fast-forwarded.
#
nothing to commit (working directory clean)
soulierm@espresso:~/work/mitel-msl-tug$ git pull
Updating 92437d6..9c784c8
Fast forward
mitel-msl-tug.spec | 7 +-
.../etc/e-smith/pgsql/init/tugdb.sh/20auth | 4 +-
.../etc/e-smith/pgsql/init/tugdb.sh/50apps | 37 ---
.../etc/e-smith/pgsql/init/tugdb.sh/90loaddata | 8 +-
.../etc/e-smith/pgsql/init/tugdb.sh/95schema | 2 +-
root/etc/e-smith/templates/etc/tug/tug.ini/00setup | 2 +
.../e-smith/templates/etc/tug/tug.ini/10teleworker | 37 +++-
.../templates/etc/tug/tug.ini/11teleworker_fixed | 1 -
.../e-smith/web/django/teleworker/scrc/views.py | 11 +-
root/usr/lib/scrc/migrate.pl | 322 --------------------
root/usr/lib/tug/migrate/30_add_scrc | 2 +-
root/usr/lib/tug/migrate/31_add_scrc_connections | 22 ++-
12 files changed, 77 insertions(+), 378 deletions(-)
delete mode 100755 root/usr/lib/scrc/migrate.pl
soulierm@espresso:~/work/mitel-msl-tug$ git --version
git version 1.6.0
When I pulled the first time, I was told that one of the files was
not up-to-date, but status did not note any modified files. The
second pull then worked as expected.
That directory is mounted via NFS, and I'm curious as to
whether some kind of time skew could be the problem. But
then, if it is, why did it go away after the first pull?
Thanks,
Mike
--
Michael P. Soulier <msoulier@digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It takes a
touch of genius - and a lot of courage to move in the opposite direction."
--Albert Einstein
^ permalink raw reply
* [PATCH 3/3] [FYI]git-gui: repo.or.cz-ish fork integration
From: pasky @ 2008-09-24 23:57 UTC (permalink / raw)
To: git; +Cc: spearce
In-Reply-To: <20080924235734.697978308@suse.cz>
[-- Attachment #1: t/git-gui/remote-publish.diff --]
[-- Type: text/plain, Size: 5507 bytes --]
During my internship at Novartis, I have deployed a local instance of the
repo.or.cz software and for our Git deployment, some kind of integration with
git-gui was very desirable - if someone makes local changes in his repository,
he can easily publish them on the local repo.or.cz instance as a fork of the
original project. They can use the extra 'Register on repo.or.cz' item in the
'Remote' menu, which will enforce the default locator and aside of initializing
the remote repository and pushing will also open the web browser with the
project registration form of repo.or.cz.
I'm not sure if something like this would be desirable for upstream, even as an
optional feature, and to what degree should it be configurable - but I imagine
that something like this could be very useful for corporate Git deployments
especially among less technical users and in scenarios using some kind of
central place to store all the repositories. Perhaps people deploying Git
in these cases will find the patch useful to apply locally even if it won't
end up merged.
This patch has been sponsored by Novartis.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
git-gui/git-gui.sh | 4 ++++
git-gui/lib/remote_add.tcl | 42 +++++++++++++++++++++++++++++++++++++-----
git-gui/lib/transport.tcl | 7 +++++++
3 files changed, 48 insertions(+), 5 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index aef9d66..a79d734 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -2305,6 +2305,10 @@ if {[is_enabled transport]} {
menu .mbar.remote
.mbar.remote add command \
+ -label [mc "Register on repo.or.cz"] \
+ -command remote_add::dialog_reg \
+ -accelerator $M1T-L
+ .mbar.remote add command \
-label [mc "Add..."] \
-command remote_add::dialog \
-accelerator $M1T-A
diff --git a/git-gui/lib/remote_add.tcl b/git-gui/lib/remote_add.tcl
index 94662fb..fb43abd 100644
--- a/git-gui/lib/remote_add.tcl
+++ b/git-gui/lib/remote_add.tcl
@@ -6,22 +6,36 @@ class remote_add {
field w ; # widget path
field w_name ; # new remote name widget
field w_loc ; # new remote location widget
+field is_reg 0; # are we the REGistering dialog, or normal add remote?
+field base_name ; # name of base project if is_reg
field name {}; # name of the remote the user has chosen
field location {}; # location of the remote the user has chosen
-field opt_action fetch; # action to do after registering the remote locally
+field opt_action {}; # action to do after registering the remote locally
-constructor dialog {} {
+proc dialog {} {
+ dialog_create "" 0 "fetch" "Add New Remote"
+}
+
+proc dialog_reg {} {
+ dialog_create "public" 1 "push" "Register On repo.or.cz"
+}
+
+constructor dialog_create {name_ is_reg_ opt_action_ title} {
global repo_config
+ set name $name_
+ set is_reg $is_reg_
+ set opt_action $opt_action_
+
make_toplevel top w
- wm title $top [append "[appname] ([reponame]): " [mc "Add Remote"]]
+ wm title $top [append "[appname] ([reponame]): " [mc $title]]
if {$top ne {.}} {
wm geometry $top "+[winfo rootx .]+[winfo rooty .]"
}
- label $w.header -text [mc "Add New Remote"] -font font_uibold
+ label $w.header -text [mc $title] -font font_uibold
pack $w.header -side top -fill x
frame $w.buttons
@@ -49,7 +63,9 @@ constructor dialog {} {
label $w.desc.loc_l -text [mc "Location:"]
set w_loc $w.desc.loc_t
- location_input $w_loc @location remote
+ set location_op "remote"
+ if {$is_reg} { set location_op "reg" }
+ location_input $w_loc @location $location_op
grid $w.desc.loc_l $w_loc -sticky we -padx {0 5}
grid columnconfigure $w.desc 1 -weight 1
@@ -78,6 +94,18 @@ constructor dialog {} {
grid columnconfigure $w.action 1 -weight 1
pack $w.action -anchor nw -fill x -pady 5 -padx 5
+ if {$is_reg} {
+ focus $w_loc
+ set matcher [regsub -all %s "$repo_config(locator.repo.template)" "(.*)"]
+ set origin willnevermatch
+ catch { set origin $repo_config(remote.origin.url) }
+ if {![regexp $matcher $origin xx base_name]} {
+ error_popup "This repository is not based on a repo.or.cz project; you need to register your project manually."
+ destroy $w
+ return
+ }
+ }
+
bind $w <Visibility> [cb _visible]
bind $w <Key-Escape> [list destroy $w]
bind $w <Key-Return> [cb _add]\;break
@@ -160,6 +188,10 @@ method _add {} {
[mc "Setting up the %s (at %s)" $name $location]]
lappend cmds [list exec git push -v --all $name]
+ if {$is_reg} {
+ global _locator_input
+ start_browser "http://repo.or.cz/m/regproj.cgi?fork=$base_name;LOC_i1=$_locator_input"
+ }
console::chain $c $cmds
}
none {
diff --git a/git-gui/lib/transport.tcl b/git-gui/lib/transport.tcl
index 277e6b8..b80d526 100644
--- a/git-gui/lib/transport.tcl
+++ b/git-gui/lib/transport.tcl
@@ -62,6 +62,12 @@ proc location_input {widget urlvar op} {
return 0
}
+ set state "normal"
+ if {$op == "reg"} {
+ set state "disabled"
+ set op "remote"
+ }
+
if {[catch {set default_locator $repo_config(gui.${op}locator)}]} {
set default_locator [lindex $all_locators 0]
}
@@ -75,6 +81,7 @@ proc location_input {widget urlvar op} {
frame $widget
eval tk_optionMenu $widget.l _locator_template $all_locators
+ $widget.l configure -state $state
entry $widget.s \
-borderwidth 1 \
-relief sunken \
--
tg: (2735999..) t/git-gui/remote-publish (depends on: git-gui/remotes git-gui/locators git-gui/web-browse t/git-gui/remote-fetch)
^ permalink raw reply related
* [PATCH 2/3] git-gui: Use git web--browse --stdin for safe URL passing
From: pasky @ 2008-09-24 23:57 UTC (permalink / raw)
To: git; +Cc: spearce
In-Reply-To: <20080924235734.697978308@suse.cz>
[-- Attachment #1: t/git-gui/web-browse-stdin.diff --]
[-- Type: text/plain, Size: 972 bytes --]
The current code does not actually require this since the documentation
URL should always pass through unmangled, but future users of
start_browser() (as in the patch to follow) might require this.
This patch has been sponsored by Novartis.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
git-gui/git-gui.sh | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index fc67eb8..4d2d600 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -2360,7 +2360,11 @@ if {[file isfile $doc_path]} {
}
proc start_browser {url} {
- git "web--browse" $url
+ # We use --stdin here since passing URLs (especially with query
+ # strings) does insane things in MSysGit.
+ set fd [git_write "web--browse" "--stdin"]
+ puts $fd $url
+ close $fd
}
.mbar.help add command -label [mc "Online Documentation"] \
--
tg: (6e32399..) t/git-gui/web-browse-stdin (depends on: t/git-gui/web-browse t/web--browse/stdin)
^ permalink raw reply related
* [PATCH 0/3] [RFC] Support for publishing projects at central site
From: pasky @ 2008-09-24 23:57 UTC (permalink / raw)
To: git; +Cc: spearce
This series implements a special variant of the 'add remote' dialog
designed for publishing new projects at a central site - it fixes
certain parameters and launches web browser during the push for
project registration in a repo.or.cz-like fashion. The feature is
aimed especially at corporate Git deployment.
This is not really meant for as-is application, of course, but more
to see if people think it is good idea to have this kind of functionality
in git-gui at all and how generic it should be. This mini-series depends
on pretty much all the other patches I have submitted tonight.
^ permalink raw reply
* [PATCH 1/3] git web--browse: Add --stdin option support
From: pasky @ 2008-09-24 23:57 UTC (permalink / raw)
To: git; +Cc: spearce
In-Reply-To: <20080924235734.697978308@suse.cz>
[-- Attachment #1: t/web--browse/stdin.diff --]
[-- Type: text/plain, Size: 1868 bytes --]
This ugly hack seems to be necessary to safely pass URLs containing
query string even in the MinGW environment from TCL (git-gui). I admit
that it is not nice, but I at least did not manage to find any other
way to achieve that even after spending very long time debugging this
mysterious problem.
This patch has been sponsored by Novartis.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-web--browse.txt | 5 ++++-
git-web--browse.sh | 6 +++++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-web--browse.txt b/Documentation/git-web--browse.txt
index 7f7a45b..15d2c25 100644
--- a/Documentation/git-web--browse.txt
+++ b/Documentation/git-web--browse.txt
@@ -7,7 +7,7 @@ git-web--browse - git helper script to launch a web browser
SYNOPSIS
--------
-'git web--browse' [OPTIONS] URL/FILE ...
+'git web--browse' [OPTIONS] {--stdin,URL/FILE...}
DESCRIPTION
-----------
@@ -45,6 +45,9 @@ OPTIONS
CONF.VAR is looked up in the git config files. If it's set,
then its value specify the browser that should be used.
+--stdin::
+ Read the location to open from stdin.
+
CONFIGURATION VARIABLES
-----------------------
diff --git a/git-web--browse.sh b/git-web--browse.sh
index 384148a..68234fa 100755
--- a/git-web--browse.sh
+++ b/git-web--browse.sh
@@ -16,7 +16,7 @@
# git maintainer.
#
-USAGE='[--browser=browser|--tool=browser] [--config=conf.var] url/file ...'
+USAGE='[--browser=browser|--tool=browser] [--config=conf.var] {--stdin,url/file...}'
# This must be capable of running outside of git directory, so
# the vanilla git-sh-setup should not be used.
@@ -71,6 +71,10 @@ do
shift ;;
esac
;;
+ --stdin*)
+ shift
+ set "$(cat)"
+ break ;;
--)
break
;;
--
tg: (c427559..) t/web--browse/stdin (depends on: vanilla/master)
^ permalink raw reply related
* Re: On Sponsor Notices
From: Martin Langhoff @ 2008-09-24 23:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, spearce
In-Reply-To: <20080924234753.GE10360@machine.or.cz>
On Thu, Sep 25, 2008 at 11:47 AM, Petr Baudis <pasky@suse.cz> wrote:
> That works fine when it is signed off by employers using their company
> e-mail, but that is not feasible in my case -
Don't know that much about your case... Whoever at Novartis that gave
the go-ahead to "develop and release the patches"?
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: On Sponsor Notices
From: Petr Baudis @ 2008-09-24 23:47 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git, spearce
In-Reply-To: <46a038f90809241643i1e366dfbtea8dbdd9a1bc1de5@mail.gmail.com>
On Thu, Sep 25, 2008 at 11:43:52AM +1200, Martin Langhoff wrote:
> On Thu, Sep 25, 2008 at 10:51 AM, Petr Baudis <pasky@suse.cz> wrote:
> > However, I'm not sure if acknowledging the Novartis-originated patches
> > in the log message like this is the best practice and we will understand
> > if the maintainers will decide to strip these notices when applying the
> > patches.
>
> AIUI, the signed-off-by line is meant to track this, and it serves
> both legal purposes and a as recognition.
That works fine when it is signed off by employers using their company
e-mail, but that is not feasible in my case - what should be in the
Signed-off-line? Name of the company? What about the e-mail? Some
generic e-mail of the legal department? That doesn't really work well
with all the machinery developed around s-o-b lines, besides the
question does not seem to be by far that simple with such a huge
corporation.
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* Re: On Sponsor Notices
From: Martin Langhoff @ 2008-09-24 23:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, spearce
In-Reply-To: <20080924225120.GL10544@machine.or.cz>
On Thu, Sep 25, 2008 at 10:51 AM, Petr Baudis <pasky@suse.cz> wrote:
> to follow up a little on the "This patch has been sponsored by
> Novartis" messages - I have been on a summer internship at Novartis busy
> deploying Git and these patches (still quite a few more to come, mostly
> for gitweb) have been one of the main outputs of that work.
In my case, if the contribution is done at the behest of a client the
copyright is theirs (they paid for my work, and it's a "work for hire"
in legal terms). So
- if the contribution is large, I tend to add a copyright line (see
git-cvsserver: copyright != authors, though that's out of date now)
- they probably have to provide sign-off, so s-o-b line is appropriate
> However, I'm not sure if acknowledging the Novartis-originated patches
> in the log message like this is the best practice and we will understand
> if the maintainers will decide to strip these notices when applying the
> patches.
AIUI, the signed-off-by line is meant to track this, and it serves
both legal purposes and a as recognition.
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* [PATCH] git-gui: Fix fetching from remotes when adding them
From: Petr Baudis @ 2008-09-24 23:39 UTC (permalink / raw)
To: git, git; +Cc: spearce
In-Reply-To: <20080924204615.625864882@suse.cz>
As you can see, this particular code branch did not see a lot
of testing for some time now. Apologies for that.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
git-gui/lib/remote_add.tcl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-gui/lib/remote_add.tcl b/git-gui/lib/remote_add.tcl
index 8e3ad16..fb29422 100644
--- a/git-gui/lib/remote_add.tcl
+++ b/git-gui/lib/remote_add.tcl
@@ -130,9 +130,9 @@ method _add {} {
switch -- $opt_action {
fetch {
set c [console::new \
- [mc "fetch %s" $remote] \
- [mc "Fetching the %s" $remote]]
- console::exec $c [list git fetch --all $name]
+ [mc "fetch %s" $name] \
+ [mc "Fetching the %s" $name]]
+ console::exec $c [list git fetch $name]
}
push {
set cmds [list]
--
tg: (17f0c43..) t/git-gui/remote-fetch (depends on: git-gui/remotes)
^ permalink raw reply related
* [PATCH] Fix removing non-pushable remotes
From: Petr Baudis @ 2008-09-24 23:32 UTC (permalink / raw)
To: git, git; +Cc: spearce
In-Reply-To: <20080924204616.189163849@suse.cz>
Git-gui does not add most of the remotes to the 'push' menu
since they are missing the "Push" line in their remotespec.
In that case, removing the remote would end up with an error.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Note that I think this should be abandoned and all remotes
added to the push menu. Having the push part of the remotespec
is actually a very rare situation and it is just not there
in most of the cases, relying on default git push behaviour.
git-gui/lib/remote.tcl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-gui/lib/remote.tcl b/git-gui/lib/remote.tcl
index 1852247..b92b429 100644
--- a/git-gui/lib/remote.tcl
+++ b/git-gui/lib/remote.tcl
@@ -271,5 +271,6 @@ proc remove_remote {name} {
delete_from_menu $remote_m.fetch $name
delete_from_menu $remote_m.prune $name
delete_from_menu $remote_m.remove $name
- delete_from_menu $remote_m.push $name
+ # Not all remotes are in the push menu
+ catch { delete_from_menu $remote_m.push $name }
}
--
tg: (17f0c43..) t/git-gui/remove-push (depends on: git-gui/remotes)
^ permalink raw reply related
* Re: [JGIT PATCH] Test and fix handling of quotes in ~/.ssh/config
From: Shawn O. Pearce @ 2008-09-24 23:31 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Robin Rosenberg, sverre, git
In-Reply-To: <20080924232519.GA15318@diku.dk>
Jonas Fonseca <fonseca@diku.dk> wrote:
> Shawn O. Pearce <spearce@spearce.org> wrote Mon, Sep 22, 2008:
> > Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> > > söndagen den 21 september 2008 13.25.19 skrev Jonas Fonseca:
> > > > + assertEquals("bad.tld\"", osc.lookup("bad").getHostName());
...
> > > This one is really (as you noted) bad so we shouldn't allow it at all.
>
> Using exceptions seems a bit harsh, since the quote is not really fatal
> in anyway.
...
> I propose to simply remove these hosts from the host map and clear
> the current host list so that no values will be saved, effectively
> causing invalid hosts to result in the same as unknown hosts.
Yea, that seems quite reasonable.
If you want more debugging than that on your ~/.ssh/config file then
run OpenSSH tools on it. Hell, I can't count the number of times
I've made typos in there and couldn't figure out why it was still
asking for a password, etc. And that's just the OpenSSH command
line tools.
--
Shawn.
^ permalink raw reply
* Re: [JGIT PATCH] Test and fix handling of quotes in ~/.ssh/config
From: Jonas Fonseca @ 2008-09-24 23:25 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Robin Rosenberg, sverre, git
In-Reply-To: <20080922210734.GE3669@spearce.org>
Shawn O. Pearce <spearce@spearce.org> wrote Mon, Sep 22, 2008:
> Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> > söndagen den 21 september 2008 13.25.19 skrev Jonas Fonseca:
> > > + assertEquals("bad.tld\"", osc.lookup("bad").getHostName());
> > This one is really (as you noted) bad so we shouldn't allow it at all. A new
> > subclass of TransportExcpeption should be thrown to indicate a serious
> > configuration problem when attempting to use the option.
>
> Probably so.
>
> But then we need to mark that the Host is invalid, because we
> are serving requests from a cache, not from the file itself.
> And TransportException isn't something that the SshSessionFactory
> knows about. Probably better to use a a subclass of IOException.
Sorry, for not following up on this. I was trying to cook up a patch for
this today. Now, it is somehow sad that testing "forces" us to waste
time on these stupid corner cases. ;-) On the other hand, this problem
might exist (.git/config) or turn up again, so it would be good to have
a design principle.
Using exceptions seems a bit harsh, since the quote is not really fatal
in anyway. Also, for badly formatted Port values the value is simply
ignored. So for bad quoting encountered during non-Host values, I think
it is fair to just ignore the value. For Host values it is a bit more
non-obvious to me. In terms of invalidating hosts, the API ensures that
a lookup will always return a host, so invalid hosts should not return
null. I propose to simply remove these hosts from the host map and clear
the current host list so that no values will be saved, effectively
causing invalid hosts to result in the same as unknown hosts.
--
Jonas Fonseca
^ permalink raw reply
* stg 0.14.3 breakage on push after moving hunk
From: Yann Dirson @ 2008-09-24 23:26 UTC (permalink / raw)
To: Catalin Marinas, Karl Hasselström; +Cc: GIT list
Just saw the following problem - ever saw that ?
Getting into context: split changes affecting a particular file into
another patch
$ stg --version
Stacked GIT 0.14.3
git version 1.6.0.1
Python version 2.5.2 (r252:60911, Aug 8 2008, 09:22:44)
[GCC 4.3.1]
$ stg pop
Checking for changes in the working directory ... done
Popping patch "factorize" ... done
Now at patch "x-dummy"
$ stg new -m test
$ stg-fold-files-from factorize 't/*'
Checking for changes in the working directory ... done
Folding patch from stdin ... done
$ stg ref
Checking for changes in the working directory ... done
Refreshing patch "test" ... done
... then attempting to push to get rid of the now-duplicated changes
from orig patch (which has been how I have used stg-fold-files-from
ever since I wrote it, so I'm pretty sure it used to work, but then,
it's been a couple of months since I did not use it ;):
$ stg push
Checking for changes in the working directory ... done
Pushing patch "factorize" ... Traceback (most recent call last):
File "/usr/bin/stg", line 43, in <module>
main()
File "/var/lib/python-support/python2.5/stgit/main.py", line 281, in main
command.func(parser, options, args)
File "/var/lib/python-support/python2.5/stgit/commands/push.py", line 102, in func
push_patches(crt_series, patches, options.merged)
File "/var/lib/python-support/python2.5/stgit/commands/common.py", line 202, in push_patches
modified = crt_series.push_patch(p)
File "/var/lib/python-support/python2.5/stgit/stack.py", line 1112, in push_patch
git.merge(bottom, head, top, recursive = True)
File "/var/lib/python-support/python2.5/stgit/git.py", line 790, in merge
stages['2'][0], stages['3'][0]) != 0:
File "/var/lib/python-support/python2.5/stgit/gitmergeonefile.py", line 268, in merge
% path)
TypeError: not all arguments converted during string formatting
Best regards,
--
Yann
^ permalink raw reply
* [PATCH] Documentation: clarify the details of overriding LESS via core.pager
From: Chris Frey @ 2008-09-24 23:21 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <20080918232207.GA31193@foursquare.net>
The process of overriding the default LESS options using only
git-specific methods is rather obscure. Show the end user how
to do it in a step-by-step manner.
Signed-off-by: Chris Frey <cdfrey@foursquare.net>
---
No comments on this patch last week, so sending again, to be
applied.
Thanks,
- Chris
Documentation/config.txt | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 922ac7b..9493621 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -363,8 +363,17 @@ core.pager::
variable. Note that git sets the `LESS` environment
variable to `FRSX` if it is unset when it runs the
pager. One can change these settings by setting the
- `LESS` variable to some other value or by giving the
- `core.pager` option a value such as "`less -+FRSX`".
+ `LESS` variable to some other value. Alternately,
+ these settings can be overridden on a project or
+ global basis by setting the `core.pager` option.
+ Setting `core.pager` has no affect on the `LESS`
+ environment variable behaviour above, so if you want
+ to override git's default settings this way, you need
+ to be explicit. For example, to disable the S option
+ in a backward compatible manner, set `core.pager`
+ to "`less -+$LESS -FRX`". This will be passed to the
+ shell by git, which will translate the final command to
+ "`LESS=FRSX less -+FRSX -FRX`".
core.whitespace::
A comma separated list of common whitespace problems to
--
1.6.0.2
^ permalink raw reply related
* [PATCH] for-each-ref: Fix --format=%(subject) for log message without newlines
From: Johan Herland @ 2008-09-24 23:10 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
'git for-each-ref --format=%(subject)' currently returns an empty string
if the log message does not contain a newline.
This patch teaches 'git for-each-ref' to return the entire log message
(instead of an empty string) if there is no newline in the log message.
Signed-off-by: Johan Herland <johan@herland.net>
---
Normally, log messages in git have trailing newlines. However, it seems the
"tag fixup commits" manufactured by cvs2svn/cvs2git (via git-fast-import)
have single-line log message without trailing newlines.
I have checked the other callers of copy_line(), and AFAICS they are not
affected by this change, since that would violate the git object format.
Have fun! :)
...Johan
builtin-for-each-ref.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index 9b44092..e59bd80 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -321,8 +321,8 @@ static const char *find_wholine(const char *who, int wholen, const char *buf, un
static const char *copy_line(const char *buf)
{
const char *eol = strchr(buf, '\n');
- if (!eol)
- return "";
+ if (!eol) // simulate strchrnul()
+ eol = buf + strlen(buf);
return xmemdupz(buf, eol - buf);
}
--
1.6.0.2.463.g7f0eb
^ permalink raw reply related
* Re: On Sponsor Notices
From: Heikki Orsila @ 2008-09-24 22:55 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, spearce
In-Reply-To: <20080924225120.GL10544@machine.or.cz>
On Thu, Sep 25, 2008 at 12:51:20AM +0200, Petr Baudis wrote:
> Now, Shawn has proposed 'Sponsored-by:' line
> at the header footer, which is also an interesting possibility.
In my opinion, one should aim for minimum amount of technically
irrelevant information. Extra lines cause penalty for reading logs.
--
Heikki Orsila
heikki.orsila@iki.fi
http://www.iki.fi/shd
^ 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