Re: git should not use a default user.email config value
On Fri, Aug 09, 2013 at 04:06:16PM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: Yeah, there are basically three levels of ident: 1. The user told us explicitly (e.g., $EMAIL, user.email). Trust it. 2. We guessed and it looks reasonable (e.g., hostname is FQDN). Warn but use it. 3. It looks obviously bogus (e.g., we do not have a domain name). Reject it. We can move some cases from (2) down to (3), like ... Judging from Thorsten's earlier response, I am afraid no amount of autodetection would help the users of that site. If we were to do something, /etc/gitconfig as you outlined below would be the way to go, even though it makes me feel dirty. It was not clear to me whether his site has /etc/mailname. If it does not, then the new rule could be to leave /etc/mailname in group 2, and put gethostname/gethostbyname into group 3 (right now we do so only when the results from those functions are obviously not fully-qualified). But from his description, the machine may even have a split-horizon name in /etc/mailname, and we can do nothing at all about that. Even if it worked, though, I am not sure it would be worth such a rule. The /etc/mailname file is not a standard, so you would effectively be cutting off the auto-ident behavior for people on every other system. If we are going to do that, we might as well do it uniformly. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-hg: fix path when cloning with tilde expansion
On Sat, Aug 10, 2013 at 12:18 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: Hmph, do you mean the third example of this? $ python import os os.path.expanduser(~/repo) '/home/junio/repo' os.path.expanduser(~junio/repo) '/home/junio/repo' os.path.expanduser(~felipe/repo) '~felipe/repo' which will give ~felipe/repo that is _not_ an absolute repository because no such user exists on this box? It is true that in that case fix_path() will not return early and will throw a bogus path at git config, but if the ~whom does not resolve to an existing home directory of a user, I am not sure what we can do better than what Antoine's patch does. I was thinking something like this: if url.scheme != 'file' or os.path.isabs(url.path) or url.path[0] == '~': return That did cross my mind. I know ~/ and ~who/ are expanded on UNIXy systems, and I read in Python documentation that Python on Windows treats ~/ and ~who/ the same way as on UNIXy systems, so the begins with ~ test would work on both systems. But it is probably a better design to outsource that knowledge to os.path.expanduser(), with the emphasis on os. part of that function. That way, we do not even have to care about such potential platform specifics, which is a big plus. The only possible difference that approach makes is the above example of naming a non-existent ~user, but that will not work anyway, so... We would be doing better than os.path.expanduser(), because if Mercurial somehow decided to treat ~ differently, our code would still work just fine. If we do os.path.expanduser(), then we are not outsourcing anything, we are taking ownership and fixing the path by ourselves and dealing with all the consequences. If I clone ~/git, and then change my username, and move my home directory, doing a 'git fetch' in ~/git wouldn't work anymore, because we have expanded the path and fixed it to my old home, if instead we simply return without fixing, it would still work just fine. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
On Fri, Aug 09, 2013 at 04:19:28PM -0700, Jonathan Nieder wrote: Jeff King wrote: Yeah, there are basically three levels of ident: 1. The user told us explicitly (e.g., $EMAIL, user.email). Trust it. 2. We guessed and it looks reasonable (e.g., hostname is FQDN). Warn but use it. 3. It looks obviously bogus (e.g., we do not have a domain name). Reject it. We can move some cases from (2) down to (3), like when we use gethostname rather than /etc/mailname. But we risk breaking people's existing setups. I don't think we know how many people rely on the implicit hostname selection and would be affected. I don't know if there is a good way to find out short of changing it and seeing who screams. Yes. The result from a reverse DNS lookup is almost never the right mailname. Just to nitpick, the name we guess is not necessarily from DNS (and if the FQDN comes from DNS, it is not a reverse lookup, but rather following the search rules in resolv.conf, or even /etc/hosts). But I think the point is the same: we somehow arrive at the hostname through some accurate means, but that hostname does not reflect the user's actual email address. * Small installations tend to use a smarthost. * Large installations tend to use more than one machine, and only one machine's name gets the MX record. I'm not sure the second one is true. Many large installations will MX all of their workstations names to a smarthost. So mail to u...@randommachine.example.com _is_ deliverable. It has (thankfully) been a long time since I have been involved in large network IT, but that was standard practice at one time. But I think MX records and deliverability is beside the point. Even in a case where we come up with a valid, deliverable address, is that what the user wants to have in their commit history for all time? So except for cases where someone doesn't actually care about the recorded author and just has a script making commits (such users already suffer from the .(none) heuristic), I don't think this would hurt anyone. I think the other case is people who actually think the per-machine information is useful. I recall Linus arguing for this early on, but he seems to have relented. I am not sure whether anyone else in the world has that view (or ever did). There are certainly people in the I don't care, just make it work camp, judging from the repositories I sometimes see on GitHub. Whether we would be harming them (because their workflow breaks) or helping them (because they had no idea they had these crappy idents in their history and we would be letting them know) is not clear to me, though. We can put a deprecation warning in the release notes, but people tend to ignore those. Not so much a deprecation warning as an Here is one of the more noticeable changes in this release announcement. I meant a warning to give people a chance to comment before the change comes. Following this mailing list is another source for people to find out about it, but I suspect most casual users do not read the list. Perhaps it would be worth taking a straw poll over G+ or another more casual medium? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-hg: fix path when cloning with tilde expansion
Felipe Contreras felipe.contre...@gmail.com writes:
If I clone ~/git, and then change my username, and move my home
directory, doing a 'git fetch' in ~/git wouldn't work anymore, because
we have expanded the path and fixed it to my old home, if instead we
simply return without fixing, it would still work just fine.
Antoine's patch runs expanduser() only to see if the given one gets
modified to absolute path, and makes fix_path() return without
calling the extra 'git config', so it is my understanding that the
above describes exactly what the patch does. Am I reading the patch
incorrectly?
It outsources the determination of is this a special notation to
name a home directory? logic to .isabs(.expanduser()) instead of
doing a .beginswith('~') ourselves.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
Jeff King wrote: Sorry to be unclear. I meant that treating /etc/mailname and gethostname differently might be justified on Debian under the logic if you have /etc/mailname, that is a trustworthy address, and if you do not, then we cannot guess at a trustworthy address (because putting it in /etc/mailname is the accepted way to do so on Debian). But such logic would not extend to other operating systems, where /etc/mailname does not have such a status. I thought that on other operating systems people typically don't have an /etc/mailname. How does trusting the file when present hurt? I am guessing, too, about what people even put in /etc/mailname. If they relay mail from the machine to a smarthost, do they put the individual hostname into /etc/mailname? Or do they put in the domain name that represents a real deliverable address? If the former, then it is no better than gethostname anyway. Debian policy explains: If your package needs to know what hostname to use on (for example) outgoing news and mail messages which are generated locally, you should use the file /etc/mailname. It will contain the portion after the username and @ (at) sign for email addresses of users on the machine (followed by a newline). Such a package should check for the existence of this file when it is being configured. If it exists, it should be used without comment, although an MTA's configuration script may wish to prompt the user even if it finds that this file exists. If the file does not exist, the package should prompt the user for the value (preferably using debconf) and store it in /etc/mailname as well as using it in the package's configuration. The prompt should make it clear that the name will not just be used by that package. So on a properly configured Debian system, /etc/mailname contains something appropriate to put after the @ sign in an email address and the sysadmin expects it to be used for that. As far as I can tell, to the extent that other distros support /etc/mailname, it is only as a side effect of handling that Debian requirement. I don't think e.g. Fedora or Solaris systems typically will have a /etc/mailname file. I *am* a bit worried about what people might put in /etc/mailname on Debian systems when there is no appropriate host to put there (as on Thorsten's machine). Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] whatchanged: document its historical nature
Junio C Hamano wrote: Documentation/git-whatchanged.txt | 41 --- 1 file changed, 8 insertions(+), 33 deletions(-) Looks good. Thanks for doing this. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-hg: fix path when cloning with tilde expansion
On Sat, Aug 10, 2013 at 1:50 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: If I clone ~/git, and then change my username, and move my home directory, doing a 'git fetch' in ~/git wouldn't work anymore, because we have expanded the path and fixed it to my old home, if instead we simply return without fixing, it would still work just fine. Antoine's patch runs expanduser() only to see if the given one gets modified to absolute path, and makes fix_path() return without calling the extra 'git config', so it is my understanding that the above describes exactly what the patch does. Am I reading the patch incorrectly? Antoine's *second* patch, which I missed, does that, yeah. That should work fine. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] gc: reject if another gc is running, unless --force is given
Duy Nguyen pclo...@gmail.com writes: On Fri, Aug 9, 2013 at 11:29 PM, Andres Perera andre...@zoho.com wrote: On Thu, Aug 8, 2013 at 6:35 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: + uintmax_t pid; pid_t is always an signed type, therefore unintmax_t does not make sense as a catch all value I only catch real process id. In practice we don't have processes with negative pid_t, do we? I can't find any document about this, but at least waitpid seems to treat negative pid (except -1) just as an indicator while the true pid is the positive counterpart. Negative pids are used for denoting process groups in various interfaces. No process can have a negative pid. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
On Sat, Aug 10, 2013 at 12:03:00AM -0700, Jonathan Nieder wrote: Jeff King wrote: Sorry to be unclear. I meant that treating /etc/mailname and gethostname differently might be justified on Debian under the logic if you have /etc/mailname, that is a trustworthy address, and if you do not, then we cannot guess at a trustworthy address (because putting it in /etc/mailname is the accepted way to do so on Debian). But such logic would not extend to other operating systems, where /etc/mailname does not have such a status. I thought that on other operating systems people typically don't have an /etc/mailname. How does trusting the file when present hurt? I guess I am not explaining myself well. Trusting the file when present does not hurt at all. But the logic above is making assumptions about the state when the file is _not_ present (i.e., the if you do not... clause above). On Debian, we might assume that if /etc/mailname is not present that this is a clue that the machine cannot produce a useful address. But on other operating systems, that is not a useful clue (it is simply that /etc/mailname is not used on that system). Dying on such a system when /etc/mailname is not present would be a regression. Does that make more sense? I *am* a bit worried about what people might put in /etc/mailname on Debian systems when there is no appropriate host to put there (as on Thorsten's machine). Yeah. Or even in a split-horizon setup where the mail is deliverable but does not reflect the public identity of the user. I think we are getting down to the question I mentioned elsewhere: it is not about whether we have a deliverable address or not, but what users want to cement in history for all time as their identity. So thinking too much about /etc/mailname versus gethostname is probably not useful. Either it is worth breaking the few (if any) users who depend on the auto ident in favor of fewer accidental implicit idents making their way into the wild, or it is not. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff: remove ternary operator evaluating always to true
On Thu, Aug 08, 2013 at 08:31:44PM +0200, Stefan Beller wrote:
The next occurrences are at:
/* Never use a non-valid filename anywhere if at all possible */
name_a = DIFF_FILE_VALID(one) ? name_a : name_b;
name_b = DIFF_FILE_VALID(two) ? name_b : name_a;
a_one = quote_two(a_prefix, name_a + (*name_a == '/'));
b_two = quote_two(b_prefix, name_b + (*name_b == '/'));
In the last line of this block 'name_b' is dereferenced and compared
to '/'. This would crash if name_b was NULL. Hence in the following code
we can assume name_b being non-null.
I think your change is correct, but I find the reasoning above a little
suspect. It assumes that the second chunk of code (accessing name_a and
name_b) is correct, and pins the correctness of the code you are
changing to it. If the second chunk is buggy, then you are actually
making the code worse.
The interesting part is the top chunk, which aliases the names if one of
them is NULL. And there is an implicit assumption there that we will
never get _two_ NULL names in this function. And that is why the second
chunk does not ever crash (and why your change is the right thing to
do).
Sorry if this seems nit-picky. It is just that seemingly trivial
cleanups can sometimes end up revealing larger bugs, and I think it is
worth making sure we understand the root cause to be sure that our
cleanup really is trivial.
I wonder if the implicit expectation of the function to take at least
one non-NULL name would be more obvious if the first few lines were
written as:
if (DIFF_FILE_VALID(one)) {
if (!DIFF_FILE_VALID(two))
name_b = name_a;
} else if (DIFF_FILE_VALID(two))
name_a = name_b;
else
die(BUG: two invalid files to diff);
That covers all of the cases explicitly, though it is IMHO uglier to
read (and there is still an implicit assumption that the name is
non-NULL if DIFF_FILE_VALID() is true).
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug: Pulling remotes into an empty repo deletes the index
On Sat, Aug 03, 2013 at 09:57:28AM -0700, Jonathan Nieder wrote:
All is not lost. Your local files should be stored in the repository's
reflog. Examine the output of git reflog. You can then reset your
working directory to obtain those files by doing something _like_
git reset --hard HEAD@{1}.
Adam hadn't made a commit, so that wouldn't work in this case.
git fsck --lost-found should be helpful, but yeah, this is a bug.
See for example [1] for the start of a patch to play with (needs
tests).
If I understand the situation correctly, this is actually already fixed
in v1.8.3.3 and higher by b4dc085 (pull: merge into unborn by
fast-forwarding from empty tree, 2013-06-20).
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git exproll: steps to tackle gc aggression
Jeff King wrote: [...] First off, thanks for the fabulous writeup. I hope more contributors read this, and get interested in tackling the problems. You are missing a step in the preparation of the delta list. If we already have a delta on-disk, we will check whether it is usable and keep a note in the list (see check_object). Then when we prepare the list of objects to delta, it is omitted from the list (see prepare_pack). Ah, prepare_pack() calls get_object_details(), which then calls check_object(): reuse_delta is what I was looking for. That is why you may see a much smaller number objects in the progress eye candy for Compressing objects... than we are actually sending. I see. As Junio mentioned, that is what --thin is about; the sender omits the base and the receiver adds it back in (index-pack --fix-thin). Yeah, I read about the --thin option. However, it's only for network-packs (i.e --stdout; why?). Also, is it turned on by default? The documentation says so, but I ran it and found that the value of thin is 0 in builtin/push.c:316. What is going on? And if you think about it, that is likely where most of Martin's 317 packs turned into 8MB space savings are coming from. Thin packs have nothing to do with git-exproll per-se, but I think I understand why pack generations work. The reason we do not store thin-packs on disk is that you run into problems with cycles in the delta graph (e.g., A deltas against B, which deltas against C, which deltas against A; at one point you had a full copy of one object which let you create the cycle, but you later deleted it as redundant with the delta, and now you cannot reconstruct any of the objects). Ah, that's why. Somebody pushes X, which deltas against Y. They send only the delta for X-Y, but the receiver stores that delta plus a full copy of Y, even though we already have Y in another pack. Repacking throws away the extra copy of Y. Right, I got that. And that is why something like Junio's suggestion of do not traverse history; just concatenate the packs and throw away duplicate objects might be helpful. You would not find new deltas, but you would get rid of these duplicate objects, and doing so would be relatively cheap. ... but we've already determined that git pack-objects does a good job of reusing deltas, so I'm not sure what we can do over and above this. If I understand correctly, the proposal is to use existing (but sub-optimal) deltas more aggressively when repacking? Another solution could involve not writing the duplicate of Y in the first place. [...] You could possibly solve this with cycle detection, though it would be complicated (you need to do it not just when getting rid of objects, but when sending a pack, to make sure you don't send a cycle of deltas that the other end cannot use). You _might_ be able to get by with a kind of two-level hack: consider your main pack as group A and newly pushed packs as group B. Allow storing thin deltas on disk from group B against group A, but never the reverse (nor within group B). That makes sure you don't have cycles, and it eliminates even more I/O than any repacking solution (because you never write the extra copy of Y to disk in the first place). But I can think of two problems: Hm, having two kinds of packs: full packs and thin packs, and different codepaths to handle them. 1. You still want to repack more often than every 300 packs, because having many packs cost both in space, but also in object lookup time (we can do a log(N) search through each pack index, but have to search linearly through the set of indices). Once you narrow it down to a pack-index, you can bisect it since the table is sorted. How do you find the right pack-index though? Do I have to do the bisection-search on each one to see if the object exists? Can this be improved by generating a global index for all packs that contains packfile-name in addition to offset for each object? 2. As you accumulate group B packs with new objects, the deltas that people send will tend to be against objects in group B. They are closer to the tip of history, and therefore make better deltas for history built on top. Actually, I'm not sure it's worth the additional complexity at all. Keeping packs self-contained means that simpler code and easier isolation in the face of corruption: the space isn't a big trade-off, unless there are lots of really tiny packs (in which case we consolidate them into larger packs). The way I see it, we'll be saving on some IO by creating thin packs. But the trade-off seems to be quite heavy: self-contained packs means that I can just mmap() that pack-index, look for objects and apply deltas without bothering about any other packs. Thin packs means that I'll have to mmap() a lot more than one pack-index, and spend a lot more time searching for the base object to apply the delta to, right? That's all just off the
Re: [PATCH] git exproll: steps to tackle gc aggression
On Sat, Aug 10, 2013 at 3:42 PM, Ramkumar Ramachandra artag...@gmail.com wrote: As Junio mentioned, that is what --thin is about; the sender omits the base and the receiver adds it back in (index-pack --fix-thin). Yeah, I read about the --thin option. However, it's only for network-packs (i.e --stdout; why?). Also, is it turned on by default? The documentation says so, but I ran it and found that the value of thin is 0 in builtin/push.c:316. What is going on? --thin is enabled by default for fetch (see transport.c:transport_get()) but it's only effective when the server advertises thin-pack capability (see protocol-capabilities.txt). push has --thin turned off by default favoring server resources over network traffic, see a4503a1 (Make --no-thin the default in git-push to save server resources - 2007-09-09) -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git exproll: steps to tackle gc aggression
On Sat, Aug 10, 2013 at 4:24 PM, Duy Nguyen pclo...@gmail.com wrote: push has --thin turned off by default favoring server resources over network traffic, see a4503a1 (Make --no-thin the default in git-push to save server resources - 2007-09-09) Side note, I think the server should be able to control the default behavior. Maybe if the server advertises thin-pack capability and the user does not explicitly specify --no-thin, then --thin is automatically turned on at the client. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git exproll: steps to tackle gc aggression
On Sat, Aug 10, 2013 at 02:12:46PM +0530, Ramkumar Ramachandra wrote: First off, thanks for the fabulous writeup. I hope more contributors read this, and get interested in tackling the problems. You're welcome. I'll just respond to a few questions/points you raised in your response: Yeah, I read about the --thin option. However, it's only for network-packs (i.e --stdout; why?). Also, is it turned on by default? The documentation says so, but I ran it and found that the value of thin is 0 in builtin/push.c:316. What is going on? I'm not sure whether push --thin actually does anything anymore. It looks like we always turn on thin-packs for the git transport in transport_get, and have ever since 9b28851 (Push code for transport library, 2007-09-10). And you cannot turn off thin-packing with --no-thin. So I suspect it is historical cruft at this point. And if you think about it, that is likely where most of Martin's 317 packs turned into 8MB space savings are coming from. Thin packs have nothing to do with git-exproll per-se, but I think I understand why pack generations work. I think it matters in terms of understanding the workload, and why the repo benefits from repacking. In a normal git repo that accumulates packs via incremental git repack (e.g., by running gc --auto until we hit the pack limit), you will not have duplicate objects (only objects which could be delta'd across the pack boundary but are not). But if you accumulate packs by repeated thin-pack pushing, you will have good deltas, but extra copies of base objects. And that is why something like Junio's suggestion of do not traverse history; just concatenate the packs and throw away duplicate objects might be helpful. You would not find new deltas, but you would get rid of these duplicate objects, and doing so would be relatively cheap. ... but we've already determined that git pack-objects does a good job of reusing deltas, so I'm not sure what we can do over and above this. If I understand the proposal correctly, the problem space is something like: A fully packed repository is the best way to store objects, both in terms of space efficiency and for delta reuse when clients fetch from us. But it is too expensive to do a full repack after each push. What makes it expensive, and how can we get around that? I think the answer to why is it expensive is two-fold: 1. We spend a lot of CPU on history traversal. Even if we have only 10 new commits to pack, we have to traverse the _whole_ history to generate the pack. 2. We spend some CPU on delta compression. This scales nicely (10 commits means we only do deltas for those 10 commits). 3. We do a lot of I/O, as we rewrite the whole of the old pack content into the new pack, along with the extra objects (so again, we might rewrite millions of objects just to add 10 more to the pack). I do not think (2) is that big a deal. It scales nicely already, and the deltas you get are worth it (and you would have to compute them on the fly for the next clone anyway). But (1) and (3) are bad, because they are based on the size of the repository, not the size of the new content. If we were to simply append the objects from the new packs onto the big, old pack, dropping any duplicates but retaining the deltas we have, we would make (1) and (3) go away. Our pack probably wouldn't be as good as a real repack, as it would potentially contain unreachable objects, and we might miss some delta opportunities. But we could cheaply run the concatenate repack after each push, and then do a real repack less frequently. I am not sure if that is exactly what Junio is proposing. There are some logistical complications (fixing up the pack header and footer, along with the filename, and updating the pack index). 1. You still want to repack more often than every 300 packs, because having many packs cost both in space, but also in object lookup time (we can do a log(N) search through each pack index, but have to search linearly through the set of indices). Once you narrow it down to a pack-index, you can bisect it since the table is sorted. How do you find the right pack-index though? Do I have to do the bisection-search on each one to see if the object exists? Can this be improved by generating a global index for all packs that contains packfile-name in addition to offset for each object? Right. The bisection-search is the log(N) I mention above; you can do that on each pack index. But you have to search the packs linearly, since there is no indication of which pack the object might be found in. A global index would solve that. Right now, the way to create such an index is git repack -ad. :) But there is nothing to say that we could not have a meta-index on top of the existing pack indices (however it does introduce complications with lifetimes, as right now we can delete redundant packs and their indices).
Re: [PATCH] git exproll: steps to tackle gc aggression
On Sat, Aug 10, 2013 at 08:24:39AM +0700, Nguyen Thai Ngoc Duy wrote: the other end cannot use). You _might_ be able to get by with a kind of two-level hack: consider your main pack as group A and newly pushed packs as group B. Allow storing thin deltas on disk from group B against group A, but never the reverse (nor within group B). That makes sure you don't have cycles, and it eliminates even more I/O than any repacking solution (because you never write the extra copy of Y to disk in the first place). But I can think of two problems: [...] Some refinements on this idea - We could keep packs in group B ordered as the packs come in. The new pack can depend on the previous ones. I think you could dispense with the two-level altogether and simply give a definite ordering to packs, whereby newer packs can only depend on older packs. Enforcing that with filesystem mtime feels a bit error-prone; I think you'd want to explicitly store a counter somewhere. - A group index in addition to separate index for each pack would solve linear search object lookup problem. Yeah. I do not even think it would be that much work. It is a pure optimization, so you can ignore issues like what happens if I search for an object, but the pack it is supposed to be in went away?. The answer is you fall back to a linear search through the packs, and assume it happens infrequently enough not to care. I'd wait to see how other proposed optimizations work out before doing a global index, though. The current wisdom is don't have a ton of packs, for both the index issue and other reasons, like wasting space and on-the-fly deltas for fetches. If the other reasons go away, then a global index would make sense to solve the remaining issue. But if the solution for the other issues is to make it cheaper to repack so you can do it more often, then the index issue just goes away. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git exproll: steps to tackle gc aggression
On Sat, Aug 10, 2013 at 4:43 PM, Jeff King p...@peff.net wrote: push has --thin turned off by default favoring server resources over network traffic, see a4503a1 (Make --no-thin the default in git-push to save server resources - 2007-09-09) Hmm. I don't think that is the case anymore. If I do: git init parent (cd parent seq 1 1 file git add file git commit -m base ) git clone parent child cd child seq 1 10001 file git commit -a -m more GIT_TRACE=1 git push origin HEAD:foo I see: trace: run_command: 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress' Right. transport_get() is also run for push and it sets smart_options-thin = 1 unconditionally. Thanks for correcting. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
On 08/10/2013 08:47 AM, Jeff King wrote: But I think MX records and deliverability is beside the point. Even in a case where we come up with a valid, deliverable address, is that what the user wants to have in their commit history for all time? I intentionally don't set user.email in my ~/.gitconfig because I use different identities (on the same machine) depending on what project I am committing to (open-source vs. work). After I clone a repo, I *rely* on Git reminding me to set user.email on my first commit, because I invariably forget to set it myself. And for me, *any* universal, heuristically-determined email address would be wrong for me for at least some repos. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git exproll: steps to tackle gc aggression
Duy Nguyen wrote: Right. transport_get() is also run for push and it sets smart_options-thin = 1 unconditionally. So, it looks like smart http implies the thin capability. I think sop's patch (6 years ago) was about turning off thin on dumb http: can we check that before deciding that push --[no-]thin is historical cruft? Also, a documentation update is required. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] push: respect --no-thin
Over the time the default value for --thin has been switched between
on and off. As of now it's always on, even if --no-thin is given.
Correct the code to respect --no-thin.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/push.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/builtin/push.c b/builtin/push.c
index 04f0eaf..333a1fb 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -15,7 +15,7 @@ static const char * const push_usage[] = {
NULL,
};
-static int thin;
+static int thin = 1;
static int deleterefs;
static const char *receivepack;
static int verbosity;
@@ -313,8 +313,7 @@ static int push_with_options(struct transport *transport,
int flags)
if (receivepack)
transport_set_option(transport,
TRANS_OPT_RECEIVEPACK, receivepack);
- if (thin)
- transport_set_option(transport, TRANS_OPT_THIN, yes);
+ transport_set_option(transport, TRANS_OPT_THIN, thin ? yes : NULL);
if (verbosity 0)
fprintf(stderr, _(Pushing to %s\n), transport-url);
--
1.8.2.83.gc99314b
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git exproll: steps to tackle gc aggression
On Sat, Aug 10, 2013 at 5:05 PM, Ramkumar Ramachandra artag...@gmail.com wrote: Duy Nguyen wrote: Right. transport_get() is also run for push and it sets smart_options-thin = 1 unconditionally. So, it looks like smart http implies the thin capability. smart_options is a bit misleading. This applies to both smart http://, git:// and ssh:// I think sop's patch (6 years ago) was about turning off thin on dumb http No, dumb http walks through the remote repository object database, there's no temporary pack created for transferring data. Dumb http has nothing to do with this flag. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
On Sat, Aug 10, 2013 at 11:59:21AM +0200, Michael Haggerty wrote: On 08/10/2013 08:47 AM, Jeff King wrote: But I think MX records and deliverability is beside the point. Even in a case where we come up with a valid, deliverable address, is that what the user wants to have in their commit history for all time? I intentionally don't set user.email in my ~/.gitconfig because I use different identities (on the same machine) depending on what project I am committing to (open-source vs. work). After I clone a repo, I *rely* on Git reminding me to set user.email on my first commit, because I invariably forget to set it myself. And for me, *any* universal, heuristically-determined email address would be wrong for me for at least some repos. So if I understand your use case, then you would be even happier if rather than giving a warning, git simply barfed and said please set your identity before committing? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] push: respect --no-thin
On Sat, Aug 10, 2013 at 05:10:07PM +0700, Nguyen Thai Ngoc Duy wrote: Over the time the default value for --thin has been switched between on and off. As of now it's always on, even if --no-thin is given. Correct the code to respect --no-thin. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com This makes sense, and I confirmed with the script I posted earlier that it does work (and didn't before). Thanks. It might be nice to have a test, but I am not sure of a good way to check whether a push was thin. I guess we can grep the output of GIT_TRACE, though it feels a bit hacky. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
On 08/10/2013 12:28 PM, Jeff King wrote: On Sat, Aug 10, 2013 at 11:59:21AM +0200, Michael Haggerty wrote: On 08/10/2013 08:47 AM, Jeff King wrote: But I think MX records and deliverability is beside the point. Even in a case where we come up with a valid, deliverable address, is that what the user wants to have in their commit history for all time? I intentionally don't set user.email in my ~/.gitconfig because I use different identities (on the same machine) depending on what project I am committing to (open-source vs. work). After I clone a repo, I *rely* on Git reminding me to set user.email on my first commit, because I invariably forget to set it myself. And for me, *any* universal, heuristically-determined email address would be wrong for me for at least some repos. So if I understand your use case, then you would be even happier if rather than giving a warning, git simply barfed and said please set your identity before committing? Yes, definitely. For the particular use case that I described, I wouldn't mind setting a global setting barfOnMissingEmail = true because I always use the same Linux account. But for other uses cases that arise at my company, people have to jump around from one computer to another, and it would be more convenient if the barfing behavior was the default without the need for a setting. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] push: respect --no-thin
On Sat, Aug 10, 2013 at 06:31:23AM -0400, Jeff King wrote:
It might be nice to have a test, but I am not sure of a good way to
check whether a push was thin. I guess we can grep the output of
GIT_TRACE, though it feels a bit hacky.
In theory, if we have a way to tell receive-pack not to pass
--fix-thin to index-pack, then it should barf on the thin pack
received from push/send-pack. But it does not work this way, or at
least I set up the test the wrong way, or pack-objects decides not to
create deltas.. anybody sees what's wrong in this test?
-- 8 --
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index e3eb5fc..da60817 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -38,6 +38,7 @@ static int quiet;
static int prefer_ofs_delta = 1;
static int auto_update_server_info;
static int auto_gc = 1;
+static int fix_thin = 1;
static const char *head_name;
static void *head_name_to_free;
static int sent_capabilities;
@@ -869,7 +870,8 @@ static const char *unpack(int err_fd)
keeper[i++] = --stdin;
if (fsck_objects)
keeper[i++] = --strict;
- keeper[i++] = --fix-thin;
+ if (fix_thin)
+ keeper[i++] = --fix-thin;
keeper[i++] = hdr_arg;
keeper[i++] = keep_arg;
keeper[i++] = NULL;
@@ -975,6 +977,10 @@ int cmd_receive_pack(int argc, const char **argv, const
char *prefix)
stateless_rpc = 1;
continue;
}
+ if (!strcmp(arg, --no-thin)) {
+ fix_thin = 0;
+ continue;
+ }
usage(receive_pack_usage);
}
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 4691d51..9c9d43c 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -126,6 +126,16 @@ test_expect_success setup '
'
+test_expect_success 'push --no-thin' '
+ git init no-thin
+ git --git-dir=no-thin/.git config receive.unpacklimit 0
+ git push no-thin/.git refs/heads/master:refs/heads/foo
+ echo modified path1
+ git commit -am modified
+ git push --no-thin --receive-pack=git receive-pack --no-thin
no-thin/.git refs/heads/master:refs/heads/foo
+ false
+'
+
test_expect_success 'fetch without wildcard' '
mk_empty testrepo
(
-- 8 --
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git clone doesn't work in symlink dir roots on Windows
Hi, I verified this behavior on Git 1.7.8 and 1.8.3. My D:\src folder is a symlink to another folder in my Google Drive, created by Windows command mklink /d d:\src d:\Google Drive\src D:\srcgit clone https://github.com/jlewallen/jenkins-hipchat-plugin.git Cloning into 'jenkins-hipchat-plugin'... fatal: Invalid symlink 'D:/src': Function not implemented The same error is shown with the bash prompt too: $ git clone https://github.com/jlewallen/jenkins-hipchat-plugin.git Cloning into 'jenkins-hipchat-plugin'... fatal: Invalid symlink 'd:/src': Function not implemented If I go one directory below (D:\src\somethingelse) the command works fine but not at the root of the symlink directory. Thanks, Sedat -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
Jeff King p...@peff.net writes: So if I understand your use case, then you would be even happier if rather than giving a warning, git simply barfed and said please set your identity before committing? FWIW, this is what both hg and bzr do. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git clone doesn't work in symlink dir roots on Windows
On Sat, Aug 10, 2013 at 03:10:49PM +0300, Sedat Kapanoglu wrote: My D:\src folder is a symlink to another folder in my Google Drive, created by Windows command mklink /d d:\src d:\Google Drive\src D:\srcgit clone https://github.com/jlewallen/jenkins-hipchat-plugin.git Cloning into 'jenkins-hipchat-plugin'... fatal: Invalid symlink 'D:/src': Function not implemented git is a disk intense program, so this setup is not sane at all. With that said I know that git on windows historically had problems with working on smb-mounted shares (sometimes you're forced to have stupid setups). I doubt that git really is the right tool for your work, since you're using a decentralized tool in a centralized work flow. Maybe something like subversion would suite you better. (or just simple use a hosting service such as github/bitbucket/your own server). However I can't find that error message in the git source code which make me wonder if this actually is a git problem. Could you investigate more on where that error message comes from? Using dropbox git users have experienced corrupt repositories due to the dropbox sync algoritm isn't suited for the git file access patterns, I would imagine that you could have the same problems using google drive. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
Jeff King dixit:
It was not clear to me whether his site has /etc/mailname. If it does
Some may, some may not but…
But from his description, the machine may even have a split-horizon name
in /etc/mailname, and we can do nothing at all about that.
… that won’t happen. The problem is that they may have
the correct domain there but the localpart will still
be wrong because Kolab localparts are not Unix usernames.
Jonathan Nieder dixit:
I thought that on other operating systems people typically don't have
an /etc/mailname. How does trusting the file when present hurt?
Right, MirBSD doesn’t have it, and I don’t think OpenBSD
added it since we forked.
Jeff King dixit:
On Sat, Aug 10, 2013 at 11:59:21AM +0200, Michael Haggerty wrote:
I intentionally don't set user.email in my ~/.gitconfig because I use
different identities (on the same machine) depending on what project I
For me that’s also true, but I set a default one at the moment
which is still better than having an unroutable one (on my private
laptop, ${unix_username}@${fqdn} does work, but only as long as my
laptop is powered on, has got IPv6 Internet, and the sending MTA
has IPv6 Internet, so… it’s mostly unroutable).
While I used a fallback for this scenario (me, privately), I’d
also benefit from git refusing to accept commits by default.
So if I understand your use case, then you would be even happier if
rather than giving a warning, git simply barfed and said please set
your identity before committing?
Exactly. That’s what I think he said, and what I asked for too.
Thanks,
//mirabilos (working with many OSS projects)
--
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence. -- Coywolf Qi Hunt
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase --interactive using short SHA-1's internally
Ooops, that's exactly it =) On Sat, Aug 10, 2013 at 2:28 AM, Junio C Hamano gits...@pobox.com wrote: David bouncingc...@gmail.com writes: On 10 August 2013 05:22, Diogo de Campos cam...@esss.com.br wrote: Had some problems rebasing a large repository, fatal error because a short SHA-1 ref was ambiguous. This recent disussion might also interest you: http://thread.gmane.org/gmane.comp.version-control.git/229091 I was wondering why the topic looked familiar ;-) -- Diogo Campos Engineering Simulation and Scientific Software BOS - Business Operation Support Software Engineer -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] status: always show tracking branch even no change
2013/8/10 Junio C Hamano gits...@pobox.com:
Jiang Xin worldhello@gmail.com writes:
So always show the remote tracking branch in the output of git status
and other commands will help users to see where the current branch
will push to and pull from. E.g.
...
Hmmph.
I do not know if this will help any case you described above, even
though this might help some other cases. The added output is to
always show the current branch and its upstream, but the thing is,
the original issue in $gmane/198703 was *not* that the current
branch was pushed and up to date. It was that there was no current
branch to be pushed. The same thing would happen if you are on a
local branch that is not set to be pushed to the other side
(e.g. the configuration is set to matching and there is no such
branch on the other end).
How about write the commit log like this:
-- 8 --
From: Jiang Xin worldhello@gmail.com
Date: Wed, 7 Aug 2013 21:45:01 +0800
Subject: [PATCH v4] status: always show tracking branch even no change
If the current branch has an upstream branch, and there are changes
between the current branch and its upstream, some commands (such as
git status, git status -bs, and git checkout) will report their
relationship. E.g.
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
...
$ git status -bs
## master...origin/master [ahead 1]
...
$ git checkout master
Already on 'master'
Your branch is ahead of 'origin/master' by 1 commit.
...
With this patch, the relationship between the current branch its
upstream will be reported always even if there is no difference
between them. E.g.
$ git status
# On branch master
# Your branch is identical to 'origin/master'.
...
$ git status -bs
## master...origin/master
...
$ git checkout master
Already on 'master'
Your branch is identical to 'origin/master'.
...
Then if there is no tracking info reported, the user may need to do
something. Maybe the current branch is a new branch that needs to be
pushed out, or maybe it's a branch which should add remote tracking
settings.
This patch changes the return value of function stat_tracking_info()
from 0 (not report) to 1 (report), when the current branch and its
remote tracking branch point to the same commit. Also add some test
cases in t6040.
Signed-off-by: Jiang Xin worldhello@gmail.com
---
builtin/branch.c | 18 +---
remote.c | 18 +++-
t/t6040-tracking-info.sh | 54
wt-status.c | 5 +
4 files changed, 73 insertions(+), 22 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 0836890..359e75d 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -424,19 +424,8 @@ static void fill_tracking_info(struct strbuf *stat, const
char *branch_name,
struct branch *branch = branch_get(branch_name);
struct strbuf fancy = STRBUF_INIT;
- if (!stat_tracking_info(branch, ours, theirs)) {
- if (branch branch-merge branch-merge[0]-dst
- show_upstream_ref) {
- ref = shorten_unambiguous_ref(branch-merge[0]-dst, 0);
- if (want_color(branch_use_color))
- strbuf_addf(stat, [%s%s%s] ,
-
branch_get_color(BRANCH_COLOR_UPSTREAM),
- ref,
branch_get_color(BRANCH_COLOR_RESET));
- else
- strbuf_addf(stat, [%s] , ref);
- }
+ if (!stat_tracking_info(branch, ours, theirs))
return;
- }
if (show_upstream_ref) {
ref = shorten_unambiguous_ref(branch-merge[0]-dst, 0);
@@ -448,7 +437,10 @@ static void fill_tracking_info(struct strbuf *stat, const
char *branch_name,
strbuf_addstr(fancy, ref);
}
- if (!ours) {
+ if (!ours !theirs) {
+ if (ref)
+ strbuf_addf(stat, _([%s]), fancy.buf);
+ } else if (!ours) {
if (ref)
strbuf_addf(stat, _([%s: behind %d]), fancy.buf,
theirs);
else
diff --git a/remote.c b/remote.c
index 2433467..79766df 100644
--- a/remote.c
+++ b/remote.c
@@ -1740,6 +1740,10 @@ int stat_tracking_info(struct branch *branch, int
*num_ours, int *num_theirs)
const char *rev_argv[10], *base;
int rev_argc;
+ /* Set both num_theirs and num_ours as undetermined. */
+ *num_theirs = -1;
+ *num_ours = -1;
+
/*
* Nothing to report unless we are marked to build on top of
* somebody else.
@@ -1758,16 +1762,18 @@ int stat_tracking_info(struct branch *branch, int
*num_ours, int *num_theirs)
theirs = lookup_commit_reference(sha1);
if
Re: [PATCH] remote-hg: fix path when cloning with tilde expansion
On Sat, Aug 10, 2013 at 9:07 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sat, Aug 10, 2013 at 1:50 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: If I clone ~/git, and then change my username, and move my home directory, doing a 'git fetch' in ~/git wouldn't work anymore, because we have expanded the path and fixed it to my old home, if instead we simply return without fixing, it would still work just fine. Antoine's patch runs expanduser() only to see if the given one gets modified to absolute path, and makes fix_path() return without calling the extra 'git config', so it is my understanding that the above describes exactly what the patch does. Am I reading the patch incorrectly? Antoine's *second* patch, which I missed, does that, yeah. That should work fine. OK Cool, Thank you both, -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] remote-hg: shared repo upgrade fix
On Sat, Aug 10, 2013 at 12:38 AM, Felipe Contreras felipe.contre...@gmail.com wrote: Hi, Same as before, except with commit messages updated, and improved the second patch: --- a/contrib/remote-helpers/git-remote-hg +++ b/contrib/remote-helpers/git-remote-hg @@ -400,8 +400,9 @@ def get_repo(url, alias): local_hg = os.path.join(shared_path, x, 'clone', '.hg') if not os.path.exists(local_hg): continue -shutil.copytree(local_hg, hg_path) -break +if not os.path.exists(hg_path): +shutil.move(local_hg, hg_path) +shutil.rmtree(os.path.join(shared_path, x, 'clone')) # setup shared repo (if not there) try: FWIW, Reviewed-by: Antoine Pelisse apeli...@gmail.com Cheers, -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: fix indentation in git-svn.txt
The indentation should be tab not spaces. Signed-off-by: sgm sim0...@gmail.com --- Documentation/git-svn.txt | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 4dd3bcb..c13d0ed 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -159,11 +159,11 @@ Skip branches and tags of first level directories;; precedence over '--include-paths'. --log-window-size=n;; -Fetch n log entries per request when scanning Subversion history. -The default is 100. For very large Subversion repositories, larger -values may be needed for 'clone'/'fetch' to complete in reasonable -time. But overly large values may lead to higher memory usage and -request timeouts. + Fetch n log entries per request when scanning Subversion history. + The default is 100. For very large Subversion repositories, larger + values may be needed for 'clone'/'fetch' to complete in reasonable + time. But overly large values may lead to higher memory usage and + request timeouts. 'clone':: Runs 'init' and 'fetch'. It will automatically create a @@ -256,7 +256,7 @@ first have already been pushed into SVN. For each patch, one may answer yes (accept this patch), no (discard this patch), all (accept all patches), or quit. + - 'git svn dcommit' returns immediately if answer is no or quit, without + 'git svn dcommit' returns immediately if answer is no or quit, without committing anything to SVN. 'branch':: @@ -347,12 +347,12 @@ environment). This command has the same behaviour. Any other arguments are passed directly to 'git log' 'blame':: - Show what revision and author last modified each line of a file. The - output of this mode is format-compatible with the output of - `svn blame' by default. Like the SVN blame command, - local uncommitted changes in the working tree are ignored; - the version of the file in the HEAD revision is annotated. Unknown - arguments are passed directly to 'git blame'. + Show what revision and author last modified each line of a file. The + output of this mode is format-compatible with the output of + `svn blame' by default. Like the SVN blame command, + local uncommitted changes in the working tree are ignored; + the version of the file in the HEAD revision is annotated. Unknown + arguments are passed directly to 'git blame'. + --git-format;; Produce output in the same format as 'git blame', but with @@ -506,7 +506,7 @@ OPTIONS -r arg:: --revision arg:: - Used with the 'fetch' command. + Used with the 'fetch' command. + This allows revision ranges for partial/cauterized history to be supported. $NUMBER, $NUMBER1:$NUMBER2 (numeric ranges), @@ -810,7 +810,7 @@ Tracking and contributing to an entire Subversion-managed project # View all branches and tags you have cloned: git branch -r # Create a new branch in SVN -git svn branch waldo + git svn branch waldo # Reset your master to trunk (or any other branch, replacing 'trunk' # with the appropriate name): git reset --hard remotes/trunk -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] tig-1.2
Hello, It's been almost a year since the last release of tig, so here is a much needed update. It brings a lot of cool new features, such as the ability to jump directly from diff to the corresponding line in the changed file, a stash view, improvements to the log view, plus a bunch of bug fixes. On behalf of everyone who contributed to this release, please enjoy. What is tig? Tig is an ncurses-based text-mode interface for git. It functions mainly as a git repository browser, but can also assist in staging changes for commit at chunk level and act as a pager for output from various git commands. - Homepage:http://jonas.nitro.dk/tig/ - Manual: http://jonas.nitro.dk/tig/manual.html - Tarballs:http://jonas.nitro.dk/tig/releases/ - Git URL: git://github.com/jonas/tig.git - Gitweb: http://repo.or.cz/w/tig.git - QA: http://stackoverflow.com/questions/tagged/tig Release notes - - Tig now has its own tag on Stack Overflow, where users are invited to ask questions: http://stackoverflow.com/questions/tagged/tig Improvements: - Make tig prompt commands bindable to keys. For example: `bind diff F :set diff-options = --full-diff`. (GH #69, #116) - Add a diff-options setting for specifying default diff options. Example: `set diff-options = --patience`. (GH #116) - Options in diff-options and blame-options matching tig browsing state variables are replaced. - Show diff stats as wide as the terminal. (GH #109) - Show line numbers in the branch view. (GH #135) - Add toggles for showing author email or email user names. (GH #115) - Open editor at the selected line by prefixing the file argument with `+lineno`. Tested in vi, vim, emacs, nano, gedit, geany. Disable by adding `set editor-line-number = no` to ~/.tigrc. (GH #118, #119) - Add toggle-files to control whether to show full commit diff or only the diff concerning the currently selected file, e.g. for blame. - Optionally highlight exceeding characters in long commit titles. The default title max width is 50 characters. Customize using: `set title-overflow = 50` (GH #125) - Add +ESC key bindings. Example: `bind generic ^[v move-page-up` (GH #120) - Create temporary files in TMPDIR, TEMP, or TMP before defaulting to /tmp. - Reenable `tig log` as a subcommand. (GH #146) - Enable tilde expansion in ~/.tigrc source commands. (GH #168) - Introduce the stash view, bound to the 'y' keybinding. (GH #169, #174) Bug fixes: - Fix blame and status to work in directories starting with a dot. (GH #172) - Reload current branch name when reloading the status view. (GH #93) - Fix compile errors on old Solaris. (GH #97) - Reload HEAD info when reloading the stage view. (GH #104, #93) - Fix disappearing branch labels after external commands. (GH #148) - Fix diff view display for staged/unstaged changes when using 'd'. - Fix display of status messages when toggling view options. (GH #111) - Fix illegal memory access. (GH #98) - Fix display of all branches label in repos with short branch names. - Fix rendering glitch for branch names. - Do not apply diff styling to untracked files in the stage view. (GH #153) - Fix tree indentation for entries containing combining characters. (GH #170) - Ignore unrepresentable characters when transliterating text for rendering. - Transliterate text to output encoding before trimming it to avoid misalignment. (GH #86) - Introduce a more natural context-sensitive log display. (GH #155) Change summary -- The diffstat and log summary for changes made in this release. BUGS|3 +- Makefile| 32 +- NEWS| 51 ++ SITES |1 + autogen.sh |2 +- compat/compat.h | 44 ++ compat/mkstemps.c | 152 + compat/setenv.c | 186 ++ config.make.in |4 + configure.ac| 13 +- contrib/aspell.dict |3 +- contrib/config.make-Darwin |1 + contrib/header.h| 12 + contrib/tig-completion.bash |2 +- contrib/tig.spec.in |4 + git.h |4 +- graph.c | 10 +- graph.h |5 +- io.c| 42 +- io.h|7 +- manual.txt | 34 +- refs.c | 12 +- refs.h |5 +- test-graph.c| 24 +- tig.1.txt | 18 +- tig.c | 1124 +-- tig.h | 32 +- tigrc.5.txt | 69 ++- 28 files changed, 1509 insertions(+), 387 deletions(-) 1 Aaron Franks 1 Beat Bolli 1 Dominik Vogt 2 Drew Northup 3 IWASAKI Yudai 1 Joakim Sernbrant 61 Jonas Fonseca 1 Julian Langschaedel 4
Re: git clone doesn't work in symlink dir roots on Windows
(my symdir was called 'gitto', fyi) On Sat, Aug 10, 2013 at 7:22 PM, Sedat Kapanoglu se...@eksiteknoloji.com wrote: git is a disk intense program, so this setup is not sane at all. With that said I know that git on windows historically had problems with working on smb-mounted shares (sometimes you're forced to have stupid setups). I doubt that git really is the right tool for your work, since I reproduced the same problem in a regular symlink directory. Repro steps: mkdir actualdir mklink /d symdir actualdir cd symdir git init . fatal: Invalid symlink 'D:/gitto': Function not implemented Thanks, Sedat -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] submodule: don't print status output with ignore=all
On Sun, Aug 04, 2013 at 08:24:09PM +0200, Jens Lehmann wrote: I'm a bit confused. The commit message talks about git status, but the code you changed handles git submodule summary. Looks like you are trying to fix the output of status when the status.submodulesummary option is set, right? That's a good thing to do. But your patch also changes the default behavior of git submodule summary, which is a change in behavior as that is currently not configurable via the ignore option (and I believe it should stay that way for backward compatibility reasons unless actual users provide sound reasons to change that). So a NACK on this patch from me (and a note to self that tests are missing that should have failed due to this change). Right, that wasn't the intent. As a short term solution you could honor the submodule.name.ignore setting only if --for-status is used, as that is explicitly given by git status when it forks the git submodule summary script (to make it prepend # to each line, which it could do easily itself nowadays using recently added code ;-). I think I'm going to go this route. My goal is to fix up the TODO tests and make them work so I can get more familiar with the code. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Google 토크 사용 초대장
--- GYUMIN SIM님이 Google 토크를 사용하도록 초대했습니다. 이미 Google 계정이 있는 경우 Gmail에 로그인하여 채팅 초대를 수락하세요. http://mail.google.com/mail/invite/ANGjdJ-V370ibCmQi5Wf8-H5vRs1PXVjYktJLkwo3IP8X-YOQ2Au7ONYcx4uXUlURt3pzAaAgTe1kaNptUaZ Google 계정에 가입한 후 Google 토크를 시작하려면 아래 사이트를 방문하세요. http://mail.google.com/mail/invite/ANGjdJ-Bt7og0VIh875cxNUiEF0hTe1Z-Wj3mYFnG3gf8SjynJwvFnHlaNkzhFJ5CZ8ElsMpaqHZKo7s4uyo?pc=ko-rf---a 자세한 내용은 다음 사이트를 참조하세요. http://www.google.com/intl/ko/landing/accounts/ 감사합니다. Google 팀
Re: [PATCH v2] git-p4: Ask p4 to interpret View setting
ksaitoh...@gmail.com wrote on Tue, 06 Aug 2013 15:45 +0900: In Perforce, View setting of p4 client can describe -//depot/project/files/*.xls //client/project/files/*.xls to exclude Excel files. But git p4 --use-client-spec cannot support '*'. In git-p4.py, map_in_client method analyzes View setting and return client file path. So I modify the method to just ask p4. Let me play with this for a bit. I wonder about the performance aspects of doing a p4 fstat for every file. Would it be possible to do one or a few batch queries higher up somewhere? To reduce p4 access, it cache result of asking client path. And addition, fstat depends on sync status, so modify to use p4 where instead of fstat. I played around with your patch a bit, ending up with this teensy series. I redid the code to use clientFile, not path, as that will work better with AltRoots. Also I simplified your test and added a couple more for the now-supported wildcards. And deleted a bunch of newly dead code. My only concern is in the commit message, about performance. A change that has lots of files in it will cause many roundtrips to p4d to do p4 where on each. When the files don't have much edited content, this new approach will make the import take twice as long, I'll guess. Do you have a big repository where you could test that? Tell me what you think. -- Pete -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] git p4 test: sanitize P4CHARSET
From: kazuki saitoh ksaitoh...@gmail.com In the tests, p4d is started without using internationalized mode. Make sure this environment variable is unset, otherwise a mis-matched user setting would break the tests. The error message would be Unicode clients require a unicode enabled server. [pw: use unset, add commit text] Signed-off-by: Kazuki Saitoh ksaitoh...@gmail.com Signed-off-by: Pete Wyckoff p...@padd.com --- t/lib-git-p4.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh index 2098b9b..ccd918e 100644 --- a/t/lib-git-p4.sh +++ b/t/lib-git-p4.sh @@ -48,7 +48,8 @@ P4DPORT=$((10669 + ($testid - $git_p4_test_start))) P4PORT=localhost:$P4DPORT P4CLIENT=client P4EDITOR=: -export P4PORT P4CLIENT P4EDITOR +unset P4CHARSET +export P4PORT P4CLIENT P4EDITOR P4CHARSET db=$TRASH_DIRECTORY/db cli=$TRASH_DIRECTORY/cli -- 1.8.4.rc2.88.ga5463da -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature Request: Support logic or shell execution to control values in .gitconfig
Matthieu Moy wrote: That would mean executing SOMETEXTTOEXECUTE each time the config file is read. This raises two issues: * A security issue, as SOMETEXTTOEXECUTE could also be something dangerous. It would not be much worse than the current situation (if your config file is not trusted, then an attacker could put malicious code in core.editor for example), but still increase the security risk (as any command reading the config may trigger execution). I don't think the security issue is too bad. As you say, the combination of control over core.pager and pager.config is already pretty dangerous. * A performance issue with the current git implementation, as the config file may be read many time for a single git execution. This issue is harder. Is this a feature others could get behind? I think it's unlikely that this ever be implemented. What I suggest instead is to edit/track/share template configuration files like ~/.gitconfig.in email = me@HOSTNAME@ and then script something like sed -e s/@HOSTNAME@/$(hostname)/ ~/.gitconfig.in ~/.gitconfig. Yeah, substitution scripts like this are probably the simplest way to go. Maybe some day it will make sense for commands to check the timestamp or checksum of foo.in to automatically regenerate foo on the fly when foo.in and other inputs change, but that sounds like more complication than it's worth for git to take on. Other alternatives might be to do that on the filesystem level (a FUSE filesystem or Hurd-style translator generating determining the read(2) result for foo on the fly), the editor level (vi knowing to regenerate foo when you save foo.in), or the session management level (bash via ~/.profile or ~/.bashrc or pam-login regenerating foo at the start of each interactive session). I wish there were an standard way to deal with such tasks instead of running an update script manually, but now I'm getting off topic. Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git stash takes excessively long when many untracked files present
[CCing folks involved in the recent stash-refuse-to-kill merge.] I keep portions of my home directory in git. I tried to git stash some local changes, and it ran for several minutes with no progress. ps showed that it was running git ls-files --killed, which was taking 100% CPU, and occasionally reading the disk very slowly. strace shows that git ls-files --killed is doing a full recursive enumeration of my entire home directory. That's a Really Bad Idea: ~$ find | wc -l 3248997 ~$ find -type d | wc -l 350680 Not only that, but it also appears to be attempting to stat and open several files in every single directory; for instance: stat(.ccache/1/3/.git, 0x7fff254bc7a0) = -1 ENOENT (No such file or directory) open(.ccache/1/3/.git/HEAD, O_RDONLY) = -1 ENOENT (No such file or directory) stat(.ccache/1/3/.git, 0x7fff254bc770) = -1 ENOENT (No such file or directory) open(.ccache/1/3/.git/packed-refs, O_RDONLY) = -1 ENOENT (No such file or directory) (Yes, in that order.) I see a lot of room for optimization here. Most importantly, git ls-files --killed really doesn't need to look at any directory entry unless something in the index would conflict with it. - Josh Triplett -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
How can I automatically create a GIT branch that represents a sequence of tags?
In our current setup, we have automatic tagging in git of all successful release builds. This makes it easy to go back to stable points in history and compare functionality, check when bugs were introduced etc. To help with this process further, it would be useful to be able to use git bisect, but as these are just a sequence of tags, not commits on a branch, git bisect will not work as is. Is there any tooling for automatically recreating a branch from a sequence of tags, where each generated commit is the calculated delta between each two neighbouring tags? Thanks, Kristian -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How can I automatically create a GIT branch that represents a sequence of tags?
On Sat, Aug 10, 2013 at 11:29:45PM +0100, Kristian Freed wrote: In our current setup, we have automatic tagging in git of all successful release builds. This makes it easy to go back to stable points in history and compare functionality, check when bugs were introduced etc. To help with this process further, it would be useful to be able to use git bisect, but as these are just a sequence of tags, not commits on a branch, git bisect will not work as is. Is there any tooling for automatically recreating a branch from a sequence of tags, where each generated commit is the calculated delta between each two neighbouring tags? I don't understand, why is it better to find between which tags a error was found and not in what commit. It's much easier to find a bug introduced in a commit than in a tag/release. It sounds like you're doing the bug hunting harder. Could you explain this further? It would be very hard to do a tool such as you describe, the reason is that there's no sane way to order your tags. Git today show tags alphabetically, all versions does not have a alphabtic order. You could argue that it should be in the order of the tagged commits commit date, however the commits are not ordered by date, an older commit can have a younger commit as a parent. You could say that the tag order is the order you find the tags if you go from a branch and backwards in the history, however how do you then choose which path to take when you find a merge? My suggestion if you want to do this, is to have your buildtool to checkout a special branch (let's call it tag_branch) do a git reset to get the worktree from the newly tagged commit and commit on that branch once for each tag it's creating, when it creates the tag. It would be quite easy to make a script that create such branch for you, if you only can sort the tags somehow. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] push: respect --no-thin
Over the time the default value for --thin has been switched between
on and off. As of now it's always on, even if --no-thin is given.
Correct the code to respect --no-thin.
receive-pack learns about --no-thin only for testing purposes, hence
no document update.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
v2 adds a test for push --no-thin. I figured out the problem in my
test. I hit size filtering heuristics in pack-objects.c:try_delta().
builtin/push.c | 5 ++---
builtin/receive-pack.c | 8 +++-
t/t5516-fetch-push.sh | 12
3 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/builtin/push.c b/builtin/push.c
index 04f0eaf..333a1fb 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -15,7 +15,7 @@ static const char * const push_usage[] = {
NULL,
};
-static int thin;
+static int thin = 1;
static int deleterefs;
static const char *receivepack;
static int verbosity;
@@ -313,8 +313,7 @@ static int push_with_options(struct transport *transport,
int flags)
if (receivepack)
transport_set_option(transport,
TRANS_OPT_RECEIVEPACK, receivepack);
- if (thin)
- transport_set_option(transport, TRANS_OPT_THIN, yes);
+ transport_set_option(transport, TRANS_OPT_THIN, thin ? yes : NULL);
if (verbosity 0)
fprintf(stderr, _(Pushing to %s\n), transport-url);
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index e3eb5fc..da60817 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -38,6 +38,7 @@ static int quiet;
static int prefer_ofs_delta = 1;
static int auto_update_server_info;
static int auto_gc = 1;
+static int fix_thin = 1;
static const char *head_name;
static void *head_name_to_free;
static int sent_capabilities;
@@ -869,7 +870,8 @@ static const char *unpack(int err_fd)
keeper[i++] = --stdin;
if (fsck_objects)
keeper[i++] = --strict;
- keeper[i++] = --fix-thin;
+ if (fix_thin)
+ keeper[i++] = --fix-thin;
keeper[i++] = hdr_arg;
keeper[i++] = keep_arg;
keeper[i++] = NULL;
@@ -975,6 +977,10 @@ int cmd_receive_pack(int argc, const char **argv, const
char *prefix)
stateless_rpc = 1;
continue;
}
+ if (!strcmp(arg, --no-thin)) {
+ fix_thin = 0;
+ continue;
+ }
usage(receive_pack_usage);
}
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 4691d51..e80247b 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -1172,4 +1172,16 @@ test_expect_success 'push --follow-tag only pushes
relevant tags' '
test_cmp expect actual
'
+test_expect_success 'push --no-thin must produce non-thin pack' '
+ for i in `seq 100`; do echo modified path1; done
+ git commit -am path1 big enough to pass size heuristics in try_delta
+ git init no-thin
+ git --git-dir=no-thin/.git config receive.unpacklimit 0
+ git push no-thin/.git refs/heads/master:refs/heads/foo
+ echo modified path1
+ git commit -am modified
+ git repack -adf
+ git push --no-thin --receive-pack=git receive-pack --no-thin
no-thin/.git refs/heads/master:refs/heads/foo
+'
+
test_done
--
1.8.2.83.gc99314b
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git clone doesn't work in symlink dir roots on Windows
On Sat, Aug 10, 2013 at 6:34 PM, Fredrik Gustafsson iv...@iveqy.com wrote: On Sat, Aug 10, 2013 at 07:22:03PM +0300, Sedat Kapanoglu wrote: git is a disk intense program, so this setup is not sane at all. With that said I know that git on windows historically had problems with working on smb-mounted shares (sometimes you're forced to have stupid setups). I doubt that git really is the right tool for your work, since I reproduced the same problem in a regular symlink directory. Repro steps: mkdir actualdir mklink /d symdir actualdir cd symdir git init . fatal: Invalid symlink 'D:/gitto': Function not implemented Thanks, Sedat Good, then we can determinate that this is a symlink error, it seams that readlink() isn't implemented in the msysgit version of msysgit. However msysgit should have a implementation of readlink() according to: http://mingw.5.n7.nabble.com/Replacement-for-readlink-td30679.html I've CC:ed the msysgit-maillist so that they can decide if this is something they want to address in newer releases. No, we do not. (I won't be bothered to read *yet* another thread about someone who thinks they know how symlinks should work on Windows, so I'll assume it's the Cygwin-take... which is the most senseful IMO) Symlinks in Cygwin are generally not compatible with native Windows applications. And Windows symlinks are not at all compatible with POSIX-symlinks. At all. Whoever wants symlink support in Git for Windows have clearly not considered how this would work (or more likely, break). It's an idea built on misunderstanding and poor engineering-concepts. There's no way we can support symlinks in a clean, Windows specific way. So let's not even pretend it works. That being said, we could probably error out in a more senseful way. But if so,suggestions/patches welcome. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
document git blame --no-follow and git diff --no-follow
Hi, Please document git blame --no-follow and git diff --no-follow Regards, ch3cooli -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] push: respect --no-thin
On Sat, Aug 10, 2013 at 9:24 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: Over the time the default value for --thin has been switched between on and off. As of now it's always on, even if --no-thin is given. Correct the code to respect --no-thin. receive-pack learns about --no-thin only for testing purposes, hence no document update. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh index 4691d51..e80247b 100755 --- a/t/t5516-fetch-push.sh +++ b/t/t5516-fetch-push.sh @@ -1172,4 +1172,16 @@ test_expect_success 'push --follow-tag only pushes relevant tags' ' test_cmp expect actual ' +test_expect_success 'push --no-thin must produce non-thin pack' ' + for i in `seq 100`; do echo modified path1; done s/seq/test_seq/ d17cf5f3a32f07bf (tests: Introduce test_seq; 2012-08-03) + git commit -am path1 big enough to pass size heuristics in try_delta + git init no-thin + git --git-dir=no-thin/.git config receive.unpacklimit 0 + git push no-thin/.git refs/heads/master:refs/heads/foo + echo modified path1 + git commit -am modified + git repack -adf + git push --no-thin --receive-pack=git receive-pack --no-thin no-thin/.git refs/heads/master:refs/heads/foo +' + test_done -- 1.8.2.83.gc99314b -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How can I automatically create a GIT branch that represents a sequence of tags?
On 08/11/2013 01:20 AM, Fredrik Gustafsson wrote: [...] It would be very hard to do a tool such as you describe, the reason is that there's no sane way to order your tags. Git today show tags alphabetically, all versions does not have a alphabtic order. [...] It would be quite easy to make a script that create such branch for you, if you only can sort the tags somehow. GNU sort has a nice option that can sort this way: -V, --version-sort Sort by version name and number. It behaves like a standard sort, except that each sequence of decimal digits is treated numerically as an index/version number. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
