* Re: Bash completion Issue?
From: Shawn Pearce @ 2006-11-04 18:41 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200611041236.59989.alan@chandlerfamily.org.uk>
Alan Chandler <alan@chandlerfamily.org.uk> wrote:
> When I type a normal command on the bash command line (say emacs) followed by
> the partial directory name the completion completes the directory and then
> adds a slash. If I type a git command (say git update-index) with the same
> partial directory name it completes the directory, but then adds a space. I
> have to backspace, manually add the slash, before continuing with the next
> directory or filename.
Hmm. I just tried 'git update-index' and it completed here for
me as you want it to (this is with the current stock Git bash
completion support).
However we do some funny things when completing into trees. E.g. the
completion support for 'git ls-tree man:man<tab>' may seem a little
strange but it works well for my fingers. I've never really had
any problem with it.
I think the only way we differ from normal bash completion is we
sometimes don't add a space after fully completing a path name.
Usually the user has to type the space in by hand.
> In debian, there seems to be a directory /etc/bash_completion.d with files for
> each of the packages, and the debian git packages have entries in there. So
> I assume they are derived from the completion work mentioned on this list.
What completion script is it? The one that is now shipped as part
of Git has a header of the following, and resides in git.git as
contrib/completion/git-completion.bash:
#
# bash completion support for core Git.
#
# Copyright (C) 2006 Shawn Pearce
# Conceptually based on gitcompletion (http://gitweb.hawaga.org.uk/).
#
> What seems strange to me is that nobody else has mentioned this before now.
Maybe because you have a different completion script?
--
^ permalink raw reply
* Re: Problem with git-apply?
From: Junio C Hamano @ 2006-11-04 18:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611040821290.25218@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sat, 4 Nov 2006, Junio C Hamano wrote:
>>
>> The problem appears that GNU diff _never_ uses "--- /dev/null" or "+++
>> /dev/null" to indicate creation or deletion of the file, but the
>> "traditional patch parser" builtin-apply has assumed that is what the
>> traditional diff output from day one. Where we got that idea is mystery
>> to me (this is Linus's code), but I suspect it is what other SCMs did.
>
> No, the original code used to trigger a "create" diff on
> - source was /dev/null
> OR
> - source had zero patches.
>
> It used to have code like
>...
> and I think the person who broke it was you ;)
Sorry, if you followed the threads by now you know I know that.
A few messages down there is a fix for the breakage caused by
4be60962, which I'll have in 'maint'.
I think it is a time for a 1.4.3.4; these are queued since
we did 1.4.3.3.
Andy Parkins (2):
Minor grammar fixes for git-diff-index.txt
git-clone documentation didn't mention --origin as equivalent of -o
Christian Couder (3):
Remove --syslog in git-daemon inetd documentation examples.
Documentation: add upload-archive service to git-daemon.
Documentation: add git in /etc/services.
Edgar Toernig (1):
Use memmove instead of memcpy for overlapping areas
J. Bruce Fields (1):
Documentation: updates to "Everyday GIT"
Jakub Narebski (3):
diff-format.txt: Combined diff format documentation supplement
diff-format.txt: Correct information about pathnames quoting in patch format
gitweb: Check git base URLs before generating URL from it
Jan Harkes (1):
Continue traversal when rev-list --unpacked finds a packed commit.
Johannes Schindelin (1):
link_temp_to_file: call adjust_shared_perm() only when we created the directory
Junio C Hamano (9):
Documentation: clarify refname disambiguation rules.
combine-diff: a few more finishing touches.
combine-diff: fix hunk_comment_line logic.
combine-diff: honour --no-commit-id
Surround "#define DEBUG 0" with "#ifndef DEBUG..#endif"
quote.c: ensure the same quoting across platforms.
revision traversal: --unpacked does not limit commit list anymore.
link_temp_to_file: don't leave the path truncated on adjust_shared_perm failure
apply: handle "traditional" creation/deletion diff correctly.
Nicolas Pitre (1):
pack-objects doesn't create random pack names
Rene Scharfe (1):
git-cherry: document limit and add diagram
^ permalink raw reply
* Re: git bug? + question
From: Josef Weidendorfer @ 2006-11-04 17:52 UTC (permalink / raw)
To: Shawn Pearce
Cc: Sean, Junio C Hamano, Miles Bader, git, Karl Hasselström
In-Reply-To: <20061104050305.GA9003@spearce.org>
On Saturday 04 November 2006 06:03, Shawn Pearce wrote:
> After reading your reply you are probably correct. I can see there
> may be workflows that want every remote branch also created as a
> local branch.
>
> I could certainly live with a command line option to clone, e.g.:
>
> git clone --only vmdvt,vmtip user@host:/path...
Still missing here: What branch should be checked out after
cloning?
Perhaps it is better to extend git-checkout to allow to do the
correct thing when the user specifies a read-only branch from
refs/remotes. E.g. with refs/remotes/origin/vmdvt,
git checkout origin/vmdvt
should create a new local branch refs/heads/vmdvt which forks
from remotes/origin/vmdvt (and abort with
error if refs/heads/vmdvt already exists without being the local
development branch for remotes/origin/vmdvt), add to .git/config
[branch "vmdvt"]
remote = origin
merge = remotes/origin/vmdvt
and switch to this new created branch.
Given this addition to git-checkout, the implicit default
action after cloning with --use-separate-remote should be
git checkout origin/master
where "master" can be changed on the git-clone command line
to another branch, e.g. "--checkout vmdvt".
IMHO, this addition to git-checkout would make it a lot
easier to work with --use-separate-remote, as there,
every branch other the master is read-only.
And if you have two remote repositories with a master branch
each, and you want to develop locally on both, this could
be accomplished with
git checkout -b othermaster remotes/otherrepo/master
^ permalink raw reply
* Re: git bug? + question
From: Josef Weidendorfer @ 2006-11-04 17:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk62bxvtx.fsf@assigned-by-dhcp.cox.net>
On Saturday 04 November 2006 13:03, Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>
> > On Friday 03 November 2006 10:46, Karl Hasselström wrote:
> >> Hmm. How about changing the meaning of "remote" slightly? Like this:
> >
> > That's not good, as it changes existing config meaning.
> >...
> > Other option: Introduce "fetchonly" line which ignores the original
> > fetch lines in the remote section.
> >
> > [remote."gitster"]
> > url = gitster.example.com:/home/junio/git.git/
> > fetch = heads/master:remotes/gitster/master
> > fetch = heads/next:remotes/gitster/next
> > [branch."master"]
> > remote = gitster
> > fetchonly = heads/master:remotes/gitster/master
> > merge = remotes/gitster/master
>
> That is a regression in that now I need to fetch twice (in the
> above example, in reality four).
Hmm. You do not need to use it.
However, there are use cases for this.
For example, I am mostly interested in what's new on the
next and master branch in the git repository. There is no need for me
to always fetch pu or maint.
So I can use (I am behind a firewall):
[remote "origin"]
url = http://www.kernel.org/pub/scm/git/git.git
fetch = master:origin
fetch = maint:maint
fetch = next:next
fetch = todo:todo
fetch = +pu:pu
[branch "master"]
remote = origin
fetchonly = master:origin
fetchonly = next:next
merge = origin
and get master and next with a "git fetch" when on master, and
"git fetch origin" would fetch all branches.
^ permalink raw reply
* Re: If I were redoing git from scratch...
From: Linus Torvalds @ 2006-11-04 16:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsc3xx65.fsf@assigned-by-dhcp.cox.net>
On Sat, 4 Nov 2006, Junio C Hamano wrote:
>
> The biggest one is that we use too many static (worse, function
> scope static) variables that live for the life of the process,
> which makes many things very nice and easy ("run-once and let
> exit clean up the mess" mentality), but because of this it
> becomes awkward to do certain things. Examples are:
>
> - Multiple invocations of merge-bases (needs clearing the
> marks left on commit objects by earlier traversal),
Well, quite frankly, I dare anybody to do it differently, yet have good
performance with millions of objects.
The fact is, I don't think it _can_ be done. I would seriously suggest
re-visiting this in five years, just because CPU's and memory will by then
hopefully have gotten an order of magnitude faster/bigger.
The thing is, the object database when we read it in really needs to be
pretty compact-sized, and we need to remember objects we've seen earlier
(exactly _because_ we depend on the flags). So there's exactly two
alternatives:
- global life-time allocations of objects like we do now
- magic memory management with unknown lifetimes and keeping track of all
pointers.
And I'd like to point out that the memory management right now is simply
not realistic:
- it's too damn hard. A simple garbage collector based on the approach we
have now would simply not be able to do anything, since all objects are
_by_definition_ reachable from the hash chains, so there's nothing to
collect. The lifetime of an object fundamentally _is_ the whole process
lifetime, exactly because we expect the objects (and the object flags
in particular) to be meaningful.
- pretty much all garbage collection schemes tend to have a memory
footprint that is about twice what a static footprint is under any
normal load. Think about what we already do with "git pack-objects" for
something like the mozilla repository: I worked quite a lot on getting
the memory footprint down, and it's _still_ several hundred MB.
In other words, I can pretty much guarantee that some kind of "smarter"
memory management would be a huge step backwards. Yes, we now have to do
some things explicitly, but exactly because we do them explicitly we can
_afford_ to have the stupid and simple and VERY EFFICIENT memory
management ("lack of memory management") that we have now.
The memory use of git had an very real correlation with performance when I
was doing the memory shrinking a few months back (back in June). I realize
that it's perhaps awkward, but I would really want people to realize that
it's a huge performance issue. It was a clear performance issue for me
(and I use machines with 2GB of RAM, so I was never swapping), it would be
an even bigger one for anybody where the size meant that you needed to
start doing paging.
So I would seriously ask you not to even consider changing the object
model. Maybe add a few more helper routines to clear all object flags or
something, but the "every object is global and will never be de-allocated"
is really a major deal.
Five years from now, or for somebody who re-implements git in Java (where
performance isn't going to be the major issue anyway, and you probably do
"small" things like "commit" and "diff", and never do full-database things
like "git repack"), _then_ you can happily look at having something
fancier. Right now, it's too easy to just look at cumbersome interfaces,
and forget about the fact that those interfaces is sometimes what allows
us to practically do some things in the first place.
^ permalink raw reply
* Re: Problem with git-apply?
From: Linus Torvalds @ 2006-11-04 16:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kevin Shanahan, git
In-Reply-To: <7v8xir4k3w.fsf@assigned-by-dhcp.cox.net>
On Sat, 4 Nov 2006, Junio C Hamano wrote:
>
> The problem appears that GNU diff _never_ uses "--- /dev/null" or "+++
> /dev/null" to indicate creation or deletion of the file, but the
> "traditional patch parser" builtin-apply has assumed that is what the
> traditional diff output from day one. Where we got that idea is mystery
> to me (this is Linus's code), but I suspect it is what other SCMs did.
No, the original code used to trigger a "create" diff on
- source was /dev/null
OR
- source had zero patches.
It used to have code like
if (patch->is_new < 0) {
patch->is_new = !oldlines;
if (!oldlines)
patch->old_name = NULL;
}
if (patch->is_delete < 0) {
patch->is_delete = !newlines;
if (!newlines)
patch->new_name = NULL;
}
and I think the person who broke it was you ;)
According to git-pickaxe, the buggy commit is 4be60962.
You should know by now that I never have bugs.
^ permalink raw reply
* Re: git bug? + question
From: Sean @ 2006-11-04 15:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn Pearce, Miles Bader, Karl Hasselström
In-Reply-To: <7vejsjxvtw.fsf@assigned-by-dhcp.cox.net>
On Sat, 04 Nov 2006 04:03:39 -0800
Junio C Hamano <junkio@cox.net> wrote:
> There is no "get it right most of the time" that would apply to
> every workflow. We should just admit that no default layout and
> configuration would suit everybody's needs. What we should do
> is to try to capture a handful useful patterns and make it easy
> for people to apply those canned patterns.
Consider it admitted ;o) But there is no need to have just a single
configuration that suits everybody. For instance, nobody is saying
to do away with the current default in favor of use-separate-remotes.
That is why someone saying "Nak" to a feature where all branches
are checked out locally on clone is "rash". Because it _is_ valuable
to some workflows. There is no reason Git could not support it. If
it gets in the way of some workflows, then we just make it a
configuration option. However, I don't feel strongly about this
particular option, if you notice in my email I merely suggested it
for discussion.
But by the same token, Git should _better_ support Shawn's example
workflow where currently Git makes him delete a bunch of branches
and edit the remotes/origin file every time after cloning. It would
be rash of me to send out a Nak for such an improvement just because
I don't need that feature.
All that remains is coming to some consensus on which set of options
should be enabled for new Git users. Once someone is up to speed, they
can enable whichever options support their workflow. But once they've
enabled those options, Git should do it's best to support that workflow
without a lot of manual intervention most of the time. That's what
the options I was suggesting would do for some workflows.
^ permalink raw reply
* Bash completion Issue?
From: Alan Chandler @ 2006-11-04 12:36 UTC (permalink / raw)
To: git
I am experiencing (and have for some time) a strange effect with bash
completion on my Debian (Unstable) system. Is this a git problem, or
something else?
When I type a normal command on the bash command line (say emacs) followed by
the partial directory name the completion completes the directory and then
adds a slash. If I type a git command (say git update-index) with the same
partial directory name it completes the directory, but then adds a space. I
have to backspace, manually add the slash, before continuing with the next
directory or filename.
In debian, there seems to be a directory /etc/bash_completion.d with files for
each of the packages, and the debian git packages have entries in there. So
I assume they are derived from the completion work mentioned on this list.
What seems strange to me is that nobody else has mentioned this before now.
--
Alan Chandler
^ permalink raw reply
* Re: If I were redoing git from scratch...
From: Jakub Narebski @ 2006-11-04 12:21 UTC (permalink / raw)
To: git
In-Reply-To: <7vpsc3xx65.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> * Core data structure
[...]
> The biggest one is that we use too many static (worse, function
> scope static) variables that live for the life of the process,
> which makes many things very nice and easy ("run-once and let
> exit clean up the mess" mentality), but because of this it
> becomes awkward to do certain things. Examples are:
One of examples that have been only rarely fixed was for_each_ref
forcing callers to using static variable to store gathered data
instead of passing the data as one of arguments.
> * Fetch/Push/Pull/Merge confusion
>
> Everybody hates the fact that inverse of push is fetch not pull,
> and merge is not a usual Porcelain (while it _is_ usable as a
> regular UI command, it was originally done as a lower layer
> helper to "pull" Porcelain and has a strange parameter order
> with seemingly useless HEAD parameter in the middle).
>
> If I were doing git from scratch, I would probably avoid any of
> the above words that have loaded meanings from other SCMs.
I'm a bit used to "push", "fetch" and "pull". I consider "pull"
a bit of artifact from times of one branch per repository layout.
The fact that "pull" fetches _all_ the branches but merges one
[usually] with the _current_ branch (unless you configure it other
way)...
I'll leave "push" as is, leave "fetch" as is, and make "pull" to be
"fetch" by default unless you use "--merge[=<branch>]" option.
I'd rename "merge" to "merge-driver" and make new "merge" thanks
to new users wouldn't have to learn to use "git pull . branchA"
to merge current branch with branchA.
Perhaps would make it possible to specify remote branch a la cogito,
<URL>#<branch>, to pull remote branch without tracking branch, and
for symmetry have "--pull[=<repo>]" or "--fetch[=<repo>]" option.
> * Unified "fetch" and "push" across backends.
>
Very nice idea, but one must remember the limitations of import/export tools
and of course limitations of other SCM... well, and also limitations of
Git, if there are any compared to other SCM ;-)
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Git hosting techniques
From: Petr Baudis @ 2006-11-04 12:08 UTC (permalink / raw)
To: Sylvain Beucler; +Cc: savannah-hackers-public, git
In-Reply-To: <20061029175446.GE12285@localhost.localdomain>
Hi,
cc'ing git@vger.kernel.org since this might be interesting for other
Git people as well.
On Sun, Oct 29, 2006 at 06:54:46PM CET, Sylvain Beucler wrote:
> We're currently setting up something similar at
> http://cvs.sv.gnu.org/gitweb/,
That's great!
> I would like to know if you considered the ability to autopack
> repositories to optimize space and disk i/o. For example, we're
> experimenting with the coreutils repository which weighs 1.1GB. Since
> you mirror the glibc repository, maybe you have similar issues?
currently I do it in a rather silly way and when I do an "all-repo
check" every hour (which updates mirrors of external repositories etc.)
- I also check for unpacked objects and if there are any, I will repack
the repository; see
http://repo.or.cz/w/repo.git?a=blob;f=updatecheck.sh;hb=HEAD
This is not an optimal behaviour, for two reasons:
(i) Full repack can be a lot of work on large repositories, so we
shouldn't *always* repack but more importantly, we should only rarely do
a full repack - see below.
(ii) This is very unfriendly to those who fetch over HTTP, because
after you do a full repack, they will need to download the whole new
packfile instead of just the missing objects.
The best solution would be to have a more intelligent repacking
strategy, where you have "archival" packs with very old history and an
active pack with just the new changes, and when you pack the loose
objects they just get appended to the "current" pack. Alternatively,
a slightly more complicated but even more flexible "logarithmic"
repacking strategy could be implemented, see
http://news.gmane.org/find-root.php?message_id=<20051112135947.GC30496@pasky.or.cz>
Even with the dumb packing strategy though, I think it pays off if you
have at least a bit of CPU power to spare. The packing saving are
really immense. For example with the glibc repository, an incremental
CVS import worth of few days of changes _doubled_ the size of the
repository (from 100M to 200M), while repacking brought it back to the
original size (100M) + epsilon.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: git bug? + question
From: Junio C Hamano @ 2006-11-04 12:03 UTC (permalink / raw)
To: Sean; +Cc: git, Shawn Pearce, Miles Bader, Karl Hasselström
In-Reply-To: <BAYC1-PASMTP01F45766D9195AAFD81789AEFE0@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
> I think your Nack was a little rash here. The feature would be quite
> useful to work flows other than yours. It sounds like what _you_ want
> is a feature to select branches when cloning rather than the current
> default of cloning all. That would stop your developers having to
> delete branches and editing .git/remotes/origin immediately
> after cloning.
I think this conversation demonstrates that this previous
statement of yours was also rather rash:
The essential point is that most of the time the Git user
should not have to manually create the merge entries in the
config file. Git should be smart enough to get it right most
of the time automatically.
There is no "get it right most of the time" that would apply to
every workflow. We should just admit that no default layout and
configuration would suit everybody's needs. What we should do
is to try to capture a handful useful patterns and make it easy
for people to apply those canned patterns.
For example, that is what we did for "git clone". We identified
two common layouts, traditional and separate-remote, and we
support both. The reason we might want to favor separate-remote
over traditional should be based on the expected workflow and
expertise level of the majority of users. If a census turns out
that the more experienced people tend to prefer traditional
layout, then changing the default to separate-remote would be
easier even if people with workflow separate-remote is more
appropriate is not the absolute majority, because the layout can
be easily changed by more experienced folks.
I think the "what should the default merge source be" topic is
very similar. There is no single _right_ way and to some extent
what the vanilla default is does not really matter.
^ permalink raw reply
* Re: git bug? + question
From: Junio C Hamano @ 2006-11-04 12:03 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200611031815.49553.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> On Friday 03 November 2006 10:46, Karl Hasselström wrote:
>> Hmm. How about changing the meaning of "remote" slightly? Like this:
>
> That's not good, as it changes existing config meaning.
>...
> Other option: Introduce "fetchonly" line which ignores the original
> fetch lines in the remote section.
>
> [remote."gitster"]
> url = gitster.example.com:/home/junio/git.git/
> fetch = heads/master:remotes/gitster/master
> fetch = heads/next:remotes/gitster/next
> [branch."master"]
> remote = gitster
> fetchonly = heads/master:remotes/gitster/master
> merge = remotes/gitster/master
That is a regression in that now I need to fetch twice (in the
above example, in reality four).
^ permalink raw reply
* Re: Initial push to git+ssh://repo.or.cz/srv/git/git/jnareb-git.git fails
From: Petr Baudis @ 2006-11-04 11:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611041251.07790.jnareb@gmail.com>
Dear diary, on Sat, Nov 04, 2006 at 12:51:07PM CET, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Petr Baudis "<pasky@ucw.cz>" wrote
>
> > On Sun, Oct 29, 2006 at 01:08:44PM CET, Jakub Narebski wrote:
>
> >> And here it hangs...
> >
> > This is because the unpacking takes really looooooooong time. :-(
>
> That was because git-push didn't have progress report on uploading and
> unpacking.
No, that makes it more bearable but not shorter and less totally
pointless (since the next time we hit the repository we are going to
pack it back).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: Initial push to git+ssh://repo.or.cz/srv/git/git/jnareb-git.git fails
From: Jakub Narebski @ 2006-11-04 11:51 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061104111340.GZ18879@pasky.or.cz>
Petr Baudis "<pasky@ucw.cz>" wrote
> On Sun, Oct 29, 2006 at 01:08:44PM CET, Jakub Narebski wrote:
>> And here it hangs...
>
> This is because the unpacking takes really looooooooong time. :-(
That was because git-push didn't have progress report on uploading and
unpacking.
--
Jakub Narebski
^ permalink raw reply
* If I were redoing git from scratch...
From: Junio C Hamano @ 2006-11-04 11:34 UTC (permalink / raw)
To: git
I've been thinking about these for a while on the back of my
head, and thought it might be better to start writing it down.
A lot of issues involve UI which means it will not materialize
without breaking existing uses, but if we know in advance what
we will be aiming for, maybe we will find a smoother path to
reach there.
* Core data structure
I consider on-disk data structures and on-wire protocol we
currently use are sane and there is not much to fix. There are
certainly things to be enhanced (64-bit .idx offset, for
example), but I do not think there is anything fundamentally
broken and needs to be reworked.
I have the same feeling for in-core data structures in general,
except a few issues.
The biggest one is that we use too many static (worse, function
scope static) variables that live for the life of the process,
which makes many things very nice and easy ("run-once and let
exit clean up the mess" mentality), but because of this it
becomes awkward to do certain things. Examples are:
- Multiple invocations of merge-bases (needs clearing the
marks left on commit objects by earlier traversal),
- Creating a new pack and immediately start using it inside the
process itself (prepare_packed_git() is call-once, and we
have hacks to cause it re-read the packs in many places).
- Visiting more than one repositories within one process
(many per-repository variables in sha1_file.c are static
variables and there is no "struct repository" that we can
re-initialize in one go),
- The object layer holds onto all parsed objects
indefinitely. Because the object store at the philosophy
level represents the global commit ancestry DAG, there is
no inherent reason to have more than one instance of
object.c::obj_hash even if we visit more than one
repositories in a process, but if the two repositories are
unrelated, objects from the repository we were looking at
only waste memory after switching to a different
repostiory.
- The diffcore is not run-once but it is run-one-at-a-time.
This is easy to fix if needed, though.
There are some other minor details but they are not as
fundamental. Examples are:
- The revision traversal is nicely done but one gripe I have is
that it is focused on painting commits into two (and only
two) classes: interesting and uninteresting. If we allowed
more than one (especially, arbitrary number of) kinds of
interesting, answering questions like "which branches does
this commit belong to? which tagged versions is this commit
already included in?" would become more easy and efficient.
show-branch has machinery to do that for a handful but it
could be unified with the revision.c traversal machinery.
- We have at least three independent implementations of
pathspec match logic and two different semantics (one is
component-prefix match, the other is shell glob), and they
should be unified. You can say "git grep foo -- 't/t5*'" but
not "git diff otherbranch -- 't/t5*'".
* Fetch/Push/Pull/Merge confusion
Everybody hates the fact that inverse of push is fetch not pull,
and merge is not a usual Porcelain (while it _is_ usable as a
regular UI command, it was originally done as a lower layer
helper to "pull" Porcelain and has a strange parameter order
with seemingly useless HEAD parameter in the middle).
If I were doing git from scratch, I would probably avoid any of
the above words that have loaded meanings from other SCMs.
Perhaps...
- "git download" would download changes made in the other end
since we contacted them the last time and would not touch our
branches nor working tree (associate the word with getting
tarballs -- people would not expect the act of downloading a
tarball would touch their working tree nor local history.
untarring it does). It is a different story if the end-user
should be required to explicitly say "download"; I am leaning
towards making it more or less transparent.
- "git upload" to upload our changes to the other end -- that
is what "git push" currently does.
- "git join" to merge another branch into the current branch,
with the "per branch configuration" frills to decide what the
default for "another branch" is based on what the current
branch is, etc.
* Less visible "remoteness" of remote branches
If I were doing git from scratch, I would probably have done
separate remotes _the_ only layout, except I might have opted to
make "remotes" even less visible and treating it as merely a
cache of "the branch tips and tags we saw when we connected over
the network to look at them the last time".
So "git branch --list $remote" might contact the remote over the
network or use cached version. When you think about, it it is
not all that different from always contacting the remote end --
the remote end may have mirror propagation delays, and your
local instance of git caching and not contacting the remote all
the time introduces a similar delay on your end which is (1) not
a big deal, and (2) unlike the remote mirror delay, controllable
on your end. For example, you could force it to update the
cache by "git download $remote; git branch --list $remote".
* Unified "fetch" and "push" across backends.
I was rediscovering git-cvsimport today and wished if I could
just have said (syntax aside):
URL: cvs;/my.re.po/.cvsroot
Pull: HEAD:remotes/cvs/master
Pull: experiment:remotes/cvs/experiment
to cause "git fetch" to run git-cvsimport to update the remotes/cvs/
branches (and "git pull" to merge CVS changes to my branches).
The same thing should be possible for SVN and other foreign SCM
backends.
Also it should be possible to use git-cvsexportcommit as a
backend for "git push" into the cvs repository.
That's it for tonight...
^ permalink raw reply
* Re: Problem with git-apply?
From: Kevin Shanahan @ 2006-11-04 10:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu01f34bo.fsf@assigned-by-dhcp.cox.net>
On Sat, Nov 04, 2006 at 02:15:55AM -0800, Junio C Hamano wrote:
> Actually it was a small problem in the patch parsing code. Can
> you give this a try?
Yes, this patch works for me.
Cheers,
Kev.
> ---
> diff --git a/builtin-apply.c b/builtin-apply.c
> index 11397f5..db7cdce 100644
> --- a/builtin-apply.c
> +++ b/builtin-apply.c
> @@ -1043,10 +1043,14 @@ static int parse_single_patch(char *line
> * then not having oldlines means the patch is creation,
> * and not having newlines means the patch is deletion.
> */
> - if (patch->is_new < 0 && !oldlines)
> + if (patch->is_new < 0 && !oldlines) {
> patch->is_new = 1;
> - if (patch->is_delete < 0 && !newlines)
> + patch->old_name = NULL;
> + }
> + if (patch->is_delete < 0 && !newlines) {
> patch->is_delete = 1;
> + patch->new_name = NULL;
> + }
> }
>
> if (0 < patch->is_new && oldlines)
^ permalink raw reply
* Re: [PATCH 2/n] gitweb: Use '&iquot;' instead of '?' in esc_path
From: Petr Baudis @ 2006-11-04 10:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vr6wk3wpo.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Nov 04, 2006 at 01:02:43AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > Dear diary, on Fri, Nov 03, 2006 at 11:44:48PM CET, I got a letter
> > where Junio C Hamano <junkio@cox.net> said that...
> >> Jakub Narebski <jnareb@gmail.com> writes:
> >> > Which solution do you think it's best?
> >>
> >> Sorry, if it was not clear in my message, I wanted to say that I
> >> kinda liked those "control pictures" in U+2400 range.
> >
> > In principle, right now it should be pretty easy for a project that for
> > some reason does not use UTF-8 in commits etc. to adjust gitweb to work
> > properly, right? Just change the encoding in HTTP headers and you're
> > done, I think.
> >
> > Is it worth trying to preserve that flexibility?
>
> Absolutely, and I got your point. Maybe <blink>\011</blink>
> would be more portable and appropriate.
Actually Jakub is right, &#number; is always a Unicode codepoint,
regardless of document encoding.
Anything but <blink>! ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: cogito needs "mv xxx README"
From: Petr Baudis @ 2006-11-04 10:18 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86slgzmtsl.fsf@blue.stonehenge.com>
Dear diary, on Sat, Nov 04, 2006 at 10:43:06AM CET, I got a letter
where "Randal L. Schwartz" <merlyn@stonehenge.com> said that...
> I'd submit a patch, but "mv xxx README" does it. :)
Yes, sorry for that, I don't know how the hell that got out... I've
already pushed out fixed version last night.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: Problem with git-apply?
From: Junio C Hamano @ 2006-11-04 10:15 UTC (permalink / raw)
To: Kevin Shanahan; +Cc: git
In-Reply-To: <7v4ptf4jmj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> *BLUSH* A prime example of "you should not speak before
> thinking".
>
> Please forget everything I said. The patch parsing is just fine
> with or without "/dev/null". This must be a recent breakage
> around write_out_one_result(). Will take a look.
Actually it was a small problem in the patch parsing code. Can
you give this a try?
---
diff --git a/builtin-apply.c b/builtin-apply.c
index 11397f5..db7cdce 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1043,10 +1043,14 @@ static int parse_single_patch(char *line
* then not having oldlines means the patch is creation,
* and not having newlines means the patch is deletion.
*/
- if (patch->is_new < 0 && !oldlines)
+ if (patch->is_new < 0 && !oldlines) {
patch->is_new = 1;
- if (patch->is_delete < 0 && !newlines)
+ patch->old_name = NULL;
+ }
+ if (patch->is_delete < 0 && !newlines) {
patch->is_delete = 1;
+ patch->new_name = NULL;
+ }
}
if (0 < patch->is_new && oldlines)
^ permalink raw reply related
* Re: Problem with git-apply?
From: Kevin Shanahan @ 2006-11-04 10:12 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eihmas$8sj$1@sea.gmane.org>
On Sat, Nov 04, 2006 at 10:26:13AM +0100, Jakub Narebski wrote:
> This I think is a bug, or rather misfeature in git-apply (or at least
> inconsistency between GNU diff and git patch format). But if you change
> from-file line from "--- a/foo" to "--- /dev/null" then git-apply happily
> applies creation patch and creates file.
Thanks. At least that gives me a workaround for now.
Cheers,
^ permalink raw reply
* Re: Problem with git-apply?
From: Junio C Hamano @ 2006-11-04 10:00 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xir4k3w.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Kevin Shanahan <kmshanah@disenchant.net> writes:
>
>> #!/bin/sh
>>
>> mkdir a b repo
>> echo foo > b/foo
>> diff -urN a b > test.diff
>
> It is *very* surprising that this issue did not come up earlier,
> given that we used to use GNU diff internally to generate our
> own diff.
>
> If you cat the test.diff file, you will see "a/foo" and "b/foo",
> not "/dev/null".
>
> The problem appears that GNU diff _never_ uses "--- /dev/null"
> or "+++ /dev/null" to indicate creation or deletion of the file,
> but the "traditional patch parser" builtin-apply has assumed
> that is what the traditional diff output from day one. Where we
> got that idea is mystery to me (this is Linus's code), but I
> suspect it is what other SCMs did.
*BLUSH* A prime example of "you should not speak before
thinking".
Please forget everything I said. The patch parsing is just fine
with or without "/dev/null". This must be a recent breakage
around write_out_one_result(). Will take a look.
^ permalink raw reply
* Re: Problem with git-apply?
From: Junio C Hamano @ 2006-11-04 9:49 UTC (permalink / raw)
To: Kevin Shanahan; +Cc: git
In-Reply-To: <20061104072349.GA19667@cubit>
Kevin Shanahan <kmshanah@disenchant.net> writes:
> #!/bin/sh
>
> mkdir a b repo
> echo foo > b/foo
> diff -urN a b > test.diff
It is *very* surprising that this issue did not come up earlier,
given that we used to use GNU diff internally to generate our
own diff.
If you cat the test.diff file, you will see "a/foo" and "b/foo",
not "/dev/null".
The problem appears that GNU diff _never_ uses "--- /dev/null"
or "+++ /dev/null" to indicate creation or deletion of the file,
but the "traditional patch parser" builtin-apply has assumed
that is what the traditional diff output from day one. Where we
got that idea is mystery to me (this is Linus's code), but I
suspect it is what other SCMs did.
With the GNU diff output, the only way to guess it is a file
creation patch is to notice that the patch has only a single
hunk that inserts into -0,0 (this tests that the file is
originally empty), and it is followed by a HT and the UNIX epoch
(i.e. 1970-01-01 00:00:00 GMT) timestamp in localtime + offset
format (the latter is a guess to tell creation from modification
to a file that was originally empty). This means that we do not
have a way to tell if it was a file that had UNIX epoch
timestamp that was modified or if this is a creation.
Having to parse the localtime + offset and compare it with UNIX
epoch is already crazy, but the saddest part is that this is
quite GNU diff specific right now, and I'd rather not to require
the trailing HT + timestamp (which is now being written down in
new POSIX) to the "traditional patch" input format.
Probably a reasonable compromise is to treat a non-git patch
(i.e. the ones that does not begin with "diff --git") that
touches an empty file as a file creation patch, but I need to
look at the code to see how much damage such a change needs to
cause. If I remember collectly it wants to decide if it is a
creation patch or modification patch upfront, so it may not be
as trivial as it sounds. We'll see.
^ permalink raw reply
* cogito needs "mv xxx README"
From: Randal L. Schwartz @ 2006-11-04 9:43 UTC (permalink / raw)
To: git
I'd submit a patch, but "mv xxx README" does it. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Re: Problem with git-apply?
From: Jakub Narebski @ 2006-11-04 9:26 UTC (permalink / raw)
To: git
In-Reply-To: <20061104072349.GA19667@cubit>
Kevin Shanahan wrote:
> I seem to be having problems using git-apply to apply any patch which
> creates a new file. Unfortunately it's been a few weeks since I last
> used git here locally, but this seems like some behaviour change since
> the last version I was using. I'm currently using version 1.4.3.3 from
> Debian Sid. This little test script demonstrates the problem I'm
> having:
>
> #!/bin/sh
>
> mkdir a b repo
> echo foo > b/foo
> diff -urN a b > test.diff
Which produces the following diff:
diff -urN a/foo b/foo
--- a/foo 1970-01-01 01:00:00.000000000 +0100
+++ b/foo 2006-11-04 10:05:04.000000000 +0100
@@ -0,0 +1 @@
+foo
> (
> cd repo
> echo bar > bar # need something to init the db
> git init-db
> git add .
> git commit -a -m "Test Commit"
>
> git apply ../test.diff
> git commit -a -m "Test Commit (file added)"
> )
>
> Here, this outputs for me:
>
> defaulting to local storage area
> Committing initial tree ee314a31b622b027c10981acaed7903a3607dbd4
> error: foo: No such file or directory
> nothing to commit
This I think is a bug, or rather misfeature in git-apply (or at least
inconsistency between GNU diff and git patch format). But if you change
from-file line from "--- a/foo" to "--- /dev/null" then git-apply happily
applies creation patch and creates file.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Problem with git-apply?
From: Kevin Shanahan @ 2006-11-04 8:07 UTC (permalink / raw)
To: git
In-Reply-To: <20061104072349.GA19667@cubit>
On Sat, Nov 04, 2006 at 05:53:49PM +1030, Kevin Shanahan wrote:
> I seem to be having problems using git-apply to apply any patch which
> creates a new file. Unfortunately it's been a few weeks since I last
> used git here locally, but this seems like some behaviour change since
> the last version I was using. I'm currently using version 1.4.3.3 from
> Debian Sid. This little test script demonstrates the problem I'm
> having:
Sorry, I probably should have said to CC me, as I'm not subscribed.
Thanks for your reply Shawn, but --index doesn't seem to make any
difference. If it helps, I can confirm that the script works fine with
version 1.4.1.1.
> #!/bin/sh
>
> mkdir a b repo
> echo foo > b/foo
> diff -urN a b > test.diff
>
> (
> cd repo
> echo bar > bar # need something to init the db
> git init-db
> git add .
> git commit -a -m "Test Commit"
>
> git apply ../test.diff
> git commit -a -m "Test Commit (file added)"
> )
>
> Here, this outputs for me:
>
> defaulting to local storage area
> Committing initial tree ee314a31b622b027c10981acaed7903a3607dbd4
> error: foo: No such file or directory
> nothing to commit
>
> Has something broken or am I doing something wrong here?
>
> Thanks,
^ 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