* Re: Many gits are offline this week
From: Randal L. Schwartz @ 2007-10-07 19:37 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Paolo Ciarrocchi, git
In-Reply-To: <20071007170153.GX2137@spearce.org>
>>>>> "Shawn" == Shawn O Pearce <spearce@spearce.org> writes:
Shawn> What, no mention of git-gui as a porcelain? It has more users
Shawn> than qgit according to the survey. Maybe rephrase the porcelains
Shawn> on slide 15 as:
Shawn> Other porcelain exists:
Shawn> - StGit ("stacked git"), guilt
Shawn> - tig (curses-based viewer)
Shawn> - qgit, git-gui
git-gui should have been mentioned with "the git distro". Fixed.
Shawn> On slide 26 you say "gitk mytopic origin" shows the changes back to
Shawn> the common ancestor. That's what "gitk mytopic...origin" would do.
Shawn> Note the three dots instead of the space. The space will cause
Shawn> gitk to show all history back to the beginning of time.
Darned inconsistency! Sometimes, it's a space. Sometimes it's two dots.
Sometimes, it's three dots. I know, there's reasons for that, but it's still
hard for the newbie.
--
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.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: Many gits are offline this week
From: Daniel Barkalow @ 2007-10-07 19:04 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Randal L. Schwartz, Paolo Ciarrocchi, git
In-Reply-To: <20071007170153.GX2137@spearce.org>
On Sun, 7 Oct 2007, Shawn O. Pearce wrote:
> "Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
> > >>>>> "Paolo" == Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> writes:
> >
> > Paolo> is there any material (slides, docs) you can share before the talks?
> >
> > I've had the slides reviewed by Smarter People Than Me on #git already, so
> > hopefully most of it is accurate. :) They're temporarily at
> >
> > http://www.stonehenge.com/pic/Git-2.0.3-to-be.pdf
> >
> > I still hope to have a few hours to go in and add a few sadly missing
> > graphics, particularly on the rebase vs merge section.
>
> What, no mention of git-gui as a porcelain? It has more users
> than qgit according to the survey. Maybe rephrase the porcelains
> on slide 15 as:
>
> Other porcelain exists:
> - StGit ("stacked git"), guilt
> - tig (curses-based viewer)
> - qgit, git-gui
For that matter, gitweb is essentially a limited porcelain. And this
points out that all VCSes have alternative porcelains, but git is unusual
in having convenient plumbing to support and encourage this.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Missing tags from git-clone, but not git-clone -l ?
From: Gerald (Jerry) Carter @ 2007-10-07 18:58 UTC (permalink / raw)
To: git
In-Reply-To: <4709242F.7070004@samba.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gerald (Jerry) Carter wrote:
> I'm really a but stumped on this one. I've got a set of tags
> (created by git-svnimport):
>
> $ git tag -l release-4*
> release-4-0-0tp1
> release-4-0-0tp2
> release-4-0-0tp3
> release-4-0-0tp4
>
> but when I "git-clone samba-svnimport tags-test"", one tag
> is missing.
>
> $ git tag -l release-4*
> release-4-0-0tp2
> release-4-0-0tp3
> release-4-0-0tp4
>
> Running git-clone -l works as expected (i.e. the tp1 tag appears
> in the clone).
Sorry. I did get confused. And I now understand what happened.
git-clone works correctly. What I did was "git-remote add svn
/.../path" followed by a "git-fetch svn". Looks like that
one tag was not directly reachable in the history. Running
"git-fetch -t svn" gave me the missing tags.
Sorry for the noise.
cheers, jerry
=====================================================================
Samba ------- http://www.samba.org
Centeris ----------- http://www.centeris.com
"What man is a man who does not make the world better?" --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHCSxvIR7qMdg1EfYRAldVAJ4ns/X3JDrBnTft6JDEL5e8Tv80agCgvb59
/odKKLNtH2E1zB83pHg3Qdc=
=KkBD
-----END PGP SIGNATURE-----
^ permalink raw reply
* Missing tags from git-clone, but not git-clone -l ?
From: Gerald (Jerry) Carter @ 2007-10-07 18:23 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I'm really a but stumped on this one. I've got a set of tags
(created by git-svnimport):
$ git tag -l release-4*
release-4-0-0tp1
release-4-0-0tp2
release-4-0-0tp3
release-4-0-0tp4
but when I "git-clone samba-svnimport tags-test"", one tag
is missing.
$ git tag -l release-4*
release-4-0-0tp2
release-4-0-0tp3
release-4-0-0tp4
Running git-clone -l works as expected (i.e. the tp1 tag appears
in the clone).
Here's some more info about the tag in the original svnimport
repo:
$ ls -l .git/refs/tags/
total 0
$ grep release-4 .git/packed-refs
2fbd67786af06b8f5184048d997b660cbd80cbc4 refs/tags/release-4-0-0tp1
a786f423d6dee793418e8c6591f9b962c0fa96bc refs/tags/release-4-0-0tp2
1fea21bffc836a28e3e86e930d3d9fca85590ae6 refs/tags/release-4-0-0tp3
c58417a9934d3c1f04becb542a9fb6334a07f19d refs/tags/release-4-0-0tp4
$ for h in `grep release-4 .git/packed-refs | awk '{print $1}'`; \
do git-cat-file -t $h; done
tag
tag
tag
tag
Any suggestions on how to debug this? Am I just misunderstanding
something about tags?
cheers, jerry
=====================================================================
Samba ------- http://www.samba.org
Centeris ----------- http://www.centeris.com
"What man is a man who does not make the world better?" --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHCSQvIR7qMdg1EfYRAhOIAKDpefcPqyVhPfxTazJhtd/QrmzM8QCgyyQc
e0Br/1PngGmQlGNkME+tY7c=
=+PIn
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] Make strbuf_cmp inline, constify its arguments and optimize it a bit
From: Johannes Schindelin @ 2007-10-07 18:25 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: Pierre Habouzit, Alex Riesen, git, Junio C Hamano
In-Reply-To: <20071007191821.c872cc51.tihirvon@gmail.com>
Hi,
On Sun, 7 Oct 2007, Timo Hirvonen wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Sun, 7 Oct 2007, Pierre Habouzit wrote:
> >
> > > On Sun, Oct 07, 2007 at 02:24:25PM +0000, Timo Hirvonen wrote:
> > >
> > > > strbuf->buf is always non-NULL and NUL-terminated so you could just do
> > > >
> > > > static inline int strbuf_cmp(const struct strbuf *a, const struct strbuf *b)
> > > > {
> > > > int len = a->len < b->len ? a->len : b->len;
> > > > return memcmp(a->buf, b->buf, len + 1);
> > > > }
> > >
> > > doesn't work, because a buffer can have (in some very specific cases)
> > > an embeded NUL.
> >
> > But it should work. The function memcmp() could not care less if there is
> > a NUL or not, it just compares until it finds a difference.
>
> Almost. If a is "hello\0world" and b is "hello" then it would compare 6
> characters from both and think the strings are equal.
Good point.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/4] git-gui i18n: Add more words to glossary.
From: Shawn O. Pearce @ 2007-10-07 18:05 UTC (permalink / raw)
To: Christian Stimming; +Cc: Johannes Schindelin, git
In-Reply-To: <200710052239.02492.stimming@tuhh.de>
Christian Stimming <stimming@tuhh.de> wrote:
> Signed-off-by: Christian Stimming <stimming@tuhh.de>
>
> ---
> po/glossary/git-gui-glossary.pot | 12 ++++++++++--
> po/glossary/git-gui-glossary.txt | 2 ++
> 2 files changed, 12 insertions(+), 2 deletions(-)
What version is this series applied to? It rejects against my
currently published master on repo.or.cz.
--
Shawn.
^ permalink raw reply
* Re: How to pick a commit from another git tree?
From: Pierre Habouzit @ 2007-10-07 17:50 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: git
In-Reply-To: <000101c80907$d461a810$04ac10ac@Jocke>
[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]
On Sun, Oct 07, 2007 at 05:31:00PM +0000, Joakim Tjernlund wrote:
> Hi
>
> This is probably a somewhat stupid question but I havn't had a need until now so here goes:
> There is a commit in David Millers tree:
> http://git.kernel.org/?p=linux/kernel/git/davem/bak-net-2.6.24.git;a=commit;h=bbb4c0c35a4c2aed5e025b668c8dfc99c5b74cff
> that hasn't made it into 2.6.23, but will go into 2.6.24.
> I need this fix on top of 2.6.23(once it is released).
> Now I wonder how to best add this fix to my tree. Once this fix hits linus tree and I pull
> linus tree, I don't wan't a conflict as I already have this fix in my tree.
>
> Should I just pull Davids tree? Or should I cherry-pick this one commit?
> Or something else?
The easiest way is to fetch his tree (git remote add ...; git fetch)
and then yes, cherry-pick the commit(s) you need.
If you need more than one commit, you can use:
git rebase --onto <your tip> fromCommit toCommit
and it will move ]fromCommit..toCommit] onto <your tip>
It's likely that the fetch will be quite cheap as I suppose that David
Millers tree as very few objects different from linus tree (compared to
the linux2.6 git repository size I mean).
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* How to pick a commit from another git tree?
From: Joakim Tjernlund @ 2007-10-07 17:31 UTC (permalink / raw)
To: git
Hi
This is probably a somewhat stupid question but I havn't had a need until now so here goes:
There is a commit in David Millers tree:
http://git.kernel.org/?p=linux/kernel/git/davem/bak-net-2.6.24.git;a=commit;h=bbb4c0c35a4c2aed5e025b668c8dfc99c5b74cff
that hasn't made it into 2.6.23, but will go into 2.6.24.
I need this fix on top of 2.6.23(once it is released).
Now I wonder how to best add this fix to my tree. Once this fix hits linus tree and I pull
linus tree, I don't wan't a conflict as I already have this fix in my tree.
Should I just pull Davids tree? Or should I cherry-pick this one commit?
Or something else?
Jocke
^ permalink raw reply
* Re: [PATCH] git-gui: try to locate git in same directory as git-gui (on Windows)
From: Shawn O. Pearce @ 2007-10-07 17:10 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11916634041243-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> This commit adds another guess where git might be located.
> After searching PATH the last fallback is the directory
> in which git-gui is installed. This is a good guess for
> a sane installation.
Thanks.
--
Shawn.
^ permalink raw reply
* Re: Many gits are offline this week
From: Shawn O. Pearce @ 2007-10-07 17:01 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Paolo Ciarrocchi, git
In-Reply-To: <86tzp54sez.fsf@blue.stonehenge.com>
"Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
> >>>>> "Paolo" == Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> writes:
>
> Paolo> is there any material (slides, docs) you can share before the talks?
>
> I've had the slides reviewed by Smarter People Than Me on #git already, so
> hopefully most of it is accurate. :) They're temporarily at
>
> http://www.stonehenge.com/pic/Git-2.0.3-to-be.pdf
>
> I still hope to have a few hours to go in and add a few sadly missing
> graphics, particularly on the rebase vs merge section.
What, no mention of git-gui as a porcelain? It has more users
than qgit according to the survey. Maybe rephrase the porcelains
on slide 15 as:
Other porcelain exists:
- StGit ("stacked git"), guilt
- tig (curses-based viewer)
- qgit, git-gui
On slide 26 you say "gitk mytopic origin" shows the changes back to
the common ancestor. That's what "gitk mytopic...origin" would do.
Note the three dots instead of the space. The space will cause
gitk to show all history back to the beginning of time.
On slide 27 you say that you can rebase your changes on upstream
using "git-rebase origin/master master". That's a lot more
typing than is required, most people will want to rebase their
current branch onto the upstream and thus will use "git-rebase
origin/master". Personally I think combining git-checkout's branch
switch feature into git-rebase is stupid. It really makes things
confusing. But its supported. :-(
--
Shawn.
^ permalink raw reply
* Re: [ALTERNATE PATCH] Add a simple option parser.
From: Pierre Habouzit @ 2007-10-07 17:01 UTC (permalink / raw)
To: Kristian Høgsberg, git, Junio C Hamano
In-Reply-To: <20071005142507.GL19879@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 339 bytes --]
FWIW this patch has some issues with long options parsing, I have a
fix, but am trying to migrate more builtins to this parser to see how
well it behaves.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Make strbuf_cmp inline, constify its arguments and optimize it a bit
From: Pierre Habouzit @ 2007-10-07 16:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Timo Hirvonen, Alex Riesen, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0710071710190.4174@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]
On Sun, Oct 07, 2007 at 04:11:29PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 7 Oct 2007, Pierre Habouzit wrote:
>
> > On Sun, Oct 07, 2007 at 02:24:25PM +0000, Timo Hirvonen wrote:
> >
> > > strbuf->buf is always non-NULL and NUL-terminated so you could just do
> > >
> > > static inline int strbuf_cmp(const struct strbuf *a, const struct strbuf *b)
> > > {
> > > int len = a->len < b->len ? a->len : b->len;
> > > return memcmp(a->buf, b->buf, len + 1);
> > > }
> >
> > doesn't work, because a buffer can have (in some very specific cases)
> > an embeded NUL.
>
> But it should work. The function memcmp() could not care less if there is
> a NUL or not, it just compares until it finds a difference.
not if your one of your strbuf has as prefix, the other followed by
'\0', then anything else (including nothing ;p).
Your test would yield equality.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] Have a filter_start/filter_end API.
From: Pierre Habouzit @ 2007-10-07 16:52 UTC (permalink / raw)
To: Alex Riesen; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <20071007160707.GA3270@steel.home>
[-- Attachment #1: Type: text/plain, Size: 3367 bytes --]
On Sun, Oct 07, 2007 at 04:07:07PM +0000, Alex Riesen wrote:
> Pierre Habouzit, Sun, Oct 07, 2007 16:53:55 +0200:
> > On Sat, Oct 06, 2007 at 09:06:21AM +0000, Alex Riesen wrote:
> > > If you continue to insist the code is generic enough to justify its
> > > residence in strbuf.c, continue reading.
> > >
> > > First off, what was wrong with dumb
> > >
> > > void strbuf_make_room(struct strbuf *, size_t newsize);
> > >
> > > again?
> >
> > If newsize is >= sb->alloc then the area is reallocated, the pointer
> > may move, and the "src" pointer would then be invalidated.
>
> So what? You already _have_ to know it points inside the strbuf, so
> you can't expect it to be valid after any serious strbuf operation.
Then you can't write a filter, because you need to reallocate the
buffer before even starting to read the input buffer sometimes. If you
reallocate the strbuf, and that your original buffer was in there, you
lose.
> > The idea is to have a unified API to deal with both the cases where
> > the filtering is known not to work in place by the caller, or for the
> > cases where it could if enough space is allocated but that a realloc is
> > needed.
>
> this just makes it convoluted and opaque (as in "not transparent")
I'm totally open to better alternatives. We could probably easily get
rid of strbuf_end_filter, as whichever way to deal with the issue I try
to solve in a better way, in the end, it will always be just a "free".
So, maybe there is a way to rename strbuf_start_filter so that it's
more straightforward. The way to use the API is:
@ char *to_free = NULL;
@ if ((src is inside dst && need_realloc) || operation is not in-place)
@ to_free = strbuf_detach(dst, NULL);
@ strbuf_make_room(dst, needed_size);
// do whatever you want with src and dst
free(to_free);
strbuf_start_filter tries to implement the block marked with `@'. Of
course:
* need_realloc == (needed_size >= dst->alloc)
* src is inside dst means:
src > dst->buf && src < dst->buf + dst->alloc
Though, those are both things that I find ugly to "know" in convert.c.
How things are allocated in strbufs is one of the few things we don't
want to assume anywhere outside of the strbuf module.
> > > It is for the first "if", for example. free() wont free the buf in sb.
> > > Oh, right, one can check if returned pointer !NULL. Which just adds
> > > more code to handle your API.
> >
> > I don't get that part. free(NULL) is totally ok.
>
> Not that. One have to store the result of start_filter and check it
Why check it ? You don't have to check. You have to keep it until
you're done with "src". Whichever the result was. The return of
strbuf_start_filter intends to stash a pointer to be freed for the cases
where "src" points into the destination buffer.
> > Note that I did not created this semantics, it was how convert.c
> > worked already, in a even more convoluted way before.
>
> And why shouldn't these semantics kept to convert.c?
I missed where having this live in convert.c rather than in strbuf.c
makes it less ugly or better in any sense.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] setup/rev-parse: allow HEAD to be spelled 'head'
From: Johannes Schindelin @ 2007-10-07 16:49 UTC (permalink / raw)
To: Sam Vilain; +Cc: Alex Riesen, git
In-Reply-To: <47080AC4.3040902@catalyst.net.nz>
Hi,
On Sun, 7 Oct 2007, Sam Vilain wrote:
> Alex Riesen wrote:
> > Sam Vilain, Fri, Oct 05, 2007 05:09:10 +0200:
> >> If the repository got mangled by FAT capitalization rules, then a ref
> >> such as "HEAD" will become "head" once it is back on a non-FAT FS.
> >> Check for this condition in resolve_refs and in the setup code.
> >>
> >> Suggested-by: Francois Marier <francois@debian.org>
> >> Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
> >> ---
> >> This should probably help people putting their git repos on
> >> FAT USB sticks.
> >
> > Can the people just mount FAT partitions with shortname=mixed?
>
> Of course, that is probably a solution to the problem, whereas my patch
> is a workaround.
>
> Now, I realise that this might open a can of worms ... would we also
> want to go looking for files called "pack-ab~1.pac" ?
Hell, no.
> Almost certainly not - but this solves the most immediate problem
> experienced by people putting their git repositories onto FAT
> filesystems mounted with the default options, which will say "FATAL: not
> a git repository" otherwise.
You certainly mean the issue of capitalization; yes, that is my
experience, too. Somehow, "HEAD" is the culprit.
Ciao,
Dscho
P.S.: seems you have quite cute coworkers.
^ permalink raw reply
* Re: [PATCH] Make git-clean a builtin
From: rae l @ 2007-10-07 16:42 UTC (permalink / raw)
To: Shawn Bohrer; +Cc: Linus Torvalds, git, frank, gitster
In-Reply-To: <20071007154126.GD5642@mediacenter.austin.rr.com>
On 10/7/07, Shawn Bohrer <shawn.bohrer@gmail.com> wrote:
> Thanks for the input.
>
> On Sat, Oct 06, 2007 at 06:31:36PM -0700, Linus Torvalds wrote:
> > This looks better, but I think you'd be even better off actually using the
> > "read_directory()" interface directly, instead of exec'ing off "git
> > ls-files" and parsing the line output.
>
> Perhaps, I'll take a look at how git-ls-files does it and see if I can
> do that directly. Since I'm new to git (and C) it will probably take me
> a while to re-implement though.
>
> > I also would still worry a bit about 'chdir(x)' and 'chdir("..")', because
> > quite frankly, they are *not* mirrors of each other (think symlinks, but
> > also error behaviour due to directories that might be non-executable).
> > Now, admittedly, if a directory isn't executable, I can imagine other git
> > things having problems (anybody want to test?), but that whole pattern is
> > just very fragile and not very reliable.
>
> Yes it does seem fragile, but 'chdir("-")' doesn't work in C and I
> couldn't find any equivalents. I actually did think about symlinks, and
> my code does do the right thing since I test if it is a directory before
> doing the 'chdir(x)'. Symlinks are therefore treated as normal files and
> removed.
'chdir -' is just supported by the shell, and the C interface could
use chdir(OLDPWD).
^ permalink raw reply
* Re: git-push [--all] and tags
From: Linus Torvalds @ 2007-10-07 16:39 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list, Sam Vilain
In-Reply-To: <20071007093636.GA3568@lapse.madduck.net>
On Sun, 7 Oct 2007, martin f krafft wrote:
>
> So am I right if I say that all the logic should really be happening
> in send-pack and that push is really just an interface when it comes
> to selecting the refs to push, so it should basically feed through
> the options and refs, meaning that send-pack should get --tags and
> --shared as well?
I really don't have any strong personal opinions. I don't think anybody is
ever supposed to use send-pack directly, so I don't think it really much
matters whether send-pack is taught to do all the helper options too, or
whether it should just get the list of refs..
But yes, I suspect it would be cleanest to just remove the "expand --tags"
logic from builtin-push, and make the actual sending side do that.
> Or should push enumerate all refs needed and pass them directly to
> send-pack, effectively making send-pack's --all option obsolete?
I don't think this works very well - builtin-push doesn't even know what
the remote branches _are_, so it cannot list "these branches are shared".
So we'd always have to have that shared behaviour embedded in send-pack
anyway, so I think the most logical thing is to also do the logic for
--all and --tags there.
IOW, builtin-push would just be a wrapper around send-pack, doing the
"for each remote" thing, but just passing down all/tags/shared.
Linus
^ permalink raw reply
* Re: [PATCH] Make git-clean a builtin
From: Johannes Schindelin @ 2007-10-07 16:38 UTC (permalink / raw)
To: Shawn Bohrer; +Cc: git, frank, gitster
In-Reply-To: <1191719841666-git-send-email-shawn.bohrer@gmail.com>
Hi,
On Sat, 6 Oct 2007, Shawn Bohrer wrote:
> +static int remove_directory(const char *path)
Please use remove_directory_recursively(), introduced in commit
7155b727c9baae9ef6d7829370aefc09c4ab64e2 to 'next'.
I have not looked at the rest of your patch yet.
Ciao,
Dscho
^ permalink raw reply
* Re: git fetch -- double fetch
From: Johannes Schindelin @ 2007-10-07 16:29 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <20071006185759.GE28610@shadowen.org>
Hi,
On Sat, 6 Oct 2007, Andy Whitcroft wrote:
> I have recently been seeing repeated fetching of some branches. I feel
> this has happened in at least three of my repos on three distinct
> projects:
>
> apw@pinky$ git fetch origin
> remote: Generating pack...
> remote: Done counting 5 objects.
> remote: Deltifying 5 objects...
> remote: 100% (5/5) done
> Unpacking 5 objects...
> remote: Total 5 (delta 0), reused 0 (delta 0)
> 100% (5/5) done
> * refs/remotes/origin/master: fast forward to branch 'master' of ssh://git@abat-dev/var/www/git/abat
> old..new: ce046f0..41c9dde
> * refs/remotes/origin/master: fast forward to branch 'master' of ssh://git@abat-dev/var/www/git/abat
> old..new: ce046f0..41c9dde
What does "git config --get-all remote.origin.fetch" say?
Ciao,
Dscho
^ permalink raw reply
* Re: Question about "git commit -a"
From: Johannes Schindelin @ 2007-10-07 16:26 UTC (permalink / raw)
To: Marko Macek
Cc: Dmitry Potapov, Kristian Høgsberg, Andreas Ericsson,
Paolo Ciarrocchi, Nguyen Thai Ngoc Duy, Wincent Colaiuta,
Git Mailing List, andyparkins, torvalds
In-Reply-To: <470878CB.2010609@gmx.net>
Hi,
On Sun, 7 Oct 2007, Marko Macek wrote:
> Dmitry Potapov wrote:
> > You don't. Even with 'commit -a' there is no guarantee that the
> > result will compile, because you can forget to add a new file.
>
> Actually, it would be a good idea for commit to report an error if there
> are any new files that have not been 'added' or 'ignored' (or even if
> there are missing files that have not been 'deleted'.
It is no error.
And it is reported. That is the whole _point_ of having git status output
both changed-but-not-staged and untracked files.
Of course, you only see that when you do not provide the message within
the editor, but from the command line. But then chances are that your
message is too short anyway.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make strbuf_cmp inline, constify its arguments and optimize it a bit
From: David Kastrup @ 2007-10-07 16:27 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20071007161012.GB3270@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> David Kastrup, Sun, Oct 07, 2007 16:24:57 +0200:
>> Alex Riesen <raa.lkml@gmail.com> writes:
>>
>> > It is definitely less code (also object code). It is not always
>> > measurably faster (but mostly is).
>>
>> > -int strbuf_cmp(struct strbuf *a, struct strbuf *b)
>> > -{
>> > - int cmp;
>> > - if (a->len < b->len) {
>> > - cmp = memcmp(a->buf, b->buf, a->len);
>> > - return cmp ? cmp : -1;
>> > - } else {
>> > - cmp = memcmp(a->buf, b->buf, b->len);
>> > - return cmp ? cmp : a->len != b->len;
>> > - }
>> > -}
>> > -
>>
>> > +static inline int strbuf_cmp(const struct strbuf *a, const struct strbuf *b)
>> > +{
>> > + int len = a->len < b->len ? a->len: b->len;
>> > + int cmp = memcmp(a->buf, b->buf, len);
>> > + if (cmp)
>> > + return cmp;
>> > + return a->len < b->len ? -1: a->len != b->len;
>> > +}
>>
>> My guess is that you are conflating two issues about speed here: the
>> inlining will like speed the stuff up. But having to evaluate the
>> (a->len < b->len) comparison twice will likely slow it down.
>
> Can't the result of the expression be reused in compiled?
> Isn't it a common expression?
No, since the call to memcmp might change a->len or b->len. A
standard-compliant C compiler can't make assumptions about what memcmp
might or might not touch unless both a and b can be shown to refer to
variables with an address never passed out of the scope of the
compilation unit.
>> So if you do any profiling, you should do it on both separate
>> angles of this patch.
>
> I compared the inlined versions of both.
Interesting.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] Make strbuf_cmp inline, constify its arguments and optimize it a bit
From: Timo Hirvonen @ 2007-10-07 16:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pierre Habouzit, Alex Riesen, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0710071710190.4174@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sun, 7 Oct 2007, Pierre Habouzit wrote:
>
> > On Sun, Oct 07, 2007 at 02:24:25PM +0000, Timo Hirvonen wrote:
> >
> > > strbuf->buf is always non-NULL and NUL-terminated so you could just do
> > >
> > > static inline int strbuf_cmp(const struct strbuf *a, const struct strbuf *b)
> > > {
> > > int len = a->len < b->len ? a->len : b->len;
> > > return memcmp(a->buf, b->buf, len + 1);
> > > }
> >
> > doesn't work, because a buffer can have (in some very specific cases)
> > an embeded NUL.
>
> But it should work. The function memcmp() could not care less if there is
> a NUL or not, it just compares until it finds a difference.
Almost. If a is "hello\0world" and b is "hello" then it would compare 6
characters from both and think the strings are equal.
^ permalink raw reply
* Re: [PATCH] Make strbuf_cmp inline, constify its arguments and optimize it a bit
From: Johannes Schindelin @ 2007-10-07 16:11 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Timo Hirvonen, Alex Riesen, git, Junio C Hamano
In-Reply-To: <20071007143912.GB10024@artemis.corp>
Hi,
On Sun, 7 Oct 2007, Pierre Habouzit wrote:
> On Sun, Oct 07, 2007 at 02:24:25PM +0000, Timo Hirvonen wrote:
>
> > strbuf->buf is always non-NULL and NUL-terminated so you could just do
> >
> > static inline int strbuf_cmp(const struct strbuf *a, const struct strbuf *b)
> > {
> > int len = a->len < b->len ? a->len : b->len;
> > return memcmp(a->buf, b->buf, len + 1);
> > }
>
> doesn't work, because a buffer can have (in some very specific cases)
> an embeded NUL.
But it should work. The function memcmp() could not care less if there is
a NUL or not, it just compares until it finds a difference.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make strbuf_cmp inline, constify its arguments and optimize it a bit
From: Alex Riesen @ 2007-10-07 16:10 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85fy0nknnq.fsf@lola.goethe.zz>
David Kastrup, Sun, Oct 07, 2007 16:24:57 +0200:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > It is definitely less code (also object code). It is not always
> > measurably faster (but mostly is).
>
> > -int strbuf_cmp(struct strbuf *a, struct strbuf *b)
> > -{
> > - int cmp;
> > - if (a->len < b->len) {
> > - cmp = memcmp(a->buf, b->buf, a->len);
> > - return cmp ? cmp : -1;
> > - } else {
> > - cmp = memcmp(a->buf, b->buf, b->len);
> > - return cmp ? cmp : a->len != b->len;
> > - }
> > -}
> > -
>
> > +static inline int strbuf_cmp(const struct strbuf *a, const struct strbuf *b)
> > +{
> > + int len = a->len < b->len ? a->len: b->len;
> > + int cmp = memcmp(a->buf, b->buf, len);
> > + if (cmp)
> > + return cmp;
> > + return a->len < b->len ? -1: a->len != b->len;
> > +}
>
> My guess is that you are conflating two issues about speed here: the
> inlining will like speed the stuff up. But having to evaluate the
> (a->len < b->len) comparison twice will likely slow it down.
Can't the result of the expression be reused in compiled?
Isn't it a common expression?
> So if you do any profiling, you should do it on both separate angles
> of this patch.
>
I compared the inlined versions of both.
^ permalink raw reply
* Re: [PATCH] Make strbuf_cmp inline, constify its arguments and optimize it a bit
From: David Kastrup @ 2007-10-07 16:07 UTC (permalink / raw)
To: Miles Bader
Cc: Pierre Habouzit, Timo Hirvonen, Alex Riesen, git, Junio C Hamano
In-Reply-To: <87sl4nlyg0.fsf@catnip.gol.com>
Miles Bader <miles@gnu.org> writes:
> Pierre Habouzit <madcoder@debian.org> writes:
>>> strbuf->buf is always non-NULL and NUL-terminated so you could just do
>>>
>>> static inline int strbuf_cmp(const struct strbuf *a, const struct strbuf *b)
>>> {
>>> int len = a->len < b->len ? a->len : b->len;
>>> return memcmp(a->buf, b->buf, len + 1);
>>> }
>>
>> doesn't work, because a buffer can have (in some very specific cases)
>> an embeded NUL.
>
> Couldn't you then just do:
>
> int len = a->len < b->len ? a->len : b->len;
> int cmp = memcmp(a->buf, b->buf, len);
> if (cmp == 0)
> cmp = b->len - a->len;
> return cmp;
>
> [In the case where one string is a prefix of the other, then the longer
> one is "greater".]
>
> ?
I fail to see where this variant is simpler than what we started the
journey of simplification from.
The only change I consider worth checking from the whole series in
this thread is making the function inline. All the rest pretty much
was worse than what we started from in that it needed to reevaluate
more conditions and turned out more complicated and obfuscate even to
the human reader.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH 1/2] Have a filter_start/filter_end API.
From: Alex Riesen @ 2007-10-07 16:07 UTC (permalink / raw)
To: Pierre Habouzit, Linus Torvalds, Junio C Hamano, git
In-Reply-To: <20071007145355.GC10024@artemis.corp>
Pierre Habouzit, Sun, Oct 07, 2007 16:53:55 +0200:
> On Sat, Oct 06, 2007 at 09:06:21AM +0000, Alex Riesen wrote:
> > If you continue to insist the code is generic enough to justify its
> > residence in strbuf.c, continue reading.
> >
> > First off, what was wrong with dumb
> >
> > void strbuf_make_room(struct strbuf *, size_t newsize);
> >
> > again?
>
> If newsize is >= sb->alloc then the area is reallocated, the pointer
> may move, and the "src" pointer would then be invalidated.
So what? You already _have_ to know it points inside the strbuf, so
you can't expect it to be valid after any serious strbuf operation.
> > what is that for? Why can't the caller just use strbuf_detach? (He
> > already has to pass negative hint somehow, which should be a concious
> > action).
>
> The idea is to have a unified API to deal with both the cases where
> the filtering is known not to work in place by the caller, or for the
> cases where it could if enough space is allocated but that a realloc is
> needed.
this just makes it convoluted and opaque (as in "not transparent")
> > > + if ((size_t)hint >= sb->alloc) {
> > > + void *tmp = strbuf_detach(sb, NULL);
> > > + strbuf_grow(sb, hint);
> > > + return tmp;
> > > + }
> > > +
> > > + return NULL;
> > > +}
> >
> > How can one know when it sb is safe to use after strbuf_end_filter?
>
> We could document it, that's not an issue.
The fact that you _have_to_ document is.
> > It is for the first "if", for example. free() wont free the buf in sb.
> > Oh, right, one can check if returned pointer !NULL. Which just adds
> > more code to handle your API.
>
> I don't get that part. free(NULL) is totally ok.
Not that. One have to store the result of start_filter and check it
> > What actually happens to sb? Is it detached? Is it reallocated?
> > When it is detached and when it is reallocated?
>
> It is detached if the filter does not works in place (caller says that
> with '-1' as a hint) or if it works in place but needs a buffer
> reallocation.
Too many if's. Ugly
> Note that I did not created this semantics, it was how convert.c
> worked already, in a even more convoluted way before.
And why shouldn't these semantics kept to convert.c?
^ 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