On Thu, Jul 06, 2017 at 09:01:49AM +0530, Kaartic Sivaraam wrote:
> In the context of "git merge" the meaning of an "empty message"
> is one that contains no line of text. This is not in line with
> "git commit" where an "empty message" is one that contains only
> whitespaces and/or signed-off-by l
On Tue, Jul 04, 2017 at 10:19:09AM +0300, Konstantin Khomoutov wrote:
> On Tue, Jul 04, 2017 at 12:00:49AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> > I don't have a OSX box, but was helping a co-worker over Jabber the
> > other day, and he pasted something like:
> >
> > $ git merge-base gith
In the context of "git merge" the meaning of an "empty message"
is one that contains no line of text. This is not in line with
"git commit" where an "empty message" is one that contains only
whitespaces and/or signed-off-by lines. This could cause surprises
to users who are accustomed to the meanin
On Wed, 2017-07-05 at 12:19 -0700, Junio C Hamano wrote:
> I honestly do not see your point. Yes, I said that the change
> indicates that there is no useful example found (so far). That does
> not necessarily mean that we must find a useful example so that we
> can keep this sample script, which
Signed-off-by: Kaartic Sivaraam
---
builtin/commit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 8d1cac062..aff6bf7aa 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -984,7 +984,7 @@ static int rest_is_empty(struct strbuf *
On Wed, 2017-07-05 at 11:18 -0700, Junio C Hamano wrote:
> Kaartic Sivaraam writes:
>
> > ---
> > Though very trivial, I wanted to correct this as I didn't
> > want to ignore it after seeing it.
>
> Thanks for sharp eyes. Sign-off? (or Sign-of? ;-))
>
I should also thank you for your sharp
Ævar Arnfjörð Bjarmason writes:
> Even though this modifies some of the same files as
> mh/packed-ref-store it looks to me like this doesn't conflict with
> that topic in any meaningful way, but I may be missing something. I
> can't get a merge between this & gitster/mh/packed-ref-store
> compil
Dear Talented,
I am Talent Scout For Sony Pictures Animation, Present Sony Pictures Animation
Movies a Film Corporation Located in the United State, is Soliciting for the
Right to use Your Photo/Face and Personality as One of the Semi -Major
Role/ Character in our Upcoming ANIMATED Stereoscope 3D
Add a test for how 'git branch -m' handles the renaming of multiple
config sections existing for one branch.
The config format we use is hybrid machine/human editable, and we do
our best to preserve the likes of comments and formatting when editing
the file with git-config.
This adds a test for t
From: Sahil Dua
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work
From: Sahil Dua
Factor out the logic which creates section headers in the config file,
e.g. the 'branch.foo' key will be turned into '[branch "foo"]'.
This introduces no function changes, but is needed for a later change
which adds support for copying branch sections in the config file.
Signed-
On Wed, Jul 05 2017, Junio C. Hamano jotted:
> * sd/branch-copy (2017-06-18) 3 commits
> - branch: add a --copy (-c) option to go with --move (-m)
> - branch: add test for -m renaming multiple config sections
> - config: create a function to format section headers
>
> "git branch" learned "-c/
> [Graduated to "master"]
>
> * bw/repo-object (2017-06-23) 21 commits
...
>
> Introduce a "repository" object to eventually make it easier to
> work in multiple repositories (the primary focus is to work with
> the superproject and its submodules) in a single process.
It's pretty rad to see th
Jeff King writes:
>> > +test_expect_failure 'walking multiple reflogs shows both' '
>> > + {
>> > + do_walk HEAD &&
>> > + do_walk side
>> > + } >expect &&
>> > + do_walk HEAD side >actual &&
>> > + test_cmp expect actual
>> > +'
>>
>> I somehow find this one a bit iffy.
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
You can find the changes described
On Wed, Jul 05, 2017 at 11:07:35AM -0700, Junio C Hamano wrote:
> > This is actually the main "gotcha" I'm worried about with this series.
> > I'm not sure if any other code would care about seeing the pending items
> > in revs->commits. I still think the series is the right direction; if
> > ther
On Wed, Jul 05, 2017 at 09:05:14PM +0100, Ramsay Jones wrote:
> On 05/07/17 09:00, Jeff King wrote:
> > Since its inception, the general strategy of the reflog-walk
> > code has been to start with the tip commit for the ref, and
> > as we traverse replace each commit's parent pointers with
> > fak
On Wed, Jul 05, 2017 at 10:56:42AM -0700, Junio C Hamano wrote:
> > 1. The fake parents are used for commit selection and
> > display. So for example, "--merges" or "--no-merges"
> > are useful, because the history appears as a linear
>
> s/useful/useless/ perhaps?
Oops, yes ("not us
On Wed, Jul 05, 2017 at 10:34:03AM -0700, Junio C Hamano wrote:
> > + if (!logobj)
> > + logobj = parse_object(&reflog->ooid);
> > }
>
> For the current 'maint', this would need to be backported to the
> uchar[20] interface (which is trivial to do, and merging it u
tbo...@web.de writes:
> From: Torsten Bögershausen
>
> cygwin can use an UNC path like //server/share/repo
> $ cd //server/share/dir
> $ mkdir test
> $ cd test
> $ git init --bare
>
> However, when we try to push from a local Git repository to this repo,
> there is a problem: Git converts
Stefan Beller writes:
> This goes on top of sb/hashmap-customize-comparison.
> No functional impact but a pure cleanup series:
> No casts to hashmap_cmp_fn in the whole code base any more.
>
> This revealed another interesting thing, which is not a bug per se:
> The const correctness of hashmap_c
On 05/07/17 18:35, Kaartic Sivaraam wrote:
> The sample hook to prepare the commit message before
> a commit allows users to opt-in to add the signature
> to the commit message. The signature is added at a place
> that isn't consistent with the "-s" option of "git commit".
> Further, it could go
On 05/07/17 09:00, Jeff King wrote:
> Since its inception, the general strategy of the reflog-walk
> code has been to start with the tip commit for the ref, and
> as we traverse replace each commit's parent pointers with
> fake parents pointing to the previous reflog entry.
>
> This lets us trav
Kaartic Sivaraam writes:
> +sed -e '/^# Please enter the .*/ {
> + N
> + N
> + d
> +}' "$1" >'.sed-output.temp' && mv '.sed-output.temp' "$1"
Three things that caught my eyes:
- Between "git commit --cleanup=strip" and "git commit --cleanup=verbatim",
lines that make up this initial inst
Kaartic Sivaraam writes:
> The sample hook to prepare the commit message before
> a commit allows users to opt-in to add the signature
> to the commit message. The signature is added at a place
> that isn't consistent with the "-s" option of "git commit".
> Further, it could go out of view in cer
Kaartic Sivaraam writes:
>> On Wed, 2017-07-05 at 10:00 -0700, Junio C Hamano wrote:
>> > I am not so sure that we are searching for them, to be honest (who
>> > are we in this context anyway?)
>>
> Imagining HTML could be used in plain-text,
>
> I think I misinterpreted your sentence in one of
On Sat, Jul 1, 2017 at 10:35 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> When status is called with '--porcelain' (as implied by '-z'), we promise
>> to output only messages as described in the man page.
>>
>> Suppress CRLF warnings.
>>
>> Signed-off-by: Stefan Beller
>> ---
>>
>> May
On Wed, Jul 5, 2017 at 12:43 PM, Francesco Mazzoli wrote:
>> On 5 Jul 2017, at 17:17, Junio C Hamano wrote:
>>
>> The take-away lesson that the earlier thread gave me was that the
>> order in which the three options are ranked by their desirebility
>> in the UI (and the order we would like to enc
Stefan Beller writes:
>> @@ -636,7 +636,7 @@ static int get_sha1_basic(const char *str, int len,
>> unsigned char *sha1,
>> int detached;
>>
>> if (interpret_nth_prior_checkout(str, len, &buf) > 0) {
>> - detached = (buf.len == 40 && !get_sha
> On Wed, 2017-07-05 at 10:00 -0700, Junio C Hamano wrote:
> > I am not so sure that we are searching for them, to be honest (who
> > are we in this context anyway?)
>
Imagining HTML could be used in plain-text,
I think I misinterpreted your sentence in one of the other
mails (found below), Sor
Kaartic Sivaraam writes:
> ---
> Though very trivial, I wanted to correct this as I didn't
> want to ignore it after seeing it.
Thanks for sharp eyes. Sign-off? (or Sign-of? ;-))
>
> builtin/commit.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/commit.c
Jeff King writes:
> When git-rev-list sees no pending commits, it shows a usage
> message. This works even when reflog-walking is requested,
> because the reflog-walk code currently puts the reflog tips
> into the pending queue.
>
> In preparation for refactoring the reflog-walk code, let's
> exp
On Wed, Jul 05 2017, Stefan Beller jotted:
> On Tue, Jul 4, 2017 at 6:56 PM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> On Tue, Jul 4, 2017 at 3:50 PM, Ævar Arnfjörð Bjarmason
>>> wrote:
>>>
I think some invocation of "git submodule update ???" will do the same,
but I
On Tue, Jul 4, 2017 at 9:10 PM, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
>> It is possible there will be some other conflicts with in flight topics,
>> as get_sha1 is commonly used in the codebase. This is unavoidable to
>> some extent, but should be kept in mind. My experience is t
> @@ -496,8 +496,8 @@ int find_unique_abbrev_r(char *hex, const unsigned char
> *sha1, int len)
> return 40;
> exists = has_sha1_file(sha1);
> while (len < 40) {
Here are two prime candidates for GIT_SHA1_HEXSZ, too.
> @@ -636,7 +636,7 @@ static int get_sha1_basic
Jeff King writes:
> Since its inception, the general strategy of the reflog-walk
> code has been to start with the tip commit for the ref, and
> as we traverse replace each commit's parent pointers with
> fake parents pointing to the previous reflog entry.
>
> This lets us traverse the reflog as
On Tue, Jul 4, 2017 at 6:56 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Tue, Jul 4, 2017 at 3:50 PM, Ævar Arnfjörð Bjarmason
>> wrote:
>>
>>>
>>> I think some invocation of "git submodule update ???" will do the same,
>>> but I can't from the docs see what that is right now.
>>
>>
The sample hook to prepare the commit message before
a commit allows users to opt-in to add the signature
to the commit message. The signature is added at a place
that isn't consistent with the "-s" option of "git commit".
Further, it could go out of view in certain cases.
Add the signature in a w
Jeff King writes:
> Since 39ee4c6c2f (branch: record creation of renamed branch
> in HEAD's log, 2017-02-20), a rename on the currently
> checked out branch will create two entries in the HEAD
> reflog: one where the branch goes away (switching to the
> null oid), and one where it comes back (swi
On Wed, 2017-07-05 at 10:00 -0700, Junio C Hamano wrote:
> Kaartic Sivaraam writes:
>
> > So, we're searching for scripts that
> > could both be helpful to users and could serve as a good sample to
> > prove what could be done using the hooks.
>
> I am not so sure that we are searching for them
Jeff King writes:
> Ultimately I think the path forward is to have a ref backend that
> behaves uniformly (either because it avoids the filesystem, or because
> it encodes around the differences). See:
>
> http://public-inbox.org/git/xmqqvb4udyf9@gitster.mtv.corp.google.com/
>
> and its rep
On Wed, 2017-07-05 at 01:30 +0530, Kaartic Sivaraam wrote:
> I tried pointing it to the installed location, it doesn't seem to be
> working. To elaborate a little on what I did,
>
> * I installed the "libcurl4-openssl-dev" package b
> * I found that the 'include' directory to be pr
---
Though very trivial, I wanted to correct this as I didn't
want to ignore it after seeing it.
builtin/commit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 8d1cac0..aff6bf7 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@
The sample hook to prepare the commit message before
a commit allows users to opt-in to add the signature
to the commit message. The signature is added at a place
that isn't consistent with the "-s" option of "git commit".
Further, it could go out of view in certain cases.
Add the signature in a w
Kaartic Sivaraam writes:
> So, we're searching for scripts that
> could both be helpful to users and could serve as a good sample to
> prove what could be done using the hooks.
I am not so sure that we are searching for them, to be honest (who
are we in this context anyway?)
This sounds like
The pre-commit-msg hook sample has an example that comments
the "Conflicts:" part of the merge commmit. It isn't relevant
anymore as it's done by default since 261f315b ("merge & sequencer:
turn "Conflicts:" hint into a comment", 2014-08-28).
Add an alternative example that replaces it. This ensur
Hello all,
There's an attempt in progress to replace the part of the sample
"prepare-commit-msg" hook that comments the "Conflicts" part of a merge
commit message. This is being done as the "Conflicts" portion is
commented by default for quite some time (since 2014) and thus the
script in the hook
> On 5 Jul 2017, at 17:17, Junio C Hamano wrote:
>
> The take-away lesson that the earlier thread gave me was that the
> order in which the three options are ranked by their desirebility
> in the UI (and the order we would like to encourage users to use)
> is, from the most to the least preferrab
Johannes Schindelin writes:
> It seems to be a little-known feature of `grep` (and it certainly came
> as a surprise to this here developer who believed to know the Unix tools
> pretty well) that multiple patterns can be passed in the same
> command-line argument simply by separating them by newl
Ævar Arnfjörð Bjarmason writes:
> On Fri, Jun 30 2017, Junio C. Hamano jotted:
>
>> * xz/send-email-batch-size (2017-05-23) 1 commit
>> - send-email: --batch-size to work around some SMTP server limit
>>
>> "git send-email" learned to overcome some SMTP server limitation
>> that does not allow
On Wed, Jul 5, 2017 at 1:26 PM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Wed, Jul 05 2017, Junio C. Hamano jotted:
>
>> On Tue, Jul 4, 2017 at 11:34 PM, Francesco Mazzoli wrote:
>>>
>>> Could you clarify the danger you're referring to? E.g. give an example
>>> of surprising --force-with-lease behavi
Francesco Mazzoli writes:
> So we would have something like
>
> * `push.disableForce`: config flag that disables `--force` and suggests
> `--force-with-lease` instead;
> * `--disable-force` and `--no-disable-force`, config flags to tune the above
> config parameter at will.
>
> What do yo
It seems to be a little-known feature of `grep` (and it certainly came
as a surprise to this here developer who believed to know the Unix tools
pretty well) that multiple patterns can be passed in the same
command-line argument simply by separating them by newlines. Watch, and
learn:
$ pri
On Wed, Jul 05 2017, Junio C. Hamano jotted:
> On Tue, Jul 4, 2017 at 11:34 PM, Francesco Mazzoli wrote:
>>
>> Could you clarify the danger you're referring to? E.g. give an example
>> of surprising --force-with-lease behavior that we do not want to
>> encourage?
>
> https://public-inbox.org/git
On Sat, Jul 01, 2017 at 08:30:38PM +0200, Michael Haggerty wrote:
> This is v3 of a patch series creating a `packed_ref_store` reference
> backend. Thanks to Peff and Junio for their comments about v2 [1].
>
> Changes since v2:
>
> * Delete some debugging `cat` commands in t1408.
>
> * Add some
On Fri, Jun 30, 2017 at 12:14:06PM -0700, Stefan Beller wrote:
> As eluded to in the previous patch, the code in patch-ids.c is using
> the hashmaps API wrong.
>
> Luckily we do not have a bug, as all hashmap functionality that we use
> here (hashmap_get) passes through the keydata. If hashmap_g
On Tue, Jul 04, 2017 at 10:24:30AM +0200, Ævar Arnfjörð Bjarmason wrote:
> I.e. we allow any arbitrary ref sitting in .git/, but presumably we
> could just record the original string the user provided so that this
> dies on OSX/Windows too:
>
> $ cp .git/{HEAD,Whatever}
> $ git rev-parse
On Tue, Jul 04, 2017 at 09:57:58AM +0200, Andreas Krey wrote:
> Questions:
>
> What can be done about this? Cronjob 'git reflog expire' at midnight,
> so the heuristic don't trigger during the day? (The relnotes don't
> mention anything after 2.4.0, so I suppose a git upgrade won't help.)
>
> Wh
The reflog-walk system works by putting a ref's tip into the
pending queue, and then "traversing" the reflog by
pretending that the parent of each commit is the previous
reflog entry.
This causes a number of user-visible oddities, as documented
in t1414 (and the commit message which introduced it)
When git-rev-list sees no pending commits, it shows a usage
message. This works even when reflog-walking is requested,
because the reflog-walk code currently puts the reflog tips
into the pending queue.
In preparation for refactoring the reflog-walk code, let's
explicitly check whether we have any
On 5 July 2017 at 09:43, Junio C Hamano wrote:
> On Tue, Jul 4, 2017 at 11:34 PM, Francesco Mazzoli wrote:
>>
>> Could you clarify the danger you're referring to? E.g. give an example
>> of surprising --force-with-lease behavior that we do not want to
>> encourage?
>
> https://public-inbox.org/gi
The get_revision_1() function tries to avoid entering its
main loop at all when there are no commits to look at. But
it's perfectly safe to call pop_commit() on an empty list
(in which case it will return NULL). Switching to an early
return from the loop lets us skip repeating the loop
condition be
When we're doing a reflog walk (instead of walking the
actual parent pointers), we may see commits multiple times.
For this reason, we hold on to the commit buffer for each
commit rather than freeing it after we've showed the commit.
We should do the same for the parent list. Right now this is
jus
Since its inception, the general strategy of the reflog-walk
code has been to start with the tip commit for the ref, and
as we traverse replace each commit's parent pointers with
fake parents pointing to the previous reflog entry.
This lets us traverse the reflog as if it were a real
history, but
Since 39ee4c6c2f (branch: record creation of renamed branch
in HEAD's log, 2017-02-20), a rename on the currently
checked out branch will create two entries in the HEAD
reflog: one where the branch goes away (switching to the
null oid), and one where it comes back (switching away from
the null oid)
On Tue, Jul 04, 2017 at 05:24:08PM -0400, Jeff King wrote:
> On Tue, Jul 04, 2017 at 07:58:06PM +, brian m. carlson wrote:
>
> > > And here's one more patch on top of those that's necessary to get the
> > > tests to pass (I don't expect anybody to necessarily be applying this
> > > slow strin
On Tue, Jul 4, 2017 at 11:34 PM, Francesco Mazzoli wrote:
>
> Could you clarify the danger you're referring to? E.g. give an example
> of surprising --force-with-lease behavior that we do not want to
> encourage?
https://public-inbox.org/git/1491617750.2149.10.ca...@mattmccutchen.net/
From: "Junio C Hamano"
Sent: Monday, July 03, 2017 9:19 PM
"Philip Oakley" writes:
Am I right that the What's cooking is prepared by a script?
Because I have to keep track of so many topics, its maintenance is
heavily helped by a script. I do not think it is sensible to expect
me to (or it
68 matches
Mail list logo
