[PATCH] git stash: Avoid data loss when saving a stash
I have been recently again bitten by git stash versus an uncommitted
file-to-directory change that happily threw away few gigabytes of my
data. This has been recently discussed in the past, e.g.
http://thread.gmane.org/gmane.comp.version-control.git/202332/
and I implemented Junio's suggestion in this patch - if ls-files --killed
produced any output, the stash save is stopped and the user is required
to pass --force to really have the data removed.
A test case is included. I think that the (currently failing) tests
'stash file to directory' and 'stash directory to file' are related to
this, but I consider their expectation to be bogus - I would personally
be surprised by `git stash` suddenly importing the complete
never-meant-to-be-tracked contents of my directory to Git during a stash
save, and I think the approach of aborting in this situation is more
reasonable.
Other parts of Git also behave in a troublesome way in case of tracked
file being replaced by an untracked directory - I wouldn't expect `git
reset --hard` alone to remove the directory (i.e. touch untracked files)
either. However, this matter is much more complicated since `git reset
--hard` is assumed to "never fail in ordinary circumstances" (see e.g.
git-stash code ;-) and I'm unable to devote sufficient effort to seeing
such a change through.
Signed-off-by: Petr Baudis
---
Please Cc me, I'm currently not subscribed on the list.
Documentation/git-stash.txt | 12 ++--
git-stash.sh| 10 ++
t/t3903-stash.sh| 16
3 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index db7e803..52d4def 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -14,7 +14,8 @@ SYNOPSIS
'git stash' ( pop | apply ) [--index] [-q|--quiet] []
'git stash' branch []
'git stash' [save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
-[-u|--include-untracked] [-a|--all] []]
+[-u|--include-untracked] [-a|--all] [-f|--force]
+[]]
'git stash' clear
'git stash' create []
'git stash' store [-m|--message ] [-q|--quiet]
@@ -44,7 +45,7 @@ is also possible).
OPTIONS
---
-save [-p|--patch] [--[no-]keep-index] [-u|--include-untracked] [-a|--all]
[-q|--quiet] []::
+save [-p|--patch] [--[no-]keep-index] [-u|--include-untracked] [-a|--all]
[-q|--quiet] [-f|--force] []::
Save your local modifications to a new 'stash', and run `git reset
--hard` to revert them. The part is optional and gives
@@ -71,6 +72,13 @@ linkgit:git-add[1] to learn how to operate the `--patch`
mode.
+
The `--patch` option implies `--keep-index`. You can use
`--no-keep-index` to override this.
++
+In some cases, saving a stash could mean irretrievably removing some
+data - if a directory with untracked files replaces a tracked file of
+the same name, the new untracked files are not saved (except in case
+of `--include-untracked`) but the original tracked file shall be restored.
+Normally, stash save will abort; `--force` will make it remove the
+untracked files.
list []::
diff --git a/git-stash.sh b/git-stash.sh
index 1e541a2..3cb9b05 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -195,6 +195,7 @@ save_stash () {
keep_index=
patch_mode=
untracked=
+ force=
while test $# != 0
do
case "$1" in
@@ -215,6 +216,9 @@ save_stash () {
-u|--include-untracked)
untracked=untracked
;;
+ -f|--force)
+ force=t
+ ;;
-a|--all)
untracked=all
;;
@@ -258,6 +262,12 @@ save_stash () {
say "$(gettext "No local changes to save")"
exit 0
fi
+ if test -z "$untracked$force" -a -n "$(git ls-files --killed | head -n
1)"; then
+ say "$(gettext "The following untracked files would NOT be
saved but need to be removed by stash save:")"
+ test -n "$GIT_QUIET" || git ls-files --killed | sed 's/^/\t/'
+ say "$(gettext "Abording. Consider using either the --force or
--include-untracked switches.")" >&2
+ exit 1
+ fi
test -f "$GIT_DIR/logs/$ref_stash" ||
clear_stash || die "$(gettext "Cannot initialize stash")"
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index debda7a..4ac4ebe 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -673,4 +673,19 @@ test_expect_success 'store updates stash ref and reflog' '
grep quux bazzy
'
Re: [PATCH] git stash: Avoid data loss when saving a stash
Hi! On Fri, Jun 28, 2013 at 11:39:16AM -0700, Junio C Hamano wrote: > Thanks. I'll queue it with a pair of fix-up commits on top, so that > they can later be squashed in. > > The result of squashing the fix-ups would look like this. Thanks! I agree with all of your changes. > -- >8 -- > From: Petr Baudis > Date: Fri, 28 Jun 2013 17:05:32 +0200 > Subject: [PATCH] git stash: avoid data loss when "git stash save" kills a > directory Hmm, it's a pity that the note that `git reset --hard` itself should perhaps also abort in that case got lost. I don't insist on mentioning it in the commit message, though. On Fri, Jun 28, 2013 at 02:30:15PM -0700, Junio C Hamano wrote: > -- >8 -- > Subject: treat_directory(): do not declare submodules in index to be untracked Oh, you are truly awesome! I admit that properly reviewing this patch is a little out of my depth right now as I'm not familiar with this infrastructure. I'd just like to note... > case index_gitdir: > if (dir->flags & DIR_SHOW_OTHER_DIRECTORIES) > return path_none; > - return path_untracked; > + return path_none; ...that the if-test can be removed now as both branches are the same. Petr "Pasky" Baudis -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git stash: Avoid data loss when saving a stash
Hi! (tl;dr - I disagree but this issue is perhaps not so important in practice) On Sun, Jun 30, 2013 at 12:14:26PM -0700, Junio C Hamano wrote: > I do not agree with your `git reset --hard` at all. With the > command, the user demands "no matter what, I want get rid of any > funny state in my working tree so that I can start my work from that > specified commit (default to HEAD)". Yeah, but this normally concerns only tracked files; `git reset --hard` does not imply `git clean`. I'm worried when a tool normally behaves in a way that follows an apparent rule but its behavior is defined in such a way that in a corner case this rule is violated (but it's ok since it's a - non-obvious - implication of the specification). > Imagine that this is you did to arrive that "funny state": > > $ git rm foo ;# foo used to be tracked and in HEAD > $ cp /somewhere/else/foo foo > $ cp /somewhere/else/bar bar ;# bar is not in HEAD > $ cp /somewhere/else/bar baz ;# baz is in HEAD > ... do various other things ... > > and then "git reset --hard". At that point, "foo" and "bar" are not > tracked and completely unrelated to the project. "baz" is tracked > and have unrelated contents from that of "HEAD". > > In order to satisfy your desire to go back to the state of HEAD with > minimal collateral amage, we need to get rid of the updated "foo" > and "baz" and replace them with those from HEAD. We do not have to > touch "bar" so we leave it as-is. Perhaps we misundertood each other here. I certainly don't care to keep local changes as a whole - a command behaving like that wouldn't be very useful for me; for me, the crucial distinction is between tracked and untracked files. Therefore, from my viewpoint it's fine to overwrite baz, but not to overwrite foo. > And the "killed" case is just like "foo" and "baz". If the state > you want to go back to with "--hard" has a directory (a file) where > your working tree's funny state has a file (a directory), the local > cruft needs to go away to satisify your request. > > I do not mind if you are proposing a different and new kind of reset > that fails if it has to overwrite any local changes (be it tracked > or untracked), but that is not "reset --hard". It is something else. Hmm, I suppose the assumption I would prefer is that "the only command that will destroy (currently) untracked data without warning is `git clean`"; even though (unlike in case of git stash) the current reset --hard behavior wouldn't surprise me, I suspect it can be a bad surprise for many Git users when they hit this situation; but since I didn't notice any actual complaint yet, so I don't care enough to press this further for now anyway. :-) -- Petr "Pasky" Baudis For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git stash deletes/drops changes of
Hi! On Fri, May 24, 2013 at 12:56:50AM +0200, Thomas Rast wrote: > > It is not --ignore-changes bit, and has never been. Indeed, it has been my lack of imagination regarding what can go wrong. I am fine with the changes not being shown in `git diff` and even not so worried about them being overwritten by a merge/checkout (touching that file for other purposes), but `git stash` dropping the changes is rather vicious. ;-) An emergency fix would be to add a warning to the documentation that under various circumstances, your changes may get overwritten and keep a backup copy. It's a bit silly, I'm not sure how long it may take to flesh out a proper solution; if we just stop recommending anything (or recommend something unhelpful like "you don't want that"), people will just refer to the old advice and I think it's better to warn them. > > What are the workflows that are helped if we had such a bit? If we > > need to support them, I think you need a real --ignore-changes bit, > > not an abuse of --assume-unchanged. > > I gather -- from #git -- that it's mostly used for config files, which > have an annoying habit of being different from the repository. > > Which is wrong, really. But we still claim that --assume-unchanged is > a solution to it in git-update-index(1). The main workflow for me is when you don't get to pick the workflow. Most recently, I found myself tackling this scenario: (i) https://github.com/huceke/omxplayer carries file Makefile.include (ii) I'm paid to make some modifications to the omxplayer software on short notice. (iii) Makefile.include hardcodes some crosscompiling tool paths and other things (like CFLAGS) that are different in my setup. For the first few commits, I have avoided using -a, then I went ahead and marked Makefile.include with --assume-unchanged. It felt like something dangerous, so I also made a backup of the file for good measure; that turned out to be a good idea after the first `git stash` issued. (Unfortunately, I forgot about the problem before I would have time to think about fixing that.) Yeah, omxplayer's setup is not ideal. But in this scenario, I'm not really in the position to easily start poking into other people's toolchain setup, I'd like git just to help me get my work done and move on and ideally keep my pull requests clean of unrelated commits. Just to clear up on what the best practice is, I'd imagine the setup to be something like: (a) Makefile contains inclusion of Makefile.include. (b) There is a file like Makefile.include.template containing a template to be copied over and filled by the user. (c) Makefile contains code that makes sure all variables that are supposed to be set are set and obsolete variables are not, since there is no mechanism to cause e.g. a merge conflict on change of Makefile.include.template. Is there a better way to solve this? There are a couple of things to notice here: (i) The solution is highly specific for the particular file format and usage, universal recommendations are difficult especially if we are to cover (c). (ii) The solution is certainly not the simplest one to occur to the original author, who will probably initially just commit Makefile.include with the values suitable for them. (iii) A corrolary to (ii), the person who will find tackling this problem first will probably be a newcoming developer to the project who is likely not to be familiar with it and its toolchain / config mechanisms, and this will be a huge hassle. Therefore the demand for Git to just solve their problem on its level. Of course Git would be simpler and more elegant if it didn't have to do this and cover all the annoying corner cases. But is this simplification worth the extra workflow hassle for its users? -- Petr "Pasky" Baudis For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git stash deletes/drops changes of
On Fri, May 24, 2013 at 09:22:53AM +0100, John Keeping wrote: > On Fri, May 24, 2013 at 01:57:12AM +0200, Petr Baudis wrote: > > Just to clear up on what the best practice is, I'd imagine the setup > > to be something like: > > > > (a) Makefile contains inclusion of Makefile.include. > > > > (b) There is a file like Makefile.include.template containing > > a template to be copied over and filled by the user. > > > > (c) Makefile contains code that makes sure all variables that > > are supposed to be set are set and obsolete variables are not, > > since there is no mechanism to cause e.g. a merge conflict > > on change of Makefile.include.template. > > > > Is there a better way to solve this? > > I think the best practice would be what Git itself does ;-) > > The Makefile sets default values for all parameters, some of which are > inferred based on the system. It then includes config.mak, which allows > the user to override any of these values. So that's pretty similar to what I described, modulo the filenames. I'd say it's more friendly if you don't need to tweak any of the defaults in the common case, but less friendly if you always need to tweak something/everything (you really want a template file then and not covering (c) is a problem). -- Petr "Pasky" Baudis For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git stash deletes/drops changes of
On Fri, May 24, 2013 at 11:06:12AM +0100, John Keeping wrote: > I don't see anything wrong with having a template file documenting the > parameters, but I think it's important that there are sensible defaults > in place when the user's configuration file does not specify a value for > a parameter. It wasn't clear to me from your definition that there were > defaults to be overridden by the user's configuration file, as opposed > to forcing the user to define certain values and causing an error if > those are not defined. That's the case in plenty of situations - when specifying usernames and passwords and server hostnames, paths to cross-compiling environments that pretty much everyone has at a different place, and so on. -- Petr "Pasky" Baudis For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git stash deletes/drops changes of
On Fri, May 24, 2013 at 11:40:18AM +0100, John Keeping wrote: > So that it continues to Just Work for people using buildroot but you can > create Makefile.config to override those defaults. Indeed, that doesn't cover some corner cases of (c), but that's not a big deal in practice I guess. My point still stands - this is extra hassle, done just for the sake of the tool; I think the tool should not get in the way. Moreover, it's not the default solution for your typical original author and therefore you will still often find yourself in a situation where you have to deal with a setup that's broken already. -- Petr "Pasky" Baudis For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] update pasky's email address
Hi! On Thu, Apr 04, 2013 at 01:50:42AM +, Eric Wong wrote: > Mail to pa...@suse.cz is bouncing. Oh, I totally forgot to take care of this. Thanks a lot for fixing it! > Signed-off-by: Eric Wong In general, Acked-by: Petr Baudis On Thu, Apr 04, 2013 at 07:21:23AM +, Eric Wong wrote: > Junio C Hamano wrote: > > Especially, a change like this: > > > > > index db6eb50..e162ec9 100644 > > > --- a/gitweb/static/js/blame_incremental.js > > > +++ b/gitweb/static/js/blame_incremental.js > > > @@ -1,5 +1,5 @@ > > > // Copyright (C) 2007, Fredrik Kuivinen > > > -// 2007, Petr Baudis > > > +// 2007, Petr Baudis > > > > makes me feel very uneasy and feels outright wrong; unless the > > change by Petr in year 2007 was associated with the ucw.cz address, > > not his then-current employer, that is. > > I understand your concern. Perhaps keeping the old address with > a pointer to the current address? > > 2007, Petr Baudis (currently pa...@ucw.cz) > > I'll wait for Petr's thoughts. Frankly, I have no idea how to handle this well; is this the first time such a change has to happen in Git? Your proposed form seems formally correct but feels a bit cumbersome to me. :-) I think that if SUSE would like the email address to stay in the original form, the best way to confirm their preference would be to keep it actually functional. Maybe Vojtech will have some thoughts on whether that would be possibe or whether we should keep the address inact. Kind regards, -- Petr "Pasky" Baudis For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] perl: redirect stderr to /dev/null instead of closing
Hi!
On Thu, Apr 04, 2013 at 10:41:41PM +0200, Thomas Rast wrote:
> As pointed out by Eric Wong (thanks), the initial close needs to go:
> die() would again write nowhere if we close STDERR beforehand.
>
> > Perhaps we should also do the following:
> >
> > --- a/perl/Git.pm
> > +++ b/perl/Git.pm
> > @@ -1489,9 +1489,6 @@ sub _command_common_pipe {
> > if (not defined $pid) {
> > throw Error::Simple("open failed: $!");
> > } elsif ($pid == 0) {
> > - if (defined $opts{STDERR}) {
> > - close STDERR;
> > - }
> > if ($opts{STDERR}) {
> > open (STDERR, '>&', $opts{STDERR})
> > or die "dup failed: $!";
>
> Indeed. Thanks for pointing that out.
I'm sorry, I don't follow. Doesn't this just break the STDERR option
altogether as we will try to dup2() over an already open file
descriptor? We do need to close STDERR if we are going to reopen it,
I think.
Kind regards,
Petr "Pasky" Baudis
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] perl: redirect stderr to /dev/null instead of closing
On Fri, Apr 05, 2013 at 11:57:19AM -0700, Junio C Hamano wrote:
> Petr Baudis writes:
> >> > -if (defined $opts{STDERR}) {
> >> > -close STDERR;
> >> > -}
> >> > if ($opts{STDERR}) {
> >> > open (STDERR, '>&', $opts{STDERR})
> >
> > I'm sorry, I don't follow. Doesn't this just break the STDERR option
> > altogether as we will try to dup2() over an already open file
> > descriptor? We do need to close STDERR if we are going to reopen it,
> > I think.
>
> When $opts{STDERR} is 2, what the three lines the proposed patch
> removes did is actively wrong, because you dup2 the fd you just
> closed.
Indeed, though $opts{STDERR} == 2 is something weird to do, it is a case
to consider.
> When $opts{STDERR} is 1, it seems to do the right thing with or
> without the "close STDERR" in front. Isn't this because the usual
> "open($fd, <<>>) closes $fd as necessary" applies to this
> case as well?
I never actually tried that and was always happy to go with perldoc
maxim
To (re)open "STDOUT" or "STDERR" as an in-memory file, close it first:
close STDOUT;
open(STDOUT, ">", \$variable)
or die "Can't open STDOUT: $!";
but my assumption that this generalizes to other kinds of open was
apparently invalid; an example further down the page proves me wrong
completely, moreover.
The thing is, I was confused about dup2() all along as my old UNIX
masters taught me that I must close() the original descriptor first
and since that's what's commonly done anyway, I never thought to
double-check. Now I did and I learned something new, thanks!
I guess Acked-by: Petr Baudis then. :-)
--
Petr "Pasky" Baudis
For every complex problem there is an answer that is clear,
simple, and wrong. -- H. L. Mencken
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] perl: redirect stderr to /dev/null instead of closing
On Sat, Apr 06, 2013 at 10:07:40AM +0200, Thomas Rast wrote: > The manpage for dup2 does, however, say > >If newfd was open, any errors that would have been reported at >close(2) time are lost. A careful programmer will not use dup2() or >dup3() without closing newfd first. > > which is probably what you were referring to. Yes, that's probably one reason why I had this stuck in my mind (though, how often does anyone bother to detect errors on close()...? ;-). Funnily enough, POSIX.2008 specifies that if closing newfd would fail, dup2() reports EIO and newfd is not closed, eliminating this problem. The manpage does not cover this; well, that's fair enough as Linux just doesn't care and never does that if I didn't miss anything in the code. -- Petr "Pasky who might even send a patch, but the matter is oh so obscure" Baudis -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cogito Mac OS X compatibility
Dear diary, on Sat, Jul 09, 2005 at 01:34:55AM CEST, I got a letter where Bryan Larsen <[EMAIL PROTECTED]> told me that... > On Mac OS X > > $ cg-clone http://www.kernel.org/pub/scm/cogito/cogito.git > defaulting to local storage area > 19:11:10 > URL:http://www.kernel.org/pub/scm/cogito/cogito.git/refs/heads/master > [41/41] -> "refs/heads/origin" [1] > /Users/blarsen/bin/cg-pull: line 82: 0 + : syntax error: operand > expected (error token is " ") > cg-pull: objects pull failed > cg-init: pull failed That's strange. I assume you don't have the stat utility, but that shouldn't matter - Cogito has own stat stub to use in those cases. Could you please put some debugging stuff into stat() in cg-Xlib to see what's going on? (Beware, cg-pull calls it with 2>/dev/null.) Thanks. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ be careful, some twit might quote you out of context.. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Cogito-0.12
Dear diary, on Sun, Jul 10, 2005 at 10:09:14AM CEST, I got a letter where Russell King <[EMAIL PROTECTED]> told me that... > On Sat, Jul 09, 2005 at 10:58:18PM +0100, Russell King wrote: > > $ mv .git/objects/pack/* .git/ > > $ for i in .git/*.pack; do git-unpack-objects < $i; done > > Unpacking 55435 objects > > fatal: inflate returned -3 > > This morning's cg-update gave these new errors: > > receiving file list ... done > > wrote 86 bytes read 192 bytes 556.00 bytes/sec > total size is 410 speedup is 1.47 > Missing object of tag v2.6.11... different source (obsolete tag?) > Missing object of tag v2.6.11-tree... different source (obsolete tag?) > Missing object of tag v2.6.12... different source (obsolete tag?) > Missing object of tag v2.6.12-rc2... different source (obsolete tag?) > Missing object of tag v2.6.12-rc3... different source (obsolete tag?) > Missing object of tag v2.6.12-rc4... different source (obsolete tag?) > Missing object of tag v2.6.12-rc5... different source (obsolete tag?) > Missing object of tag v2.6.12-rc6... different source (obsolete tag?) > Missing object of tag v2.6.13-rc1... different source (obsolete tag?) > Missing object of tag v2.6.13-rc2... different source (obsolete tag?) Ok, cg-pull didn't quite handle this. I've fixed it so that it should reasonably handle it now. Hopefully. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ be careful, some twit might quote you out of context.. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
Dear diary, on Sat, Jul 09, 2005 at 11:04:37PM CEST, I got a letter where Matthias Urlichs <[EMAIL PROTECTED]> told me that... > > o Is there a way to force git to apply and safe the rejects? > > Well, you can use "patch -p1 ..." directly, and manually add the files it > created to the object cache. Personally I wouldn't, if at all possible. Or you can do cg-patch, which should handle that for you properly as well. I think the "no fuzz" approach is hyper-paranoid. I deal with small or larger fuzz all the time when I'm reordering patches or applying them to a few hours younger version than they were based on. I think the restriction it imposes is overly draconian here and doesn't trust the developer to know what he is doing as much as it should. (And that's why cg-patch doesn't use git-apply. ;-) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ be careful, some twit might quote you out of context.. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] add -N option to cg-add (resent)
Dear diary, on Sat, Jul 09, 2005 at 12:40:22PM CEST, I got a letter where Bryan Larsen <[EMAIL PROTECTED]> told me that... > (resending cogito patches) > > Add the -N option to cg-add. > > Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]> Applied all three patches. Note that I'm a bit happier when they are a little more maintainer-friendly - it helps to describe why are you resending them, and be a little more verbose in the accompanying message. :-) Thanks, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ be careful, some twit might quote you out of context.. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linus kernel tree corrupt?
Dear diary, on Sat, Jul 09, 2005 at 08:03:32PM CEST, I got a letter where "H. Peter Anvin" <[EMAIL PROTECTED]> told me that... > Petr Baudis wrote: > > > >Yes, please do. I deprecated rsync a day before Linus "broke" http-pull. > >It's un-deprecated again for now in the latest Cogito. > > > > Presumably for packed repos you want to drop the --ignore-existing > --whole-file options I assume? It _is_ unsafe for individual objects, and your packfile will be corrupt if you break it in the middle and not have --whole-file turned on, I assume. It would be ideal if we could make rsync allow resuming download of the file if interrupted, but not under the final name but in that hidden file it uses. > sent 339 bytes received 1802 bytes 4282.00 bytes/sec > total size is 410 speedup is 0.19 > Missing object of tag v2.6.11... different source (obsolete tag?) > Missing object of tag v2.6.11-tree... different source (obsolete tag?) > Missing object of tag v2.6.12... different source (obsolete tag?) > Missing object of tag v2.6.12-rc2... different source (obsolete tag?) > Missing object of tag v2.6.12-rc3... different source (obsolete tag?) > Missing object of tag v2.6.12-rc4... different source (obsolete tag?) > Missing object of tag v2.6.12-rc5... different source (obsolete tag?) > Missing object of tag v2.6.12-rc6... different source (obsolete tag?) > Missing object of tag v2.6.13-rc1... different source (obsolete tag?) > Missing object of tag v2.6.13-rc2... different source (obsolete tag?) > New branch: 0109fd37046de64e8459f8c4f4706df9ac7cc82c > Cloned (origin > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > available as branch "origin") > Cloned to ./ (origin > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > available as branch "origin") > > Is the "missing objects" thing spurious? Yes, already fixed. Will release 0.12.1 soon. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ be careful, some twit might quote you out of context.. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New script: cg-clean
Dear diary, on Sat, Jul 09, 2005 at 12:34:44AM CEST, I got a letter where Pavel Roskin <[EMAIL PROTECTED]> told me that... > Hello, Petr! Hello, > Please consider this script for Cogito. > > Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]> the script is definitively interesting, but I have couple of notes about it first: (i) -i sounds wrong for anything but being interactive here ;-) What about -A? (ii) I'm confused - if -a is all of the above, how do I clean _only_ regular files, and only those not ignored by cg-status? (iii) Makes it any sense to remove only special files? (iv) -r implies being recursive, but it has nothing to do with that here. (v) Semantically, I think it's quite close to cg-reset. What about making it part of cg-reset instead of a separate command? I tend to be careful about command inflation. (That's part of being careful about the usability in general.) That's just an idea and possibly a bad one, what do you think? Thanks, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ be careful, some twit might quote you out of context.. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: arch 2.0 first source available (git related)
Dear diary, on Sat, Jul 09, 2005 at 04:20:13PM CEST, I got a letter where Thomas Lord <[EMAIL PROTECTED]> told me that... > The prereq graph is, indeed, an improvement. ..snip.. But object retrieval can be potentially as much as linear to the depth of the prereq graph, right? I don't think any of the benefits you listed are worth the complication, and you can still do the reachability analysis pretty easily. (And I think it takes the same number of roundtrips when downloading from remote server?) > Other advantageous (imo) changes from `git' not mentioned in the > original message: > > * blobs do not have header lines > > Git blobs all begin with a line of text declaring the "type" > and size of the blob. That doesn't increase database > verifiability significantly and I found no use for the headers. > Having the headers makes it needlessly complicated to translate > a file to or from a blob. > > `revc' does not have blob headers. In git, this is crucial at least for distinguishing commits and tags. I personally consider the verifiability boost useful. > * `revc' uses portable file formats > >In working dirs, `git' stores binary files which are >endian, word-size, and compiler-environment specific. > >`revc' stores some binary files too (for performance >and simplicity reasons) but uses only portable formats. I think they are only word-size specific, and that should be no big matter to resolve, shall anyone want to. > * `revc' is shaping up into much cleaner and more portable code > >(at least compared to the last version of `git' I saw -- > which was extremely *lucid* code but not terribly > clean and not even attempting to be portable.) All right, the portability could be better. ;-) Kind regards, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ be careful, some twit might quote you out of context.. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: arch 2.0 first source available (git related)
Dear diary, on Mon, Jul 11, 2005 at 11:36:56PM CEST, I got a letter where Thomas Lord <[EMAIL PROTECTED]> told me that... > On Mon, 2005-07-11 at 21:39 +0200, Petr Baudis wrote: > > Dear diary, on Sat, Jul 09, 2005 at 04:20:13PM CEST, I got a letter > > where Thomas Lord <[EMAIL PROTECTED]> told me that... > > > The prereq graph is, indeed, an improvement. > > ..snip.. > > > But object retrieval can be potentially as much as linear to the depth > > of the prereq graph, right? > > Potentially but not, by far, in the common case. > > Moreover, that depth is an arbitrary parameter which user's can > freely vary -- that's part of the point. But if the depth will be less than that, won't the user end up with some (plenty) of the objects duplicated? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ be careful, some twit might quote you out of context.. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cogito clone, invalid cross-dev links
Dear diary, on Mon, Jul 11, 2005 at 10:44:45PM CEST, I got a letter where Marc Singer <[EMAIL PROTECTED]> told me that... > It complained when I cloned across devices. > > `/git/cogito/.git/refs/tags/cogito-0.8' -> `.git/refs/tags/cogito-0.8' > cp: cannot create link `.git/refs/tags/cogito-0.8': Invalid cross-device > link > `/git/cogito/.git/refs/tags/cogito-0.9' -> `.git/refs/tags/cogito-0.9' > cp: cannot create link `.git/refs/tags/cogito-0.9': Invalid cross-device > link > > and so on. Is this a problem? Small problem, yes - fixed now. Thanks. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ be careful, some twit might quote you out of context.. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cogito-0.12: problem with local clone
Dear diary, on Fri, Jul 08, 2005 at 01:00:55AM CEST, I got a letter where Wolfgang Denk <[EMAIL PROTECTED]> told me that... > Hello, Hello, > I have problems with Cogito-0.12 when trying to clone a "local" tree: sorry for the late reply. > When I try to create a local clone I get lots of error messages: Yes, Cogito did not handle cross-filesystem local pulls correctly. Should be fixed now. Thanks, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ be careful, some twit might quote you out of context.. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Cogito 0.12.1
Hello,
here is Cogito 0.12.1, another desperate attempt to keep pace with
'@' or Linus, the named Human Master Coder. (Linus, the Human Master
Coder, mumbles arcane do { formulae } while (0)! Some kind of force
seems to attack your mind. Everything suddenly looks so different...
You are confused.) Visit the greater spellbook vault at
http://www.kernel.org/pub/software/scm/cogito
or re-attune yourself to the git plane (in case you are already
connected to the mana flow of Cogito) for updated powerful
counter-magick.
Most of it is upstream stuff. Otherwise, almost everything are
bugfixes and updates to deal better with the mighty pack stuff.
Important bugfixes is fixed parent-id (cg-admin-uncommit, subsequently)
and massive pull fixes w.r.t. pulling from packed repositories and
cross-filesystem local pull.
Oh, don't get used too much to the new cg-info script's semantics,
I want to move the functionality to cg-status; I just forgot to do it
before tagging the release and only remembered it now.
May the sun always shine on you,
--
Petr "the High Elven Codethrower" Baudis
Stuff: http://pasky.or.cz/
You play too little rogue-like RPG games, apparently.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why is there no git-update-cache --modified (aka I give up)
Dear diary, on Tue, Jul 12, 2005 at 07:52:18AM CEST, I got a letter where Marc Singer <[EMAIL PROTECTED]> told me that... > # git-diff-cache HEAD > > is really nice. But, do I really have to invoke git-update-cache with > every modified file? I could write a script to cul the filenames from > git-diff-cache, but I'm having a hard time believing that that is how > others are preparing their commits. It is. :-) It's only that they have cool scripts to do it, e.g. cg-commit. (You have to enumerate the files explicitly for git-commit-script as well, IIRC.) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ be careful, some twit might quote you out of context.. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remove Obsoletes from cogito.spec.in
Dear diary, on Tue, Jul 12, 2005 at 02:33:45AM CEST, I got a letter where Chris Wright <[EMAIL PROTECTED]> told me that... > This is leftover from early naming, and is no longer relevant. > > Signed-off-by: Chris Wright <[EMAIL PROTECTED]> Thanks, applied. BTW, Josh Boyer of Fedora suggested having the Provides: git line in cogito.spec.in as long as it comes with git bundled (which will be so until git stabilizes, doesn't break backwards compatibility once in a while, and gets into some regular and reasonably frequent release cycle). What do you think? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ be careful, some twit might quote you out of context.. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
Dear diary, on Tue, Jul 12, 2005 at 06:34:33AM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > On Mon, 11 Jul 2005, Linus Torvalds wrote: > > > > Of course, if you want to create a new branch "my-branch" and _not_ > > check it out, you could have done so with just > > > > git-rev-parse v2.6.12^0 > .git/refs/heads/my-branch > > > > which I think I will codify as "git branch". > > And now we have that "git branch". It's a trivial one-liner, except with > the setup and error checking it's actually more like six lines. Could we please have the branch name written to .git/head-name in case we switch the branch? The reason is that .git/HEAD may not be always a symlink. Specifically, I do this - there's a command cg-seek, which will seek your working tree to a given commit, while staying on the branch (committing and some other operations are blocked). In that case, I remove .git/HEAD and replace it with ID of the commit I'm seeked at, and when I'm "unseeking" back to the top, I replace it with the symlink again. With some heuristics, I could create .git/head-name at the time of seek and hope, but I think it'd be cleaner to just always set it (except when we are on the master branch), if you agree. Note that even though Cogito won't let you create/change a local branch yet, it will understand .git/head-name and hopefully behave properly (although it's totally untested, of course). -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ be careful, some twit might quote you out of context.. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tagger id
Dear diary, on Tue, Jul 12, 2005 at 05:04:23PM CEST, I got a letter where "Eric W. Biederman" <[EMAIL PROTECTED]> told me that... > > By the way, I do not particularly like the name "git-id". There > > could be IDs for different kinds (not just people) we would want > > later (file IDs, for example). Naming what you are computing > > _the_ "id" feels a bit too generic. I do not have a better > > alternative to suggest, though. > > Agreed. Something like git-author or git-author-stamp is probably > better. Since that "infriges" the author/committer distinction, I would prefer git-person-id. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ be careful, some twit might quote you out of context.. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cg update failing
Dear diary, on Fri, Jul 15, 2005 at 06:12:48AM CEST, I got a letter where James Cloos <[EMAIL PROTECTED]> told me that... > Well, it wasn't as Ok as I first thought. There were several .rej and > backup files as left behind by patch(1). cg update HEAD says: Branch > already fully merged but Makefile still says 2.6.12. > > I'm cloning now to a remote uml and will try and rsync from there to > the laptop. Perhaps *that* will get me a working repo. Huh. Well, you had to do uberweird things with your repository - why did you cg-seek at all? What Cogito version is it? Anyway, cg-reset (or cg-cancel in "older" Cogito) should bring everything in shape. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cannot get git any more?
Dear diary, on Mon, Jul 18, 2005 at 12:49:04AM CEST, I got a letter where Wolfgang Denk <[EMAIL PROTECTED]> told me that... > -> cd .. > -> mv git git.OLD > -> cg-clone rsync://rsync.kernel.org/pub/scm/git/git.git > /usr/local/src/git > defaulting to local storage area > @ERROR: Unknown module 'pub' > rsync: connection unexpectedly closed (41 bytes read so far) > rsync error: error in rsync protocol data stream (code 12) at io.c(342) > cg-pull: unable to get the head pointer of branch master > cg-init: pull failed That's puzzling. Try just rsync -a rsync://rsync.kernel.org/pub/scm/git/git.git /usr/local/src/git which should fail too and indicates that something must be weird on your side since it apparently works for the rest of the world. ;-) Try upgrading rsync, check if it really connects to the real rsync.kernel.org and such... > -> rm -fr git > -> cg-clone http://www.kernel.org/pub/scm/git/git.git > /usr/local/src/git > defaulting to local storage area > 00:44:43 URL:http://www.kernel.org/pub/scm/git/git.git/refs/heads/master > [41/41] -> "refs/heads/origin" [1] > progress: 2 objects, 4252 bytes > error: File 6ff87c4664981e4397625791c8ea3bbb5f2279a3 > (http://www.kernel.org/pub/scm/git/git.git/objects/6f/f87c4664981e4397625791c8ea3bbb5f2279a3) > corrupt > > Cannot obtain needed blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3 > while processing commit . > cg-pull: objects pull failed > cg-init: pull failed This is unfortunately normal now. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Cogito 0.12.1
Dear diary, on Wed, Jul 13, 2005 at 01:13:52PM CEST, I got a letter where Catalin Marinas <[EMAIL PROTECTED]> told me that... > Russell King <[EMAIL PROTECTED]> wrote: > > I won't bother trying to explain, I'll just paste the errors. We've been > > here before in a previous cogito revision. > > > > [EMAIL PROTECTED]:[linux-2.6-rmk]:<1038> cg-branch-ls > > origin ../linux-2.6 > > smp ../linux-2.6-smp > > I noticed that Cogito doesn't work well with relative paths. Run > cg-branch-chg and put absolute paths, it might work (it did for me). Yes, that's it. Will be fixed in Cogito-0.12.2 (or 0.13, whichever comes first), thanks. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is cogito really this inefficient
Dear diary, on Thu, Jul 14, 2005 at 05:26:07PM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > It's quite possible that some path in cg-update ends up not updating the > index properly. For example, I notice that the "fast-forward" uses > "git-checkout-cache -f -a", which can do so (lack of "-u" fila), but then > it does do a "git-update-cache --refresh" later, so that doesn't seem to > be it either. Just a side note for casual readers, Cogito could use a cleanup here - from large part it ignores things like git-checkout-cache -u simply because there was no such option at the time that part of Cogito was written. I myself am not even too familiar about those gazillions of funny new options, and as long as it works, I prefer not to touch that code, but if someone is bored and wants to get familiar with core git usage as well as Cogito internals... -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Gct-0.1, a GUI enabled Git commit tool
Dear diary, on Fri, Jul 15, 2005 at 02:46:42AM CEST, I got a letter where Fredrik Kuivinen <[EMAIL PROTECTED]> told me that... > Hi, Hello from a lazy reader who didn't actually try it, > Gct v0.1 has been released and can be downloaded from > http://www.cyd.liu.se/~freku045/gct/gct-0.1.tar.gz > > What follows is an excerpt from the README in the tarball: > > Introduction > > > Git Commit Tool or gct is a simple GUI enabled Git commit tool. It > allows the user to select which files should be committed, write > commit messages and perform the commit. It also has some support for > controlling the synchronisation between the Git cache and the working > directory. do you have any screenshots please? From the description it appears it is actually not any more powerful than cg-commit. Does it let you see the diff, actually prune the changes to be committed and such? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why fetching latest kernel sources is failing?
Dear diary, on Wed, Jul 13, 2005 at 07:22:22PM CEST, I got a letter where "Paolo \\'Blaisorblade\\' Giarrusso" <[EMAIL PROTECTED]> told me that... > cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Please use rsync, http is broken for the time being and not trivially fixable (patches pending, though). -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cg update failing
Dear diary, on Wed, Jul 20, 2005 at 06:34:43AM CEST, I got a letter where James Cloos <[EMAIL PROTECTED]> told me that... > >>>>> "Petr" == Petr Baudis <[EMAIL PROTECTED]> writes: > > Petr> Huh. Well, you had to do uberweird things with your repository - > Petr> why did you cg-seek at all? What Cogito version is it? > > All I ever did was track and compile linus??? tree. IIRC, when the > first new tag was added after I cloned the tree I had to seek to > that tag to see the new versions of the files. But obviously > that was long enough before hg???s repo broke that I???d forgotten > how I???d done that Ah so. Well, yes, the first tag was IIRC weird since it was a tree tag, not a commit tag. That confused things, but it shouldn't be necessary anymore since all new tags are hopefully commits. That might somehow create the local modifications as well, although I don't have a clear idea how could be that possible. Well, there were some bugs like this in Cogito in the past, but that should be long fixed. Thanks anyway, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] cogito: compatibility with OS X
Dear diary, on Mon, Jul 18, 2005 at 04:50:31AM CEST, I got a letter where Bryan Larsen <[EMAIL PROTECTED]> told me that... > 3) upload Portfile's along with the .tar.gz's. That's what we do with cogito.spec as well and it's fine. Just send me an appropriate patch for the dist target. > 2 of these 5 patches are unchanged from the previous post. I have > attached them anyways to maintain the series. Please let me know if > this is poor etiquette. I think it's fine. :-) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Misc documentation fixes and improvements
Dear diary, on Wed, Jul 20, 2005 at 02:05:01PM CEST, I got a letter where Jonas Fonseca <[EMAIL PROTECTED]> told me that... > Fix displaying of an error message when cg-help is called with unknown > command and use $USAGE so the correct cg-help usage string is printed. > Drop useless use of cat in print_help(). Improve the asciidoc markup. > > Signed-off-by: Jonas Fonseca <[EMAIL PROTECTED]> > --- > > diff --git a/cg-diff b/cg-diff > --- a/cg-diff > +++ b/cg-diff > @@ -3,7 +3,7 @@ > # Make a diff between two GIT trees. > # Copyright (c) Petr Baudis, 2005 > # > -# Outputs a diff for converting the first tree to the second one. > +# Outputs a diff for converting between two trees. > # By default compares the current working tree to the state at the > # last commit. The output will automatically be displayed in a pager > # unless it is piped to a program. I dropped this hunk (seems to only lose clarity). > diff --git a/cg-help b/cg-help > --- a/cg-help > +++ b/cg-help > @@ -90,7 +91,7 @@ ADVANCED_COMMANDS="$(ls $bin_path/cg-adm > colorize <<__END__ > The Cogito version control system $(cg-version) > > -Usage: cg-COMMAND [ARG]... > +Usage: $USAGE > > Available commands: > $(print_command_listing $REGULAR_COMMANDS) And I dropped the Usage string here altogether. Thanks, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
Dear diary, on Fri, Jul 22, 2005 at 12:37:05PM CEST, I got a letter where Catalin Marinas <[EMAIL PROTECTED]> told me that... > > Cogito seems to use $GIT_DIR/commit-template for that purpose. > > Can't users put that "vim:" hint there, and if StGIT does not > > use a commit template, patch it to use the same file as Cogito > > does? > > I would use a neutral commit template, only that it should have a > neutral prefix as well for the lines to be removed (neither STG nor CG > but GIT maybe). The $GIT_DIR/commit-template is fine as a file name. This unfortunately isn't that simple, since this file substitutes only the CG: --- CG: Lines beginning with the CG: prefix are removed automatically. snippet of the file. The trouble is, Cogito autogenerates most of the rest of it. Would the acceptable solution be that I would have @[EMAIL PROTECTED] placeholders there, and any tool processing the file would simply drop lines containing @ directives it does not understand? (@@ is escaped @) I have nothing against changing the prefix to GIT:. Then, Cogito's default commit-template would look like GIT: --- GIT: Lines beginning with the GIT: prefix are removed automatically. GIT: GIT: Author: @AUTHOR_NAME@ GIT: Email: @AUTHOR_EMAIL@ GIT: Date: @AUTHOR_DATE@ GIT:@CG_SHOWFILES@@CG_NOMERGE@ GIT:@CG_SHOWFILES@@CG_NOMERGE@ By deleting lines beginning with GIT:F, the associated file GIT:@CG_SHOWFILES@@CG_NOMERGE@ will be removed from the commit list. GIT:@CG_SHOWFILES@ GIT:@CG_SHOWFILES@ Modified files: GIT:@[EMAIL PROTECTED] @FILELIST@ GIT: --- GIT: vim: textwidth=75 (where CG_SHOWFILES is defined only when the list of the files is to be shown and CG_NOMERGE only when there is no merge going on). -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
Dear diary, on Fri, Jul 22, 2005 at 10:39:06PM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > Porcelains need to agree on what is placed where and used in > what way. Yes, I always try to make things as Cogito-unspecific as possible. > - Per user. A user may want to use different environment > settings for different projects [*4*]. > > - Per repository (or work tree). A user may have more than > one work tree for the same project, and want to use > different "preference" items per tree. I wouldn't distinct between those two. You as a user can copy things around when you clone the repositories (if you ever do so), or the Porcelain can do it, but having global per-user _combined with per-project settings sounds nightmarish. After all, how do you identify a project? What if projects merge? I wouldn't open this can of worms. Obviously, there have to be just per-user settings (independent of "project"). > About the "where" part, one proposal I have off the top of my > head is something like this: > > - Have a directory at the root of the tree, "_git" (I do not > care about the name at this moment. The point being it can > be revision controlled as part of the project and propagate > to other repositories), to store per-project configuration. Fine, but I would probably prefer having it hidden. .gitinfo? > - Use $GIT_DIR/conf/ as a convention to store per repository > configuration files. This does not propagate with > pulls/pushes/merges across repositories. That's fine by me. I'd prefer the hooks staying in $GIT_DIR/hooks/. > - Use $HOME/.gitrc (could be a directory or a file in .ini > style like StGIT uses -- again, I do not care about the > details at this moment) to store per-user configuration. As long as I can sanely parse it in shell... ;-) > Which configuration is read first, what can be overridden, and > if the configuration is cumulative would be specific to each > preference item, I suspect. Some project may not want a user to > override the pre-commit hooks, for a bad example. But normally > the per-repository one would take precedence over per-user one > which in turn would take precedence over per-project one. What about just running all the hooks in the order you specified? > [Footnotes] > > *1* Technically this does not involve the core at all, but the > core people can act as objective, Porcelain-neutral referees. > They'll need to know the outcome of the discussion anyway, since > they are the ones that end up maintaining the Porcelain-neutral > tutorial document. > > *2* Unless we are talking about the kind that shows and lets you > edit the diff to be committed, which somebody else's Porcelain > may support, that is. FWIW, I'm planning something like this in cg-commit (when called explicitly with -d) in short-term future. > *3* .gitignore in the cwd is used in Cogito, if I am not > mistaken. Yes. There were several discussions about this in the past, with no clear outcome, IIRC. I would prefer: ~/.git/ignore per-user /.git/ignore per-repository .gitignore per-directory (cummulative with parent directories) Note that I also want to make use of some special characters in this file. In particular /^# and /^!, to make it at least as powerful as CVS' ignore. > *4* E.g. I would commit for GIT project with [EMAIL PROTECTED] > while using [EMAIL PROTECTED] for my day-job projects. .git/author in current Cogito (.git/conf/author or something in the Brave New World ;-). -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should cg-mkpatch output be usable with cg-patch?
Dear diary, on Thu, Jul 21, 2005 at 05:57:49AM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > I only briefly looked at cg-patch, but I suspect that it can > lose 90% lines of its code by just using "git-apply --index". Can git-apply already deal with fuzzy patches? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should cg-mkpatch output be usable with cg-patch?
Dear diary, on Thu, Jul 21, 2005 at 01:49:04AM CEST, I got a letter where Wolfgang Denk <[EMAIL PROTECTED]> told me that... > I wander what I should do with "cg-mkpatch" generated output; I had > the impression that this should be usable with "cg-patch", but these > are incompatible with each other. They certainly aren't. > Forexample. if a commit contains permission changes, my generated > patch may look like this: > > ... > diff --git a/MAKEALL b/MAKEALL > old mode 100644 > new mode 100755 > diff --git a/mkconfig b/mkconfig > old mode 100644 > new mode 100755 > diff --git a/tools/img2brec.sh b/tools/img2brec.sh > old mode 100644 > new mode 100755 > ... > > If I feed this into "cg-patch", I get: > > patch: Only garbage was found in the patch input. And did the changes apply? :-) The message is surely confusing, but appeared to be rather corner-casy and after I imagined the required complexity of filtering this, I decided to spend my time on something more useful for the time being. :) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] GIT: Try all addresses for given remote name
Dear diary, on Thu, Jul 21, 2005 at 03:10:36PM CEST, I got a letter
where "YOSHIFUJI Hideaki / ?$B5HF#1QL@" <[EMAIL PROTECTED]> told me that...
> Hello.
Hello,
> Try all addresses for given remote name until it succeeds.
> Also supports IPv6.
>
> Signed-of-by: Hideaki YOSHIFUJI <[EMAIL PROTECTED]>
>
> diff --git a/connect.c b/connect.c
> --- a/connect.c
> +++ b/connect.c
> @@ -96,42 +96,57 @@ static enum protocol get_protocol(const
> die("I don't handle protocol '%s'", name);
> }
>
> -static void lookup_host(const char *host, struct sockaddr *in)
> -{
> - struct addrinfo *res;
> - int ret;
> -
> - ret = getaddrinfo(host, NULL, NULL, &res);
> - if (ret)
> - die("Unable to look up %s (%s)", host, gai_strerror(ret));
> - *in = *res->ai_addr;
> - freeaddrinfo(res);
> -}
> +#define STR_(s) # s
> +#define STR(s) STR_(s)
Uh-huh? Why two macros? Well, why any macros at all?
> static int git_tcp_connect(int fd[2], const char *prog, char *host, char
> *path)
> {
> - struct sockaddr addr;
> - int port = DEFAULT_GIT_PORT, sockfd;
> - char *colon;
> -
> - colon = strchr(host, ':');
> - if (colon) {
> - char *end;
> - unsigned long n = strtoul(colon+1, &end, 0);
> - if (colon[1] && !*end) {
> - *colon = 0;
> - port = n;
> + int sockfd = -1;
> + char *colon, *end;
> + char *port = STR(DEFAULT_GIT_PORT);
> + struct addrinfo hints, *ai0, *ai;
> + int gai;
> +
> + if (host[0] == '[') {
> + end = strchr(host + 1, ']');
> + if (end) {
> + *end = 0;
> + end++;
> + host++;
> + } else
> + end = host;
> + } else
> + end = host;
> + colon = strchr(end, ':');
> +
> + if (colon)
> + port = colon + 1;
> +
> + memset(&hints, 0, sizeof(hints));
> + hints.ai_socktype = SOCK_STREAM;
> + hints.ai_protocol = IPPROTO_TCP;
> +
> + gai = getaddrinfo(host, port, &hints, &ai);
> + if (gai)
> + die("Unable to look up %s (%s)", host, gai_strerror(gai));
> +
> + for (ai0 = ai; ai; ai = ai->ai_next) {
> + sockfd = socket(ai->ai_family, ai->ai_socktype,
> ai->ai_protocol);
> + if (sockfd < 0)
> + continue;
> + if (connect(sockfd, ai->ai_addr, ai->ai_addrlen) < 0) {
> + close(sockfd);
> + sockfd = -1;
> + continue;
> }
> + break;
> }
>
> - lookup_host(host, &addr);
> - ((struct sockaddr_in *)&addr)->sin_port = htons(port);
> + freeaddrinfo(ai0);
>
> - sockfd = socket(PF_INET, SOCK_STREAM, IPPROTO_IP);
> if (sockfd < 0)
> die("unable to create socket (%s)", strerror(errno));
> - if (connect(sockfd, (void *)&addr, sizeof(addr)) < 0)
> - die("unable to connect (%s)", strerror(errno));
> +
> fd[0] = sockfd;
> fd[1] = sockfd;
> packet_write(sockfd, "%s %s\n", prog, path);
You are saying that you were unable to create socket while you just were
unable to connect. Not any biggie, but it saves the user the trouble of
one strace after being confused by an error message. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] GIT: Listen on IPv6 as well, if available.
Dear diary, on Thu, Jul 21, 2005 at 03:10:49PM CEST, I got a letter
where "YOSHIFUJI Hideaki / ?$B5HF#1QL@" <[EMAIL PROTECTED]> told me that...
> Hello.
Hello from an IPv6 fan,
> Listen on IPv6 as well, if available.
>
> Signed-off-by: Hideaki YOSHIFUJI <[EMAIL PROTECTED]>
>
> diff --git a/daemon.c b/daemon.c
> --- a/daemon.c
> +++ b/daemon.c
> @@ -219,37 +219,102 @@ static void child_handler(int signo)
>
> static int serve(int port)
> {
..snip..
this whole getaddrinfo() magic looks horribly complicated. What's wrong
on just adding a similar code (or factoring it out to a function) for
IPv6 as there is for IPv4, just s/INET/INET6/?
> for (;;) {
> - struct sockaddr_in in;
> - socklen_t addrlen = sizeof(in);
> - int incoming = accept(sockfd, (void *)&in, &addrlen);
> -
> - if (incoming < 0) {
> - switch (errno) {
> - case EAGAIN:
> - case EINTR:
> - case ECONNABORTED:
> - continue;
> - default:
> - die("accept returned %s", strerror(errno));
> + struct sockaddr_storage ss;
> + socklen_t sslen = sizeof(ss);
Perhaps move those to the most inner block. (All right, I'm nitpicking
too much again, sorry.)
> +
> + int i;
> + fds = fds_init;
> +
> + if (select(maxfd + 1, &fds, NULL, NULL, NULL) == -1) {
> + /* warning? */
Certainly a warning and at least sleep(1) to avoid cpuburn-like
behaviour in case of anything going wrong.
> + continue;
> + }
> +
> + for (i = 0; i < socknum; i++) {
> + int sockfd = socklist[i];
> +
> + if (FD_ISSET(sockfd, &fds)) {
> + int incoming = accept(sockfd, (struct sockaddr
> *)&ss, &sslen);
> + if (incoming < 0) {
> + switch (errno) {
> + case EAGAIN:
> + case EINTR:
> + case ECONNABORTED:
> + continue;
> + default:
> + die("accept returned %s",
> strerror(errno));
> + }
> + }
> + handle(incoming, (struct sockaddr *)&ss, sslen);
> }
> }
> - handle(incoming, &in, addrlen);
> }
> }
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
Dear diary, on Fri, Jul 22, 2005 at 11:16:51PM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > Wonderful start. > > Later on, Porcelains could agree on what @TOKEN@ are generally > available, and even start using a common script to pre-fill the > templates, like: > > $ git-fill-template-script var=val var=val... > > In your example, I see AUTHOR_NAME, AUTHOR_EMAIL, and > AUTHOR_DATE (I'd use GIT_AUTHOR_NAME etc to match existing > environment variables, though) would be something that are > probably common across Porcelains, and the Porcelain would not > even have to bother passing them as the command argument to > fill-template. Good idea. More interesting exercise would be to make a script which extracts the values back after the user had a chance to touch it. > About FILELIST, the default would be to do "git-diff-cache --name-only > HEAD", but if a Porcelain keeps track of "modified" files differently > it can be overridden by passing FILELIST as an explicit parameter. Cogito shows '[NMD] filename' in place of @[EMAIL PROTECTED] This brings me to another subject, M and N are pretty hard to distinguish visually without close inspection of the output. What about switching to use A instead of N everywhere? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] GIT: Try all addresses for given remote name
Dear diary, on Fri, Jul 22, 2005 at 11:26:29PM CEST, I got a letter
where "YOSHIFUJI Hideaki / ?$B5HF#1QL@" <[EMAIL PROTECTED]> told me that...
> In article <[EMAIL PROTECTED]> (at Fri, 22 Jul 2005 23:09:13 +0200), Petr
> Baudis <[EMAIL PROTECTED]> says:
>
> > > -}
> > > +#define STR_(s) # s
> > > +#define STR(s) STR_(s)
> >
> > Uh-huh? Why two macros? Well, why any macros at all?
> >
> :
> > > + char *colon, *end;
> > > + char *port = STR(DEFAULT_GIT_PORT);
> > > + struct addrinfo hints, *ai0, *ai;
>
> The macro is used here.
> This is trick.
>
> After preprocess,
>
> /* --- cut here --- */
> #define TEST 12345
> #define STR_(s) # s
> #define STR(s) STR_(s)
>
> test(STR(TEST));
> test(STR_(TEST));
> test(# TEST);
> /* --- cut here --- */
>
> becomes
>
> test("12345");
> test("TEST");
> test(# 12345);
I see, I didn't know about this. Well, I didn't actually use the #
stringificator many times. Perhaps a short comment would be due.
> > > if (sockfd < 0)
> > > die("unable to create socket (%s)", strerror(errno));
> > > - if (connect(sockfd, (void *)&addr, sizeof(addr)) < 0)
> > > - die("unable to connect (%s)", strerror(errno));
> :
> > You are saying that you were unable to create socket while you just were
> > unable to connect. Not any biggie, but it saves the user the trouble of
> > one strace after being confused by an error message. :-)
>
> In fact, I don't think it is really worng, because it says that
> it could not create (connected) socket or endpoint of connection.
It uses only two words ("create socket") from that, though. ;-)
> Anyway, I agree that it would be confusing.
> Better ideas / wordings?
if (connect() < 0) sockfd = -2;
...
if (sockfd == -1) die("unable to create socket");
else die("unable to connect")
or I'd prefer the second error message "unable to connect", which is
perhaps more descriptive regarding what effectively happened.
BTW, could the close() on the socket ever fail (read as "modify errno")
here?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] GIT: Listen on IPv6 as well, if available.
Dear diary, on Fri, Jul 22, 2005 at 11:35:17PM CEST, I got a letter where "YOSHIFUJI Hideaki / ?$B5HF#1QL@" <[EMAIL PROTECTED]> told me that... > In article <[EMAIL PROTECTED]> (at Fri, 22 Jul 2005 23:21:51 +0200), Petr > Baudis <[EMAIL PROTECTED]> says: > > this whole getaddrinfo() magic looks horribly complicated. What's wrong > > on just adding a similar code (or factoring it out to a function) for > > IPv6 as there is for IPv4, just s/INET/INET6/? > > Because it is the Good Way To Go; protocol independent programming. I can see its merits, and it doesn't look so horrible after a while. ;-) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make debian/rules executable, and correct the spelling of rsync in debian/control
Dear diary, on Wed, Jul 20, 2005 at 03:17:47AM CEST, I got a letter where Ryan Anderson <[EMAIL PROTECTED]> told me that... > Make debian/rules executable, and correct the spelling of rsync in > debian/control Any progress with applying of this one? Linus, do you want me to ack even trivial patches which had you in the recipient list? Or I could start actively maintaining git-pb again, if you wish. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git-pb rebased
Hello, I don't expect anyone but myself to actually follow git-pb, but just in case - I rebased it against the latest Linus' HEAD since its history was becoming rather dirty, rusty and generally undesirable to merge for anyone. So if you will try to update, you will end up with tree merge and you don't want to do that, so cat .git/refs/heads/origin >.git/refs/heads/master -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Local cg-pull fails
Dear diary, on Thu, Jul 14, 2005 at 12:12:25PM CEST, I got a letter where Russell King <[EMAIL PROTECTED]> told me that... > Last time this was discussed, someone suggested -f, which solved the > problem. Can we please modify the cg-pull script to use -f ? Thanks, done. > Secondly, can I suggest that cogito developers consider the above > usage scenario and construct a regression test for it to ensure that > future breakages of this nature are caught. For me, cogito has been > extremely fragile, and I don't think the above usage is unreasonable. Done. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] apply.c: a fix and an enhancement
Dear diary, on Fri, Jul 22, 2005 at 11:53:41PM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > On Fri, 22 Jul 2005, Junio C Hamano wrote: > > > > And the file would obviously be per-project, so according to > > Pasky's suggestion that would be ".gitinfo/fake_parents" ;-). > > I'd _really_ prefer to not have any preferences or other metadata files > under version control within that same project. > > If you want to version control them, that's fine, but don't tie the > versioning to the main project itself. You can have a _separate_ git > index, and a separate branch for the preferences and other metadata (but > you can, if you want to, obviously share the .git directory contents and > mix up the objects). I think that is a bad idea. Suddenly, you do not have the two things in the same timeline, which may be quite confusing especially in case of some hooks which depend on the contents of the tree of the project itself, in case of commit templates and such. > And personal preferences are just that - personal. I do _not_ want to have > the kernel project history have things like "editor preferences" etc in > the revision history - you might want to revision them, but that would be > totally independent of the history of the project itself. Yes, but this stuff is not for personal preferences. It is for project-wide preferences and policies, which can be still normally overridden or altered locally in each repository. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] apply.c: a fix and an enhancement
Dear diary, on Sat, Jul 23, 2005 at 01:26:07AM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > On Fri, 22 Jul 2005, Junio C Hamano wrote: > > Linus Torvalds <[EMAIL PROTECTED]> writes: > > > > > I'd _really_ prefer to not have any preferences or other metadata files > > > under version control within that same project. > > > > Don't you think that would be a per-project decision? Is it > > acceptable if I make sure that .gitinfo/* is _optional_ and > > things do not break for projects that do not use it? > > It can't be a per-project decision, since the preferences are > per-developer. > > In other words, if it's per-project, then that implies that every single > developer has to agree on the same thing. Which just not possible - it > makes no sense. Some example of possible per-project settings: pre-commit hook killing trailing whitespaces global per-project ignore file (*.ko or something) common base commit template (standardized form developer fills in when committing, some remindments in the comment section, ...) Obviously, you still ought to have a way to locally override any of those per-repository in your .git/conf/. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
Dear diary, on Sat, Jul 23, 2005 at 01:24:35AM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > Petr Baudis <[EMAIL PROTECTED]> writes: > > > Cogito shows '[NMD] filename' in place of @[EMAIL PROTECTED] > > Sounds sensible. Does it parse it to limit the files to be > committed? Yes. > > This brings me to another subject, M and N are pretty hard to > > distinguish visually without close inspection of the output. What about > > switching to use A instead of N everywhere? > > Although I admit that is minor, I've had the same problem, and > this sounds like a good idea. > > However, I'd like to see what the extent of damage would be even > if everybody agrees this is a good change. Any one of core > barebone Porcelain, Linus git-tools, gitk, gitweb, Cogito, and > StGIT would have a veto over this kind of change, or at least we > should wait until everybody catches up. I don't think the situation is so bad. At least in Cogito, there is only one use of 'N' (and cg-status, but that goes directly to the user), and it's likely useless and things would work even with that changing to 'A' (nevertheless, I just updated Cogito to accept 'A' at that place as well). -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] apply.c: a fix and an enhancement
Dear diary, on Sat, Jul 23, 2005 at 01:50:09AM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > > > On Sat, 23 Jul 2005, Petr Baudis wrote: > > > > Yes, but this stuff is not for personal preferences. It is for > > project-wide preferences and policies, which can be still normally > > overridden or altered locally in each repository. > > What you are describing is a nightmare. > > Let's assume that a user alters the settings locally. > > EVERY SINGLE TIME he does a "cg-commit", those local alterations would get > committed, since that config file is part of the same project, and cogito > by default commits all changes. No, no, no. A user does not alter the settings locally in .gitinfo/ - .gitinfo/ is for per-_project_ stuff, not per-user. If user wants an override, he does it per-repository in his .git/conf directory, which is not version-tracked (actually, core GIT does not even let me to). > That's just insane. It means that in practive it's simply not reasonable > to have your own local copies of that file. So what would you do? You'd > add more and more hacks to cover this up, and have a "commit-ignore" file > that ignores the .gitinfo files etc etc. UGLY. All because of a design > mistake. Actually, commit-ignore might be useful in other cases, e.g. when someone (me, a thousand times in the past) needs to keep temporary hacks in the Makefile so that he can actually build the thing on his weird system etc. ;-) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
Dear diary, on Sat, Jul 23, 2005 at 01:07:05AM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > Catalin Marinas <[EMAIL PROTECTED]> writes: > > > Would such a template only have 'GIT:' prefixed lines? I usually put > > another line like 'Signed-off-by:', for convenience. The problem with > > StGIT appears when one wants to re-edit the patch description (stg > > refresh -e), in which case the existing description should be merged > > with a part of the template (if you want to get the editor setting for > > example). It doesn't do this since there is no point in getting another > > 'Signed...' line in the existing description. > > If signed-off-by is the only thing you are worried about, how > about making it not part of the commit template and the message > user touches with the editor? You first look at the user > configuration somewhere to see if the user wants the > signed-off-by line to his commits and with what value, and if > the last lines of the edit result does not contain that value > (to avoid duplicates), add it before feeding the message to > git-commit-tree. I would rather have something universal. Just avoid inserting duplicate lines at the bottom. > >> - standard "dontdiff/ignore" file. > > > > StGIT currently uses .git/exclude, since I saw it used by cogito. What > > is dontdiff supposed to do? The 'git diff' command only shows the diff > > for the files added to the repository. > > I see that what I wrote was vague and badly stated. Please > forget about my mentioning "dontdiff". What I meant was your > .git/exclude, Pasky's .gitignore file and friends. Cogito supports .git/exclude too, but I'd rather rename it to .git/ignore (or .git/conf/ignore) as well (gradually). > >> - environment overrides (COMMITTER_NAME, COMMITTER_EMAIL and > >> such). > > > > StGIT works the other way around. By default uses the environment, which > > can be overridden by the stgitrc file. I could change this easily. > > Again I was vague, and what you say StGIT does is exactly what I > meant. I have one value in my environment coming from the login > shell, and a per- repository preference item overrides it to > something else. I have it the other way around, with the rationale that your default settings should be in your ~/.gitrc, not environment, which is always the highest priority. The simple reason is that how would I apply the patches of other people otherwise? Now I do GIT_AUTHOR_NAME="Junio C Hamano" \ GIT_AUTHOR_EMAIL="[EMAIL PROTECTED]" \ GIT_AUTHOR_DATE="2008-04-01 05:12:33" \ cg-commit and it makes complete sense to me. > > For StGIT it makes sense to get some default settings via /etc/stgitrc. > > There are things like a SMTP server and the diff3 command. These are set > > when installing the application and can be overridden in your home > > or .git directories. > > Exactly, but that is not specific to StGIT, I presume, and I did > not want to hear "``For StGIT'' it makes sense". If StGIT needs > to use "diff3" on a system, probably that is because "merge" is > not available on that system. In that case, cogito needs to > use it too, doesn't it? diff3 throws its output on stdout, AFAIK. > If we can make users and sysadmins not having to maintain two > sets of configuration files for two Porcelains, if we > can,... that is what I have been trying to address. Yes, but it is a bit secondary to me. The most important for me is that meta-files inside the project itself (e.g. .gitignore) should be as portable as possible, as that'd be the biggest hurdle. The second priority for me is to make ~/.git/ as universal as possible. Having common per-user/per-system configuration file as well is nice too, but not so crucial. > > Before we get to "where", we should define the common > > settings. I think that git should define the common settings > > for its operations and the other tools should follow them. > > Personally, unless it is something very obvious and basic, I do > not think the core barebone Porcelain should be inventing > arbitrary conventions and imposing them on other Porcelains. > For very basic things I would agree. > > I think Petr already started the discussion rolling for commit > templates, and I like his proposal. For ignore pattern files, I > think what Cogito does sounds almost sensible [*1*] and I am > sure StGIT have something similar. I do not see Linus and co > jumping up and down saying git-status should detect and show new > files not registered in the cache, so for now I'd propose to > skip adding this one to the barebone Porcelain (meaning, this is > an example of not "git defining the common and others following > suite"). (Quite some things came to git from Cogito anyway. ;-) And well, that's completely natural.) > *1* I said "almost sensible" but it is not meant to blame Pasky. > I think the --exclude mechanism in git-ls-files should be > extended to all
Re: [PATCH 1/1] Tell vim the textwidth is 75.
Dear diary, on Sat, Jul 23, 2005 at 10:41:38AM CEST, I got a letter
where Catalin Marinas <[EMAIL PROTECTED]> told me that...
> Another problem with the template is when one wants a header as well as
> footer (for things like '-*- mode: text; -*-'). Maybe something like
> below would work:
>
> GIT: your header
> @DESCRIPTION@
> GIT: your footer
> GIT: @FILELIST@
>
> where @DESCRIPTION@ is either a blank line for cogito or the existing
> patch description for StGIT. One could also add a 'Signed-...' line when
> the patch is first created (instead of a blank line).
>
> For StGIT, one could add something like @PATCHNAME@ as well.
Great idea.
> > When you merge two projects like Linus did between git.git and
> > gitk, obviously the person who is merging the two is responsible
> > for merging the per-project default configuration and resolving
> > conflicts. This probably should be overridable by individual
> > developers who pull/fetch into their repository by having per-
> > repository configuration.
>
> The problem appears when one upstream maintainer changes the
> configuration, should this be merged again? In this case you can get
> conflicts.
So you resolve them...? If the upstream keeps doing changes frequent
enough and large-scale enough to this becoming annoying, something is
wrong. :-)
> > > That's the thing I didn't like in GNU Arch. You modify the file ignoring
> > > rules for example and the change will be included in the next commit.
> > > You could only get some defaults when cloning a repository, otherwise
> > > once you have different preferences from the repository's maintainer,
> > > you start getting conflicts in the config files.
> >
> > That's why I suggested to have "_git" (project wide default)
> > separate from $GIT_DIR/info (repository owner's discretion), the
> > latter overriding the former.
>
> That's OK with one issue - git should be able to exclude _git when
> generating a diff between 2 trees, unless one can enforce the _git/*
> files to be read-only.
Why? I think those meta-information is important too, and if it differs,
I want to see it in the diff. Oh, now I see what you mean - to
optionally exclude it. That would be nice, having --exclude in
common diff options.
> Another option would be to have .git/info/ and, with cogito for
> example, .git/info/origin should always be pulled, even if the local
> files were modified. You would override these settings
> in .git/info/master. The problem is to define the branches order in
> which the settings are read.
Yes, and you may be pulling from multiple branches. I would keep
.git/info simple and single-instanced. If you want your stuff to
propagate to others, put it to .gitinfo/.
> > > Again, having Porcelain specific options mixed in the same file might
> > > lead to some confusion among users.
> >
> > True. We need to be careful.
>
> This could be avoided by using ini-like files (well, easy to read in
> Python) and have [git] (for the common things like author name),
> [cogito], [stgit] etc. sections.
Now if it is going to look like this, I think separate files would be
much more practical, more effective and likely simpler for the user as
well. For Cogito-specific stuff, the user can well dive into
Cogito-specific configuration files, I think. (Well, there's none now;
there is .cgrc but that only contains default options for Cogito
commands and will stay so; I plan ~/.cg/cogito.conf or something.
Actually, perhaps the Git configuration file should be ~/.git/git.conf -
it looks cool, doesn't it?)
> The problem is how much similar we want the Porcelains to be regarding
> the settings and the templates. For StGIT, it is much simpler to have
> something like '%(FILELIST)s' rather than '@FILELIST@' in a template but
> I have not problem with switching to a common syntax. But we should see
> what can easily be changed.
I chose @FILELIST@ only since it is a common convention to have this as
rewrite placeholders, and I think it's more visually clear than
%(FILELIST). Were you insisting on the second syntax, I wouldn't have
%any problem switching, though. Cogito does no @@ rewriting yet.
> I will write a list with what files StGIT uses and where they are placed
> and we can agree on a structure. I think the .git/ directory usage is
> more important to be clarified than having a common {git,cogito,stgit}rc
> file.
Agreed. What Cogito uses:
.git/author Default author information in format
Person Name <[EMAIL PROTECTED]>
.git/branch-name
Symbolic name of the branch of this repository.
This is purely descriptive, does not need to be
unique and is used only in commit-post. I need
to distinguish commits done in git-pb and Cogito
so that's the contents of this file in those two
repositories. Quite ad-hoc and deserves a better
Re: cg-init find error message on empty project directory
Dear diary, on Wed, Jul 13, 2005 at 06:47:43AM CEST, I got a letter where Jerry Seutter <[EMAIL PROTECTED]> told me that... > When I run cg-init on an empty directory, it displays the following output: > > $ cg-init > defaulting to local storage area > find: *: No such file or directory > Committing initial tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904 > Committed as d25f00309e336884854de8cab8ab9e819294bb83. > > Is the find error message supposed to be displayed? Nope. Thanks for the report, it has been fixed recently. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
Dear diary, on Tue, Jul 12, 2005 at 11:07:43AM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > If you block certain operations while you have seeked to non-top > anyway, wouldn't it be cleaner to have .git/seeked-to that > records the commit ID you are at, which at the same time > indicates that you are in a special situation, and not touching > HEAD at all? Then .git/HEAD will always have that line of > development information. > > Well, that was half tongue-in-cheek suggestion; I have a feeling > that you may feel it is a bit too late to change this kind of > thing easily. The thing is, _everything_ assumes .git/HEAD is the current commit checked out in the index. All the Cogito (that wouldn't be hard to change at all), all the other Porcelains, the core GIT tools. So changing that would be difficult and it's much easier this way. > But if we are going to agree on using .git/head-name, I'd rather > see it exist all times, so that cat "$GIT_DIR/head-name" would > always tell us which branch we are working in. After some thought, I like Linus' approach more now, having head-name only when it's really necessary. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should cg-mkpatch output be usable with cg-patch?
Dear diary, on Sun, Jul 24, 2005 at 07:50:18PM CEST, I got a letter where Wolfgang Denk <[EMAIL PROTECTED]> told me that... > In message <[EMAIL PROTECTED]> you wrote: > > > > > I wander what I should do with "cg-mkpatch" generated output; I had > > > the impression that this should be usable with "cg-patch", but these > > > are incompatible with each other. > > > > They certainly aren't. > > Is this a problem with the current implementation, or intentional? Implementation. Should be fixed now, after rewriting part of it. ;-) > > The message is surely confusing, but appeared to be rather corner-casy > > and after I imagined the required complexity of filtering this, I > > decided to spend my time on something more useful for the time being. :) > > I don't think this is a corner case. I think it is pretty important > to be able to promote permissiong changes. Of course. By the corner case I meant "the external patch tool invoked by cg-patch emits bogus error in case of patch containing only mode changes and nothing else". I wasn't aware that the changes wouldn't apply at all - actually, I was when I was writing the code, but completely forgot about it later. Thanks, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Handover, Make
Dear diary, on Thu, Jul 28, 2005 at 01:08:03AM CEST, I got a letter where Brian O'Mahoney <[EMAIL PROTECTED]> told me that... > First, congratulations Junio, on taking over this stuff, and all the best. > > Second, the killer argument, in the 'Recursive Make ... harmful' is the > basic one that Recursive Makes breaks up the dependancy graph, and > almost guarentees that it is wrong unless you do a lot of work to fix > that artifact. Now git is small enough that make clean; make won't take > too long I think there are basically none dependencies like this, or if they are any, they virtually never break under regular usage. At least I never do make clean and I never saw a rebuild of git to break. I think especially for smaller projects recursive make is just fine and makes maintenance easier, and I think most of the arguments about the dependency graph rarely matter in real projects (especially ones of the size of git). So I'd say, keep it as it is till we can. :-) > but git is also a basis for other layers, so there is good > reason to try to get it right. For what layers? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] "Recursive Make considered harmful"
Dear diary, on Thu, Jul 28, 2005 at 12:07:07AM CEST, I got a letter where A Large Angry SCM <[EMAIL PROTECTED]> told me that... > Junio C Hamano wrote: > >While I do not have strong objections to make the build process > >go faster, it is somewhat disturbing that the Makefile pieces > >maintained in subdirectories need to name things they touch > >using paths that include the subdirectory names. I do not have > >a better alternative to suggest, though... > > For a project the size of Git, is there any real benefit to this change? > > Besides pathing issues, you also have to aware that all identifiers in > the included makefile fragments will be global. > > I don't object to the change but I see it as trading one maintenance > issue for another. I'd also argue that generally, larger files are inherently harder to maintain, and having all the targets for all the subdirectories in a single file sounds nightmarish. (OTOH, by now you probably know that I'm a keep-it-as-local-as-possible junkie.) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
Dear diary, on Wed, Jul 27, 2005 at 02:58:42PM CEST, I got a letter where Josef Weidendorfer <[EMAIL PROTECTED]> told me that... > Hi, Hello, > if I clone a remote head other than master via Cogito with > > cg-clone host:path#remoteHead, > > work on this branch, and try to push back my changes with > > cg-push, > > I get the error > > "pushing to a different head not supported yet". > > As far as I can see, there is no support in core GIT to make this ever work > (at least with get-send-packs), as "git-send-pack" only updates a set of > heads with the same name both locally and remote. Yes. It sucks. :-) > I suppose the best would be to always keep the same head names in cloned > repositories - it seems to be easier to handle for users. Perhaps the only > exception would be "master", as one probably would like to pull masters of > different remote repositories into a local one (without really working on > them). I think that would be quite confusing. I mean, you added a remote "bar" branch under name "foo" by cg-branch-add, but suddenly, branch "bar" appears as well. Worse if you already have a different branch "bar". > Thus, what about the following: Each time a remote head other than master is > cloned, a head with the same name is created locally which is an alias to the > local master. This way, cg-push almost works out of the box. Following patch > implements this behavior. See above. I would much rather see more flexible git-send-pack. Junio, what about changing its [heads]* parameter e.g. to [remotehead[:localhead]]* ? Dear diary, on Thu, Jul 28, 2005 at 03:32:01AM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > Josef Weidendorfer <[EMAIL PROTECTED]> writes: > > > As far as I can see, there is no support in core GIT to make this ever work > > (at least with get-send-packs), as "git-send-pack" only updates a set of > > heads with the same name both locally and remote. > > Yes, it is my understanding that "clone" means to literally > clone, not "pull into an empty repository with renamed head > names", to the core GIT. I do not speak for Pasky, but Cogito's > "clone" seems to have a bit different semantics (which I suspect > is more friendly to the users in many situations). cg-clone serves only for initializing the repository from a remote source initially. > Similarly, "push" to the core GIT (that is what git-send-pack is > about) means performing a subset of "clone" in reverse. This is > primarily to synchronise two repositories owned by a single > person. cg-push aims to serve as a general pushing mechanism, which should work properly even if multiple people push to a single repository. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
Dear diary, on Thu, Jul 28, 2005 at 03:07:01PM CEST, I got a letter where Johannes Schindelin <[EMAIL PROTECTED]> told me that... > Hi, Hello, > On Thu, 28 Jul 2005, Petr Baudis wrote: > > > See above. I would much rather see more flexible git-send-pack. Junio, > > what about changing its [heads]* parameter e.g. to > > [remotehead[:localhead]]* ? > > IMHO this opens the door for shooting in your own foot. Isn't it much too > easy to make a mistake with that syntax? What mistake? > What is so wrong with git-clone not allowing you to name the HEAD > differently? Did you read the preceding discussion? When you are pushing from your master branch to a remote branch, it may well be called different over there. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
Dear diary, on Thu, Jul 28, 2005 at 02:08:07PM CEST, I got a letter where Petr Baudis <[EMAIL PROTECTED]> told me that... > See above. I would much rather see more flexible git-send-pack. Junio, > what about changing its [heads]* parameter e.g. to > [remotehead[:localhead]]* ? Ok, I was thinking backwards about it. I meant [localhead[:remotehead]]*, sorry. :-) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Hello, after skimming through it, I think I completely like what you have shown here. I'm only concerned about this: Dear diary, on Mon, Jul 25, 2005 at 12:49:33AM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > $ cat Documentation/.gitignore > # ignore generated html files, > # except foo.html which is maintained by hand > !foo.html > *.html I think this is wrong, and my brief experiments confirm that. I think that the actually useful semantics of exclusion would be for _subsequent_ exclusions, not preliminary ones. You generally don't say "I never want this ignored, but I want the rest of that ignored", but "I want that ignored, except this". This also gives you more flexibility: *.html !f*.html fo*.html would ignore *.html and fo*.html, but not any other f*.html filenames. But more importantly, .gitignore: *.txt Documentation/.gitignore: !*.txt will not work, which was the whole _point_ of the exclusion. Could we please have this semantics changed for those reasons? Thanks, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Dear diary, on Mon, Jul 25, 2005 at 10:27:36PM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > Linus Torvalds <[EMAIL PROTECTED]> writes: > > > On Mon, 25 Jul 2005, Junio C Hamano wrote: > >> > >> I personally do not have preference either way, but am slightly > >> biased towards the "cumulative" behaviour the patch attempts to > >> implement, which was what Pasky said he wanted to have. > > > > I think that makes sense. > > > > Imagine, for example, that you have separate subdirectory structures for > > Documentation and for source - maybe you'd put the "*.o" rule in the > > source directory, and a "*.1" rule in the Docs subdirectory. > > I imagined it, but it appears to me that this is a bad example. > My understanding of what Catalin and the proposed patch > disagrees is whether the patterns in .gitignore at the top level > should govern files under ppc/ and mozilla-sha1/ subdirectories; > Catalin thinks they should not. They should. If you don't want them take effect in most of the directories, you would add them as ./pattern in the parent directory, while if you want them to take effect in most of the directories, you would exclude them in the ones you don't want the pattern to take effect in (if you accept my proposal for ! semantics change). > What I meant by "cumulative" (now I realize I might have > misunderstood what Pasky wanted to mean by that word, though) > was not just .gitignore in subdirectory being added, but the > effect of patterns being added so far, either from the command > line or by parent directories, last while in the deeper > directories. Yes, that's what I meant. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
Dear diary, on Thu, Jul 28, 2005 at 06:14:17PM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > My gut feeling is that Johannes is right here, at least about > the send-pack side. Storing "master" pulled from a remote under > a name different from the remote is a different story. I do not > have much problem with that. But that means you already have to manage the mapping anyway, with all the burden of configuration items etc. And what if repository A has branch 'foo' and repository B also has branch 'foo'? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
Dear diary, on Thu, Jul 28, 2005 at 06:52:45PM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > Petr Baudis <[EMAIL PROTECTED]> writes: > > > AFAIK the plan is to centralize all the kernel repositories to a single > > one. For that, developers would generally push into branches with name > > different that "master". > > I did not know about that plan, but that is interesting and now > I understand why you think it is important to be able for more > than one person to push into a single repository. For that particular thing, this is only part of the motivation. The much bigger part of the motivation are projects which don't have a central maintainer but where group of people needs to be equal in access to a central repository. That's actually vast majority of larger projects, I think. > How will the namespace of N-hundred branches in that repository > be managed? To avoid collisions, wouldn't there be some > coordination, and there will be branch names there that > everybody agrees that they are owned by you? You could name your branches e.g. "davej/agpgart", "davej/cpufreq", etc. But those proposals of central repository were certainly quite preliminary, and perhaps I overstated saying "the plan is". > At that point, wouldn't it be easier for _you_ (as one kernel > developer who owns such globally unique branch names) to name > your branch you intend to push there the same way in your > working repository as well? And if you are cloning locally or whatever, you have to mention the branch name explicitly. One of the Cogito design bits is that branch name is something local to the repository. When you are adding a branch, the local name you assign it is your private thing repository-wise, and doesn't have to have any correlation to other repositories you might interact width. As I already argued, this helps when you are importing someone else's master as your branch called whatever (obviously not master), and if you have to deal with two remote branches with the same name (such a conflict is bound to happen and bound to be vulnerable to be a huge hassle). That also applies to pushing, you might be pushing to multiple repositories - say you are working on some cool kernel stuff for SuSE, so you might want to push to kernel.org _and_ into the deep bowels of some SuSE kernel infrastructure (whatever - I'm not familiar with those things yet if you are now drooling to get some insight about how this is working in SuSE]. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Unnamed branches
Dear diary, on Thu, Jul 28, 2005 at 08:53:56PM CEST, I got a letter where Josef Weidendorfer <[EMAIL PROTECTED]> told me that... > So why not put the name of the remote repository into the local branch name? > A remote branch "host1:path#branch1" could be named "host1:path#branch1". > The shorthand specified with "cg-add-branch" would be a local alias, i.e. > (cd .git/refs/heads; ln -s host1:path#branch1 mylocalalias) > > I even would find it handy to be able to say > cg-pull host1:path#branch1 > , and > cg-push mylocalbranch host2:path#branch2 > should create the alias "mylocalbranch"="host2:path#branch2" > and create a entry in .git/branches. This is a sensible argument, and I initially disallowed this mainly to save some work. ;-) But I agree that something like this would be nice. The issues: * How to name the unnamed branches? You need some way to normalize URLs like http://www.kernel.org/pub/s%63m//cogito/ to something which is unique for a given location (http://www.kernel.org/pub/scm/cogito) and usable as filename - at least substituting the slashes for something, like underscores, and encoding underscored by % sequences. * Have all named remote branches as symlinks to their URLs (thus effectively also eliminating the need for .git/branches/), or keep them as they are? One disadvantage of the symlinks is that the refs/ directory would become quite messy. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
Dear diary, on Thu, Jul 28, 2005 at 05:56:21PM CEST, I got a letter where Johannes Schindelin <[EMAIL PROTECTED]> told me that... > Hi, Hello, > On Thu, 28 Jul 2005, Petr Baudis wrote: > > > Dear diary, on Thu, Jul 28, 2005 at 03:07:01PM CEST, I got a letter > > where Johannes Schindelin <[EMAIL PROTECTED]> told me that... > > > > > On Thu, 28 Jul 2005, Petr Baudis wrote: > > > > > > > See above. I would much rather see more flexible git-send-pack. Junio, > > > > what about changing its [heads]* parameter e.g. to > > > > [remotehead[:localhead]]* ? > > > > > > IMHO this opens the door for shooting in your own foot. Isn't it much too > > > easy to make a mistake with that syntax? > > > > What mistake? > > To mix up different branches. With that syntax you can easily push changes > onto the wrong head. How? Only when you explicitly specify the remote head. When you're explicit, you ought to know what are you doing. > I might well be wrong here, but I think the most common usage for git-push > is to update a public repository, which is done by one or just a few > maintainer(s), in which case it is no problem to enforce > localhead=remotehead. BTW, this whole multihead mess applies only to Jeffs > anyway :-) AFAIK the plan is to centralize all the kernel repositories to a single one. For that, developers would generally push into branches with name different that "master". > I just do not see a high demand for mappings of remote and local HEAD > names, but rather a high potential of making mistakes (after all, it is > not the machine which makes mistakes, it's the human operator). If you fear making mistakes, better use something which attempts to do some babysitting for you, like Cogito. ;-) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
Dear diary, on Sat, Jul 23, 2005 at 12:27:31PM CEST, I got a letter where Catalin Marinas <[EMAIL PROTECTED]> told me that... > > Agreed. What Cogito uses: > > > > .git/author Default author information in format > > Person Name <[EMAIL PROTECTED]> > > What about .git/committer? This is useful if I do a commit at work and I > want the repository to have my gmail address. The committer field generally identifies the committer "physically", and isn't usually overriden. You'll find <[EMAIL PROTECTED]> in my committer field, e.g. > > .git/branch-name > > Symbolic name of the branch of this repository. > > Isn't this the same as $(readlink .git/HEAD), with some trimming? No, that is something totally separate from the usual concepts of branches and repositories, designed to make it possible to distinguish between repositories etc. from the outside of the system. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
Dear diary, on Fri, Jul 29, 2005 at 04:24:40AM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > Petr Baudis <[EMAIL PROTECTED]> writes: > > > One of the Cogito design bits is that branch name is something local to > > the repository. When you are adding a branch, the local name you assign > > it is your private thing repository-wise, and doesn't have to have any > > correlation to other repositories you might interact width. > > I do not disagree with that. I think branch name is mostly a > local matter. However, I happen to think that two repositories > you use send-pack (not clone which uses completely different > protocol) to sync one from the other are semantically equivalent > ones, except that the destination may be a strict subset. I > think of it as "a copy I throw at a public place to show what I > have in my private repository I work in", so,... Aha, so it seems our problem is hopefully only in terminology, great. So, what do you mean by "clone" here? And what command should I use for pushing then? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
Dear diary, on Thu, Jul 28, 2005 at 10:14:35PM CEST, I got a letter where Johannes Schindelin <[EMAIL PROTECTED]> told me that... > Hi, Hello, > Naming the remote HEAD differently than the local HEAD is just *wrong* > when you want to push back to them. But you might not know that in advance. That's one of they key points of the distributed systems, after all - when you are cloning, you needn't know in advance that you will want to do local commits, and don't need upstream approval. You also might not know in advance that you will want to push them back. Sure, distributed systems are more complicated. If you don't like complicated things, there's always RCS. ;-) > The only sane way if you have to have different local and remote HEADs > that I can think of, would be to allow only the current local active HEAD > to be pushed to a certain remote HEAD (preferably identified by a file in > .git/branches). Well, but (if I understand you correctly) that was always the _point_. It's what I was talking about all the time. :-) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
Dear diary, on Thu, Jul 28, 2005 at 11:13:38PM CEST, I got a letter
where Matthias Urlichs <[EMAIL PROTECTED]> told me that...
> Then, you'd kill porcelain writers who don't verify that the old head is
> a(n indirect) parent of the new one. ;-)
send-pack.c:
if (!ref_newer(new_sha1, ref->old_sha1)) {
error("remote '%s' isn't a strict parent of local", name);
continue;
}
"git-core: Making life nice for Porcelains."
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Dear diary, on Thu, Jul 28, 2005 at 09:25:45PM CEST, I got a letter where Matthias Urlichs <[EMAIL PROTECTED]> told me that... > Hi, A Large Angry SCM wrote: > > > So you're arguing for "last match wins" versus "first match wins". I, > > personally, find the former more natural and easier to debug by hand. > > You know, up until five minutes ago, I thought so too. So is the Large Angry SCM agreeing with me or not? I wrote long reply to his mail, then reread what he wrote again, and decided that he is _agreeing_ with me and you that "last match wins" is better. :-) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Dear diary, on Fri, Jul 29, 2005 at 07:04:36AM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > * When checking a file to see if it is excluded, we first look >at "exclude-from patterns" list, then "per directory >patterns" list, and then "command line patterns list", in >that order. The last match wins [*1*]. Hmm. What about just excluding the files according to the order of parameters on the command line? Here, the question is whether the GIT Core tools should provide full flexibility and friendness to custom use, or rather serve as tighter unifying layer for the porcelains, enforcing certain conventions. That's up to you to decide, obviously, but perhaps someone will want to use the exclude mechanisms for something else than the "classic" other files ignoring stuff, and generally more flexibility might be better. So I'd argue for codifying those conventions at the level of the porcelain users and not enforcing them in git-ls-files itself. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] "Recursive Make considered harmful"
Dear diary, on Fri, Jul 29, 2005 at 09:31:34AM CEST, I got a letter where Sam Ravnborg <[EMAIL PROTECTED]> told me that... > > > While I do not have strong objections to make the build process > > > go faster, it is somewhat disturbing that the Makefile pieces > > > maintained in subdirectories need to name things they touch > > > using paths that include the subdirectory names. I do not have > > > a better alternative to suggest, though... > > If the goal is to speed up the build process the only sane way is to fix > the dependencies. In kbuild fixdep is used to parse the .c file and it > locates all references to .h files (recursive) and also detects any > usage of CONFIG_ symbols. > This part should be relative straightforward to include in git. FWIW, I made tiny "build system" (inspired by kconfig) for smaller projects I work on: http://pasky.or.cz/~pasky/dev/tunneler/co/Makefile http://pasky.or.cz/~pasky/dev/tunneler/co/Makefile.lib http://pasky.or.cz/~pasky/dev/tunneler/co/client/Makefile Perhaps someone might find that a nice base for further hacking. It generally appears to work pretty well in practice, although the automatic dependency tracking might not be perfect. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
Dear diary, on Fri, Jul 29, 2005 at 09:48:57AM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > Petr Baudis <[EMAIL PROTECTED]> writes: > > > Aha, so it seems our problem is hopefully only in terminology, great. > > > > So, what do you mean by "clone" here? And what command should I use for > > pushing then? > > Notice I never used the word "clone" in what I said. > > However, I happen to think that two repositories > > you use send-pack (not _CLONE_ which uses completely different > > protocol) (emphasis mine ;-) > Now, A may happen to be on my home machine and B may happen be > on my notebook, meaning the owner of A and B are both myself. > But even in that case I would still work by "pulling from A" > when I am on B, and "pulling from B" when I am on A. In other > words, "pulling" is the only patch flow mechanism I would use. I use cg-push on my notebook, given that the notebook might not happen to have public IP address in some cases, or might be behind some corporate firewall, or that I'm lazy to ssh to my home machine in order to pull. > Pushing is only for publication and I treat it as just a > GIT-aware rsync/mirror, nothing more. I have a feeling that > your workflow is different and you plan to use both push and > pull for normal patch flows. This distinction is probably where > the disagreement comes from. Exactly. I want much more freedom in pushing, the only requirement being that "the to-be-replaced remote head is ancestor of the to-be-pushed local head". I think (am I wrong?) git-send-pack localhead:remotehead would work just fine for me, the only thing I need is the support for different local and remote head names. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Dear diary, on Fri, Jul 29, 2005 at 10:24:54AM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > In the meantime, the current one is clearly broken as you > pointed out, so let's replace it with the updated "generic rule > with the following exceptions" one. That's fine by me. I would only like to ask the Porcelain authors to keep their git-ls-files exclude parameters order matching the internal ordering so that when we indeed change it in the future to follow the commandline order, the Porcelains won't break. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cg-restore - restoring modified files
Umm. I just discovered a portion of mailing list I somehow completely missed. :/ Sorry for the delayed replies. Dear diary, on Wed, Jun 15, 2005 at 03:45:21AM CEST, I got a letter where Pavel Roskin <[EMAIL PROTECTED]> told me that... > Hello! Hi, > I believe the documented behavior of cg-restore is inconsistent. > > "Restore given files to their original state. Without any parameters, it > recovers any files removed locally whose removal was not recorded by > `cg-rm`." > > I interpret it that cg-restore without arguments restores removed files > but not modified ones. > > "If passed a set of file names, it restores those files to their state > as of the last commit (including bringing files removed with cg-rm back > to life; FIXME: does not do that part yet)." > > I interpret it that cg-restore with arguments restores both removed and > modified files. > > Maybe we need an option whether to restore modified files? Or maybe > they should always be restored (I think it would more consistent)? Then > the help text should be more clear about modified files. > > The actual behavior is that modified files are never restored. We need > "-f" option for git-checkout-cache to overwrite existing files, and it's > not used whether the filenames are specified or not. I wanted to send a > patch, but after reading help I'm not sure what exactly cg-restore is > supposed to do. in the meantime, I actually implemented the -f option. Now I agree that cg-rm'd files should indeed be restored only when -f is passed. Not a big deal yet since we don't remove them at all now. :-) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Bits from git-pb
Hi, those two bits were long kept local to git-pb. You can either apply the patches or pull: www.kernel.org/pub/scm/cogito/git-pb.git The bits are mostly cosmetic but I want to get rid of them. :-) I'd like to know what to do with the git-pb branch in the future. Based on what do you think, I can either: (i) Keep the git-pb branch polished and nice-to-merge, if you want to pull from it. (ii) Keep the git-pb branch polished and nice-to-merge and rebase it regularily if you don't want loong edges in your history graph, but want to pull from it. (ii) Do wild things in the git-pb branch and send you patches. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Trivial tidyups
Simple whitespace-related tidyups ensuring style consistency.
This is carried over from my old git-pb branch.
Signed-off-by: Petr Baudis <[EMAIL PROTECTED]>
---
commit 83b1762040b111b4736d108cd91b8a9d75aad3a9
tree e07192546e9bd6a972e3945dd941fc7a29ec1a4b
parent d854f783af2a441827d66b4b70e9d0d9e3434b15
author Petr Baudis <[EMAIL PROTECTED]> Sat, 23 Jul 2005 00:21:48 +0200
committer Petr Baudis <[EMAIL PROTECTED]> Sat, 23 Jul 2005 00:21:48 +0200
Documentation/git-write-tree.txt |3 +--
git-merge-one-file-script|7 +++
write-tree.c |4 ++--
3 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-write-tree.txt b/Documentation/git-write-tree.txt
--- a/Documentation/git-write-tree.txt
+++ b/Documentation/git-write-tree.txt
@@ -9,8 +9,7 @@ git-write-tree - Creates a tree from the
SYNOPSIS
-'git-write-tree'
- [--missing-ok]
+'git-write-tree' [--missing-ok]
DESCRIPTION
---
diff --git a/git-merge-one-file-script b/git-merge-one-file-script
--- a/git-merge-one-file-script
+++ b/git-merge-one-file-script
@@ -22,11 +22,10 @@ case "${1:-.}${2:-.}${3:-.}" in
#
"$1.." | "$1.$1" | "$1$1.")
echo "Removing $4"
- if test -f "$4"
- then
+ if test -f "$4"; then
rm -f -- "$4"
fi &&
- exec git-update-cache --remove -- "$4"
+ exec git-update-cache --remove -- "$4"
;;
#
@@ -62,7 +61,7 @@ case "${1:-.}${2:-.}${3:-.}" in
# We reset the index to the first branch, making
# git-diff-file useful
- git-update-cache --add --cacheinfo "$6" "$2" "$4"
+ git-update-cache --add --cacheinfo "$6" "$2" "$4"
git-checkout-cache -u -f -- "$4" &&
merge "$4" "$orig" "$src2"
ret=$?
diff --git a/write-tree.c b/write-tree.c
--- a/write-tree.c
+++ b/write-tree.c
@@ -89,14 +89,14 @@ int main(int argc, char **argv)
int entries = read_cache();
unsigned char sha1[20];
- if (argc==2) {
+ if (argc == 2) {
if (!strcmp(argv[1], "--missing-ok"))
missing_ok = 1;
else
die("unknown option %s", argv[1]);
}
- if (argc>2)
+ if (argc > 2)
die("too many options");
if (entries < 0)
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Unify usage strings declaration
All usage strings are now declared as static const char [].
This is carried over from my old git-pb branch.
Signed-off-by: Petr Baudis <[EMAIL PROTECTED]>
---
commit 1e02de8f49a8fca696b3cb363545fad3c98fd662
tree feee1ccdea90d33fae2bf41621a876c5aa2ecfe5
parent 83b1762040b111b4736d108cd91b8a9d75aad3a9
author Petr Baudis <[EMAIL PROTECTED]> Sat, 23 Jul 2005 00:30:06 +0200
committer Petr Baudis <[EMAIL PROTECTED]> Sat, 23 Jul 2005 00:30:06 +0200
checkout-cache.c |2 +-
commit-tree.c|2 +-
diff-cache.c |2 +-
diff-files.c |2 +-
diff-helper.c|2 +-
diff-stages.c|2 +-
diff-tree.c |2 +-
hash-object.c|2 +-
local-pull.c |2 +-
ls-files.c |2 +-
ls-tree.c|2 +-
read-tree.c |2 +-
ssh-push.c |2 +-
tar-tree.c |2 +-
test-delta.c |2 +-
var.c|2 +-
verify-pack.c|2 +-
17 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/checkout-cache.c b/checkout-cache.c
--- a/checkout-cache.c
+++ b/checkout-cache.c
@@ -75,7 +75,7 @@ static int checkout_all(void)
return 0;
}
-static const char *checkout_cache_usage =
+static const char checkout_cache_usage[] =
"git-checkout-cache [-u] [-q] [-a] [-f] [-n] [--prefix=] [--]
...";
int main(int argc, char **argv)
diff --git a/commit-tree.c b/commit-tree.c
--- a/commit-tree.c
+++ b/commit-tree.c
@@ -64,7 +64,7 @@ static void check_valid(unsigned char *s
#define MAXPARENT (16)
static unsigned char parent_sha1[MAXPARENT][20];
-static char *commit_tree_usage = "git-commit-tree [-p ]* <
changelog";
+static const char commit_tree_usage[] = "git-commit-tree [-p ]* <
changelog";
static int new_parent(int idx)
{
diff --git a/diff-cache.c b/diff-cache.c
--- a/diff-cache.c
+++ b/diff-cache.c
@@ -163,7 +163,7 @@ static void mark_merge_entries(void)
}
}
-static char *diff_cache_usage =
+static const char diff_cache_usage[] =
"git-diff-cache [-m] [--cached] "
"[] [...]"
COMMON_DIFF_OPTIONS_HELP;
diff --git a/diff-files.c b/diff-files.c
--- a/diff-files.c
+++ b/diff-files.c
@@ -6,7 +6,7 @@
#include "cache.h"
#include "diff.h"
-static const char *diff_files_usage =
+static const char diff_files_usage[] =
"git-diff-files [-q] "
"[] [...]"
COMMON_DIFF_OPTIONS_HELP;
diff --git a/diff-helper.c b/diff-helper.c
--- a/diff-helper.c
+++ b/diff-helper.c
@@ -20,7 +20,7 @@ static void flush_them(int ac, const cha
diff_flush(DIFF_FORMAT_PATCH, '\n');
}
-static const char *diff_helper_usage =
+static const char diff_helper_usage[] =
"git-diff-helper [-z] [-O] [-S] [--pickaxe-all]
[...]";
int main(int ac, const char **av) {
diff --git a/diff-stages.c b/diff-stages.c
--- a/diff-stages.c
+++ b/diff-stages.c
@@ -17,7 +17,7 @@ static int diff_break_opt = -1;
static const char *orderfile = NULL;
static const char *diff_filter = NULL;
-static char *diff_stages_usage =
+static const char diff_stages_usage[] =
"git-diff-stages [] [...]"
COMMON_DIFF_OPTIONS_HELP;
diff --git a/diff-tree.c b/diff-tree.c
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -395,7 +395,7 @@ static int diff_tree_stdin(char *line)
return diff_tree_commit(commit, line);
}
-static char *diff_tree_usage =
+static const char diff_tree_usage[] =
"git-diff-tree [--stdin] [-m] [-s] [-v] [--pretty] [-t] "
"[] "
COMMON_DIFF_OPTIONS_HELP;
diff --git a/hash-object.c b/hash-object.c
--- a/hash-object.c
+++ b/hash-object.c
@@ -21,7 +21,7 @@ static void hash_object(const char *path
printf("%s\n", sha1_to_hex(sha1));
}
-static const char *hash_object_usage =
+static const char hash_object_usage[] =
"git-hash-object [-t ] [-w] ...";
int main(int argc, char **argv)
diff --git a/local-pull.c b/local-pull.c
--- a/local-pull.c
+++ b/local-pull.c
@@ -101,7 +101,7 @@ int fetch_ref(char *ref, unsigned char *
return 0;
}
-static const char *local_pull_usage =
+static const char local_pull_usage[] =
"git-local-pull [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [-l] [-s]
[-n] commit-id path";
/*
diff --git a/ls-files.c b/ls-files.c
--- a/ls-files.c
+++ b/ls-files.c
@@ -285,7 +285,7 @@ static void show_files(void)
}
}
-static const char *ls_files_usage =
+static const char ls_files_usage[] =
"git-ls-files [-z] [-t]
(--[cached|deleted|others|stage|unmerged|killed])* "
"[ --ignored [--exclude=] [--exclude-from=) ]";
diff --git a/ls-tree.c b/ls-tree.c
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -208,7 +208,7 @@ static int list(char **path)
return err;
}
-static const char *ls_tree_usage =
+static const char ls_tree_usage[] =
"git-ls-tree [-d] [-r] [-z] [path...]";
int main(int argc, char **argv)
diff --git a/read-tree.c
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
Dear diary, on Fri, Jul 29, 2005 at 10:54:07AM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > I however still suspect that you might be spreading chaos under the > name of more flexibility. I'm such a villain! ;-)) > The fact that you can push into it by definition means you have some > control over the other end, and obviously you are in total control on > your end. I do not see why you cannot rename branches where needed so > that whatever you are pushing match. That would also be one less > thing to keep track of for yourself [*1*]. You might get the push access rather lately in the process (this "lazy development privileges granting" is one of the point of distributed VCSes), at point where other people are used to pull from you and renaming your branch locally might mean some trouble. > Yes, I am aware that you brought up the example of pushing to > two separate places, but does it happen in practice that you can > push to two places, and at the same time neither of them > cooperates with you to make it easier for you to work on these > three machines by having the same head names? Yes, they may have incompatible but strict head naming conventions. And wouldn't it be easier to just have different head names rather than forcing to increase administrative load 'n stuff? > [Footnote] > > *1* In a hypothetical situation ``I use branch "b00" in this > repository to do XYZ work but I use branch "b24" in the other > repository for the same XYZ work'', Porcelain can keep track of > mapping between b00:b24 for you, but you still need to keep > track of b00:XYZ and b24:XYZ mapping in your head. I think 95% of the cases will be "master locally, non-master remotely". That's not really that difficult at all. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
Dear diary, on Fri, Jul 29, 2005 at 11:55:52AM CEST, I got a letter
where Catalin Marinas <[EMAIL PROTECTED]> told me that...
> Petr Baudis <[EMAIL PROTECTED]> wrote:
> > The committer field generally identifies the committer "physically", and
> > isn't usually overriden. You'll find <[EMAIL PROTECTED]> in my
> > committer field, e.g.
>
> I thought GIT_COMMITTER_{NAME,EMAIL} were added to be able to override
> the defaults like [EMAIL PROTECTED]
Yes, but IIRC only for rather special cases like recommitting older
commits, importing from other VCSes, etc.
> The latest StGIT snapshot uses, by default, the committer's details
> for the From: line when sending patches by e-mail, assuming that this
> is a valid e-mail address. One can define his own e-mail template and
> use a different From: line but I thought it would be simpler to
> provide some defaults based on this.
Why don't you rather use the GIT_AUTHOR_* variables?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
Dear diary, on Fri, Jul 29, 2005 at 12:57:50PM CEST, I got a letter where Johannes Schindelin <[EMAIL PROTECTED]> told me that... > Hi, Hello, > On Fri, 29 Jul 2005, Petr Baudis wrote: > > > You might get the push access rather lately in the process (this "lazy > > development privileges granting" is one of the point of distributed > > VCSes), at point where other people are used to pull from you and > > renaming your branch locally might mean some trouble. > > I still do not get it. What is so wrong with > > git-switch-tree remotehead > git-merge master > git-push remoteside remotehead > > which would have the further advantage of documenting what you really did > in the history. How would that document anything normal push wouldn't? > And if you really want to be able to spread chaos in your own head, you > can do something like > > ln -s master .git/refs/heads/remotehead > git-push remoteside remotehead I'd argue that's much more messy and evil than pushing to heads with different names. If you compare what you just proposed with pushing to heads with different names, what's the advantage? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
Dear diary, on Fri, Jul 29, 2005 at 02:26:51PM CEST, I got a letter where Johannes Schindelin <[EMAIL PROTECTED]> told me that... > Hi, > > On Fri, 29 Jul 2005, Petr Baudis wrote: > > > Dear diary, on Fri, Jul 29, 2005 at 12:57:50PM CEST, I got a letter > > where Johannes Schindelin <[EMAIL PROTECTED]> told me that... > > > > > git-switch-tree remotehead > > > git-merge master > > > git-push remoteside remotehead > > > > > > which would have the further advantage of documenting what you really did > > > in the history. > > > > How would that document anything normal push wouldn't? > > git-merge? You have to git-merge anyway if remote head is not your ancestor yet, otherwise the push cannot proceed. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/2] git-merge-cache -q doesn't complain about failing merge program
git-merge-cache reporting failed merge program is undesirable for
Cogito, since it emits its own more appropriate error message in that
case. However, I want to show other possible git-merge-cache error
messages. So -q will just silence this particular error.
Signed-off-by: Petr Baudis <[EMAIL PROTECTED]>
---
There's more of patches to come. All those which are overflowing this
series are in the git-pb branch as well and you'd get them by pulling
it.
commit 8ddefe85adc8e035864be615c87844ef982f4bc6
tree d5e6c49f93d2e4138ad63faa7fcfb893f4843c88
parent 527a155a0400df1af2e1da64fc02f2dd003413a8
author Petr Baudis <[EMAIL PROTECTED]> Fri, 29 Jul 2005 14:52:53 +0200
committer Petr Baudis <[EMAIL PROTECTED]> Fri, 29 Jul 2005 14:52:53 +0200
Documentation/git-merge-cache.txt |9 +++--
merge-cache.c | 23 +++
2 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-merge-cache.txt
b/Documentation/git-merge-cache.txt
--- a/Documentation/git-merge-cache.txt
+++ b/Documentation/git-merge-cache.txt
@@ -9,7 +9,7 @@ git-merge-cache - Runs a merge for files
SYNOPSIS
-'git-merge-cache' [-o] (-a | -- | \*)
+'git-merge-cache' [-o] [-q] (-a | -- | \*)
DESCRIPTION
---
@@ -32,6 +32,11 @@ OPTIONS
returned errors, and only return the error code after all the
merges are over.
+-q::
+ Do not complain about failed merge program (the merge program
+ failure usually indicates conflicts during merge). This is for
+ porcelains which might want to emit custom messages.
+
If "git-merge-cache" is called with multiple s (or -a) then it
processes them in turn only stopping if merge returns a non-zero exit
code.
@@ -40,7 +45,7 @@ Typically this is run with the a script
the RCS package.
A sample script called "git-merge-one-file-script" is included in the
-ditribution.
+distribution.
ALERT ALERT ALERT! The git "merge object order" is different from the
RCS "merge" program merge object order. In the above ordering, the
diff --git a/merge-cache.c b/merge-cache.c
--- a/merge-cache.c
+++ b/merge-cache.c
@@ -5,7 +5,7 @@
static const char *pgm = NULL;
static const char *arguments[8];
-static int one_shot;
+static int one_shot, quiet;
static int err;
static void run_program(void)
@@ -27,10 +27,13 @@ static void run_program(void)
die("unable to execute '%s'", pgm);
}
if (waitpid(pid, &status, 0) < 0 || !WIFEXITED(status) ||
WEXITSTATUS(status)) {
- if (one_shot)
+ if (one_shot) {
err++;
- else
- die("merge program failed");
+ } else {
+ if (quiet)
+ die("merge program failed");
+ exit(1);
+ }
}
}
@@ -97,15 +100,19 @@ int main(int argc, char **argv)
int i, force_file = 0;
if (argc < 3)
- usage("git-merge-cache [-o] (-a |
*)");
+ usage("git-merge-cache [-o] [-q] (-a |
*)");
read_cache();
i = 1;
- if (!strcmp(argv[1], "-o")) {
+ if (!strcmp(argv[i], "-o")) {
one_shot = 1;
i++;
}
+ if (!strcmp(argv[i], "-q")) {
+ quiet = 1;
+ i++;
+ }
pgm = argv[i++];
for (; i < argc; i++) {
char *arg = argv[i];
@@ -122,7 +129,7 @@ int main(int argc, char **argv)
}
merge_file(arg);
}
- if (err)
+ if (err && quiet)
die("merge program failed");
- return 0;
+ return err;
}
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PACKAGERS] Makefile: DESTDIR vs. dest
Hello, git has $dest in its Makefile while Cogito uses $DESTDIR. I'd like to ask the potential users of those variables (probably mostly distribution package maintainers) what's easier for them and what do they prefer, as I would like to unify this. Thanks, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Makefile: COPTS vs CFLAGS
Hello, one more thing - should we keep the $COPTS variable? Most projects (including Cogito) have the C flags controlled by the $CFLAGS variable. What I would propose: -COPTS=-g -O2 -CFLAGS=$(COPTS) -Wall +CFLAGS?=-g -O2 +CFLAGS+=-Wall That is, if user does not specify custom $CFLAGS, default to "-g -O2", and always append -Wall (and more after I'll send my Makefile patches). Opinions? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/2] Remove the explicit Makefile dependencies description
Remove about one gazillion of explicit dependency rules with few lines describing the general dependency pattern and then the exceptions. This noticably shortens the Makefile and makes it easier to touch it. This is part of the Cogito Makefile changes port. Signed-off-by: Petr Baudis <[EMAIL PROTECTED]> --- commit ee84cc0f730f0e744fe8d922b24f6f7ebe31d737 tree 0b3edc11a0eba131788e42768b56ba6ceba32b96 parent 601722751e42dfef8bcd2fe3d6b070b07eb9198e author Petr Baudis <[EMAIL PROTECTED]> Fri, 29 Jul 2005 15:46:40 +0200 committer Petr Baudis <[EMAIL PROTECTED]> Fri, 29 Jul 2005 15:46:40 +0200 Makefile | 74 +++--- 1 files changed, 8 insertions(+), 66 deletions(-) diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -97,8 +97,9 @@ LIB_H += quote.h LIB_OBJS += quote.o LIB_H += diff.h count-delta.h -LIB_OBJS += diff.o diffcore-rename.o diffcore-pickaxe.o diffcore-pathspec.o \ - count-delta.o diffcore-break.o diffcore-order.o +DIFF_OBJS = diff.o diffcore-rename.o diffcore-pickaxe.o diffcore-pathspec.o \ + diffcore-break.o diffcore-order.o +LIB_OBJS += $(DIFF_OBJS) count-delta.o LIB_OBJS += gitenv.o LIB_OBJS += server-info.o @@ -136,75 +137,16 @@ test-delta: test-delta.c diff-delta.o pa git-%: %.c $(LIB_FILE) $(CC) $(CFLAGS) -o $@ $(filter %.c,$^) $(LIBS) -git-update-cache: update-cache.c -git-diff-files: diff-files.c -git-init-db: init-db.c -git-write-tree: write-tree.c -git-read-tree: read-tree.c -git-commit-tree: commit-tree.c -git-cat-file: cat-file.c -git-fsck-cache: fsck-cache.c -git-checkout-cache: checkout-cache.c -git-diff-tree: diff-tree.c -git-rev-tree: rev-tree.c -git-ls-files: ls-files.c -git-check-files: check-files.c -git-ls-tree: ls-tree.c -git-merge-base: merge-base.c -git-merge-cache: merge-cache.c -git-unpack-file: unpack-file.c -git-export: export.c -git-diff-cache: diff-cache.c -git-convert-cache: convert-cache.c -git-http-pull: http-pull.c pull.c -git-local-pull: local-pull.c pull.c -git-ssh-push: rsh.c +git-http-pull: pull.c +git-local-pull: pull.c git-ssh-pull: rsh.c pull.c -git-rev-list: rev-list.c -git-mktag: mktag.c -git-diff-helper: diff-helper.c -git-tar-tree: tar-tree.c -git-hash-object: hash-object.c -git-stripspace: stripspace.c -git-diff-stages: diff-stages.c -git-rev-parse: rev-parse.c -git-patch-id: patch-id.c -git-pack-objects: pack-objects.c -git-unpack-objects: unpack-objects.c -git-verify-pack: verify-pack.c -git-receive-pack: receive-pack.c -git-send-pack: send-pack.c -git-prune-packed: prune-packed.c -git-fetch-pack: fetch-pack.c -git-var: var.c -git-peek-remote: peek-remote.c -git-update-server-info: update-server-info.c -git-build-rev-cache: build-rev-cache.c -git-show-rev-cache: show-rev-cache.c +git-ssh-push: rsh.c git-http-pull: LIBS += -lcurl git-rev-list: LIBS += -lssl -# Library objects.. -blob.o: $(LIB_H) -tree.o: $(LIB_H) -commit.o: $(LIB_H) -tag.o: $(LIB_H) -object.o: $(LIB_H) -read-cache.o: $(LIB_H) -sha1_file.o: $(LIB_H) -usage.o: $(LIB_H) -rev-cache.o: $(LIB_H) -strbuf.o: $(LIB_H) -gitenv.o: $(LIB_H) -entry.o: $(LIB_H) -diff.o: $(LIB_H) diffcore.h -diffcore-rename.o : $(LIB_H) diffcore.h -diffcore-pathspec.o : $(LIB_H) diffcore.h -diffcore-pickaxe.o : $(LIB_H) diffcore.h -diffcore-break.o : $(LIB_H) diffcore.h -diffcore-order.o : $(LIB_H) diffcore.h -epoch.o: $(LIB_H) +$(LIB_OBJS): $(LIB_H) +$(DIFF_OBJS): diffcore.h git-core.spec: git-core.spec.in Makefile sed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > $@ - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/2] Improve the compilation-time settings interface
Describe variables which make itself takes and adjusts compilation accordingly (MOZILLA_SHA1, NO_OPENSSL, PPC_SHA1), and make adding defines more convenient through the $DEFINES variable. $COPTS includes -g as well now and is not overriden if it was already declared in the environment. Also, $CFLAGS is appended to rather than reset, so that if there was already a $CFLAGS environment variable, it's appended to. Some more variables are also made overridable through the environment. Renamed $bin to $bindir which is the name commonly used for this. This is part of the Cogito Makefile changes port. Signed-off-by: Petr Baudis <[EMAIL PROTECTED]> --- commit 601722751e42dfef8bcd2fe3d6b070b07eb9198e tree ebe576c5bd841b4daeb855e49635491c02a322b5 parent 8ddefe85adc8e035864be615c87844ef982f4bc6 author Petr Baudis <[EMAIL PROTECTED]> Fri, 29 Jul 2005 15:45:42 +0200 committer Petr Baudis <[EMAIL PROTECTED]> Fri, 29 Jul 2005 15:45:42 +0200 Makefile | 56 ++-- 1 files changed, 38 insertions(+), 18 deletions(-) diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -1,33 +1,53 @@ -# -DCOLLISION_CHECK if you believe that SHA1's -# 1461501637330902918203684832716283019655932542976 hashes do not give you -# enough guarantees about no collisions between objects ever hapenning. +# Define MOZILLA_SHA1 environment variable when running make to make use of +# a bundled SHA1 routine coming from Mozilla. It is GPL'd and should be fast +# on non-x86 architectures (e.g. PowerPC), while the OpenSSL version (default +# choice) has very fast version optimized for i586. # -# -DUSE_NSEC if you want git to care about sub-second file mtimes and ctimes. -# -DUSE_STDEV if you want git to care about st_dev changing +# Define NO_OPENSSL environment variable if you do not have OpenSSL. You will +# miss out git-rev-list --merge-order. This also implies MOZILLA_SHA1. # -# Note that you need some new glibc (at least >2.2.4) for this, and it will -# BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely randomly -# break unless your underlying filesystem supports those sub-second times -# (my ext3 doesn't). +# Define PPC_SHA1 environment variable when running make to make use of +# a bundled SHA1 routine optimized for PowerPC. + + +# Define COLLISION_CHECK below if you believe that SHA1's +# 1461501637330902918203684832716283019655932542976 hashes do not give you +# sufficient guarantee that no collisions between objects will ever happen. + +# DEFINES += -DCOLLISION_CHECK + +# Define USE_NSEC below if you want git to care about sub-second file mtimes +# and ctimes. Note that you need recent glibc (at least 2.2.4) for this, and +# it will BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely +# randomly break unless your underlying filesystem supports those sub-second +# times (my ext3 doesn't). + +# DEFINES += -DUSE_NSEC + +# Define USE_STDEV below if you want git to care about the underlying device +# change being considered an inode change from the update-cache perspective. + +# DEFINES += -DUSE_STDEV + GIT_VERSION=0.99.2 -COPTS=-O2 -CFLAGS=-g $(COPTS) -Wall +COPTS?=-g -O2 +CFLAGS+=$(COPTS) -Wall $(DEFINES) prefix=$(HOME) -bin=$(prefix)/bin +bindir=$(prefix)/bin # dest= -CC=gcc -AR=ar -INSTALL=install -RPMBUILD=rpmbuild +CC?=gcc +AR?=ar +INSTALL?=install +RPMBUILD?=rpmbuild # # sparse is architecture-neutral, which means that we need to tell it # explicitly what architecture to check for. Fix this up for yours.. # -SPARSE_FLAGS=-D__BIG_ENDIAN__ -D__powerpc__ +SPARSE_FLAGS?=-D__BIG_ENDIAN__ -D__powerpc__ SCRIPTS=git git-apply-patch-script git-merge-one-file-script git-prune-script \ git-pull-script git-tag-script git-resolve-script git-whatchanged \ @@ -57,7 +77,7 @@ PROG= git-update-cache git-diff-files all: $(PROG) install: $(PROG) $(SCRIPTS) - $(INSTALL) -m755 -d $(dest)$(bin) + $(INSTALL) -m755 -d $(dest)$(bindir) $(INSTALL) $(PROG) $(SCRIPTS) $(dest)$(bin) LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o \ - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/2] Reorder Makefile rules
The Makefile rules were massively reordered so that they are actually logically grouped now. Captions were added to separate the sections. No rule contents was touched during the process. Signed-off-by: Petr Baudis <[EMAIL PROTECTED]> --- commit 656a66fe63898954dbc40854dd049dc76eb9b841 tree a5b29a2163c1bbd671a1dc40d0cb6dade3c4aaee parent ee84cc0f730f0e744fe8d922b24f6f7ebe31d737 author Petr Baudis <[EMAIL PROTECTED]> Fri, 29 Jul 2005 17:02:14 +0200 committer Petr Baudis <[EMAIL PROTECTED]> Fri, 29 Jul 2005 17:02:14 +0200 Makefile | 87 +- 1 files changed, 57 insertions(+), 30 deletions(-) diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -43,12 +43,16 @@ AR?=ar INSTALL?=install RPMBUILD?=rpmbuild -# # sparse is architecture-neutral, which means that we need to tell it # explicitly what architecture to check for. Fix this up for yours.. -# SPARSE_FLAGS?=-D__BIG_ENDIAN__ -D__powerpc__ + + +### --- END CONFIGURATION SECTION --- + + + SCRIPTS=git git-apply-patch-script git-merge-one-file-script git-prune-script \ git-pull-script git-tag-script git-resolve-script git-whatchanged \ git-fetch-script git-status-script git-commit-script \ @@ -74,18 +78,12 @@ PROG= git-update-cache git-diff-files git-show-index git-daemon git-var git-peek-remote \ git-update-server-info git-show-rev-cache git-build-rev-cache -all: $(PROG) - -install: $(PROG) $(SCRIPTS) - $(INSTALL) -m755 -d $(dest)$(bindir) - $(INSTALL) $(PROG) $(SCRIPTS) $(dest)$(bin) - -LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o \ -tag.o date.o index.o diff-delta.o patch-delta.o entry.o path.o \ -epoch.o refs.o csum-file.o pack-check.o pkt-line.o connect.o ident.o LIB_FILE=libgit.a LIB_H=cache.h object.h blob.h tree.h commit.h tag.h delta.h epoch.h csum-file.h \ pack.h pkt-line.h refs.h +LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o \ +tag.o date.o index.o diff-delta.o patch-delta.o entry.o path.o \ +epoch.o refs.o csum-file.o pack-check.o pkt-line.o connect.o ident.o LIB_H += rev-cache.h LIB_OBJS += rev-cache.o @@ -122,17 +120,12 @@ endif CFLAGS += '-DSHA1_HEADER=$(SHA1_HEADER)' -$(LIB_FILE): $(LIB_OBJS) - $(AR) rcs $@ $(LIB_OBJS) -check: - for i in *.c; do sparse $(CFLAGS) $(SPARSE_FLAGS) $$i; done -test-date: test-date.c date.o - $(CC) $(CFLAGS) -o $@ test-date.c date.o +### Build rules + +all: $(PROG) -test-delta: test-delta.c diff-delta.o patch-delta.o - $(CC) $(CFLAGS) -o $@ $^ git-%: %.c $(LIB_FILE) $(CC) $(CFLAGS) -o $@ $(filter %.c,$^) $(LIBS) @@ -148,6 +141,47 @@ git-rev-list: LIBS += -lssl $(LIB_OBJS): $(LIB_H) $(DIFF_OBJS): diffcore.h +$(LIB_FILE): $(LIB_OBJS) + $(AR) rcs $@ $(LIB_OBJS) + +doc: + $(MAKE) -C Documentation all + + + +### Testing rules + +test: all + $(MAKE) -C t/ all + +test-date: test-date.c date.o + $(CC) $(CFLAGS) -o $@ test-date.c date.o + +test-delta: test-delta.c diff-delta.o patch-delta.o + $(CC) $(CFLAGS) -o $@ $^ + +check: + for i in *.c; do sparse $(CFLAGS) $(SPARSE_FLAGS) $$i; done + + + +### Installation rules + +install: $(PROG) $(SCRIPTS) + $(INSTALL) -m755 -d $(dest)$(bindir) + $(INSTALL) $(PROG) $(SCRIPTS) $(dest)$(bin) + +install-tools: + $(MAKE) -C tools install + +install-doc: + $(MAKE) -C Documentation install + + + + +### Maintainer's dist rules + git-core.spec: git-core.spec.in Makefile sed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > $@ @@ -163,23 +197,16 @@ dist: git-core.spec git-tar-tree rpm: dist $(RPMBUILD) -ta git-core-$(GIT_VERSION).tar.gz -test: all - $(MAKE) -C t/ all -doc: - $(MAKE) -C Documentation all +backup: clean + cd .. ; tar czvf dircache.tar.gz dir-cache -install-tools: - $(MAKE) -C tools install -install-doc: - $(MAKE) -C Documentation install + +### Cleaning rules clean: rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE) rm -f git-core-*.tar.gz git-core.spec $(MAKE) -C tools/ clean $(MAKE) -C Documentation/ clean - -backup: clean - cd .. ; tar czvf dircache.tar.gz dir-cache - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/2] Support for NO_OPENSSL
Support for completely OpenSSL-less builds. FSF considers distributing GPL
binaries with OpenSSL linked in as a legal problem so this is trouble
e.g. for Debian, or some people might not want to install OpenSSL
anyway. If you
make NO_OPENSSL=1
you get completely OpenSSL-less build, disabling --merge-order and using
Mozilla's SHA1 implementation.
Ported from Cogito.
Signed-off-by: Petr Baudis <[EMAIL PROTECTED]>
---
commit cd2182ac0e0635faeca6467b68decf8ab9625f4c
tree d0c704c203d2319a77cd8fd9ee8fda8adc2d27b4
parent 656a66fe63898954dbc40854dd049dc76eb9b841
author Petr Baudis <[EMAIL PROTECTED]> Fri, 29 Jul 2005 17:42:32 +0200
committer Petr Baudis <[EMAIL PROTECTED]> Fri, 29 Jul 2005 17:42:32 +0200
Makefile |8 +++-
rev-list.c |6 +-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -83,7 +83,7 @@ LIB_H=cache.h object.h blob.h tree.h com
pack.h pkt-line.h refs.h
LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o \
tag.o date.o index.o diff-delta.o patch-delta.o entry.o path.o \
-epoch.o refs.o csum-file.o pack-check.o pkt-line.o connect.o ident.o
+refs.o csum-file.o pack-check.o pkt-line.o connect.o ident.o
LIB_H += rev-cache.h
LIB_OBJS += rev-cache.o
@@ -105,6 +105,12 @@ LIB_OBJS += server-info.o
LIBS = $(LIB_FILE)
LIBS += -lz
+ifndef NO_OPENSSL
+ LIB_OBJS += epoch.o
+else
+ CFLAGS += '-DNO_OPENSSL'
+ MOZILLA_SHA1=1
+endif
ifdef MOZILLA_SHA1
SHA1_HEADER="mozilla-sha1/sha1.h"
LIB_OBJS += mozilla-sha1/sha1.o
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -537,9 +537,13 @@ int main(int argc, char **argv)
sort_in_topological_order(&list);
show_commit_list(list);
} else {
+#ifndef NO_OPENSSL
if (sort_list_in_merge_order(list, &process_commit)) {
- die("merge order sort failed\n");
+ die("merge order sort failed\n");
}
+#else
+ die("merge order sort unsupported, OpenSSL not linked");
+#endif
}
return 0;
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/2] Build commands through object files
Separate the process of building the commands to compilation and linkage. This makes it more consistent with the library objects, is the traditional thing to do, and significantly speeds up the subsequent rebuilds, especially for us the people who develop git on 300MHz notebooks. Ported from Cogito. Signed-off-by: Petr Baudis <[EMAIL PROTECTED]> --- commit 02074521a74483bec941ceacea35f92b485ebd48 tree b08deb01bab982b846b5757943571d0c39b9ba76 parent cd2182ac0e0635faeca6467b68decf8ab9625f4c author Petr Baudis <[EMAIL PROTECTED]> Fri, 29 Jul 2005 19:20:28 +0200 committer Petr Baudis <[EMAIL PROTECTED]> Fri, 29 Jul 2005 19:20:28 +0200 Makefile | 15 --- 1 files changed, 8 insertions(+), 7 deletions(-) diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -133,13 +133,14 @@ CFLAGS += '-DSHA1_HEADER=$(SHA1_HEADER)' all: $(PROG) -git-%: %.c $(LIB_FILE) - $(CC) $(CFLAGS) -o $@ $(filter %.c,$^) $(LIBS) - -git-http-pull: pull.c -git-local-pull: pull.c -git-ssh-pull: rsh.c pull.c -git-ssh-push: rsh.c +.PRECIOUS: %.o +git-%: %.o $(LIB_FILE) + $(CC) $(CFLAGS) -o $@ $(filter %.o,$^) $(LIBS) + +git-http-pull: pull.o +git-local-pull: pull.o +git-ssh-pull: rsh.o pull.o +git-ssh-push: rsh.o git-http-pull: LIBS += -lcurl git-rev-list: LIBS += -lssl - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/2] Improve the compilation-time settings interface
Dear diary, on Fri, Jul 29, 2005 at 05:48:26PM CEST, I got a letter where Petr Baudis <[EMAIL PROTECTED]> told me that... > diff --git a/Makefile b/Makefile > --- a/Makefile > +++ b/Makefile > @@ -1,33 +1,53 @@ > +# Define NO_OPENSSL environment variable if you do not have OpenSSL. You will > +# miss out git-rev-list --merge-order. This also implies MOZILLA_SHA1. Sorry for this, I didn't realize until much later that NO_OPENSSL wasn't actually in git yet. I hope I won't have to resend the patches just because of this. :-) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Last mile to 1.0?
Dear diary, on Sat, Jul 16, 2005 at 07:46:00PM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > I do not know what release plan Linus has in mind, and also > expect things to be quieter next week during OLS and kernel > summit, but I think we are getting really really close. > > Here are the things I think we would want to see before we hit > 1.0: > > - Remaining feature enhancements and fixes. > >- Anonymous pull from packed archives on remote sites via > non-rsync, non-ssh transport. Many people are behind > corporate firewalls that do not pass anything but outgoing > http(s) and some do not even pass outgoing ssh. The recent > addition of git-daemon by Linus would greatly alleviate the > situation, but we may also end up wanting something HTTP > reachable. I hope to get to it tomorrow but it now occurred to me that I don't know when do you actually want to release 1.0 and I think it's crucial for it to support some sensible HTTP transport - I saw some scripts going in etc, but what's its current state? Is it usable? Note that I really _loved_ the Daniel's tools while they lasted. What I loved most about them was that they really only pulled objects I needed and not a single worthless one. Does the current HTTP transport share this property? > - Publicity. I would be very happy to see somebody with good >writing and summarizing skills to prepare an article to be >published on LWN.NET to coincide with the 1.0 release. An >update to GIT traffic would also be nice. Note that I also want to setup a simple "proof-of-concept" GIT homepage tomorrow. Well, write it, where it should be hosted can be worked out later and I have places for it to reside at for now. (Suggestions for final hosting welcome. In reality, how nice (and persistent) the URL gets is probably the only thing that really matters. My attempt will live at http://git.or.cz/.) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Bits from git-pb
Dear diary, on Fri, Jul 29, 2005 at 10:58:19AM CEST, I got a letter where Petr Baudis <[EMAIL PROTECTED]> told me that... > (i) Keep the git-pb branch polished and nice-to-merge, if you want to > pull from it. > > (ii) Keep the git-pb branch polished and nice-to-merge and rebase it > regularily if you don't want loong edges in your history graph, but > want to pull from it. > > (iii) Do wild things in the git-pb branch and send you patches. So I assume (iii) holds? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git: problems in read-only trees
Dear diary, on Wed, Aug 03, 2005 at 09:42:41AM CEST, I got a letter where Wolfgang Denk <[EMAIL PROTECTED]> told me that... > Hello, > > sometimes I have to work in trees for which I have only read > permissions; cogito has problems then - for example: > > -> cg-diff > fatal: unable to create new cachefile > fatal: unable to create temp-file > > It would be nice if there was at least a way to specify some TMPDIR > instead of the current directory in such a situation. This is a bug in git-diff-* (producing the second error message; the first error message means failed git-update-cache --refresh but that isn't fatal). Any reason why prep_temp_blob() works in . instead of $TMPDIR? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-local-pull?
Dear diary, on Wed, Aug 03, 2005 at 07:11:00PM CEST, I got a letter where [EMAIL PROTECTED] told me that... > IIRC, git-local-pull still doesn't work for a packed source repository, > because it doesn't include the possibility of copying a pack (or > extracting an object) if the requested object is in a pack. > > I can probably fix it if anyone cares, but it's not something I use > personally, so I don't know if it's worthwhile. It should probably be > removed if we don't fix it, since it will fail on any popular repository > at this point. I want to use it in Cogito again, since copying everything obviously sucks and I want to hardlink, so repacking is not a solution either. Didn't you post some patches to fix this long time ago, actually? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] daemon.c: squelch error message from EINTR
Dear diary, on Wed, Aug 03, 2005 at 08:20:01AM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > I am not sure if this is the right fix, and I have not received > an answer from the original author of the patch. I would > appreciate help from the folks on the list who are familiar with > the networking. I think it's fine. EINTR means it got a signal while waiting, it might be worthwhile checking by strace what signal it actually was - one thing coming on my mind is SIGPIPE or so, but I barely saw the code. Anyway, just sticking your hand in sand if you see this is probably fine. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Status of git.git repository
Dear diary, on Sat, Jul 30, 2005 at 04:11:48AM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > By the way, do people mind my posting my own patches to the > list? I keep the same in the "pu" (proposed updates) branch, so > if the list readers think I am just adding noise to the list > traffic, I would stop doing so, and instead just invite > interested people to browse the "pu" branch. Browsing the "pu" branch may be bothersome and you won't ensure that the related discussion stays in a single thread, and posting the patches here makes them generally more visible, so I think it's a good idea to keep doing so. Cogito (and Git itself as well, I guess) does not handle those "volatile" branches well at all - following them is difficult since Cogito will think that you did some local commits and want to do a tree merge. Would anyone consider doing if ref(updatebranch) == ref(master) then merge: always_fastforward else merge: perhaps_treemerge a Bad Thing (tm)? It seems to me that it should do the right thing and never get it wrong. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cogito missing asciidoc.conf?
Dear diary, on Wed, Aug 03, 2005 at 12:40:35AM CEST, I got a letter where Sebastian Kuzminsky <[EMAIL PROTECTED]> told me that... > Or am I missing something? > > The most recent commit to cogito makes the documentation depend on > asciidoc.conf, but it looks like the actual config file was not added. Hm, cg-patch was broken again. Thanks, fixed. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
