* Re: [PATCH] allow git-bundle to create bottomless bundle
From: Mark Levedahl @ 2007-08-09 2:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List, Mark Levedahl
In-Reply-To: <7vps1xzic2.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> While "git bundle" was a useful way to sneakernet incremental
> changes, we did not allow:
>
Thanks - I've been thinking for months I could fix this bug, never
figured it out and didn't want to nag Dscho one more time. I confirm
that this allows creation of bundles with arbitrary refs, not just those
under refs/heads. Yahoo!
Mark
^ permalink raw reply
* Re: [PATCH] Mod. gitk to support REBASE (with stash support).
From: Shawn O. Pearce @ 2007-08-09 3:26 UTC (permalink / raw)
To: David Kastrup
Cc: Johannes Schindelin, Alexandre Bourget, Git Mailing List, paulus
In-Reply-To: <85lkclrdpr.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > General question: should this not be in git-gui rather than gitk? Gitk as
> > of now is really more a viewing tool.
>
> Well, yes. But git-gui only works on a single branch head at a time,
> and that is not enough for rebasing.
Sure. But so does git's command line tools. They tend to only
work on a single branch at time, the one called `HEAD`. HEAD is
usually a symref/symlink, in which case such work is actually done
on a different branch, but doesn't have to be. Oh, and in case
you did not know this, such single head operation *does* support
rebasing. Bought to you by no less than *three* different flavors
of git-rebase.
So "single branch head at a time" is *not* why git-gui doesn't
support rebase. Its because nobody has gotten around to writing it.
> It would be really nice if
> git-gui did not outsource its branch handling and viewing to gitk.
I agree, for the very reason that you mention about being able to
drag and drop commit nodes to setup a rebase. This gets a little
hairy when you want to also drag and drop to create merges, or to
recreate merges, but its still implementable.
I have been considering loading a 'safe' interpreter and throwing
gitk into there, rather than reimplementing its rendering engine
in git-gui. But I haven't had the time to look into how that would
work, and if there is any benefit to it.
> Could git-gui perhaps be merged with giggle at some point of time?
Unlikely. A while ago I considered "Stay in Tcl/Tk or move to
something more 'powerful/better/faster/Linus friendly'" and stayed
in Tcl/Tk. I doubt git-gui will leave Tcl/Tk. giggle is Gtk based.
> Another option might be to let it talk with uDraw(Graph) over a
> socket: uDraw(Graph) keeps track of the graph layout and tells its
> client what has been dragged where.
Interesting. I had not heard of this tool before.
> Rebasing would also be a fine operation for drag and drop on a
> graphical revision history/branch system: pull one head onto another,
> or mark one segment and pull it onto another head. And use the reflog
> to recover from catastrophes...
Yes, I agree. I decided that any sort of rebase operation in git-gui
must be *at least* as easy to use/user friendly as `rebase -i` is.
Anything less is just mocking the end-user. Or something like that.
Anyway, since git-gui is restricted to a graphical interface and
most such interfaces have these pointy rodents available we can do
fancy things like dragging to express what we want to have happen,
instead of moving lines of text around.
Want to write a patch (or series of patches) for git-gui? ;-)
--
Shawn.
^ permalink raw reply
* [PATCH] cvsserver: Fix for work trees
From: Brian Downing @ 2007-08-09 4:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Langhoff, Brian Downing
git-cvsserver used checkout-index internally for commit and annotate.
Since a work tree is required for this to function now, this was
breaking. Work around this by defining GIT_WORK_TREE=. in the
appropriate places.
Signed-off-by: Brian Downing <bdowning@lavos.net>
---
git-cvsserver.perl | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index ae7d511..13dbd27 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -1196,6 +1196,7 @@ sub req_ci
$log->info("Lockless commit start, basing commit on '$tmpdir', index file is '$file_index'");
$ENV{GIT_DIR} = $state->{CVSROOT} . "/";
+ $ENV{GIT_WORK_TREE} = ".";
$ENV{GIT_INDEX_FILE} = $file_index;
# Remember where the head was at the beginning.
@@ -1721,6 +1722,7 @@ sub req_annotate
$log->info("Temp checkoutdir creation successful, basing annotate session work on '$tmpdir', index file is '$file_index'");
$ENV{GIT_DIR} = $state->{CVSROOT} . "/";
+ $ENV{GIT_WORK_TREE} = ".";
$ENV{GIT_INDEX_FILE} = $file_index;
chdir $tmpdir;
--
1.5.3.GIT
^ permalink raw reply related
* Re: git on Cygwin: Not a valid object name HEAD
From: Steffen Prohaska @ 2007-08-09 4:59 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Git Mailing List
In-Reply-To: <46BA4C98.4050005@gmail.com>
On Aug 9, 2007, at 1:07 AM, Mark Levedahl wrote:
> Steffen Prohaska wrote:
>>
> Let me guess, you have Cygwin on the path along with Msys, and had
> it that way when you downloaded the package and it tried to build.
I don't think so. At least I did not actively do something to
have Cygwin in my path.
Steffen
^ permalink raw reply
* Re: [PATCH] allow git-bundle to create bottomless bundle
From: Junio C Hamano @ 2007-08-09 5:04 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Johannes Schindelin, Git Mailing List, Mark Levedahl
In-Reply-To: <46BA8065.6010005@gmail.com>
Mark Levedahl <mlevedahl@gmail.com> writes:
> Junio C Hamano wrote:
>> While "git bundle" was a useful way to sneakernet incremental
>> changes, we did not allow:
>>
> Thanks - I've been thinking for months I could fix this bug, never
> figured it out and didn't want to nag Dscho one more time. I confirm
> that this allows creation of bundles with arbitrary refs, not just
> those under refs/heads. Yahoo!
Actually, there is another bug nearby.
If you do:
git bundle create v2.6-20-v2.6.22.bndl v2.6.20..v2.6.22
the bundle records that it requires v2.6.20^0 commit (correct)
and gives you tag v2.6.22 (incorrect); the bug is that the
object it lists in fact is the commit v2.6.22^0, not the tag.
This is because the revision range operation .. is always about
set of commits, but the code near where my patch touches does
not validate that the sha1 value obtained from dwim_ref()
against the commit object name e->item->sha1 before placing the
head information in the commit.
The attached patch attempts to fix this problem.
---
builtin-bundle.c | 43 ++++++++++++++++++++++++++++++++++++++++++-
t/t5510-fetch.sh | 8 ++++++++
2 files changed, 50 insertions(+), 1 deletions(-)
diff --git a/builtin-bundle.c b/builtin-bundle.c
index 6ae5ab0..2d0e106 100644
--- a/builtin-bundle.c
+++ b/builtin-bundle.c
@@ -208,6 +208,10 @@ static int create_bundle(struct bundle_header *header, const char *path,
struct rev_info revs;
struct child_process rls;
+ /*
+ * NEEDSWORK: this should use something like lock-file
+ * to create temporary that is cleaned up upon error.
+ */
bundle_fd = (!strcmp(path, "-") ? 1 :
open(path, O_CREAT | O_EXCL | O_WRONLY, 0666));
if (bundle_fd < 0)
@@ -267,12 +271,49 @@ static int create_bundle(struct bundle_header *header, const char *path,
* Make sure the refs we wrote out is correct; --max-count and
* other limiting options could have prevented all the tips
* from getting output.
+ *
+ * Non commit objects such as tags and blobs do not have
+ * this issue as they are not affected by those extra
+ * constraints.
*/
- if (!(e->item->flags & SHOWN)) {
+ if (!(e->item->flags & SHOWN) && e->item->type == OBJ_COMMIT) {
warning("ref '%s' is excluded by the rev-list options",
e->name);
+ free(ref);
+ continue;
+ }
+ /*
+ * If you run "git bundle create bndl v1.0..v2.0", the
+ * name of the positive ref is "v2.0" but that is the
+ * commit that is referenced by the tag, and not the tag
+ * itself.
+ */
+ if (hashcmp(sha1, e->item->sha1)) {
+ /*
+ * Is this the positive end of a range expressed
+ * in terms of a tag (e.g. v2.0 from the range
+ * "v1.0..v2.0")?
+ */
+ struct commit *one = lookup_commit_reference(sha1);
+ struct object *obj;
+
+ if (e->item == &(one->object)) {
+ /*
+ * Need to include e->name as an
+ * independent ref to the pack-objects
+ * input, so that the tag is included
+ * in the output; otherwise we would
+ * end up triggering "empty bundle"
+ * error.
+ */
+ obj = parse_object(sha1);
+ obj->flags |= SHOWN;
+ add_pending_object(&revs, obj, e->name);
+ }
+ free(ref);
continue;
}
+
ref_count++;
write_or_die(bundle_fd, sha1_to_hex(e->item->sha1), 40);
write_or_die(bundle_fd, " ", 1);
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index 426017e..439430f 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -145,4 +145,12 @@ test_expect_success 'bundle does not prerequisite objects' '
test 4 = $(git verify-pack -v bundle.pack | wc -l)
'
+test_expect_success 'bundle should be able to create a full history' '
+
+ cd "$D" &&
+ git tag -a -m '1.0' v1.0 master &&
+ git bundle create bundle4 v1.0
+
+'
+
test_done
^ permalink raw reply related
* Re: Submodules
From: Sven Verdoolaege @ 2007-08-09 5:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andy Parkins, git, Junio C Hamano, Dmitry Kakurin
In-Reply-To: <Pine.LNX.4.64.0708082211100.21857@racer.site>
On Wed, Aug 08, 2007 at 10:12:52PM +0100, Johannes Schindelin wrote:
> This is what I did. I cloned msysgit.git, which contains one submodule.
> To initialise that, I did "git submodule init" and "git submodule update".
> It went and cloned the submodule. Fine.
>
> Then I committed in the submodule, a well-needed fix.
>
> If I now go to the superproject again, and say "git submodule status", it
> will not find the newest commit, and complain that it cannot access that
> object.
There must be something else you're not telling us.
This procedure works just fine for me
bash-3.00$ git clone git://repo.or.cz/msysgit.git
Initialized empty Git repository in /home/skimo/git/msysgit/.git/
remote: Generating pack...
remote: Done counting 1857 objects.
remote: Deltifying 1857 objects...
remote: 100% (1857/1857) done
Indexing 1857 objects...
remote: Total 1857 (delta 475), reused 1857 (delta 475)
100% (1857/1857) done
Resolving 475 deltas...
100% (475/475) done
bash-3.00$ cd msysgit/
bash-3.00$ git submodule init
Submodule 'git' (git://repo.or.cz/git/mingw/4msysgit.git/) registered for path 'git'
bash-3.00$ git submodule update
Initialized empty Git repository in /home/skimo/git/msysgit/git/.git/
remote: Generating pack...
remote: Done counting 58074 objects.
remote: Deltifying 58074 objects...
remote: 100% (58074/58074) done
Indexing 58074 objects...
remote: Total 58074 (delta 40790), reused 55132 (delta 37853)
100% (58074/58074) done
Resolving 40790 deltas...
100% (40790/40790) done
Submodule path 'git': checked out 'f1e1dc5119bd9862bb4d2a975c8ca6362ea43af5'
bash-3.00$ cd git/
bash-3.00$ touch a; git add a; git commit -m 'add a'
Created commit 5318784: add a
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 a
bash-3.00$ cd ..
bash-3.00$ git submodule status
+5318784e6d492d988284a4d9aa4025496f2a3309 git (v1.5.3-rc2-690-g5318784)
skimo
^ permalink raw reply
* Re: [PATCH] cvsserver: Fix for work trees
From: Junio C Hamano @ 2007-08-09 5:45 UTC (permalink / raw)
To: Brian Downing; +Cc: git, Martin Langhoff
In-Reply-To: <1186633570700-git-send-email-bdowning@lavos.net>
Hmmmmm....
This is a good fix to adjust to the new world order introduced
by Dscho's rewrite of work-tree stuff, where the rules are:
* When GIT_DIR is set and GIT_WORK_TREE is not, GIT_DIR is used
to read config file, to figure out core.worktree. When
core.worktree is not set, a complicated algorithm is used to
figure out the top of the working tree based on the value of
GIT_DIR, and this can sometimes figure out that you are in a
subdirectory of the working tree. In such a case, you are in
the working tree, but not necessarily at the top.
* Otherwise, commands that require to have working tree now
barf. Earlier they always and consistently treated that your
$cwd is the top of working tree and did not barf.
This new world order is probably an improvement, and if the
rules were like this from the beginning, it would have been
much nicer. However, this _is_ a change of semantics in the
middle of the road, and probably we will see many fallouts like
this. Unfortunate... I am torn between a cleaner semantics and
the short-term pain...
^ permalink raw reply
* Re: [PATCH] Mod. gitk to support REBASE (with stash support).
From: David Kastrup @ 2007-08-09 5:51 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Johannes Schindelin, Alexandre Bourget, Git Mailing List, paulus
In-Reply-To: <20070809032610.GA24573@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> David Kastrup <dak@gnu.org> wrote:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > General question: should this not be in git-gui rather than gitk? Gitk as
>> > of now is really more a viewing tool.
>>
>> Well, yes. But git-gui only works on a single branch head at a time,
>> and that is not enough for rebasing.
>
> Sure. But so does git's command line tools. They tend to only
> work on a single branch at time, the one called `HEAD`.
"tend", and many accept an explicit override: rebase accepts three
commit names, for example. Those that _write_ into the repository
usually _end_ up at HEAD, but most need not start there.
And git-gui does not have any operation either looking at or working
other than on the current HEAD. No diff, no file view, no rebase,
nothing.
> So "single branch head at a time" is *not* why git-gui doesn't
> support rebase. Its because nobody has gotten around to writing it.
I never claimed that it is not possible to put a rebase in there (the
patch does this, after all). I just said that it does not _fit_ in
there since you can't actually look at what you are rebasing on.
>> Could git-gui perhaps be merged with giggle at some point of time?
>
> Unlikely. A while ago I considered "Stay in Tcl/Tk or move to
> something more 'powerful/better/faster/Linus friendly'" and stayed
> in Tcl/Tk. I doubt git-gui will leave Tcl/Tk. giggle is Gtk based.
My bad: git-gui has a nice polished look on my systems (Ubuntu Feisty)
while gitk has an ugly retro-blockish old-font Tk look; so not looking
at the innards, I had assumed they were implemented using different
systems.
> I decided that any sort of rebase operation in git-gui must be *at
> least* as easy to use/user friendly as `rebase -i` is. Anything
> less is just mocking the end-user. Or something like that. Anyway,
> since git-gui is restricted to a graphical interface and most such
> interfaces have these pointy rodents available we can do fancy
> things like dragging to express what we want to have happen, instead
> of moving lines of text around.
>
> Want to write a patch (or series of patches) for git-gui?
User interfaces are really not what I am good at, and I don't even
have enough time to deal with the things I am good at.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Marius Storm-Olsen @ 2007-08-09 6:01 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Johannes Schindelin, Mark Levedahl, Junio C Hamano,
Linus Torvalds, Git Mailing List, Shawn O. Pearce,
Sebastian Schuberth
In-Reply-To: <7E22DF40-1E28-4B8A-B132-18B05136B5E9@zib.de>
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]
>> I have two 'crashes' during installation. I attached snapshots of
>> the requesters. I don't know how to copy text from the installer.
>> Therefore I attached snapshots.
>
> Hmm... how do I get started? I naively chose cygwin as my shell. I
> set
>
> export PATH=$PATH:/cygdrive/c/msysgit/bin
>
> then I tried
>
> $ git clone git://git.kernel.org/pub/scm/git/git.git
> c:/msysgit/bin/git-clone: line 214: git-init: command not found
>
> Maybe it's related to the errors during installation?
>
> How can I build and install git manually, based on the result of
> GitMe-3's basic setup?
Ok, first, which system is this? Windows 2000/XP/Vista?
(The Gitme installer doesn't work on old ones for now)
Try running gitme from a terminal. Download gitme-3.exe into C:\temp,
open a native terminal (Start - Run - Type "cmd" <enter>); then in the
terminal, type:
C:\temp> set PATH=%WINDIR%\system32;%WINDIR%
C:\temp> gitme-3
Does it work then? If so, the problem is likely to be that you have
Cygwin in the system path, which is not advisable/compatible with MSys.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Steffen Prohaska @ 2007-08-09 6:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0708082228520.21857@racer.site>
On Aug 8, 2007, at 11:30 PM, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 8 Aug 2007, Steffen Prohaska wrote:
>
>> On Aug 8, 2007, at 7:20 PM, Johannes Schindelin wrote:
>>
>>> So go for it, everybody, or alternatively do not even bother to
>>> whine.
>>
>> I don't care about these things. I typically start the Explorer by
>> typing explorer into the 'Run ...' box of the start meny. So don't
>> expect anything from me that makes git more beautiful.
>
> That's nice to hear. Finally somebody honest. I'll return the
> favour: I
> have no time to work on the bugs you sent in a reply.
That's fine. I don't expect anything, except for being honest about
the level of Windows support that is currently available. In retrospect,
I relied on the claim that git works in Cygwin without problems (not
made by you but on the mailing list in general). This claim turns out
to be wrong for me, because it highly depends on the details of how you
configure your Cygwin, which makes it impossible to run git in Cygwin
that is configured according to the 'wrong' policy.
Any hint how I can start debugging? I saw mingw for the
first time in my life, yesterday. I only worked with cygwin and various
Visual Studio versions, before.
[ btw, my point was that I'm mostly interested in getting the basic
stuff going first. That is git with the same functionality that
I have on Linux and Mac. The next would be a good integration with
useful tools on Windows, for example git-mergetool should launch
Windows three-way merge tools. The thing I'm least interested is
a beautiful installer, which clutters my Desktop with icons, which
I never use and need to cleanup later anyway.
Bottom line: if you have points on your list that better fit the
described priorities, there would be a good chance that I can look
into one or two of them, for example
Is anything needed to get mingw changes merged to the official repo?
Is anything needed to get changes from the official repo to mingw?
My goal would be to type 'make windist' in the official repo and
get a very basic installer (maybe just a zip archive) that contains
everything needed to run git on Windows. Unpacking this self-contained
installer on a freshly installed Windows should get you going. There
should be no need to install Cygwin or something else.
Is this realistic?
What is needed to get there?
What would be an estimated timeframe to achieve this goal?
Will all this run on Windows XP 64 bit and Windows Vista 64 bit?
After I'm convinced that the level of support for Windows is
sufficient, I will recommend using it, which means that approximately
30 developers will start using git in the way I describe to them.
This will generate a lot of real-world testing. But it should not
generate too many critical issues. People will blame me for
recommending them the tool. ]
Back to debugging...
I tried the following (is this the right way to go?)
- double click on c:\msysgit\msys.bat to start a shell.
- cd git
- make
compiles with some warnings ..., and crashed with a popup...
The popup says (translated to english):
"NTVDM-CPU detected an invalid instruction.
CS:0000 IP:0077 OP: f0 37 05 0c 02 click to close the application."
the last lines I see in the shell are
LINK test-match-trees.exe
SUBDIR git-gui
INDEX lib/
I clicked and the compilation stops. My shell remains alive.
So, I started to run tests.
t0000-basic fails on creation of symlinks. Apparently mingw
doesn't support symlinks to files that do not exist. I reports
'ln: creating symbolic link 'path0sym' to 'hello path0' fails'.
I tried with 'export no_symlinks=1' (is this the right thing
to do? Who should set no_symlinks=1? Should it be set by the
makefile or in some global architecture configuration?).
Now t0000-basic runs except for some noise created by failing
ln, which is not detected as a failure by the test script.
so I ran all tests and they look good. Only t7004
reported 'gpg: error loading iconv.dll'.
I tried 'make install' which yields another crash popup.
Then I tried 'make -k install'
Wow... this crashed my virtual machine. Maybe Parallels should
add msysgit to their test cases. If I read their automatically
generated bugreport correctly it's again related to an invalid
instruction. Maybe mingw uses some op codes it shouldn't?
Hmm... I planned to upgrade to the newest release of Parallels
anyway. Hopefully it's more stable in this regards.
I set NO_TCLTK=1 in the Makefile to skip git-gui during installation.
The installation finished without reporting any problem. Maybe
I have a working git now ...
Steffen
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Steffen Prohaska @ 2007-08-09 6:38 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Johannes Schindelin, Mark Levedahl, Git Mailing List,
Sebastian Schuberth
In-Reply-To: <46BAADC8.9020003@trolltech.com>
On Aug 9, 2007, at 8:01 AM, Marius Storm-Olsen wrote:
>>> I have two 'crashes' during installation. I attached snapshots of
>>> the requesters. I don't know how to copy text from the installer.
>>> Therefore I attached snapshots.
>> Hmm... how do I get started? I naively chose cygwin as my shell. I
>> set
>> export PATH=$PATH:/cygdrive/c/msysgit/bin
>> then I tried
>> $ git clone git://git.kernel.org/pub/scm/git/git.git c:/msysgit/
>> bin/git-clone: line 214: git-init: command not found
>> Maybe it's related to the errors during installation?
>> How can I build and install git manually, based on the result of
>> GitMe-3's basic setup?
>
> Ok, first, which system is this? Windows 2000/XP/Vista?
> (The Gitme installer doesn't work on old ones for now)
XP 32bit.
> Try running gitme from a terminal. Download gitme-3.exe into C:
> \temp, open a native terminal (Start - Run - Type "cmd" <enter>);
> then in the terminal, type:
> C:\temp> set PATH=%WINDIR%\system32;%WINDIR%
> C:\temp> gitme-3
> Does it work then? If so, the problem is likely to be that you have
> Cygwin in the system path, which is not advisable/compatible with
> MSys.
I had cygwin at the tail of my PATH. After removing it the
installation went through flawlessly.
A check in the installer would be a good idea.
Would you recommend running git only from the mingw shell prompt,
or can I start it also from a Cygwin shell prompt?
Thanks a lot,
Steffen
^ permalink raw reply
* [PATCH 1/3] Teach update-paranoid how to store ACLs organized by groups
From: Shawn O. Pearce @ 2007-08-09 6:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In some applications of this paranoid update hook the set of ACL
rules that need to be applied to a user can be large, and the
number of users that those rules must also be applied to can be
more than a handful of individuals. Rather than repeating the same
rules multiple times (once for each user) we now allow users to be
members of groups, where the group supplies the list of ACL rules.
For various reasons we don't depend on the underlying OS groups
and instead perform our own group handling.
Users can be made a member of one or more groups by setting the
user.memberOf property within the "users/$who.acl" file:
[user]
memberOf = developer
memberOf = administrator
This will cause the hook to also parse the "groups/$groupname.acl"
file for each value of user.memberOf, and merge any allow rules
that match the current repository with the user's own private rules
(if they had any).
Since some rules are basically the same but may have a component
differ based on the individual user, any user.* key may be inserted
into a rule using the "${user.foo}" syntax. The allow rule does
not match if the user does not define one (and exactly one) value
for the key "foo".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/hooks/update-paranoid | 60 ++++++++++++++++++++++++++++++-----------
1 files changed, 44 insertions(+), 16 deletions(-)
diff --git a/contrib/hooks/update-paranoid b/contrib/hooks/update-paranoid
index 5ee1835..fb2aca3 100644
--- a/contrib/hooks/update-paranoid
+++ b/contrib/hooks/update-paranoid
@@ -118,22 +118,29 @@ sub info ($) {
print STDERR "-Info- $_[0]\n" if $debug;
}
-sub parse_config ($$) {
- my ($data, $fn) = @_;
- info "Loading $fn";
- open(I,'-|','git',"--git-dir=$acl_git",'cat-file','blob',$fn);
+sub git_value (@) {
+ open(T,'-|','git',@_); local $_ = <T>; chop; close T; $_;
+}
+
+sub parse_config ($$$$) {
+ my $data = shift;
+ local $ENV{GIT_DIR} = shift;
+ my $br = shift;
+ my $fn = shift;
+ info "Loading $br:$fn";
+ open(I,'-|','git','cat-file','blob',"$br:$fn");
my $section = '';
while (<I>) {
chomp;
if (/^\s*$/ || /^\s*#/) {
} elsif (/^\[([a-z]+)\]$/i) {
- $section = $1;
+ $section = lc $1;
} elsif (/^\[([a-z]+)\s+"(.*)"\]$/i) {
- $section = "$1.$2";
+ $section = join('.',lc $1,$2);
} elsif (/^\s*([a-z][a-z0-9]+)\s*=\s*(.*?)\s*$/i) {
- push @{$data->{"$section.$1"}}, $2;
+ push @{$data->{join('.',$section,lc $1)}}, $2;
} else {
- deny "bad config file line $. in $fn";
+ deny "bad config file line $. in $br:$fn";
}
}
close I;
@@ -202,11 +209,6 @@ sub check_committers (@) {
}
}
-sub git_value (@) {
- open(T,'-|','git',@_); local $_ = <T>; chop; close T;
- $_;
-}
-
deny "No GIT_DIR inherited from caller" unless $git_dir;
deny "Need a ref name" unless $ref;
deny "Refusing funny ref $ref" unless $ref =~ s,^refs/,,;
@@ -231,13 +233,39 @@ $op = 'U' if ($op eq 'R'
&& $ref =~ m,^heads/,
&& $old eq git_value('merge-base',$old,$new));
-# Load the user's ACL file.
+# Load the user's ACL file. Expand groups (user.memberof) one level.
{
my %data = ('user.committer' => []);
- parse_config(\%data, "$acl_branch:users/$this_user.acl");
+ parse_config(\%data,$acl_git,$acl_branch,"external/$repository_name.acl");
+
+ %data = (
+ 'user.committer' => $data{'user.committer'},
+ 'user.memberof' => [],
+ );
+ parse_config(\%data,$acl_git,$acl_branch,"users/$this_user.acl");
+
%user_committer = map {$_ => $_} @{$data{'user.committer'}};
- my $rules = $data{"repository.$repository_name.allow"} || [];
+ my $rule_key = "repository.$repository_name.allow";
+ my $rules = $data{$rule_key} || [];
+
+ foreach my $group (@{$data{'user.memberof'}}) {
+ my %g;
+ parse_config(\%g,$acl_git,$acl_branch,"groups/$group.acl");
+ my $group_rules = $g{$rule_key};
+ push @$rules, @$group_rules if $group_rules;
+ }
+
+RULE:
foreach (@$rules) {
+ while (/\${user\.([a-z][a-zA-Z0-9]+)}/) {
+ my $k = lc $1;
+ my $v = $data{"user.$k"};
+ next RULE unless defined $v;
+ next RULE if @$v != 1;
+ next RULE unless defined $v->[0];
+ s/\${user\.$k}/$v->[0]/g;
+ }
+
if (/^([CDRU ]+)\s+for\s+([^\s]+)$/) {
my $ops = $1;
my $ref = $2;
--
1.5.3.rc4.29.g74276
^ permalink raw reply related
* [PATCH 2/3] Teach the update-paranoid to look at file differences
From: Shawn O. Pearce @ 2007-08-09 6:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In some applications of the update hook a user may be allowed to
modify a branch, but only if the file level difference is also an
allowed change. This is the commonly requested feature of allowing
users to modify only certain files.
A new repository.*.allow syntax permits granting the three basic
file level operations:
A: file is added relative to the other tree
M: file exists in both trees, but its SHA-1 or mode differs
D: file is removed relative to the other tree
on a per-branch and path-name basis. The user must also have a
branch level allow line already granting them access to create,
rewind or update (CRU) that branch before the hook will consult
any file level rules.
In order for a branch change to succeed _all_ files that differ
relative to some base (by default the old value of this branch,
but it can also be any valid tree-ish) must be allowed by file
level allow rules. A push is rejected if any diff exists that
is not covered by at least one allow rule.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/hooks/update-paranoid | 112 ++++++++++++++++++++++++++++++++++++++---
1 files changed, 105 insertions(+), 7 deletions(-)
diff --git a/contrib/hooks/update-paranoid b/contrib/hooks/update-paranoid
index fb2aca3..84ed452 100644
--- a/contrib/hooks/update-paranoid
+++ b/contrib/hooks/update-paranoid
@@ -102,6 +102,8 @@ my ($this_user) = getpwuid $<; # REAL_USER_ID
my $repository_name;
my %user_committer;
my @allow_rules;
+my @path_rules;
+my %diff_cache;
sub deny ($) {
print STDERR "-Deny- $_[0]\n" if $debug;
@@ -122,6 +124,13 @@ sub git_value (@) {
open(T,'-|','git',@_); local $_ = <T>; chop; close T; $_;
}
+sub match_string ($$) {
+ my ($acl_n, $ref) = @_;
+ ($acl_n eq $ref)
+ || ($acl_n =~ m,/$, && substr($ref,0,length $acl_n) eq $acl_n)
+ || ($acl_n =~ m,^\^, && $ref =~ m:$acl_n:);
+}
+
sub parse_config ($$$$) {
my $data = shift;
local $ENV{GIT_DIR} = shift;
@@ -209,6 +218,31 @@ sub check_committers (@) {
}
}
+sub load_diff ($) {
+ my $base = shift;
+ my $d = $diff_cache{$base};
+ unless ($d) {
+ local $/ = "\0";
+ open(T,'-|','git','diff-tree',
+ '-r','--name-status','-z',
+ $base,$new) or return undef;
+ my %this_diff;
+ while (<T>) {
+ my $op = $_;
+ chop $op;
+
+ my $path = <T>;
+ chop $path;
+
+ $this_diff{$path} = $op;
+ }
+ close T or return undef;
+ $d = \%this_diff;
+ $diff_cache{$base} = $d;
+ }
+ return $d;
+}
+
deny "No GIT_DIR inherited from caller" unless $git_dir;
deny "Need a ref name" unless $ref;
deny "Refusing funny ref $ref" unless $ref =~ s,^refs/,,;
@@ -266,7 +300,19 @@ RULE:
s/\${user\.$k}/$v->[0]/g;
}
- if (/^([CDRU ]+)\s+for\s+([^\s]+)$/) {
+ if (/^([AMD ]+)\s+of\s+([^\s]+)\s+for\s+([^\s]+)\s+diff\s+([^\s]+)$/) {
+ my ($ops, $pth, $ref, $bst) = ($1, $2, $3, $4);
+ $ops =~ s/ //g;
+ $pth =~ s/\\\\/\\/g;
+ $ref =~ s/\\\\/\\/g;
+ push @path_rules, [$ops, $pth, $ref, $bst];
+ } elsif (/^([AMD ]+)\s+of\s+([^\s]+)\s+for\s+([^\s]+)$/) {
+ my ($ops, $pth, $ref) = ($1, $2, $3);
+ $ops =~ s/ //g;
+ $pth =~ s/\\\\/\\/g;
+ $ref =~ s/\\\\/\\/g;
+ push @path_rules, [$ops, $pth, $ref, $old];
+ } elsif (/^([CDRU ]+)\s+for\s+([^\s]+)$/) {
my $ops = $1;
my $ref = $2;
$ops =~ s/ //g;
@@ -300,13 +346,65 @@ foreach my $acl_entry (@allow_rules) {
next unless $acl_ops =~ /^[CDRU]+$/; # Uhh.... shouldn't happen.
next unless $acl_n;
next unless $op =~ /^[$acl_ops]$/;
+ next unless match_string $acl_n, $ref;
+
+ # Don't test path rules on branch deletes.
+ #
+ grant "Allowed by: $acl_ops for $acl_n" if $op eq 'D';
+
+ # Aggregate matching path rules; allow if there aren't
+ # any matching this ref.
+ #
+ my %pr;
+ foreach my $p_entry (@path_rules) {
+ my ($p_ops, $p_n, $p_ref, $p_bst) = @$p_entry;
+ next unless $p_ref;
+ push @{$pr{$p_bst}}, $p_entry if match_string $p_ref, $ref;
+ }
+ grant "Allowed by: $acl_ops for $acl_n" unless %pr;
- grant "Allowed by: $acl_ops for $acl_n"
- if (
- ($acl_n eq $ref)
- || ($acl_n =~ m,/$, && substr($ref,0,length $acl_n) eq $acl_n)
- || ($acl_n =~ m,^\^, && $ref =~ m:$acl_n:)
- );
+ # Allow only if all changes against a single base are
+ # allowed by file path rules.
+ #
+ my @bad;
+ foreach my $p_bst (keys %pr) {
+ my $diff_ref = load_diff $p_bst;
+ deny "Cannot difference trees." unless ref $diff_ref;
+
+ my %fd = %$diff_ref;
+ foreach my $p_entry (@{$pr{$p_bst}}) {
+ my ($p_ops, $p_n, $p_ref, $p_bst) = @$p_entry;
+ next unless $p_ops =~ /^[AMD]+$/;
+ next unless $p_n;
+
+ foreach my $f_n (keys %fd) {
+ my $f_op = $fd{$f_n};
+ next unless $f_op;
+ next unless $f_op =~ /^[$p_ops]$/;
+ delete $fd{$f_n} if match_string $p_n, $f_n;
+ }
+ last unless %fd;
+ }
+
+ if (%fd) {
+ push @bad, [$p_bst, \%fd];
+ } else {
+ # All changes relative to $p_bst were allowed.
+ #
+ grant "Allowed by: $acl_ops for $acl_n diff $p_bst";
+ }
+ }
+
+ foreach my $bad_ref (@bad) {
+ my ($p_bst, $fd) = @$bad_ref;
+ print STDERR "\n";
+ print STDERR "Not allowed to make the following changes:\n";
+ print STDERR "(base: $p_bst)\n";
+ foreach my $f_n (sort keys %$fd) {
+ print STDERR " $fd->{$f_n} $f_n\n";
+ }
+ }
+ deny "You are not permitted to $op $ref";
}
close A;
deny "You are not permitted to $op $ref";
--
1.5.3.rc4.29.g74276
^ permalink raw reply related
* [PATCH 3/3] Use the empty tree for base diff in paranoid-update on new branches
From: Shawn O. Pearce @ 2007-08-09 6:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
We have to load a tree difference for the purpose of testing
file patterns. But if our branch is being created and there is no
specific base to difference against in the rule our base will be
'0'x40. This is (usually) not a valid tree-ish object in a Git
repository, so there's nothing to difference against.
Instead of creating the empty tree and running git-diff against
that we just take the output of `ls-tree -r --name-only` and mark
every returned pathname as an add.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/hooks/update-paranoid | 31 +++++++++++++++++++++----------
1 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/contrib/hooks/update-paranoid b/contrib/hooks/update-paranoid
index 84ed452..068fa37 100644
--- a/contrib/hooks/update-paranoid
+++ b/contrib/hooks/update-paranoid
@@ -223,20 +223,31 @@ sub load_diff ($) {
my $d = $diff_cache{$base};
unless ($d) {
local $/ = "\0";
- open(T,'-|','git','diff-tree',
- '-r','--name-status','-z',
- $base,$new) or return undef;
my %this_diff;
- while (<T>) {
- my $op = $_;
- chop $op;
+ if ($base =~ /^0{40}$/) {
+ open(T,'-|','git','ls-tree',
+ '-r','--name-only','-z',
+ $new) or return undef;
+ while (<T>) {
+ chop;
+ $this_diff{$_} = 'A';
+ }
+ close T or return undef;
+ } else {
+ open(T,'-|','git','diff-tree',
+ '-r','--name-status','-z',
+ $base,$new) or return undef;
+ while (<T>) {
+ my $op = $_;
+ chop $op;
- my $path = <T>;
- chop $path;
+ my $path = <T>;
+ chop $path;
- $this_diff{$path} = $op;
+ $this_diff{$path} = $op;
+ }
+ close T or return undef;
}
- close T or return undef;
$d = \%this_diff;
$diff_cache{$base} = $d;
}
--
1.5.3.rc4.29.g74276
^ permalink raw reply related
* Re: git on Cygwin: Not a valid object name HEAD
From: Marius Storm-Olsen @ 2007-08-09 6:47 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Johannes Schindelin, Mark Levedahl, Git Mailing List,
Sebastian Schuberth
In-Reply-To: <872D90BF-CB37-496B-9E7D-3C9A19125EBA@zib.de>
[-- Attachment #1: Type: text/plain, Size: 929 bytes --]
Steffen Prohaska said the following on 09.08.2007 08:38:
> On Aug 9, 2007, at 8:01 AM, Marius Storm-Olsen wrote:
>> Does it work then? If so, the problem is likely to be that you
>> have Cygwin in the system path, which is not advisable/compatible
>> with MSys.
>
> I had cygwin at the tail of my PATH. After removing it the
> installation went through flawlessly.
>
> A check in the installer would be a good idea.
>
> Would you recommend running git only from the mingw shell prompt,
> or can I start it also from a Cygwin shell prompt?
Well, some say that you can, but I'm not sure (especially since you're
using Cygwin in Windows EOL mode, which is opposite of MSys).
The way I use it is either from the MSys shell, or directly from CMD
shell. (If you have PATH=c:\msysgit\bin;C:\msysgit\mingw\bin;%PATH% it
works quite well like that.)
Actually, I use CMD most of the time..
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH] Mod. gitk to support REBASE (with stash support).
From: Shawn O. Pearce @ 2007-08-09 6:58 UTC (permalink / raw)
To: David Kastrup
Cc: Johannes Schindelin, Alexandre Bourget, Git Mailing List, paulus
In-Reply-To: <85odhhntmb.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> >> Well, yes. But git-gui only works on a single branch head at a time,
> >> and that is not enough for rebasing.
> >
> > Sure. But so does git's command line tools. They tend to only
> > work on a single branch at time, the one called `HEAD`.
>
> "tend", and many accept an explicit override: rebase accepts three
> commit names, for example. Those that _write_ into the repository
> usually _end_ up at HEAD, but most need not start there.
>
> And git-gui does not have any operation either looking at or working
> other than on the current HEAD. No diff, no file view, no rebase,
> nothing.
Uh, "Repository->Browse Browse Branch Files..." will let you look
at files from any commit-ish, not just HEAD or an existing branch.
You can open many file browsers at once against the same commit or
different commits. Double clicking a file opens it in the blame
viewer, which itself can move around history a little bit.
"Merge->Local Merge..." will let you select any another commit to
merge with this current branch. That's two commits.
So your assertion that git-gui only works with one commit, HEAD,
is wrong.
And git-rebase taking three arguments? Its actually two; if it
is given the optional final argument of the branch to rebase it
first switches to that branch, then does the rebase. In other
words these are identical:
# this...
git checkout to-rebase &&
git rebase --onto upstreamA upstreamB
# is the same as this...
git rebase --onto upstreamA upstreamB to-rebase
> >> Could git-gui perhaps be merged with giggle at some point of time?
> >
> > Unlikely. A while ago I considered "Stay in Tcl/Tk or move to
> > something more 'powerful/better/faster/Linus friendly'" and stayed
> > in Tcl/Tk. I doubt git-gui will leave Tcl/Tk. giggle is Gtk based.
>
> My bad: git-gui has a nice polished look on my systems (Ubuntu Feisty)
> while gitk has an ugly retro-blockish old-font Tk look; so not looking
> at the innards, I had assumed they were implemented using different
> systems.
Nope. Myself and a few others have just spent some time making
git-gui look somewhat sane by default. It doesn't always; there are
at least a few places where it still has too much of a Tk-ish look
to it. This is especially true in a few of the dialog boxes that
git-gui might open when you are about to do something potentially
bad.
> User interfaces are really not what I am good at, and I don't even
> have enough time to deal with the things I am good at.
Hah. Me neither. Yet git-gui exists.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Mod. gitk to support REBASE (with stash support).
From: Shawn O. Pearce @ 2007-08-09 7:21 UTC (permalink / raw)
To: David Kastrup
Cc: Johannes Schindelin, Alexandre Bourget, Git Mailing List, paulus
In-Reply-To: <20070809065810.GC24573@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> David Kastrup <dak@gnu.org> wrote:
> > other than on the current HEAD. No diff, no file view, no rebase,
> > nothing.
>
> So your assertion that git-gui only works with one commit, HEAD,
> is wrong.
Oh, and git-gui has some features that don't even really exist in the
shell porcelain. E.g. you can do this all from the Branch->Create
dialog in git-gui:
b=refs/heads/branch-to-create
git fetch origin foof:refs/remotes/origin/foof &&
if test git show-ref $b
then
git push . refs/remotes/origin/foof:$b
else
git branch $b refs/remotes/origin/foof
fi &&
git checkout foof
That's actually somewhat hard to do on the command line, but as
it turns out is just insanely handy to have for some workflows.
It amounts to "Always fetch the remote tracking branch, make sure
my local branch will fast-forward to it, do so, then checkout my
local branch; but if the local branch doesn't exist create it,
then do the checkout anyway".
I used git-push above just because its handy to do the fast-forward
check and update if successful; that's not what git-gui uses
internally because its actually a really stupid abuse of the
push command. But it was shorter to write out the shell code for
this email. Wow, OK, I just spent more time explaining why I used
git-push than to just write the damn fast-forward test. Whatever.
I count 1-2 commits in that operation, depending on if your local
branch exists or not. Oh, and this nifty thing called a remote.
But you are correct to some extent, there's no diff of a prior commit
available from within git-gui. Or rebase. I'd like to fix both.
But its time for sleep instead. Oh, and I'm supposed to be fixing
some "features" of fast-import this week too...
--
Shawn.
^ permalink raw reply
* msysgit: does git gui work?
From: Steffen Prohaska @ 2007-08-09 7:24 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Git Mailing List, Shawn O. Pearce, Johannes Schindelin
Does 'git gui' work for you in msysgit?
I get
Invalid command name "git-version"
while executing
"git-version >= 1.5.3"
(in namespace eval "::blame" script line 36)
[...]
with msysgit (v1.5.3-rc2-690-g8ca1f6a).
Steffen
^ permalink raw reply
* git-filter-branch
From: Mike Hommey @ 2007-08-09 6:34 UTC (permalink / raw)
To: Git Mailing List
Hi,
What is supposed to be the usage() of git-fetch-branch ?
git-filter-branch itself says:
git-filter-branch [-d TEMPDIR] [FILTERS] DESTBRANCH [REV-RANGE]
while the documentation doesn't explicitely talk about DESTBRANCH,
expect in the form of an hypothetical /newbranch/, that you obviously
don't give to the command line.
And whereas git-filter-branch itself says there is such an argument,
it actually doesn't take it, and doesn't seem to be hardwired to create
a new branch instead of overwriting the current one.
So what is git-filter-branch supposed to be doing ?
As a side note, if it ever happens that git-filter-branch can create a
new branch, it might be nice to have each commit on the branch to have
the original commit as parent, as well as its branch parent, so that
they are seen as merges.
Cheers,
Mike
^ permalink raw reply
* Re: [GUILT PATCH 2/5] guilt-guard: Assign guards to patches in series
From: Eric Lesh @ 2007-08-09 7:34 UTC (permalink / raw)
To: Josef Sipek; +Cc: git
In-Reply-To: <20070731040510.GD12918@filer.fsl.cs.sunysb.edu>
[ I'm finally back to this. Thanks for your comments. ]
Josef Sipek <jsipek@fsl.cs.sunysb.edu> writes:
[...]
>> +}
>> +
>> +# usage: set_guards <patch> <guards...>
>> +set_guards()
>> +{
>> + p="$1"
>
> Again, be careful about namespace polution.
>
Can I use "local", or is it a bashism? If not, use parentheses around
the function body?
>> + shift
>> + for x in "$@"; do
>> + if [ -z $(printf %s "$x" | grep -e "^[+-]") ]; then
>
> Out of curiosity, why printf and not echo?
>
For guards named '-e' or other funky things echo doesn't like and can't
process with echo --.
>> + echo "'$x' is not a valid guard name"
>> + else
>> + sed -i -e "s,^\($p[[:space:]]*.*\)$,\1 #$x," "$series"
>
> The regexp is in double quotes, so you should escape the $ (EOL), as well as
> all the \. Yep, this is shell scripting at its worst.
>
Yikes.
[...]
I'm trying to clean the rest and get it ready again. This whole series
will definitely need to incubate for a while once there's a
reasonable-looking version, to make sure nothing goes crazy. Hopefully
it ends up being useful somewhere!
Eric
^ permalink raw reply
* Re: 'pu' branch for StGIT
From: Karl Hasselström @ 2007-08-09 7:38 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git, Catalin Marinas, Yann Dirson
In-Reply-To: <20070808201003.nm90u2s5ny888wcc@webmailbeta.spamcop.net>
On 2007-08-08 20:10:03 -0400, Pavel Roskin wrote:
> Quoting Karl Hasselström <kha@treskal.com>:
>
> > It was all due to a sloppy regexp. This is the fix:
>
> Thank you!
You did all the work on this one.
> And by the way, please fix the description of the commit where you
> added --smtp-server option. You added it to "stg mail", not to "stg
> add".
Mmm, thanks. Will fix tonight.
I take it this all means you're actually using my branch? What's your
opinion on its usefulness?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Mod. gitk to support REBASE (with stash support).
From: David Kastrup @ 2007-08-09 7:55 UTC (permalink / raw)
To: git
In-Reply-To: <20070809065810.GC24573@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> David Kastrup <dak@gnu.org> wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>> >> Well, yes. But git-gui only works on a single branch head at a time,
>> >> and that is not enough for rebasing.
>> >
>> > Sure. But so does git's command line tools. They tend to only
>> > work on a single branch at time, the one called `HEAD`.
>>
>> "tend", and many accept an explicit override: rebase accepts three
>> commit names, for example. Those that _write_ into the repository
>> usually _end_ up at HEAD, but most need not start there.
>>
>> And git-gui does not have any operation either looking at or working
>> other than on the current HEAD. No diff, no file view, no rebase,
>> nothing.
>
> Uh, "Repository->Browse Browse Branch Files..." will let you look at
> files from any commit-ish, not just HEAD or an existing branch.
Duh. But why are the menus called "Browse master's Files" and "Browse
Branch Files" rather than "Browse heads/master" or "Browse master's
head" versus "Browse any commit" or maybe just "Browse current" and
"Browse at ..."? "Browse Branch Files" is _really_ misleading.
> You can open many file browsers at once against the same commit or
> different commits. Double clicking a file opens it in the blame
> viewer, which itself can move around history a little bit.
I though about the blame window after my first posting (actually, I
did not yet notice one can move around in the revisions in the blame.
Nice. Now if it supported utf-8 files...). Well, yes.
> "Merge->Local Merge..." will let you select any another commit to
> merge with this current branch. That's two commits.
Ok, ok. Still, commits and history are much more visible as whole in
gitk: git-gui mostly lets one pick out single views (the blame window
is probably the closest one gets to moving about, but then it _is_ a
moving view which always shows a single point of time ultimately).
> So your assertion that git-gui only works with one commit, HEAD,
> is wrong.
Yes.
--
David Kastrup
^ permalink raw reply
* Re: [GUILT PATCH 2/5] guilt-guard: Assign guards to patches in series
From: David Kastrup @ 2007-08-09 8:17 UTC (permalink / raw)
To: git
In-Reply-To: <87bqdhnotj.fsf@hubert.paunchy.net>
Eric Lesh <eclesh@ucla.edu> writes:
> [ I'm finally back to this. Thanks for your comments. ]
>
> Josef Sipek <jsipek@fsl.cs.sunysb.edu> writes:
>
> [...]
>
>>> +}
>>> +
>>> +# usage: set_guards <patch> <guards...>
>>> +set_guards()
>>> +{
>>> + p="$1"
>>
>> Again, be careful about namespace polution.
>>
>
> Can I use "local", or is it a bashism? If not, use parentheses around
> the function body?
>
>>> + shift
>>> + for x in "$@"; do
>>> + if [ -z $(printf %s "$x" | grep -e "^[+-]") ]; then
>>> + echo "'$x' is not a valid guard name"
>>> + else
>>> + sed -i -e "s,^\($p[[:space:]]*.*\)$,\1 #$x," "$series"
>>
>> Out of curiosity, why printf and not echo?
>>
>
> For guards named '-e' or other funky things echo doesn't like and
> can't process with echo --.
The problem with the above is that it reacts strangely to multiline
options.
Should be much better (and faster on shells without builtin printf) to
use
case "$x" in
[+-]*)
sed -i -e ... ;;
*)
echo "'$x' is not ...
esac
and this runs portably without forking on shells that are 30 years
old. Shell script programmers _really_ should know "case" inside out.
Also, instead of 'for x in "$@"' one can just write "for x'
>> The regexp is in double quotes, so you should escape the $ (EOL),
>> as well as all the \. Yep, this is shell scripting at its worst.
\ does not need to be escaped in double quotes except before \, $ and `.
You can write
sed -i -e "s,^\($p[[:space:]]*.*\)\$,\1 #$x," "$series"
and that's fine.
--
David Kastrup
^ permalink raw reply
* Re: [GUILT PATCH 2/5] guilt-guard: Assign guards to patches in series
From: Thomas Adam @ 2007-08-09 8:22 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86r6mdp1e1.fsf@lola.quinscape.zz>
On 09/08/07, David Kastrup <dak@gnu.org> wrote:
> sed -i -e "s,^\($p[[:space:]]*.*\)\$,\1 #$x," "$series"
>
> and that's fine.
I'm surprised to see 'sed -i' being at all, it's certainly non-portable.
-- Thomas Adam
^ permalink raw reply
* Re: [GUILT PATCH 2/5] guilt-guard: Assign guards to patches in series
From: David Kastrup @ 2007-08-09 8:43 UTC (permalink / raw)
To: git
In-Reply-To: <18071eea0708090122h79dec205j4528f4dfd7aab588@mail.gmail.com>
"Thomas Adam" <thomas.adam22@gmail.com> writes:
> On 09/08/07, David Kastrup <dak@gnu.org> wrote:
>> sed -i -e "s,^\($p[[:space:]]*.*\)\$,\1 #$x," "$series"
>>
>> and that's fine.
>
> I'm surprised to see 'sed -i' being at all, it's certainly non-portable.
Yes. Neither is [[:space:]]. The above actually is pretty much
equivalent to
$(RM) "$series+"
sed "/^$p/s/\$/ #$x/" "$series" >"$series+"
$(MV) "$series+" "$series"
Which is probably not what was intended (the whole [[:space:]]
construct is irrelevant). More likely it was intended to do something
like
$(RM) "$series+"
sed "/^$p[ ]/s/\$/ #$x/" "$series" >"$series+"
$(MV) "$series+" "$series"
or if $p can contain slashes but not commata,
$(RM) "$series+"
sed "\,^$p[ ],s,\$, #$x," "$series" >"$series+"
$(MV) "$series+" "$series"
Note that the included tab character will get safely from any shell to
any sed.
--
David Kastrup
^ 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