On Thu, Dec 04, 2014 at 01:33:53PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Thu, Dec 04, 2014 at 10:24:09AM -0800, Junio C Hamano wrote:
> >
> >> I wish this covered a lot more than just this part from an
> >> end-user's point of view, but this is definitely one of the most
> >>
On Fri, Dec 05, 2014 at 03:27:17AM +0100, Christian Couder wrote:
> For example, to chose the editor all the following could apply:
>
> GIT_SEQUENCE_EDITOR env variable
> sequence.editor config variable
> GIT_EDITOR env variable
> core.editor config variable
> VISUAL env variable
> EDITOR env var
On Thu, Dec 04, 2014 at 10:04:29AM -0800, Junio C Hamano wrote:
> > If it is a problem (and again, I am just guessing), I'd imagine you
> > would need a similar setup to what you proposed for unlink(): before
> > renaming "packed-refs.lock" into "packed-refs", hard-link it into your
> > "trash" ar
On Thu, Dec 04, 2014 at 04:25:32PM -0700, Stephen Fisher wrote:
> I'm installing Git 2.2.0 from source distribution on NetBSD 6.1.5
> (amd64) and when I specify --mandir=/usr/local/man, it still installs
> man pages in the default /usr/local/share/man directory. Is there a fix
> available for
Dear Friend,
I am William Keith,Personal banker and account officer to the late UWE
Gamballa who was murdered in South Africa, before his death he was the
CEO of Porsche Motors.
My urgent need for a foreign partner that made me to contact You for
this transaction. I got your contact from yahoo Tou
In the same spirit of 7fce6e3 (commit: correctly respect skip-worktree
bit - 2009-12-14), if a file is marked unchanged, skip it.
Noticed-by: Sérgio Basto
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/commit.c | 2 +-
t/t2106-update-index-assume-unchanged.sh | 10
On Fri, Dec 5, 2014 at 1:55 PM, Johannes Sixt wrote:
> Actually, it's a user error. When you set --assume-unchanged, then you give
> a promise to git that you do not change the files, and git does not have to
> check itself whether there is a change.
>
> But since you did not keep your promise, yo
Junio C Hamano schrieb am 04.12.2014 um 20:13:
> Michael J Gruber writes:
>
>> -f/--force is the standard way to force an action, and is used by branch
>> for the recreation of existing branches, but not for deleting unmerged
>> branches nor for renaming to an existing branch.
>>
>> Make "-m -f"
On 12/05/2014 12:28 AM, Jonathan Nieder wrote:> Michael Haggerty wrote:
>> It was called "unused", so at least it was self-consistent.
>
> The missing context is that this was a callback function that had to
> match the each_ref_fn signature [...]
>
> With or without a note in the commit message ex
On 12/05/2014 12:53 AM, Jonathan Nieder wrote:
> Michael Haggerty wrote:
>
>> [Subject: expire_reflog(): exit early if the reference has no reflog]
>
> The caller moves on to expire other reflogs, so it's not exiting.
> "return early", maybe?
>
> Except the function already returned early. I th
> -Original Message-
> From: git-ow...@vger.kernel.org
> [mailto:git-ow...@vger.kernel.org] On Behalf Of Jason Pyeron
> Sent: Thursday, December 04, 2014 16:34
> To: git@vger.kernel.org
> Cc: 'brian m. carlson'
> Subject: SPAM: RE: FW: [cygwin] Cygwin's git says "error:
> failed to read
> -Original Message-
> From: Jason Pyeron
> Sent: Thursday, December 04, 2014 16:34
> To: git@vger.kernel.org
> Cc: 'brian m. carlson'
> Subject: RE: FW: [cygwin] Cygwin's git says "error:
> failed to read delta-pack base object"
>
> > -Original Message-
> > From: brian m. carlson
On 12/04/2014 09:55 PM, Jeff King wrote:
> On Thu, Dec 04, 2014 at 06:21:40PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>>> That is one of the many reasons why I proposed to have a dictionary of
>>> the main technical terms for each language before we even localise git
>>> in that language. In an id
On 12/05/2014 09:10 AM, Torsten Bögershausen wrote:
> On 05.12.14 06:42, Alex Stangl wrote:
>> Hi,
>>
>> There seems to be problems with the checks in the git code for conflicts
>> between config values of core.autocrlf and core.eol. Because the various
>> config files are read in separate passes,
On Fri, Dec 05, 2014 at 04:55:51PM +0100, Torsten B?gershausen wrote:
> On 12/05/2014 09:10 AM, Torsten B?gershausen wrote:
> Or a test case showing the problem is welcome too.
I mentioned some examples in my previous post. Here they are in
condensed form. They assume core.eol isn't set in your gl
Hi,
On Sex, 2014-12-05 at 17:52 +0700, Duy Nguyen wrote:
> On Fri, Dec 5, 2014 at 1:55 PM, Johannes Sixt wrote:
> > Actually, it's a user error. When you set --assume-unchanged, then you give
> > a promise to git that you do not change the files, and git does not have to
> > check itself whether
Jeff King writes:
> On Thu, Dec 04, 2014 at 01:33:53PM -0800, Junio C Hamano wrote:
>
>> Of course, from _our_ point of view, that somebody is not us. We do
>> not have direct control, certainly from this codepath.
Belated typofix - s/from /not &/.
>
> Right, but in theory we can provoke gpg t
On Thu, Dec 04, 2014 at 06:51:36PM -0800, ronnie sahlberg wrote:
> On Thu, Dec 4, 2014 at 3:08 PM, Michael Haggerty
> wrote:
>
> > We don't actually need the locking functionality, because we already
> > hold the lock on the reference itself,
>
>
> No. You do need the lock.
> The ref is locked
Jeff King writes:
> The only downside I can think of is that we may truncate the message in
> exceptional circumstances. But is it really any less helpful to say:
>
> error: unable to open file: some-incredibly-long-filename-aa...
>
> than printing out an extra 100 lines of "a"? And I mean
Michael J Gruber writes:
>> What should "-f -u" and "-f -l" do, then, though?
>>
>>> list + unset_upstream > 1)
>>> usage_with_options(builtin_branch_usage, options);
>>>
>
> I would say there is nothing to force, so we ignore -f there.
OK, and that is what the updated cod
Sérgio Basto writes:
> On Sex, 2014-12-05 at 17:52 +0700, Duy Nguyen wrote:
>> On Fri, Dec 5, 2014 at 1:55 PM, Johannes Sixt wrote:
>> > Actually, it's a user error. When you set --assume-unchanged, then you give
>> > a promise to git that you do not change the files, and git does not have to
Duy Nguyen writes:
> You are correct about the original idea behind --assume-unchanged. But
> over the time I think we bend over a bit and sort of support these use
> cases. For example, aecda37 (do not overwrite files marked "assume
> unchanged" - 2010-05-01). The change is one-liner, so I don't
On Fri, Dec 05, 2014 at 12:08:21AM +0100, Michael Haggerty wrote:
> Extract two functions, reflog_expiry_prepare() and
> reflog_expiry_cleanup(), from expire_reflog(). This is a further step
> towards separating the code for deciding on expiration policy from the
> code that manages the physical ex
Jeff King writes:
> I _think_ the patch below is also applicable to the code before my
> boundary-fixing patch. But the rearranging also made me more confident
> in it.
Yeah, thanks for a fix.
> -- >8 --
> Subject: for_each_reflog_ent_reverse: turn leftover check into assertion
>
> Our loop sho
On Thu, Dec 04, 2014 at 04:23:31PM -0800, Jonathan Nieder wrote:
> Michael Haggerty wrote:
>
> > We don't actually need the locking functionality, because we already
> > hold the lock on the reference itself, which is how the reflog file is
> > locked. But the lock_file code still does some of the
Stefan Beller writes:
>> > +static struct lock_file reflog_lock;
>>
>> If this lockfile is only used in that one function, it can be declared
>> inside the function.
>>
>> If it is meant to be used throughout the 'git reflog' command, then it
>> can go near the top of the file.
>>
>
> After th
On Fri, Dec 5, 2014 at 11:32 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>>> > +static struct lock_file reflog_lock;
>>>
>>> If this lockfile is only used in that one function, it can be declared
>>> inside the function.
>>>
>>> If it is meant to be used throughout the 'git reflog' comman
Instead of calculating, whether to put a plus or minus sign, offload
the responsibilty to the fprintf function.
Signed-off-by: Stefan Beller
---
refs.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/refs.c b/refs.c
index 40c5591..1147216 100644
--- a/refs.c
+++ b/refs
On Fri, Dec 5, 2014 at 11:53 AM, Stefan Beller wrote:
> Instead of calculating, whether to put a plus or minus sign, offload
> the responsibilty to the fprintf function.
>
> Signed-off-by: Stefan Beller
> ---
Ah! I forgot the --notes switch when sending out the email:
Michael,
please q
I noticed when cherry-picking a commit it includes changes from this commit
and also changes from a different commit as the one I was picking.
I was in contact with "jast" on IRC, who noticed the issue, but didn't had
time to look further.
For a description of my problem, please read
http://stack
From: "Junio C Hamano"
Sérgio Basto writes:
On Sex, 2014-12-05 at 17:52 +0700, Duy Nguyen wrote:
On Fri, Dec 5, 2014 at 1:55 PM, Johannes Sixt wrote:
> Actually, it's a user error. When you set --assume-unchanged, then
> you give
> a promise to git that you do not change the files, and git
Stefan Beller writes:
>>> After the series completes, this lock is only used in reflog_expire.
>>> So I'd rather move it inside the function? Then we could run the
>>> reflog_expire
>>> function in parallel for different locks in theory?
>>
>> I am not sure about the "parallel" part, but I would
"Philip Oakley" writes:
> The problem here is that there is no guidance on what those actions are
> that may make git 'notice'
I think the guidance the users need is the one j6t has given already
in the upthread: "If you are promising Git you are not going to
touch a path, do not touch it.
Junio C Hamano writes:
> If however you did something that made Git notice that you changed
> these paths marked with assume-unchanged bit anyway, then Git will,
> well, notice that they are not "unchanged" as you promised.
By the way, this cuts both ways. I would not bother checking with
the c
Hi,
I've (re)started work on a longstanding idea of mine of having a git tool
talking the mercurial wire protocol directly. I'm now at a stage where
the tool can clone and pull/fetch from mercurial.
As it is a prototype, there are many things that it doesn't handle (like
named branches, bookmarks
I see nobody commented on this, which probably fell into cracks.
Even though I am personally not very interested, I obviously am not
the only user of Git, and there may be others who are interested in
a change like this.
Onno Kortmann writes:
> Hi again,
>
> oops, I realized that my MUA mangled
On Sex, 2014-12-05 at 10:30 -0800, Junio C Hamano wrote:
> Your promise is "these paths I will not modify" and in return you
> gain performance in "git status"
yeah so --assume-unchanged is for administrators of git , like I write
I change first and --assume-unchanged after and never change it
Sérgio Basto writes:
> On Sex, 2014-12-05 at 10:30 -0800, Junio C Hamano wrote:
>> Your promise is "these paths I will not modify" and in return you
>> gain performance in "git status"
>
> yeah so --assume-unchanged is for administrators of git ,...
Not at all.
Administrators would typically
From: "Junio C Hamano"
"Philip Oakley" writes:
The problem here is that there is no guidance on what those actions
are
that may make git 'notice'
I think the guidance the users need is the one j6t has given already
in the upthread: "If you are promising Git you are not going to
touch a
Mike Hommey wrote:
> I'm currently evaluating what the final tool would look like. I'm *very*
> tempted to implement it in C, based on core git code, because there are
> many things that this helper does that would be so much easier to do
> with direct access to git's guts. And that wouldn't requi
"Philip Oakley" writes:
> However the man page's statement 'When the "assume unchanged" bit is on,
> Git stops checking the working tree files for possible modifications, so
> you need to manually unset the bit to tell Git when you change the working
> tree file.' can easily be understood the way
Hi Junio, this is my quick attempt at a patch for the man page.
In $gmane/260837 the --assume-unchanged flag was reported as buggy because
of a misunderstanding about what it is being promised.
This patch looks to be more assertive in stating what promise is being made.
While at it correct a co
Many users misunderstand the --assume-unchanged contract, believing
it means Git won't look at the flagged file.
Be explicit that the --assume-unchanged contract is by the user that
they will NOT change the file so that Git does not need to look (and
expend, fore example, lstat(2) cycles)
Signed-
Hello all –
I am working to create a wrapper around git bundle to synchronize of
git repos via sneakernet from network ‘a’ to network ‘b’ transfer on a
fairly frequent basis (daily to weekly). Network ‘b’ has a
gatekeeper who is persnickety about what content might end up on his
network. The
Test #25 'git client sends Accept-Language based on LANGUAGE, LC_ALL,
LC_MESSAGES and LANG' in t5550 fails consistently on my mac, and has
since the test was introduced. Test 26 and 27 ('git client sends
Accept-Language with many preferred languages' and 'git client does
not send Accept-Language')
From: "Mike Hommey"
Hi,
I've (re)started work on a longstanding idea of mine of having a git
tool
talking the mercurial wire protocol directly. I'm now at a stage where
the tool can clone and pull/fetch from mercurial.
As it is a prototype, there are many things that it doesn't handle
(like
Philip Oakley writes:
> Many users misunderstand the --assume-unchanged contract, believing
> it means Git won't look at the flagged file.
Yeah, I suspect that many of them come from how-tos floating on the
'net (e.g. stackoverflow) that are misguided or outright incorrect.
I've stopped correcti
Michael Blume writes:
> Test #25 'git client sends Accept-Language based on LANGUAGE, LC_ALL,
> LC_MESSAGES and LANG' in t5550 fails consistently on my mac, and has
> since the test was introduced. Test 26 and 27 ('git client sends
> Accept-Language with many preferred languages' and 'git client
On Fri, Dec 05, 2014 at 02:13:19PM -0800, Jonathan Nieder wrote:
> Mike Hommey wrote:
>
> > I'm currently evaluating what the final tool would look like. I'm *very*
> > tempted to implement it in C, based on core git code, because there are
> > many things that this helper does that would be so m
On Fri, Dec 5, 2014 at 2:51 PM, Junio C Hamano wrote:
> Michael Blume writes:
>
>> Test #25 'git client sends Accept-Language based on LANGUAGE, LC_ALL,
>> LC_MESSAGES and LANG' in t5550 fails consistently on my mac, and has
>> since the test was introduced. Test 26 and 27 ('git client sends
>> A
Jesse Hopkins writes:
> 2. Is there a way to list commits contained in the bundle file itself?
> This seems like it would be more robust than trying to re-create the
> commit list via 'git rev-list'.
"git bundle list-heads o.bndl" shows the positive endpoints, but
there is no corresponding "git
Jeff King wrote:
> One of the nice things about spinning remote-hg out of the core repo is
> that it means we do not have to endorse a particular implementation, and
> they can compete with each other on their merits.
True.
[...]
> It's a shame that both squat on the name "remote-hg", because it
On Fri, Dec 05, 2014 at 03:36:18PM -0700, Jesse Hopkins wrote:
> 1. Any thoughts on why a tag would be included by 'git bundle', when
> 'git rev-list' with the same arguments returns empty?
I think the answer to this is found in the git rev-list manpage:
List commits that are reachable by follo
Torsten Bögershausen writes:
> Depending on the file content, eol parameters and .gitattributes
> "git add" may give a warning when the eol of a file will change
> when the file is checked out again.
>
> There are 2 different warnings, either "CRLF will be replaced..." or
> "LF will be replaced..
On Fri, Dec 05, 2014 at 05:59:30PM -0500, Jeff King wrote:
> On Fri, Dec 05, 2014 at 02:13:19PM -0800, Jonathan Nieder wrote:
>
> > Mike Hommey wrote:
> >
> > > I'm currently evaluating what the final tool would look like. I'm *very*
> > > tempted to implement it in C, based on core git code, bec
Junio C Hamano writes:
> This reads much better than the original, but you may want to go a
> bit further. How about removing the original a bit more, like so:
> ...
So here is what I came up to squash into your version when queuing
it to 'pu'.
-- >8 --
Subject: [PATCH] SQUASH???
- Further m
"brian m. carlson" writes:
> On Fri, Dec 05, 2014 at 03:36:18PM -0700, Jesse Hopkins wrote:
>> 1. Any thoughts on why a tag would be included by 'git bundle', when
>> 'git rev-list' with the same arguments returns empty?
>
> I think the answer to this is found in the git rev-list manpage:
>
> L
On Fri, Dec 05, 2014 at 03:40:06PM -0800, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> > On Fri, Dec 05, 2014 at 03:36:18PM -0700, Jesse Hopkins wrote:
> >> 1. Any thoughts on why a tag would be included by 'git bundle', when
> >> 'git rev-list' with the same arguments returns empty?
>
On Fri, Dec 05, 2014 at 03:13:30PM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > One of the nice things about spinning remote-hg out of the core repo is
> > that it means we do not have to endorse a particular implementation, and
> > they can compete with each other on their merits.
>
>
On Sex, 2014-12-05 at 20:48 +, Philip Oakley wrote:
> The problem here is that there is no guidance on what those actions
> are
> that may make git 'notice'. The man page git-update-index isn't as
> clear
> as it could be. Using --really-refresh being one option that would
> make
> git notice,
On Sun, Oct 26, 2014 at 8:39 AM, Dennis Kaarsemaker
wrote:
> On Wed, Oct 22, 2014 at 10:11:40AM -0700, Junio C Hamano wrote:
>> Dennis Kaarsemaker writes:
>>
>> > On di, 2014-10-21 at 10:56 -0700, Junio C Hamano wrote:
>> >> Dennis Kaarsemaker writes:
>> >>
>> >> > By not clearing the request bu
Signed-off-by: Stefan Beller
---
Just stumbled accross this one and wasn't sure if it also frees up
the memory involved.
string-list.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/string-list.h b/string-list.h
index 494eb5d..99ecc44 100644
--- a/string-list.h
+++ b/string-list.h
@
Stefan Beller wrote:
> Signed-off-by: Stefan Beller
> ---
>
> Just stumbled accross this one and wasn't sure if it also frees up
> the memory involved.
>
> string-list.h | 5 +
> 1 file changed, 5 insertions(+)
Sounds reasonable. Documentation/technical/api-string-list.txt
documents thes
Failures start from
commit d2384abff7a6181fd7b9a51af7e780aa21e5cb8d (refs/bisect/bad)
Author: Luis Henriques
Date: Thu Dec 4 19:11:30 2014 +
test/send-email: --[no-]xmailer tests
Add tests for the --[no-]xmailer option.
Signed-off-by: Luis Henriques
Signed-off-by: Junio
Instead of calculating, whether to put a plus or minus sign, offload
the responsibilty to the fprintf function.
Signed-off-by: Stefan Beller
---
Notes:
This patch was already sent as a single patch to the list,
but not yet acknowledge in any way, so I am including it here.
This
Currently a transaction can include one or more reflog updates. But these
are not part of the contract of the transaction committing all or nothing.
Introduce a function transaction_update_reflog, which adds a reflog update
to a transaction. Later patches will update code that writes to reflogs to
From: Ronnie Sahlberg
log_ref_setup is used to do several semi-related things:
* Sometimes it will create a new reflog including missing parent
directories and cleaning up any conflicting stale directories
in the path.
* Fill in a filename buffer for the full path to the reflog.
* Uncondition
The updates are only holding refs not reflogs, so express it to the reader.
Signed-off-by: Stefan Beller
Reviewed-by: Jonathan Nieder
---
Notes:
no changes since last sending it.
refs.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/refs.c b/refs.c
inde
From: Ronnie Sahlberg
Add back support to make it possible to delete refs that have a broken
sha1.
Add new internal flags REF_ALLOW_BROKEN and RESOLVE_REF_ALLOW_BAD_SHA1
to pass intent from branch.c that we are willing to allow
resolve_ref_unsafe and lock_ref_sha1_basic to allow broken refs.
Sin
Rename the transaction functions. Remove the leading ref_ from the
names and append _ref to the names for functions that create/delete/
update sha1 refs.
The goal in the long term is to have different things running through
the transaction api, such as the .git/config file. The dream is to
have an
This continues the work of the previous patch as reflogs not
only grow, but also need a cut sometimes. This patch introduces
transaction_delete_reflog as part of the transaction API to
delete the reflog.
This function serves two purposes. It can be used to actually
delete the reflog as the name in
This goes on top of Michaels series. The idea of this series is make the
reflogs being part of the transaction API, so it will be part of the contract
of transaction_commit to either commit all the changes or none at all.
Currently when using the transaction API to change refs, also reflogs are
c
From: Ronnie Sahlberg
Use a transaction for all updates during expire_reflog.
[sb: This was once a patch series on its own. I cherry-picked these
patches on top of Michaels series to cleanup the refs api. So any
anomalies and bugs may be introduced by me.]
Signed-off-by: Ronnie Sahlberg
Signed
If you're referring to what 86ff53a7a178 has it has resolved the merge
conflict in a way that is almost certainly wrong. If you turn on diff3
markers you can see that LHS deleted clone_test while RHS added a
function right after it. The correct resolution is to include RHS's new
stuff but not tha
On Fri, Dec 05, 2014 at 03:13:30PM -0800, Jonathan Nieder wrote:
> > It's a shame that both squat on the name "remote-hg", because it makes
> > it difficult to tell the two apart. But of course that is the only way
> > to make "git clone hg::..." work. Maybe we need a layer of indirection?
> > :)
On Fri, Dec 05, 2014 at 03:36:18PM -0700, Jesse Hopkins wrote:
> #Create the bundle
> git bundle create out.bundle --all "--since="
Others pointed out that a bug in the handling of --since may be the
culprit here. However, I'd encourage you to use actual sha1s, as they
are going to be more robust
On Fri, Dec 05, 2014 at 06:04:58PM -0800, Jonathan Nieder wrote:
> That reminds me: why do we call this string_list_clear instead of
> string_list_free?
Because it does not free the struct itself, and because you can then use
the result again. I think we try to draw a distinction between:
/* F
On Fri, Dec 05, 2014 at 06:04:58PM -0800, Jonathan Nieder wrote:
> Stefan Beller wrote:
>
> > Signed-off-by: Stefan Beller
> > ---
> >
> > Just stumbled accross this one and wasn't sure if it also frees up
> > the memory involved.
> >
> > string-list.h | 5 +
> > 1 file changed, 5 inserti
On Fri, Dec 05, 2014 at 06:05:24PM -0800, Michael Blume wrote:
> Failures start from
>
> commit d2384abff7a6181fd7b9a51af7e780aa21e5cb8d (refs/bisect/bad)
> Author: Luis Henriques
> Date: Thu Dec 4 19:11:30 2014 +
>
> test/send-email: --[no-]xmailer tests
>
> Add tests for the --
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks for the input, Junio.
On Thu, Dec 04, 2014 at 13:11:15 -0800, Junio C Hamano wrote:
> I am however not quite sure what conclusion you are trying to drive
> at by contrasting approaches #2 and #3. The perceived problem of
> approach #2, if I am
On Fri, Dec 5, 2014 at 9:34 PM, Jeff King wrote:
> On Fri, Dec 05, 2014 at 06:05:24PM -0800, Michael Blume wrote:
>
>> Failures start from
>>
>> commit d2384abff7a6181fd7b9a51af7e780aa21e5cb8d (refs/bisect/bad)
>> Author: Luis Henriques
>> Date: Thu Dec 4 19:11:30 2014 +
>>
>> test/send
On Fri, Dec 05, 2014 at 10:27:40PM -0800, Michael Blume wrote:
> > We have had trouble in the past with "wc -l" output not being strictly
> > portable. I do not recall offhand which systems, but it is a good bet
> > that this is the culprit. Doing:
> >
> > grep ^X-Mailer: out >mailer &&
> > te
On Fri, Dec 05, 2014 at 11:07:37PM -0800, Michael Blume wrote:
> > Ah, right, we might be looking for 0 sometimes. The right way to do it
> > without destroying the &&-chaining is:
> >
> > { grep ^X-Mailer: out || true } &&
> > test_line_count = $expected mailer
>
> Hmm, it doesn't look like
83 matches
Mail list logo
