* Re: [PATCH] user-manual: Add section on ignoring files
From: Johan Herland @ 2007-05-15 23:31 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <f2dffu$so6$2@sea.gmane.org>
On Wednesday 16 May 2007, Jakub Narebski wrote:
> Johan Herland wrote:
>
> > +A project will often generate files that you do 'not' want to track with git.
> > +This typically includes files generated by a build process or temporary
> > +backup files made by your editor. Of course, 'not' tracking files with git
> > +is just a matter of 'not' calling "git add" on them. But it might be
> > +annoying to have these untracked files automatically showing up in the
> > +output of "git status", in the commit message template, etc.
>
> _And_ ignored files affect globbing and path patterns ("git add ." or
> "git add *.txt"would not add ignored files), and --all options
> ("git commit -a" would not commit changed but ignored files).
Yes, of course. I forgot about that "minor" point...
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] user-manual: Add section on ignoring files
From: Junio C Hamano @ 2007-05-15 23:30 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Randal L. Schwartz
In-Reply-To: <200705160047.52717.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> +[[ignoring-files]]
> +Ignoring files
> +--------------
Looks good ;-).
> +A project will often generate files that you do 'not' want to track with git.
> +This typically includes files generated by a build process or temporary
> +backup files made by your editor. Of course, 'not' tracking files with git
> +is just a matter of 'not' calling "git add" on them. But it might be
> +annoying to have these untracked files automatically showing up in the
> +output of "git status", in the commit message template, etc.
Another point about this annoyance factor is that "git-add ."
does not add files that are excluded.
> +Git therefore provides "exclude patterns" for telling git which files to
> +actively ignore. Exclude patterns are thoroughly explained in the
> +"Exclude Patterns" section of the gitlink:git-ls-files[1] manual page,
> +but the heart of the concept is simply a list of files which git should
> +ignore. Entries in the list may contain globs to specify multiple files,
> +or may be prefixed by "`!`" to explicitly include (un-ignore) a file.
I think you can safely teach the reader that later entries
override the earlier ones here, as you are about to give such an
example just below.
> +The following example should illustrate such patterns:
> +
> +-------------------------------------------------
> +# Lines starting with '#' are considered comments.
> +# Ignore foo.txt.
> +foo.txt
> +# Ignore (generated) html files,
> +*.html
> +# except foo.html which is maintained by hand.
> +!foo.html
> +# Ignore objects and archives.
> +*.[oa]
> +-------------------------------------------------
> +The next question is where to put these exclude patterns so that git can
> +find them. Git looks for exclude patterns in the following files:
> +
> +`.gitignore` files in your working tree:::
> + You may store multiple `.gitignore` files at various locations in your
> + working tree. Each `.gitignore` file is applied to the directory where
> + it's located, including its subdirectories. Furthermore, the
> + `.gitignore` files can be tracked like any other files in your working
> + tree; just do a `git add .gitignore` and commit. `.gitignore` is
> + therefore the perfect place to put exclude patterns that match
> + ignored files that pop up in every copy of your project, such as
> + build output files (e.g. `\*.o`), etc.
... and more importantly, the patterns that are _meant_ to be
shared by all the project participants. I think it is probably
easier to follow if you explain that in-tree .gitignore is not
about personal preference upfront in this section, rather than
saying it in .git/info/exclude section.
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: Shawn O. Pearce @ 2007-05-15 23:29 UTC (permalink / raw)
To: Jan Hudec; +Cc: git
In-Reply-To: <20070515201006.GD3653@efreet.light.src>
Jan Hudec <bulb@ucw.cz> wrote:
> Did anyone already think about fetching over HTTP working similarly to the
> native git protocol?
No work has been done on this (that I know of) but I've discussed
it to some extent with Simon 'corecode' Schubert on #git, and I
think he also brought it up on the mailing list not too long after.
I've certainly thought about adding some sort of pack-objects
frontend into gitweb.cgi for this exact purpose. It is really
quite easy, except for the negotation of what the client has. ;-)
> Than a question is how to implement it. The current protocol is stateful on
> both sides, but the stateless nature of HTTP more or less requires the
> protocol to be stateless on the server.
>
> I think it would be possible to use basically the same protocol as now, but
> make it stateless for server. That is server first sends it's heads and than
> client repeatedly sends all it's wants and some haves until the server acks
> all of them and sends the pack.
I think Simon was talking about doubling the number of haves the
client sends in each request. So the client POSTs initially all
of its current refs; then current refs and their parents; then 4
commits back, then 8, etc. The server replies to each POST request
with either a "send more please" or the packfile.
--
Shawn.
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Johannes Schindelin @ 2007-05-15 23:27 UTC (permalink / raw)
To: David Kågedal; +Cc: git
In-Reply-To: <87sl9ygau1.fsf@morpheus.local>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 544 bytes --]
Hi,
On Mon, 14 May 2007, David Kågedal wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Therefore, I now put all changed files into the index (git add -u),
> > and clean up the files one by one, always checking with "git diff" and
> > "git diff HEAD" what I still have to do.
>
> Why not simply use a temporary branch for this? They're free, and you
> can diff just as easily, if not more. And you don't risk losing it if
> you slip with a command.
Because it is much faster to work with the index?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] user-manual: Add section on ignoring files
From: Jakub Narebski @ 2007-05-15 23:24 UTC (permalink / raw)
To: git
In-Reply-To: <200705160047.52717.johan@herland.net>
Johan Herland wrote:
> +A project will often generate files that you do 'not' want to track with git.
> +This typically includes files generated by a build process or temporary
> +backup files made by your editor. Of course, 'not' tracking files with git
> +is just a matter of 'not' calling "git add" on them. But it might be
> +annoying to have these untracked files automatically showing up in the
> +output of "git status", in the commit message template, etc.
_And_ ignored files affect globbing and path patterns ("git add ." or
"git add *.txt"would not add ignored files), and --all options
("git commit -a" would not commit changed but ignored files).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Fix signedness on return value from xread()
From: Shawn O. Pearce @ 2007-05-15 23:24 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Paolo Teti
In-Reply-To: <200705151439.25871.johan@herland.net>
Johan Herland <johan@herland.net> wrote:
> The return value from xread() is ssize_t.
> Paolo Teti <paolo.teti@gmail.com> pointed out that in this case, the
> signed return value was assigned to an unsigned type (size_t). This patch
> fixes that.
Thanks for fixing this. Its rather embarrassing as:
commit 00be8dcc1aca3c1c1a94b39f0563d30d1fa89290
Author: Sami Farin <safari-kernel@safari.iki.fi>
Date: Tue Apr 24 22:56:02 2007 +0300
fast-import: size_t vs ssize_t
size_t is unsigned, so (n < 0) is never true.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
was applied by me to fix this very bug and I also applied the
patch that created the buggy copy in pack-write.c.
--
Shawn.
^ permalink raw reply
* Re: pull/push inconsistencies
From: Jakub Narebski @ 2007-05-15 23:21 UTC (permalink / raw)
To: git
In-Reply-To: <46a038f90705151553h553ae9d3kc3d43af72f385a42@mail.gmail.com>
Martin Langhoff wrote:
> When tracking several branches from a repo, git-pull does a fetch (of
> all the remote heads) and merges _only the tracking branch currently
> checked out_. That's ok. However, if I checkout another tracking
> branch and issue git-pull, the merge does not happen because git-fetch
> finds nothing new on the remote side. git-pull should merge anyway if
> remotes/origin/<trackinghead> is ahead of the local head.
>
> The workaround is to call git-merge explicitly, but git-pull is
> misleading the user saying "nothing to merge" instead of completing
> the merge.
Strange. This would be regression, but in my experience "git pull" _always_
merges, even if there is nothing to fetch. But I don't have branch to merge
configured...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Add an option to git-ls-tree to display also the size of object
From: Shawn O. Pearce @ 2007-05-15 23:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vy7jpj4lr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Add -l/--long/--size option to git-ls-tree command, which displays
> > object size of an entry after object id (left-justified with minimum
> > width of 7 characters).
>
> Also I suspect that having to show the size of a tree object,
> expressed in terms of the canonical representation, might
> force packv4 aware ls-tree to convert its traversal efficient
> representation to the canonical one only to get its size.
Yes, you are right Junio. In pack v4 we don't know the size of
the canonical representation. We compute it on the fly when its
needed by summing up the lengths of the names of each element in
the tree, so it requires us to expand the delta chain and is thus
O(delta_depth * entry_count) or something like that.
I didn't see this as a huge problem, as the only in-tree caller at
the time that needed the size and did not also want the canonical
representation was the -s flag to cat-file.
So I'm kind of against adding something that would want to print
that canonical representation for every subtree in a parent tree,
as it would make either pack v4 less efficient for that operation
or force it to store the canonical size, for no other good reason.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Add an option to git-ls-tree to display also the size of object
From: Jakub Narebski @ 2007-05-15 23:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7jpj4lr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Add -l/--long/--size option to git-ls-tree command, which displays
> > object size of an entry after object id (left-justified with minimum
> > width of 7 characters).
>
> Not a NAK at all (but not an ACK either yet), but just asking
> questions on some design considerations.
I guess I should use [PATCH/RFC] for this patch...
> * Do these options do different things? If not, why have more
> than one (or two, --long and its shorthand -l)?
The idea was to have output similar (if possible by git-ls-tree
machinery) to 'ls -l' output, hence -l/--long, but actually it is
about --size.
> * Why pad to 7 places? Do we have a similar padding elsewhere?
> Will this ever used by non-scripts? How does this padding
> affect parsers other than Perl that read this information?
Padding is added here to make output more human-readable. And I guess
padding of 7 places is default for 'ls -l'.
But certainly padding is not needed.
> * Does it make sense to show size information when giving a tree
> entry? I realize not having it in the output would make the
> job of the script reading the output a bit harder, but if this
> output is meant also for human consumption I think it would
> not be so interesting and raise a confusion factor.
Giving tree size information is similar to 'ls -l giving size of
directory, and not total size taken by its contents. That would be
better left for git-ls-tree `--du' option :-)
> Also I suspect that having to show the size of a tree object,
> expressed in terms of the canonical representation, might
> force packv4 aware ls-tree to convert its traversal efficient
> representation to the canonical one only to get its size.
It still will be accessible, but perhaps it would be less efficient
with v4 pack. It is I think acceptable that -l needs more CPU (and I/O)
time...
--
Jakub Narebski
Poland
^ permalink raw reply
* pull/push inconsistencies
From: Martin Langhoff @ 2007-05-15 22:53 UTC (permalink / raw)
To: Git Mailing List
I am noticing some UI inconsistencies with pull/push. Not sure where
they are -- and quite busy atm -- if they are in bash I might be able
to hunt them down and fix. In case anyone else cares...
--
When tracking several branches from a repo, git-pull does a fetch (of
all the remote heads) and merges _only the tracking branch currently
checked out_. That's ok. However, if I checkout another tracking
branch and issue git-pull, the merge does not happen because git-fetch
finds nothing new on the remote side. git-pull should merge anyway if
remotes/origin/<trackinghead> is ahead of the local head.
The workaround is to call git-merge explicitly, but git-pull is
misleading the user saying "nothing to merge" instead of completing
the merge.
--
My second issue is that git-push does not update
remotes/<repo>/<headname> so if I do git-push && gitk --all it looks
as if I haven't pushed. Misleading again. :-/
--
Third issue - if I do
# we start with a cloned repo that is in sync with
# its "origin" repo. No local commits to speak of...
# git-fetch brings updates to 3 remote branches - none affecting the current
# checked out branch...
git-fetch
git-commit some/path
git-push
the output of git-push will show _4_ branches being pushed. For some
reason git-push says that it's pushing remotes/origin/branchname ->
origin/branchname for all the branches fetched recently -- and not
modified! I expect only _1_ branch to be named during push - the only
one.
None of the above are showstoppers, but the user feedback of these
commands - the very core workflow for beginners - is quite confusing.
I know how to check that things are correct in spite of the messages,
and by now I trust git internals to do the right thing. But newcomers
are getting some frights over here...
cheers,
martin
^ permalink raw reply
* [PATCH] user-manual: Add section on ignoring files
From: Johan Herland @ 2007-05-15 22:47 UTC (permalink / raw)
To: git; +Cc: Randal L. Schwartz
The todo list at the end of the user manual says that something must be
said about .gitignore. Also, there seems to be a lack of documentation
on how to choose between the various types of ignore files (.gitignore
vs. .git/info/exclude, etc.).
This patch adds a section on ignoring files which try to introduce how
to tell git about ignored files, and how the different strategies
complement eachother.
The syntax of exclude patterns is explained in a simplified manner, with
a reference to git-ls-files(1) which already contains a more thorough
explanation.
Signed-off-by: Johan Herland <johan@herland.net>
---
Writing this section was triggered by Randal L. Schwartz on #git lamenting
the lack of documentation on the difference between .gitignore and
.git/info/exclude. Hope this is what you're looking for, Randal. :)
Documentation/user-manual.txt | 69 +++++++++++++++++++++++++++++++++++++++-
1 files changed, 67 insertions(+), 2 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index a7abeaa..4ca30dd 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1188,6 +1188,73 @@ description. Tools that turn commits into email, for example, use
the first line on the Subject line and the rest of the commit in the
body.
+[[ignoring-files]]
+Ignoring files
+--------------
+
+A project will often generate files that you do 'not' want to track with git.
+This typically includes files generated by a build process or temporary
+backup files made by your editor. Of course, 'not' tracking files with git
+is just a matter of 'not' calling "git add" on them. But it might be
+annoying to have these untracked files automatically showing up in the
+output of "git status", in the commit message template, etc.
+
+Git therefore provides "exclude patterns" for telling git which files to
+actively ignore. Exclude patterns are thoroughly explained in the
+"Exclude Patterns" section of the gitlink:git-ls-files[1] manual page,
+but the heart of the concept is simply a list of files which git should
+ignore. Entries in the list may contain globs to specify multiple files,
+or may be prefixed by "`!`" to explicitly include (un-ignore) a file.
+The following example should illustrate such patterns:
+
+-------------------------------------------------
+# Lines starting with '#' are considered comments.
+# Ignore foo.txt.
+foo.txt
+# Ignore (generated) html files,
+*.html
+# except foo.html which is maintained by hand.
+!foo.html
+# Ignore objects and archives.
+*.[oa]
+-------------------------------------------------
+
+The next question is where to put these exclude patterns so that git can
+find them. Git looks for exclude patterns in the following files:
+
+`.gitignore` files in your working tree:::
+ You may store multiple `.gitignore` files at various locations in your
+ working tree. Each `.gitignore` file is applied to the directory where
+ it's located, including its subdirectories. Furthermore, the
+ `.gitignore` files can be tracked like any other files in your working
+ tree; just do a `git add .gitignore` and commit. `.gitignore` is
+ therefore the perfect place to put exclude patterns that match
+ ignored files that pop up in every copy of your project, such as
+ build output files (e.g. `\*.o`), etc.
+`.git/info/exclude` in your repo:::
+ Exclude patterns in this file are applied to the working tree as a
+ whole. Since the file is not located in your working tree, it does
+ not follow push/pull/clone like `.gitignore` can do. This is therefore
+ the best place to put exclude patterns that you want to keep local
+ to your copy of the repo, such as temporary backups made by your
+ editor (e.g. `\*~`), etc.
+The file specified by the `core.excludesfile` config directive:::
+ By setting the `core.excludesfile` config directive you can tell git
+ where to find more exclude patterns (see gitlink:git-config[1] for
+ more information on configuration options). This config directive
+ can be set in the per-repo `.git/config` file, in which case the
+ exclude patterns will apply to that repo only. Alternatively, you
+ can set the directive in the global `~/.gitconfig` file to apply
+ the exclude pattern to all your git repos. As with the above
+ `.git/info/exclude` (and, indeed, with git config directives in
+ general), this directive does not follow push/pull/clone, but stays
+ local to your repo(s).
+
+[NOTE]
+In addition to the above alternatives, there are git commands that can take
+exclude patterns directly on the command line. See gitlink:git-ls-files[1]
+for an example of this.
+
[[how-to-merge]]
How to merge
------------
@@ -3184,8 +3251,6 @@ Think about how to create a clear chapter dependency graph that will
allow people to get to important topics without necessarily reading
everything in between.
-Say something about .gitignore.
-
Scan Documentation/ for other stuff left out; in particular:
howto's
some of technical/?
--
1.5.1.4
^ permalink raw reply related
* Re: Smart fetch via HTTP?
From: A Large Angry SCM @ 2007-05-15 22:30 UTC (permalink / raw)
To: Jan Hudec; +Cc: git
In-Reply-To: <20070515201006.GD3653@efreet.light.src>
Jan Hudec wrote:
> Hello,
>
> Did anyone already think about fetching over HTTP working similarly to the
> native git protocol?
>
> That is rather than reading the raw content of the repository, there would be
> a CGI script (could be integrated to gitweb), that would negotiate what the
> client needs and then generate and send a single pack with it.
>
> Mercurial and bzr both have this option. It would IMO have three benefits:
> - Fast access for people behind paranoid firewalls, that only let http and
> https (you can tunel anything through, but only to port 443) through.
> - Can be run on shared machine. If you have web space on machine shared
> by many people, you can set up your own gitweb, but cannot/are not allowed
> to start your own network server for git native protocol.
> - Less things to set up. If you are setting up gitweb anyway, you'd not need
> to set up additional thing for providing fetch access.
>
> Than a question is how to implement it. The current protocol is stateful on
> both sides, but the stateless nature of HTTP more or less requires the
> protocol to be stateless on the server.
>
> I think it would be possible to use basically the same protocol as now, but
> make it stateless for server. That is server first sends it's heads and than
> client repeatedly sends all it's wants and some haves until the server acks
> all of them and sends the pack.
>
> Alternatively I am thinking about using Bloom filters (somebody came with
> such idea on the bzr list when I still followed it). It might be useful, as
> over HTTP we need to send as many haves as possible in one go.
>
Bundles?
Client POSTs it's ref set; server uses the ref set to generate and
return the bundle.
Push over http(s) could work the same...
^ permalink raw reply
* Re: testing vger handling of charsets (part 1)
From: David Kågedal @ 2007-05-15 22:05 UTC (permalink / raw)
To: git
In-Reply-To: <20070515test.1@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> This is a test message to check how vger reacts to seeing 8bit
> characters (like Hasselström) in a message without the right mime
> header. Previous attempts were eaten by the list because of a lack of a
> message id.
This is broken when reading over NNTP from GMANE.
--
David Kågedal
^ permalink raw reply
* [StGIT RFC] Changing patch@branch syntax
From: Yann Dirson @ 2007-05-15 22:03 UTC (permalink / raw)
To: GIT list, Catalin Marinas
The patch@branch syntax is annoying, at least for bash-completion
purposes: we don't want to provide all possible completions accross
all branches, yet we'd like to get completion for foreign patches.
Another place where I feel it is bad is when using the full
"patch@branch//top" syntax: the MSB is in the middle, and the LSB is
on the right.
Both issues would be solved by switching to a MSB ordering, with a way
to distinguish branchnames when given. Something similar to pathnames
would fit well - eg. [/branchname/]patchname[//top]. However, I'm not
sure using slashes would be a good choice, precisely because of the
similarity with real pathnames. But we don't have so many separator
chars that are not special in one way or another, and would require
quoting them to avoid more user confusion.
What do you think ?
--
Yann.
^ permalink raw reply
* Re: [StGIT PATCH] Don't use patches/<branch>/current
From: Yann Dirson @ 2007-05-15 21:49 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Hasselström, git
In-Reply-To: <b0943d9e0705151436g64e24a32r23c45c19f750082@mail.gmail.com>
On Tue, May 15, 2007 at 10:36:05PM +0100, Catalin Marinas wrote:
> I think it would be useful to have a version file (probably per
> branch) and just upgrade when a mismatch is detected (in the __init__
> function).
Sounds reasonable, but I'd rather keep that in the config file
(eg. branch.<name>.stgit.formatversion).
Best regards,
--
Yann.
^ permalink raw reply
* Re: newby question about merge.
From: Junio C Hamano @ 2007-05-15 21:47 UTC (permalink / raw)
To: picca; +Cc: Jakub Narebski, git
In-Reply-To: <20070515133720.20d76042@localhost.localdomain>
picca <picca@synchrotron-soleil.Fr> writes:
> Is it possible to add this git cat-file -p :2:filename > filename in
> the man page of git-merge in the resolve conflict part ?
>
> Or a link to the documentation speaking of this stage part.
See:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#conflict-resolution
As this walk through section from the user manual's already
talks about it, I am not sure if we would want to duplicate its
wording in git-merge manual page.
Regardlessly, I think it is a good idea to refer to it in SEE
ALSO section, just in case the user hasn't read the user manual
before reading the git-merge manpage.
^ permalink raw reply
* Re: [StGIT RFC PATCH] Activate rename detection by default.
From: Yann Dirson @ 2007-05-15 21:37 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20070515184759.GC17851@diana.vm.bytemark.co.uk>
On Tue, May 15, 2007 at 08:47:59PM +0200, Karl Hasselström wrote:
> On 2007-05-15 16:41:47 +0100, Catalin Marinas wrote:
>
> > On 05/05/07, Yann Dirson <ydirson@altern.org> wrote:
> >
> > > This patch uses -M when generating diffs, which then looks fine,
> > > just like any other git-generated diff.
> >
> > I think we should only use -M for "files", "status", "show", "diff"
> > but not for "export" and "mail", maybe by adding an extra parameter
> > to git.diff() (or we could have this configurable or with an cmd
> > line option). The reason is that I send patches that might not be
> > applied with GIT.
>
> Seems like a good idea to me: default to -M whenever the consumer is
> guaranteed to understand it, and have it as an option defaulting to
> off when we export data.
This option should probably be available through a config setting as
well: we want to use it everytime we send a git or StGIT patch to the
list :)
OTOH, using different conventions for different commands is guaranted
to confuse more than one user. Eg, I customarily use "stg show >
../file.diff", assuming it will be readable by patch(1) - I even
issued today more than one "stg diff -r //bottom.old | (cd ../other &&
patch -p1)" - luckily, no rename there ;)
It makes sense to have it my default on for "files" and "status", but
it breaks the output format, and thus probably some user scripts.
Maybe we should add this behaviour as off by default, tunable from
config, and overridable from command-line (roughly what I suggested in
https://gna.org/task/?4773, with everything off by default). Now the
question would be what command-line syntax to use to be usable.
-M/--renames <> --no-renames ? -M would become useles when the
default, and --no-renames is cumbersome. Also, adds 2 flags per
option, we have 3 of them (-M -C --find-copies-harder), and we may
want to allow other useful ones like -w and -b.
--diff-flags='-M -C' ? Can't find a non-brain-damaging way of
negating that: --no-diff-flags='-C' to negate part of a
stgit.diff.defaultflags='-M -C' is likely to be confusing.
Better ideas anyone ?
--
Yann.
^ permalink raw reply
* Re: [StGIT PATCH] Don't use patches/<branch>/current
From: Catalin Marinas @ 2007-05-15 21:36 UTC (permalink / raw)
To: Yann Dirson; +Cc: Karl Hasselström, git
In-Reply-To: <20070515210801.GO19253@nan92-1-81-57-214-146.fbx.proxad.net>
On 15/05/07, Yann Dirson <ydirson@altern.org> wrote:
> On Tue, May 15, 2007 at 04:56:33PM +0100, Catalin Marinas wrote:
> > I think the self.__current_file (same for the base file removed in a
> > different patch) should still be available in the Series object and
> > removed when deleting a branch, otherwise you get a "Series directory
> > .. is not empty" exception.
>
> Shouldn't we also migrate to new format as soon as we need to touch a
> data - in this case, whenever we push/pop ?
>
> Or maybe declare a new "stgit stack format version" ? Currently we
> have "stg branch --convert", which switches between a "new" and an
> "old" format which noone probably uses any more. What about
> versionning the on-disk format, and possibly provide the "convert"
> functionnality back and forth between one format and the next, with
> formal documentation about which version works with which stack
> format ?
I think it would be useful to have a version file (probably per
branch) and just upgrade when a mismatch is detected (in the __init__
function). The other option is to keep ignoring the unused files until
the branch is deleted but we might make a change at some point that
would break things.
We should write successive convert() functions and keep all of them in
case one skips an intermediate version.
--
Catalin
^ permalink raw reply
* Re: torvalds talk on youtube
From: Anand Kumria @ 2007-05-15 21:12 UTC (permalink / raw)
To: git
In-Reply-To: <f2b6lu$jm$1@sea.gmane.org>
On Mon, 14 May 2007 23:41:17 -0300, Han-Wen Nienhuys wrote:
> In case you haven't noticed yet, the talk that Linus gave on Git at
> Google is now on YouTube.
>
> See:
>
> http://www.youtube.com/watch?v=4XpnKHJAok8
>
Pfft. You can download Linus being dunked
<http://video.google.com/videoplay?docid=557395790187689130>
but not talking about Git.
Anand
^ permalink raw reply
* Re: [StGIT PATCH] Don't use patches/<branch>/current
From: Yann Dirson @ 2007-05-15 21:08 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Hasselström, git
In-Reply-To: <b0943d9e0705150856n771cb696h6e8225a0bbd5d43d@mail.gmail.com>
On Tue, May 15, 2007 at 04:56:33PM +0100, Catalin Marinas wrote:
> On 06/05/07, Karl Hasselström <kha@treskal.com> wrote:
> >The name of the current patch, if any, is always the last line of
> >patches/<branch>/applied (and there is no current patch if and only if
> >the "applied" file is empty). So use that instead, and stop having to
> >worry about keeping the redundant "current" file up-to-date.
>
> I applied this patch. Could you also send me a patch for the
> bash-completion script as it uses this file?
>
> I think the self.__current_file (same for the base file removed in a
> different patch) should still be available in the Series object and
> removed when deleting a branch, otherwise you get a "Series directory
> .. is not empty" exception.
Shouldn't we also migrate to new format as soon as we need to touch a
data - in this case, whenever we push/pop ?
Or maybe declare a new "stgit stack format version" ? Currently we
have "stg branch --convert", which switches between a "new" and an
"old" format which noone probably uses any more. What about
versionning the on-disk format, and possibly provide the "convert"
functionnality back and forth between one format and the next, with
formal documentation about which version works with which stack
format ?
Best regards,
--
Yann.
^ permalink raw reply
* Smart fetch via HTTP?
From: Jan Hudec @ 2007-05-15 20:10 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]
Hello,
Did anyone already think about fetching over HTTP working similarly to the
native git protocol?
That is rather than reading the raw content of the repository, there would be
a CGI script (could be integrated to gitweb), that would negotiate what the
client needs and then generate and send a single pack with it.
Mercurial and bzr both have this option. It would IMO have three benefits:
- Fast access for people behind paranoid firewalls, that only let http and
https (you can tunel anything through, but only to port 443) through.
- Can be run on shared machine. If you have web space on machine shared
by many people, you can set up your own gitweb, but cannot/are not allowed
to start your own network server for git native protocol.
- Less things to set up. If you are setting up gitweb anyway, you'd not need
to set up additional thing for providing fetch access.
Than a question is how to implement it. The current protocol is stateful on
both sides, but the stateless nature of HTTP more or less requires the
protocol to be stateless on the server.
I think it would be possible to use basically the same protocol as now, but
make it stateless for server. That is server first sends it's heads and than
client repeatedly sends all it's wants and some haves until the server acks
all of them and sends the pack.
Alternatively I am thinking about using Bloom filters (somebody came with
such idea on the bzr list when I still followed it). It might be useful, as
over HTTP we need to send as many haves as possible in one go.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [StGIT PATCH] Don't use patches/<branch>/current
From: Catalin Marinas @ 2007-05-15 20:01 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20070515182549.GB17851@diana.vm.bytemark.co.uk>
On 15/05/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-05-15 16:56:33 +0100, Catalin Marinas wrote:
>
> > On 06/05/07, Karl Hasselström <kha@treskal.com> wrote:
> >
> > > The name of the current patch, if any, is always the last line of
> > > patches/<branch>/applied (and there is no current patch if and
> > > only if the "applied" file is empty). So use that instead, and
> > > stop having to worry about keeping the redundant "current" file
> > > up-to-date.
> >
> > I applied this patch. Could you also send me a patch for the
> > bash-completion script as it uses this file?
>
> I realized this myself yesterday or so, and patched it to not need the
> current, applied, and unapplied files. Are you OK with that patch, or
> would you like one that keeps using {,un}applied?
What is the impact on the bash completion for calling StGIT rather
than reading those files? Is it visible? If I integrate the DAG
patches, there probably isn't other way anyway.
> > I think the self.__current_file (same for the base file removed in a
> > different patch) should still be available in the Series object and
> > removed when deleting a branch, otherwise you get a "Series
> > directory ... is not empty" exception.
>
> Ah, very true. I'll whip up a fix.
>
> Same question there: are you OK with a single fix for base, current,
> applied, and unapplied, or do you want them separate?
Whatever is easier for you :-), I don't have any preference.
I'll push the patches I integrated in the next hour or so and you can
base your changes on them.
Thanks.
--
Catalin
^ permalink raw reply
* Re: GIT on MinGW problem
From: Han-Wen Nienhuys @ 2007-05-15 19:51 UTC (permalink / raw)
To: Aaron Gray, git
In-Reply-To: <033501c79710$a2eb0290$0200a8c0@AMD2500>
I think it might be a bug. Patches are welcome.
I suppose git-clone has a hardcoded path. Paths under windows should
be either taken from registry (yuck) or dynamically detected from
$PATH and argv[0].
2007/5/15, Aaron Gray <angray@beeb.net>:
> Han-Wen,
>
> Dont know whether you got the message or not so I'll try you again.
>
> On doing a git-clone I get the message :-
>
> warning: templates not found /usr/share/git-core/templates/
>
> Regards,
>
> Aaron
>
> > >This should be fixed in
> >>
> >>http://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe
> >
> > Great.
> >
> > I could not get commands like git-clone to work from CMD although this is
> > not really a handycap for the time being.
> >
> > On doing a clone I get the message :-
> >
> > warning: templates not found /usr/share/git-core/templates/
>
>
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* [StGIT PATCH] Remove obsolete files when deleting a branch
From: Karl Hasselström @ 2007-05-15 19:38 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070515182549.GB17851@diana.vm.bytemark.co.uk>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/stack.py | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/stgit/stack.py b/stgit/stack.py
index 52f39a6..4ed3a73 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -660,6 +660,16 @@ class Series(StgitObject):
if os.path.exists(self._dir()+'/orig-base'):
os.remove(self._dir()+'/orig-base')
+ # Remove obsolete files that StGIT no longer uses, but
+ # that might still be around if this is an old repository.
+ for obsolete in ([os.path.join(self._dir(), fn)
+ for fn in ['current', 'description',
+ 'applied', 'unapplied']]
+ + [os.path.join(self.__base_dir,
+ 'refs', 'bases', self.__name)]):
+ if os.path.exists(obsolete):
+ os.remove(obsolete)
+
if not os.listdir(self.__patch_dir):
os.rmdir(self.__patch_dir)
else:
^ permalink raw reply related
* Re: [PATCH] git name-rev writes beyond the end of malloc() with large generations
From: Junio C Hamano @ 2007-05-15 19:09 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <2be2ad34be511217dc735a15490f4536@pinky>
Andy Whitcroft <apw@shadowen.org> writes:
> When using git name-rev on my kernel tree I triggered a malloc()
> corruption warning from glibc.
>
> apw@pinky$ git log --pretty=one $N/base.. | git name-rev --stdin
> *** glibc detected *** malloc(): memory corruption: 0x0bff8950 ***
> Aborted
>
> This comes from name_rev() which is building the name of the revision
> in a malloc'd string, which it sprintf's into:
>
> char *new_name = xmalloc(len + 8);
> [...]
> sprintf(new_name, "%.*s~%d^%d", len, tip_name,
> generation, parent_number);
>
> This allocation is only sufficient if the generation number is
> less than 5 digits, in my case generation was 13432. In reality
> parent_number can be up to 16 so that also can require two digits,
> reducing us to 3 digits before we are at risk of blowing this
> allocation.
>
> This patch introduces a decimal_length() which approximates the
> number of digits a type may hold, it produces the following:
> ...
Does this attempt to cramp down to what's only necessary really
matter in practice in the light of malloc overhead?
It does futureproof against an insanely long "long long" on
future architectures, but I am not sure if we care either. Why
not just raise 8 to 25 or something and be done with it?
> diff --git a/git-compat-util.h b/git-compat-util.h
> index c08688c..25b8274 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -19,6 +19,9 @@
> #define TYPEOF(x)
> #endif
>
> +/* Approximation of the length of the decimal representation of this type. */
> +#define decimal_length(x) ((int)(sizeof(x) * 2.56 + 0.5) + 1)
> +
> #define MSB(x, bits) ((x) & TYPEOF(x)(~0ULL << (sizeof(x) * 8 - (bits))))
>
> #if !defined(__APPLE__) && !defined(__FreeBSD__)
Having said that, clever and clean math and use of compiler's
ability always attracts me, so maybe I would end up applying
this as is.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox