On 05/21/2015 05:20 AM, Junio C Hamano wrote:
Karthik Nayak writes:
convert 'for-each-ref' to use the common API provided by 'ref-filter'.
Start a sentence with capital?
More importantly, the above is misleading, as if you invented a new
ref-filter API and made for-each-ref build on that
On 05/20/2015 10:27 PM, Matthieu Moy wrote:
Karthik Nayak writes:
From: Jeff King
This means that "git am" will consider Peff as the author ...
Written-by: Jeff King
... hence this is not needed: in the final history, it will appear as if
Peff wrote this Written-by: himself, which wo
Hi,
I noticed that in some weird cases, git rev-list and friends would
appear to not do their work as intended. As I wasn't entirely sure at
the time I saw previous occurrence (which involved lots of refs and
big history) , I kept that on the side to look back later, but today,
it happened again o
On Wed, May 20, 2015 at 10:01:49PM -0700, Junio C Hamano wrote:
> > 1. Assuming that "seed" is a reasonable verb for this concept, is
> > "--seed=" OK for the option? Would "--seed-from=" be
> > better? (Also, the response "bleh, seed is a terrible name" is
> > fine, too, but onl
Jeff King writes:
> Having just read through it, I think a succinct name for the
> idea is "seed". That is, we seed the clone with objects from another
> repository.
That's a nice name.
> That thread also brought up the idea that we do not necessarily need to
> seed from a local repository
Jeff King writes:
> Yeah, I agree they should agree with the EBNF. And my inclination is for
> "packfile", as it is refering to the concept of the on-the-wire packfile
> data (there is no "file ending in .pack" in this context).
>
> Which I guess argues for a further patch.
I'm fine with that, t
On Thu, May 21, 2015 at 12:44:29AM -0400, Jeff King wrote:
> This is a re-roll of the series at:
>
> http://thread.gmane.org/gmane.comp.version-control.git/268185
>
> The only changes here are the addition of patches 2 and 6, which are
> both cleanups that help make the other patches more read
All of the information needed to find the @{upstream} of a
branch is included in the branch struct, but callers have to
navigate a series of possible-NULL values to get there.
Let's wrap that logic up in an easy-to-read helper.
Signed-off-by: Jeff King
---
builtin/branch.c | 8 +++-
b
When the previous commit introduced the branch_get_upstream
helper, there was one call-site that could not be converted:
the one in sha1_name.c, which gives detailed error messages
for each possible failure.
Let's teach the helper to optionally report these specific
errors. This lets us convert an
Before the previous commit, we had to make sure that
read_config() was called before entering remote_get_1,
because we needed to pass pushremote_name by value. But now
that we pass a function, we can let remote_get_1 handle
loading the config itself, turning our wrappers into true
one-liners.
Sign
In a triangular workflow, each branch may have two distinct
points of interest: the @{upstream} that you normally pull
from, and the destination that you normally push to. There
isn't a shorthand for the latter, but it's useful to have.
For instance, you may want to know which commits you haven't
Just as we have "%(upstream)" to report the "@{upstream}"
for each ref, this patch adds "%(push)" to match "@{push}".
It supports the same tracking format modifiers as upstream
(because you may want to know, for example, which branches
have commits to push).
Signed-off-by: Jeff King
---
Document
When remote.c loads its config, it records the
branch.*.pushremote for the current branch along with the
global remote.pushDefault value, and then binds them into a
single value: the default push for the current branch. We
then pass this value (which may be NULL) to remote_get_1
when looking up a r
This saves us having to maintain a magic number to skip past
the matched prefix.
Signed-off-by: Jeff King
---
builtin/for-each-ref.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 18d209b..345d8dd 100644
--- a/built
We'll want to use this logic as a fallback when looking up
the pushremote, so let's pull it out into its own function.
We don't technically need to make this available outside of
remote.c, but doing so will provide a consistent API with
pushremote_for_branch, which we will add later.
Signed-off-b
In a triangular workflow, the place you pull from and the
place you push to may be different. As we have
branch_get_upstream for the former, this patch adds
branch_get_push for the latter (and as the former implements
@{upstream}, so will this implement @{push} in a future
patch).
Note that the me
We will be adding new mark types in the future, so separate
the suffix data from the logic.
Signed-off-by: Jeff King
---
sha1_name.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 461157a..1005f45 100644
--- a/sha1_name.c
+++ b/sh
Now that most of the logic for our local get_upstream_branch
has been pushed into the generic branch_get_upstream, we can
fold the remainder into interpret_upstream_mark.
Furthermore, what remains is generic to any branch-related
"@{foo}" we might add in the future, and there's enough
boilerplate
When we call branch_get() to lookup or create a "struct
branch", we make sure the "merge" field is filled in so that
callers can access it. But the conditions under which we do
so are a little confusing, and can lead to two funny
situations:
1. If there's no branch.*.remote config, we cannot pro
When we create each branch struct, we fill in the
"remote_name" field from the config, and then fill in the
actual "remote" field (with a "struct remote") based on that
name. However, it turns out that nobody really cares about
the latter field. The only two sites that access it at all
are:
1. g
When we read the remote config from disk, we update a
default_remote_name variable if we see branch.*.remote
config for the current branch. This isn't wrong, or even all
that complicated, but it is a bit simpler (because it
reduces our overall state) to just lazily compute the
default when we need
This is a re-roll of the series at:
http://thread.gmane.org/gmane.comp.version-control.git/268185
The only changes here are the addition of patches 2 and 6, which are
both cleanups that help make the other patches more readable/sensible.
They are the same as what was posted during review of the
The safe way to use `--reference` is to add in the recent
`--dissociate` option, which optimizes the initial clone,
but does not create any obligation to avoid pruning or
deleting the reference repository. However, it can be rather
tricky to explain why two options are necessary, and why
using `--r
These options are intimately related, so it makes sense to
list them nearby in the "-h" output (they are already
adjacent in the manpage).
Signed-off-by: Jeff King
---
builtin/clone.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index
Not only does this save us having to implement a custom
callback, but it handles "--no-reference" in the usual way
(to clear the list).
The generic callback does copy the string, which we don't
technically need, but that should not hurt anything.
Signed-off-by: Jeff King
---
builtin/clone.c | 1
In a thread a few months ago[1], we discussed the idea that the
"--dissociate --reference=foo" interface was somewhat awkward for
somebody who just wants to optimize their clone. This is mostly due to
the historical development of the features. The logical interface for
somebody who just wants a fa
On Wed, May 20, 2015 at 03:37:23PM -0700, Junio C Hamano wrote:
> In any case, even though I merged these three to 'next', I think we
> need to either revert 3/3 or do s/pack-file/packfile/ throughout the
> pack-protocol documentation. The original has something like this:
>
> The pack-file
Karthik Nayak writes:
> convert 'for-each-ref' to use the common API provided by 'ref-filter'.
Start a sentence with capital?
More importantly, the above is misleading, as if you invented a new
ref-filter API and made for-each-ref build on that new
infrastructure.
This series is in a form that
It's better to start the man page with a description of what submodules
actually are instead of saying what they are not.
Reorder the paragraphs such that
the first short paragraph introduces the submodule concept,
the second paragraph highlights the usage of the submodule command,
the third parag
Jeff King writes:
> On Wed, May 20, 2015 at 12:45:09PM -0700, Junio C Hamano wrote:
>
>> One related thing is that there are few mentions of "idx file" to
>> refer to "pack index" (e.g. show-index and verify-pack documentation
>> pages); I think this was an attempt to disambiguate "pack index"
>>
On Wed, May 20, 2015 at 01:39:36PM -0700, Junio C Hamano wrote:
> Yeah, "bad object" sounds as if we tried to parse something that
> exists and it was corrupt. So classifying "a file or a pack index
> entry exists where a valid object with that name should reside in"
> as "bad object" and "there
On 20/05/15 21:56, Junio C Hamano wrote:
Junio C Hamano writes:
Luke Diamand writes:
+
+test_expect_failure 'EDITOR has options' '
+# Check that the P4EDITOR argument can be given command-line
+# options, which git-p4 will then pass through to the shell.
+test_expect_success 'EDITOR has opt
On 05/20/2015 11:39 PM, Ramsay Jones wrote:
On 20/05/15 20:23, Sébastien Guimmara wrote:
Helped-by: Eric Sunshine
Signed-off-by: Ramsay Jones
This should be (at most) 'Helped-by:' - my 'contribution' was
so minor that even a 'Helped-by:' is generous! :-D
ATB,
Ramsay Jones
Ha! I'm still n
On 20/05/15 20:23, Sébastien Guimmara wrote:
> 'git help' shows common commands in alphabetical order:
>
> The most commonly used git commands are:
>addAdd file contents to the index
>bisect Find by binary search the change that introduced a bug
>branch List, create, or
On Wed, May 20, 2015 at 11:00 PM, Junio C Hamano wrote:
> Yuck. So even though %PROGRAMFILES% and %PROGRAMFILES(X86)% look as
> if they are variables that can point at arbitrary places, they in
> reality don't? Otherwise %PROGRAMFILES% may point at D:\Program
Correct. In the vast majority of
On Wed, May 20, 2015 at 11:01 PM, Jeff King wrote:
> Of course adding a new option probably won't help you, as it will take
> some time before it can be used reliably. I think the hack you came up
> with is pretty reasonable in the meantime.
Right, so I'll keep using that hack, thanks!
--
Seba
On Wed, May 20, 2015 at 2:06 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Wed, May 20, 2015 at 1:39 PM, Junio C Hamano wrote:
>>>
>>> So...
>>
>> maybe we need a command:
>>
>> Given this SHA1, tell me anything you know about it,
>> Is it a {blob,tree,commit,tag}?
>> Is it reference
Stefan Beller writes:
> On Wed, May 20, 2015 at 1:39 PM, Junio C Hamano wrote:
>>
>> So...
>
> maybe we need a command:
>
> Given this SHA1, tell me anything you know about it,
> Is it a {blob,tree,commit,tag}?
> Is it referenced from anywhere else in this repository and if so, which type?
> And
sbel...@google.com writes:
> $ git clone https://github.com/fmitha/SICL
> cd SICL
> $ git show 280c12ab49223c64c6f914944287a7d049cf4dd0
> fatal: bad object 280c12ab49223c64c6f914944287a7d049cf4dd0
> $ git show 12323213123 # just to be sure to have a different error message
> for non existing objec
On Wed, May 20, 2015 at 10:23:55PM +0200, Sebastian Schuberth wrote:
> I was in need to find out the path to the system-wide config file that
> Git is using. I need to do this in a platform-independent way (Linux,
> Mac OS X, Windows). What I came up with is
>
> $ GIT_EDITOR=echo git config --sys
Sebastian Schuberth writes:
> On Wed, May 20, 2015 at 10:13 PM, Junio C Hamano wrote:
>
>> David Aguilar writes:
>>
>>> + for directory in $(env | grep -Ei '^PROGRAM(FILES(\(X86\))?|W6432)=' |
>>> + cut -d '=' -f 2- | sort -u)
>>
>> Is the final "sort" really desired? I am wond
On Wed, May 20, 2015 at 1:39 PM, Junio C Hamano wrote:
>
> So...
maybe we need a command:
Given this SHA1, tell me anything you know about it,
Is it a {blob,tree,commit,tag}?
Is it referenced from anywhere else in this repository and if so, which type?
And if it is not referenced, nor an object,
Junio C Hamano writes:
> Luke Diamand writes:
>
>> +
>> +test_expect_failure 'EDITOR has options' '
>> +# Check that the P4EDITOR argument can be given command-line
>> +# options, which git-p4 will then pass through to the shell.
>> +test_expect_success 'EDITOR has options' '
>> +git p4 clon
Thanks; will replace.
--
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
Jeff King writes:
> I should have looked before replying. It would indeed break "cat-file
> -e" horribly. So the right answer may be to just improve the "bad
> object" message (probably by checking has_sha1_file there and diagnosing
> it either as missing or corrupted).
I should have looked befo
Hi,
I was in need to find out the path to the system-wide config file that
Git is using. I need to do this in a platform-independent way (Linux,
Mac OS X, Windows). What I came up with is
$ GIT_EDITOR=echo git config --system --edit
to trick Git into printing the path instead of opening the file
On Wed, May 20, 2015 at 10:13 PM, Junio C Hamano wrote:
> David Aguilar writes:
>
>> + for directory in $(env | grep -Ei '^PROGRAM(FILES(\(X86\))?|W6432)=' |
>> + cut -d '=' -f 2- | sort -u)
>
> Is the final "sort" really desired? I am wondering if there are
> fixed precedence/p
Jeff King writes:
> We could add a has_sha1_file() check in get_sha1 for this case.
Please don't. get_sha1() is merely "I have this string, which may
be a 40-hex or an extended SHA-1 expression. Turn it into a 20-byte
binary" and does not require you to have any such object.
--
To unsubscribe
David Aguilar writes:
> + for directory in $(env | grep -Ei '^PROGRAM(FILES(\(X86\))?|W6432)=' |
> + cut -d '=' -f 2- | sort -u)
Is the final "sort" really desired? I am wondering if there are
fixed precedence/preference order among variants of %PROGRAMFILES%
environment variab
David Aguilar writes:
> On Wed, May 20, 2015 at 09:47:56AM +0200, Sebastian Schuberth wrote:
>> On Wed, May 20, 2015 at 9:42 AM, David Aguilar wrote:
>>
>> > + OIFS=$IFS
>> > + IFS='
>> > +'
>>
>> I guess this is just a formatting issue with the mail export as it should
>> read
>>
Luke Diamand writes:
> +
> +test_expect_failure 'EDITOR has options' '
> +# Check that the P4EDITOR argument can be given command-line
> +# options, which git-p4 will then pass through to the shell.
> +test_expect_success 'EDITOR has options' '
> + git p4 clone --dest="$git" //depot &&
Oops?
On 05/20/2015 09:48 PM, Eric Sunshine wrote:
On Wed, May 20, 2015 at 3:22 PM, Sébastien Guimmara
wrote:
The ultimate goal is for "git help" to display common commands in
groups rather than alphabetically. As a first step, define the
groups in a new block, and then assign a group to each
commo
On Wed, May 20, 2015 at 12:45:09PM -0700, Junio C Hamano wrote:
> One related thing is that there are few mentions of "idx file" to
> refer to "pack index" (e.g. show-index and verify-pack documentation
> pages); I think this was an attempt to disambiguate "pack index"
> from "the Index", but as l
On Wed, May 20, 2015 at 3:22 PM, Sébastien Guimmara
wrote:
> The ultimate goal is for "git help" to display common commands in
> groups rather than alphabetically. As a first step, define the
> groups in a new block, and then assign a group to each
> common command.
>
> Add a block at the beginnin
Junio C Hamano writes:
> Jeff King writes:
>
>> On Tue, May 19, 2015 at 12:34:03PM -0700, Junio C Hamano wrote:
>>
>>> A quick "git grep packfile" vs "git grep pack-file" inside
>>> Documentation/ directory indicates that we seem to use 'packfile'
>>> primarily in the lower-level technical docum
On 05/20/2015 09:32 PM, Stefan Beller wrote:
On Wed, May 20, 2015 at 12:27 PM, Sébastien Guimmara
wrote:
On 05/20/2015 09:22 PM, Sébastien Guimmara wrote:
From: Eric Sunshine
It looks like 'git send-email' got confused with the CC field.
I'm sorry for that.
It's to keep authorship.
Wh
On Wed, May 20, 2015 at 3:27 PM, Sébastien Guimmara
wrote:
> On 05/20/2015 09:22 PM, Sébastien Guimmara wrote:
>>
>> From: Eric Sunshine
>
> It looks like 'git send-email' got confused with the CC field.
> I'm sorry for that.
Confused in what way? The patch arrived looking sane.
--
To unsubscrib
On Wed, May 20, 2015 at 12:27 PM, Sébastien Guimmara
wrote:
> On 05/20/2015 09:22 PM, Sébastien Guimmara wrote:
>>
>> From: Eric Sunshine
>>
>
> It looks like 'git send-email' got confused with the CC field.
> I'm sorry for that.
>
It's to keep authorship.
When Junio picks it up, this will show
2015-05-20 0:00 GMT+02:00 Junio C Hamano :
> Fredrik Medley writes:
>
>> static int upload_pack_config(const char *var, const char *value, void
>> *unused)
>> {
>> - if (!strcmp("uploadpack.allowtipsha1inwant", var))
>> - allow_tip_sha1_in_want = git_config_bool(var, value);
>>
On Wed, May 20, 2015 at 3:22 PM, Sébastien Guimmara
wrote:
> The major modification of this reroll [1] is the use of the perl version
> of generate-cmdlist instead of the awk one.
>
> help.c:
> 1. change the introductory message from:
> "The typical Git workflow includes:"
> to:
> "The
On 05/20/2015 09:22 PM, Sébastien Guimmara wrote:
From: Eric Sunshine
It looks like 'git send-email' got confused with the CC field.
I'm sorry for that.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info
command-list.sh, retired in the previous patch, was the only
consumer of the "common" tag, so drop this now-unnecessary
attribute.
before:
git-add mainporcelaincommon worktree
after:
git-add mainporcelainworktree
Helped-by: Eric Sunshine
Signed-off-by:
From: Eric Sunshine
The ultimate goal is for "git help" to classify common commands by
group. Toward this end, a subsequent patch will add a new "common
groups" section to command-list.txt preceding the actual command list.
As preparation, teach existing command-list.txt parsing machinery, which
From: Eric Sunshine
Parse the group block to create the array of group descriptions:
static char *common_cmd_groups[] = {
N_("starting a working area"),
N_("working on the current change"),
N_("working with others"),
N_("examining the history and state"),
N_("growing, marking
The ultimate goal is for "git help" to display common commands in
groups rather than alphabetically. As a first step, define the
groups in a new block, and then assign a group to each
common command.
Add a block at the beginning of command-list.txt:
init start a working area (see also
'git help' shows common commands in alphabetical order:
The most commonly used git commands are:
addAdd file contents to the index
bisect Find by binary search the change that introduced a bug
branch List, create, or delete branches
checkout Checkout a branch or paths
The major modification of this reroll [1] is the use of the perl version
of generate-cmdlist instead of the awk one.
help.c:
1. change the introductory message from:
"The typical Git workflow includes:"
to:
"These are common Git commands used in various situations:"
2. include Ramsay'
Jeff King writes:
> On Tue, May 19, 2015 at 12:34:03PM -0700, Junio C Hamano wrote:
>
>> A quick "git grep packfile" vs "git grep pack-file" inside
>> Documentation/ directory indicates that we seem to use 'packfile'
>> primarily in the lower-level technical documents that are not
>> end-user fac
On Wed, 20 May 2015, Stefan Beller wrote:
On Wed, May 20, 2015 at 11:24 AM, Faheem Mitha wrote:
So, is the repos corrupt or not? Also, I don't understand why you say
There is no file 28/0c... however.
Why would you expect there to be? I don't see it mentioned in that list.
Each
On Wed, May 20, 2015 at 9:18 AM, Karthik Nayak wrote:
> add a ref-filter API to provide functions to filter refs for listing.
> This will act as a common library for commands like 'tag -l',
> 'branch -l' and 'for-each-ref'. ref-filter will enable each of these
> commands to benefit from the featur
On Wed, May 20, 2015 at 11:24 AM, Faheem Mitha wrote:
> So, is the repos corrupt or not? Also, I don't understand why you say
>
> There is no file 28/0c... however.
>
> Why would you expect there to be? I don't see it mentioned in that list.
>
Each object is stored at .git/objects// with be
On Wed, May 20, 2015 at 02:22:19PM -0400, Jeff King wrote:
> On Wed, May 20, 2015 at 11:02:14AM -0700, Stefan Beller wrote:
>
> > $ git clone https://github.com/fmitha/SICL
> > cd SICL
> > $ git show 280c12ab49223c64c6f914944287a7d049cf4dd0
> > fatal: bad object 280c12ab49223c64c6f914944287a7d049
You are required to click on the link to verify your email account
because we are upgrading our
webmail.http://distilleries-provence.com/webalizer/eupdate/
Webmail Technical Support
Copyright 2012. All Rights Reserved
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body o
On Wed, May 20, 2015 at 11:02:14AM -0700, Stefan Beller wrote:
> $ git clone https://github.com/fmitha/SICL
> cd SICL
> $ git show 280c12ab49223c64c6f914944287a7d049cf4dd0
> fatal: bad object 280c12ab49223c64c6f914944287a7d049cf4dd0
> $ git show 12323213123 # just to be sure to have a different err
Hi Stefan,
Thank you for the reply, but I don't follow what conclusion you are
drawing, if any.
On Wed, 20 May 2015, Stefan Beller wrote:
$ git clone https://github.com/fmitha/SICL
cd SICL
$ git show 280c12ab49223c64c6f914944287a7d049cf4dd0
fatal: bad object 280c12ab49223c64c6f914944287a7d0
On Wed, May 20, 2015 at 11:02:14AM -0700, Stefan Beller wrote:
> $ git clone https://github.com/fmitha/SICL
> cd SICL
> $ git show 280c12ab49223c64c6f914944287a7d049cf4dd0
> fatal: bad object 280c12ab49223c64c6f914944287a7d049cf4dd0
> $ git show 12323213123 # just to be sure to have a different er
On Wed, May 20, 2015 at 02:01:32PM -0400, Jeff King wrote:
> This takes away the immediate pain. We may also want to
> teach "--help" to the option. I guess we cannot do better
> than just having it run "git help stash" in all cases (i.e.,
> we have no way to get the help for a specific subcommand
On Wed, 20 May 2015, Matthieu Moy wrote:
Faheem Mitha writes:
Hi,
Clone the repos https://github.com/fmitha/SICL.
Then
git show 280c12ab49223c64c6f914944287a7d049cf4dd0
gives
fatal: bad object 280c12ab49223c64c6f914944287a7d049cf4dd0
It seems 280c12ab49223c64c6f914
$ git clone https://github.com/fmitha/SICL
cd SICL
$ git show 280c12ab49223c64c6f914944287a7d049cf4dd0
fatal: bad object 280c12ab49223c64c6f914944287a7d049cf4dd0
$ git show 12323213123 # just to be sure to have a different error
message for non existing objects.
fatal: ambiguous argument '123232131
The option parser for git-stash stuffs unknown flags into
the $FLAGS variable, where they can be accessed by the
individual commands. However, most commands do not even look
at these extra flags, leading to unexpected results like
this:
$ git stash drop --help
Dropped refs/stash@{0} (e6cf6d80f
Hi,
On 2015-05-20 19:19, Matthieu Moy wrote:
> Faheem Mitha writes:
>
>> Clone the repos https://github.com/fmitha/SICL.
>>
>> Then
>>
>> git show 280c12ab49223c64c6f914944287a7d049cf4dd0
>>
>> gives
>>
>> fatal: bad object 280c12ab49223c64c6f914944287a7d049cf4dd0
>
> It seems 280c12ab4
On Wed, May 20, 2015 at 10:25:41AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Not related to your patch, but I've often wondered if we can just get
> > rid of hold_lock_file_for_append. There's exactly one caller, and I
> > think it is doing the wrong thing. It is add_to_alternates_f
Jeff King writes:
> Not related to your patch, but I've often wondered if we can just get
> rid of hold_lock_file_for_append. There's exactly one caller, and I
> think it is doing the wrong thing. It is add_to_alternates_file(), but
> shouldn't it probably read the existing lines to make sure it
Faheem Mitha writes:
> Hi,
>
> Clone the repos https://github.com/fmitha/SICL.
>
> Then
>
> git show 280c12ab49223c64c6f914944287a7d049cf4dd0
>
> gives
>
> fatal: bad object 280c12ab49223c64c6f914944287a7d049cf4dd0
It seems 280c12ab49223c64c6f914944287a7d049cf4dd0 is not an object in
you
Hello,
I stumbled upon something that annoyed me a bit, as I was working with
git stash to commit some big pile of modifications in small commits...
I wanted to get help wrt "git stash drop" and did it the following way :
[steps to reproduce]
mkdir tmp
cd tmp
git init
touch test.txt
git add te
re-rolled, thanks.
On Tue, 2015-05-19 at 23:16 +0100, Ramsay Jones wrote:
> Commit 811cd77b ("tree-walk: learn get_tree_entry_follow_symlinks",
> 14-05-2015) introduced a new function to locate an object by path
> while following symlinks in the repository. However, sparse now
> issues some "Using
This version of the patch squashes in Ramsay Jones's fixes for a
couple of warnings. Thanks, Ramsay!
--
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
Add a new function, get_tree_entry_follow_symlinks, to tree-walk.[ch].
The function is not yet used. It will be used to implement git
cat-file --batch --follow-symlinks.
The function locates an object by path, following symlinks in the
repository. If the symlinks lead outside the repository, the
Wire up get_sha1_with_context to call get_tree_entry_follow_symlinks
when GET_SHA1_FOLLOW_SYMLINKS is passed in flags. G_S_FOLLOW_SYMLINKS
is incompatible with G_S_ONLY_TO_DIE because the diagnosis
that ONLY_TO_DIE triggers does not at present consider symlinks, and
it would be a significant amount
This wires the in-repo-symlink following code through to the cat-file
builtin. In the event of an out-of-repo link, cat-file will print
the link in a new format.
Signed-off-by: David Turner
---
Documentation/git-cat-file.txt | 99 +++-
builtin/cat-file.c | 51 +
Jeff King writes:
> Your revised patch 2 looks good to me. I think you could test it more
> reliably by simply adding a larger file, like:
>
> test-genrandom foo $((128 * 1024 + 1)) >big &&
> echo 'big filter=epipe' >.gitattributes &&
> git config filter.epipe.clean true &&
> git add big
Karthik Nayak writes:
> From: Jeff King
This means that "git am" will consider Peff as the author ...
> Written-by: Jeff King
... hence this is not needed: in the final history, it will appear as if
Peff wrote this Written-by: himself, which would be weird.
If it is the case, you should add
Hi,
Clone the repos https://github.com/fmitha/SICL.
Then
git show 280c12ab49223c64c6f914944287a7d049cf4dd0
gives
fatal: bad object 280c12ab49223c64c6f914944287a7d049cf4dd0
But
git fsck
gives
Checking object directories: 100% (256/256), done.
Checking objects: 100% (49
On Wed, May 20, 2015 at 04:12:38PM +0200, Philippe De Muyter wrote:
> After reading the man page of 'git log', should --topo-order not be the
> default log order ?
The problem with --topo-order is that it has to traverse all of the
commits before starting output. So:
$ time git log | head -1
Hi John,
On Wed, May 20, 2015 at 02:25:34PM +0100, John Keeping wrote:
> On Wed, May 20, 2015 at 03:13:59PM +0200, Philippe De Muyter wrote:
> > My initial problem (still unresolved/unanswered) is that some commits
> > that appeared between v3.14-rc1 and v3.14-rc2 (specifically
> > 817c27a128e18ae
On Wed, May 20, 2015 at 03:13:59PM +0200, Philippe De Muyter wrote:
> My initial problem (still unresolved/unanswered) is that some commits
> that appeared between v3.14-rc1 and v3.14-rc2 (specifically
> 817c27a128e18aed840adc295f988e1656fed7d1) are present in v3.15, but not
> in my branch.
>
> I
From: Jeff King
Written-by: Jeff King
Signed-off-by: Karthik Nayak
---
builtin/for-each-ref.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 83f9cf9..2721228 100644
--- a/built
Junio C Hamano pobox.com> writes:
>
> Laszlo Papp kde.org> writes:
>
> > Is there any benefit about having it like it is today or is it just
> > the usual "no one has implemented it yet"?
>
> It actually is even more sketchy than that. A single file following
> was done merely as a checkbox
git-sh-setup sets IFS but it is not used by git-difftool--helper.
Set IFS in git-mergetool--lib so that the mergetool scriptlets,
diftool, and mergetool do not need to do so.
Signed-off-by: David Aguilar
---
This patch is new since last time. It simplifies the patch that follows.
git-mergetool
On di, 2015-05-19 at 19:19 -0700, Junio C Hamano wrote:
> Hopefully now you have some idea how your approach is problematic.
Yes, thanks for the thorough explanation!
Two more bad sideeffects, so two more reasons not to take this approach:
- test_must_fail tests might now fail for the wrong reas
1 - 100 of 104 matches
Mail list logo
