* Re: [PATCH 1/3] log_ref_write() -- do not chomp reflog message at the first LF
From: Johannes Schindelin @ 2007-07-29 11:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sean, Benoit SIGOURE, git
In-Reply-To: <7vvec4nhfk.fsf_-_@assigned-by-dhcp.cox.net>
Hi,
On Sat, 28 Jul 2007, Junio C Hamano wrote:
> A reflog file is organized as one-line-per-entry records, and we
> enforced the file format integrity by chomping the given message
> at the first LF. This changes it to convert them to SP, which
> is more in line with the --pretty=oneline format.
Would it not be better to chop off before the first "\n", and just append
"..."? IOW something like
-- snip --
refs.c | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index 2694e70..554436b 100644
--- a/refs.c
+++ b/refs.c
@@ -1043,7 +1043,7 @@ static int log_ref_write(const char *ref_name, const unsigned char *old_sha1,
unsigned maxlen, len;
int msglen;
char *log_file, *logrec;
- const char *committer;
+ const char *committer, *postmsg;
if (log_all_ref_updates < 0)
log_all_ref_updates = !is_bare_repository();
@@ -1088,15 +1088,16 @@ static int log_ref_write(const char *ref_name, const unsigned char *old_sha1,
break;
if (*msg) {
const char *ep = strchr(msg, '\n');
- if (ep)
+ if (ep) {
msglen = ep - msg;
- else
+ postmsg = (ep[1] && !isspace(ep[1])) ? "..." : NULL;
+ } else
msglen = strlen(msg);
}
}
committer = git_committer_info(-1);
- maxlen = strlen(committer) + msglen + 100;
+ maxlen = strlen(committer) + msglen + 100 + 3;
logrec = xmalloc(maxlen);
len = sprintf(logrec, "%s %s %s\n",
sha1_to_hex(old_sha1),
@@ -1104,6 +1105,10 @@ static int log_ref_write(const char *ref_name, const unsigned char *old_sha1,
committer);
if (msglen)
len += sprintf(logrec + len - 1, "\t%.*s\n", msglen, msg) - 1;
+ if (postmsg) {
+ len += strlen(postmsg);
+ strcat(logrec + len - 1, postmsg);
+ }
written = len <= maxlen ? write_in_full(logfd, logrec, len) : -1;
free(logrec);
if (close(logfd) != 0 || written != len)
-- snap --
It is not like the reflog messages have to be very verbose; they only have
to give a hint what the commit was about, and the commit name is the
important information.
What do you think?
Ciao,
Dscho
^ permalink raw reply related
* Re: git-gui blame: show previous commit
From: Johannes Schindelin @ 2007-07-29 11:40 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87myxfzhk6.fsf@mid.deneb.enyo.de>
Hi,
On Sun, 29 Jul 2007, Florian Weimer wrote:
> How can I view the previous commit touching a specific line, so that I
> can see what was there before? For instance, the change could be
> whitespace-only, so that I want to dig deeper.
If you want to ignore whitespace changes, try the option "-w" to "git
blame". I have no idea if "git-gui blame" can use that option, but it
should not be hard for you to find out, and provide a patch if it does
not yet.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Documentation/git-diff: remove -r from --name-status example
From: Jeff King @ 2007-07-29 11:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0707291214060.14781@racer.site>
On Sun, Jul 29, 2007 at 12:14:49PM +0100, Johannes Schindelin wrote:
> How about
>
> if (!rev.diffopt.quiet)
> rev.diffopt.recursive = 1;
>
> instead?
Can you explain?
My assumption is that you want the diff machinery to exit as quickly as
possible. But the "recursive" option is _already_ turned on for most
output formats in that case, so I had assumed that it was the quiet
option itself which caused the early return, not a failure to set
"recursive".
If you don't want recursive set for quiet runs, I think there is an
error in diff.c, which sets the output format from quiet to NO_FORMAT
only _after_ having set recursive based on the output format.
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation/git-diff: remove -r from --name-status example
From: David Kastrup @ 2007-07-29 11:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0707291214060.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> }
>> rev.diffopt.allow_external = 1;
>> + rev.diffopt.recursive = 1;
>
> How about
>
> if (!rev.diffopt.quiet)
> rev.diffopt.recursive = 1;
>
> instead?
I think that the optimization "don't descend if we can figure this out
at the top level" should be rather implemented at the program flow
level than in the option processing, and quietness does not actually
play into this: _any_ diff operation can skip trees with identical
top-level SHA1.
So the above optimization should not cause a performance difference
(if it does, this is better fixed elsewhere), and makes it obscure to
guess the "-q" behavior which should be more or less equivalent to
--exit-status >/dev/null
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: What's in git.git (stable)
From: Johannes Schindelin @ 2007-07-29 11:27 UTC (permalink / raw)
To: Theodore Tso; +Cc: git
In-Reply-To: <20070729031612.GB17204@thunk.org>
Hi,
On Sat, 28 Jul 2007, Theodore Tso wrote:
> So I really am beginning to think the right answer is to give up on
> using git-mergetool to support anything other than basic emacs users
> (who just use emacs as an editor, what a concept), and for the H4rd C0re
> emacs l33t, they can use a contrib/git-mergetool.el that does everything
> inside emacs. Since these are the people who want emacs to be their
> desktop, their shell, *and* their window manager, they will probably be
> happier that way....
Well, maybe not happier. But at least they will be forced to write a
patch (if they really want to use git _their_ way, and they'll have to
defend their patch if they break all other people's work flow), instead of
writing a lot of long and useless emails.
IOW I do not think "we" have to do something about it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Documentation/git-diff: remove -r from --name-status example
From: Johannes Schindelin @ 2007-07-29 11:14 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20070729094955.GA14915@coredump.intra.peff.net>
Hi,
On Sun, 29 Jul 2007, Jeff King wrote:
> -- >8 --
> git-diff: turn on recursion by default
>
> The tree recursion behavior of git-diff may appear
> inconsistent to the user because it depends on the format of
> the patch as well as whether one is diffing between trees or
> against the index.
>
> Since git-diff is a porcelain wrapper for low-level diff
> commands, it makes sense for its behavior to be consistent
> no matter what is being diffed. This patch turns on
> recursion in all cases.
>
> diff --git a/builtin-diff.c b/builtin-diff.c
> index 7f367b6..b48121e 100644
> --- a/builtin-diff.c
> +++ b/builtin-diff.c
> @@ -233,6 +233,7 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
> die("diff_setup_done failed");
> }
> rev.diffopt.allow_external = 1;
> + rev.diffopt.recursive = 1;
How about
if (!rev.diffopt.quiet)
rev.diffopt.recursive = 1;
instead?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Documentation/git-diff: remove -r from --name-status example
From: Jeff King @ 2007-07-29 9:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwswjmu08.fsf@assigned-by-dhcp.cox.net>
On Sun, Jul 29, 2007 at 02:36:23AM -0700, Junio C Hamano wrote:
> In short, I think recursive behaviour by default makes sense for
> "git diff".
Your reasoning sounds sane to me.
Here is the patch with a commit message more succint than all of these
emails.
-- >8 --
git-diff: turn on recursion by default
The tree recursion behavior of git-diff may appear
inconsistent to the user because it depends on the format of
the patch as well as whether one is diffing between trees or
against the index.
Since git-diff is a porcelain wrapper for low-level diff
commands, it makes sense for its behavior to be consistent
no matter what is being diffed. This patch turns on
recursion in all cases.
diff --git a/builtin-diff.c b/builtin-diff.c
index 7f367b6..b48121e 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -233,6 +233,7 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
die("diff_setup_done failed");
}
rev.diffopt.allow_external = 1;
+ rev.diffopt.recursive = 1;
/* Do we have --cached and not have a pending object, then
* default to HEAD by hand. Eek.
^ permalink raw reply related
* [BUG] gitweb on repo.or.cz shows buggy commitdiff
From: Yann Dirson @ 2007-07-29 9:46 UTC (permalink / raw)
To: GIT list
Looking at [1] one can see that the diff, instead of showing the
changes to the various .gitignore files touched by the commit,
displays again and again the data/.gitignore one, but even confuses a
Makefile modified by the commit for the .gitignore file to diff.
|diff --git a/data/pics/.gitignore b/data/pics/.gitignore
|index c5ec666af7db2d53e7ed86090c88f62ab8ec25a4..912bca74cbee222936f08e421230fd9dde903ecb 100644 (file)
|--- a/lua/Makefile
|+++ b/data/pics/.gitignore
Also, despite "+++ b/data/pics/.gitignore" being displayed in the diff
header, it is indeed showing the diffs to "b/lua/Makefile".
[1] http://repo.or.cz/w/tagua/ydirson.git?a=commitdiff;h=1f285b312fa526293164548d88e8403dfb354eb4
Best regards,
--
Yann
^ permalink raw reply
* Re: [PATCH] Documentation/git-diff: remove -r from --name-status example
From: Junio C Hamano @ 2007-07-29 9:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, git, Jakub Narebski, Jon Smirl
In-Reply-To: <7vbqdvolww.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> ...
>> Ack. Patch looks fine, makes sense, and is obviously good.
>
> That makes it two of us. ... eh, excuse me, there is one issue
> I mention at the end.
>
>> It *is* a change in behaviour, though, so I can understand if Junio
>> doesn't think it's appropriate this late in the 1.5.3 series.
>
> One minor objection I do have is that, just as a matter of
> principle, in order to avoid setting precedence of making a
> fundamental semantics change in late -rc stage in the game, we
> should not swallow it. I do not mind if this were clearly a
> good change.
>
> However, I think Jeff's patch always makes it recursive even
> when the user asks for --raw, which makes it inappropriate for
> inclusion whether before or after 1.5.3.
Actually, I would like to take this back. The highest level UI
"git-diff" is for the end-users, and most of them typically do
not seem to want non recursive "birds-eye" view of changes.
The top-level non-recursive behaviour is not always useful as a
birds-eye view. Even in Linux kernel context, when you are
interested in one area e.g. i386, the answer the non recursive
behaviour gives us would not show what you typically want to see
(i.e. include/asm-i386 and arch/i386), but it stops at the
"toplevel", i.e. include and arch.
In addition, it is not like our tree diff is too slow and not
recursing into lower level makes it usable.
In short, I think recursive behaviour by default makes sense for
"git diff".
When people want to use lower level git-diff-* family, I think
the traditional behaviour is fine. We _might_ want to default
the --name-status and --name-only to recursive behaviour as
well, but (1) that is an independent topic, and (2) we should
re-examine what the appropriate recursiveness for the other
options.
^ permalink raw reply
* git-gui blame: show previous commit
From: Florian Weimer @ 2007-07-29 9:26 UTC (permalink / raw)
To: git
How can I view the previous commit touching a specific line, so that I
can see what was there before? For instance, the change could be
whitespace-only, so that I want to dig deeper.
^ permalink raw reply
* Re: git-gui problem with version number.
From: David Kastrup @ 2007-07-29 9:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070729071030.GL20052@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> David Kastrup <dak@gnu.org> wrote:
>> David Kastrup <dak@gnu.org> writes:
>>
>> > Now that is funny. I am pretty sure (or rather _have_ been pretty
>> > sure) that I cloned the respective repositories with the same command.
>> > Yet now both are up-to-date according to git-pull (and have identical
>> > .config contents), and the first compiles version git version
>> > 1.5.3.rc2.41.gb47b1 while the second compiles version
>> > 1.5.3.rc3.7.gd58e-dirty. Both have been cloned from git.git, the
>>
>> A combination of rebasing and pushing made the difference go away and
>> made git-gui work again. Nevertheless, it would be a good idea not to
>> balk at the dirty version strings.
>
> Did you not see me already state in this thread that its already
> been fixed?
I saw you state that the problem was fixed in your local version, but
that this had not been pulled into git.git. So I was adding a vote to
have this included.
> Latest git-gui already has the problem dealt with, and that latest
> version will be included in git 1.5.3 when it ships.
That is good to hear but it was far from obvious when I wrote the
above mail.
> Nevertheless, thanks for the problem report.
You are welcome.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: What's in git.git (stable)
From: David Kastrup @ 2007-07-29 9:05 UTC (permalink / raw)
To: Theodore Tso; +Cc: git
In-Reply-To: <20070729031612.GB17204@thunk.org>
Theodore Tso <tytso@mit.edu> writes:
> So I really am beginning to think the right answer is to give up on
> using git-mergetool to support anything other than basic emacs users
> (who just use emacs as an editor, what a concept),
In contrast, you are trying to support only people by using Emacs
_not_ as an editor, but as a mergetool under the control of git.
That's a mistake.
> and for the H4rd C0re emacs l33t, they can use a
> contrib/git-mergetool.el that does everything inside emacs. Since
> these are the people who want emacs to be their desktop, their
> shell, *and* their window manager, they will probably be happier
> that way....
Sorry, but you are way off here. The normal, standard use of Emacs is
to start it once and do everything in it. Its startup time is such
that other uses are not feasible.
(info "(emacs) Entering Emacs")
Many editors are designed to edit one file. When done with
that file, you exit the editor. The next time you want to edit a
file, you must start the editor again. Working this way, it is
convenient to use a command-line argument to say which file to
edit.
However, killing Emacs after editing one each and starting it
afresh for the next file is both unnecessary and harmful, since it
denies you the full power of Emacs. Emacs can visit more than one
file in a single editing session, and that is the right way to use
it. Exiting the Emacs session loses valuable accumulated context,
such as the kill ring, registers, undo history, and mark ring.
These features are useful for operating on multiple files, or even
continuing to edit one file. If you kill Emacs after each file,
you don't take advantage of them.
The recommended way to use GNU Emacs is to start it only once,
just after you log in, and do all your editing in the same Emacs
session. Each time you edit a file, you visit it with the
existing Emacs, which eventually has many files in it ready for
editing. Usually you do not kill Emacs until you are about to log
out. *Note Files::, for more information on visiting more than
one file.
To edit a file from another program while Emacs is running, you
can use the `emacsclient' helper program to open a file in the
already running Emacs. *Note Emacs Server::.
So git's mergetool philosophy is currently _straight_ set against the
way Emacs is designed to work.
One solution would be to call emacs -q in order to weed out users with
the impunity of customizing Emacs to suit their needs rather than
those of git.
But the sanest is really to call Emacs just the way the user
configured $EDITOR to call it and pass it an initial merge command.
And then decide from the results on the disk what to further do.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Teach git-gui about merging around modified files?
From: Shawn O. Pearce @ 2007-07-29 9:04 UTC (permalink / raw)
To: Brian Downing; +Cc: git
In-Reply-To: <20070729073652.GN20052@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Brian Downing <bdowning@lavos.net> wrote:
> > "git merge" will happily merge a change with modified files in the tree
> > as long as the merge doesn't touch any of them. However, it appears
> > "git gui" won't even try if there are modified files at all.
>
> Yes. That is actually intentional...
>
> If you merge and get conflicts you cannot abort to your pre-merge
> state safely by just doing a `git reset --hard` (or git-gui's own
> builtin action that does the same) as you will toss your own not
> yet committed changes too. You really need to save those changes
> off first.
I felt bad about my original response to this thread. Telling a
user that their workflow is broken and should be changed is not
very nice, and not user friendly.
So I just spent a couple of hours trying to teach git-gui to first
save off your index and working directory, then run the merge, and
during abort let you restore things even if they weren't committed.
During testing I learned that you can't merge if you have any
staged but uncommitted changes. If you try git-merge-recursive
just aborts and refuses to execute the merge, even if the file
paths aren't in conflict and won't require a file level merge.
The issue is the files are staged in the index and would commit
as part of the merge commit, rather than staying out until after,
so the merge driver is really doing the right thing here.
I'm still convinced that merging while you have uncommitted changes
in the working directory is really bad. Its nearly impossible
to recover from a conflict and get back to pre-merge state, and
its also confusing to resolve conflicts because your unstaged but
modified files are still showing in the status.
I'm going to shelve this work until post 0.8.0 and try to rework
it using git-stash as part of git-gui 0.9.0. Ideally you should
be able to stash your work before merging, and unstash after the
merge is complete.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-mergetool: add support for ediff
From: David Kastrup @ 2007-07-29 8:54 UTC (permalink / raw)
To: Theodore Tso; +Cc: git
In-Reply-To: <20070729023854.GA17204@thunk.org>
Theodore Tso <tytso@mit.edu> writes:
> On Sat, Jul 28, 2007 at 11:22:43AM +0200, David Kastrup wrote:
>> Ted, I think you are somewhat missing the main audience here. The
>> main audience are people who actually _use_ Emacs, and those will
>> be comfortable with the concept "save to have changes persist,
>> don't save if you don't want changes to persist, exit using C-x #
>> or C-x C-c as appropriate". Basically, it would appear that you
>> try figuring out how to make ediff appeal to non-Emacs users. But
>> those would not have emacs/emacsclient in their EDITOR variable in
>> the first place.
>>
>> I have been bitten by mergetool calling emacs rather than
>> emacsclient, resulting in a non-working merge (since the default
>> directory was set differently from what the call expected due to my
>> use of the desktop package), and mergetool afterwards assuming that
>> the not-even-started merge was successful. A royal nuisance, and
>> completely unworkable.
>
> Emacsclient is a completely different problem, or at least adds a
> whole new dimention, compared to the ediff/emerge issue. You can't
> run either emerge or ediff using the emacsclient in emacs21, since
> it lacks support for either the -e or the -f command-line option.
If the user asks for it, we should try giving it to him. If
Emacsclient bombs out because of a non-understood option, one can
still fall back to calling a separate Emacs.
> All you can do in emacs21 when using eamcsclient is to request emacs
> to edit a file.
Yes, but emacsclient --version returns a version string, and
emacsclient will exit with an error if it can't get to understand the
command line options or to talk with Emacs. So there are reasonably
ways to notice when to fallback.
> One of the problems with emacs is that it is so customizable that
> people can set up emacs in such a way that different ways of
> launching emacs may lead to surprises, thanks to their .emacs21.
> This makes supporting emacs based merging clients to be highly
> problematic. Use of the desktop package is one way in which things
> can be quite surprising. Worse yet, the desktop package is only in
> emacs22 and up.
The desktop package has already been in Emacs 21, so it is not exactly
a new problem but has been round for more than 7 years.
> (And emacs 22 was *just* released, not all that long ago; many
> people may still be using emacs21). So if we use emacs --no-desktop
> to disable the desktop package, it will cause emacs21 to complain
> about an unknown option. Joy.
Correct: the --no-desktop option is new.
> Which means that to avoid running into problems with emacs22 users
> who are using the desktop package, git-mergetool is going to have to
> find out in advance whether emacs21 or emacs22 (or an emacs
> development 23.0.0 snapshot) is in use; on a debian system you can
> have 3 or 4 emacs installed simultaneously. What fun.
$EDITOR --version
> In any case, the main issue is that there is an emerging (sorry)
> standard about how merge tools are supposed to work, in terms of
> being able to support 2-way or 3-way merges, about being able to
> specify which file (and which file only, in the best case) should be
> used as the output file as the result of the merge, and about how
> tools can signal either a successful merge, or a request by the user
> to abort the merge becuase things didn't work out for one reason or
> another.
>
> The problem is that ediff doesn't really fit this model.
Emacs is an editor. If we can't make an editor fit into merge
resolution, we have a design problem. It is a matter of convenience
that the editor is called with some initial files and something like
ediff-whatever, but the end result clearly should be that the user
writes the file if he wants changes to persist, and doesn't if
doesn't.
> For people who really want to live their life in emacs, and using
> emacs as their desktop (not for me, but maybe for some folks), maybe
> it would be better for those folks to simply build a
> git-mergetool.el that ran 100% in emacs, instead of trying to shift
> back and forth between the command-line and emacs, would make
> everyone happier. Right now git-mergetool needs to ask questions
> about the disposition of symlinks, permission changes, etc. If it
> is done as a git-mergetool.el which is tied into git.el and ediff,
> it could be a lot more seamless.
But this is no reason not to fix the currently broken behavior. If
you insist that "emerge" or "ediff" is _not_ to be used as an editor,
but rather as a special-purpose mergetool for the sake of git, then
the only logical conclusion can be to call it with "-q", bypassing any
user initialization.
I believe this would be a mistake at least when $EDITOR points to
Emacs, because this means the user is used to using Emacs/Emacsclient
as _editor_, and anything else would be _confusing_.
>> While it may be nice to have some Lisp preparation for people who
>> don't want to touch or learn Emacs _except_ for using it for
>> merging in git, I think we should first cater to people actually
>> using Emacs already.
>
> Catering to the hard-core Emacs folks is *hard*.
Saving a desktop session is not hard-core. Using emacsclient is not
hard-core. Those are standard, basic, use cases.
> I knew someone who had PDP-10 assembly language in their .emacs.el
> file, and one day his custom emacs extension worked again when he
> started playing with the KLH10 PDP-10 emulator, and reused his
> .emacs.el startup file there....
Can we get another strawman a bit closer to the main road, please?
> Of course, at some level folks like that will always need to fend
> for themselves.
Yes. I am not talking about people breaking things by code of their
own. I am talking about a _standard_ setup being broken by git.
> As I said earlier, I don't have a huge objection to support ediff in
> some degraded mode (I think the UI is ghastly bad), if users
> explicitly request it, but I would *not* want to make it the default
> and spring it on some unsuspecting user. Quite frankly, right now
> the KDE and GNOME tools are way better either emerge or ediff, so
> they are only really useful as a default in the terminal-only case.
Again, you fall into the trap of not allowing others to have a life
and Emacs outside of git's preconceptions. emerge and ediff might be
worse for people who would not use Emacs for anything but merging.
But one advantage of Emacs is that I can look at all sorts of other
files and buffers and information sources _while_ I am merging, and
declare the merge finished when _I_ want it (signaled by exiting
either Emacs or Emacsclient), not when some arbitrary command thinks
it finished.
Emacs is one of the most flexible tools ever. Disallowing any editing
use not foreseen and sanctioned by git-mergetool is _always_ going to
lead to trouble. If you do _anything_ like this, you _must_ call
Emacs -q in order to omit _any_ user initializations you did not
foresee. But this will also kill user-specific major modes which he
might want to use for visualizing files. It will be less onerous than
having all hell break lose because you can't cater for even standard
initializations or setup, but it will still be a nuisance.
So please don't try crippling Emacs into a git-only tool. Call it
with the files in question, give it an appropriate initial command to
work with if possible, and leave the rest to the user. He will save
and finish, or not save and finish, which is the way of an editor to
communicate with its environment.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* [GUILT PATCH 0/4] Add guards to guilt
From: Eric Lesh @ 2007-07-29 7:50 UTC (permalink / raw)
To: jsipek; +Cc: git
This series adds Mercurial Queues-like guards to guilt. It allows you
to assign guards to related patches in the series file to selectively
push patches.
See Chapter 13 of the HG Book for more info.
(http://hgbook.red-bean.com/hgbookch13.html)
Guards are appended as "#+foo" or "#-foo" to the end of the patch name
in the series file, so they are compatible with quilt. The
guard setting and unsetting functions also respect comments on the
patch line, so they aren't mangled when you use guards.
This introduces the command `get_guarded_series`, which just lists
patches that are to be applied based on the guards. It also makes
eidx=`wc -l < $applied`
inaccurate if you're using it as an index into get_series.
If you change guards on a patch or select a different guard while
patches are applied, some commands might get confused. guilt pop -a will fix
everything though. Usually, it's best to pop -a before fiddling with
guards anyway.
This is an RFC, but I have tested it and things seem to be working
well.
[PATCH 1/4] get_series: Remove comments from end of series lines
This just strips everything but the patch name from get_series,
to hide comments or guards on the line.
[PATCH 2/4] guilt-guard: Assign guards to patches in series
This adds the guilt-guard command and utility functions to
guilt.
[PATCH 3/4] guilt-select: Select guards to apply when pushing patches
This puts selected guards in .git/patch/$branch/guards, and
adds a $guards_file variable to guilt.
[PATCH 4/4] Use guards information and functions
This changes guilt-header, guilt-next, guilt-push and guilt-unapplied to
use the guards information properly.
After the guilt-push change, header, next, and unapplied get
confused and break, so I rolled their fixes into this patch
instead of separate ones.
Documentation/guilt-guards.txt | 40 +++++++++++++++++++++++++
Documentation/guilt-select.txt | 42 ++++++++++++++++++++++++++
guilt | 62 ++++++++++++++++++++++++++++++++++++++-
guilt-guards | 63 ++++++++++++++++++++++++++++++++++++++++
guilt-header | 7 ++--
guilt-next | 2 +-
guilt-push | 8 ++--
guilt-select | 36 +++++++++++++++++++++++
guilt-unapplied | 2 +-
9 files changed, 252 insertions(+), 10 deletions(-)
create mode 100644 Documentation/guilt-guards.txt
create mode 100644 Documentation/guilt-select.txt
create mode 100755 guilt-guards
create mode 100755 guilt-select
^ permalink raw reply
* Re: [PATCH] Documentation/git-diff: remove -r from --name-status example
From: David Kastrup @ 2007-07-29 8:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Jeff King, git, Jakub Narebski, Jon Smirl
In-Reply-To: <7vbqdvolww.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> One minor objection I do have is that, just as a matter of
> principle, in order to avoid setting precedence of making a
> fundamental semantics change in late -rc stage in the game, we
> should not swallow it. I do not mind if this were clearly a
> good change.
>
> However, I think Jeff's patch always makes it recursive even
> when the user asks for --raw, which makes it inappropriate for
> inclusion whether before or after 1.5.3.
Personally, I think -r should be the default while one can use
--directory to switch it off.
Whether --raw should imply --directory might be a different question.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* [GUILT PATCH 3/4] guilt-select: Select guards to apply when pushing patches
From: Eric Lesh @ 2007-07-29 7:50 UTC (permalink / raw)
To: jsipek; +Cc: git, Eric Lesh
In-Reply-To: <118569541814-git-send-email-eclesh@ucla.edu>
guilt-select chooses guards that alter which patches will be applied
with a guilt-push. The selected guards are stored in
.git/patches/$branch/guards.
Signed-off-by: Eric Lesh <eclesh@ucla.edu>
---
Documentation/guilt-select.txt | 42 ++++++++++++++++++++++++++++++++++++++++
guilt | 1 +
guilt-select | 36 ++++++++++++++++++++++++++++++++++
3 files changed, 79 insertions(+), 0 deletions(-)
create mode 100644 Documentation/guilt-select.txt
create mode 100755 guilt-select
diff --git a/Documentation/guilt-select.txt b/Documentation/guilt-select.txt
new file mode 100644
index 0000000..8e18f26
--- /dev/null
+++ b/Documentation/guilt-select.txt
@@ -0,0 +1,42 @@
+guilt-select(1)
+===============
+
+NAME
+----
+guilt-select - Select guards to apply when pushing patches
+
+SYNOPSIS
+--------
+include::usage-guilt-select.txt[]
+
+DESCRIPTION
+-----------
+Select guards to apply when pushing patches.
+
+Guards are selected without the + or - prefix. Patches are applied in
+the following way:
+
+An unguarded patch is always applied.
+
+A patch with a positive guard is applied *only* if the guard is
+selected with guilt-select.
+
+A patch with a negative guard is applied *unless* the guard is
+selected with guilt-select.
+
+OPTIONS
+-------
+-n|--none::
+ Remove all selected guards
+-s|--series::
+ List all guards listed in the series file
+
+Author
+------
+Written by Eric Lesh <eclesh@ucla.edu>
+
+Documentation
+-------------
+Documentation by Eric Lesh <eclesh@ucla.edu>
+
+include::footer.txt[]
diff --git a/guilt b/guilt
index b2767ea..3882962 100755
--- a/guilt
+++ b/guilt
@@ -641,6 +641,7 @@ fi
# very useful files
series="$GUILT_DIR/$branch/series"
applied="$GUILT_DIR/$branch/status"
+guards_file="$GUILT_DIR/$branch/guards"
# determine an editor to use for anything interactive (fall back to vi)
editor="vi"
diff --git a/guilt-select b/guilt-select
new file mode 100755
index 0000000..f237ef0
--- /dev/null
+++ b/guilt-select
@@ -0,0 +1,36 @@
+#!/bin/sh
+#
+# Copyright (c) Eric Lesh, 2007
+#
+
+USAGE="[-n|--none] [-s|--series] [<guard>]"
+ . `dirname $0`/guilt
+
+if [ $# == 0 ]; then
+ if [ -s "$guards_file" ]; then
+ cat "$guards_file"
+ else
+ echo "No guards applied"
+ fi
+ exit 0
+fi
+
+case $1 in
+ -n|--none)
+ rm -f "$guards_file"
+ touch "$guards_file"
+ ;;
+ -s|--series)
+ (get_series | while read patch; do
+ get_guards "$patch"
+ done) | sed -e 's/ /\n/g' | sort | uniq
+ ;;
+ *)
+ for x in "$@"; do
+ if [ $(echo $x | grep -e "^[+-]") ]; then
+ die "'$x' is not a valid guard name"
+ fi
+ done
+ echo "$@" | sed -e 's/ /\n/g' | sort | uniq > "$guards_file"
+ ;;
+esac
--
1.5.2
^ permalink raw reply related
* [GUILT PATCH 2/4] guilt-guard: Assign guards to patches in series
From: Eric Lesh @ 2007-07-29 7:50 UTC (permalink / raw)
To: jsipek; +Cc: git, Eric Lesh
In-Reply-To: <118569541814-git-send-email-eclesh@ucla.edu>
guilt-guard will assign guards to a patch. They work so that:
* Patches with no guards are always pushed.
* Patches with positive guards (i.e. +foo) are pushed *only if* the
guard is selected.
* Patches with negative guards (i.e. -foo) are pushed *unless* the
guard is selected.
Signed-off-by: Eric Lesh <eclesh@ucla.edu>
---
Documentation/guilt-guards.txt | 40 +++++++++++++++++++++++++
guilt | 58 ++++++++++++++++++++++++++++++++++++
guilt-guards | 63 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 161 insertions(+), 0 deletions(-)
create mode 100644 Documentation/guilt-guards.txt
create mode 100755 guilt-guards
diff --git a/Documentation/guilt-guards.txt b/Documentation/guilt-guards.txt
new file mode 100644
index 0000000..f5ac537
--- /dev/null
+++ b/Documentation/guilt-guards.txt
@@ -0,0 +1,40 @@
+guilt-guards(1)
+===============
+
+NAME
+----
+guilt-guards - Assign guards to patches
+
+SYNOPSIS
+--------
+include::usage-guilt-guards.txt[]
+
+DESCRIPTION
+-----------
+Assign guards to the specified patch, or to the patch on top of the
+stack if no patch is given on the command line.
+
+An unguarded patch is always pushed.
+
+A positive guard begins with a +. A patch with a positive guard is
+pushed *only if* the guard is selected.
+
+A negative guard begins with a -. A patch with a negative guard is
+always pushed, *unless* the guard is selected.
+
+OPTIONS
+-------
+-l|--list::
+ List all patches and their guards
+-n|--none::
+ Remove all guards from a patch
+
+Author
+------
+Written by Eric Lesh <eclesh@ucla.edu>
+
+Documentation
+-------------
+Documentation by Eric Lesh <eclesh@ucla.edu>
+
+include::footer.txt[]
diff --git a/guilt b/guilt
index 774909e..b2767ea 100755
--- a/guilt
+++ b/guilt
@@ -182,6 +182,64 @@ get_series()
grep -ve '^[[:space:]]*\(#.*\)*$' < "$series" | sed -e 's/[[:space:]]*#.*$//'
}
+get_guarded_series()
+{
+ get_series | while read p
+ do
+ [ -z `check_guards $p` ] && echo "$p"
+ done
+}
+
+# usage: check_guards <patch>
+# Returns t if the patch should be skipped
+check_guards()
+{
+ get_guards "$1" | while read guard
+ do
+ pos=`echo $guard | grep -e "^+"`
+ guard=`echo $guard | sed -e 's/[+-]//'`
+ if [ $pos ]; then
+ # Push +guard *only if* guard selected
+ push=`grep -e "^$guard\$" "$guards_file" > /dev/null; echo $?`
+ [ $push -ne 0 ] && echo t
+ else
+ # Push -guard *unless* guard selected
+ push=`grep -e "^$guard\$" "$guards_file" > /dev/null; echo $?`
+ [ $push -eq 0 ] && echo t
+ fi
+ done
+}
+
+# usage: get_guards <patch>
+get_guards()
+{
+ grep -e "^$1[[:space:]]*#" < "$series" | sed -e "s/^$1 //" -e 's/#[^+-]*//g'
+}
+
+# usage: set_guards <patch> <guards>
+set_guards()
+{
+ p="$1"
+ shift
+ for x in "$@"; do
+ if [ -z $(echo "$x" | grep -e "^[+-]") ]; then
+ echo "'$x' is not a valid guard name"
+ else
+ sed -i -e "s/^\($p[[:space:]]*.*\)$/\1 #$x/" "$series"
+ fi
+ done
+}
+
+# usage: unset_guards <patch> <guards>
+unset_guards()
+{
+ p="$1"
+ shift
+ for x in "$@"; do
+ sed -i -e "/^$p[[:space:]]/s/ #$x//" "$series"
+ done
+}
+
# usage: do_make_header <hash>
do_make_header()
{
diff --git a/guilt-guards b/guilt-guards
new file mode 100755
index 0000000..71df4f8
--- /dev/null
+++ b/guilt-guards
@@ -0,0 +1,63 @@
+#!/bin/sh
+#
+# Copyright (c) Eric Lesh, 2007
+#
+
+USAGE="[-l|--list] [-n|--none] [<patchname>] [+<guard>] [-<guard>]"
+. guilt
+
+print_guards()
+{
+ guards=`get_guards "$1"`
+ echo "$1: $guards"
+}
+
+if [ "$1" == "-l" ] || [ "$1" == "--list" ]; then
+ get_series | while read patch; do
+ print_guards "$patch"
+ done
+ exit 0
+elif [ "$1" == "-n" ] || [ "$1" == "--none" ]; then
+ patch="$2"
+ if [ -z "$patch" ]; then
+ patch=`get_top`
+ fi
+ unset_guards "$patch" `get_guards "$patch"`
+ exit 0
+fi
+
+case $# in
+ 0)
+ if [ ! -s "$applied" ]; then
+ die "No patches applied."
+ fi
+ print_guards `get_top`
+ ;;
+ 1)
+ if [ -z $(echo $1 | grep -e '^[+-]') ]; then
+ if [ -z $(get_series | grep -e "^$1\$") ]; then
+ die "Patch $1 does not exist"
+ else
+ print_guards "$1"
+ fi
+ else
+ p=`get_top`
+ unset_guards "$p" `get_guards "$p"`
+ set_guards "$p" "$1"
+ fi
+ ;;
+ *)
+ if [ -z $(echo $1 | grep -e '^[+-]') ]; then
+ if [ -z $(get_series | grep -e "^$1\$") ]; then
+ die "Patch $1 does not exist"
+ else
+ patch="$1"
+ fi
+ shift
+ else
+ patch=`get_top`
+ fi
+ unset_guards "$patch" `get_guards "$patch"`
+ set_guards "$patch" "$@"
+ ;;
+esac
--
1.5.2
^ permalink raw reply related
* [GUILT PATCH 4/4] Use guards information and functions
From: Eric Lesh @ 2007-07-29 7:50 UTC (permalink / raw)
To: jsipek; +Cc: git, Eric Lesh
In-Reply-To: <118569541814-git-send-email-eclesh@ucla.edu>
Make guilt-push respect guards. Also teach guilt-header, guilt-next,
and guilt-unapplied to grok patches that are skipped because of
guards.
Signed-off-by: Eric Lesh <eclesh@ucla.edu>
---
| 7 ++++---
guilt-next | 2 +-
guilt-push | 8 ++++----
guilt-unapplied | 2 +-
4 files changed, 10 insertions(+), 9 deletions(-)
--git a/guilt-header b/guilt-header
index d07e2be..ef7f55e 100755
--- a/guilt-header
+++ b/guilt-header
@@ -15,15 +15,16 @@ patch="$1"
if [ -z "$patch" ]; then
# use the patch that's on the top of the stack
- eidx=`wc -l < $applied`
- if [ $eidx -eq 0 ]; then
+ patch=`get_top`
+ if [ -z "$patch" ]; then
die "Status file is empty"
fi
+ eidx=`get_series | grep -ne "^$patch\$" | cut -d: -f1`
else
# use the specified patch
eidx=`get_series | grep -ne "^$patch\$" | cut -d: -f1`
- if [ $eidx -eq 0 ]; then
+ if [ -z "$eidx" ]; then
die "Patch $patch is not in the series"
fi
fi
diff --git a/guilt-next b/guilt-next
index f38f1cc..38f57fa 100755
--- a/guilt-next
+++ b/guilt-next
@@ -13,5 +13,5 @@ fi
n=`wc -l < $applied`
n=$(($n + 1))
-get_series | awk "{ if (NR == $n) print \$0}"
+get_guarded_series | awk "{ if (NR == $n) print \$0}"
diff --git a/guilt-push b/guilt-push
index ad3616b..ce928e3 100755
--- a/guilt-push
+++ b/guilt-push
@@ -24,7 +24,7 @@ if [ "$patch" = "--all" ] || [ "$patch" = "-a" ]; then
# we are supposed to push all patches, get the last one out of
# series
- eidx=`get_series | wc -l`
+ eidx=`get_guarded_series | wc -l`
if [ $eidx -eq 0 ]; then
die "There are no patches to push"
fi
@@ -37,9 +37,9 @@ else
# we're supposed to push only up to a patch, make sure the patch is
# in the series
- eidx=`get_series | grep -ne "^$patch\$" | cut -d: -f1`
+ eidx=`get_guarded_series | grep -ne "^$patch\$" | cut -d: -f1`
if [ -z "$eidx" ]; then
- die "Patch $patch is not in the series"
+ die "Patch $patch is not in the series or is guarded"
fi
fi
@@ -52,7 +52,7 @@ fi
sidx=`wc -l < $applied`
sidx=`expr $sidx + 1`
-get_series | sed -n -e "${sidx},${eidx}p" | while read p
+get_guarded_series | sed -n -e "${sidx},${eidx}p" | while read p
do
echo "Applying patch..$p"
if [ ! -f "$GUILT_DIR/$branch/$p" ]; then
diff --git a/guilt-unapplied b/guilt-unapplied
index 192a7e5..6904360 100755
--- a/guilt-unapplied
+++ b/guilt-unapplied
@@ -13,4 +13,4 @@ fi
n=`wc -l < $applied`
n=`expr $n + 1`
-get_series | sed -n -e "$n,\$p"
+get_guarded_series | sed -n -e "$n,\$p"
--
1.5.2
^ permalink raw reply related
* [GUILT PATCH 1/4] get_series: Remove comments from end of series lines
From: Eric Lesh @ 2007-07-29 7:50 UTC (permalink / raw)
To: jsipek; +Cc: git, Eric Lesh
In-Reply-To: <118569541814-git-send-email-eclesh@ucla.edu>
Signed-off-by: Eric Lesh <eclesh@ucla.edu>
--
---
guilt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/guilt b/guilt
index f67bfb5..774909e 100755
--- a/guilt
+++ b/guilt
@@ -178,7 +178,8 @@ get_series()
# - whitespace only
# - optional whitespace followed by '#' followed by more
# optional whitespace
- grep -ve '^[[:space:]]*\(#.*\)*$' "$series"
+ # also remove comments from end of lines
+ grep -ve '^[[:space:]]*\(#.*\)*$' < "$series" | sed -e 's/[[:space:]]*#.*$//'
}
# usage: do_make_header <hash>
--
1.5.2
^ permalink raw reply related
* Re: Teach git-gui about merging around modified files?
From: Shawn O. Pearce @ 2007-07-29 7:36 UTC (permalink / raw)
To: Brian Downing; +Cc: git
In-Reply-To: <20070727170347.GX21692@lavos.net>
Brian Downing <bdowning@lavos.net> wrote:
> "git merge" will happily merge a change with modified files in the tree
> as long as the merge doesn't touch any of them. However, it appears
> "git gui" won't even try if there are modified files at all.
Yes. That is actually intentional...
> How hard would it be to fix this, or is this an intentional choice?
Its not hard to fix. I just did it in a patch that would be:
lib/merge.tcl | 12 +-----------
1 files changed, 1 insertions(+), 11 deletions(-)
and we all know deleting more lines is good, but after I made the
patch and started testing it I remembered exactly why I don't allow
you to merge with modified files.
If you merge and get conflicts you cannot abort to your pre-merge
state safely by just doing a `git reset --hard` (or git-gui's own
builtin action that does the same) as you will toss your own not
yet committed changes too. You really need to save those changes
off first.
> I realize that commiting even untouched files before a merge is safer,
> but I'm tasked with migrating some CVS users to Git, and I'd prefer
> to be able to introduce the new Git workflow slowly.
>
> (I'm happy enough with disallowing merges that actually touch modified
> files, so I'm not looking for any kind of in-working-directory merge
> like some others were. I'd just like the "git merge" behavior to work
> in git-gui.)
What do you do when the merge goes badly on the command line
(lots of conflicts, but none to the files you have modified),
and you want to get back to your pre-merge state? You can't,
there's no state saved for git to reset back to.
Really what you want to do here is stash your local changes away,
then do the merge, and after the merge is successfully completed
apply the stash back onto your working tree. Because then if the
merge goes badly you can `git reset --hard && git stash apply`
to bring back your prior state.
So until git-gui plays along nicely with git-stash (can save
and apply to it) I'm going to continue to disallow merging with
uncommitted changes. Its just not a smart thing to be doing.
--
Shawn.
^ permalink raw reply
* Re: git-gui ignores core.excludesFile
From: Shawn O. Pearce @ 2007-07-29 7:22 UTC (permalink / raw)
To: Lars Noschinski; +Cc: git
In-Reply-To: <20070723150700.GA17167@lars.home.noschinski.de>
Lars Noschinski <lars@public.noschinski.de> wrote:
> It seems git-gui (0.7.5 from git 1.5.2.4 tarball) ignores the global
> ignore file configured with the core.excludesfile option. My
> ~/.gitconfig contains
>
> [core]
> excludesFile = /home/noschinski/.gitignore
>
> which is honoured by git-status but not by git-gui.
Whoops. Thanks. git-gui 0.8.0 will include the following patch:
-->8--
From 94a4dd9bfda79a226f8dd57fd20c39c6603ec194 Mon Sep 17 00:00:00 2001
From: Shawn O. Pearce <spearce@spearce.org>
Date: Sun, 29 Jul 2007 03:22:27 -0400
Subject: [PATCH] git-gui: Honor core.excludesfile when listing extra files
Recent git versions have a git-status that honors the core.excludesfile
configuration option when it reports on untracked files. Unfortunately
I missed the introduction of this configuration option in the core
porcelain implementation, so it was not reflected here in git-gui.
Found and reported by Lars Noschinski <lars@public.noschinski.de>.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-gui.sh | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index d7fad46..4e3b58c 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -872,6 +872,10 @@ proc rescan_stage2 {fd after} {
if {[file readable $info_exclude]} {
lappend ls_others "--exclude-from=$info_exclude"
}
+ set user_exclude [get_config core.excludesfile]
+ if {$user_exclude ne {} && [file readable $user_exclude]} {
+ lappend ls_others "--exclude-from=$user_exclude"
+ }
set buf_rdi {}
set buf_rdf {}
--
1.5.3.rc3.843.g25b4
--
Shawn.
^ permalink raw reply related
* Re: git-gui problem with version number.
From: Shawn O. Pearce @ 2007-07-29 7:10 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86lkd2mcsu.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> wrote:
> David Kastrup <dak@gnu.org> writes:
>
> > Now that is funny. I am pretty sure (or rather _have_ been pretty
> > sure) that I cloned the respective repositories with the same command.
> > Yet now both are up-to-date according to git-pull (and have identical
> > .config contents), and the first compiles version git version
> > 1.5.3.rc2.41.gb47b1 while the second compiles version
> > 1.5.3.rc3.7.gd58e-dirty. Both have been cloned from git.git, the
>
> A combination of rebasing and pushing made the difference go away and
> made git-gui work again. Nevertheless, it would be a good idea not to
> balk at the dirty version strings.
Did you not see me already state in this thread that its already
been fixed? Latest git-gui already has the problem dealt with,
and that latest version will be included in git 1.5.3 when it ships.
Nevertheless, thanks for the problem report.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-gui.git: Wording suggestions, 2nd try
From: Shawn O. Pearce @ 2007-07-29 7:08 UTC (permalink / raw)
To: Christian Stimming
Cc: David Kastrup, Brett Schwarz, git, Paul Mackerras, Junio C Hamano
In-Reply-To: <200707282217.10772.stimming@tuhh.de>
Christian Stimming <stimming@tuhh.de> wrote:
> Unify wording to say "to stage" instead of "to add" always.
>
> Also, the warning message when clicking "Reset" is adapted to
> the wording "Reset" rather than a confusion "Cancel commit?".
>
> Signed-off-by: Christian Stimming <stimming@tuhh.de>
> ---
> This time, this patch is actually based on git-gui.git's master. If
> you want to, you can directly apply this regardless of i18n work that
> was deferred until later. The last hunk in lib/merge.tcl looks a
> bit confusing; in preparation of i18n work, the previous message
> that inserted a single word into the long english sentence was
> already replaced by the i18n'able form of two completely different
> messages. But nevertheless the main point is that when clicking
> "Reset", the upcoming question should use the wording "reset",
> which it will do after this patch.
Thanks, I'm including this in 0.8.0 as I think it makes things
a lot clearer, at least for English speakers. ;-)
As soon as git 1.5.3 ships I'll start work on 0.9.0, and I'm
looking to bringing the i18n work in as the first series of
changes for the 0.9.x series...
--
Shawn.
^ permalink raw reply
* [PATCH] gitweb: localhost placeholder parser for cloneurl file
From: Leandro Dorileo @ 2007-07-29 6:54 UTC (permalink / raw)
To: git
Hi...
I just started to use gitweb and saw that there isn`t in the git-tree
of gitweb the feature of that link to the git url (wich we can see in
git.kernel.org:D - I didn`t understand it, was that changed/done only
for kernel.org?).
I also have a specific need. I work with my laptop and there I keep
some git repositories, these repositories are shared/published with
some coworkers but as it`s a notebook the network environment normally
changes depending where I`m, so I implemented a placeholder for
cloneurl file. Gitweb will change #localhost# by server_name.
If your git repositories aren`t in your local machine or if your
gitweb is hosted in a specific server what you have to do (in fact
what you don`t have to do :D) is just not use it.
>From 32da24e1e18a1c5f32bfa0afdbcb6d0f2b0432f3 Mon Sep 17 00:00:00 2001
From: Leandro Dorileo <dorileo@ossystems.com.br>
Date: Sat, 28 Jul 2007 15:34:20 -0400
Subject: [PATCH] gitweb: localhost placeholder parser for cloneurl file
Implementation of a localhost placeholder parsing in git_get_project_url_list.
It`s useful in cases of gitweb being hosted in a work-station (like a notebook)
used in a local team development environment and, implementation of a git-url
link in the git project list body like in git.kernel.org.
---
gitweb/gitweb.perl | 21 ++++++++++++++++++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b381692..281d823 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1471,7 +1471,16 @@ sub git_get_project_url_list {
my @git_project_url_list = map { chomp; $_ } <$fd>;
close $fd;
- return wantarray ? @git_project_url_list : \@git_project_url_list;
+ if(wantarray){
+ for(my $i = 0; $i < @git_project_url_list; $i++){
+ if(index(@git_project_url_list[$i], "#localhost#") != -1){
+ @git_project_url_list[$i] =~
s/#localhost#/server_name()/eg;
+ }
+ }
+ return @git_project_url_list;
+ }else{
+ return \@git_project_url_list;
+ }
}
sub git_get_projects_list {
@@ -3384,8 +3393,14 @@ sub git_project_list_body {
$cgi->a({-href => href(project=>$pr->{'path'},
action=>"shortlog")}, "shortlog") . " | " .
$cgi->a({-href => href(project=>$pr->{'path'},
action=>"log")}, "log") . " | " .
$cgi->a({-href => href(project=>$pr->{'path'},
action=>"tree")}, "tree") .
- ($pr->{'forks'} ? " | " . $cgi->a({-href =>
href(project=>$pr->{'path'}, action=>"forks")}, "forks") : '') .
- "</td>\n" .
+ ($pr->{'forks'} ? " | " . $cgi->a({-href =>
href(project=>$pr->{'path'}, action=>"forks")}, "forks") : '');
+
+ my @url_list = git_get_project_url_list($pr->{'path'});
+ if(@url_list != 0){
+ print " | " . $cgi->a({-href => @url_list[0]}, "git");
+ }
+
+ print "</td>\n" .
"</tr>\n";
}
if (defined $extra) {
--
1.5.2.4
--
Dorileo
^ permalink raw reply related
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