gmane.comp.version-control.git

Re: more merge strategies : feature request

Jeff King — 2008-12-02T03:30:14

It's not clear to me exactly what you want. Let's say I have a file 'foo' with changes from my merged branches in two different spots. For example: merge base branch A branch B 1 2 1 2 3 2 3 4 3 4 5 4 5 Did you want conflict markers in the resulting file? If so, what should the conflict markers look like, since there isn't actually a conflict? Alternatively, you could have git leave the file in an unmerged state, and then access the base, ours, and theirs version from the index (or even use git mergetool). Then you would get your desired versions into the merging tool of your choice. Of course, you could also just use a custom merge driver to accomplish the same thing: git config merge.xxdiff.driver 'xxdiff %A %O %B' echo '* merge=xxdiff' >.gitattributes git merge your-branch and of course you can specify whatever subset of files you want to actually do this for inst

Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo

Leo Razoumov — 2008-12-02T03:08:01

I am sorry, I had to be more accurate in my wording. "git fetch" with no explicit refspecs fetches everything in. It is quite cumbersome to form a refspec for git-fetch operation if you are not logged in into the "source repo" machine. git-fetch does not have a --dry-run option to help discover all the branch/tag names on the source side needed for a meaningful refspec. "git-push -v --dry-run" allows one to experiment and see what branches/tags exist at the destination and form refspecs selectively. To the best of my knowledge, git-fetch does not provide such discovery tools. --Leo--

Re: [PATCH 0/5] support reading and writing uncompressed loose object

Liu Yubao — 2008-12-02T03:11:59

Hi all, It seems my patch series are not in one mail thread, I'm very sorry for that, I replied this thread and paste my patches into Thunderbird with external editor plugin, don't know why they become separate topics. Best regards, Liu Yubao

Re: Git as a BuildRequires (packaging)

Jeff King — 2008-12-02T03:09:23

I don't think Linus, Junio, or anybody involved with git has _ever_ advocated using git source files as a library. The expected method for interfacing with git is the plumbing API, which is stable and available via the installed git programs. That being said, I think linking with libgit.a has been discussed on the list, and Lars took part in the discussion. So I think he is aware that what cgit does is not officially supported, that there is no stable library API, and that he is taking his chances. I think that is a mistake; the headers are subject to change in ways that will break calling code, and creating a -devel package creates the impression that it's OK to link against it. I don't know how one is usually expected to build cgit. But yes, you are always going to have a problem with upgrading git. I would think each cgit release would be tested based on a particular git version. And you should rely on cgit upstream to figure that out and just package (either in whole or as patches, as appropriate)

Re: two questions about the format of loose object

Liu Yubao — 2008-12-02T03:05:16

In fact the format I proposed in my patches is uncompressed loose object, not uncompressed loose object header, that's to say I proposed format 2 in my question 2, I am just curious why the loose object header is compressed in question 1. I did a test to add all files of git-1.6.1-rc1 with git-add, the time spent decreased by half. Other commands like git diff, git diff --cached, git diff HEAD~ HEAD should be faster now although the change may be not noticable for small and medium project. Thank you for dig it out for me! Best regards, Liu Yubao

Re: more merge strategies : feature request

Leo Razoumov — 2008-12-02T02:49:08

I guess that "no-overwrite" can be achieved by git merge -s ours --no-commit --Leo--

Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo

Jeff King — 2008-12-02T02:48:37

a) you are responding to a nearly month-old message. Please read the rest of the thread where we decide that it is not so insane, and that the behavior should be configurable with a default of "warn" at least for now. b) My comment was not that it is insane simply because it is different from mine. It is because it creates a dangerous situation (where dangerous implies changes might be silently lost) which requires manual intervention to fix, and which the user was given no warning whatsoever about. It is a direct response to frequent complaints on the list about users getting bit by this. (3) Use git-reset --hard, but set a config variable that says "I know what I'm doing." You don't even have to do it per-repo, you can do it per-user. (4) Push into a non-current branch and merge from the target. Er, what? git-fetch takes a refspec very similar to the ones used by git-push. The real reason that (2) is not an acceptable solution is that you can't necessaril

Re: two questions about the format of loose object

Liu Yubao — 2008-12-02T02:43:56

Yes, exceptional case, is it acceptable that core.uncompressedLooseObject is set to false by default especially for NFS file system? I mean to add a format, not to replace the current format of loose object. In my company we have a central server to host source code repository managed by git+ssh. Some collegues also work on the same machine (maybe not a good practice) and set alternates to the central repository, so there can be multiple git processes operating same git object database. In fact we have a wrapper script of git to make git fit our development process better because git's submodule support isn't good enough. One command in the wrapper script can execute many git commands in a short time. Could you review my patches sent just a moment ago? The key changes are rather small. Best regards, Liu Yubao

