Re: [PATCH] rebase --preserve-merges keeps empty merge commits
On Fri, Feb 1, 2013 at 1:05 PM, Phil Hord ho...@cisco.com wrote: This is probably right, but it is not exactly the case that caused my itch. I think my branch looked like [...] That also makes sense. I'll add tests for both cases. Your patch makes both of them pass. # a---b---c # \ \ # d \ #\ \ # e \ # \ \ # C---l As you say, your patch doesn't try to handle this case, but at least the new behavior seems better. I think we would ideally want the recreated 'l' to have only 'C' as parent in this case. Does that make sense? This is not what I meant, but it is a very interesting corner case. I am not sure I have a solid opinion on what the result should be here. Neither do I, so I'll just drop the test case. Thanks. Here is the corner case I was thinking of. I did not test this to see if this will happen, but I conceived that it might. Suppose you have this tree where # a---b---c # \ # d---g---l #\ / # C where 'C' introduced the same changes as 'c'. When I execute 'git rebase -p l c', I expect that I will end up with this: # a---b---c---d--- # \ \ # ---g---l That is, 'C' gets skipped because it introduces the same changes already seen in 'c'. So 'g' now has two parents: 'd' and 'C^'. But 'C^' is 'd', so 'g' now has two parents, both of whom are 'd'. I think it should collapse to this instead: # a---b---c---d---g---l I think this is actually what you will get. But I think it will only be linearized if the branch that should be dropped is the second parent. I have two tests for this, but I need to simplify them a little to see that that (parent number) is the only difference. I hope this is clear, but please let me know if I made it too confusing. Very clear. Thanks. -- 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 4/6] introduce a commit metapack
On Fri, Feb 1, 2013 at 5:15 PM, Jeff King p...@peff.net wrote: The short-sha1 is a clever idea. Looks like it saves us on the order of 4MB for linux-2.6 (versus the full 20-byte sha1). Not as big as the savings we get from dropping the other 3 sha1's to uint32_t, but still not bad. We could save another 4 bytes per commit by using 3 bytes for storing .idx offsets. linux-2.6 only has 3M objects. It'll take many years for big projects to reach 16M objects and need the fourth byte in uint32_t. I guess the next steps in iterating on this would be: 1. splitting out the refactoring here into separate patches 2. squashing the cleaned-up bits into my patch 4/6 3. deciding whether this should go into a separate file or as part of index v3. Your offsets depend on the .idx file having a sorted sha1 list. That is not likely to change, but it would still be nice to make sure they cannot get out of sync. I'm still curious what the performance impact is for mmap-ing N versus N+8MB. 4. Print some cache statistics in count-objects -v The length of SHA-1 is chosen to be able to unambiguously identify any cached commits. Full SHA-1 check is done after to catch false positives. Just to be clear, these false positives come because the abbreviation is unambiguous within the packfile, but we might be looking for a commit that is not even in our pack, right? It may even be ambiguous within the pack, say an octopus (i.e. not cached) commit that shares the same sha-1 prefix with one of the cached commits. -- 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/RFC 0/6] commit caching
On Fri, Feb 1, 2013 at 1:11 AM, Jeff King p...@peff.net wrote: On Thu, Jan 31, 2013 at 09:14:26AM -0800, Shawn O. Pearce wrote: On Tue, Jan 29, 2013 at 1:14 AM, Jeff King p...@peff.net wrote: Coupled with using compression level 0 for trees (which do not compress well at all, and yield only a 2% increase in size when left uncompressed), my git rev-list --objects --all time drops from ~40s to ~25s. This uhm is nice? But consider reachability bitmaps. ~40s to ~80ms. :-) Yeah, yeah. I'm working my way up to it. :) :-) At this point I'm convinced that my 25s is about the best we will do for reachability analysis with a graph traversal. The repeated hashcmps to see that we've visited each node are starting to dominate. So the next obvious step is to try reachability bitmaps. Yea, its hard to make a big N go fast when you still have a big N... I was hoping to iron out the pack metadata goes here issues with the commit cache stuff, though, as the actual cache implementation is quite simple (whereas the bitmap stuff is more on the complex side, but can build on the same metadata base). Junio and I were talking about putting these in an index v3, below the current tables where he thought there was a hole in v2. I am inclined to agree with his comment elsewhere that we don't want 50 auxiliary files next to a pack in 5 years. But if we go that route I also suggested we append the index below the pack file itself, so its a single file, and that we rename the file to be SHA1(all-bits) not SHA1(sorted-object-list). Both steps make it much safer to perform git gc on Windows while the repository is being accessed. Yup. I have also futzed with the one in JGit for quite a while now. I pull some tricks there like making it a 2 level directory to reduce the need to find a contiguous array of 8M entries when processing the Linux kernel, and I try to preallocate the first level table based on the number of objects in pack-*.idx files. But the bottleneck is basically the cache lookups and hits, these happen like 100M times on 2M objects, because its every link in nearly every tree. Right. I tried some multi-level tricks (and even a radix trie), but I couldn't get anything to beat the simple-and-stupid single hash table with linear probing. O(1) lookup is hard for big N. Lets go shopping^Wcoding instead. If we modified pack-objects' delta compressor for tree objects to only generate delta instructions at tree record boundaries, a delta-encoded tree can be processed without inflating the full content of that tree. Because of the way deltas are created, most tree deltas should have their delta base scanned by the object traversal before the delta is considered. This means the tree delta just needs to consider the much smaller records that are inserted into the base. We know these are different SHA-1s than what was there before, so they are more likely to be new to the lookup_object table. So sort of a magic shortcut tree diff you get while accessing the object. Neat idea. Yes, exactly. So the --objects traversal algorithm can change to get the delta base SHA-1 and raw tree delta from the pack storage. Perform a lookup_object on the base to see if it has been scanned. If it has, just scan the delta insert instructions. If the base has not yet been scanned, inflate the tree to its normal format and scan the entire tree. This would not perform well if we hit the deltas before the bases. In general, though, our use the larger as the base heuristic should mean that our traversal hits the bases first. It won't perform worse than the current code. And its actually the time heuristic that should kick in here for trees. Most trees are roughly the same size, or are only slightly bigger because a new source file was added. More recent trees should appear earlier in the delta window and be suitable candidates for older trees. So we should get a large percentage of trees covered by this trick. This is an approximation of what Nico and I were talking about doing for pack v4. But doesn't require a file format change. :-) Yeah. It just needs to be very careful that the deltas it is looking at all fall on record boundaries, since we might get deltas generated by other versions of git. Can we necessarily identify that case for sure, though? I imagine a tree delta like that would look something like: delete bytes 100-120 add 20 bytes at offset 100: \x12\x34\x56... Of course we can't know without some flag. I assumed it was obvious we would need to tag the pack somehow with extra metadata to say every tree delta in this pack is on a record boundary. That does make delta reuse more complex as a tree delta can only be reused if it is coming from a pack that has the same promise about record boundaries. Otherwise the delta must be regenerated during packing. Without looking at the base object, and without knowing whether the delta was generated by our
Re: [PATCH 0/2] optimizing pack access on read only fetch repos
On Fri, Feb 1, 2013 at 1:14 AM, Jeff King p...@peff.net wrote: On Thu, Jan 31, 2013 at 08:47:37AM -0800, Shawn O. Pearce wrote: - System resource cost we incur by having to keep 50 file descriptors open and maintaining 50 mmap windows will reduce by 50 fold. I wonder how measurable that is (and if it matters on Linux versus less efficient platforms). It does matter. We know it has a negative impact on JGit even on Linux for example. You don't want 300 packs in a repository. 50 might be tolerable. 300 is not. I'd love to see numbers if you have them. It's not that I don't believe it is slower, but knowing _how much_ is important when thinking about what kind of performance increase we are looking to get (which in turn impacts how much effort to put into the repacking). Never done a formal experiment. Just working from memory where 4 years and 3 desks ago I got called because one of our Git servers was struggling to keep up with user git fetch commands. Turns out the repository had O(200) pack files. git gc that normally took only about 5 minutes took a hellva lot longer, like an hour or more. The problem happened because the server was saving every push to a pack and never exploding incoming packs to loose objects. This meant the thin packs from the wire got delta bases appended to them. pack-objects was looking at O(50) different alternatives for most objects when trying to decide which one it should copy into the output pack... for either a fetch/clone client, or the gc I was trying to run to fix the repository. -- 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-send-email: add ~/.authinfo parsing
On Thu, 31 Jan 2013 14:38:45 -0500 Jeff King p...@peff.net wrote:
JK On Thu, Jan 31, 2013 at 10:23:51AM -0500, Ted Zlatanov wrote:
Jeff, is there a way for git-credential to currently support
authinfo/netrc parsing? I assume that's the right way, instead of using
Michal's proposal to parse internally?
I'd like to add that, plus support for the 'string' and string
formats, and authinfo.gpg decoding through GPG. I'd write it in Perl,
if there's a choice.
JK Yes, you could write a credential helper that understands netrc and
JK friends; git talks to the helpers over a socket, so there is no problem
JK with writing it in Perl. See Documentation/technical/api-credentials.txt
JK for an overview, or the sample implementation in credential-store.c for a
JK simple example.
I wrote a Perl credential helper for netrc parsing which is pretty
robust, has built-in docs with -h, and doesn't depend on external
modules. The netrc parser regex was stolen from Net::Netrc.
It will by default use ~/.authinfo.gpg, ~/.netrc.gpg, ~/.authinfo, and
~/.netrc (whichever is found first) and this can be overridden with -f.
If the file name ends with .gpg, it will run gpg --decrypt FILE and
use the output. So non-interactively, that could hang if GPG was
waiting for input. Does Git handle that, or should I check for a TTY?
Take a look at the proposed patch and let me know if it's usable, if you
need a formal copyright assignment, etc.
Thanks
Ted
commit 3d28bc2a610ebcc988eba5443d82d0ded92c24bc
Author: Ted Zlatanov t...@lifelogs.com
Date: Sat Feb 2 06:42:13 2013 -0500
Add contrib/credentials/netrc with GPG support
diff --git a/contrib/credential/netrc/git-credential-netrc b/contrib/credential/netrc/git-credential-netrc
new file mode 100755
index 000..92fc306
--- /dev/null
+++ b/contrib/credential/netrc/git-credential-netrc
@@ -0,0 +1,242 @@
+#!/usr/bin/perl
+
+use strict;
+use warnings;
+
+use Data::Dumper;
+
+use Getopt::Long;
+use File::Basename;
+
+my $VERSION = 0.1;
+
+my %options = (
+ help = 0,
+ debug = 0,
+
+ # identical token maps, e.g. host - host, will be inserted later
+ tmap = {
+port = 'protocol',
+machine = 'host',
+path = 'path',
+login = 'username',
+user = 'username',
+password = 'password',
+ }
+ );
+
+foreach my $v (values %{$options{tmap}})
+{
+ $options{tmap}-{$v} = $v;
+}
+
+foreach my $suffix ('.gpg', '')
+{
+ foreach my $base (qw/authinfo netrc/)
+ {
+ my $file = glob(~/.$base$suffix);
+ next unless (defined $file -f $file);
+ $options{file} = $file ;
+ }
+}
+
+Getopt::Long::Configure(bundling);
+
+# TODO: maybe allow the token map $options{tmap} to be configurable.
+GetOptions(\%options,
+ help|h,
+ debug|d,
+ file|f=s,
+ );
+
+if ($options{help})
+{
+ my $shortname = basename($0);
+ $shortname =~ s/git-credential-//;
+
+ print EOHIPPUS;
+
+$0 [-f AUTHFILE] [-d] get
+
+Version $VERSION by tzz\@lifelogs.com. License: any use is OK.
+
+Options:
+ -f AUTHFILE: specify a netrc-style file
+ -d: turn on debugging
+
+To enable (note that Git will prepend git-credential- to the helper
+name and look for it in the path):
+
+ git config credential.helper '$shortname -f AUTHFILE'
+
+And if you want lots of debugging info:
+
+ git config credential.helper '$shortname -f AUTHFILE -d'
+
+Only get mode is supported by this credential helper. It opens
+AUTHFILE and looks for entries that match the requested search
+criteria:
+
+ 'port|protocol':
+ The protocol that will be used (e.g., https). (protocol=X)
+
+ 'machine|host':
+ The remote hostname for a network credential. (host=X)
+
+ 'path':
+ The path with which the credential will be used. (path=X)
+
+ 'login|user|username':
+ The credential’s username, if we already have one. (username=X)
+
+Thus, when we get protocol=https\nusername=tzz, this credential
+helper will look for lines in AUTHFILE that match
+
+port https login tzz
+
+OR
+
+protocol https login tzz
+
+OR... etc. acceptable tokens as listed above. Any unknown tokens are
+simply ignored.
+
+Then, the helper will print out whatever tokens it got from the line,
+including password tokens, mapping e.g. port back to protocol.
+
+The first matching line is used. Tokens can be quoted as 'STRING' or
+STRING.
+
+No caching is performed by this credential helper.
+
+EOHIPPUS
+
+ exit;
+}
+
+my $mode = shift @ARGV;
+
+# credentials may get 'get', 'store', or 'erase' as parameters but
+# only acknowledge 'get'
+die Syntax: $0 [-f AUTHFILE] [-d] get unless defined $mode;
+
+# only support 'get' mode
+exit unless $mode eq 'get';
+
+my $debug = $options{debug};
+my $file = $options{file};
+
+die Sorry, you need to specify an existing netrc file (with or without a .gpg extension) with -f AUTHFILE
+ unless
Re: [PATCH 4/6] introduce a commit metapack
Jeff King p...@peff.net writes: On Thu, Jan 31, 2013 at 09:03:26AM -0800, Shawn O. Pearce wrote: ... If we are going to change the index to support extension sections and I have to modify JGit to grok this new format, it needs to be index v3 not index v2. If we are making index v3 we should just put index v3 on the end of the pack file. I'm not sure what you mean by your last sentence here. I am not Shawn, but here is a summary of what I think I discussed with him in person, lest I forget. You could imagine that a new pack system (from pack-objects, index-pack down to read_packed_sha1() call) that works with a packfile that * is a single file, whose name is pack-$SHA1.$sfx (where $sfx is something other than 'pack', perhaps); * has the pack data stream, including the concluding checksum of the stream contents at the end, at the beginning of the file; and * has the index v3 data blob appended to the pack data stream. The pack data is streamed over the wire exactly the same way, interoperating with existing software. When receiving, the new index-pack can read such a pack stream and add index at the end. When re-indexing an existing pack (think: upgrading existing packfiles from the current system), the index-pack can read from the packfile and do what it does currently (notably, it knows where the pack stream ends and can stop reading at that point, so even if you feed the new pack to it, it will stop at the end of the pack data, ignoring the index v3 already at the end of the input). One potential advantage of using a single file, instead of the primary .pack file with 3 (or 47) auxiliary files, is that it lets you repack without having to deal with this sequence, which happens currently when you repack: * create a new .pack file and the corresponding auxiliary files under temporary filename; * move existing pack files that describe the same set of objects away; * rename these new files, one at a time, to their final name, making sure that you rename .idx the last, because that happens to be the key to the pack aware programs. Instead you can rename only one thing (the new one) to the final name (possibly atomically replacing the existing one). With the current system, when you need to replace a pack with a new pack with the same packname (e.g. you repack everything with a better pack parameter in a repository that has everything packed into one), there is a very small window other concurrent users will not find the object data between the time when you rename the old ones away and the time when you move the new ones in. The hairly logic between Ok we have prepared all new packfiles and End of pack replacement can be done with a single rename(2) of the new packfile (which contains everything) to the final name, which atomically replaces the old one. This will become even safer if we picked $SHA1 (the name of the packfile) to represent the hash of the whole thing, not the hash of the sorted object names in the pack, as that will let us know there is no need to even replace the files. -- 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] Honor configure's htmldir switch
Honor autoconf's --htmldir switch. This allows relocating HTML docs straight from the configure script. Signed-off-by: Christoph J. Thompson cjsthomp...@gmail.com --- config.mak.in | 1 + 1 file changed, 1 insertion(+) diff --git a/config.mak.in b/config.mak.in index e8a9bb4..d7c49cd 100644 --- a/config.mak.in +++ b/config.mak.in @@ -19,6 +19,7 @@ template_dir = @datadir@/git-core/templates sysconfdir = @sysconfdir@ mandir = @mandir@ +htmldir = @htmldir@ srcdir = @srcdir@ VPATH = @srcdir@ -- 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
Re: [PATCH] Honor configure's htmldir switch
Christoph J. Thompson cjsthomp...@gmail.com writes: Honor autoconf's --htmldir switch. This allows relocating HTML docs straight from the configure script. Signed-off-by: Christoph J. Thompson cjsthomp...@gmail.com --- config.mak.in | 1 + 1 file changed, 1 insertion(+) diff --git a/config.mak.in b/config.mak.in index e8a9bb4..d7c49cd 100644 --- a/config.mak.in +++ b/config.mak.in @@ -19,6 +19,7 @@ template_dir = @datadir@/git-core/templates sysconfdir = @sysconfdir@ mandir = @mandir@ +htmldir = @htmldir@ srcdir = @srcdir@ VPATH = @srcdir@ Hmph, in the output of git grep -e mandir config.mak.in, I see export exec_prefix mandir which makes me wonder if we should either export htmldir as well, or drop mandir from the export. Off-hand, I am not sure which is the right way, but in either case the inconsistency disturbs me. Thanks. -- 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
[RFC/PATCH] config.mak.in: remove unused definitions
When 5566771 (autoconf: Use autoconf to write installation directories to config.mak.autogen, 2006-07-03) introduced support for autoconf generated config.mak file, it added a few export, in addition to definitions of srcdir and VPATH. These export logically does not belong there. The common make variables like mandir, prefix, etc, should be exported to submakes for people who use config.mak and people who use config.mak.autogen the same way, so if we want to get these exported, that should be in the main Makefile, no? We do use mandir and htmldir in Documentation/Makefile, so let's add export for them in the main Makefile instead. We may eventually want to support VPATH, and srcdir may turn out to be useful for that purpose, but right now nobody uses it, so it is useless to define them in this file. Signed-off-by: Junio C Hamano gits...@pobox.com --- * As everybody knows, I do not use autoconf/configure, so this may be breaking things for those who do. Comments, objectsions, and general education etc. are very much appreciated. Makefile | 2 +- config.mak.in | 7 --- 2 files changed, 1 insertion(+), 8 deletions(-) diff --git a/Makefile b/Makefile index 731b6a8..e946402 100644 --- a/Makefile +++ b/Makefile @@ -384,7 +384,7 @@ lib = lib # DESTDIR = pathsep = : -export prefix bindir sharedir sysconfdir gitwebdir localedir +export prefix bindir sharedir mandir htmldir sysconfdir gitwebdir localedir CC = cc AR = ar diff --git a/config.mak.in b/config.mak.in index e8a9bb4..f87c18c 100644 --- a/config.mak.in +++ b/config.mak.in @@ -11,7 +11,6 @@ DIFF = @DIFF@ #INSTALL = @INSTALL@ # needs install-sh or install.sh in sources prefix = @prefix@ -exec_prefix = @exec_prefix@ bindir = @bindir@ gitexecdir = @libexecdir@/git-core datarootdir = @datarootdir@ @@ -19,9 +18,3 @@ template_dir = @datadir@/git-core/templates sysconfdir = @sysconfdir@ mandir = @mandir@ - -srcdir = @srcdir@ -VPATH = @srcdir@ - -export exec_prefix mandir -export srcdir VPATH -- 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] Honor configure's htmldir switch
Christoph Thompson cjsthomp...@gmail.com writes: Will the --htmldir switch still work by exporting mandir and htmldir from the Makefile instead of config.mak.in ? It should not make a difference where you export them from. Lets see... -- cut here -- 8 -- cut here -- $ cat Makefile \EOF # The default target of this Makefile is ... all: var1 = one var2 = two var5 = five var7 = seven var8 = eight include config.mak export var2 var4 var8 all: env | grep '^var' EOF $ cat config.mak \EOF var3 = three var4 = four var6 = six var7 = siete var8 = ocho export var1 var3 var7 EOF $ make env | grep '^var' var1=one var3=three var2=two var4=four var7=siete var8=ocho -- cut here -- 8 -- cut here -- Everything behaves as I expect, I think. -- 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] Honor configure's htmldir switch
Christoph Thompson cjsthomp...@gmail.com writes: [administrivia: why do you keep dropping git@vger from Cc???] I was under the impression that configure passed on the value of it's --htmldir switch by doing some substitution work like the following : sed 's|@htmldir@|$(htmldir)|g' config.mak.in config.mak The information flow goes more like this: * configure.ac is used to generate the configure script with autoconf; * configure script is driven by the user and finds the system characteristics and user's wish; * what configure found out is used to generate config.mak.autogen, using config.mak.in as a template; and then * the primary Makefile reads config.mak.autogen if exists and then config.mak if exists. Note that use of ./configure is entirely optional for the build system of Git. You can give parameters to make on its command line (without having config.mak or config.mak.autogen), or you can give these parameters in handwritten config.mak and just say make. You can also use ./configure to write some reasonable values in config.mak.autogen, but if ./configure guesses things incorrrectly, you can still override them in your handwritten config.mak exactly because it is read after config.mak.autogen is read by Makefile. -- 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: What's cooking in git.git (Feb 2013, #01; Fri, 1)
Junio C Hamano gits...@pobox.com writes: Regarding these two topics * da/mergetool-docs (2013-01-30) 7 commits - doc: generate a list of valid merge tools - mergetool--lib: list user configured tools in '--tool-help' - fixup! doc: generate a list of valid merge tools - fixup! mergetool--lib: add functions for finding available tools - mergetool--lib: add functions for finding available tools - mergetool--lib: improve the help text in guess_merge_tool() - mergetool--lib: simplify command expressions (this branch uses jk/mergetool.) Build on top of the clean-up done by jk/mergetool and automatically generate the list of mergetool and difftool backends the build supports to be included in the documentation. Will merge to 'next', after squashing the fixup! commits from John Keeping. * jk/mergetool (2013-01-28) 8 commits - mergetools: simplify how we handle vim and defaults - mergetool--lib: don't call exit in setup_tool - mergetool--lib: improve show_tool_help() output - mergetools/vim: remove redundant diff command - git-difftool: use git-mergetool--lib for --tool-help - git-mergetool: don't hardcode 'mergetool' in show_tool_help - git-mergetool: remove redundant assignment - git-mergetool: move show_tool_help to mergetool--lib (this branch is used by da/mergetool-docs.) Cleans up mergetool/difftool combo. This is looking ready for 'next'. Do the tips of these two topics look reasonable to both of you, or are there anything you sent but I missed? -- 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] branch: show rebase/bisect info when possible instead of (no branch)
This prints more helpful info when HEAD is detached: is it detached
because of bisect or rebase? What is the original branch name in those
cases?
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
- Incorporate Jonathan's version of checking
- Show original branch name, e.g. (rebasing foo), when possible
builtin/branch.c| 40 +++-
t/t6030-bisect-porcelain.sh | 2 +-
2 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index ea6498b..40f20ad 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -550,6 +550,44 @@ static int calc_maxwidth(struct ref_list *refs)
return w;
}
+static char *get_head_description()
+{
+ struct stat st;
+ struct strbuf sb = STRBUF_INIT;
+ struct strbuf result = STRBUF_INIT;
+ int bisect = 0;
+ int ret;
+ if (!stat(git_path(rebase-merge), st) S_ISDIR(st.st_mode))
+ ret = strbuf_read_file(sb, git_path(rebase-merge/head-name),
0);
+ else if (!access(git_path(rebase-apply/rebasing), F_OK))
+ ret = strbuf_read_file(sb, git_path(rebase-apply/head-name),
0);
+ else if (!access(git_path(BISECT_LOG), F_OK)) {
+ ret = strbuf_read_file(sb, git_path(BISECT_START), 0);
+ bisect = 1;
+ } else
+ return xstrdup(_((no branch)));
+
+ if (ret = 0)
+ return xstrdup(bisect ? _((bisecting)) : _(_(rebasing)));
+
+ while (sb.len sb.buf[sb.len - 1] == '\n')
+ strbuf_setlen(sb, sb.len - 1);
+
+ if (bisect) {
+ unsigned char sha1[20];
+ if (!get_sha1_hex(sb.buf, sha1))
+ strbuf_addstr(result, _((bisecting)));
+ else
+ strbuf_addf(result, _((bisecting %s)), sb.buf);
+ } else {
+ if (!prefixcmp(sb.buf, refs/heads/))
+ strbuf_addf(result, _((rebasing %s)), sb.buf + 11);
+ else
+ strbuf_addstr(result, _((rebasing)));
+ }
+ strbuf_release(sb);
+ return strbuf_detach(result, NULL);
+}
static void show_detached(struct ref_list *ref_list)
{
@@ -557,7 +595,7 @@ static void show_detached(struct ref_list *ref_list)
if (head_commit is_descendant_of(head_commit,
ref_list-with_commit)) {
struct ref_item item;
- item.name = xstrdup(_((no branch)));
+ item.name = get_head_description();
item.width = utf8_strwidth(item.name);
item.kind = REF_LOCAL_BRANCH;
item.dest = NULL;
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 3e0e15f..90968d5 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -164,7 +164,7 @@ test_expect_success 'bisect start: existing
.git/BISECT_START not modified if
cp .git/BISECT_START saved
test_must_fail git bisect start $HASH4 foo --
git branch branch.output
- test_i18ngrep * (no branch) branch.output /dev/null
+ test_i18ngrep * (bisecting other) branch.output /dev/null
test_cmp saved .git/BISECT_START
'
test_expect_success 'bisect start: no .git/BISECT_START if mistaken rev' '
--
1.8.1.1.459.g5970e58
--
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 v3] status: show the branch name if possible in in-progress info
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- - avoid hardcoding SHA-1 in t7512 - I did not act on Junio's --format=%s idea because frankly I don't care much about the on 'xxx' part. It was Matthieu's idea and he did not make any comments on --format=%s t/t7512-status-help.sh | 87 +++--- wt-status.c| 94 ++ wt-status.h| 2 ++ 3 files changed, 142 insertions(+), 41 deletions(-) diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh index b3f6eb9..51ab894 100755 --- a/t/t7512-status-help.sh +++ b/t/t7512-status-help.sh @@ -73,10 +73,11 @@ test_expect_success 'prepare for rebase conflicts' ' test_expect_success 'status when rebase in progress before resolving conflicts' ' test_when_finished git rebase --abort + ONTO=$(git rev-parse --short HEAD^^) test_must_fail git rebase HEAD^ --onto HEAD^^ - cat expected -\EOF + cat expected -EOF # Not currently on any branch. - # You are currently rebasing. + # You are currently rebasing branch '\''rebase_conflicts'\'' on '\''$ONTO'\''. # (fix conflicts and then run git rebase --continue) # (use git rebase --skip to skip this patch) # (use git rebase --abort to check out the original branch) @@ -97,12 +98,13 @@ test_expect_success 'status when rebase in progress before resolving conflicts' test_expect_success 'status when rebase in progress before rebase --continue' ' git reset --hard rebase_conflicts test_when_finished git rebase --abort + ONTO=$(git rev-parse --short HEAD^^) test_must_fail git rebase HEAD^ --onto HEAD^^ echo three main.txt git add main.txt - cat expected -\EOF + cat expected -EOF # Not currently on any branch. - # You are currently rebasing. + # You are currently rebasing branch '\''rebase_conflicts'\'' on '\''$ONTO'\''. # (all conflicts fixed: run git rebase --continue) # # Changes to be committed: @@ -130,10 +132,11 @@ test_expect_success 'prepare for rebase_i_conflicts' ' test_expect_success 'status during rebase -i when conflicts unresolved' ' test_when_finished git rebase --abort + ONTO=$(git rev-parse --short rebase_i_conflicts) test_must_fail git rebase -i rebase_i_conflicts - cat expected -\EOF + cat expected -EOF # Not currently on any branch. - # You are currently rebasing. + # You are currently rebasing branch '\''rebase_i_conflicts_second'\'' on '\''$ONTO'\''. # (fix conflicts and then run git rebase --continue) # (use git rebase --skip to skip this patch) # (use git rebase --abort to check out the original branch) @@ -154,11 +157,12 @@ test_expect_success 'status during rebase -i when conflicts unresolved' ' test_expect_success 'status during rebase -i after resolving conflicts' ' git reset --hard rebase_i_conflicts_second test_when_finished git rebase --abort + ONTO=$(git rev-parse --short rebase_i_conflicts) test_must_fail git rebase -i rebase_i_conflicts git add main.txt - cat expected -\EOF + cat expected -EOF # Not currently on any branch. - # You are currently rebasing. + # You are currently rebasing branch '\''rebase_i_conflicts_second'\'' on '\''$ONTO'\''. # (all conflicts fixed: run git rebase --continue) # # Changes to be committed: @@ -182,10 +186,11 @@ test_expect_success 'status when rebasing -i in edit mode' ' FAKE_LINES=1 edit 2 export FAKE_LINES test_when_finished git rebase --abort + ONTO=$(git rev-parse --short HEAD~2) git rebase -i HEAD~2 - cat expected -\EOF + cat expected -EOF # Not currently on any branch. - # You are currently editing a commit during a rebase. + # You are currently editing a commit while rebasing branch '\''rebase_i_edit'\'' on '\''$ONTO'\''. # (use git commit --amend to amend the current commit) # (use git rebase --continue once you are satisfied with your changes) # @@ -206,11 +211,12 @@ test_expect_success 'status when splitting a commit' ' FAKE_LINES=1 edit 2 3 export FAKE_LINES test_when_finished git rebase --abort + ONTO=$(git rev-parse --short HEAD~3) git rebase -i HEAD~3 git reset HEAD^ - cat expected -\EOF + cat expected -EOF # Not currently on any branch. - # You are currently splitting a commit during a rebase. + # You are currently splitting a commit while rebasing branch '\''split_commit'\'' on '\''$ONTO'\''. # (Once your working directory is clean, run git rebase --continue) # # Changes not staged for commit: @@ -236,11 +242,12
Re: Getting started contributing.
adamfraser adamfras...@gmail.com writes: I would like to start contributing to git and am looking for a small project idea to get started with. On the Small Project Ideas wiki https://git.wiki.kernel.org/index.php/SmallProjectsIdeas site there is a suggestion for adding a 'git rebase --status' command that sounds like it would be good for someone who has little knowledge of the code base. I think the two patches Duy just posted tonight overlap with that topic, and I suspect it would give the end users a better experience to put the information in git status output rather than a separate git rebase subcommand. Perhaps you can work with him to see what other things his patch may have missed can be improved? -- 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: Getting started contributing.
adamfraser adamfras...@gmail.com writes: I've done a little searching and haven't been able to find an official bug tracker for git is there somewhere I can find some bugs to help fix? You came to the right place. A new bug or regression is reported to this list, and it often is fixed (or often diagnosed as pebcak) fairly quickly by list regulars. Nobody maintains a bugzilla that is not maintained and is full of stale/invalid bug reports. The best contribution a new person can make is to use the software regularly and find issues. It is very hard to find real bugs that can easily be fixed by somebody totally new to the codebase in Git these days. On the other hand, there probably still are many loose ends. When a command is supposed to take only two arguments because taking more than three does not make any sense, for example, it has not been unusual for us to document the two-argument form of the command, reject if the user gives only one argument with an error message, but we simply ignore the third argument if the user mistakenly runs the command with three arguments, instead of erroring out (i.e. the code does not bother to help insane or too inexperienced users). That kind of things are hard to find by users experienced with Git exactly because they know running such a command with three or more arguments is nonsense, and they do not even try to make such a mistake. Still, it would be very nice to find and fix such issues. Thanks. -- 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
