* [PATCH] gitk: try to set program icon
From: Giuseppe Bilotta @ 2008-11-15 23:45 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Junio C Hamano, Giuseppe Bilotta
We add the git icon in three formats (.xbm, .ico, .ppm), which we try to
set as window icon.
---
Ugh. This rather simple patch cost me _way_ more time than I expected to
dedicate to it. Making those pesky iconbitmap and iconphoto commands do what
they were supposed to do is not as trivial as it seems. Thanks the people on
Freenode/#tcl for giving me a hand in understading they very restricted way in
which they could work.
Also, I'm not really sure the gitk program path itself is the best place to put
the icon files in, but I couldn't think of a better place so feel free to
suggest alternatives (it's a real pity that you can't embed the icon data in
the program itself).
gitk-git/Makefile | 3 +++
gitk-git/gitk | 9 +++++++++
gitk-git/gitk.ico | Bin 0 -> 318 bytes
gitk-git/gitk.ppm | Bin 0 -> 781 bytes
gitk-git/gitk.xbm | 6 ++++++
5 files changed, 18 insertions(+), 0 deletions(-)
create mode 100644 gitk-git/gitk.ico
create mode 100644 gitk-git/gitk.ppm
create mode 100644 gitk-git/gitk.xbm
diff --git a/gitk-git/Makefile b/gitk-git/Makefile
index e1b6045..a55f905 100644
--- a/gitk-git/Makefile
+++ b/gitk-git/Makefile
@@ -31,6 +31,7 @@ endif
PO_TEMPLATE = po/gitk.pot
ALL_POFILES = $(wildcard po/*.po)
ALL_MSGFILES = $(subst .po,.msg,$(ALL_POFILES))
+LOGO_FILES = gitk.ico gitk.xbm gitk.ppm
ifndef V
QUIET = @
@@ -43,8 +44,10 @@ install:: all
$(INSTALL) -m 755 gitk-wish '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(msgsdir_SQ)'
$(foreach p,$(ALL_MSGFILES), $(INSTALL) -m 644 $p '$(DESTDIR_SQ)$(msgsdir_SQ)' &&) true
+ $(foreach p,$(LOGO_FILES), $(INSTALL) -m 644 $p '$(DESTDIR_SQ)$(bindir_SQ)' &&) true
uninstall::
+ $(foreach p,$(LOGO_FILES), $(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/$(notdir $p) &&) true
$(foreach p,$(ALL_MSGFILES), $(RM) '$(DESTDIR_SQ)$(msgsdir_SQ)'/$(notdir $p) &&) true
$(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 3353f4a..25cf627 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -10797,6 +10797,15 @@ set lserial 0
set isworktree [expr {[exec git rev-parse --is-inside-work-tree] == "true"}]
setcoords
makewindow
+# try to set the window icon, testing the logos from the worst to the best
+# quality. XBM is likely to fail on Windows, ICO is likely to fail on other
+# systems, and PPM with iconphoto only works for 8.4.9 or later
+catch { wm iconbitmap . @[file join [file dirname [file normalize $argv0]] gitk.xbm] }
+catch { wm iconbitmap . @[file join [file dirname [file normalize $argv0]] gitk.ico] }
+catch {
+ image create photo gitlogo -file [file join [file dirname [file normalize $argv0]] gitk.ppm]
+ wm iconphoto . -default gitlogo
+}
# wait for the window to become visible
tkwait visibility .
wm title . "[file tail $argv0]: [file tail [pwd]]"
diff --git a/gitk-git/gitk.ico b/gitk-git/gitk.ico
new file mode 100644
index 0000000000000000000000000000000000000000..db349141ec3f510d98751fc117ff63eb4fc465c0
GIT binary patch
literal 318
zcmb7;u?~PB5JL-bbGgIB8JYM@Kg~bGR>MNVK*{Tc_J#ujpPA7&)Bv0SDlw9Ya_J_=
p{-aI+&sVh8AXZgo@^Ym@^W;wJQ<3sf8Bxc^KF5CcU%hwSe*yPC7a#xt
literal 0
HcmV?d00001
diff --git a/gitk-git/gitk.ppm b/gitk-git/gitk.ppm
new file mode 100644
index 0000000000000000000000000000000000000000..b6ea231fc8eb12827dced0cee8390bd0a2a424d1
GIT binary patch
literal 781
zcmWGA<1#c;Ff`*bGBxG;Kk~o<1_n3+`X0^(GBCNAA_UdbAw(G(7=Q?F5iwl28VCay
X7icDa1!%GmH^5CJh6{K0U|;|M>w9nk
literal 0
HcmV?d00001
diff --git a/gitk-git/gitk.xbm b/gitk-git/gitk.xbm
new file mode 100644
index 0000000..ce5871d
--- /dev/null
+++ b/gitk-git/gitk.xbm
@@ -0,0 +1,6 @@
+#define gitk_width 16
+#define gitk_height 16
+static char gitk_bits[] = {
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xDE, 0x7B,
+ 0xDE, 0x7B, 0x00, 0x00, 0x00, 0x00, 0x8C, 0x31, 0xDE, 0x7B, 0xDE, 0x7B,
+ 0x8C, 0x31, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, };
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH v2 09/11] gitweb: git_is_head_detached() function
From: Jakub Narebski @ 2008-11-15 23:43 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1226616555-24503-10-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, 13 Nov 2008, Giuseppe Bilotta wrote:
> The function checks if the HEAD for the current project is detached by
> checking if 'git branch' returns "* (no branch)"
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
In my opinion this patch should really be squashed together with
previous one. They belong together.
> ---
> gitweb/gitweb.perl | 13 +++++++++----
> 1 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index a168f6f..ceb0271 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1844,6 +1844,13 @@ sub git_get_head_hash {
> return $retval;
> }
>
> +# check if current HEAD is detached
> +sub git_is_head_detached {
> + my @x = (git_cmd(), 'branch');
> + my @ret = split("\n", qx(@x));
> + return 0 + grep { /^\* \(no branch\)$/ } @ret;
> +}
First, not git-branch. Second, you can use Perl-only solution:
+# check if current HEAD is detached
+sub git_is_head_detached {
+ my $head_file = "$project/HEAD";
+ return if -l $head_file; # symlink
+ open my $fd, '<', $head_file
+ or return;
+ my $head_hash = <$fd>;
+ close $fd;
+ return if $head_hash =~ /^ref: /;
+ return $head_hash;
+}
Alternate solution would be to create git_get_symbolic_ref, and use
"!defined $current_branch" in place of "git_is_head_detached()".
> +
> # get type of given object
> sub git_get_type {
> my $hash = shift;
> @@ -2673,11 +2680,9 @@ sub git_get_heads_list {
> my @headslist;
>
> if (grep { $_ eq 'heads' } @class) {
> - my @x = (git_cmd(), 'branch');
> - my @ret = split("\n", qx(@x));
> - if (grep { /^\* \(no branch\)$/ } @ret) { ;
> + if (git_is_head_detached()) {
> my %ref_item;
> - @x = (git_cmd(), 'log', '-1', '--pretty=format:%H%n%ct%n%s');
> + my @x = (git_cmd(), 'log', '-1', '--pretty=format:%H%n%ct%n%s');
Hmmm... git-log, git-show, or perhaps parse_commit?
> my ($hash, $epoch, $title) = split("\n", qx(@x), 3);
>
> $ref_item{'class'} = 'head';
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] gitk: Highlight found text only for when search type is "containing".
From: Mark Burton @ 2008-11-15 23:12 UTC (permalink / raw)
To: git; +Cc: Mark Burton
Highlighting the text in the commit list and comments that match the find
string is useful but only really when the search type is "containing".
This patch suppresses the highlighting for the other search types.
Signed-off-by: Mark Burton <markb@ordern.com>
---
gitk-git/gitk | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 3353f4a..dea8bc8 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -4302,6 +4302,7 @@ proc askfindhighlight {row id} {
global nhighlights commitinfo iddrawn
global findloc
global markingmatches
+ global gdttype
if {![info exists commitinfo($id)]} {
getcommit $id
@@ -4326,7 +4327,7 @@ proc askfindhighlight {row id} {
bolden_name $row mainfontbold
}
}
- if {$markingmatches} {
+ if {$markingmatches && $gdttype eq [mc "containing:"]} {
markrowmatches $row $id
}
}
@@ -5565,6 +5566,7 @@ proc drawcmitrow {row} {
global filehighlight fhighlights findpattern nhighlights
global hlview vhighlights
global highlight_related rhighlights
+ global gdttype
if {$row >= $numcommits} return
@@ -5595,7 +5597,7 @@ proc drawcmitrow {row} {
set iddrawn($id) 1
incr nrows_drawn
}
- if {$markingmatches} {
+ if {$markingmatches && $gdttype eq [mc "containing:"]} {
markrowmatches $row $id
}
}
@@ -6227,7 +6229,8 @@ proc findselectline {l} {
set markingmatches 1
set findcurline $l
selectline $l 1
- if {$findloc == [mc "All fields"] || $findloc == [mc "Comments"]} {
+ if {$gdttype eq [mc "containing:"] &&
+ ($findloc == [mc "All fields"] || $findloc == [mc "Comments"])} {
# highlight the matches in the comments
set f [$ctext get 1.0 $commentend]
set matches [findmatches $f]
--
1.6.0.4
^ permalink raw reply related
* Re: Any overview available on jgit codebase?
From: Shawn O. Pearce @ 2008-11-15 23:15 UTC (permalink / raw)
To: Farrukh Najmi; +Cc: Kyle Moffett, Robin Rosenberg, git
In-Reply-To: <491F2F5E.20206@wellfleetsoftware.com>
Farrukh Najmi <farrukh@wellfleetsoftware.com> wrote:
>
> At minimum could anyone tell me what packages and classes to look at in
> order to make changes to jgit so it uses a database instead of
> filesystem to references.
See RefDatabase, created by Repository. You would want to replace
RefDatabase with your own implementation, which means abstracting
that class to be an abstract base class or an interface.
RefUpdate and RefLogWriter are connected to RefDatabase, so you
would likely need to modify those too in order to make the change,
especially since RefUpdate is the "INSERT OR UPDATE OR DELETE"
logic. :)
BTW, I want to do that RefDatabase abstraction anyway, because I'd
like to get an in-memory only version of RefDatabase, to make unit
testing easier. So abstracting this code may be useful beyond just
your desire to back Git with a JDBC-style database.
--
Shawn.
^ permalink raw reply
* Re: [PATCH v2 08/11] gitweb: display HEAD in heads list when detached
From: Jakub Narebski @ 2008-11-15 22:31 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1226616555-24503-9-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, 13 Nov 2008, Giuseppe Bilotta wrote:
First, I think that _at least_ the first two patches dealing with
detached should be squashed.
Second, not this way!
But I think that support for detached HEAD (I am not sure if it should
have to be explicitly turned on using some %feature, or reusing some
existing feature like 'remote_heads') is a very good idea. Especially
for git-instaweb.
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> gitweb/gitweb.perl | 21 +++++++++++++++++++++
> 1 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 09728cb..a168f6f 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2672,6 +2672,27 @@ sub git_get_heads_list {
> my @refs = map { "refs/$_" } @class;
> my @headslist;
>
> + if (grep { $_ eq 'heads' } @class) {
First, IMHO layering violation. Resolving detached HEAD should not be
in my opinion left to git_get_heads_list, which is wrapped around
git-for-each-ref, which for some reason (contrary for example to
"git ls-remote ." or "git show-ref -h") doesn't show HEAD even if it
is detached. Probably misfeature / a bug in git-for-each-ref. I guess
that we should resolve detached HEAD in caller.
But I am not sure about this decision. Maybe instead of showing
detached HEAD (if it is detached) for 'heads', we should show it if
there is 'HEAD' in @class (well, @refs would have to be corrected,
too)?
> + my @x = (git_cmd(), 'branch');
> + my @ret = split("\n", qx(@x));
^^^^^^^- bit strange
Especially compared to almost everywhere else using open ... "-|"
> + if (grep { /^\* \(no branch\)$/ } @ret) { ;
^
WTF? -------------------------|
Second, if we go the route of manually resolving detached HEAD,
instead of adding [-h|--head] (from git-show-ref) option equivalent
to git-for-each-ref, which would work only for detached HEAD (fixing
kind of a bug), this is *not* the way to do it.
A. It should be done using encapsulation, adding is_HEAD_detached() or
git_is_head_detached() subroutine (squashing the next patch), or
simply using !defined($current_branch), where $current_branch would
be set using git_get_symbolic_ref('HEAD') or something.
B. Using porcelain, especially end-user porcelain such as git-branch,
which can change its output format (because they are porcelain). Use
equivalent plumbing, be if git-symbolic-ref ("git symbolic-ref -q HEAD"
to be more exact) to get current branch name[1], or just simply do
that in Perl: check if it is symlink, or if it starts with "ref: "
if it is regular file (IIRC HEAD, even detached HEAD, cannot get
packed into .git/packed-refs and deleted... at least I think so).
[1] This means that we have better way of detecting (and showing)
which branch is current one than comparing sha1 with resolved HEAD.
($head_hash).
> + my %ref_item;
> + @x = (git_cmd(), 'log', '-1', '--pretty=format:%H%n%ct%n%s');
> + my ($hash, $epoch, $title) = split("\n", qx(@x), 3);
Errr... if we don't fix git-for-each-ref, and go that route, why not
simply use parse_commit subroutine, and extract relevant info from
there, instead of handcrafting git-log (why not git-show?) call?
You get more info than needed, but I think the cost of getting it is
almost the same, and you can reuse existing code.
And if we go --pretty=format:<...> or --pretty=tformat:<...> route for
git-log, git-rev-list or git-show, wouldn't it be possible to generate
the same output format as git-for-each-ref below?
> +
> + $ref_item{'class'} = 'head';
> + $ref_item{'name'} = 'HEAD';
> + $ref_item{'id'} = $hash;
> + $ref_item{'title'} = $title || '(no commit message)';
> + if ($ref_item{'epoch'} = $epoch) {
> + $ref_item{'age'} = age_string(time - $ref_item{'epoch'});
Hmmm...
> + } else {
> + $ref_item{'age'} = "unknown";
> + }
> + push @headslist, \%ref_item;
> + }
> + }
> +
> open my $fd, '-|', git_cmd(), 'for-each-ref',
> ($limit ? '--count='.($limit+1) : ()), '--sort=-committerdate',
> '--format=%(objectname) %(refname) %(subject)%00%(committer)',
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* What's in git.git (Nov 2008, #03; Sat, 15)
From: Junio C Hamano @ 2008-11-15 22:12 UTC (permalink / raw)
To: git
Consider that the tip of 'master' is 1.6.1-rc0, although I haven't tagged
it as such. There are a handful more topics cooking in 'next' and they
are worthy of being in 1.6.1 final.
* The 'maint' branch has these fixes since the last announcement.
Brandon Casey (1):
revision.c: use proper data type in call to sizeof() within xrealloc
Christian Couder (1):
Documentation: fix links to "everyday.html"
Jan Krüger (1):
Documentation: git-svn: fix example for centralized SVN clone
Linus Torvalds (1):
date/time: do not get confused by fractional seconds
* The 'master' branch has these since the last announcement
in addition to the above.
Alexander Gavrilov (14):
gitk: Allow forcing branch creation if it already exists
gitk: Fix file list context menu for merge commits
gitk: Allow starting gui blame for a specific line
gitk: Add Return and Escape bindings to dialogs
gitk: Make gitk dialog windows transient
gitk: Make cherry-pick call git-citool on conflicts
gitk: Implement a user-friendly Edit View dialog
git-gui: Fix focus transition in the blame viewer.
git-gui: Add the Show SSH Key item to the clone dialog.
git-gui: Request blame metadata in utf-8.
gitk: Add accelerators to frequently used menu commands
gitk: Fix transient windows on Win32 and MacOS
gitk: Fix commit encoding support
Documentation: New GUI configuration and command-line options.
Brandon Casey (10):
t7700: demonstrate mishandling of objects in packs with a .keep file
packed_git: convert pack_local flag into a bitfield and add pack_keep
pack-objects: new option --honor-pack-keep
repack: don't repack local objects in packs with .keep file
repack: do not fall back to incremental repacking with [-a|-A]
builtin-gc.c: use new pack_keep bitfield to detect .keep file existence
t7700: demonstrate mishandling of loose objects in an alternate ODB
sha1_file.c: split has_loose_object() into local and non-local
counterparts
pack-objects: extend --local to mean ignore non-local loose objects too
t7700: test that 'repack -a' packs alternate packed objects
Brian Gernhardt (1):
Avoid using non-portable `echo -n` in tests.
David M. Syzdek (4):
Build: add NO_UINTMAX_T to support ancient systems
Add Makefile check for FreeBSD 4.9-SECURITY
Make Pthread link flags configurable
Add autoconf tests for pthreads
Davide Libenzi (1):
xdiff: give up scanning similar lines early
Deskin Miller (2):
git-svn: proper detection of bare repositories
git-svn: proper detection of bare repositories
Eric Wong (4):
git-svn: don't escape tilde ('~') for http(s) URLs
git-svn: respect i18n.commitencoding config
git-svn: don't escape tilde ('~') for http(s) URLs
git-svn: respect i18n.commitencoding config
Giuseppe Bilotta (3):
gitweb: make the supported snapshot formats array global
gitweb: retrieve snapshot format from PATH_INFO
gitweb: embed snapshot format parameter in PATH_INFO
Jakub Narebski (1):
gitweb: Better processing format string in custom links in navbar
Jeff King (11):
diff: add missing static declaration
document the diff driver textconv feature
refactor userdiff textconv code
userdiff: require explicitly allowing textconv
only textconv regular files
wt-status: load diff ui config
add userdiff textconv tests
enable textconv for diff in verbose status/commit
t5516: refactor oddball tests
receive-pack: detect push to current branch of non-bare repo
commit: Fix stripping of patch in verbose mode.
Junio C Hamano (3):
t5303: work around printf breakage in dash
t5303: fix printf format string for portability
Update draft release notes to 1.6.1
Linus Torvalds (4):
Add a 'source' decorator for commits
revision: make tree comparison functions take commits rather than trees
Make '--decorate' set an explicit 'show_decorations' flag
revision traversal: '--simplify-by-decoration'
Marten Svanfeldt (dev) (2):
Git.pm: Make _temp_cache use the repository directory
git-svn: Update git-svn to use the ability to place temporary files
within repository directory
Martin Koegler (1):
git push: Interpret $GIT_DIR/branches in a Cogito compatible way
Miklos Vajna (4):
Implement git remote rename
remote: add a new 'origin' variable to the struct
git-remote rename: migrate from remotes/ and branches/
git-remote: document the migration feature of the rename subcommand
Nanako Shiraishi (2):
Document "git log --source"
Document "git log --simplify-by-decoration"
Nicolas Pitre (9):
close another possibility for propagating pack corruption
better validation on delta base object offsets
make unpack_object_header() non fatal
make packed_object_info() resilient to pack corruptions
make check_object() resilient to pack corruptions
make find_pack_revindex() aware of the nasty world
pack-objects: allow "fixing" a corrupted pack without a full repack
extend test coverage for latest pack corruption resilience improvements
pack-objects: don't leak pack window reference when splitting packs
Paul Mackerras (8):
gitk: Fix some off-by-one errors in computing which line to blame
gitk: Add a menu item to show where a given line comes from
gitk: Make the background color of marked lines configurable
gitk: Unify handling of merge diffs with normal 2-way diffs
gitk: Make "show origin of this line" work on fake commits
gitk: Cope with unmerged files in local changes
gitk: Improve cherry-pick error handling
gitk: Fix linehtag undefined error with file highlighting
Samuel Tardieu (2):
tag: Check that options are only allowed in the appropriate mode
tag: Add more tests about mixing incompatible modes and options
Santi Béjar (1):
rev-list documentation: clarify the two parts of history simplification
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Pierre Habouzit @ 2008-11-15 22:12 UTC (permalink / raw)
To: Miklos Vajna
Cc: Junio C Hamano, Shawn O. Pearce, Linus Torvalds, Andreas Ericsson,
Git Mailing List
In-Reply-To: <20081115193327.GS24201@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]
On Sat, Nov 15, 2008 at 07:33:27PM +0000, Miklos Vajna wrote:
> On Sat, Nov 15, 2008 at 05:00:52AM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> > Under LGPL, you must provide linkable object files to your (possibly
> > closed source) program, so that people who made changes to (or obtained an
> > updated version of) a LGPL'ed library can re-link your program and use the
> > updated library. The above does not ask you to do so.
> >
> > The way I read LGPL is that "We deeply care about our LGPL library and any
> > improvements to it. Although we do not care at all about how your crappy
> > closed source program is written, we want to make sure that the users can
> > keep using your program after improvements are made to our library.". I
> > do not think it makes a practical difference when your program uses the
> > LGPL library as a shard library from that point of view.
>
> Ah, I see - so this is a "Lesser LGPL". :)
LGPL also has a clause that allow the user to make it become GPLv2 or
later, even if you chose LGPL v2.1 *only* (as in not LGPL v2.1 or later).
Seeing how the FSF has just decided to use those upgrade clauses with
the GFDL, I'm not really likely to fancy the use of any license that
forces me to accept an "or later" clause. I would be _really_ against
the LGPL FWIW.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Re* [take 2] git send-email updates
From: Pierre Habouzit @ 2008-11-15 22:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxlwlcid.fsf_-_@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 374 bytes --]
On Thu, Nov 13, 2008 at 12:01:46AM +0000, Junio C Hamano wrote:
> This patch on top of your [2/4] illustrates what I had in mind (it also
> removes the "print foo" while at it).
I like it.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [take 2] git send-email updates
From: Pierre Habouzit @ 2008-11-15 22:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5b9x0kj.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2927 bytes --]
On Wed, Nov 12, 2008 at 12:14:20AM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > Oh you mean that if one use --no-format-patch you don't wan't _any_
> > option to be passed to format-patch?
>
> The option name --no-format-patch sounded like "I do not want you to act
> as a frontend, ever", i.e. if you type master..next by mistake on the
> command line, the command would barf when the option is given. Not even
> "pass to format-patch", but "do not run format-patch to begin with".
>
> It is not a big deal especially for interactive use (and that is why I
> said "somewhat" unfortunate).
>
> > If we're really doing this, then maybe we want a 5-state kind of option:
> > 1 disallow any file name ;
> > 2 if conflict, chose the revision ;
> > 3 barf if any conflict arises (default) ;
> > 4 if conflict chose the file ;
> > 5 disallow any kind of revision argument.
> >
> > My proposal implements 2 as --format-patch, 3 as default, and 4 as
> > --no-format-patch. You propose basically (5) for --no-format-patch
> > instead, well I say this makes sense, but it's somehow "sad" not to have
> > (1) too in that case.
>
> Actually, "send-email --format-patch master..fixes Documentation/" may be
> a useful command to send out only documentation fixes. For such a usage,
> Documentation/ should not be taken as a maildir. If we would want to
> support such usage (and I'd say why not), a token can fall into one (or
> two) of three categories:
You can do that doing:
git send-email --format-patch master..fixes -- Documentation/
I've kept the `--` usual meaning, and it's sent to git-format-patch
verbatim and it'll work, so it's not required to change the meaning of
the options for that.
[sorry for the late reply, I've been somehow busy lately]
The sole conflict we have is when there is a path/rev conflict *before*
the `--` because of the legacy of git-send-email. I believe that
--format-patch should still allow to send patches passed on the command
line, this way.
> As to options, how about doing this:
>
> --no-format-patch means never ever run format-patch, behave exactly as
> before;
>
> --format-patch means what you have in your patch. guess and favor
> format-patch parameter when ambiguous;
>
> without either option, guess and favor mbox/maildir but still run
> format-patch if remaining parameters and options need to
> (e.g. "send-email my-cover-letter origin/master..master" will find
> my-cover-letter which is not tracked and take it as mbox, and grab
> patches from commits between origin/master..master, and send all of
> them).
That's sane and I like it.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Any overview available on jgit codebase?
From: Farrukh Najmi @ 2008-11-15 20:21 UTC (permalink / raw)
To: Kyle Moffett; +Cc: Robin Rosenberg, git
In-Reply-To: <f73f7ab80811140638m4045cf83p311c593aff066002@mail.gmail.com>
I am looking for any available docs that will help me learn the layout
of the jgit code base.
In the ideal world here is what would help newbies get productive with
the project quickly:
1. Have a clear one line description available in the javadocs for each
package.
2. Have a clear one line description available in javadocs for each
class in each package.
3. Have a clear one line description available in javadocs for each
method in each class.
I would gladly do this and contribute the changes back but its a chicken
and egg situation since I do not know the code base.
I realize its a lot to ask but would anyone familiar with code base
volunteer to do at least (1) above?
At minimum could anyone tell me what packages and classes to look at in
order to make changes to jgit so it uses a database instead of
filesystem to references.
Lastly, where can I find information on the structure of the .git directory?
Thanks for your help.
Kyle Moffett wrote:
> On Thu, Nov 13, 2008 at 3:27 PM, Farrukh Najmi
> <farrukh@wellfleetsoftware.com> wrote:
>
>> The problem I am trying to solve is this. In my service I need to store
>> metadata in a relational db and content in git such that both either commit
>> or not in a single transaction. If one commits and the other does not that
>> is a serious integrity issue. Seems to me, two phase commit would be the
>> right solution for that in the long run. This what JDBC + JMS topologies do.
>>
>
> That's really easy! First tweak jgit so that *instead* of using
> .git/refs, it uses your database to store references and exports them
> on a routine basis to .git/refs for debugging purposes. Then, for
> each database update:
>
> (1) Start transaction
> (2) Commit the change to GIT (adds ref update to the transaction)
> (3) Make other metadata updates
> (4) Commit transaction
>
> Then set up periodic garbage collection and you're done! If the
> transaction is aborted, there will simply be a bunch of random loose
> objects in the git repository, which will be cleaned up the next time
> you garbage collect. The ref update will be atomic and conditional
> with the rest of the transaction, and in git the *only* part that
> really matters for atomicity is the ref.
>
> Cheers,
> Kyle Moffett
>
>
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Miklos Vajna @ 2008-11-15 19:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: Shawn O. Pearce, Linus Torvalds, Andreas Ericsson,
Git Mailing List
In-Reply-To: <7vk5b55ekb.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 899 bytes --]
On Sat, Nov 15, 2008 at 05:00:52AM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> Under LGPL, you must provide linkable object files to your (possibly
> closed source) program, so that people who made changes to (or obtained an
> updated version of) a LGPL'ed library can re-link your program and use the
> updated library. The above does not ask you to do so.
>
> The way I read LGPL is that "We deeply care about our LGPL library and any
> improvements to it. Although we do not care at all about how your crappy
> closed source program is written, we want to make sure that the users can
> keep using your program after improvements are made to our library.". I
> do not think it makes a practical difference when your program uses the
> LGPL library as a shard library from that point of view.
Ah, I see - so this is a "Lesser LGPL". :)
Thank you both Junio and David.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Teach/Fix pull/fetch -q/-v options
From: Tuncer Ayaz @ 2008-11-15 19:23 UTC (permalink / raw)
To: git; +Cc: gitster
Implement git-pull --quiet and git-pull --verbose by
adding the options to git-pull and fixing verbosity
handling in git-fetch.
Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>
---
Documentation/merge-options.txt | 8 +++++
builtin-fetch.c | 19 ++++++------
builtin-merge.c | 21 +++++++++----
git-pull.sh | 10 ++++--
parse-options.c | 22 ++++++++++++++
parse-options.h | 6 ++++
t/t5521-pull-options.sh | 60 +++++++++++++++++++++++++++++++++++++++
7 files changed, 126 insertions(+), 20 deletions(-)
create mode 100755 t/t5521-pull-options.sh
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 007909a..427cdef 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -1,3 +1,11 @@
+-q::
+--quiet::
+ Operate quietly.
+
+-v::
+--verbose::
+ Be verbose.
+
--stat::
Show a diffstat at the end of the merge. The diffstat is also
controlled by the configuration option merge.stat.
diff --git a/builtin-fetch.c b/builtin-fetch.c
index f151cfa..7568163 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -22,7 +22,7 @@ enum {
TAGS_SET = 2
};
-static int append, force, keep, update_head_ok, verbose, quiet;
+static int append, force, keep, update_head_ok, verbosity;
static int tags = TAGS_DEFAULT;
static const char *depth;
static const char *upload_pack;
@@ -30,8 +30,7 @@ static struct strbuf default_rla = STRBUF_INIT;
static struct transport *transport;
static struct option builtin_fetch_options[] = {
- OPT__QUIET(&quiet),
- OPT__VERBOSE(&verbose),
+ OPT__VERBOSITY(&verbosity),
OPT_BOOLEAN('a', "append", &append,
"append to .git/FETCH_HEAD instead of overwriting"),
OPT_STRING(0, "upload-pack", &upload_pack, "PATH",
@@ -192,7 +191,6 @@ static int s_update_ref(const char *action,
static int update_local_ref(struct ref *ref,
const char *remote,
- int verbose,
char *display)
{
struct commit *current = NULL, *updated;
@@ -210,7 +208,7 @@ static int update_local_ref(struct ref *ref,
die("object %s not found", sha1_to_hex(ref->new_sha1));
if (!hashcmp(ref->old_sha1, ref->new_sha1)) {
- if (verbose)
+ if (verbosity > 0)
sprintf(display, "= %-*s %-*s -> %s", SUMMARY_WIDTH,
"[up to date]", REFCOL_WIDTH, remote,
pretty_ref);
@@ -366,18 +364,19 @@ static int store_updated_refs(const char *url, const char *remote_name,
note);
if (ref)
- rc |= update_local_ref(ref, what, verbose, note);
+ rc |= update_local_ref(ref, what, note);
else
sprintf(note, "* %-*s %-*s -> FETCH_HEAD",
SUMMARY_WIDTH, *kind ? kind : "branch",
REFCOL_WIDTH, *what ? what : "HEAD");
if (*note) {
- if (!shown_url) {
+ if (verbosity >= 0 && !shown_url) {
fprintf(stderr, "From %.*s\n",
url_len, url);
shown_url = 1;
}
- fprintf(stderr, " %s\n", note);
+ if (verbosity >= 0)
+ fprintf(stderr, " %s\n", note);
}
}
fclose(fp);
@@ -637,9 +636,9 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
remote = remote_get(argv[0]);
transport = transport_get(remote, remote->url[0]);
- if (verbose >= 2)
+ if (verbosity >= 2)
transport->verbose = 1;
- if (quiet)
+ if (verbosity < 0)
transport->verbose = -1;
if (upload_pack)
set_option(TRANS_OPT_UPLOADPACK, upload_pack);
diff --git a/builtin-merge.c b/builtin-merge.c
index 5e7910b..7c2b90c 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -50,6 +50,7 @@ static unsigned char head[20], stash[20];
static struct strategy **use_strategies;
static size_t use_strategies_nr, use_strategies_alloc;
static const char *branch;
+static int verbosity;
static struct strategy all_strategy[] = {
{ "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL },
@@ -171,6 +172,7 @@ static struct option builtin_merge_options[] = {
OPT_CALLBACK('m', "message", &merge_msg, "message",
"message to be used for the merge commit (if any)",
option_parse_message),
+ OPT__VERBOSITY(&verbosity),
OPT_END()
};
@@ -250,7 +252,8 @@ static void restore_state(void)
/* This is called when no merge was necessary. */
static void finish_up_to_date(const char *msg)
{
- printf("%s%s\n", squash ? " (nothing to squash)" : "", msg);
+ if (verbosity >= 0)
+ printf("%s%s\n", squash ? " (nothing to squash)" : "", msg);
drop_save();
}
@@ -331,14 +334,15 @@ static void finish(const unsigned char *new_head, const char *msg)
if (!msg)
strbuf_addstr(&reflog_message, getenv("GIT_REFLOG_ACTION"));
else {
- printf("%s\n", msg);
+ if (verbosity >= 0)
+ printf("%s\n", msg);
strbuf_addf(&reflog_message, "%s: %s",
getenv("GIT_REFLOG_ACTION"), msg);
}
if (squash) {
squash_message();
} else {
- if (!merge_msg.len)
+ if (verbosity >= 0 && !merge_msg.len)
printf("No merge message -- not updating HEAD\n");
else {
const char *argv_gc_auto[] = { "gc", "--auto", NULL };
@@ -872,6 +876,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, builtin_merge_options,
builtin_merge_usage, 0);
+ if (verbosity < 0)
+ show_diffstat = 0;
if (squash) {
if (!allow_fast_forward)
@@ -1013,10 +1019,11 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
strcpy(hex, find_unique_abbrev(head, DEFAULT_ABBREV));
- printf("Updating %s..%s\n",
- hex,
- find_unique_abbrev(remoteheads->item->object.sha1,
- DEFAULT_ABBREV));
+ if (verbosity >= 0)
+ printf("Updating %s..%s\n",
+ hex,
+ find_unique_abbrev(remoteheads->item->object.sha1,
+ DEFAULT_ABBREV));
strbuf_addstr(&msg, "Fast forward");
if (have_message)
strbuf_addstr(&msg,
diff --git a/git-pull.sh b/git-pull.sh
index 664fe34..a9dc713 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -16,13 +16,17 @@ cd_to_toplevel
test -z "$(git ls-files -u)" ||
die "You are in the middle of a conflicted merge."
-strategy_args= no_stat= no_commit= squash= no_ff= log_arg=
+strategy_args= no_stat= no_commit= squash= no_ff= log_arg= verbosity=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short=$(echo "$curr_branch" | sed "s|refs/heads/||")
rebase=$(git config --bool branch.$curr_branch_short.rebase)
while :
do
case "$1" in
+ -q|--quiet)
+ verbosity=-q ;;
+ -v|--verbose)
+ verbosity="$verbosity -v" ;;
-n|--no-stat|--no-summary)
no_stat=-n ;;
--stat|--summary)
@@ -121,7 +125,7 @@ test true = "$rebase" && {
"refs/remotes/$origin/$reflist" 2>/dev/null)"
}
orig_head=$(git rev-parse --verify HEAD 2>/dev/null)
-git fetch --update-head-ok "$@" || exit 1
+git fetch $verbosity --update-head-ok "$@" || exit 1
curr_head=$(git rev-parse --verify HEAD 2>/dev/null)
if test -n "$orig_head" && test "$curr_head" != "$orig_head"
@@ -182,4 +186,4 @@ test true = "$rebase" &&
exec git-rebase $strategy_args --onto $merge_head \
${oldremoteref:-$merge_head}
exec git-merge $no_stat $no_commit $squash $no_ff $log_arg $strategy_args \
- "$merge_name" HEAD $merge_head
+ "$merge_name" HEAD $merge_head $verbosity
diff --git a/parse-options.c b/parse-options.c
index fd08bb4..9eb55cc 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -484,6 +484,28 @@ int parse_opt_approxidate_cb(const struct option *opt, const char *arg,
return 0;
}
+int parse_opt_verbosity_cb(const struct option *opt, const char *arg,
+ int unset)
+{
+ int *target = opt->value;
+
+ if (unset)
+ /* --no-quiet, --no-verbose */
+ *target = 0;
+ else if (opt->short_name == 'v') {
+ if (*target >= 0)
+ (*target)++;
+ else
+ *target = 1;
+ } else {
+ if (*target <= 0)
+ (*target)--;
+ else
+ *target = -1;
+ }
+ return 0;
+}
+
/*
* This should really be OPTION_FILENAME type as a part of
* parse_options that take prefix to do this while parsing.
diff --git a/parse-options.h b/parse-options.h
index 5199950..034162e 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -150,9 +150,15 @@ extern int parse_options_end(struct parse_opt_ctx_t *ctx);
/*----- some often used options -----*/
extern int parse_opt_abbrev_cb(const struct option *, const char *, int);
extern int parse_opt_approxidate_cb(const struct option *, const char *, int);
+extern int parse_opt_verbosity_cb(const struct option *, const char *, int);
#define OPT__VERBOSE(var) OPT_BOOLEAN('v', "verbose", (var), "be verbose")
#define OPT__QUIET(var) OPT_BOOLEAN('q', "quiet", (var), "be quiet")
+#define OPT__VERBOSITY(var) \
+ { OPTION_CALLBACK, 'v', "verbose", (var), NULL, "be more verbose", \
+ PARSE_OPT_NOARG, &parse_opt_verbosity_cb, 0 }, \
+ { OPTION_CALLBACK, 'q', "quiet", (var), NULL, "be more quiet", \
+ PARSE_OPT_NOARG, &parse_opt_verbosity_cb, 0 }
#define OPT__DRY_RUN(var) OPT_BOOLEAN('n', "dry-run", (var), "dry run")
#define OPT__ABBREV(var) \
{ OPTION_CALLBACK, 0, "abbrev", (var), "n", \
diff --git a/t/t5521-pull-options.sh b/t/t5521-pull-options.sh
new file mode 100755
index 0000000..83e2e8a
--- /dev/null
+++ b/t/t5521-pull-options.sh
@@ -0,0 +1,60 @@
+#!/bin/sh
+
+test_description='pull options'
+
+. ./test-lib.sh
+
+D=`pwd`
+
+test_expect_success 'setup' '
+ mkdir parent &&
+ (cd parent && git init &&
+ echo one >file && git add file &&
+ git commit -m one)
+'
+
+cd "$D"
+
+test_expect_success 'git pull -q' '
+ mkdir clonedq &&
+ cd clonedq &&
+ git pull -q "$D/parent" >out 2>err &&
+ test ! -s out
+'
+
+cd "$D"
+
+test_expect_success 'git pull' '
+ mkdir cloned &&
+ cd cloned &&
+ git pull "$D/parent" >out 2>err &&
+ test -s out
+'
+cd "$D"
+
+test_expect_success 'git pull -v' '
+ mkdir clonedv &&
+ cd clonedv &&
+ git pull -v "$D/parent" >out 2>err &&
+ test -s out
+'
+
+cd "$D"
+
+test_expect_success 'git pull -v -q' '
+ mkdir clonedvq &&
+ cd clonedvq &&
+ git pull -v -q "$D/parent" >out 2>err &&
+ test ! -s out
+'
+
+cd "$D"
+
+test_expect_success 'git pull -q -v' '
+ mkdir clonedqv &&
+ cd clonedqv &&
+ git pull -q -v "$D/parent" >out 2>err &&
+ test -s out
+'
+
+test_done
--
1.6.0.2.GIT
^ permalink raw reply related
* Re: [PATCH] Teach/Fix pull/fetch -q/-v options
From: Tuncer Ayaz @ 2008-11-15 19:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <4ac8254d0811150942s7d4f5444xbc2b068beecbb44f@mail.gmail.com>
On Sat, Nov 15, 2008 at 6:42 PM, Tuncer Ayaz <tuncer.ayaz@gmail.com> wrote:
> On Sat, Nov 15, 2008 at 2:15 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> @@ -637,9 +638,9 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
>>> remote = remote_get(argv[0]);
>>>
>>> transport = transport_get(remote, remote->url[0]);
>>> - if (verbose >= 2)
>>> + if (verbosity == VERBOSE)
>>> transport->verbose = 1;
>>> - if (quiet)
>>> + if (verbosity == QUIET)
>>> transport->verbose = -1;
>>> if (upload_pack)
>>> set_option(TRANS_OPT_UPLOADPACK, upload_pack);
>>
>> In the original code, the variable verbose can be ">= 2" when "-v -v" is
>> given, so transport->verbose is not turned on with a single "-v" alone
>> (this correctly mimics the original behaviour in the scripted version).
>>
>
> Doesn't this also mean that we need to be able to concatenate
> multiple -v options in git-pull.sh similar to what one of the first
> versions of my patch did?
>
> <snip>
>
The next patch revision arriving here in a minute or two
will do the following in git-pull.sh:
1) if -q then verbosity=-q
2) if -v then verbosity=verbosity + -v
This means that git pull -v -q will reset verbosity to -q
and allow counting of -v instances. If this is not desired
or incorrect another change is needed :-).
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: David Brown @ 2008-11-15 18:53 UTC (permalink / raw)
To: Pau Garcia i Quiles; +Cc: Git Mailing List
In-Reply-To: <3af572ac0811150228k291b8850idc34cb474f455aa7@mail.gmail.com>
On Sat, Nov 15, 2008 at 11:28:39AM +0100, Pau Garcia i Quiles wrote:
>> Shawn posted the exact text. The spirit of that license is that anyone can
>> use an unmodified version of the library for whatever they want, but it's
>> illegal to link non-GPL software to an altered version of the library. That
>> is, the git community will get all changes back while other projects can
>> use the official version of the library without having to worry about
>> licensing issues. EvilCompany cannot make changes to the library and then
>> link non-GPL'd software to their changed version. They can do that if they
>> send their library changes upstream and then only use them once they're
>> considered "official" though.
>
>Do you mean if I write a patch to libgit2, send it upstream and make
>it public on my website but it is not accepted upstream, I cannot link
>my modified libgit2 version (i. e. libgit2 + my patch) to my non-GPL
>software? It looks insane to me: I wrote the patch and made it public
>but you guys did not accept it!
The license is not clear on this, at all. Since under the GPLv2, you
are allowed to make a derivative work, and distribute that, you are
then basing your binary off of your particular distribution. The
license does not have a notion of an "official" version. So, it might
be satisfied as long as you base it off of something that is
distributed.
But, yes, it is vaguely worded and unclear in it's intent.
David
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: David Brown @ 2008-11-15 18:49 UTC (permalink / raw)
To: Miklos Vajna
Cc: Shawn O. Pearce, Linus Torvalds, Andreas Ericsson,
Git Mailing List
In-Reply-To: <20081115123916.GN24201@genesis.frugalware.org>
On Sat, Nov 15, 2008 at 01:39:16PM +0100, Miklos Vajna wrote:
>On Fri, Nov 14, 2008 at 03:46:58PM -0800, "Shawn O. Pearce" <spearce@spearce.org> wrote:
>> Note that the only valid version of the GPL as far as this project
>> is concerned is _this_ particular version of the license (ie v2, not
>> v2.2 or v3.x or whatever), unless explicitly otherwise stated.
>>
>> In addition to the permissions in the GNU General Public License,
>> the authors give you unlimited permission to link the compiled
>> version of this file into combinations with other programs,
>> and to distribute those combinations without any restriction
>> coming from the use of this file. (The General Public License
>> restrictions do apply in other respects; for example, they cover
>> modification of the file, and distribution when not linked into
>> a combined executable.)
>
>IANAL - what is the difference between this and the LGPL?
This clause allows static linking, and distribution of only the final
binary. The LGPL always requires source to be made available to the
libaray. This clause does not require that source to be distributed.
In other words, it allows libgit2 to be linked into a proprietary
program and the distributor of that program to _not_ include the
source of libgit2. It is not clear if they have to provide source to
modifications that they have made, or if making those modifications
under the exception is even allowed.
There are numerous other versions of this exception, some of which
might be better worded than this.
David
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: David Brown @ 2008-11-15 18:39 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Shawn O. Pearce, Linus Torvalds, Andreas Ericsson,
Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811150256140.27509@xanadu.home>
On Sat, Nov 15, 2008 at 03:04:29AM -0500, Nicolas Pitre wrote:
>libgcc is a dynamic library on most modern systems these days. Yet they
>routinely execute non-GPL programs. If that text intentionally excluded
>the dynamic case then every non-GPL applications on such systems would
>have been breaking the license for a long time. So I don't think anyone
>could have substance for such a claim.
Sure they can. Lack of enforcement doesn't dilute copyright like it
does trademark.
It may be that the gcc authors intend for it to be allowed for dynamic
libraries, and therefore wouldn't sue for that usage, but that's not
what they're saying in their license.
What I'm saying is that if I was in a position to review the license
and determine what was permitted, this license with exception does not
appear to allow dynamic linking against the library. It doesn't
explicitly forbid this, but it is ambiguous about it.
David
^ permalink raw reply
* Fix machine-parseability of 'git log --source'
From: Linus Torvalds @ 2008-11-15 18:02 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List; +Cc: Paul Mackerras
The space between the commit and the source attribute is not easily
machine-parseable: if we combine --source with --parents and give a SHA1
as a starting point, it's unnecessarily hard to see where the list of
parents ends and the source decoration begins.
Example:
git show --parents --source $(git rev-list HEAD)
which is admittedly contrived, but can easily happen in scripting.
So use a <tab> instead of a space as the source separator.
The other decorations didn't have this issue, because they were surrounded
by parenthesis, so it's obvious that they aren't parent SHA1's.
It so happens that _visually_ this makes no difference for "git log
--source", since "commit <40-char SHA1>" is 47 characters, so both a space
and a <tab> will end up showing as a single commit. Of course, with
'--pretty=oneline' or '--parents' or '--abbrev-commit' you'll see the
difference.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
This is all partly because I also wish that 'gitk' would use --decorate to
give decorations rather than look them up by hand. I'm not entirely source
--source is useful for gitk (since it wants _all_ branches), but I do know
that I hate knowing that
gitk --source
just results in parse errors.
log-tree.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 5444f08..194ddb1 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -58,7 +58,7 @@ void show_decorations(struct rev_info *opt, struct commit *commit)
struct name_decoration *decoration;
if (opt->show_source && commit->util)
- printf(" %s", (char *) commit->util);
+ printf("\t%s", (char *) commit->util);
if (!opt->show_decorations)
return;
decoration = lookup_decoration(&name_decoration, &commit->object);
^ permalink raw reply related
* Re: [PATCH] Teach/Fix pull/fetch -q/-v options
From: Tuncer Ayaz @ 2008-11-15 17:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7i7594cx.fsf@gitster.siamese.dyndns.org>
On Sat, Nov 15, 2008 at 2:15 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> @@ -637,9 +638,9 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
>> remote = remote_get(argv[0]);
>>
>> transport = transport_get(remote, remote->url[0]);
>> - if (verbose >= 2)
>> + if (verbosity == VERBOSE)
>> transport->verbose = 1;
>> - if (quiet)
>> + if (verbosity == QUIET)
>> transport->verbose = -1;
>> if (upload_pack)
>> set_option(TRANS_OPT_UPLOADPACK, upload_pack);
>
> In the original code, the variable verbose can be ">= 2" when "-v -v" is
> given, so transport->verbose is not turned on with a single "-v" alone
> (this correctly mimics the original behaviour in the scripted version).
>
Doesn't this also mean that we need to be able to concatenate
multiple -v options in git-pull.sh similar to what one of the first
versions of my patch did?
<snip>
^ permalink raw reply
* Re: [PATCH] Teach/Fix pull/fetch -q/-v options
From: Tuncer Ayaz @ 2008-11-15 17:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3aht8z17.fsf@gitster.siamese.dyndns.org>
On Sat, Nov 15, 2008 at 4:10 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>
>>> The approach with enum { Q, N, V } cannot express this, unfortunately.
>>>
>>> So let's do something like the attached patch, instead.
>>
>> That's ok. We should not break anything.
>>
>> Do you want me to resubmit a new patch with the changes?
>
> As long as you are happy with the suggested change, there is no need to.
> You'd need to sign-off the patch, though...
>
I forgot to add -s to my commit call this time around.
I will apply your changes and repost it with the signoff.
^ permalink raw reply
* Re: [PATCH] Makefile: introduce NO_PTHREADS
From: Linus Torvalds @ 2008-11-15 17:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vtza95h01.fsf@gitster.siamese.dyndns.org>
On Sat, 15 Nov 2008, Junio C Hamano wrote:
>
> This introduces make variable NO_PTHREADS for platforms that lack the
> support for pthreads library or people who do not want to use it for
> whatever reason. When defined, it makes the multi-threaded index
> preloading into a no-op, and also disables threaded delta searching by
> pack-objects.
Ack. Makes sense.
Linus
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Martin Koegler @ 2008-11-15 17:13 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <491E021E.5020104@op5.se>
Andreas Ericsson wrote:
> Shawn posted the exact text. The spirit of that license is that anyone can
> use an unmodified version of the library for whatever they want, but it's
> illegal to link non-GPL software to an altered version of the library. That
> is, the git community will get all changes back while other projects can
> use the official version of the library without having to worry about
> licensing issues. EvilCompany cannot make changes to the library and then
> link non-GPL'd software to their changed version. They can do that if they
> send their library changes upstream and then only use them once they're
> considered "official" though.
I would not interpret the license this way. Lets look at the text:
| In addition to the permissions in the GNU General Public License,
| the authors give you unlimited permission to link the compiled
| version of this file into combinations with other programs,
| and to distribute those combinations without any restriction
| coming from the use of this file. (The General Public License
| restrictions do apply in other respects; for example, they cover
| modification of the file, and distribution when not linked into
| a combined executable.)
It's an additional permission, which allows linking into binaries and
distributing them.
Modification is still covered by the GPL text, 2b:
| You must cause any work that you distribute or publish, that in
| whole or in part contains or is derived from the Program or any
| part thereof, to be licensed as a whole at no charge to all third
| parties under the terms of this License.
So a patched version must be available unter the "this" license. In my
option, this must be GPLv2+addition permission. GPLv3 explicitly talks
about additional terms, so its clear, that they propagate. GPLv2
doesn't do this, but additional terms, like OpenSSL linkage exceptions
are usually propagated.
So EvilCompany can create their own, modified GPL+GCC exception
libgit2 version behind their doors.
Then they link it into their non-GPL software and can distribute the
resulting binary without any GPL restriction. As the exception states,
that the binary can be distributed without any restrictions coming
from the GPL+GCC exception code, this COULD mean, that clause 3 of the
GPL does not apply too (ship binary without source code).
I'm only a programmer, so you should ask people with better
understanding of legal things.
Your interpretation of the GCC exception would render it useless for
the Debian probject [and probably other projects too], which means,
that they can use/distribute libgit2 only the GPL. If you don't want
that, you should consider posting to Debian Legal
(http://lists.debian.org/debian-legal/) for advice.
mfg Martin Kögler
PS:
Have you looked at the Classpath exception:
| Linking this library statically or dynamically with other modules is
| making a combined work based on this library. Thus, the terms and
| conditions of the GNU General Public License cover the whole
| combination.
|
| As a special exception, the copyright holders of this library give you
| permission to link this library with independent modules to produce an
| executable, regardless of the license terms of these independent
| modules, and to copy and distribute the resulting executable under
| terms of your choice, provided that you also meet, for each linked
| independent module, the terms and conditions of the license of that
| module. An independent module is a module which is not derived from
| or based on this library. If you modify this library, you may extend
| this exception to your version of the library, but you are not
| obligated to do so. If you do not wish to do so, delete this
| exception statement from your version.
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Linus Torvalds @ 2008-11-15 16:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Andreas Ericsson, Git Mailing List
In-Reply-To: <20081114234658.GA2932@spearce.org>
On Fri, 14 Nov 2008, Shawn O. Pearce wrote:
>
> The language we are using in libgit2 is taken from libgcc, and is
> as follows:
Ok, I'm fine with this.
Linus
^ permalink raw reply
* Re: [PATCH 3/3] Add -k/--keep-going option to mergetool
From: Theodore Tso @ 2008-11-15 16:12 UTC (permalink / raw)
To: Charles Bailey
Cc: Jeff King, Junio C Hamano, git, Andreas Ericsson, William Pursell
In-Reply-To: <491D7C38.7070906@hashpling.org>
On Fri, Nov 14, 2008 at 01:25:12PM +0000, Charles Bailey wrote:
> Previously, if you aborted a merge, you were left with the
> base/local/remote temporaries for the merge that you aborted.
>
> To be honest, I found this a little irritating. The base, local and
> remote temporaries are inputs so are accessible from slots 1,2 and 3 of
> the index, and any intermediate output will be in the target file. You
> can git clean, but if you have other temporaries you need to keep, you
> end up having to manually clean them up in any case.
I agree. On occasion it's useful, but more often than not, keeping
the temporaries is more annoying than anything else. At the time when
I wrote mergetool, it was a pain for me to either do "git ls-files
--stage" and then cut and paste the SHA hash, or to type commands like
"git cat-file blob :1:long/pathname/from/the/top.c" to look one
various staged versions of the file.
I'd suggest that this is probably worth turning into an option
(-k|--keep-files), and default the answer to deleting the temporaries
before mergetool exits.
- Ted
^ permalink raw reply
* Re: [PATCH 3/3] Add -k/--keep-going option to mergetool
From: Theodore Tso @ 2008-11-15 15:56 UTC (permalink / raw)
To: Charles Bailey
Cc: Junio C Hamano, git, Jeff King, Andreas Ericsson, William Pursell
In-Reply-To: <1226580075-29289-4-git-send-email-charles@hashpling.org>
On Thu, Nov 13, 2008 at 12:41:15PM +0000, Charles Bailey wrote:
> This option stops git mergetool from aborting at the first failed merge.
> This allows some additional use patterns. Merge conflicts can now be
> previewed one at time and merges can also be skipped so that they can be
> performed in a later pass.
>
> There is also a mergetool.keepGoing configuration variable covering the
> same behaviour.
Instead of making this be a command-line and configuration option,
maybe it would be better to prompt the user after an aborted merge,
and give the user the opportunity to continue or abort? i.e., instead
of just saying "merge of foo.c failed" and then exiting, to ask the
user instad something like, "Merge of foo.c failed; continue
attempting to merge the rest of the files? <y>"
I suspect this might be more friendly than Yet Another command-line
option and configuration parameter. What do you think?
- Ted
^ permalink raw reply
* Re: [PATCH 2/3] Add -y/--no-prompt option to mergetool
From: Theodore Tso @ 2008-11-15 15:50 UTC (permalink / raw)
To: Charles Bailey
Cc: Junio C Hamano, git, Jeff King, Andreas Ericsson, William Pursell
In-Reply-To: <1226580075-29289-3-git-send-email-charles@hashpling.org>
On Thu, Nov 13, 2008 at 12:41:14PM +0000, Charles Bailey wrote:
> This option lets git mergetool invoke the conflict resolution program
> without waiting for a user prompt each time.
>
> Also added a mergetool.prompt (default true) configuration variable
> controlling the same behaviour
My apologies for not commeting earlier on your patches; I've been a
bit overloaded as of late --- way too much conference travel! :-(
I can see why this should perhaps be the default for gui-based merge
program. The one place where it should perhaps not be the default is if
the tool could be text based (i.e., if you are using text-based emacs
to do the emerge). So perhaps what we should do is
1) Make the question of whether or not a particular back-end merge
program should require the user to hit return first to be configured
on a per-gui tool basis.
2) For all of the gui tools default the answer to be to _not_ prompt
first.
3) For the emacs-based merge, make the default be based on whether or
not $DISPLAY is set. (But allow an overide based on
mergetool.emerge.prompt.)
I think this much more accurately would model what users want, and if
we get the default right for most users, that's definitely a win.
Regards,
- Ted
^ 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