[PATCH] git-svn: Make branch use correct svn-remote

Deskin Miller — 2008-12-02T02:43:00

The 'branch' subcommand incorrectly had the svn-remote to use hardcoded as 'svn', the default remote name. This meant that branches derived from other svn-remotes would try to use the branch and tag configuration for the 'svn' remote, potentially copying would-be branches to the wrong place in SVN, into the branch namespace for another project. Fix this by using the remote name extracted from the svn info for the specified git ref. Add a testcase for this behaviour. Signed-off-by: Deskin Miller umich.edu> --- Applies on v1.6.1-rc1. Apologies for not catching this when first writing testcases for the branch subcommand. Deskin Miller git-svn.perl | 2 +- t/t9128-git-svn-cmd-branch.sh | 17 +++++++++++++++++ 2 files changed, 18 insertions(+), 1 deletions(-) diff --git a/git-svn.perl b/git-svn.perl index 914c707..e64e97b 100755 --- a/git-svn.perl +++ b/git-svn.perl < at >< at > -558,7 +558,7 < at >< at > sub cmd_branch { my ($src, $rev, undef, $gs) = working_head_info($head); -my $remo

Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo

Leo Razoumov — 2008-12-02T02:41:53

Junio, thanks for supporting the "third way". I am not sure whether I interpret it correctly but in the same thread several message earlier you wrote "We can ship 1.6.1 with it and then switch the default to forbid in 1.6.3, for example". With the default set to "deny" it would be useful if the git-push error message will indicate what config variable to set in order to reverse the denial. --Leo--

Re: more merge strategies : feature request

Caleb Cushing — 2008-12-02T02:38:07

conflict: when auto-merging isn't merging the way you want it too, but you still want to see the diffs and handle them by hand. no commit won't do this, it just doesn't commit. I've had 2 situations now where git's fast-forward has overwritten changes in a branch I didn't want it to, it would have been better if I could handle them by hand without having to have 1 terminal open to the diff and the other open to the editor to fix it. and yes git was right by it's perspective, but the code it created was wrong by what I wanted and needed. I'm not really sure what more of a use case is needed for this. no-overwrite: it's basically my way of saying that even though git thinks it's changes are newer and better than the ones in my branch I know they aren't. I only want the new stuff from the other branch. In the second situation mentioned above I have 2 branches that I like to merge back and forth, each needing a specific set of changes to certain files however most changes are shared. when I merge them I often

Re: [PATCH 5/6 (v2)] upload-pack: send the HEAD information

Jeff King — 2008-12-02T02:36:43

I disagree. 99% of the time we see people complain about this, it is not "I tried to announce my repo to people but it didn't have any commits" but rather "why must I hack, init remote, then push, instead of init remote, hack, push"[1]. That is, some segment of people (myself included) want to say first "I'm starting a new project, and so I'm going to create a spot for it on my server". Of course we can train ourselves to do it in the other order, but it is an unnecessary complication. -Peff [1] Actually, it is more than just arbitrary preference. It is less typing to do: ssh remote 'mkdir foo && cd foo && git init --bare' git clone remote:foo hack hack hack; commit git push than git init hack hack hack; commit ssh remote 'mkdir foo && cd foo && git init --bare' git push git remote add -m refs/heads/master origin remote:foo

Re: Hotel for sale - Dominican Republic

Real Estate S.A. — 2008-12-02T02:31:51

Dear Mr. / Mrs. HOTEL PIERO Boca Chica - Dominican Republic for sale EURO 220.000!!!!!!!! 10 double rooms 3 double rooms with kitchen Cable TV - Internet Little pool - BBQ 5 minutes walk to the beach we got also several apartments and studios close to the beach to sell Further we can offer you objects for sale or rent in Spian - Mojacer contact hotelg.piero< at >yahoo.it

Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo

Junio C Hamano — 2008-12-02T02:29:28

(3) set the config in the target repository to allow such a push regardless of the git version. Remember, I am in the third camp in this topic myself.

Git as a BuildRequires (packaging)

Josh Boyer — 2008-12-02T02:30:04

Hi All, Recently we've hit an issue where a new package being reviewed for Fedora (cgit) needs to build against the git headers. The problem is that these headers aren't typically installed with the git package itself, and we have no git-devel subpackage either. This is mostly due to the fact that from what I can tell the upstream git Makefile doesn't install the headers anywhere. There are a few options here. The first is to install the git headers and create a git-devel subpackage. That seems like overkill, given that the git headers are generically named and would have to be installed to something like /usr/include/git/. The second option is to create a patch file that includes all the needed headers and use that in the cgit package. That is sort of sub-optimal given that you'd have to keep checking (and possibly regenerating) the patch for correctness every time a new version of git comes out. The third option is to include the entire git tarball as part of the sources for the package. That is

Re: two questions about the format of loose object

Liu Yubao — 2008-12-02T02:26:42

Ok, there must be exceptional cases, for these cases you can turn off core.uncompressedLooseObject (if there will be this config). Best regards, Liu Yubao

Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo

Leo Razoumov — 2008-12-02T02:22:43

I do not think that having a work-flow different from yours deserves a "somewhat insane" label. But let us consider the consequences of banning push into a (current branch) non-bare repo. To propagate changes to such a non-bare repo there are two remaining alternatives neither of which is fully satisfactory: (1) Switch target's current branch to something else (prevent a conflict) before pushing and then restore it back after the push (2) Use git-fetch from the target. Method (1) is no better than what is available today with "git reset --hard" to sync working directory. Method (2) is even worse, because git-fetch provides no control of what branches/tags to fetch, it sucks everything in from all branches. "git-push", OTOH, can be instructed to be very selective. Here is an example of such a work-flow Foo.git -- main bare repo of the project Foo.wip -- everyday "work in progress" repo. Cloned from Foo.git. Pushes to Foo.git Foo.wip.insane -- experimental "crazy" stuff cloned from Foo.wip. Pushed to Foo

Re: [PATCH 5/6 (v2)] upload-pack: send the HEAD information

Junio C Hamano — 2008-12-02T02:20:52

This is nothing new, so there is nothing to complain about here. The ref advertisement section is not very extensible to begin with and we should consider ourselves lucky that Sergey Vlasov found the hole (cf. $gmane/10710) we are exploiting to carry "server capabilities"; I do not think we should nor can stuff any more than absolute minimum in the section. I think sending 0{40} would break older clients, but older clients cannot clone from an empty repository anyway, so that should not be so bad. I however do not think it is such a big thing to be able to clone void anyway. You just have to train yourself to announce that your repository is clonable _after_ making it actually clonable.

Re: two questions about the format of loose object

Liu Yubao — 2008-12-02T02:19:52

The server can keep an old git or set core.uncompressedLooseObject = false. Even the pack file format can be changed so that forward compatability will be broken, I think it's unavoidable. I'm not clear about the story of core.legacyHeaders, I'll dig the mail list archive. Thanks for reminding me of the dumb protocols. Best regards, Liu Yubao

[PATCH 5/5] support writing uncompressed loose object

Liu Yubao — 2008-12-02T02:03:10

Signed-off-by: Liu Yubao gmail.com> --- sha1_file.c | 16 ++++++++++++---- 1 files changed, 12 insertions(+), 4 deletions(-) diff --git a/sha1_file.c b/sha1_file.c index 05a9fa3..053b564 100644 --- a/sha1_file.c +++ b/sha1_file.c < at >< at > -2328,7 +2328,7 < at >< at > static int create_tmpfile(char *buffer, size_t bufsiz, const char *filename) } static int write_loose_object(const unsigned char *sha1, char *hdr, int hdrlen, - void *buf, unsigned long len, time_t mtime) + void *buf, unsigned long len, time_t mtime, int dont_deflate) { int fd, size, ret; unsigned char *compressed; < at >< at > -2345,6 +2345,12 < at >< at > static int write_loose_object(const unsigned char *sha1, char *hdr, int hdrlen, return error("unable to create temporary sha1 filename %s: %s\n", tmpfile, strerror(errno)); } +if (dont_deflate) { +if (write_buffer(fd, hdr, hdrlen) < 0 || write_buffer(fd, buf, len) < 0) +die("unable to write sha1 file"); +goto L_close_file; +} + /* Set it up */ memset(&stream, 0, siz

Re: [PATCH 5/6 (v2)] upload-pack: send the HEAD information

Jeff King — 2008-12-02T01:59:25

Ahhh. OK. I see, I misunderstood the protocol a bit. So let me revise my complaints. ;) (1) If there are multiple symrefs to report, we have to keep re-sending the server capabilities (I think you mentioned this in the subthread with Shawn). (2) Similar to (2) before. If we ever add a _third_ extra slot, we will be stuck sending the symref field each time we want to use that third slot (though if the client properly treats an empty slot the same as non-existent, this only wastes a single byte for the NUL). (3) If HEAD doesn't point to a valid object, we have no place to put the symref. Or is it kosher to say 0000000000000000000000000000000000000000 HEAD\0...\0refs/heads/master ? I think it would be nice eventually to be able to clone a HEAD pointing to yet-to-be-born branch. -Peff