Re: [PATCH] bash completion: Add --recurse-submodules
Sup Yut Sum ch3co...@gmail.com writes: Signed-off-by: Sup Yut Sum ch3co...@gmail.com --- contrib/completion/git-completion.bash | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) Aren't you missing a commit message? -Keshav -- 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: Aw: Re: Re: Re: [Bug report] 'git status' always says Your branch is up-to-date with 'origin/master'
The following message is a courtesy copy of an article that has been posted to gmane.comp.version-control.git as well. Junio C Hamano gits...@pobox.com writes: Thomas Ackermann th.ac...@arcor.de writes: But for the simple use case where you only have a master branch I consider it not really helpful and - at least for me - misleading. I see what you mean, and you're not the only one. Git follows a rule of never contact another machine unless explicitly asked to using a command such as 'git pull' or 'git fetch'. To support this, it makes a distinction between (1) the remote-tracking ref origin/master and (2) the actual branch master in the remote repository. The former is what is updated by 'git fetch', and the latter is something git does not know about without talking to the remote server. What documentation did you use when first starting to learn git? Perhaps it can be fixed to emphasize the distinction between (1) and (2) earlier. I think it's not the problem of the documentation but of myself not having it read thorough enough ;-) (This new feature in V1.8.5 of course is not documented in any of the books up to now but in the future could be used to explain the above mentioned rule.) By the way, this is nothing new in 1.8.5; we didn't bother saying up-to-date before, so you may not have noticed, but its silence was already telling you that your branch was up-to-date with respect to what you are building on top of. Maybe it would be worthwhile to add a message like (last fetched from upstream branch at [date]), taken from $GIT_DIR/logs/refs/remotes/foo/bar ? This would mitigate the confusion Thomas suffered, I think. Caveat: pretty ill-defined, since 1) if you've been pushing and not fetching, the most recent time at which it is known that your remote-tracking branch was up to date could be much newer than when it was technically last fetched; 2) the upstream branch might not even be a remote-tracking branch; 3) probably something else I haven't thought of. -Keshav -- 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] drop support for experimental loose objects
Duy Nguyen pclo...@gmail.com writes:
On Thu, Nov 21, 2013 at 6:48 PM, Jeff King p...@peff.net wrote:
@@ -1514,14 +1469,6 @@ unsigned long unpack_object_header_buffer(const
unsigned char *buf,
int unpack_sha1_header(git_zstream *stream, unsigned char *map, unsigned
long mapsize, void *buffer, unsigned long bufsiz)
{
- unsigned long size, used;
- static const char valid_loose_object_type[8] = {
- 0, /* OBJ_EXT */
- 1, 1, 1, 1, /* commit, tree, blob, tag */
- 0, /* delta and others are invalid in a loose object */
- };
- enum object_type type;
-
/* Get the data stream */
memset(stream, 0, sizeof(*stream));
stream-next_in = map;
@@ -1529,27 +1476,6 @@ int unpack_sha1_header(git_zstream *stream, unsigned
char *map, unsigned long ma
stream-next_out = buffer;
stream-avail_out = bufsiz;
- if (experimental_loose_object(map)) {
Perhaps keep this..
- /*
-* The old experimental format we no longer produce;
-* we can still read it.
-*/
- used = unpack_object_header_buffer(map, mapsize, type,
size);
- if (!used || !valid_loose_object_type[type])
- return -1;
- map += used;
- mapsize -= used;
-
- /* Set up the stream for the rest.. */
- stream-next_in = map;
- stream-avail_in = mapsize;
- git_inflate_init(stream);
-
- /* And generate the fake traditional header */
- stream-total_out = 1 + snprintf(buffer, bufsiz, %s %lu,
-typename(type), size);
- return 0;
and replace all this with
die(detected an object in obsolete format, please repack the
repository using a version before XXX);
?
Wouldn't that fail to solve the issue of `git fsck` dying on corrupt
data? experimental_loose_object() would need to be rewritten to be more
conservative in deciding that an object was in the experimental loose
object format.
-Keshav
--
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: Command-line git Vs IDE+plugin?
Thomas Koch tho...@koch.ro writes: But also from experience I can tell that without exception everybody whom I teached Git understood it only after being introduced to the basic concepts of Git and how to inspect and operate them on the commandline. Others told me from similar experiences. Those concepts are: - hashes - content adressable storage - blops being referenced by trees being referenced by commits A great reference I always point people to for exactly those reasons is Sitaram Chamarty's git concepts simplified: http://gitolite.com/gcs/ -Keshav -- 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: Selectively commit/publish files to GIT
Thomas Manson dev.mansontho...@gmail.com writes: The problem is that in Bazaar, I've commited some big files (63MB 173MB), but this files are no longer in my project, only in the revisions files of Bazaar and now Git. I don't need this files to be pushed on Github. How can I search git history for big files and remove them, or mark them to be not published ? I see you already solved your problem, but for future reference, there is a nice tool that is more limited in functionality than git filter-branch but also much faster and possibly easier to use: http://rtyley.github.io/bfg-repo-cleaner/ -Keshav -- 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: rcs
Finnerty, James M Mr CTR USA USASOC-SOAR jim.finnerty@soar.army.mil writes: Hi. I'm going to attempt to import a git database into Razor which is linux rcs based. Does the linux version of git use rcs ? If you're talking about the GNU rcs program, no, it does not. -Keshav -- 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] graph.c: visual difference on subsequent series
Junio C Hamano gits...@pobox.com writes: [administrivia: please avoid culling addresses from To:/Cc: lines] Yikes, sorry about that. I've been sending messages through Gmane rather than via email, and I didn't realize the list didn't automatically send messages to the appropriate people who are only reading the list via actual email (as I am not such a person). Keshav Kini keshav.k...@gmail.com writes: What about just putting an extra blank line after every root commit line (possibly except the last one)? That should make it plenty easy to see where the root commits are in --oneline mode. I think it would actually be easier to spot at a glance than replacing `*` with `x` because it creates a gap in all columns of the output, rather than only in column 1. Also, this is very subjective but I think it looks kind of ugly to use x :P I agree to all of the above, including the ugliness of 'x' ;-) A blank may however be hard to spot, if the range is limited, though. For example, $ git log --graph --oneline a4.. * HEAD /* a1 | * a2 | * a3 * b1 * b2 * b3 where a4, which is a root, is the sole parent of a3 and HEAD is a merge between a1 and b1 might produce something like this, while we may get this from the same history, when shown unlimited: $ git log --graph --oneline * HEAD /* a1 | * a2 | * a3 | * a4 | * b1 * b2 * b3 A divider line might make it visually a lot more strong, i.e. $ git log --graph --oneline * HEAD /* a1 | * a2 | * a3 | * a4 | ~~~ * b1 * b2 * b3 but I am not sure if it is too distracting. I would be fine with that, fwiw. We can also turn it on and off with a config option if people really don't like it, I suppose... -Keshav -- 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?] inconsistent `git reflog show` output, possibly `git fsck` output
Junio C Hamano gits...@pobox.com writes: Roberto Tyley roberto.ty...@gmail.com writes: On 21/09/2013 23:16, Keshav Kini wrote: [SNIP] This situation came about because the BFG Repo-Cleaner doesn't write new reflog entries after creating its new objects and moving refs around. True enough - I don't think the BFG does write new entires to the reflog when it does the final ref-update, and it would be nicer if it did. I'll get that fixed. (sorry for replying late) So this can be closed as BFG not writing reflog in a consistent way, and 'git reflog show' is acting GIGO way? Or was there something the core side needs to do? Hi Junio, Below I'm resending a mail that I sent to the list earlier, but not to you or Roberto personally, as I just realized. So in case you didn't see it before, here it is -- if you did see it before, sorry for the noise. Hi Junio, Thanks for your reply. In my original mail, immediately after the snippet Roberto quoted above, I said, But that aside, I think how git handles the situation might be a bug. To wit: It seems to me that one of two things should be the case. Either 1) it should be considered impossible to have a reflog for a ref X which doesn't contain a chain of commits leading up to the current location of X; or 2) if reflogs are allowed not to form an unbroken chain of commits leading to X, then `git reflog show` should at least make sure to actually display a commit ID corresponding to the second field of each reflog entry it reads, and not some other commit ID. In the first case, the bug is that `git fsck` doesn't catch the supposedly impossible situation that exists in the repository I've described in this email. In the second case, the bug is that `git reflog show` has bad output. Before this is closed, I would appreciate it if I could get some feedback from git developers on the above two paragraphs. Thanks, Keshav -- 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] graph.c: visual difference on subsequent series
Milton Soares Filho milton.soares.fi...@gmail.com writes: On 25 October 2013 15:13, Junio C Hamano gits...@pobox.com wrote: Milton Soares Filho milton.soares.fi...@gmail.com writes: git log --graph --oneline * a1 * a2 x a3 * b1 * b2 x b3 I agree that the problem you are trying to solve is a good thing to tackle, and I also agree that marking a root commit differently from other commits is one way to solve it, but I am not sure if that is the best way. If the stretches of a's and b's in your history are very long, wouldn't it be easier to spot if they are painted in different colours, in addition to or instead of marking the roots differently [*1*], for example? Thanks for taking your time reviewing this patch, Junio. I didn't really thought it would get any attention since multiple root-commits is not a very common use-case[1]. However, if most people got excited with git-subtree new features as I did, there is a good chance that multiple root-commits are going to become a common-place in the near future ;-) I don't think this is that obscure. I've often thought there should be some way to distinguish root commits as well. In fact when dealing with multiple root commits I usually just don't use --oneline and instead use the full --graph view so I can find root commits by grepping for '^ ' :) I should also mention that there are lots of situations where you might see multiple root commits not because there are truly multiple commits with no parent in the repository, but because you're looking at some subgraph of the history graph -- that is, you have multiple commits in your display whose parents are purposely excluded. For example, you might be looking at a revision list like 'C ^A ^B': master | .---B | / `-. O .---`--C | \ / | `---A The commits you were looking at would be these ones: `-. .---`--C / So multiple roots can appear easily in such cases. That said, I completely agree that painting with different colors would be a much better fix, however I believe that it can be done in a separate changeset by someone that understands better the impact on the rest of the system. Personally, changing only the mark is sufficient because: a) it'll work on terminal types without coloring support and configurations whose explicitly disable it b) it'll spare myself of running a separate GUI program just to spot where each series begin c) it won't require any visual design skills from a developer (me) without a minimal sense for it :-) I'm a bit worried that if someone is parsing `git log --graph` output looking for `*` lines they might suddenly start missing the root commits that they were previously able to find. I mean, not that anyone should be doing that, but if we can avoid breaking that, why not do so? What about just putting an extra blank line after every root commit line (possibly except the last one)? That should make it plenty easy to see where the root commits are in --oneline mode. I think it would actually be easier to spot at a glance than replacing `*` with `x` because it creates a gap in all columns of the output, rather than only in column 1. Also, this is very subjective but I think it looks kind of ugly to use x :P By the by, you might want to use the `-v` argument to `git send-email` so that people reading the list can tell at a glance which patch versions are newer than which other patch versions. -Keshav -- 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-svn documentation: Use tabs consistently within the ascii doc
Stefan Beller stefanbel...@googlemail.com writes: While I can understand 4 or 7 white spaces are fancy, we'd rather want to use tabs throughout the whole document. You missed lines 278 and 833. There are also some spaces around line 488, but maybe those are layout-relevant and so shouldn't be converted to tabs. -Keshav -- 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?] inconsistent `git reflog show` output, possibly `git fsck` output
Junio C Hamano gits...@pobox.com writes: Roberto Tyley roberto.ty...@gmail.com writes: On 21/09/2013 23:16, Keshav Kini wrote: [SNIP] This situation came about because the BFG Repo-Cleaner doesn't write new reflog entries after creating its new objects and moving refs around. True enough - I don't think the BFG does write new entires to the reflog when it does the final ref-update, and it would be nicer if it did. I'll get that fixed. (sorry for replying late) So this can be closed as BFG not writing reflog in a consistent way, and 'git reflog show' is acting GIGO way? Or was there something the core side needs to do? Hi Junio, Thanks for your reply. In my original mail, immediately after the snippet Roberto quoted above, I said, But that aside, I think how git handles the situation might be a bug. To wit: It seems to me that one of two things should be the case. Either 1) it should be considered impossible to have a reflog for a ref X which doesn't contain a chain of commits leading up to the current location of X; or 2) if reflogs are allowed not to form an unbroken chain of commits leading to X, then `git reflog show` should at least make sure to actually display a commit ID corresponding to the second field of each reflog entry it reads, and not some other commit ID. In the first case, the bug is that `git fsck` doesn't catch the supposedly impossible situation that exists in the repository I've described in this email. In the second case, the bug is that `git reflog show` has bad output. Before this is closed, I would appreciate it if I could get some feedback from git developers on the above two paragraphs. Thanks, Keshav -- 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 v5] diff.c: keep arrow(=) on show_stats()'s shortened filename part to make rename visible.
Junio C Hamano gits...@pobox.com writes:
Yoshioka Tsuneo yoshiokatsu...@gmail.com writes:
git diff -M --stat can detect rename and show renamed file name like
foofoofoo = barbarbar. But if destination filename is long, the line
is shortened like ...barbarbar so there is no way to know whether the
file is renamed or existed in the source commit.
Is destination filename more special than the source filename?
Perhaps s/if destination filename is/if filenames are/?
Note: I do not want you to reroll using the suggested
wording without explanation; it may be possible that I am
missing something obvious and do not understand why you
singled out destination, in which case I'd rather see it
explained better in the log message than the potentially
suboptimal suggestion I made in the review without
understanding the issue. Of course, it is possible that you
want to do the same when source is overlong, in which case
you can just say Yeah, you're right; will reroll.
The above applies to all the other comments in this message.
Also s/source commit/original/. You may not be comparing two
commits after all.
Make sure there is always an arrow, like ...foo = ...bar.
The output can contains curly braces('{','}') for grouping.
s/contains/contain/;
So, in general, the outpu format is pfx{mid_a = mid_b}sfx
s/outpu/t/;
To keep arrow(=), try to omit pfx as long as possible at first
because later part or changing part will be the more important part.
If it is not enough, shorten mid_a, mid_b, and sfx trying to
have the maximum length the same because those will be equaly important.
A sound reasoning.
Also s/equaly/equally/;
-Keshav
--
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: [spf:guess,mismatch] [PATCH v2] diff.c: keep arrow(=) on show_stats()'s shortened filename part to make rename visible.
Sam Vilain s...@vilain.net writes: On 10/11/2013 06:07 AM, Yoshioka Tsuneo wrote: +prefix_len = ((prefix_len = 0) ? prefix_len : 0); +strncpy(pre_arrow, arrow - prefix_len, prefix_len); +pre_arrow[prefix_len] = '¥0'; This seems to be an encoding mistake; was this supposed to be an ASCII arrow? That's supposed to be a null terminator character, '\0'. See https://en.wikipedia.org/wiki/Yen_symbol#Code_page_932 -Keshav -- 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 0/4] git-svn.txt: miscellaneous changes
I'm not sure if this was the best way to split my changes into commits. Please let me know if it wasn't. Keshav Kini (4): git-svn.txt: fix AsciiDoc formatting error git-svn.txt: reword description of gc command git-svn.txt: replace .git with $GIT_DIR git-svn.txt: elaborate on rev_map files Documentation/git-svn.txt | 46 +- 1 file changed, 33 insertions(+), 13 deletions(-) -- 1.8.3.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
[PATCH v2 3/4] git-svn.txt: replace .git with $GIT_DIR
As $GIT_DIR may not equal '.git', it's usually more generally correct to refer to files in $GIT_DIR rather than in .git . This will also allow me to link some of the occurrences of '.git' in git-svn.txt to a new reference target inside this file in an upcoming commit, because in AsciiDoc definitions apparently can't start with a '.' character. Signed-off-by: Keshav Kini keshav.k...@gmail.com --- Documentation/git-svn.txt | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 62ec727..3ddf545 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -104,8 +104,8 @@ COMMANDS 'fetch':: Fetch unfetched revisions from the Subversion remote we are tracking. The name of the [svn-remote ...] section in the - .git/config file may be specified as an optional command-line - argument. + $GIT_DIR/config file may be specified as an optional + command-line argument. --localtime;; Store Git commit times in the local timezone instead of UTC. This @@ -684,7 +684,7 @@ svn-remote.name.noMetadata:: + This option can only be used for one-shot imports as 'git svn' will not be able to fetch again without metadata. Additionally, -if you lose your .git/svn/\*\*/.rev_map.* files, 'git svn' will not +if you lose your $GIT_DIR/svn/\*\*/.rev_map.* files, 'git svn' will not be able to rebuild them. + The 'git svn log' command will not work on repositories using @@ -977,8 +977,8 @@ When using multiple --branches or --tags, 'git svn' does not automatically handle name collisions (for example, if two branches from different paths have the same name, or if a branch and a tag have the same name). In these cases, use 'init' to set up your Git repository then, before your first 'fetch', edit -the .git/config file so that the branches and tags are associated with -different name spaces. For example: +the $GIT_DIR/config file so that the branches and tags are associated +with different name spaces. For example: branches = stable/*:refs/remotes/svn/stable/* branches = debug/*:refs/remotes/svn/debug/* @@ -1006,7 +1006,7 @@ CONFIGURATION - 'git svn' stores [svn-remote] configuration information in the -repository .git/config file. It is similar the core Git +repository $GIT_DIR/config file. It is similar the core Git [remote] sections except 'fetch' keys do not accept glob arguments; but they are instead handled by the 'branches' and 'tags' keys. Since some SVN repositories are oddly @@ -1060,8 +1060,8 @@ $ git svn branch -d branches/server release-2-3-0 Note that git-svn keeps track of the highest revision in which a branch or tag has appeared. If the subset of branches or tags is changed after -fetching, then .git/svn/.metadata must be manually edited to remove (or -reset) branches-maxRev and/or tags-maxRev as appropriate. +fetching, then $GIT_DIR/svn/.metadata must be manually edited to remove +(or reset) branches-maxRev and/or tags-maxRev as appropriate. SEE ALSO -- 1.8.3.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
[PATCH v2 1/4] git-svn.txt: fix AsciiDoc formatting error
As asterisks are used to indicate bold text in AsciiDoc, shell glob expressions must be escaped appropriately. Signed-off-by: Keshav Kini keshav.k...@gmail.com --- Documentation/git-svn.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 4dd3bcb..239c33c 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -684,7 +684,7 @@ svn-remote.name.noMetadata:: + This option can only be used for one-shot imports as 'git svn' will not be able to fetch again without metadata. Additionally, -if you lose your .git/svn/**/.rev_map.* files, 'git svn' will not +if you lose your .git/svn/\*\*/.rev_map.* files, 'git svn' will not be able to rebuild them. + The 'git svn log' command will not work on repositories using -- 1.8.3.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
[PATCH v2 2/4] git-svn.txt: reword description of gc command
It's redundant to say that $GIT_DIR/svn/refname/unhandled.log or $GIT_DIR/svn/refname/index is in .git/svn when $GIT_DIR is '.git', and is wrong when $GIT_DIR is not '.git' Also, a '/' was missing from the pathname $GIT_DIR/svn/refname/index . Signed-off-by: Keshav Kini keshav.k...@gmail.com --- Documentation/git-svn.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 239c33c..62ec727 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -435,8 +435,8 @@ Any other arguments are passed directly to 'git log' specific revision. 'gc':: - Compress $GIT_DIR/svn/refname/unhandled.log files in .git/svn - and remove $GIT_DIR/svn/refnameindex files in .git/svn. + Compress $GIT_DIR/svn/refname/unhandled.log files and remove + $GIT_DIR/svn/refname/index files. 'reset':: Undoes the effects of 'fetch' back to the specified revision. -- 1.8.3.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
[PATCH v2 4/4] git-svn.txt: elaborate on rev_map files
The man page for `git svn` describes a situation in which 'git svn' will not be able to rebuild your $GIT_DIR/svn/**/.rev_map* files, but no mention is made of in what circumstances `git svn` *will* be able to do so, how to get `git svn` to do so, or even what these files are. This patch adds a FILES section to the man page with a description of what $GIT_DIR/svn/**/.rev_map* files are and how they are (re)built, and links to this description from various other parts of the man page. Signed-off-by: Keshav Kini keshav.k...@gmail.com --- Documentation/git-svn.txt | 28 1 file changed, 24 insertions(+), 4 deletions(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 3ddf545..5383496 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -106,6 +106,9 @@ COMMANDS tracking. The name of the [svn-remote ...] section in the $GIT_DIR/config file may be specified as an optional command-line argument. ++ +This automatically updates the rev_map if needed (see +'$GIT_DIR/svn/\*\*/.rev_map.*' in the FILES section below for details). --localtime;; Store Git commit times in the local timezone instead of UTC. This @@ -201,6 +204,9 @@ accept. However, '--fetch-all' only fetches from the current + Like 'git rebase'; this requires that the working tree be clean and have no uncommitted changes. ++ +This automatically updates the rev_map if needed (see +'$GIT_DIR/svn/\*\*/.rev_map.*' in the FILES section below for details). -l;; --local;; @@ -449,9 +455,10 @@ Any other arguments are passed directly to 'git log' file cannot be ignored forever (with --ignore-paths) the only way to repair the repo is to use 'reset'. + -Only the rev_map and refs/remotes/git-svn are changed. Follow 'reset' -with a 'fetch' and then 'git reset' or 'git rebase' to move local -branches onto the new tree. +Only the rev_map and refs/remotes/git-svn are changed (see +'$GIT_DIR/svn/\*\*/.rev_map.*' in the FILES section below for details). +Follow 'reset' with a 'fetch' and then 'git reset' or 'git rebase' to +move local branches onto the new tree. -r n;; --revision=n;; @@ -684,7 +691,7 @@ svn-remote.name.noMetadata:: + This option can only be used for one-shot imports as 'git svn' will not be able to fetch again without metadata. Additionally, -if you lose your $GIT_DIR/svn/\*\*/.rev_map.* files, 'git svn' will not +if you lose your '$GIT_DIR/svn/\*\*/.rev_map.*' files, 'git svn' will not be able to rebuild them. + The 'git svn log' command will not work on repositories using @@ -1063,6 +1070,19 @@ or tag has appeared. If the subset of branches or tags is changed after fetching, then $GIT_DIR/svn/.metadata must be manually edited to remove (or reset) branches-maxRev and/or tags-maxRev as appropriate. +FILES +- +$GIT_DIR/svn/\*\*/.rev_map.*:: + Mapping between Subversion revision numbers and Git commit + names. In a repository where the noMetadata option is not set, + this can be rebuilt from the git-svn-id: lines that are at the + end of every commit (see the 'svn.noMetadata' section above for + details). ++ +'git svn fetch' and 'git svn rebase' automatically update the rev_map +if it is missing or not up to date. 'git svn reset' automatically +rewinds it. + SEE ALSO linkgit:git-rebase[1] -- 1.8.3.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
Re: [PATCH] RelNotes/1.8.5: direct script writers to git status --porcelain
Jakub Narebski jna...@gmail.com writes: Matthieu Moy Matthieu.Moy at imag.fr writes: * git status now omits the prefix to make its output a comment in a commit log editor, which is not necessary for human consumption. + Scripts that parse the output of git status are advised to use + git status --porcelain, which is both easier to parse and stable, + instead. Good addition. Perhaps to use instead ... would be easier to understand than proposed to use ..., instead. (with ... being one line long). FWIW, I find to use instead ___ slightly stilted. I'd suggest to instead use, but rewording it to the following is much better, IMHO: '... are advised to use git status --porcelain instead, as it is both stable and easier to parse.' -Keshav -- 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] Remove ciabot from contrib
Stefan Beller stefanbel...@googlemail.com writes: According to http://thread.gmane.org/gmane.comp.version-control.git/212649 Eric, the original author of ciabot, doesn't want the ciabot no longer be included in git.git, hence the removal of the whole directory. I take it you mean that he doesn't want the ciabot *any* longer be included in git.git, right? I would rephrase it as follows: Eric, the original author of ciabot, no longer wants the ciabot to be included in git.git, hence the removal of the whole directory. See http://thread.gmane.org/gmane.comp.version-control.git/212649 . -Keshav -- 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-svn.txt: mention how to rebuild rev_map files
Jonathan Nieder jrnie...@gmail.com writes: Taking a step back, the reader might wonder *why* he would want to run git svn fetch to rebuilt these .rev_map.* files, and what they are for. Perhaps there should be a separate REVISION MAP section describing this in more detail. Something as simple as FILES - .git/svn/\*\*/.rev_map.\*:: Mapping between Subversion revision numbers and Git commit names. Can be rebuilt using the git-svn-id: lines at the end of every commit as long as the noMetadata option is not set (see the 'svn.noMetadata' section above for details). + 'git svn fetch' and 'git svn rebase' automatically update the rev_map if it is missing or not up to date. 'git svn reset' automatically rewinds it. Then this reference in 'fetch' could just say something like ... argument. + This automatically updates the rev_map if needed (see '.git/svn/\*\*/.rev_map.\*' in the FILES section below for details). Note that only the first two asterisks are escaped in my patch. For some reason, escaping all three causes a literal '\' to appear in asciidoc's output... I changed the wording of your first paragraph a bit according to what I thought it meant. Does it still convey what you wanted to convey, and is it still correct? Mapping between Subversion revision numbers and Git commit names. In a repository where the noMetadata option is not set, this can be rebuilt from the git-svn-id: lines that are at the end of every commit (see the 'svn.noMetadata' section above for details). Also, I'm having a bit of trouble trying to get a definition to start with a '.' character in AsciiDoc. Escaping the '.' produces a definition block, but with a literal '\' before the '.'. If I don't escape the '.', asciidoc thinks it's a section heading or something. Is asciidoc just incapable of doing this, or am I missing something? -Keshav -- 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-svn.txt: mention how to rebuild rev_map files
Jonathan Nieder jrnie...@gmail.com writes: Keshav Kini wrote: I changed the wording of your first paragraph a bit according to what I thought it meant. Does it still convey what you wanted to convey, and is it still correct? Mapping between Subversion revision numbers and Git commit names. In a repository where the noMetadata option is not set, this can be rebuilt from the git-svn-id: lines that are at the end of every commit (see the 'svn.noMetadata' section above for details). Sounds good. Also, I'm having a bit of trouble trying to get a definition to start with a '.' character in AsciiDoc. Escaping the '.' produces a definition block, but with a literal '\' before the '.'. If I don't escape the '.', asciidoc thinks it's a section heading or something. Is asciidoc just incapable of doing this, or am I missing something? Oh. Yeah, this can be a pain. Quoting the filename with `backticks` might work. Writing $GIT_DIR instead of .git might be simpler (see v1.5.3.2~18 Documentation/git-config.txt: AsciiDoc tweak to avoid leading dot, 2007-09-14). Good point. Actually it seems to me that writing $GIT_DIR is in fact more correct, since $GIT_DIR need not be .git at all. So I'll just use that. Reroll coming up in a bit. -Keshav -- 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-svn.txt: mention how to rebuild rev_map files
Jonathan Nieder jrnie...@gmail.com writes: @@ -684,7 +687,7 @@ svn-remote.name.noMetadata:: + This option can only be used for one-shot imports as 'git svn' will not be able to fetch again without metadata. Additionally, -if you lose your .git/svn/**/.rev_map.* files, 'git svn' will not +if you lose your .git/svn/\*\*/.rev_map.* files, 'git svn' will not I don't mind seeing this fix snuck into the same commit, but a separate commit that could be applied more quickly would be even better. ;-) May I also roll into said commit a couple of replacements of .git with $GIT_DIR in the same file, or other such minor touchups? -Keshav -- 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 checkout foo is getting confused by folder named foo
David Aguilar dav...@gmail.com writes: On Tue, Sep 24, 2013 at 2:07 PM, Jona Christopher Sahnwaldt j...@sahnwaldt.de wrote: Hi, maybe this has already been reported, but I didn't find it in the mail archive. If I understand correctly, after I clone a repo, I should be able to switch to branch foo just by running git checkout foo This doesn't seem to work if a folder called foo exists in the root of the repo. git checkout foo -- The double-dash at the end disambiguates between refs and paths. You can use that trick on any command that accepts refspec (branches, tags, etc) and pathspec (path patterns). I was going to reply with similar advice, but I actually tried it on the example repo and it didn't work. Apparently it doesn't interoperate properly with the functionality that guesses when you're trying to check out a remote branch and creates an equivalently named local branch. [2] fs@erdos /tmp $ git clone https://github.com/dbpedia/extraction-framework.git Cloning into 'extraction-framework'... remote: Counting objects: 33513, done. remote: Compressing objects: 100% (6633/6633), done. remote: Total 33513 (delta 19000), reused 32922 (delta 18436) Receiving objects: 100% (33513/33513), 23.48 MiB | 747.00 KiB/s, done. Resolving deltas: 100% (19000/19000), done. Checking connectivity... done [2] fs@erdos /tmp $ cd extraction-framework/ [2] fs@erdos /tmp/extraction-framework $ git checkout live-dev -- fatal: invalid reference: live-dev [2] fs@erdos /tmp/extraction-framework $ git checkout live-dev Branch live-dev set up to track remote branch live-dev from origin. Switched to a new branch 'live-dev' [2] fs@erdos /tmp/extraction-framework $ git checkout master Switched to branch 'master' [2] fs@erdos /tmp/extraction-framework $ git checkout wiktionary [2] fs@erdos /tmp/extraction-framework $ git branch live-dev * master [2] fs@erdos /tmp/extraction-framework $ git checkout wiktionary -- fatal: invalid reference: wiktionary -Keshav -- 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] git-svn.txt: mention how to rebuild rev_map files
The man page for `git svn` describes a situation in which 'git svn' will not be able to rebuild your .git/svn/**/.rev_map files, but no mention is made of in what circumstances `git svn` *will* be able to do so, or how to get `git svn` to do so. This patch adds some language to the description of the 'fetch' command to rectify this oversight, and also fixes an AsciiDoc escaping typo. Signed-off-by: Keshav Kini keshav.k...@gmail.com --- Documentation/git-svn.txt | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 4dd3bcb..040117a 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -103,9 +103,12 @@ COMMANDS 'fetch':: Fetch unfetched revisions from the Subversion remote we are - tracking. The name of the [svn-remote ...] section in the - .git/config file may be specified as an optional command-line - argument. + tracking. If necessary, rebuild the .git/svn/\*\*/.rev_map.* + files, given the requisite information exists in commit + messages (see the svn.noMetadata config option for more + information). The name of the [svn-remote ...] section in + the .git/config file may be specified as an optional + command-line argument. --localtime;; Store Git commit times in the local timezone instead of UTC. This @@ -684,7 +687,7 @@ svn-remote.name.noMetadata:: + This option can only be used for one-shot imports as 'git svn' will not be able to fetch again without metadata. Additionally, -if you lose your .git/svn/**/.rev_map.* files, 'git svn' will not +if you lose your .git/svn/\*\*/.rev_map.* files, 'git svn' will not be able to rebuild them. + The 'git svn log' command will not work on repositories using -- 1.8.3.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
[BUG?] inconsistent `git reflog show` output, possibly `git fsck` output
Hello,
When trying out Roberto Tyley's BFG Repo-Cleaner program [1], I managed
to put a git repository in the following state:
[2] fs@erdos /tmp/bfg-test-repo $ cat .git/logs/HEAD
00afb9f9a0c87dba4a203413358984e9f4fa5ffb Keshav Kini keshav.k...@gmail.com
1379746570 -0500 clone: from /home/fs/work/x86
[2] fs@erdos /tmp/bfg-test-repo $ git rev-parse HEAD
a29caa4646698bcf2273cc60d3d612593b4ced8f
[2] fs@erdos /tmp/bfg-test-repo $ git reflog | cat
a29caa4 (HEAD, refs/remotes/origin/HEAD,
refs/remotes/origin/32-bit-accesses, refs/heads/32-bit-accesses) HEAD@{0}:
clone: from /home/fs/work/x86
[2] fs@erdos /tmp/bfg-test-repo $ git fsck
Checking object directories: 100% (256/256), done.
Checking objects: 100% (6635/6635), done.
[2] fs@erdos /tmp/bfg-test-repo $ echo $?
0
This situation came about because the BFG Repo-Cleaner doesn't write new
reflog entries after creating its new objects and moving refs around.
But that aside, I think how git handles the situation might be a bug.
As you can see, HEAD is currently at a29caa46, but the reflog's data
file .git/logs/HEAD doesn't describe how it came to be at a29caa46. The
single reflog entry describes how the HEAD pointer was initialized to
00afb9f9 when I cloned the repository from /home/fs/work/x86 .
By the wording of the `git reflog` man page, I would assume that the
lines displayed by `git reflog show HEAD` would correspond to a chain of
reflog entries, where the short commit ID at the beginning of each line
would represent the second field of the reflog entry in question, and
the first field of the reflog entry would correspond to the short commit
ID at the beginning of the line directly below. For example, if `git
reflog show HEAD` displayed this:
0123456 [stuff] foo
789abcd [stuff] bar
ef01234 [stuff] baz
Then I would expect the reflog data file for HEAD to look something like
this, where '.' represents an unknown hex digit:
789abcd.
0123456. [stuff]
ef01234.
789abcd. [stuff]
ef01234. [stuff]
However, in this example, the short commit ID shown in `git reflog show`
doesn't even appear in the reflog data file!
It seems to me that one of two things should be the case. Either 1) it
should be considered impossible to have a reflog for a ref X which
doesn't contain a chain of commits leading up to the current location of
X; or 2) if reflogs are allowed not to form an unbroken chain of commits
leading to X, then `git reflog show` should at least make sure to
actually display a commit ID corresponding to the second field of each
reflog entry it reads, and not some other commit ID.
In the first case, the bug is that `git fsck` doesn't catch the
supposedly impossible situation that exists in the repository I've
described in this email. In the second case, the bug is that `git reflog
show` has bad output.
I'm reporting this because I was having difficulty figuring out why `git
gc` was not collecting the commit 00afb9f. The reason turned out to be
that it was mentioned in a reflog and thus not getting pruned, which
would have been much easier to discover had the output of `git reflog
show` mentioned 00afb9f at all.
Please let me know what you think.
Thanks,
Keshav
[1] http://rtyley.github.io/bfg-repo-cleaner/
--
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?] inconsistent `git reflog show` output, possibly `git fsck` output
Keshav Kini keshav.k...@gmail.com writes: For example, if `git reflog show HEAD` displayed this: 0123456 [stuff] foo 789abcd [stuff] bar ef01234 [stuff] baz Then I would expect the reflog data file for HEAD to look something like this, where '.' represents an unknown hex digit: 789abcd. 0123456. [stuff] ef01234. 789abcd. [stuff] ef01234. [stuff] Sorry, that's backwards -- I would actually expect this: ef01234. [stuff] ef01234. 789abcd. [stuff] 789abcd. 0123456. [stuff] -Keshav -- 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
