* Re: [ANNOUNCE] ugit: the pythonic git gui
From: Guilhem Bonnefille @ 2008-01-02 10:42 UTC (permalink / raw)
To: David; +Cc: git
In-Reply-To: <402731c90712281449g3d0c4f53w48c65dc8883bbbb3@mail.gmail.com>
Hi,
Good to learn a new GUI is available for Git.
But, for people like me, not enougth curious to install the software,
do you have any screenshots somewhere?
2007/12/28, David <davvid@gmail.com>:
> ugit, the pyqt-based git gui, has been taking shape as of late.
>
> First off, I'd like to thank everyone that replied with suggestions
> and criticism. This list is extremely helpful with regards to
> providing honest software critiques.
>
> New features since the last announcement (almost all of which were
> mentioned in one way or another on this list):
>
> * inotify support (we've removed the "Rescan" button)
> * Patch hunk un/staging
> * Allows un/staging selected patch hunk lines (without --unidiff-zero)
> * Prepped for i18n ("env LANG=ja_JP ugit" looks pretty cool now)
> * I'm a westerner, so the unstaged list is now on the left and the
> staged list is on the right (thanks Jason)
> * Optimizations to improve the interactivity of the patch browser
> * Misc. fixes for MacOS and Windows (thanks Steffan and Sebastian)
> * Uses default system colors whenever possible [no more darkness] (thanks Alex)
> * No longer requires PYTHONPATH
>
> Source code (requires pyqt4-dev-tools to build):
> http://repo.or.cz/w/ugit.git
>
> Tarballs (require a stock pyqt-4.3 installation):
> http://ugit.justroots.com/
>
> I'll try and get some .deb, .rpm, etc. action happening soon.
>
> p.s.
> If you read ugit as "(f)uh-git" or "ugly-git", then that's good since
> I think that falls in line with the git style ;-)
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/
^ permalink raw reply
* Re: Git and securing a repository
From: Jakub Narebski @ 2008-01-02 10:51 UTC (permalink / raw)
To: Gonzalo Garramuño; +Cc: David Symonds, git
In-Reply-To: <477B69ED.3090107@advancedsl.com.ar>
Gonzalo Garramuño <ggarra@advancedsl.com.ar> writes:
> David Symonds wrote:
>>
>> You can do arbitrarily-fine-grained authentication via the
>> pre-receive hook.
>>
>
> Can you provide some more info? Looking at the kernel.org git docs,
> the pre-receive hook seems very limited as no parameters are allowed.
> So I'm not sure how an authentication system could be created.
>
> It also seems to be a push hook only (not invoked on pulls).
Some of read-only (fetch only) access protocols do not support
authentication: http, ftp, rsync, git. Authentication is provided only
for access via ssh and for push via https (WebDAV).
There is example update hook in contrib/hooks, named update-paranoid,
which could be base of what you want. Note that you probably rather
use newer pre-receive hook instead of older update hook.
AFAIK both update and pre-receive hooks are invoked also on fetch...
but I might be mistaken.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: reflog weirdness
From: Thien-Thi Nguyen @ 2008-01-02 11:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprwqcqk3.fsf@gitster.siamese.dyndns.org>
() Junio C Hamano <gitster@pobox.com>
() Fri, 28 Dec 2007 16:06:36 -0800
"git-rebase -i"
thanks. works great.
thi
^ permalink raw reply
* Trouble generating info documentation
From: David Kastrup @ 2008-01-02 12:37 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 102 bytes --]
Hi,
in my version of docbook2x, the --to-stdout option is broken and
requires the following patch:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 654 bytes --]
diff -u -L /sudo:root@lola.quinscape.zz:/usr/bin/db2x_texixml -L /tmp/buffer-content-236002qn /tmp/tramp.23600D1t /tmp/buffer-content-236002qn
--- /tmp/buffer-content-236002qn
+++ /sudo:root@lola.quinscape.zz:/usr/bin/db2x_texixml
@@ -782,9 +782,11 @@
$openstr = '>-';
}
} else {
- $openstr .= '> ' . shell_quote($filename);
- print "$filename\n"
- if $self->{options}->{'list-files'};
+ if ($self->{options}->{'list-files'})
+ {
+ $openstr .= '> ' . shell_quote($filename);
+ print "$filename\n";
+ }
}
}
Diff finished. Wed Jan 2 13:33:08 2008
[-- Attachment #3: Type: text/plain, Size: 1872 bytes --]
After fixing this (anybody got a clue how to get this upstream?) I get
the following problem upon make info:
makeinfo --no-split gitman.texi
gitman.texi:2462: Node `CO1-1' previously defined at line 1830.
gitman.texi:9205: Node `CO1-1' previously defined at line 1830.
gitman.texi:9206: Node `CO1-2' previously defined at line 2463.
gitman.texi:9207: Node `CO1-3' previously defined at line 2465.
gitman.texi:9229: Node `CO2-1' previously defined at line 1848.
gitman.texi:9230: Node `CO2-2' previously defined at line 1849.
gitman.texi:12904: Node `CO1-1' previously defined at line 1830.
gitman.texi:12905: Node `CO1-2' previously defined at line 2463.
gitman.texi:16075: warning: @strong{Note...} produces a spurious cross-reference in Info; reword to avoid that.
gitman.texi:18303: Node `CO1-1' previously defined at line 1830.
gitman.texi:18304: Node `CO1-2' previously defined at line 2463.
gitman.texi:18305: Node `CO1-3' previously defined at line 2465.
gitman.texi:18332: Node `CO2-1' previously defined at line 1848.
gitman.texi:18348: Node `CO3-1' previously defined at line 9254.
gitman.texi:18349: Node `CO3-2' previously defined at line 9255.
gitman.texi:18350: Node `CO3-3' previously defined at line 9256.
gitman.texi:18373: Node `CO4-1' previously defined at line 9277.
gitman.texi:18375: Node `CO4-2' previously defined at line 9278.
gitman.texi:18376: Node `CO4-3' previously defined at line 9279.
gitman.texi:18408: Node `CO5-1' previously defined at line 9301.
gitman.texi:18412: Node `CO5-2' previously defined at line 9302.
gitman.texi:22624: Node `CO1-1' previously defined at line 1830.
gitman.texi:22625: Node `CO1-2' previously defined at line 2463.
gitman.texi:22626: Node `CO1-3' previously defined at line 2465.
makeinfo: Removing output file `/rep/git/Documentation/gitman.info' due to errors; use --force to preserve.
--
David Kastrup
^ permalink raw reply
* Re: input validation in receive-pack
From: Daniel Barkalow @ 2008-01-02 15:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Koegler, git, Johannes Schindelin
In-Reply-To: <7vhchw3hkz.fsf@gitster.siamese.dyndns.org>
On Tue, 1 Jan 2008, Junio C Hamano wrote:
> @@ -816,9 +821,13 @@ struct ref_lock *lock_ref_sha1(const char *ref, const unsigned char *old_sha1)
>
> struct ref_lock *lock_any_ref_for_update(const char *ref, const unsigned char *old_sha1, int flags)
> {
> - if (check_ref_format(ref) == -1)
> + switch (check_ref_format(ref)) {
> + case CHECK_REF_FORMAT_ERROR:
> + case CHECK_REF_FORMAT_WILDCARD:
> return NULL;
> - return lock_ref_sha1_basic(ref, old_sha1, flags, NULL);
> + default:
> + return lock_ref_sha1_basic(ref, old_sha1, flags, NULL);
It might be wise to make "default" the return NULL case, and list the two
okay cases explicitly, so it doesn't need to be changed if
check_ref_format() someday gets additional "okay for some purposes"
values.
Aside from that, it looks good, except that builtin-send-pack.c and
fast-import.c should probably use the symbolic constants, too. (All other
callers only check whether the value is true or not).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Git and securing a repository
From: Daniel Barkalow @ 2008-01-02 16:18 UTC (permalink / raw)
To: Gonzalo Garramuño; +Cc: git
In-Reply-To: <477B39B5.5010107@advancedsl.com.ar>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2124 bytes --]
On Wed, 2 Jan 2008, Gonzalo Garramuño wrote:
> I've been using git for some time and love it. For open source projects
> there's clearly nothing currently better.
>
> However, I am now using git for proprietary elements, which in the future I
> may need or want to partially restrict access to. The idea being that at my
> company some (junior) developers should not be given access to some elements.
> That means either that some full git repository should be password protected
> or even portions of the same repository.
>
> Another desirable way to protect elements might be only giving clone/pull
> access to a repository (or portion of it) but not permissions to push in
> changes.
In order to understand the security model, you have to remember that git
is designed as a distributed system. Authorization is fundamentally not at
a project level, but rather at a repository level, and clones are all
different repositories. This makes portability of the mechanism less
important, because a particular set of authorization rules only applies to
a particular repository, which is going to be on some single system.
For that matter, git doesn't run with any special privileges in general;
if a user can affect the repository with git operations, that user can
affect the repository by hand, so git-specific rules aren't helpful.
(Although I suppose it would be theoretically useful to make git-shell,
the shell that only runs git programs, able to apply restrictions, since
it is used in a context where the user doesn't have any other access to
the filesystem.)
For read access restrictions, you want to use submodules (or entirely
separate projects); git is fundamentally unhappy running with less than
all of the project accessible, except for when a project references
another project with submodules. And, of course, if the code base is such
that users can do useful work without any access to some of the files,
those files must be optional and somewhat separate from the necessary
portions, and it makes sense to handle them separately anyway.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Optimize prefixcmp()
From: René Scharfe @ 2008-01-02 16:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marco Costalba, Git Mailing List, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0712292019450.14355@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin schrieb:
> Certain codepaths (notably "git log --pretty=format...") use
> prefixcmp() extensively, with very short prefixes. In those cases,
> calling strlen() is a wasteful operation, so avoid it.
> static inline int prefixcmp(const char *str, const char *prefix)
> {
> - return strncmp(str, prefix, strlen(prefix));
> + for (; ; str++, prefix++)
> + if (!*prefix)
> + return 0;
> + else if (*str != *prefix)
> + return (unsigned char)*prefix - (unsigned char)*str;
> }
>
> static inline int strtoul_ui(char const *s, int base, unsigned int *result)
prefixcmp() was already optimized before -- only for a different use
case. At a number of callsites the prefix is a string literal, which
allowed the compiler to perform the strlen() call at compile time.
The patch increases the text size considerably: the file "git" is
2,620,938 without and 2,640,450 with the patch in my build (there are
136 callsites in builtin*.c). The new version of prefixcmp() shouldn't
be inlined any more, as the benefit of doing so is gone.
Is there a portable way to let the preprocessor decide if
prefixcmp_literal() or prefixcmp_generic() is to be used, depending on
the prefix being a string literal or not?
René
^ permalink raw reply
* Re: Trouble generating info documentation
From: Miklos Vajna @ 2008-01-02 17:05 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86myrol7xf.fsf@lola.quinscape.zz>
[-- Attachment #1: Type: text/plain, Size: 295 bytes --]
On Wed, Jan 02, 2008 at 01:37:48PM +0100, David Kastrup <dak@gnu.org> wrote:
> in my version of docbook2x, the --to-stdout option is broken and
> requires the following patch:
according to the INSTALL file, you need docbook2X 0.8.3. the latest
stable 0.8.8 doesn't work here either.
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: About the .gitmodules file
From: Miklos Vajna @ 2008-01-02 17:13 UTC (permalink / raw)
To: Imran M Yousuf; +Cc: git
In-Reply-To: <7bfdc29a0801020239w6f4133d3pc6f1aa325b1067db@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 477 bytes --]
On Wed, Jan 02, 2008 at 04:39:24PM +0600, Imran M Yousuf <imyousuf@gmail.com> wrote:
> "git-submodule add". An entry for a submodule in that file looks like:
>
> [submodule "a"]
> path = a
> url = /home/imyousuf/projects/git-projs/smart-sip/submodules/a/.git
that means: the submodule is under /root_of_the_repo/a/ and the repo
should be cloned from $url (to a/) when one clones the parent repo and
runs git submodule init
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] git-svn: allow dcommit --no-rebase to commit multiple, dependent changes
From: Eric Wong @ 2008-01-02 18:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index c51f1e7..9b1113a 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -418,7 +418,7 @@ sub cmd_dcommit {
warn "Attempting to commit more than one change while ",
"--no-rebase is enabled.\n",
"If these changes depend on each other, re-running ",
- "without --no-rebase will be required."
+ "without --no-rebase may be required."
}
while (1) {
my $d = shift @$linear_refs or last;
@@ -453,6 +453,7 @@ sub cmd_dcommit {
$parents->{$d};
}
$_fetch_all ? $gs->fetch_all : $gs->fetch;
+ $last_rev = $cmt_rev;
next if $_no_rebase;
# we always want to rebase against the current HEAD,
@@ -512,7 +513,6 @@ sub cmd_dcommit {
$parents = \%p;
$linear_refs = \@l;
}
- $last_rev = $cmt_rev;
}
}
unlink $gs->{index};
--
1.5.4.rc2.7.g6277-dirty
^ permalink raw reply related
* [PATCH] git-svn: unlink index files that were globbed, too
From: Eric Wong @ 2008-01-02 18:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
commit 3157dd9e89a71e80673d0bc21b5c0630f3b1fe68 introduced
unlinking index files after fetching. However, this missed
indices for refs that were created by globbing branches and
tags. This will track all refs we ever touch during a fetch and
unlink them at exit time.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 9b1113a..2c97b05 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1283,8 +1283,11 @@ BEGIN {
}
}
-my %LOCKFILES;
-END { unlink keys %LOCKFILES if %LOCKFILES }
+my (%LOCKFILES, %INDEX_FILES);
+END {
+ unlink keys %LOCKFILES if %LOCKFILES;
+ unlink keys %INDEX_FILES if %INDEX_FILES;
+}
sub resolve_local_globs {
my ($url, $fetch, $glob_spec) = @_;
@@ -1376,7 +1379,6 @@ sub fetch_all {
($base, $head) = parse_revision_argument($base, $head);
$ra->gs_fetch_loop_common($base, $head, \@gs, \@globs);
- unlink $_->{index} foreach @gs;
}
sub read_all_remotes {
@@ -3945,6 +3947,7 @@ sub gs_fetch_loop_common {
if ($log_entry) {
$gs->do_git_commit($log_entry);
}
+ $INDEX_FILES{$gs->{index}} = 1;
}
foreach my $g (@$globs) {
my $k = "svn-remote.$g->{remote}." .
--
1.5.4.rc2.7.g6277-dirty
^ permalink raw reply related
* Re: [PATCH] Avoid a useless prefix lookup in strbuf_expand()
From: René Scharfe @ 2008-01-02 18:11 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List, Junio C Hamano, Johannes Schindelin
In-Reply-To: <e5bfff550712300546o167c460bl4628d87f8a4e14db@mail.gmail.com>
Marco Costalba schrieb:
> Currently the --prett=format prefix is looked up in a
> tight loop in strbuf_expand(), if found is passed as parameter
> to format_commit_item() that does another search using a
> switch statement to select the proper operation according to
> the kind of prefix.
>
> Because the switch statement is already able to discard unknown
> matches we don't need the prefix lookup before to call format_commit_item()
>
> This patch removes an useless loop in a very fasth path,
> used by, as example, by 'git log' with --pretty=format option
>
> Signed-off-by: Marco Costalba <mcostalba@gmail.com>
> ---
>
> This patch is somewhat experimental and is not intended to be merged as is.
>
> That's what is missing:
>
> - Matching of multi char prefixes is not 100% reliable, as example to match
> prefix "Cgreen" only the first 'C' and the third char 'e' is
> checked, this could
> lead to aliases in case of malformed prefixes, as example something like
> "Cxxexxxx" will match the same.
Well, you need to undo this optimization if you remove the loop that
makes sure that only valid placeholders are passed to the callback
function -- the result would be that you only move the prefixcmp() from
strbuf_expand() into the callbacks.
A better way to speed up strbuf_expand() may be to require the list of
placeholders to be sorted, their count to be passed on and then to
replace the sequential lookup with a binary search. --pretty=format
currently recognizes 29 placeholders, which might be a high enough
number for a more complicated search method to pay off.
> marco@localhost linux-2.6]$ time git log --topo-order --no-color
> --parents -z --log-size --boundary
> --pretty=format:"%m%HX%PX%n%an<%ae>%n%at%n%s%n%b" HEAD > /dev/null
In your special case it would be even faster to simply reorder the list
with decreasing number of occurrence. Of course it's hard to guess how
often a particular placeholder is used in the wild, but moving %n from
next to last to first place should be a safe bet.
René
^ permalink raw reply
* Re: [PATCH] Optimize prefixcmp()
From: Junio C Hamano @ 2008-01-02 18:52 UTC (permalink / raw)
To: René Scharfe; +Cc: Johannes Schindelin, Marco Costalba, Git Mailing List
In-Reply-To: <477BC2DA.6000105@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> prefixcmp() was already optimized before -- only for a different use
> case. At a number of callsites the prefix is a string literal, which
> allowed the compiler to perform the strlen() call at compile time.
>
> The patch increases the text size considerably: the file "git" is
> 2,620,938 without and 2,640,450 with the patch in my build (there are
> 136 callsites in builtin*.c). The new version of prefixcmp() shouldn't
> be inlined any more, as the benefit of doing so is gone.
Yuck, you are absolutely right. The late thread may have been
well intentioned but resulted in this regression. Sorry about
that.
I presume that all callers with constant prefix are outside
performance critical parts? Can we simply uninline the function
in that case?
^ permalink raw reply
* Re: Trouble generating info documentation
From: Junio C Hamano @ 2008-01-02 18:59 UTC (permalink / raw)
To: Miklos Vajna; +Cc: David Kastrup, git
In-Reply-To: <20080102170556.GD29972@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Wed, Jan 02, 2008 at 01:37:48PM +0100, David Kastrup <dak@gnu.org> wrote:
>> in my version of docbook2x, the --to-stdout option is broken and
>> requires the following patch:
>
> according to the INSTALL file, you need docbook2X 0.8.3. the latest
> stable 0.8.8 doesn't work here either.
Yuck. Also docbook2x seems to be available even much less
widely than other tools we use for documentation, which is
double yuck.
For now the "info" pages need to stay as a second class citizen,
it appears.
^ permalink raw reply
* Re: input validation in receive-pack
From: Junio C Hamano @ 2008-01-02 19:14 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Martin Koegler, git, Johannes Schindelin
In-Reply-To: <alpine.LNX.1.00.0801021043220.13593@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> It might be wise to make "default" the return NULL case, and list the two
> okay cases explicitly, so it doesn't need to be changed if
> check_ref_format() someday gets additional "okay for some purposes"
> values.
Sounds sensible.
> Aside from that, it looks good, except that builtin-send-pack.c and
> fast-import.c should probably use the symbolic constants, too. (All other
> callers only check whether the value is true or not).
Also sensible.
-- >8 --
Update callers of check_ref_format()
This updates send-pack and fast-import to use symbolic constants
for checking the return values from check_ref_format(), and also
futureproof the logic in lock_any_ref_for_update() to explicitly
name the case that is usually considered an error but is Ok for
this particular use.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-send-pack.c | 10 ++++++----
fast-import.c | 5 +++--
refs.c | 6 +++---
3 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 25ae1fe..8afb1d0 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -541,10 +541,12 @@ static void verify_remote_names(int nr_heads, const char **heads)
remote = remote ? (remote + 1) : heads[i];
switch (check_ref_format(remote)) {
case 0: /* ok */
- case -2: /* ok but a single level -- that is fine for
- * a match pattern.
- */
- case -3: /* ok but ends with a pattern-match character */
+ case CHECK_REF_FORMAT_ONELEVEL:
+ /* ok but a single level -- that is fine for
+ * a match pattern.
+ */
+ case CHECK_REF_FORMAT_WILDCARD:
+ /* ok but ends with a pattern-match character */
continue;
}
die("remote part of refspec is not a valid name in %s",
diff --git a/fast-import.c b/fast-import.c
index 4646c05..74597c9 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -642,8 +642,9 @@ static struct branch *new_branch(const char *name)
if (b)
die("Invalid attempt to create duplicate branch: %s", name);
switch (check_ref_format(name)) {
- case 0: break; /* its valid */
- case -2: break; /* valid, but too few '/', allow anyway */
+ case 0: break; /* its valid */
+ case CHECK_REF_FORMAT_ONELEVEL:
+ break; /* valid, but too few '/', allow anyway */
default:
die("Branch name doesn't conform to GIT standards: %s", name);
}
diff --git a/refs.c b/refs.c
index 7484a46..58f6d17 100644
--- a/refs.c
+++ b/refs.c
@@ -822,10 +822,10 @@ struct ref_lock *lock_ref_sha1(const char *ref, const unsigned char *old_sha1)
struct ref_lock *lock_any_ref_for_update(const char *ref, const unsigned char *old_sha1, int flags)
{
switch (check_ref_format(ref)) {
- case CHECK_REF_FORMAT_ERROR:
- case CHECK_REF_FORMAT_WILDCARD:
- return NULL;
default:
+ return NULL;
+ case 0:
+ case CHECK_REF_FORMAT_ONELEVEL:
return lock_ref_sha1_basic(ref, old_sha1, flags, NULL);
}
}
^ permalink raw reply related
* Stitching together private svn repo and public git repo
From: Gregory Jefferis @ 2008-01-02 19:25 UTC (permalink / raw)
To: git
Short Version:
Repo B is a completely linear repo that has been tracking public repo A for
some time. A number of manual merges were done to bring new A releases
into B but there are no connections between the two repos. (How) can I
stitch B to A to reflect this relationship? I want to retain B's history
and leave myself with an arrangement in which I can pull from A into B
periodically? Many thanks for your suggestions, Greg.
--
Long Version:
I have been tracking my modifications of a public project released as tar
balls with my own local svn repository. My svn repo was completely linear
and I always merged in changes manually each time a new tar ball was
released. This started to get painful.
Now I want to do better. I have set up a public git repository ("A") to
track the tar ball releases from the public project. I have converted my
svn repo with git-svn to a git repo ("B").
My goal is to end up with a (new?) git repo tracking the public repo (A) so
that I can pull in any changes and merge easily. Fine, but I also want to
keep the history that I have imported from my svn repository (B). So my
question is, can anyone suggest some pointers for how to stitch together A
and B?
Right now I have been trying to pull B into A to splice:
A $ git checkout v1.91
B $ git checkout v1.91-manualmerge
B $ git pull --no-commit -s ours ../A
This looks right when I run gitk, but if I repeat this for a second merge
point then the previous merge seems to disappear from history when I bring
up gitk.
I haven't found any docs/wiki info that has enlightened me yet. Any
suggestions, wisdom, links etc very much appreciated - I do want to try to
get this right now, so I don't have to rejig everything in the future. Best
wishes and many thanks,
Greg.
--
Gregory Jefferis, PhD and:
Research Fellow
Department of Zoology St John's College
Downing Street Cambridge
Cambridge, CB2 3EJ CB2 1TP
^ permalink raw reply
* Re: Git and securing a repository
From: Jan Hudec @ 2008-01-02 19:31 UTC (permalink / raw)
To: Gonzalo Garramuño; +Cc: Felipe Balbi, git
In-Reply-To: <477B6199.6070601@advancedsl.com.ar>
On Wed, Jan 02, 2008 at 07:04:09 -0300, Gonzalo Garramuño wrote:
> Felipe Balbi wrote:
>>
>> it's easy on the full repository case, create different groups and
>> share git repositories by groups, after that chmod o-rwx -R
>> /path/to/repository.git.
>>
>
> Thanks. I'll admit what you describe is somewhat discouraging, as what you
> are just describing is just managing user accounts or groups on the
> underlying OS. That does not extend well to placing code on the net and
> has a bunch of administrative headaches.
>
> I was really looking for a permission based system that was part of git
> itself (and thus more portable and easier to admin), and not the OS.
> Something akin to what perforce or even CVS can do.
You don't need to manage user accounts -- managing ssh public keys will do!
The git ssh access will always run one particular command (with path as
argument) to push and another particular command (again with path as
argument) to pull.
Thus you can prepare two scripts -- git-read-only will only run
$SSH_ORIGINAL_COMMAND if it is 'git-upload-pack <somearg>' and git-read-write
will also run it if it is 'git-receive-pack <somearg>'. The <somearg> is path
to the repository, so you can further limit on that. (Note: for recent git,
you need to recognize the 'git upload-pack' and 'git receive-pack' variants
too).
Now you can have each user create a ssh public key. You will put this key
into the .ssh/authorized_keys file on the server (therefore you only need
a single account there), with option command= specifying appropriate script
depending on what permissions the user should have. Than that user will be
able to push/pull (as set) via ssh using that public key and will not have
any other access to the server.
As a bonus, this way the users can't circumvent the pre-receive hooks
(perhaps you will allow each user to only push to a particular branch or
something) by manually changing the repository.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* [STG PATCH] refresh: add a --index option which takes the contents of the index as the new commit
From: Peter Oberndorfer @ 2008-01-02 19:39 UTC (permalink / raw)
To: Git Mailing List; +Cc: Karl Hasselström, Catalin Marinas
In-Reply-To: <200712302003.33478.kumbayo84@arcor.de>
just like git commit would do without the -a option
---
On Sonntag 30 Dezember 2007, Peter Oberndorfer wrote:
> Hi,
> I recently tried to split a stgit patch into 2 parts
> and it was not as easy as i would like it to be.
>
> How do i exclude a file from a patch(use version of file present in HEAD^)
> without modifying the working dir?
>
> with plain git i would use something like
> git reset HEAD^ files_i_do_not_want_in_first_patch
> git commit --amend
> git add files_i_do_not_want_in_first_patch
> git commit
>
> So my idea was to add a --use-index [1] option to stg refresh
> When it is passed stg refresh will use the current index for the contenst of the refreshed patch
> instead of looking at the working dir.
> This would solve my problem[2] and also make it possible to use git-gui for
> staging hunks.
>
OK, i got off my ass and hacked together the following patch
based on git://repo.or.cz/stgit/kha.git experimental
And i used it to create and update this commit a few times :-)
Additionally it passes the (minimal) test i added.
But since i am not a stgit expert it is highly recommend that somebody else carefully
looks at the patch before going wild on real data.
> Do you think this would be a useful/good idea?
> Or do we want a separate command for removing files from a patch anyway?
The question is still open if this is useful for somebody else.
Greetings Peter
PS: i hope i put the right people on CC
stgit/commands/refresh.py | 25 ++++++++++++++++---
stgit/stack.py | 6 ++++
t/t2700-refresh.sh | 57 ++++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 83 insertions(+), 5 deletions(-)
diff --git a/stgit/commands/refresh.py b/stgit/commands/refresh.py
index 6e8ed0c..0420b98 100644
--- a/stgit/commands/refresh.py
+++ b/stgit/commands/refresh.py
@@ -45,6 +45,9 @@ options = [make_option('-f', '--force',
make_option('--update',
help = 'only update the current patch files',
action = 'store_true'),
+ make_option('--index',
+ help = 'use the current contents of the index instead of looking at the working directory',
+ action = 'store_true'),
make_option('--undo',
help = 'revert the commit generated by the last refresh',
action = 'store_true'),
@@ -76,6 +79,14 @@ def func(parser, options, args):
if not patch:
raise CmdException, 'No patches applied'
+ if options.index:
+ if args or options.update:
+ raise CmdException, \
+ 'Only full refresh is available with the --index option'
+ if options.patch:
+ raise CmdException, \
+ '--patch is not (yet) compatible with --index option'
+
if not options.force:
check_head_top_equal(crt_series)
@@ -85,9 +96,10 @@ def func(parser, options, args):
out.done()
return
- files = [path for (stat, path) in git.tree_status(files = args, verbose = True)]
+ if not options.index:
+ files = [path for (stat, path) in git.tree_status(files = args, verbose = True)]
- if files or not crt_series.head_top_equal():
+ if options.index or files or not crt_series.head_top_equal():
if options.patch:
applied = crt_series.get_applied()
between = applied[:applied.index(patch):-1]
@@ -105,8 +117,13 @@ def func(parser, options, args):
if autoresolved == 'yes':
resolved_all()
- crt_series.refresh_patch(files = files,
- backup = True, notes = options.annotate)
+
+ if options.index:
+ crt_series.refresh_patch(use_index = True,
+ backup = True, notes = options.annotate)
+ else:
+ crt_series.refresh_patch(files = files,
+ backup = True, notes = options.annotate)
if crt_series.empty_patch(patch):
out.done('empty patch')
diff --git a/stgit/stack.py b/stgit/stack.py
index 4203931..7d14261 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -668,6 +668,7 @@ class Series(PatchSet):
config.remove_section('branch.%s.stgit' % self.get_name())
def refresh_patch(self, files = None, message = None, edit = False,
+ use_index = False,
empty = False,
show_patch = False,
cache_update = True,
@@ -717,6 +718,11 @@ class Series(PatchSet):
else:
tree_id = None
+ if use_index:
+ tree_id = None
+ files = None
+ cache_update = False
+
commit_id = git.commit(files = files,
message = descr, parents = [bottom],
cache_update = cache_update,
diff --git a/t/t2700-refresh.sh b/t/t2700-refresh.sh
index 2e7901c..9eae85d 100755
--- a/t/t2700-refresh.sh
+++ b/t/t2700-refresh.sh
@@ -6,8 +6,10 @@ test_description='Run "stg refresh"'
test_expect_success 'Initialize StGit stack' '
stg init &&
- echo expected.txt >> .git/info/exclude &&
+ echo expected*.txt >> .git/info/exclude &&
echo patches.txt >> .git/info/exclude &&
+ echo show.txt >> .git/info/exclude &&
+ echo diff.txt >> .git/info/exclude &&
stg new p0 -m "base" &&
for i in 1 2 3; do
echo base >> foo$i.txt &&
@@ -62,4 +64,57 @@ test_expect_success 'Refresh bottom patch' '
diff -u expected.txt patches.txt
'
+cat > expected.txt <<EOF
+p0
+p1
+p4
+EOF
+cat > expected2.txt <<EOF
+diff --git a/foo1.txt b/foo1.txt
+index 728535d..6f34984 100644
+--- a/foo1.txt
++++ b/foo1.txt
+@@ -1,3 +1,4 @@
+ base
+ foo 1
+ bar 1
++baz 1
+EOF
+cat > expected3.txt <<EOF
+diff --git a/foo1.txt b/foo1.txt
+index 6f34984..a80eb63 100644
+--- a/foo1.txt
++++ b/foo1.txt
+@@ -2,3 +2,4 @@ base
+ foo 1
+ bar 1
+ baz 1
++blah 1
+diff --git a/foo2.txt b/foo2.txt
+index 415c9f5..43168f2 100644
+--- a/foo2.txt
++++ b/foo2.txt
+@@ -1,3 +1,4 @@
+ base
+ foo 2
+ bar 2
++baz 2
+EOF
+test_expect_success 'Refresh --index' '
+ stg status &&
+ stg new p4 -m "refresh_index" &&
+ echo baz 1 >> foo1.txt &&
+ git add foo1.txt &&
+ echo blah 1 >> foo1.txt &&
+ echo baz 2 >> foo2.txt &&
+ stg refresh --index &&
+ stg patches foo1.txt > patches.txt &&
+ git diff HEAD^..HEAD > show.txt &&
+ stg diff > diff.txt &&
+ diff -u expected.txt patches.txt &&
+ diff -u expected2.txt show.txt &&
+ diff -u expected3.txt diff.txt &&
+ stg new p5 -m "cleanup again" &&
+ stg refresh
+'
test_done
--
1.5.4.rc2
^ permalink raw reply related
* Re: Git and securing a repository
From: Gregory Jefferis @ 2008-01-02 19:41 UTC (permalink / raw)
To: Jan Hudec; +Cc: git
In-Reply-To: <20080102193114.GA4608@efreet.light.src>
On 2/1/08 19:31, "Jan Hudec" <bulb@ucw.cz> wrote:
>
> You don't need to manage user accounts -- managing ssh public keys will do!
Has anyone used gitosis?
http://eagain.net/gitweb/?p=gitosis.git
http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-w
ay
It seems to make setting up this kind of approach easier.
Best,
Greg.
--
Gregory Jefferis, PhD and:
Research Fellow
Department of Zoology St John's College
Downing Street Cambridge
Cambridge, CB2 3EJ CB2 1TP
^ permalink raw reply
* Retroactively change email signature?
From: Stephen Sinclair @ 2008-01-02 20:37 UTC (permalink / raw)
To: git
Hi,
I imagine that changing old commits is considered one of the great
evils of source control, but I have a small problem:
I have a habit of testing my code on several different computers and
operating systems. Sometimes when setting up a new computer for
testing (and thus, for development, since testing always results in a
few commits), I have forgotten to use git-config to configure my name
and email address.
Since git doesn't warn when I've forgotten to do this, my git-log is
now sprinkled with various email addresses, some which are just my
username@hostname. This is completely useless to people who might
view my public repository.
Is it possible to retroactively change the author and email of several
commits? Perhaps some sort of search-and-replace for the commit
metadata? Even for older commits, I'd like to change the email
addresses to my current address.
If it's not possible it's not the end of the world, but I thought it
wouldn't hurt to ask.
thanks,
Steve
^ permalink raw reply
* Re: Retroactively change email signature?
From: Jakub Narebski @ 2008-01-02 21:17 UTC (permalink / raw)
To: Stephen Sinclair; +Cc: git
In-Reply-To: <9b3e2dc20801021237v4d5d236fn3d2643502b9bb78f@mail.gmail.com>
"Stephen Sinclair" <radarsat1@gmail.com> writes:
> I imagine that changing old commits is considered one of the great
> evils of source control, but I have a small problem:
> I have a habit of testing my code on several different computers and
> operating systems. Sometimes when setting up a new computer for
> testing (and thus, for development, since testing always results in a
> few commits), I have forgotten to use git-config to configure my name
> and email address.
>
> Since git doesn't warn when I've forgotten to do this, my git-log is
> now sprinkled with various email addresses, some which are just my
> username@hostname. This is completely useless to people who might
> view my public repository.
This most certainly should get addressed IMHO.
> Is it possible to retroactively change the author and email of several
> commits? Perhaps some sort of search-and-replace for the commit
> metadata? Even for older commits, I'd like to change the email
> addresses to my current address.
>
> If it's not possible it's not the end of the world, but I thought it
> wouldn't hurt to ask.
You can use git-filter-branch(1), but please remember that it is
practically rewriting whole repository, so you should do this _before_
you publish any changes.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Retroactively change email signature?
From: Linus Torvalds @ 2008-01-02 21:24 UTC (permalink / raw)
To: Stephen Sinclair; +Cc: git
In-Reply-To: <9b3e2dc20801021237v4d5d236fn3d2643502b9bb78f@mail.gmail.com>
On Wed, 2 Jan 2008, Stephen Sinclair wrote:
>
> Is it possible to retroactively change the author and email of several
> commits? Perhaps some sort of search-and-replace for the commit
> metadata? Even for older commits, I'd like to change the email
> addresses to my current address.
See
man git-filter-branch
and the "--env-filter" flag (and "--msg-filter" if you also want to change
things like Sign-off's etc in the message text itself)
BUT! See also the big bold-face warning: using "filter-branch" will not
change old commits, it will create a series of *new* commits that bear a
striking resemblance to the old ones, but are not the same. So you'll have
a totally new history.
That matters for things like
- if you've already publicised the old history, you need to tell people
that they should fetch things anew
- if you refer to the commit SHA1's elsewhere (like in commit messages
that revert previous commits), those SHA1's are still "valid", but they
refer to the *old* history, not the new history you created.
(I don't think git-filter-branch even exposes any easy way to remap the
"revert commit xyz" messages in the message format. It's not technically
hard to use a --msg-filter for it, but it seems a big bother).
Linus
^ permalink raw reply
* Re: Stitching together private svn repo and public git repo
From: Charles Bailey @ 2008-01-02 21:40 UTC (permalink / raw)
To: Gregory Jefferis; +Cc: git
In-Reply-To: <C3A195B5.10839%jefferis@gmail.com>
On Wed, Jan 02, 2008 at 07:25:41PM +0000, Gregory Jefferis wrote:
>
> Right now I have been trying to pull B into A to splice:
>
> A $ git checkout v1.91
> B $ git checkout v1.91-manualmerge
> B $ git pull --no-commit -s ours ../A
So you have something like this in B:
Av1* -- Av1_b -- Av1_c -- Av1_d -- Av2_d* -- Av2_e -- Av3_e*
Where the * are manual merges of the offical Avn releases...
And you want this:
Av1 -- -- -- Av2 -- -- Av3
\ \ \
Av1_b -- Av1_c -- Av1_d -- Av2_d -- Av2_e -- Av3_e ???
This is a "rewrite history" job as parent lists are part of each
commit. (See Linus' big bold-face warning about history re-writes.)
First of all I would add a remote for the 'A' repository so that those
commits are available in the 'B' repository.
Something like:
git remote add repoA /path/to/A
git fetch repoA
You could then do this with a 'git filter-branch --parent-filter' to
rewrite the parents of the merge commits. As far as I can see, you
would need to call filter-branch once per merge to rewrite everything
from the merge commit forwards. At this point all later commits would
have different ids, so attempting to rewrite subsequent parent-ids in
the same filter-branch invocation is probably futile.
It might be possible to use an intelligent script in a single
--commit-filter invocation of filter-branch, but the script of the
actual filter would have to be a bit (a lot!) more sophisticated,
remember the ids of the new commits as it created them with 'git
commit-tree' and merging in the repoA parents at the right points.
Leaving that aside and concentrating on the multiple filter-branch
invocation option... for example, the first parent-filter script could
be:
sed -e 's/^$/-p <commit id of Av1>/'
( This is if you want your exisiting tree to branch from Av1 in the
original repo. If you wanted to replace your tree root with a root at
Av1, because your current root is just a copy of Av1 then you want:
sed -e 's/<commit id of repoB's Av1 copy>/<commit id of Av1 in A>/'
)
Then, for whatever the Av2_d commit's new id is, you could do a
parent-filter of:
sed -e 's/\(<new commit id of Av1_d>\)/\1 -p <commit id of Av2>/'
This causes the Av2_d commit to be rewritten, maintaining its original
parent and adding another parent which comes from repoA. It then
rewrites all the descendent commits of Av2_d to take account of this
new commit id and all the subsequent new commit ids.
Now you can do similar for the next merge commit:
sed -e 's/\(<new commit id of Av2_e>\)/\1 -p <commit id of Av3>/'
As noted, you end up with completely new commit objects with a
completely new history, so you will screw everyone who is
pulling/cloning from you.
Charles.
^ permalink raw reply
* [PATCH] receive-pack: reject invalid refnames
From: Martin Koegler @ 2008-01-02 21:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Koegler
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
---
receive-pack.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/receive-pack.c b/receive-pack.c
index d0a563d..a038a40 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -165,7 +165,9 @@ static const char *update(struct command *cmd)
unsigned char *new_sha1 = cmd->new_sha1;
struct ref_lock *lock;
- if (!prefixcmp(name, "refs/") && check_ref_format(name + 5)) {
+ /* only HEAD and refs/... are allowed */
+ if (strcmp(name, "HEAD") &&
+ (prefixcmp(name, "refs/") || check_ref_format(name + 5))) {
error("refusing to create funny ref '%s' remotely", name);
return "funny refname";
}
@@ -177,7 +179,8 @@ static const char *update(struct command *cmd)
}
if (deny_non_fast_forwards && !is_null_sha1(new_sha1) &&
!is_null_sha1(old_sha1) &&
- !prefixcmp(name, "refs/heads/")) {
+ (!prefixcmp(name, "refs/heads/") ||
+ !strcmp(name, "HEAD"))) {
struct object *old_object, *new_object;
struct commit *old_commit, *new_commit;
struct commit_list *bases, *ent;
--
1.4.4.4
^ permalink raw reply related
* Re: Retroactively change email signature?
From: Stephen Sinclair @ 2008-01-02 22:06 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.1.00.0801021316080.3010@woody.linux-foundation.org>
Thanks, I was able to use git-filter-branch to accomplish what I wanted.
I should have mentioned in the original email that it is not a widely
distributed repo, so I'm not too worried about breaking things at this
point. I guess for a larger project it might be a problem, so I
probably just wouldn't do it.
> BUT! See also the big bold-face warning: using "filter-branch" will not
> change old commits, it will create a series of *new* commits that bear a
> striking resemblance to the old ones, but are not the same. So you'll have
> a totally new history.
Got it, thanks.
I'll just have to remember to git-config properly next time I do this.
One thing that's a bit odd for me is that I use a different email
address for this particular project..
Conveniently I'm able to use git-config to set an email address
locally for this repo, however I have to remember to do this every
time I clone it somewhere. Not a problem, necessarily, but perhaps
just a matter of training myself.
For example, I have a clone of this repo on a Linux, Windows, and OS X
machine, and also another clone for each on my laptop.. git is
actually turning out to be great for doing all this swapping between
machines, but it does take a little training to remember to set the
configuration, since there's no central repo to ask me for my username
and password before I can commit.
cheers,
Steve
^ 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