Linus Torvalds writes:
> So it would probably be a great idea to make the filtering code able
> to do things in smaller chunks, but I suspect that the patch to chunk
> up xread/xwrite is the right thing to do anyway.
Yes and yes, but the first yes is a bit tricky for writing things
out, as the r
Jeff King writes:
> On Mon, Aug 26, 2013 at 04:59:01PM -0400, Jeff King wrote:
>
>> Hmm. I wonder if fgetc is a macro in uclibc? Just grepping their
>> stdio.h, it looks like that is a possibility.
>>
>> I think they are probably wrong to do so (but I'd have to check the
>> standard). However, t
wor...@alum.mit.edu (Dale R. Worley) writes:
> I've noticed that Git by default puts long output through "less" as a
> pager. I don't like that, but this is not the time to change
> established behavior. But while tracking that down, I noticed that
> the paging behavior is controlled by at least
Signed-off-by: Nicolas Pitre
---
packv4-create.c | 137
1 file changed, 137 insertions(+)
create mode 100644 packv4-create.c
diff --git a/packv4-create.c b/packv4-create.c
new file mode 100644
index 000..2de6d41
--- /dev/null
+++ b/pa
The SHA1 of the base object is retrieved and the corresponding object
is loaded in memory for conv_to_dict_tree() to look at. Simple but
effective. Obviously this relies on the delta matching already performed
during the pack v3 delta search. Some native delta search for pack v4
could be investi
Augment dict entries with a 16-bit prefix in order to store the file
mode value of tree entries.
Signed-off-by: Nicolas Pitre
---
packv4-create.c | 56
1 file changed, 36 insertions(+), 20 deletions(-)
diff --git a/packv4-create.c b/packv
Let's actually open the destination pack file and write the header and
the tables.
The header isn't much different from pack v3, except for the pack version
number of course.
The first table is the sorted SHA1 table normally found in the pack index
file. With pack v4 we write this table in the m
A bit crud but good enough for now.
Signed-off-by: Nicolas Pitre
---
cache.h | 1 +
sha1_file.c | 58 +++---
2 files changed, 52 insertions(+), 7 deletions(-)
diff --git a/cache.h b/cache.h
index b6634c4..63066a1 100644
--- a/cache.h
+++
Let's create another dictionary table to hold the author and committer
entries. We use the same table format used for tree entries where the
16 bit data prefix is conveniently used to store the timezone value.
In order to copy straight from a commit object buffer, dict_add_entry()
is modified to
Add variable length number encoding. Let's apply the same encoding
currently used for the offset to base of OBJ_OFS_DELTA objects which
is the most efficient way to do this, and apply it to everything with
pack version 4.
Also add SHA1 reference encoding. This one is either an index into a
SHA1
Signed-off-by: Nicolas Pitre
---
packv4-create.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/packv4-create.c b/packv4-create.c
index 6801e21..22e14da 100644
--- a/packv4-create.c
+++ b/packv4-create.c
@@ -13,6 +13,7 @@
#include "tree-walk.h"
#include "pack.h"
#include "pack
This is a minor change over pack index v2. Since pack v4 already contains
the sorted SHA1 table, it is therefore ommitted from the index file.
Signed-off-by: Nicolas Pitre
---
pack-write.c| 6 +-
packv4-create.c | 10 +-
2 files changed, 14 insertions(+), 2 deletions(-)
diff -
This goes as follows:
- Tree reference: either variable length encoding of the index
into the SHA1 table or the literal SHA1 prefixed by 0 (see
add_sha1_ref()).
- Parent count: variable length encoding of the number of parents.
This is normally going to occupy a single byte but doesn't have
Signed-off-by: Nicolas Pitre
---
packv4-create.c | 73 +++--
1 file changed, 34 insertions(+), 39 deletions(-)
diff --git a/packv4-create.c b/packv4-create.c
index bb171c5..6801e21 100644
--- a/packv4-create.c
+++ b/packv4-create.c
@@ -949,56 +
At least commit af25e94d4dcfb9608846242fabdd4e6014e5c9f0 in the Linux
kernel repository has "author <> 1120285620 -0700"
Signed-off-by: Nicolas Pitre
---
packv4-create.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/packv4-create.c b/packv4-create.c
index 2d46d11..63
In pack v4 the object size and type is encoded differently from pack v3.
The object size uses the same efficient variable length number encoding
already used elsewhere.
The object type has 4 bits allocated to it compared to 3 bits in pack v3.
This should be quite sufficient for the foreseeable fut
This adds the missing code to finally be able to produce a complete
pack file version 4. We trap commit and tree objects as those have
a completely new encoding. Other object types are copied almost
unchanged.
As we go the pack index entries are updated in place to store the new
object offsets
Signed-off-by: Nicolas Pitre
---
packv4-create.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/packv4-create.c b/packv4-create.c
index ed67eb6..2d46d11 100644
--- a/packv4-create.c
+++ b/packv4-create.c
@@ -15,6 +15,7 @@
#include "pack-revindex.h"
+static int pack_
Here's the code to dump a table into a pack. Table entries are written
according to the current sort order. This is important as objects use
this order to index into the table.
Signed-off-by: Nicolas Pitre
---
packv4-create.c | 49 +
1 file change
Blob and tag objects have no particular changes except for their object
header.
Delta objects are also copied as is, except for their delta base reference
which is converted to the new way as used elsewhere in pack v4 encoding
i.e. an index into the SHA1 table or a literal SHA1 prefixed by 0 if no
Let's create a struct pack_idx_entry list with sorted sha1 which will
be useful later. The offset sorted list is now a separate indirect
list.
Signed-off-by: Nicolas Pitre
---
packv4-create.c | 72 +
1 file changed, 42 insertions(+), 30 de
In order to be able to quickly walk tree objects, let's encode their
"delta" as a range of entries into another tree object.
The encoding allows for the base object to change so multiple base
objects can be borrowed from. The code doesn't try to exploit this
possibility at the moment though.
The
Signed-off-by: Nicolas Pitre
---
cache.h | 1 +
sha1_file.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index 85b544f..b6634c4 100644
--- a/cache.h
+++ b/cache.h
@@ -1160,6 +1160,7 @@ struct object_info {
} u;
};
extern int sha1_object_
This goes as follows:
- Number of tree entries: variable length encoded.
Then for each tree entry:
- Path component reference: variable length encoded index into the path
string dictionary table which also covers the entry mode. To make the
overall encoding efficient, the author table is al
From: Nicolas Pitre
Let's read a pack to feed our dictionary with all the path strings
contained in all the tree objects.
Dump the resulting dictionary sorted by frequency to stdout.
Signed-off-by: Nicolas Pitre
---
Makefile| 1 +
packv4-create.c | 137 ++
Subject says it all... at last !
This can also be fetched here:
git://git.linaro.org/people/nico/git
Demonstration of what it does at the moment:
http://article.gmane.org/gmane.comp.version-control.git/233038
I'd like to preserve the author time stamps as they relate to where i
Signed-off-by: Nicolas Pitre
---
packv4-create.c | 58 +++--
1 file changed, 44 insertions(+), 14 deletions(-)
diff --git a/packv4-create.c b/packv4-create.c
index 5c08871..20d97a4 100644
--- a/packv4-create.c
+++ b/packv4-create.c
@@ -261,7 +2
Junio C Hamano writes:
> Not necessarily. If the user is asking the question in a more
> natural way (I want to see where in 'next' branch's tip commit hits
> appear, by the way, I know I am only interested in builtin/ so I'd
> give pathspec as well when I am asking this question), the output
>
On Tue, 27 Aug 2013, Duy Nguyen wrote:
> On Tue, Aug 27, 2013 at 7:06 AM, Nicolas Pitre wrote:
> > Yes, after being vaporware for many many years (I don't even remember
> > when I started making references to a possible pack format version 4 --
> > certainly more than 6 years ago) I finally compl
Antoine Pelisse writes:
> I've tried to use the netrc credential with git-send-email
> (v1.8.4-rc2), and I've had the following log (running with -d -v):
Peff what do you think? From credential layer's point of view, I
think we make it totally up to the helper to decide if a request
matches wha
Jeff King writes:
> I'd be very surprised if this works in practice on most of our current
> test scripts. There are often subtle dependencies on the state left over
> from previous tests. Running the script below up through t3800 (at which
> point I lost patience) reveals 37 test scripts that ar
Nicolas Pitre writes:
> On Fri, 23 Aug 2013, Junio C Hamano wrote:
>
>> The latest feature release Git v1.8.4 is now available at the usual
>> places. It contains 870+ changes from ~100 contributors (among
>> which 33 people are new) since v1.8.3.
>>
>> We will have two more releases til the en
Jeff King writes:
> On Mon, Aug 26, 2013 at 03:28:26PM -0400, Jeff King wrote:
>
>> Changing the object_array API would be hard, but I don't think we need
>> to do it here. Can we simply stop using object_array to pass the list,
>> and instead just have a custom list?
>>
>> I'll see how painful
> Do you have an updated patch? Want to take some time to clean up and
> resubmit the entire series? The batching should be incorporated with
> the last 2/2 that I sent out.
I don't have other update.
I'm satisfied because able to want to do and it became better than my
original modification tha
On Mon, Aug 26, 2013 at 05:57:18PM -0400, Jeff King wrote:
> On Mon, Aug 26, 2013 at 04:59:01PM -0400, Jeff King wrote:
>
> > Hmm. I wonder if fgetc is a macro in uclibc? Just grepping their
> > stdio.h, it looks like that is a possibility.
> >
> > I think they are probably wrong to do so (but I'
On Tue, Aug 27, 2013 at 7:06 AM, Nicolas Pitre wrote:
> Yes, after being vaporware for many many years (I don't even remember
> when I started making references to a possible pack format version 4 --
> certainly more than 6 years ago) I finally completed the code to produce
> a new pack format I'm
On Fri, 23 Aug 2013, Junio C Hamano wrote:
> The latest feature release Git v1.8.4 is now available at the usual
> places. It contains 870+ changes from ~100 contributors (among
> which 33 people are new) since v1.8.3.
>
> We will have two more releases til the end of this year; the release
> af
On Mon, Aug 26, 2013 at 02:34:18PM +0200, Erik Bernoth wrote:
> Now there's a lot of information (all the stat(2) stuff) that gets
> stored about the staged files, which I never needed for file-IO in
> Python or Java. In my eyes if a person would be cloning my git
> repository he wouldn't need it
On Mon, Aug 26, 2013 at 04:59:01PM -0400, Jeff King wrote:
> Hmm. I wonder if fgetc is a macro in uclibc? Just grepping their
> stdio.h, it looks like that is a possibility.
>
> I think they are probably wrong to do so (but I'd have to check the
> standard). However, the cleaner workaround would
On Sun, Aug 25, 2013 at 10:27:52PM -0700, Junio C Hamano wrote:
> > I'm on the fence. It doesn't actually save that many lines of code, and
> > I guess it's possible that somebody would want a custom mailmap in the
> > future. Even though you can't do it right now, all it would take is
> > exposin
On Mon, Aug 26, 2013 at 09:02:46AM -0700, Junio C Hamano wrote:
> > There's one subtle thing I didn't mention in the "it is already on stack
> > overflow". If you have a version of git which complains about the null
> > sha1, then the SO advice is already broken. But if the SO works, then
> > you
On Mon, Aug 26, 2013 at 10:35:01AM -0700, Jonathan Nieder wrote:
> > I don't see that splitting it up more hurts this. If we wanted more
> > automatic rearranging or skipping of tests, we would need tests to
> > declare dependencies on their setup. And we would need to be able to
> > declare depen
Hello all,
As of 1.8.0, the compdefs I set up for my shell aliases (in zsh 5.0)
worked. They can be found here:
https://github.com/gfontenot/dotfiles/blob/master/git/completion.zsh
However, once updating to 1.8.3, they broke, complaining that zsh
couldn't find the command __git-checkout_main (for
On Mon, Aug 26, 2013 at 05:03:04PM -0400, Phil Hord wrote:
> > $ git grep -l foo HEAD | head -1
> > HEAD:RelNotes/1.5.1.5.txt
> >
> > we still limit to the current directory, but the output does not note
> > this (it should be "HEAD:./RelNotes/1.5.1.5.txt"). I think this bug is
> > orthogonal
Lukas Fleischer writes:
> On Mon, Aug 26, 2013 at 02:29:12PM -0600, Lance wrote:
>> [...]
>> >> CC config.o
>> >>config.c: In function 'get_next_char':
>> >>config.c:220:14: error: expected identifier before '(' token
>> >>config.c:220:14: error: expected statement before ')' token
>> >>confi
On Mon, Aug 26, 2013 at 4:52 PM, Jeff King wrote:
> On Mon, Aug 26, 2013 at 10:13:14PM +0200, Johannes Sixt wrote:
>
>> Am 26.08.2013 21:56, schrieb Jeff King:
>> > Also, prevent the delimiter being added twice, as happens now in these
>> > examples:
>> >
>> > git grep -l foo HEAD:
>> > HEAD::
On Mon, Aug 26, 2013 at 10:31:54PM +0200, Lukas Fleischer wrote:
> > I also had to change line 224 to the following
> >
> > c = (cf->fgetc)(cf);
> >
> > Once both places were changes, it compiled successfully.
>
> Sounds like a parser bug to me. Should we patch this in Git in or
On Mon, Aug 26, 2013 at 10:13:14PM +0200, Johannes Sixt wrote:
> Am 26.08.2013 21:56, schrieb Jeff King:
> > Also, prevent the delimiter being added twice, as happens now in these
> > examples:
> >
> > git grep -l foo HEAD:
> > HEAD::some/path/to/foo.txt
> >^
>
> Which one of these t
On Mon, Aug 26, 2013 at 4:13 PM, Johannes Sixt wrote:
> Am 26.08.2013 21:56, schrieb Jeff King:
>> Also, prevent the delimiter being added twice, as happens now in these
>> examples:
>>
>> git grep -l foo HEAD:
>> HEAD::some/path/to/foo.txt
>>^
>
> Which one of these two does it print
On Mon, Aug 26, 2013 at 02:29:12PM -0600, Lance wrote:
> [...]
> >> CC config.o
> >>config.c: In function 'get_next_char':
> >>config.c:220:14: error: expected identifier before '(' token
> >>config.c:220:14: error: expected statement before ')' token
> >>config.c:220:14: error: expected statem
On 8/26/2013 2:18 PM, Lukas Fleischer wrote:
On Mon, Aug 26, 2013 at 02:10:43PM -0600, Lance wrote:
Up until the latest release, I've been able to compile git for a
uclibc based embedded linux. The toolchain I use is from "entware",
which is based off of the openwrt toolchain.
https://code.goog
On Mon, Aug 26, 2013 at 02:10:43PM -0600, Lance wrote:
> Up until the latest release, I've been able to compile git for a
> uclibc based embedded linux. The toolchain I use is from "entware",
> which is based off of the openwrt toolchain.
> https://code.google.com/p/wl500g-repo/
>
> Somewhere betw
Am 26.08.2013 21:56, schrieb Jeff King:
> Also, prevent the delimiter being added twice, as happens now in these
> examples:
>
> git grep -l foo HEAD:
> HEAD::some/path/to/foo.txt
>^
Which one of these two does it print then?
HEAD:/some/path/to/foo.txt
HEAD:some/path/to/foo.t
Up until the latest release, I've been able to compile git for a uclibc
based embedded linux. The toolchain I use is from "entware", which is
based off of the openwrt toolchain.
https://code.google.com/p/wl500g-repo/
Somewhere between git 1.8.3.4 & 1.8.4 there seems to be some changes
that bre
Am 26.08.2013 10:26, schrieb Chris Packham:
> Hi Brian,
>
> Sorry for the delay.
Same here.
> On 20/08/13 12:26, brian m. carlson wrote:
>> When git submodule summary is run and there is a deleted submodule, there is
>> an
>> warning from git rev-parse:
>>
>> fatal: Not a git repository: '.vi
I've noticed that Git by default puts long output through "less" as a
pager. I don't like that, but this is not the time to change
established behavior. But while tracking that down, I noticed that
the paging behavior is controlled by at least 5 things:
the -p/--paginate/--no-pager options
the G
From: Phil Hord
When a commit is grepped and matching filenames are printed, grep-objects
creates the filename by prefixing the original cmdline argument to the
matched path separated by a colon. Normally this forms a valid blob
reference to the filename, like this:
git grep -l foo HEAD
HEA
We use an object_array to store the set of objects to grep
that we received on the command-line. There is no particular
reason to use object_array here except that its code was
already written, and it contained the elements we needed
(though we did not care about mode at all).
However, future patc
On Mon, Aug 26, 2013 at 03:28:26PM -0400, Jeff King wrote:
> Changing the object_array API would be hard, but I don't think we need
> to do it here. Can we simply stop using object_array to pass the list,
> and instead just have a custom list?
>
> I'll see how painful that is.
Not very, I think.
On Mon, Aug 26, 2013 at 10:46:12AM -0400, Phil Hord wrote:
> This version is a bit more deterministic and also adds a test.
>
> It accepts the expense of examining the path argument again to
> determine if it is a tree-ish + path rather than just a tree (commit).
> The get_sha1 call occurs one e
On Mon, Aug 26, 2013 at 10:42 AM, Jonathan Nieder wrote:
> Bruce Korb wrote:
>
>> $ git svn --version
>> git-svn version 1.8.1.4 (svn 1.7.11)
>
> Hm. Two ideas:
>
> * Does 1.8.2 or newer work better? (It contains v1.8.2-rc0~110^2,
>"git-svn: do not escape certain characters in paths", 2013-
On Mon, Aug 26, 2013 at 1:26 PM, Junio C Hamano wrote:
> Phil Hord writes:
>
>>> If your justification were "above says 'there may be a readon why
>>> the user wanted to ask it in that way', i.e. 'find in this tree
>>> object HEAD:some/path and report where hits appear', but the reason
>>> can on
Bruce Korb wrote:
> $ git svn --version
> git-svn version 1.8.1.4 (svn 1.7.11)
Hm. Two ideas:
* Does 1.8.2 or newer work better? (It contains v1.8.2-rc0~110^2,
"git-svn: do not escape certain characters in paths", 2013-01-17,
which at first glance looks unlikely to help but might be wor
Jeff King wrote:
> On Sun, Aug 25, 2013 at 12:54:12PM -0700, Jonathan Nieder wrote:
>> [setup split across three tests]
>>
>> This is kind of an old-fashioned test, since each step of the setup is
>> treated as a separate test assertion. I don't really mind until we
>> get better automation to ma
Hi,
On Mon, Aug 26, 2013 at 10:28 AM, Jonathan Nieder wrote:
> Bruce Korb wrote:
>> I was trying to clone a SVN repo, but not having luck:
>>
>>> $ git svn clone $PWD/private-lustre-svn $PWD/private-lustre-git
>>> perl: subversion/libsvn_subr/dirent_uri.c:321: canonicalize: Assertion
>>> `*src !
Hi,
Bruce Korb wrote:
> I was trying to clone a SVN repo, but not having luck:
>
>> $ git svn clone $PWD/private-lustre-svn $PWD/private-lustre-git
>> perl: subversion/libsvn_subr/dirent_uri.c:321: canonicalize: Assertion `*src
>> != '/'' failed.
>> error: git-svn died of signal 6
>
> What is Pe
Phil Hord writes:
>> If your justification were "above says 'there may be a readon why
>> the user wanted to ask it in that way', i.e. 'find in this tree
>> object HEAD:some/path and report where hits appear', but the reason
>> can only be from laziness and/or broken script and the user always
>>
On Mon, Aug 26, 2013 at 1:03 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> If your justification were "above says 'there may be a readon why
>> the user wanted to ask it in that way', i.e. 'find in this tree
>> object HEAD:some/path and report where hits appear', but the reason
>> can o
I was trying to clone a SVN repo, but not having luck:
> $ git svn clone $PWD/private-lustre-svn $PWD/private-lustre-git
> perl: subversion/libsvn_subr/dirent_uri.c:321: canonicalize: Assertion `*src
!= '/'' failed.
> error: git-svn died of signal 6
What is Perl or Subversion or GIT trying to t
On Mon, Aug 26, 2013 at 12:49 PM, Phil Hord wrote:
> If so, then I would like to point out to you the convenience I
> accidentally encountered using this tool. Perhaps you didn't realize
> how helpful it was when you chose to use a colon there.
My itch comes from a case where I am looking for re
Junio C Hamano writes:
> If your justification were "above says 'there may be a readon why
> the user wanted to ask it in that way', i.e. 'find in this tree
> object HEAD:some/path and report where hits appear', but the reason
> can only be from laziness and/or broken script and the user always
>
Consider [anything]-by: a valid signature.
This includes Tested-by: Acked-by: Reviewed-by: etc.
Signed-off-by: Michael S. Tsirkin
---
git-send-email.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index ecbf56f..bb9093b 100755
--
On Mon, Aug 26, 2013 at 12:23 PM, Junio C Hamano wrote:
> Phil Hord writes:
>
>> On Mon, Aug 26, 2013 at 3:14 AM, Junio C Hamano wrote:
>>> Junio C Hamano writes:
>>>
Jonathan Nieder writes:
> I think Phil meant that when "git grep" is asked to search within
> "HEAD:some/path
On Mon, Aug 26, 2013 at 4:16 AM, Matthieu Moy
wrote:
> Matthieu Moy writes:
>
>> Junio C Hamano writes:
>>
>>> Matthieu Moy writes:
>>>
How would I do that? The update to the remote namespace is done by Git,
not by the remote-helper.
OK, I'm now convinced that my solution is
Matthieu Moy writes:
> Not updating was the default until 664059fb62 (i.e. until 1.8.4), so the
> default already changed once. I tend to agree with Felipe that doing the
> update by default makes sense.
OK. Thanks.
> git-remote-mediawiki is kind of a special case, as the remote side uses
> a
Phil Hord writes:
> On Mon, Aug 26, 2013 at 3:14 AM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>>> Jonathan Nieder writes:
>>>
I think Phil meant that when "git grep" is asked to search within
"HEAD:some/path", filenames tacked on at the end should be appended
with a '/
Jiang Xin writes:
> 2013/8/26 Jeremy Rosen :
>>
>> nitpicking, but shouldn't this be worded as "up to date" rather than
>> "identical" ?
>>
>> The reason is that identical gives the idea that the two branch happen to be
>> on the same
>> commit wheras "up to date" gives the idea that there is a
Jeff King writes:
>> I found this version more readable than Peff's (albeit slightly).
>
> OK. Do you want to apply with Jonathan's wording, then?
I can do that, as it seems all of us are in agreement.
> There's one subtle thing I didn't mention in the "it is already on stack
> overflow". If yo
When a commit is grepped and matching filenames are printed, grep-objects
creates the filename by prefixing the original cmdline argument to the
matched path separated by a colon. Normally this forms a valid blob
reference to the filename, like this:
git grep -l foo HEAD
HEAD:some/path/to/foo
On Sun, Aug 25, 2013 at 11:03:54PM -0700, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
> > In other words, why not use something like this?
> >
> > write_index: optionally allow broken null sha1s
> >
> > Commit 4337b58 (do not write null sha1s to on-disk index, 2012-07-28)
> > a
On Sun, Aug 25, 2013 at 12:54:12PM -0700, Jonathan Nieder wrote:
> [setup split across three tests]
>
> This is kind of an old-fashioned test, since each step of the setup is
> treated as a separate test assertion. I don't really mind until we
> get better automation to make it easy to skip or re
On Sun, Aug 25, 2013 at 11:50:01AM -0400, Pete Wyckoff wrote:
> Modern git, including your version, do "streaming" reads from p4,
> so the git-p4 python process never even holds a whole file's
> worth of data. You're seeing git-fast-import die, it seems. It
> will hold onto the entire file conten
> Thomas Ackermann writes:
>
> > Sorry Jon, but this might not be of any help to new Git users ;)
> >
> > Signed-off-by: Thomas Ackermann
>
> Yeah, I think this is long overdue. The drawing was taken from an
> e-mail posted in a discussion, and the credit should have been given
> in the commit
Hi,
I am still working on implementing git in Python for self education
purposes. Implementing the Index in memory was no problem after I
understood how its done with help of Andreas Ericsson and Junio C
Hamano.
Now I want to store an Index state to the filesystem in a
git-compatible file format.
On Mon, Aug 26, 2013 at 3:14 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Jonathan Nieder writes:
>>
>>> I think Phil meant that when "git grep" is asked to search within
>>> "HEAD:some/path", filenames tacked on at the end should be appended
>>> with a '/' separator instead of the us
The current documentation mentions the private ref namespace, but does
not really explain why it can be useful.
Signed-off-by: Matthieu Moy
---
This small patch was sent inline during a previous conversation, but
did not really catch attention ;-).
Resending as a proper patch.
Documentation/gi
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> Matthieu Moy writes:
>>
>>> How would I do that? The update to the remote namespace is done by Git,
>>> not by the remote-helper.
>>>
>>> OK, I'm now convinced that my solution is the right one. The
>>> alternatives are far more complex and I s
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> How would I do that? The update to the remote namespace is done by Git,
>> not by the remote-helper.
>>
>> OK, I'm now convinced that my solution is the right one. The
>> alternatives are far more complex and I still fail to see the benefits.
>
Hi Brian,
Sorry for the delay.
On 20/08/13 12:26, brian m. carlson wrote:
> When git submodule summary is run and there is a deleted submodule, there is
> an
> warning from git rev-parse:
>
> fatal: Not a git repository: '.vim/pathogen/.git'
>
> Silence this warning, since it is fully expect
2013/8/26 Jeremy Rosen :
>
> nitpicking, but shouldn't this be worded as "up to date" rather than
> "identical" ?
>
> The reason is that identical gives the idea that the two branch happen to be
> on the same
> commit wheras "up to date" gives the idea that there is a special
> relationship betw
>
> But this will not work if there is no change between the current
> branch and its upstream. Always report upstream tracking info
> even if there is no difference, so that "git status" is consistent
> for checking tracking info for current branch. E.g.
>
> $ git status
> # On branch fe
Jiang Xin writes:
> Changes since v7:
>
> * Squashed patch 1/3 and patch 2/3 into one big patch.
>
> But not s/gone/absent/ as Matthieu suggested.
Thanks. Will requeue.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More ma
From: Johannes Sixt
> Am 25.08.2013 21:44, schrieb Christian Couder:
>> What about:
>>
>> die("Objects must be of the same type.\n"
>> "'%s' points to a replaced object of type '%s'\n"
>> "while '%s' points to a replacement object of type '%
Eric Sunshine writes:
> ... when 'next' is ready to be rewound after 1.8.4
> is released, a replacement to the original series should be sent with
> all the incremental patches squashed in.
It was more like "could, if you want to help us keep clean history
going forward", rather than "should" ;-
Junio C Hamano writes:
> Jonathan Nieder writes:
>
>> I think Phil meant that when "git grep" is asked to search within
>> "HEAD:some/path", filenames tacked on at the end should be appended
>> with a '/' separator instead of the usual ':' (e.g.,
>> "HEAD:some/path/inner/path.c", not "HEAD:some/
Changes since v7:
* Squashed patch 1/3 and patch 2/3 into one big patch.
But not s/gone/absent/ as Matthieu suggested.
Jiang Xin (2):
branch: report invalid tracking branch as gone
status: always show tracking branch even no change
builtin/branch.c | 36
remote
In order to see what the current branch is tracking, one way is using
"git branch -v -v", but branches other than the current are also
reported. Another way is using "git status", such as:
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
...
B
Command "git branch -vv" will report tracking branches, but invalid
tracking branches are also reported. This is because the function
stat_tracking_info() can not distinguish invalid tracking branch
from other cases which it would not like to report, such as
there is no upstream settings at all, or
98 matches
Mail list logo
