* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Junio C Hamano @ 2008-11-04 0:44 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Jeff King, Sam Vilain, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Christian Couder, Kai Blin
In-Reply-To: <20081104000207.GA29458@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
>> Ok, I agree that may be a problem.
>>
>> But that would not change if you only changed the default behaviour from
>> matching to _this branch_. You need to also teach a new mode of operation
>> to send-pack/receive-pack pair, which is to "update the same branch as the
>> one I am on locally, but do not do anything if there is no such branch
>> over there". I do not think we have such a mode of operation currently.
>
> You're right.
Perhaps "git push --no-create"?
In hindsight, _if_ we did not have to worry about backward compatibility
at all, I might agree that the way "git push" ought to work with least
surprise would be:
* "git push" is the same as "git push origin" (override 'origin' with
branch.$current_branch.remote);
* "git push $remote" is the same as "git push --no-create $remote HEAD"
(override 'HEAD' with remote.$remote.push);
* "git push $remote $any_non_empty_refspec" does what it is told without
configuration interfering.
Current behaviour satisfies the first one and the third one. Instead of
the second, the current behaviour is:
* "git push $remote" is the same as "git push $remote :" (override ':'
with remote.$remote.push).
>> By the way, didn't we add a feature to let you say "git push $there :"
>> which is to do what "git push --matching $there" would do?
>
> I don't know, I thought git push --matching $remote would be the same as
> git push $remote ?
I think the point of "push --matching" (or an explicit "push $there :") is
so that you can defeat what you configured. For example, you could have:
[branch "master"]
remote = gitster
[remote "gitster"]
url = gitster:/pub/git/git.git/
push = HEAD
And with such a configuration, "git push" or "git push gitster" would only
push to the current branch.
You can countermand with "push gitster master next", of course, but you
would need a way to ask for the matching from the command line without
listing all the names, hence you would say "push gitster :".
I think you meant to give the --matching option the same efffect. My
comment is that you do not need a new option, as we already have that
feature.
^ permalink raw reply
* Re: [PATCH] contrib/hooks/post-receive-email: Make revision display configurable
From: Pete Harlan @ 2008-11-04 0:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7vy700tmdx.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Pete Harlan <pgit@pcharlan.com> writes:
>
>> Add configuration option hooks.showrev, letting the user override how
>> revisions will be shown in the commit email.
>>
>> Signed-off-by: Pete Harlan <pgit@pcharlan.com>
>> Acked-By: Andy Parkins <andyparkins@gmail.com>
>> @@ -390,8 +396,13 @@ generate_update_branch_email()
>>
>> echo ""
>> echo $LOGBEGIN
>> - git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
>> - git rev-list --pretty --stdin $oldrev..$newrev
>> + git rev-parse --not --branches |
>> + grep -v $(git rev-parse $refname) |
>> + git rev-list --stdin $oldrev..$newrev |
>> + while read onerev
>> + do
>> + eval $(printf "$showrev" $onerev)
>> + done
>
> This would make the default "non-custom" case much less efficient. If we
> really cared, perhaps we could do something like this...
>
> git rev-parse --not --branches |
> grep -v "^$(git-rev-parse --not $refname)\$" |
> case "$using_custom_showrev" in
> yes)
> git rev-list --stdin $oldrev..$newrev |
> while read onerev
> do
> done
> ;;
> *)
> git rev-list --pretty --stdin $oldrev..newrev
> ;;
> esac
>
> But I suspect we do not care too much about it.
I agree about the efficiency; that bothered me when I wrote the patch,
but figured the lack of efficiency wouldn't be noticeable.
OTOH, it still bothers me; I'll write up a v2 patch that does something
much more like what you suggest.
Is it easier at this point for you to have a new patch that applies on
top of my previous patch, or a wholesale replacement for it? Or is
what's done done and that's the end of it for something this minor?
Thanks to you both for your time and work,
--Pete
>
> Will apply as submitted. Thanks
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] git send-email: allow any rev-list option as an argument.
From: Junio C Hamano @ 2008-11-04 1:04 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Jeff King, git
In-Reply-To: <20081103091513.GC13930@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> As a summary, I'd say that I like both (1) and (3) because those are
> handy, short, and either completely or mostly backward compatible. My
> way would be to go down (1) and add a alias.s-e = !git send-email -F in
> my .gitconfig.
>
> What do you think ?
I wonder if we can do this even without an explicit -F.
What command line arguments does send-email take, and what options would
we want to give the underlying format-patch? Can't you sift them without
ambiguity?
The current syntax is:
git send-email <flags>... <file|dir>...
I am wondering if we can just extend it to:
git send-email <flags>... <<file|dir>...|rev>
E.g. we should be able to parse this out:
git send-email --to git@vger.kernel.org -M --suppress-cc=all origin
and notice "--to git@vger.kernel.org" and "--suppress-cc" are for
send-email, guess "-M" (or anything that is outside the current
send-email's vocabulary) is meant for format-patch, and if there is no
file or directory called "origin" then decide that the user wants to run
format-patch, and act as a front-end as if the user did:
git format-patch -o tmp.$$ -M origin &&
... perhaps do your --annotate and --compose here by launching
... the editor...
git send-email --to git@vger.kernel.org --suppress-cc=all tmp.$$ &&
rm -fr tmp.$$
If you happen to have a file or a directory called origin, it would be
safer for users if the command errored out asking for disambiguation. The
user can either say "./origin" or "origin^0" to disambiguate between them.
Hmm?
^ permalink raw reply
* Re: Intensive rename detection
From: Andrew Arnott @ 2008-11-04 1:18 UTC (permalink / raw)
To: git
In-Reply-To: <216e54900811031717j70669868p3c7503357ceb5138@mail.gmail.com>
I'm refactoring a library including renaming both files and
directories. A few lines of each file are also changed, but they are
substantially unchanged in content. I've done a git add to put all my
changes into the index, but a git status shows that git only detected
a few of the renames... most of them are delete-add operations. Is
there anything I can do to help git recognize the rename so that
history is preserved across this commit?
Thanks.
^ permalink raw reply
* Re: Are binary xdeltas only used if you use git-gc?
From: Nicolas Pitre @ 2008-11-04 1:18 UTC (permalink / raw)
To: Thanassis Tsiodras; +Cc: Matthieu Moy, Jakub Narebski, git
In-Reply-To: <f1d2d9ca0811031453p49390911p956149ca76b9b80d@mail.gmail.com>
On Tue, 4 Nov 2008, Thanassis Tsiodras wrote:
> RESOLVED!!!
>
> Finally...
> What happened was actually quite reasonable, in hindsight...
> As I said in the original mail, this was what I did:
>
> cp version7.1.tar version7.2.tar
> git add version7.2.tar
> git commit -m "same data as old, so git will use old blob"
> echo MAGICPLACE read below...
> cp /path/to/work/realNewVersion7.2.tar version7.2.tar
> git add version7.2.tar
> git commit -m "and now, commit the really new version, so git can xdelta"
> git push --thin
>
> The problem was solved (that is, the "git push" became optimal,
> when I added a "git push" right after the MAGICPLACE mark above...
> In that way, the remote repo learned about the "dummy" commit that
> referenced the old blob... and when I did the subsequent "git push"
> at the end, the remote side could see that it already had this "dummy"
> commit to "xdelta on", and that it only needed the delta...
>
> Originally, when I used only one "git push --thin" at the end, the remote
> side didn't have the "dummy" commit, so it probably said: "I can't
> apply a delta, give me the full object".
Oh! But of course...
In fact, the way thin packs work is to store delta against a base object
which is not included in the pack. Those objects which are not included
but used as delta base are currently only the previous version of a file
which is part of the update to be pushed/fetched. In other words, there
must be a previous version under the same name for this to work. Doing
otherwise wouldn't scale if the previous commit had thousands of files
to test against.
But this particularity had escaped my mind somehow.
> Phew.
>
> So it seems that if you must introduce a new file that is
> very similar to an existing one (in my case, a new version
> of software kept in an uncompressed .tar file),
> you have to do what I did above to allow for optimal "git push"es:
> that is:
>
> 1. Create the new filename by just copying the old
> (so the old blob is used)
> 2. commit
> 3. PUSH
> 4. copy the real new file
> 5. commit
> 6. PUSH.
>
> If you omit the middle PUSH in step 3, neither "git push", nor "git push --thin"
> can realize that this new file can be "incrementally built" on the remote side
> (even though git-gc totally squashes it in the pack).
Right. Those thin packs were designed for different versions of the
same file in mind, not different files with almost the same content.
This could possibly be improved at some point...
Nicolas
^ permalink raw reply
* Re: Are binary xdeltas only used if you use git-gc?
From: Junio C Hamano @ 2008-11-04 1:36 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Thanassis Tsiodras, Matthieu Moy, Jakub Narebski, git
In-Reply-To: <alpine.LFD.2.00.0811031959070.13034@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> Right. Those thin packs were designed for different versions of the
> same file in mind, not different files with almost the same content.
> This could possibly be improved at some point...
Wouldn't using a large --window help by going across name-hash boundaries?
^ permalink raw reply
* Re: Intensive rename detection
From: Junio C Hamano @ 2008-11-04 1:39 UTC (permalink / raw)
To: Andrew Arnott; +Cc: git
In-Reply-To: <216e54900811031718o4cc81294sc0c32be1e71b9372@mail.gmail.com>
"Andrew Arnott" <andrewarnott@gmail.com> writes:
> I'm refactoring a library including renaming both files and
> directories. A few lines of each file are also changed, but they are
> substantially unchanged in content. I've done a git add to put all my
> changes into the index, but a git status shows that git only detected
> a few of the renames... most of them are delete-add operations. Is
> there anything I can do to help git recognize the rename so that
> history is preserved across this commit?
There is no need to do anything at commit time.
After making the commit, you can look at it with lower similarity
threashold, e.g.
git show --stat -M1 HEAD
The default behaviour IIRC corresponds to -M5 (that is 50%).
^ permalink raw reply
* Re: Are binary xdeltas only used if you use git-gc?
From: Nicolas Pitre @ 2008-11-04 1:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thanassis Tsiodras, Matthieu Moy, Jakub Narebski, git
In-Reply-To: <7v3ai8tgq9.fsf@gitster.siamese.dyndns.org>
On Mon, 3 Nov 2008, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > Right. Those thin packs were designed for different versions of the
> > same file in mind, not different files with almost the same content.
> > This could possibly be improved at some point...
>
> Wouldn't using a large --window help by going across name-hash boundaries?
The issue is to decide what preferred delta base to add to the list of
objects. Currently only objects with the same path as those being
modified are considered.
Nicolas
^ permalink raw reply
* Re: Are binary xdeltas only used if you use git-gc?
From: Junio C Hamano @ 2008-11-04 3:17 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Thanassis Tsiodras, Matthieu Moy, Jakub Narebski, git
In-Reply-To: <alpine.LFD.2.00.0811032053410.13034@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> The issue is to decide what preferred delta base to add to the list of
> objects. Currently only objects with the same path as those being
> modified are considered.
Ah, I was blind (even though that part is my code). Thanks.
^ permalink raw reply
* Re: libxdiff and patience diff
From: Davide Libenzi @ 2008-11-04 3:17 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Git ML
In-Reply-To: <20081104004001.GB29458@artemis.corp>
On Tue, 4 Nov 2008, Pierre Habouzit wrote:
> Hi Davide,
>
> I've been working tonight, trying to make libxdiff support the patience
> diff algorithm, but I've totally failed, because I _thought_ I
> understood what xdl_split was doing, but it appears I don't.
>
>
> [ For the readers playing at home, the patience diff algorithm is
> explained after my sig. ]
>
>
> What I did is to:
> (1) add a flag to the xenv in xdl_split that says that I want a
> patience "split".
> (2) Then in xdl_split, if that bit is set, I compute the longest common
> subsequence from the patience diff.
> (3) for each split it computes I call xdl_recs_cmp on that interval.
>
>
> What I thought it would achieve is that I force some boundaries at which
> libxdiff _must_ resync. Though, it seems that for some reason it doesn't
> work, probably because the "ha" stuff and the boundaries absolutely
> don't work the way I thought it did.
>
> So where is the place I should do that ? I suspect it should be
> partly in xprepare.c but I'm a bit stuck right now.
>
>
> Any pointer on how the stuff in xprepare.c and xdiffi.c work would help
> greatly, it's really not self-evident to me :)
What makes you think it'd self-evident to me? :)
Seriously, I forgot stuff I wrote the last month, this is way beyond my
memory limits.
You definitely need to look at xprepare.c, especially at xdl_trim_ends()
and xdl_cleanup_records(). Lines are re-arranged in indexes, and this
might screw up your logic if you're not prepared for it.
What xdl_split() does, is find the start of an LCS and return the
coordinate. Then xdl_recs_cmp() does the box reducing (first two "for"
loops) and different-lines marking (first and second "if").
- Davide
^ permalink raw reply
* Merging two projects
From: Andrew Arnott @ 2008-11-04 3:33 UTC (permalink / raw)
To: git
I have two projects, both with histories, that I want to merge into
just one library. I'd like to preserve both histories, perhaps as if
there were two branches being merged into one. (Although each project
has its own branches that will make the history interesting).
Is there a standard way to do this?
Thanks.
^ permalink raw reply
* Re: How to send patch series without storing them to disk?
From: Ian Hilt @ 2008-11-04 3:50 UTC (permalink / raw)
To: Liu Yubao; +Cc: git
In-Reply-To: <490EC57E.4080200@gmail.com>
On Mon, 3 Nov 2008, Liu Yubao wrote:
> Hi,
>
> I want to send patches like this:
>
> git format-patch --stdout --no-color -C --thread -n $oldrev..$newrev | ...send...
>
> It seems git-send-email can't read email from stdin.
>
>
> I tried to send one patch using git-send-email, it reported "Syntax: AUTH mechanism".
> git send-email --from <myemail> --to <my-another-email> \
> --smtp-pass <mypass> --smtp-user <myaccount> \
> --smtp-server <the-smtp-server> \
> --smtp-encryption auth \
> 0001-just-a-test.patch
>
> The parameters about smtp are right, I tested with msmtp. What's wrong?
>
> I have MIME::Base64 and Authen::SASL installed and the smtp server doesn't use
> ssl and tls.
Try removing --smtp-encryption and add --envelope-sender <youremail>.
Ian
^ permalink raw reply
* Re: How to send patch series without storing them to disk?
From: Ian Hilt @ 2008-11-04 4:04 UTC (permalink / raw)
To: Liu Yubao; +Cc: git
In-Reply-To: <490EC57E.4080200@gmail.com>
On Mon, 3 Nov 2008, Liu Yubao wrote:
> Hi,
>
> I want to send patches like this:
>
> git format-patch --stdout --no-color -C --thread -n $oldrev..$newrev | ...send...
>
> It seems git-send-email can't read email from stdin.
Currently there is a discussion on the git mailing list concerning a way
to make the following possible:
git send-email $oldrev..$newrev
Here's some more information,
<http://marc.info/?l=git&w=2&r=1&s=git+send-email&q=b>
Ian
^ permalink raw reply
* Re: Intensive rename detection
From: Linus Torvalds @ 2008-11-04 4:22 UTC (permalink / raw)
To: Andrew Arnott; +Cc: git
In-Reply-To: <216e54900811031718o4cc81294sc0c32be1e71b9372@mail.gmail.com>
On Mon, 3 Nov 2008, Andrew Arnott wrote:
>
> I'm refactoring a library including renaming both files and
> directories. A few lines of each file are also changed, but they are
> substantially unchanged in content. I've done a git add to put all my
> changes into the index, but a git status shows that git only detected
> a few of the renames... most of them are delete-add operations. Is
> there anything I can do to help git recognize the rename so that
> history is preserved across this commit?
How many renames do you have? Modern versions of git will do any number of
exact renames, but the (rather expensive) inexact rename detection has a
default limit of something fairly small.
You could try adding
[diff]
renamelimit=0
to your ~/.gitconfig file. It can be quite expensive though.
Linus
^ permalink raw reply
* Re: Intensive rename detection
From: Linus Torvalds @ 2008-11-04 4:23 UTC (permalink / raw)
To: Andrew Arnott; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0811032021210.3419@nehalem.linux-foundation.org>
On Mon, 3 Nov 2008, Linus Torvalds wrote:
>
> You could try adding
>
> [diff]
> renamelimit=0
>
> to your ~/.gitconfig file. It can be quite expensive though.
Oh, and obviously Junio is right that some create/deletes won't be seen as
renames anyway, if you changed enough of the file and/or if the files in
question are so small that they end up being considered rewrites just
because of that.
Linus
^ permalink raw reply
* Re: [PATCH] push: fix local refs update if already up-to-date
From: Jeff King @ 2008-11-04 4:26 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, Junio C Hamano
In-Reply-To: <20081104000745.GA28480@localhost>
On Tue, Nov 04, 2008 at 01:07:45AM +0100, Clemens Buchacher wrote:
> git push normally updates local refs only after a successful push. If
> the remote already has the updates -- pushed indirectly through
> another repository, for example -- we forget to update local tracking
> refs.
I think this goal is a good enhancement.
> The hashcpy for new_ref is now executed more often than absolutely
> necessary. But this is not a critical path, right? So I decided to keep
> things simple.
No, I don't think the loop is tight enough to care about an extra
hashcpy. The minimally invasive change would be to just set
ref->new_sha1 in the UPTODATE code path. IOW, just:
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 298bd71..b8788f2 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -454,6 +454,7 @@ static int do_send_pack(int in, int out, struct remote *remote, const char *dest
if (!ref->deletion &&
!hashcmp(ref->old_sha1, new_sha1)) {
ref->status = REF_STATUS_UPTODATE;
+ hashcpy(ref->new_sha1, new_sha1);
continue;
}
Your patch makes ref->new_sha1 "valid" for every status case. Ordinarily
I would be in favor of that, since it reduces coupling with other parts
of the code (which have to know _which_ status flags provide a useful
value in ->new_sha1). But in this case, I think the value we would be
sticking in is not necessarily useful for every status flag we end up
setting; so any consumers of the ref structure still need to know which
flags set it. So even though it has a defined value, it is not really
"valid" in all cases.
> @@ -224,7 +224,7 @@ static void update_tracking_ref(struct remote *remote, struct ref *ref)
> {
> struct refspec rs;
>
> - if (ref->status != REF_STATUS_OK)
> + if (ref->status != REF_STATUS_OK && ref->status != REF_STATUS_UPTODATE)
> return;
>
> rs.src = ref->name;
Hmm. I was hoping to see more in update_tracking_ref. With your patch,
we end up calling update_ref for _every_ uptodate ref, which results in
writing a new unpacked ref file for each one. And that _is_ a
performance problem for people with large numbers of refs.
So I think we need a check to make sure we aren't just updating with the
same value. Something like:
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 4c17f48..0e66e8f 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -237,8 +237,17 @@ static void update_tracking_ref(struct remote *remote, struct ref *ref)
rs.dst = NULL;
if (!remote_find_tracking(remote, &rs)) {
+ unsigned char old_tracking_sha1[20];
+
if (args.verbose)
fprintf(stderr, "updating local tracking ref '%s'\n", rs.dst);
+
+ if (!resolve_ref(rs.dst, old_tracking_sha1, 0, NULL) ||
+ !hashcmp(old_tracking_sha1, ref->new_sha1)) {
+ free(rs.dst);
+ return;
+ }
+
if (ref->deletion) {
delete_ref(rs.dst, NULL, 0);
} else
Though I am not happy that we have to look up the tracking ref for every
uptodate ref. I think it shouldn't be a big performance problem with
packed refs, though, since they are cached (i.e., we pay only to compare
the hashes, not touch the filesystem for each ref).
> +test_expect_success 'push updates local refs (2)' '
Nit: Just reading the test, it is hard to see what is interesting about
it (though obviously I can blame it back to your commit :) ). Maybe a
more descriptive title like 'push updates uptodate local refs' would
make sense.
-Peff
^ permalink raw reply related
* Re: Intensive rename detection
From: Jeff King @ 2008-11-04 4:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Arnott, git
In-Reply-To: <alpine.LFD.2.00.0811032021210.3419@nehalem.linux-foundation.org>
On Mon, Nov 03, 2008 at 08:22:34PM -0800, Linus Torvalds wrote:
> How many renames do you have? Modern versions of git will do any number of
> exact renames, but the (rather expensive) inexact rename detection has a
> default limit of something fairly small.
I was about to say "git should have complained about turning off the
requested rename detection", but I forgot that we silenced that warning
except for merges.
Maybe it makes sense for "status" or a single "diff" (but definitely not
"log", where it isn't even clear which diff caused it!). I dunno. I find
it clutter for anything except a merge, but if that is in fact what is
happening here, it might have produced one slightly less confused user.
-Peff
^ permalink raw reply
* Re: [Announce] teamGit v0.0.4
From: Abhijit Bhopatkar @ 2008-11-04 4:43 UTC (permalink / raw)
To: Alex Riesen; +Cc: Matthieu Moy, git
In-Reply-To: <20081103182834.GA4180@blimp.localdomain>
On Mon, Nov 3, 2008 at 11:58 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
> Abhijit Bhopatkar, Mon, Nov 03, 2008 14:35:24 +0100:
>> teamGit is a GUI for git,
>> in its final roadmap it aims to aid small closed teams to use git,
>
> What special features does it offer to aid small closed teams?
> Why are they "closed"?
Opps s/closed/close :D , i didn't mean closed vs open etc.
Close means physically close or atleast on the same lan/intranet.
Currently it has no such features as i am concentrating on getting the
base right.
in future i plan to add collaboration facilities like auto
push/pull/rebase to central branch,
auto remote branch management etc.
Abhijt
^ permalink raw reply
* Re: Merging two projects
From: Jeff King @ 2008-11-04 4:56 UTC (permalink / raw)
To: Andrew Arnott; +Cc: git
In-Reply-To: <216e54900811031933n346e8c68se9226e79366c3eb6@mail.gmail.com>
On Mon, Nov 03, 2008 at 07:33:21PM -0800, Andrew Arnott wrote:
> I have two projects, both with histories, that I want to merge into
> just one library. I'd like to preserve both histories, perhaps as if
> there were two branches being merged into one. (Although each project
> has its own branches that will make the history interesting).
>
> Is there a standard way to do this?
You have two options:
- just merge the history as if they were two branches:
# make a new combined repo
mkdir merged && cd merged && git init
# pull in each library
for lib in lib1 lib2; do
git fetch /path/to/$lib master:$lib
git checkout $lib
# do any pre-merging fixups
mkdir $lib
mv * $lib
git add -u
git add $lib
git commit -m "move files into $lib in preparation for project merge"
done
# and then merge; order isn't really important
git checkout lib1
git merge lib2
This method is nice because it preserves the original histories, and
you can still merge from the original projects (if people are still
working on them as individual projects).
Note that this is basically what the subtree merge strategy does, so
you could also use that. I showed all the steps here to give a sense
of what is going on, and because you might want to do additional
fixups besides moving files into the subtree.
- The other alternative is rewriting the history. The advantage here
is that the history looks as if the projects had always been part of
the repo, so there is no big rename event. You can even annotate the
commit messages to indicate which project is being worked on.
The downside, of course, is that having rewritten history, merges
with the original project become more difficult. But that is not a
problem if you are going to throw away the original repositories.
You can accomplish this with filter-branch:
mkdir merged && cd merged && git init
for lib in lib1 lib2; do
git fetch /path/to/$lib master:$lib
git checkout $lib
git filter-branch -f \
--index-filter '
git ls-files -s |
sed "s,\t,&'$lib'/," |
GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
git update-index --index-info &&
mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' \
--msg-filter "sed '1s/^/[$lib] /'" \
$lib
done
and then merge the resulting branches as usual.
Hope that helps.
-Peff
^ permalink raw reply
* Re: CRLF support bugs (was: Re: .gitattributes glob matching broken)
From: Jeff King @ 2008-11-04 5:14 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <83y700alzf.fsf_-_@kalahari.s2.org>
On Mon, Nov 03, 2008 at 05:05:24PM +0200, Hannu Koivisto wrote:
> I suspect one part of that "oddness" was caused by git applying its
> heuristics in checkout as it doesn't use .gitattributes at that
> time.
It _does_ apply them in checkout, you just didn't have a .gitattributes
file yet. So it is part of the same problem.
> For example, it seems that it recognized some of my .sh
> files as text files and the rest as binary files. I suppose I was
> correct to assume that it would be stupid to rely on git guessing
> file type and the only sensible way is to use .gitattributes. If
I think it depends on what's in your scripts, since many people have not
had trouble with the auto-detection. Perhaps some are UTF-16 which
contain NULs?
If the auto-detection is not working, I am sure people would love to see
samples of what fooled it (since it is, after all, just a guess, and we
would like to make the guess more accurate).
> > To "fix" this, you can then do a "git reset --hard" which will respect
> > your .gitattributes (since it is now checked out). And further file
> > creation and checkout should work OK.
>
> Since I'm trying to launch git in a company environment, I think I
> can't rely on people remembering to do that.
Oh, absolutely. I think this is a shortcoming in git. The reset is
simply a workaround until it is actually fixed.
> Actually, even if .gitattributes were applied in checkout, I think
> the whole CRLF support is broken by design because people will have
> to remember to use -n in clone, then enable core.autocrlf support
> and then checkout. This makes it unneccessarily complicated to
Yes, that is a little bit annoying. I think there are four options:
- people set core.autocrlf in their global ~/.gitconfig. The downside,
as you mentioned, is that you might not want it for all projects
- clone should take an extra "options" parameter which can set this up
after doing the 'init'. Like:
git clone -O core.autocrlf=true /path/to/repo
- after setting autocrlf, people need to tell git to re-checkout with
the updated settings. I don't know of a straightforward way to tell
git everything needs to be updated. So I would do:
git ls-files | xargs touch
git reset --hard
which is not ideal. Probably some sort of "re-checkout" option to
git-checkout would be better.
- you could do this "re-checkout" automagically when core.autocrlf is
set via "git config". There are two obvious problems with this
magic, though:
- that may not be what the user wants, if they have work in
progress in the directory. And normally calling "git config"
has no such side effects, so it is certainly unexpected.
- we don't even know when the config is updated, since the user
may simply edit the file behind git's back
So that is a little too magic for my taste.
> I think CRLF conversion support should have some attribute (be it
> .gitattributes attribute or something else) that is somehow
> inherited from the parent repository. It would basically say that
> "you should use platform's native line end type for text files with
> this repository and its children". To go with that, one would
> maybe have a configuration option to tell what that platform
> default line end type is (just in case someone wants to pretend
> Cygwin is Unix or something like that).
I think others have complained before about something like this, in that
it really is a _local_ decision and not a _project_ decision to make. I
am fortunate enough to work exclusively on platforms with sane line
endings, so I don't know what is normal.
But if you really wanted to do such a thing for some set of corporate
users, maybe it would make sense to have a "clone" hook that runs after
init and can set up any relevant config (e.g., by copying certain config
values from the parent repo).
-Peff
^ permalink raw reply
* Re: Intensive rename detection
From: Andrew Arnott @ 2008-11-04 5:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <216e54900811032107p159e98ecn8958f0a78efde8f2@mail.gmail.com>
Awesome. Per Linus' tip, I just noticed at the top of a long list of
messages git said:
warning: too many files, skipping inexact rename detection
So I added the config file change, and that did the trick. Thanks, everyone!
Here's a related but slightly different question: I've been stashing
and unstashing in the midst of all these renames and refactoring, and
now I'm left with some files listed in git status 3 times. I
understand why this is, but I don't know the best way to proceed. Git
is telling me:
$ git status | grep MessageBase
src/DotNetOAuth/Messages/MessageBase.cs: needs merge
src/DotNetOAuth/OAuth/Messages/MessageBase.cs: needs merge
src/DotNetOpenAuth/Messages/MessageBase.cs: needs merge
# unmerged: src/DotNetOAuth/Messages/MessageBase.cs
# unmerged: src/DotNetOAuth/OAuth/Messages/MessageBase.cs
# unmerged: src/DotNetOpenAuth/Messages/MessageBase.cs
I want to end up with MessageBase.cs in
src/DotNetOpenAuth/OAuth/Messages/MessageBase.cs, which ironically is
none of these three. And the couple of lines that changed in the file
need to be merged. Only two of these listed files exist on disk. How
can I best leverage git to merge the two files on disk while moving it
to a new location?
> On Mon, Nov 3, 2008 at 8:22 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>
>>
>> On Mon, 3 Nov 2008, Andrew Arnott wrote:
>> >
>> > I'm refactoring a library including renaming both files and
>> > directories. A few lines of each file are also changed, but they are
>> > substantially unchanged in content. I've done a git add to put all my
>> > changes into the index, but a git status shows that git only detected
>> > a few of the renames... most of them are delete-add operations. Is
>> > there anything I can do to help git recognize the rename so that
>> > history is preserved across this commit?
>>
>> How many renames do you have? Modern versions of git will do any number of
>> exact renames, but the (rather expensive) inexact rename detection has a
>> default limit of something fairly small.
>>
>> You could try adding
>>
>> [diff]
>> renamelimit=0
>>
>> to your ~/.gitconfig file. It can be quite expensive though.
>>
>> Linus
>
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jeff King @ 2008-11-04 5:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Pierre Habouzit, Sam Vilain, git, Johannes Schindelin,
Scott Chacon, Tom Preston-Werner, J.H., Christian Couder,
Kai Blin
In-Reply-To: <7v4p2ov0zt.fsf@gitster.siamese.dyndns.org>
On Mon, Nov 03, 2008 at 03:33:10PM -0800, Junio C Hamano wrote:
> By the way, didn't we add a feature to let you say "git push $there :"
> which is to do what "git push --matching $there" would do?
Oh, indeed: a83619d (add special "matching refs" refspec) from April.
So given that, I think my arguments for "--matching" are pointless.
-Peff
^ permalink raw reply
* Re: libxdiff and patience diff
From: Johannes Schindelin @ 2008-11-04 5:39 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: davidel, Git ML
In-Reply-To: <20081104004001.GB29458@artemis.corp>
Hi,
On Tue, 4 Nov 2008, Pierre Habouzit wrote:
> I've been working tonight, trying to make libxdiff support the patience
> diff algorithm, but I've totally failed, because I _thought_ I
> understood what xdl_split was doing, but it appears I don't.
I thought about it, too, at the GitTogether, although I want to finish my
jGit diff first.
The main idea I had about patience diff is that you can reuse a lot of
functions in libxdiff.
But the requirement of taking just unique lines/hashes into account, and
_after_ splitting up, _again_ determine uniqueness _just_ in the
between-hunk part made me think that it may be wiser to have a separate
function for the patience diff stuff.
Basically, you would start to have libxdiff split the lines and hash them
as normal, but then determine the unique hashes (I'd start with the
smaller text, just to have a better chance to end up with unique hashes).
Once they are determined, you can search for those exact lines (hash
first) in the post-document.
Once that is done, you'd have to find the longest common subsequence,
which you could do using the existing infrastructure, but that would
require more work (as we already know the lines are unique).
After that, you would have to recurse to the same algorithm _between_
known chunks. Eventually, that would have to resort to classical libxdiff
(if there are no, or not enough, unique lines).
Ciao,
Dscho
^ permalink raw reply
* Re: How to send patch series without storing them to disk?
From: Liu Yubao @ 2008-11-04 6:01 UTC (permalink / raw)
To: Ian Hilt; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0811032242080.1791@sys-0.hiltweb.site>
Ian Hilt wrote:
> On Mon, 3 Nov 2008, Liu Yubao wrote:
>> Hi,
>> I tried to send one patch using git-send-email, it reported "Syntax: AUTH mechanism".
>> git send-email --from <myemail> --to <my-another-email> \
>> --smtp-pass <mypass> --smtp-user <myaccount> \
>> --smtp-server <the-smtp-server> \
>> --smtp-encryption auth \
>> 0001-just-a-test.patch
>>
>> The parameters about smtp are right, I tested with msmtp. What's wrong?
>>
>> I have MIME::Base64 and Authen::SASL installed and the smtp server doesn't use
>> ssl and tls.
>
> Try removing --smtp-encryption and add --envelope-sender <youremail>.
>
I traced the related Perl modules and found Authen::SASL in Ubuntu Gutsy is buggy,
the problem is resolved after I install the module from CPAN.
>
> Ian
>
^ permalink raw reply
* Re: Intensive rename detection
From: Andrew Arnott @ 2008-11-04 6:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <216e54900811032119h4cb51327v2d85712acc444185@mail.gmail.com>
Hmmm.... actually on second run I am still getting the too many files
warning. I put the [diff] section in a ~/.gitconfig file, a
.gitconfig file in the root of my repo, and in the .git/config file,
but none of them seem to get rid of the message.
I'm running git version 1.5.5.1015.g9d258
Is that too old for this removal of a file rename limit?
On Mon, Nov 3, 2008 at 9:19 PM, Andrew Arnott <andrewarnott@gmail.com> wrote:
> Awesome. Per Linus' tip, I just noticed at the top of a long list of
> messages git said:
> warning: too many files, skipping inexact rename detection
>
> So I added the config file change, and that did the trick. Thanks, everyone!
>
> Here's a related but slightly different question: I've been stashing
> and unstashing in the midst of all these renames and refactoring, and
> now I'm left with some files listed in git status 3 times. I
> understand why this is, but I don't know the best way to proceed. Git
> is telling me:
>
> $ git status | grep MessageBase
> src/DotNetOAuth/Messages/MessageBase.cs: needs merge
> src/DotNetOAuth/OAuth/Messages/MessageBase.cs: needs merge
> src/DotNetOpenAuth/Messages/MessageBase.cs: needs merge
> # unmerged: src/DotNetOAuth/Messages/MessageBase.cs
> # unmerged: src/DotNetOAuth/OAuth/Messages/MessageBase.cs
> # unmerged: src/DotNetOpenAuth/Messages/MessageBase.cs
>
> I want to end up with MessageBase.cs in
> src/DotNetOpenAuth/OAuth/Messages/MessageBase.cs, which ironically is
> none of these three. And the couple of lines that changed in the file
> need to be merged. Only two of these listed files exist on disk. How
> can I best leverage git to merge the two files on disk while moving it
> to a new location?
>
>> On Mon, Nov 3, 2008 at 8:22 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>>
>>>
>>> On Mon, 3 Nov 2008, Andrew Arnott wrote:
>>> >
>>> > I'm refactoring a library including renaming both files and
>>> > directories. A few lines of each file are also changed, but they are
>>> > substantially unchanged in content. I've done a git add to put all my
>>> > changes into the index, but a git status shows that git only detected
>>> > a few of the renames... most of them are delete-add operations. Is
>>> > there anything I can do to help git recognize the rename so that
>>> > history is preserved across this commit?
>>>
>>> How many renames do you have? Modern versions of git will do any number of
>>> exact renames, but the (rather expensive) inexact rename detection has a
>>> default limit of something fairly small.
>>>
>>> You could try adding
>>>
>>> [diff]
>>> renamelimit=0
>>>
>>> to your ~/.gitconfig file. It can be quite expensive though.
>>>
>>> Linus
>>
>
^ 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