* Re: How to check new commit availability without full fetch?
From: Nicolas Pitre @ 2010-01-11 20:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin Rosenberg, SLONIK.AZ, Git Mailing List
In-Reply-To: <7vmy0kjvms.fsf@alter.siamese.dyndns.org>
On Mon, 11 Jan 2010, Junio C Hamano wrote:
> Ahh, you are right. It walks from objects the remote side told us are at
> the tip, and stops at what we know are complete (i.e. reachable from our
> tip of objects); immediately after --dry-run slurped objects, the next
> fetch will prove everything is locally available and complete before going
> over the network.
>
> But either I am very confused or the use of fields from "struct ref" is
> unintuitive in this codepath.
>
> Why does it feed ref->old_sha1? We are feeding _their_ tip commits to:
>
> rev-list --objects --stdin --not --all
>
> and expecting it to report failure when some of their tip commits lead to
> what we don't have yet. The reason why we have old_sha1[] vs new_sha1[]
> is because we want to report what changed from what, and also to protect
> us from simultaneous updates by doing compare-and-swap using the value we
> read from our refs when we started in old_sha1[], so I would have expected
> that ref_map elements would have _their_ commits on the new_sha1[] side,
> but apparently that is not what is happening, and it has been this way for
> a long time. The use of old_sha1[] came from 4191c35 (git-fetch: avoid
> local fetching from alternate (again), 2007-11-11), so it is a lot more
> likely that I am confused than the code is wrong and nobody noticed so
> far.
Very confusing indeed. I first discovered about quickfetch() myself
when I fixed shallow clone leading to commit 86386829.
If old_sha1[] was our refs then quickfetch() would always succeed and
we'd never fetch anything.
> What am I missing?
Digging a bit, it looks like get_remote_heads() is storing the remote's
heads into old_sha1. And so is performed in get_refs_from_bundle(), and
in insert_packed_refs() from get_refs_via_rsync(), etc.
Looking at the struct ref definition, we can see:
struct ref {
struct ref *next;
unsigned char old_sha1[20];
unsigned char new_sha1[20];
[...]
struct ref *peer_ref; /* when renaming */
[...]
};
And apparently store_updated_refs() ends up using that peer_ref like
this:
for (rm = ref_map; rm; rm = rm->next) {
struct ref *ref = NULL;
if (rm->peer_ref) {
ref = xcalloc(1, sizeof(*ref) + strlen(rm->peer_ref->name) + 1);
strcpy(ref->name, rm->peer_ref->name);
hashcpy(ref->old_sha1, rm->peer_ref->old_sha1);
hashcpy(ref->new_sha1, rm->old_sha1);
ref->force = rm->peer_ref->force;
}
So.... Doesn't this all look like a total mess of needless (and even
leaked in this case) allocations and duplications, besides being
completely unintuitive? Both hashcpy() above certainly throw my sense
of logic aside...
Nicolas
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Linus Torvalds @ 2010-01-11 20:07 UTC (permalink / raw)
To: Fredrik Kuivinen
Cc: Junio C Hamano, Miles Bader, Jeff King, Nguyen Thai Ngoc Duy, git
In-Reply-To: <4c8ef71001111140j7e7d0081o7718d956104a2451@mail.gmail.com>
On Mon, 11 Jan 2010, Fredrik Kuivinen wrote:
> >
> > Try a complex pattern ("qwerty.*as" finds the same line), and see if that
> > too is slower than before. If that is faster than it used to be (with
> > --no-ext-grep, of course), then it's strstr() that is badly implemented.
>
> Ah, yes, that's it. With the pattern "qwerty.*as" I get 2.5s with the
> patch and 6s without.
Ok, so on your machine, regcomp() is basically twice as fast as strstr().
Which is not entirely unexpected: I was actually surprised by strstr()
being apparently so good on my machine. I do not generally expect things
like that to be at all optimized for bigger working sets. Most common uses
of strstr() are in short strings - not "strings" that are many kilobytes
in size (the whole file).
In fact, I suspect it works so well for me because in my version of glibc
it's not just SSE-optimized: judging by the naming it's SSE4.2 optimized -
so the case I see on my machine will _only_ happen on Nehalem-based cores
(ie the new "Core i[357]" cpu's).
It is entirely possible that strstr in general is a disaster.
Linus
^ permalink raw reply
* Re: How to check new commit availability without full fetch?
From: Andreas Schwab @ 2010-01-11 20:06 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Git Mailing List
In-Reply-To: <ee2a733e1001100312j786108fct1b4c8abd0acc5afc@mail.gmail.com>
Leo Razoumov <slonik.az@gmail.com> writes:
> Hi List,
> I am trying to find a way to check availability of new commits
> *before* doing fetch or pull. Unfortunately, neither fetch nor pull
> take "--dry-run" option (unlike push)
Try git remote show origin.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 9/9] rerere forget path: forget recorded resolution
From: Junio C Hamano @ 2010-01-11 20:05 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <201001112022.31257.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> I did encounter a case where the same resolution would apply to all
> conflicts that have the same conflict hash, so it's not quite what you
> talk about. But not all conflicts were automatically resolved. I haven't
> yet analyzed what happened - it could just be that the xdl_merge call
> fails due to the differences in the text immediately outside the
> conflict markers.
Actually it is _very_ easy to fool rerere to do something totally
unexpected, and I have been thinking about using the similarity comparison
algorithm on the region outside the conflicted area between preimage and
thisimage and reject use of rerere.
Try this in an empty directory.
-- >8 --
#!/bin/sh
git init
create_numbers () {
for n in 0 1 2 3 4 "$1" 5 6 7 8 9
do
echo $n
done >numbers.txt
}
create_letters () {
for l in a b c d e "$1" f g h i j
do
echo $l
done >letters.txt
}
create_files () {
create_numbers "$1"
create_letters "$1"
}
create_files ""
git add numbers.txt letters.txt
git commit -m initial
git branch side
create_files "+"
git commit -a -m master
git checkout side
create_files "-"
git commit -a -m side
mkdir -p .git/rr-cache
# On this history we changed an empty line to +; merge
# with another history that changed it to -
git checkout master^0
git merge side
# The above should have conflicted. The resolution is to '='
create_numbers "="
git rerere
git rerere status
git rerere diff
cat numbers.txt
cat letters.txt
-- 8< --
Now, immediately after this sequence, rerere will give you an disaster.
^ permalink raw reply
* Re: default behaviour for `gitmerge` (no arguments)
From: Junio C Hamano @ 2010-01-11 19:43 UTC (permalink / raw)
To: Gareth Adams; +Cc: git
In-Reply-To: <loom.20100111T185144-655@post.gmane.org>
Gareth Adams <gareth.adams@gmail.com> writes:
> Unfortunately my other option is:
>
> git pull; ...; git checkout otherbranch; git merge myremote/otherbranch
>
> which is annoying extra typing.
Replace 'pull' with 'fetch' and a bit more regular pattern would emerge.
The code indeed knows (as you can see "git pull" can figure it out) what
other ref the current branch is configured to merge with by default.
There is even a plumbing to do this for script writers.
$ git for-each-ref --format='%(upstream)' $(git symbolic-ref HEAD)
We can teach this short-hand to "git merge", perhaps:
$ git merge --default
But "no argument" cannot be the short-hand, because...
> 1) At the moment, `git merge` does nothing. Except mock me for not giving it a
> command in a format it recognises. This change wouldn't have any effect that
> would cause anyone a problem
... except for people who uses a script that does
commits=
while some condition
do
commit=$(find some other commit that should be merged)
commits="$commits$commit "
done
git merge $commits
and expect the last step will fail without doing any damage when the loop
finds no new developments. "no argument means --default" will break their
scripts.
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Fredrik Kuivinen @ 2010-01-11 19:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Miles Bader, Jeff King, Nguyen Thai Ngoc Duy, git
In-Reply-To: <alpine.LFD.2.00.1001111124480.17145@localhost.localdomain>
On Mon, Jan 11, 2010 at 20:29, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Mon, 11 Jan 2010, Fredrik Kuivinen wrote:
>>
>> Any ideas on how this can be explained?
>
> Could it be a bad 'strstr()' implementation?
>
> Try a complex pattern ("qwerty.*as" finds the same line), and see if that
> too is slower than before. If that is faster than it used to be (with
> --no-ext-grep, of course), then it's strstr() that is badly implemented.
Ah, yes, that's it. With the pattern "qwerty.*as" I get 2.5s with the
patch and 6s without.
Thanks.
- Fredrik
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Linus Torvalds @ 2010-01-11 19:29 UTC (permalink / raw)
To: Fredrik Kuivinen
Cc: Junio C Hamano, Miles Bader, Jeff King, Nguyen Thai Ngoc Duy, git
In-Reply-To: <4c8ef71001111119p253170f8q37bcd3708d894a62@mail.gmail.com>
On Mon, 11 Jan 2010, Fredrik Kuivinen wrote:
>
> Any ideas on how this can be explained?
Could it be a bad 'strstr()' implementation?
Try a complex pattern ("qwerty.*as" finds the same line), and see if that
too is slower than before. If that is faster than it used to be (with
--no-ext-grep, of course), then it's strstr() that is badly implemented.
For me, on x86-64 (Fedora-12), strstr() seems to do pretty well. But it's
easy to do a stupid implementation of strstr that does a 'strlen()' first,
for example, and thus always traverses all data _twice_ etc. Depending on
cache sizes etc, that can end up killing performance (or not mattering
much at all..)
Linus
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Fredrik Kuivinen @ 2010-01-11 19:26 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Miles Bader, Jeff King, Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vvdf9402f.fsf@alter.siamese.dyndns.org>
[Resending as the first copy didn't reach the list.]
On Mon, Jan 11, 2010 at 07:39, Junio C Hamano <gitster@pobox.com> wrote:
>
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > It doesn't matter. Since we do the line-by-line thing, the input is always
> > so short that DFA vs NFA vs BM vs other-clever-search doesn't matter.
> > There is no scaling - the grep buffer tends to be too small for the
> > algorithm to matter.
> >
> > And the reason we do things line-by-line is that we need to then output
> > things line-per-line.
>
> Here is an experimental patch; first, some numbers (hot cache best of 5 runs).
I get some very unexpected results with this patch. (best of 5 runs):
before:
time git grep --no-ext-grep qwerty
drivers/char/keyboard.c: "qwertyuiop[]\r\000as"
/* 0x10 - 0x1f */
real 0m3.531s
user 0m3.056s
sys 0m0.468s
after:
time git grep --no-ext-grep qwerty
drivers/char/keyboard.c: "qwertyuiop[]\r\000as"
/* 0x10 - 0x1f */
real 0m4.794s
user 0m4.380s
sys 0m0.404s
with external grep:
time git grep qwerty
drivers/char/keyboard.c: "qwertyuiop[]\r\000as"
/* 0x10 - 0x1f */
real 0m1.236s
user 0m0.668s
sys 0m0.544s
So, if I haven't messed up the benchmark, it seems that Junio's patch
makes things go _slower_. I don't understand at all why I get these
results...
This is on a laptop with an Intel T2080 processor running Ubuntu 9.10.
Any ideas on how this can be explained?
- Fredrik
^ permalink raw reply
* Re: [PATCH 9/9] rerere forget path: forget recorded resolution
From: Johannes Sixt @ 2010-01-11 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4omte72j.fsf@alter.siamese.dyndns.org>
On Montag, 11. Januar 2010, Junio C Hamano wrote:
> I ended up doing this myself. As we are dropping the postimage and adding
> a new MERGE_RR entry, I also think that it is safer to update the preimage
> with the conflict we got for this round, so I added that as well.
Thank you, it appears to work as expected. It is actually very important to
update the preimage as well, otherwise, the new postimage can contain
unrelated additional changes.
> However, I think there is a room for improvement in preimage handling.
>
> Currently, the rerere database is indexed with the conflict hash and for
> each conflict hash you can record a single preimage-postimage pair to
> replay. But you can have conflicts with the same conflict hash, but with
> slightly different contexts outside the conflicted region, and the right
> resolution can be different depending on the outside context.
I did encounter a case where the same resolution would apply to all conflicts
that have the same conflict hash, so it's not quite what you talk about. But
not all conflicts were automatically resolved. I haven't yet analyzed what
happened - it could just be that the xdl_merge call fails due to the
differences in the text immediately outside the conflict markers.
> In the traditional implementation, I punted this issue by noticing
> conflicts in the three-way merge between pre, post and this images. If
> preimage is too different from the conflicted contents we got during this
> merge, then the previous resolution should not apply.
>
> But I think the right solution would be to have more than one preimage and
> postimage pairs (preimage.0 vs postimage.0,... etc.) and try to use each
> of them in handle_path() until it finds one that can be used to cleanly
> merge with the conflict we got in thisimage during this round.
The situation happens rarely, so I don't know if we should care. OTOH, *when*
the situation arises, and a recorded resolution is applied incorrectly, it
may be quite annoying. Dunno.
-- Hannes
^ permalink raw reply
* Re: How to check new commit availability without full fetch?
From: Junio C Hamano @ 2010-01-11 19:20 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Robin Rosenberg, SLONIK.AZ, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.1001111257300.10143@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> On Mon, 11 Jan 2010, Junio C Hamano wrote:
>
>> Robin Rosenberg <robin.rosenberg@dewire.com> writes:
>>
>> > söndagen den 10 januari 2010 12.12.09 skrev Leo Razoumov:
>> >> Hi List,
>> >> I am trying to find a way to check availability of new commits
>> >> *before* doing fetch or pull. Unfortunately, neither fetch nor pull
>> >> take "--dry-run" option (unlike push)
>> >
>> > Fetch has --dry-run. It's a fairly new option. The drawback is that it
>> > still does the fetch, but it does not update the refs. If you re.run it
>> > again it'll be quicker.
>>
>> Doesn't that worry us if it really is quicker?
>>
>> If --dry-run doesn't update the refs, why do the objects that were
>> transferred by them not get asked the next time? There must be a bug
>> somewhere, but it is getting late already, so I'll leave it to experts in
>> the transfer area to figure it out...
>
> What about builtin-fetch.c:quickfetch() ?
Ahh, you are right. It walks from objects the remote side told us are at
the tip, and stops at what we know are complete (i.e. reachable from our
tip of objects); immediately after --dry-run slurped objects, the next
fetch will prove everything is locally available and complete before going
over the network.
But either I am very confused or the use of fields from "struct ref" is
unintuitive in this codepath.
Why does it feed ref->old_sha1? We are feeding _their_ tip commits to:
rev-list --objects --stdin --not --all
and expecting it to report failure when some of their tip commits lead to
what we don't have yet. The reason why we have old_sha1[] vs new_sha1[]
is because we want to report what changed from what, and also to protect
us from simultaneous updates by doing compare-and-swap using the value we
read from our refs when we started in old_sha1[], so I would have expected
that ref_map elements would have _their_ commits on the new_sha1[] side,
but apparently that is not what is happening, and it has been this way for
a long time. The use of old_sha1[] came from 4191c35 (git-fetch: avoid
local fetching from alternate (again), 2007-11-11), so it is a lot more
likely that I am confused than the code is wrong and nobody noticed so
far.
What am I missing?
^ permalink raw reply
* Git bin permissions
From: kp @ 2010-01-11 18:54 UTC (permalink / raw)
To: git
In-Reply-To: <1b727e9e1001111052t5cb6f604tb7936bd627c5f9f7@mail.gmail.com>
Hello All,
It looks like my IT came in and destroyed permissions on my
git/gitosis install. Now I'm getting permission denied error while
trying to run a git push.
git/bin/gitosis-run-hook: Permission denied
I need to know the correct permissions for gitosis-init,
gitosis-run-hook, gitosis-serve. Can someone please give me an ls -la
output?
Thanks,
Alex
^ permalink raw reply
* default behaviour for `gitmerge` (no arguments)
From: Gareth Adams @ 2010-01-11 18:49 UTC (permalink / raw)
To: git
Hi there, long time user; first time caller here.
I wanted to suggest an improvement to git-merge which will either save some
typing or save some network resources. It won't save huge amounts of either but
every little helps!
Currently, some of my colleagues frequently end up typing:
git pull; ...; git checkout otherbranch; git pull
Now, we have quite a low commit rate, it's unlikely (albeit vaguely possible)
that two people are working on the branch at the same time. This means the
second pull is doing a fetch which it effectively pointless.
Now of course this is a tiny amount of wastage, and while I could argue that it
would be an issue under poor network conditions that's not my point. As a coder
I'd want to get rid of the redundant fetch if I know it's redundant.
Unfortunately my other option is:
git pull; ...; git checkout otherbranch; git merge myremote/otherbranch
which is annoying extra typing. Even with tab completion, it's redundant extra
typing because in these cases I'm trying to merge with the branch being tracked.
My suggestion is that `git merge` defaults to the same merge that a `git pull`
would perform, and there are 2 extra factors that make me think it's a workable
idea:
1) At the moment, `git merge` does nothing. Except mock me for not giving it a
command in a format it recognises. This change wouldn't have any effect that
would cause anyone a problem
2) When I checkout a branch which has unmerged changes in the tracking branch,
git *tells me* what branch I will be taking action with "Your branch is behind
the tracked remote branch '...' by 4 commits, and can be fast-forwarded" - but
then makes me type it out explicitly anyway!
I appreciate that there are many workflows where there is an advantage in
performing a second pull in case there are additional changes since the first
pull, but I still think there is a string case for git merge having a more
sensible default, as git pull does.
What do you think?
Thanks,
Gareth
^ permalink raw reply
* Re: Problem creating commits/trees with commit-tree/mktree
From: Avery Pennarun @ 2010-01-11 18:38 UTC (permalink / raw)
To: Gavin Beatty; +Cc: git
In-Reply-To: <f6d77fed1001111014g73a06923na05cd14d37968b04@mail.gmail.com>
On Mon, Jan 11, 2010 at 1:14 PM, Gavin Beatty <gavinbeatty@gmail.com> wrote:
> I can create new blobs and trees but can't figure out how to commit a
> new tree/blob _with_ the old tree.
[...]
> I get a commit with treefileisin/file.txt. I haven't included the
> other trees/files so they are gone in this commit. How do I include
> them? Is commit-tree the wrong tool?
When I'm doing similar things, I often prefer just using a temporary
git index file to keep track of my intermediate trees. Just set
GIT_INDEX_FILE to point at a temporary file; then you can use
git-read-tree to read in an old tree, and git-update-index
(particularly with the --stdin flag) to update it. Then you can use
git-write-tree to convert the temporary index into a real tree object.
Have fun,
Avery
^ permalink raw reply
* Re: Problem creating commits/trees with commit-tree/mktree
From: Shawn O. Pearce @ 2010-01-11 18:17 UTC (permalink / raw)
To: Gavin Beatty; +Cc: git
In-Reply-To: <f6d77fed1001111014g73a06923na05cd14d37968b04@mail.gmail.com>
Gavin Beatty <gavinbeatty@gmail.com> wrote:
> I want to write commits to a branch without touching the index or
> having a checkout (for a git subcommand I'm writing).
>
> I can create new blobs and trees but can't figure out how to commit a
> new tree/blob _with_ the old tree.
>
> Currently, I do something a lot like:
>
> objsha=$(echo 'contents' | git hash-object -w --stdin)
> objtreesha=$(printf "100644 blob $objsha\tfile.txt\000" | git mktree -z)
> newtreesha=$(printf "040000 tree $objtreesha\ttreefileisin\000" | git mktree -z)
You aren't feeding in the old tree contents as part of this command.
If you are really doing this via a script, you should look at
git-fast-import. Its faster, and its language better supports
this notion of editing an existing tree.
--
Shawn.
^ permalink raw reply
* Problem creating commits/trees with commit-tree/mktree
From: Gavin Beatty @ 2010-01-11 18:14 UTC (permalink / raw)
To: git
Hello,
I want to write commits to a branch without touching the index or
having a checkout (for a git subcommand I'm writing).
I can create new blobs and trees but can't figure out how to commit a
new tree/blob _with_ the old tree.
Currently, I do something a lot like:
objsha=$(echo 'contents' | git hash-object -w --stdin)
objtreesha=$(printf "100644 blob $objsha\tfile.txt\000" | git mktree -z)
newtreesha=$(printf "040000 tree $objtreesha\ttreefileisin\000" | git mktree -z)
echo 'commit msg' | git commit-tree $newtreesha -p $(git rev-parse
refs/heads/new)
I get a commit with treefileisin/file.txt. I haven't included the
other trees/files so they are gone in this commit. How do I include
them? Is commit-tree the wrong tool?
Is there some way to use git ls-tree that I don't know about?
Gavin
--
Gavin Beatty
SEMPER UBI SUB UBI
^ permalink raw reply
* Re: How to check new commit availability without full fetch?
From: Nicolas Pitre @ 2010-01-11 17:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin Rosenberg, SLONIK.AZ, Git Mailing List
In-Reply-To: <7vljg5ukol.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 912 bytes --]
On Mon, 11 Jan 2010, Junio C Hamano wrote:
> Robin Rosenberg <robin.rosenberg@dewire.com> writes:
>
> > söndagen den 10 januari 2010 12.12.09 skrev Leo Razoumov:
> >> Hi List,
> >> I am trying to find a way to check availability of new commits
> >> *before* doing fetch or pull. Unfortunately, neither fetch nor pull
> >> take "--dry-run" option (unlike push)
> >
> > Fetch has --dry-run. It's a fairly new option. The drawback is that it
> > still does the fetch, but it does not update the refs. If you re.run it
> > again it'll be quicker.
>
> Doesn't that worry us if it really is quicker?
>
> If --dry-run doesn't update the refs, why do the objects that were
> transferred by them not get asked the next time? There must be a bug
> somewhere, but it is getting late already, so I'll leave it to experts in
> the transfer area to figure it out...
What about builtin-fetch.c:quickfetch() ?
Nicolas
^ permalink raw reply
* Re: [PATCH/RFC] filter-branch: Fix to allow replacing submodules with another content
From: Johannes Schindelin @ 2010-01-11 18:02 UTC (permalink / raw)
To: Michal Sojka; +Cc: git
In-Reply-To: <1263227634-11259-1-git-send-email-sojkam1@fel.cvut.cz>
Hi,
On Mon, 11 Jan 2010, Michal Sojka wrote:
> When git filter-branch is used to replace a submodule with another
> content, it always fails on the first commit. Consider a repository with
> directory submodule containing a submodule. If I want to remove the
> submodule and replace it with a file, the following command fails.
>
> git filter-branch --tree-filter 'rm -rf submodule &&
> git rm -q submodule &&
> mkdir submodule &&
> touch submodule/file'
>
> The error message is:
> error: submodule: is a directory - add files inside instead
>
> The reason is that git diff-index, which generates a part of the list of
> files to update-index, emits also the removed submodule even if it was
> replaced by a real directory.
>
> Adding --ignored-submodules solves the problem for me and
> tests in t7003-filter-branch.sh passes correctly.
Have you tested replacing one revision of a submodule with another?
Ciao,
Dscho
^ permalink raw reply
* Re: How to check new commit availability without full fetch?
From: Leo Razoumov @ 2010-01-11 17:35 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.2.00.1001111149150.10143@xanadu.home>
On 2010-01-11, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Mon, 11 Jan 2010, Leo Razoumov wrote:
>
> > On 2010-01-10, Nicolas Pitre <nico@fluxnic.net> wrote:
> > >
> > > You still don't answer my question though. Again, _why_ do you need to
> > > know about remote commit availability without fetching them?
> > >
> >
> > I use git to track almost all my data (code and otherwise) and spread
> > it between several computers. I end up with several local repos having
> > the same local branches. It happens once in a while that I fetch into
> > a given remote/foo from several local foo branches from different
> > machines and the operation fails. It happens because the commits have
> > not been yet consistently distributed among the repos. To do the
> > forensics and figure out who should update whom first I need a quick
> > and non-destructive way to fetch dry-run.
>
>
> There is probably something awkward about your setup then.
>
> Normally you should have a remote description for any of the remote
> repositories you fetch from. So if you have, say, remote machine_a with
> repo foo, machine_b with repo bar, and machine_c with repo baz, then
> fetching any of those will _only_ mirror locally the state of those
> remote repositories. There is no ordering required as there can't be
> any conflicts in the mere fact of mirroring what the other guys have.
> That's what remote tracking branches are for: they follow the state of a
> remote repository and are never altered by local changes. And you can
> have as many of those as you wish and they will never conflict with each
> other as each remote description is independent. And this is true
> whether or not the remote repository lives on the same machine (that
> would be a remote directory in that case).
>
Setup might be, indeed, awkward but it handles very diverse tasks.
As I said in my earlier emails different repos fetch into the *same* remote/foo.
So there could be conflicts and using fetch -f could cause loss of data.
Before switching to git I used mercurial for the same purpose and it
has command that are equivalent to fetch --dry-run.
--Leo--
^ permalink raw reply
* Re: [PATCH] fast-import: tag may point to any object type
From: Shawn O. Pearce @ 2010-01-11 17:14 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git, Junio C Hamano
In-Reply-To: <1263186165-23920-1-git-send-email-dpotapov@gmail.com>
Dmitry Potapov <dpotapov@gmail.com> wrote:
> If you tried to export the official git repository, and then to import it
> back then git-fast-import would die complaining that "Mark :1 not a commit".
>
> Accordingly to a generated crash file, Mark 1 is not a commit but a blob,
> which is pointed by junio-gpg-pub tag. Because git-tag allows to create such
> tags, git-fast-import should import them.
>
> Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
> ---
> fast-import.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/fast-import.c b/fast-import.c
> index cd87049..e99990d 100644
> --- a/fast-import.c
> +++ b/fast-import.c
> @@ -2305,6 +2305,7 @@ static void parse_new_tag(void)
> struct tag *t;
> uintmax_t from_mark = 0;
> unsigned char sha1[20];
> + enum object_type type = OBJ_COMMIT;
NAK.
Your patch is the right idea. But you need to make sure all of
the branch arms are handled correctly.
That is, if we do this, the get_sha1() on line 2459 should also
permit non-commit objects, and the lookup_branch() earlier up on
line 2451 should do "type = OBJ_COMMIT".
--
Shawn.
^ permalink raw reply
* Re: How to check new commit availability without full fetch?
From: Nicolas Pitre @ 2010-01-11 17:04 UTC (permalink / raw)
To: Leo Razoumov; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <ee2a733e1001110822t1b04c1ccg9b6eb5489b69783d@mail.gmail.com>
On Mon, 11 Jan 2010, Leo Razoumov wrote:
> On 2010-01-10, Nicolas Pitre <nico@fluxnic.net> wrote:
> >
> > You still don't answer my question though. Again, _why_ do you need to
> > know about remote commit availability without fetching them?
> >
>
> I use git to track almost all my data (code and otherwise) and spread
> it between several computers. I end up with several local repos having
> the same local branches. It happens once in a while that I fetch into
> a given remote/foo from several local foo branches from different
> machines and the operation fails. It happens because the commits have
> not been yet consistently distributed among the repos. To do the
> forensics and figure out who should update whom first I need a quick
> and non-destructive way to fetch dry-run.
There is probably something awkward about your setup then.
Normally you should have a remote description for any of the remote
repositories you fetch from. So if you have, say, remote machine_a with
repo foo, machine_b with repo bar, and machine_c with repo baz, then
fetching any of those will _only_ mirror locally the state of those
remote repositories. There is no ordering required as there can't be
any conflicts in the mere fact of mirroring what the other guys have.
That's what remote tracking branches are for: they follow the state of a
remote repository and are never altered by local changes. And you can
have as many of those as you wish and they will never conflict with each
other as each remote description is independent. And this is true
whether or not the remote repository lives on the same machine (that
would be a remote directory in that case).
And even if most if not all those remotes are actually copies of each
others, then the first fetch to occur will transfer the new objects
while fetching the other ones will simply notice that the required
objects are already available locally and only the ref will be updated.
The ordering comes into play when it is time to _merge_ those remote
branches into, say, the local master branch. That's why it is probably
a good thing to use fetch+merge instead of pull in this case. But this
is then a local matter and nothing that depends on the fetch ordering.
Nicolas
^ permalink raw reply
* [PATCH/RFC] filter-branch: Fix to allow replacing submodules with another content
From: Michal Sojka @ 2010-01-11 16:33 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Michal Sojka
When git filter-branch is used to replace a submodule with another
content, it always fails on the first commit. Consider a repository with
directory submodule containing a submodule. If I want to remove the
submodule and replace it with a file, the following command fails.
git filter-branch --tree-filter 'rm -rf submodule &&
git rm -q submodule &&
mkdir submodule &&
touch submodule/file'
The error message is:
error: submodule: is a directory - add files inside instead
The reason is that git diff-index, which generates a part of the list of
files to update-index, emits also the removed submodule even if it was
replaced by a real directory.
Adding --ignored-submodules solves the problem for me and
tests in t7003-filter-branch.sh passes correctly.
Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
---
git-filter-branch.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 195b5ef..d4ac7fb 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -331,7 +331,7 @@ while read commit parents; do
die "tree filter failed: $filter_tree"
(
- git diff-index -r --name-only $commit &&
+ git diff-index -r --name-only --ignore-submodules $commit &&
git ls-files --others
) > "$tempdir"/tree-state || exit
git update-index --add --replace --remove --stdin \
--
1.6.6
^ permalink raw reply related
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Linus Torvalds @ 2010-01-11 16:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miles Bader, Jeff King, Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vtyusr4r7.fsf@alter.siamese.dyndns.org>
On Mon, 11 Jan 2010, Junio C Hamano wrote:
>
> An ObviouslyRightThing fix is this two-liner. We shouldn't lookahead if
> we want to do something more than just skipping when we see an unmatch for
> the line we are currently looking at.
Ack. Works for me. And with that, I'd love for it to go in, and get rid of
the external grep. Performance is now a non-issue (it goes both ways), and
the internal grep doesn't have the bug with separators between multi-line
greps.
And dropping the external one gets rid of all the issues with PATHs, crap
'grep' implementations, and removes actual code. Goodie.
Linus
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Junio C Hamano @ 2010-01-11 16:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Miles Bader, Jeff King, Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vtyusr4r7.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Meh. I checked pre-context codepath before sending the patch and was very
> satisfied that René did the right thing in 49de321 (grep: handle pre
> context lines on demand, 2009-07-02), but somehow forgot about the post
> context codepath.
Just to clarify, it was *I* who forgot to check the post context codepath
while adding the lookahead; I didn't mean René forgot anything in 49de321.
^ permalink raw reply
* [PATCH 4/4] Documentation: add new git-svn branch/tag options --username and --commit-url
From: Igor Mironov @ 2010-01-11 16:22 UTC (permalink / raw)
To: git; +Cc: Eric Wong
Signed-off-by: Igor Mironov <igor.a.mironov@gmail.com>
---
Documentation/git-svn.txt | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 4cdca0d..8dbf9d1 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -239,6 +239,19 @@ discouraged.
where <name> is the name of the SVN repository as specified by the -R option to
'init' (or "svn" by default).
+--username;;
+ Specify the SVN username to perform the commit as. This option overrides
+ configuration property 'username'.
+
+--commit-url;;
+ Use the specified URL to connect to the destination Subversion
+ repository. This is useful in cases where the source SVN
+ repository is read-only. This option overrides configuration
+ property 'commiturl'.
++
+ git config --get-all svn-remote.<name>.commiturl
++
+
'tag'::
Create a tag in the SVN repository. This is a shorthand for
'branch -t'.
--
1.6.6.106.ge2de8
^ permalink raw reply related
* Re: How to check new commit availability without full fetch?
From: Leo Razoumov @ 2010-01-11 16:22 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.1001102055070.10143@xanadu.home>
On 2010-01-10, Nicolas Pitre <nico@fluxnic.net> wrote:
>
> You still don't answer my question though. Again, _why_ do you need to
> know about remote commit availability without fetching them?
>
I use git to track almost all my data (code and otherwise) and spread
it between several computers. I end up with several local repos having
the same local branches. It happens once in a while that I fetch into
a given remote/foo from several local foo branches from different
machines and the operation fails. It happens because the commits have
not been yet consistently distributed among the repos. To do the
forensics and figure out who should update whom first I need a quick
and non-destructive way to fetch dry-run.
--Leo--
^ 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