[Resent the cover letter, as I did not see it on public-inbox...]
It is fragile, as there is no way for the revision machinery to say "but
now I want to traverse the graph ignoring the graft file" e.g. when
pushing commits to a remote repository (which, as a consequence, can
miss commits).
And we
The functionality is now implemented as `git replace
--convert-graft-file`.
Signed-off-by: Johannes Schindelin
---
contrib/convert-grafts-to-replace-refs.sh | 28 ---
1 file changed, 28 deletions(-)
delete mode 100755 contrib/convert-grafts-to-replace-refs.sh
diff --git a/c
Now that grafts are deprecated, we should start to assume that readers
have no idea what grafts are. So it makes more sense to make the
description of the "shallow" feature stand on its own.
Suggested-by: Eric Sunshine
Helped-by: Junio Hamano
Signed-off-by: Johannes Schindelin
---
Documentatio
The graft file is deprecated now, so let's use replace refs in the example
in filter-branch's man page instead.
Suggested-by: Eric Sunshine
Signed-off-by: Johannes Schindelin
---
Documentation/git-filter-branch.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentatio
It is tempting to do away with commit_graft altogether (in the long
haul), now that grafts are deprecated.
However, the shallow feature needs a couple of things that the replace
refs cannot fulfill. Let's point that out in the documentation.
Signed-off-by: Johannes Schindelin
---
Documentation/
This is yet another patch to be filed under the keyword "libification".
There is one subtle change in behavior here, where a `git log` that has
been asked to show the mergetags would now stop reporting the mergetags
upon the first failure, whereas previously, it would have continued to the
next me
This is a simple function that will interpret a string as a whitespace
delimited list of values, and add those values into the array.
Note: this function does not (yet) offer to split by arbitrary delimiters,
or keep empty values in case of runs of whitespace, or de-quote Unix shell
style. All fo
When converting all grafts in a graft file to replace refs, and one of
them happens to leave the original commit's parents unchanged, we do not
want to error out. Instead, we would like to issue a warning.
Prepare the create_graft() function for such a use case by adding a
`gentle` parameter. If s
The grafts feature was a convenient way to "stitch together" ancient
history to the fresh start of linux.git.
Its implementation is, however, not up to Git's standards, as there are
too many ways where it can lead to surprising and unwelcome behavior.
For example, when pushing from a repository w
The proof, as the saying goes, lies in the pudding. So here is a
regression test that not only demonstrates what the option is supposed to
accomplish, but also demonstrates that it does accomplish it.
Signed-off-by: Johannes Schindelin
---
t/t6050-replace.sh | 28
1
This option is intended to help with the transition away from the
now-deprecated graft file.
Signed-off-by: Johannes Schindelin
---
Documentation/git-replace.txt | 11 ++---
builtin/replace.c | 44 ++-
2 files changed, 51 insertions(+), 4 deletions
File this away as yet another patch in the "libification" category.
As with all useful functions, in the next commit we want to use
create_graft() from a higher-level function where it would be
inconvenient if the called function simply die()s: if there is a
problem, we want to let the user know h
We have the BUG() macro for that purpose.
Signed-off-by: Johannes Schindelin
---
builtin/replace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/replace.c b/builtin/replace.c
index 245d3f4164e..e345a5a0f1c 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -5
Derrick Stolee writes:
> The generation number of a commit is defined recursively as follows:
>
> * If a commit A has no parents, then the generation number of A is one.
> * If a commit A has parents, then the generation number of A is one
> more than the maximum generation number among the par
While working on the --convert-graft-file test, I missed that I was
relying on the GPG prereq, by using output of test cases that were only
run under that prereq.
For debugging, it was really convenient to force that prereq to be
unmet, but there was no easy way to do that. So I came up with a way
Hello Joel,
Since there seems to be interest from GSOC students who want to
work on converting builtins, I figured I should finish what I
have that works now so they could build on top of it.
First of all, I must thank you for submitting this series of patches. It
is a great starting point to
I forgot to mention that I added the code to error out
if --remote-tags is used with "tracking" (-t | --track) or
mirror:
+ if ((fetch_tags == TAGS_SET_REMOTE) && mirror)
+ die(_("specifying --remote-tags makes no sense with
--mirror"));
+ if ((fetch_tags == TAGS_SET
Hi Martin,
On Sat, Apr 28, 2018 at 4:32 AM, Martin Ågren wrote:
> From: Elijah Newren
>
> Hi Elijah,
>
> [Since this is leaving the topic of rename-detection in favour of
> leak-plugging, I'm shortening the cc-list a bit.]
>
>> So, instead, I'd like to see something like the below
>> (built on t
W dniu sob, 28.04.2018 o godzinie 16∶23 +0200, użytkownik Duy Nguyen
napisał:
> On Thu, Apr 26, 2018 at 4:46 PM, Michał Górny wrote:
> > For the record, we're using this with ebuilds and respective cache files
> > (which are expensive to generate). We are using separate repository
> > which combi
In this version I changed "+refs/tags/*:refs/remotes/tags/%s/*"
back to "+refs/tags/*:refs/remote-tags/%s/*" as Junio originally
suggested. This way don't have remotename collisions as Bryan
pointed out.
Since I don't like "--prefix-tags" I changed the option to
"--remote-tags" but obviously open
When --remote-tags is passed to `git remote add` the tagopt is set to
--remote-tags and a second fetch line is added so tags are placed in
a separate hierarchy per remote.
For example:
$ git remote add -f --remote-tags gbenchmark g...@github.com:google/benchmark
Updating gbenchmark
warning:
Derrick Stolee writes:
> The in_commit_list() method does not check the parents of
> the candidate for containment in the list. Fix the comment
> that incorrectly states that it does.
>
> Reported-by: Jakub Narebski
> Signed-off-by: Derrick Stolee
> ---
> ref-filter.c | 2 +-
> 1 file changed,
Derrick Stolee writes:
> As promised, here is the diff from v3.
What is this strange string " " in place of tabs in the interdiff?
" " here is Unicode Character 'NO-BREAK SPACE' (U+00A0).
Though it doesn't matter for viewing, my newsreader (Gnus from GNU
Emacs) thinks that it is worth not
On Fri, Apr 27, 2018 at 3:31 PM, Johannes Schindelin
wrote:
> In this developer's earlier attempt to accelerate interactive rebases by
> converting large parts from Unix shell script into portable, performant
> C, the --root handling was specifically excluded (to simplify the task a
> little bit;
On Fri, Apr 27, 2018 at 3:31 PM, Johannes Schindelin
wrote:
> When an interactive rebase wants to recreate a root commit, it
> - first creates a new, empty root commit,
> - checks it out,
> - converts the next `pick` command so that it amends the empty root
> commit
>
> Introduce support in the
On 04/27, Eric Sunshine wrote:
> On Tue, Apr 24, 2018 at 5:56 PM, Thomas Gummerer wrote:
> > Thanks Eric for the review and the suggestions on the previous round.
> >
> > Changes since the previous round:
> >
> > - UNLEAK new_branch after it was xstrndup'd
> > - update the commit message of 2/4 ac
Hi Johannes,
On Fri, Apr 27, 2018 at 3:30 PM, Johannes Schindelin
wrote:
> This patch extracts the code from is_index_unchanged() to initialize or
> update the index' cache tree (i.e. a tree object reflecting the current
> index' top-level tree).
>
> The new helper will be used in the upcoming co
Hi Philip,
On Sat, Apr 28, 2018 at 2:04 AM, Philip Oakley wrote:
> From: "Johannes Schindelin"
>>
>> The functionality is now implemented as `git replace
>> --convert-graft-file`.
>
>
> A rather late in the day thought: Should this go through the same
> deprecation dance?
I think contrib/ has o
Jakub Narebski writes:
> Junio C Hamano writes:
>> Derrick Stolee writes:
[...]
>>> +int compare_commits_by_gen_then_commit_date(const void *a_, const void
>>> *b_, void *unused)
>>> +{
>>> + const struct commit *a = a_, *b = b_;
>>> +
>>> + /* newer commits first */
>>> + if (a->generati
On Thu, Apr 26, 2018 at 4:46 PM, Michał Górny wrote:
> For the record, we're using this with ebuilds and respective cache files
> (which are expensive to generate). We are using separate repository
> which combines sources and cache files to keep the development
> repository clean. I have resear
Hi Philip,
On Sat, 28 Apr 2018, Philip Oakley wrote:
> From: "Johannes Schindelin"
> > The functionality is now implemented as `git replace
> > --convert-graft-file`.
>
> A rather late in the day thought: Should this go through the same
> deprecation dance?
>
> I.e. replace the body of the scr
Hi Gábor,
On Sat, 28 Apr 2018, SZEDER Gábor wrote:
> > diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
> > index c630aba657e..bed86a0af3d 100755
> > --- a/t/t6050-replace.sh
> > +++ b/t/t6050-replace.sh
> > @@ -444,4 +444,24 @@ test_expect_success GPG '--graft on a commit with a
> > mergeta
Hi Stefan,
On Fri, 27 Apr 2018, Stefan Beller wrote:
> On Fri, Apr 27, 2018 at 1:48 PM, Johannes Schindelin
> wrote:
> > During a series of fixup/squash commands, the interactive rebase builds
> > up a commit message with comments. This will be presented to the user in
> > the editor if at least
Hi,
On Sat, 28 Apr 2018, Philip Oakley wrote:
> From: "Jacob Keller"
> > On Fri, Apr 27, 2018 at 5:29 PM, Tang (US), Pik S
> > wrote:
> > > Hi,
> > >
> > > I discovered that I was able to delete the feature branch I was in, due
> > > to some fat fingering on my part and case insensitivity. I n
Hi Martin,
On Sat, 28 Apr 2018, Martin Ågren wrote:
> -->8--
> Subject: merge-recursive: provide pair of `unpack_trees_{start,finish}()`
>
> Rename `git_merge_trees()` to `unpack_trees_start()` and extract the
> call to `discard_index()` into a new function `unpack_trees_finish()`.
> As a result
Hi Colin,
On Tue, 6 Mar 2018, Colin Arnott wrote:
> On March 5, 2018 1:47 PM, Johannes Schindelin
> wrote:
>
> > As the credential-helper is already intended for sensitive data, and
> > as it already allows to interact with a helper, I would strongly
> > assume that it would make more sense to
Hi Larry,
On Tue, 6 Mar 2018, Larry Hunter wrote:
> The same ^M is shown in the output of tutorial
>
>
> https://www.geekality.net/2017/08/23/setting-up-gpg-signing-for-gitgithub-on-windows/
>
> at item "4. Verify commit was signed"
Please understand that it would be helpful if you coul
Hi Derek,
On Fri, 16 Feb 2018, Derek Foulk wrote:
> An issue has arisen sometime between 2.16.1.windows.1 and 2.16.1.windows.4 in
> Git.
>
> When you execute `git stash` commands (stash/pop/apply?), a sh.exe.stackdump
> file is generated that contains the following:
>
> Exception: STATUS_STAC
From: Elijah Newren
Hi Elijah,
[Since this is leaving the topic of rename-detection in favour of
leak-plugging, I'm shortening the cc-list a bit.]
> So, instead, I'd like to see something like the below
> (built on top of my series):
Thanks a lot. I now have the below patch in my tree as a pr
From: "Jacob Keller"
On Fri, Apr 27, 2018 at 5:29 PM, Tang (US), Pik S
wrote:
Hi,
I discovered that I was able to delete the feature branch I was in, due
to some fat fingering on my part and case insensitivity. I never
realized this could be done before. A quick google search did not give
m
From: "Johannes Schindelin"
The functionality is now implemented as `git replace
--convert-graft-file`.
A rather late in the day thought: Should this go through the same
deprecation dance?
I.e. replace the body of the script with the new `git
replace --convert-graft-file` and echo (or die!) a
On Fri, Apr 27, 2018 at 5:29 PM, Tang (US), Pik S wrote:
> Hi,
>
> I discovered that I was able to delete the feature branch I was in, due to
> some fat fingering on my part and case insensitivity. I never realized this
> could be done before. A quick google search did not give me a whole lot
On Fri, Apr 27, 2018 at 12:08 PM, Wink Saville wrote:
> On Thu, Apr 26, 2018 at 4:24 PM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>>
>> Hence (1) we should detect and error out when --prefix-tags is used
>> with mirror fetch near where we do the same for track used without
>> mirror fe
On Fri, Apr 27, 2018 at 5:24 PM, Elijah Newren wrote:
> I would expect that a different example involving non-linear history
> would behave the same, if both sides update the submodule in a fashion
> that is just fast-forwarding and one commit contains the other in its
> history. I'm curious if y
45 matches
Mail list logo
