Jeff King writes:
> From the user's perspective, calling X "rerere" would probably be OK[1].
> But from an implementation perspective (and to keep the existing
> plumbing available and unchanged), it probably makes sense to call it
> something else, and have it run both rerere and a new plumbing
lukaszgryglicki writes:
>>> +--signoff::
>>> + Add Signed-off-by line by the committer at the end of the commit
>>> + log message. The meaning of a signoff depends on the project,
>>> + but it typically certifies that committer has
>>> + the rights to submit this work under the same lice
Some projects require every commit, even merges, to be signed off [*1*].
Because "git merge" does not have a "--signoff"
option like "git commit" does, the user needs to add one
manually when the command presents an editor to describe the
merge, or later use "git commit --amend --signoff".
Help de
Jeff King writes:
> Hrm. That doesn't quite work, though. Because if your are the
> merge, then merging a topic to next will get an "A" that is a merge
> commit from next. But that commit will never end up in master. What's
> causing the conflict is really some "A" that is in the history between
26.07.2017 03:36, Jacob Keller пишет:
If your goal is to make it so users filling out bug reports have a
version, then using git descrsibe and making that be part of your
version (based off your tags, and commits) is how pretty much every
other project I've worked on does this.
I really don't th
Dear Partner,
Please consider this mail serious despite the fact that you did not
expect it. Hope you are doing well. I am Mr.Alimuji Gabratai, the
Manager of head opérations department of our bank in Burkina Faso. I
discovered a risk-free deal of US$9.9 million from my department which
was left u
I am a private Lender Daniel Jones located in USA, Are You In Need Of
A Private Or Business Loans from $5,000.00 to $10.000.000.00 At 2%
Rate For Various Purposes? If Yes; Contact us Via Email:
3231...@gmail.com
Names...
Amount($)...
Country
Tel...
Duration...
From: Phillip Wood
After resolving conflicts during a rebase it is a pain to have to run
'git add' before 'git rebase --continue'. Passing --autostage to 'git
rebase --continue' will stage them automatically so long as 'git diff
--check' says they are ok. This is a safety measure to avoid
acciden
From: Phillip Wood
If rebase --interactive is unable to commit staged changes because
HEAD has changed since rebase stopped the user gets different messages
depending on whether they specified --autostage or not. Update the
messages in the other code paths to match the --autostage one.
Signed-of
From: Phillip Wood
These patches add an '--autostage' option (and corresponding config
variable) to 'rebase --continue' that will stage any unstaged changes
before continuing. This saves the user having to type 'git add' before
running 'git rebase --continue'.
Phillip Wood (5):
rebase --contin
From: Phillip Wood
This enables the user to always specify --autostage with --continue
The tests check that setting rebase.continue.autostage=true results in
'git rebase --continue' autostaging unstaged changes and that
'--no-autostage' overrides it.
Signed-off-by: Phillip Wood
---
git-rebase
From: Phillip Wood
Make sure that --autostage stages any changes and fails if there are
merge markers in the file to be staged.
Signed-off-by: Phillip Wood
---
t/t3418-rebase-continue.sh | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/t/t
From: Phillip Wood
If HEAD has changed since the rebase stopped or rebase stopped due to
a failed exec then 'git rebase --continue --autostage' will autostage
changes that cannot be commited. Fix this by reordering some of the
checks so that 'git rebase --continue --autostage' never stages
change
Hello Jonathan Nieder,
Thanks for the reply!
Jonathan Nieder wrote:
>
> > The error message shown when a flag is found when expecting a
> > filename wasn't clear as it didn't communicate what was wrong
> > using the 'suitable' words in *all* cases.
> >
> > Correct case,
> >
> > $ git r
On Tue, Jul 25, 2017 at 06:34:56PM -0700, Jonathan Tan wrote:
> Remove the unused variable "heads" from cmd_fsck().
>
> This variable was made unused in commit c3271a0 ("fsck: do not fallback
> "git fsck " to "git fsck"", 2017-01-17).
Thanks, I should have caught this then.
The patch is obvious
Splitting a single sentence across multiple lines could
degrade readability. Further, long messages are likely
to be ignored by users.
Split the sentences and simplify it to improve their readability.
Signed-off-by: Kaartic Sivaraam
---
remote.c | 18 -
t/t2020-checkou
On Wed, Jul 26, 2017 at 11:40:46AM +0300, Stas Sergeev wrote:
> 26.07.2017 03:36, Jacob Keller пишет:
> > If your goal is to make it so users filling out bug reports have a
> > version, then using git descrsibe and making that be part of your
> > version (based off your tags, and commits) is how p
On 24/07/17 21:53, Junio C Hamano wrote:
Phillip Wood writes:
git rebase --continue requiring one to git add first confuses/annoys me
too. I started a patch to autostage unstaged changes if they don't
contain conflict markers a couple of weeks ago, I'll clean it up and
post it later this week.
26.07.2017 16:23, Jeff King пишет:
In git.git we do something like:
-- >8 --
other: version
cat $< >$@
.PHONY: FORCE
version: FORCE
@git rev-parse HEAD >$@+
@if cmp $@+ $@ >/dev/null 2>&1; then rm $@+; else mv $@+ $@; fi
-- >8 --
Yes, thats a nice recipe that I would be
On Fri, Jul 14, 2017 at 8:27 AM, Christian Couder
wrote:
> On Thu, Jul 13, 2017 at 10:55 PM, Jeff King wrote:
>> On Thu, Jul 13, 2017 at 08:57:01PM +0200, Christian Couder wrote:
>>
>>> >> We want to make it possible to store the parameters to the 'run'
>>> >> script in a config file. This will m
> On 21 Jul 2017, at 18:44, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>> To answer your question: I don't see an easy solution to the problem.
>
> That's OK. Thanks for digging.
>
> I am wondering if the attached would be acceptable as a minimum
> impact patch to address this issue
> On 25 Jul 2017, at 10:35, Johannes Schindelin
> wrote:
>
> When Git for Windows was still based on MSys1, we had no gettext, ergo
> no msgfmt, either. Therefore, we introduced a small and simple Tcl
> script to perform the same task.
>
> However, with MSys2, we no longer need that because we
> On 24 Jul 2017, at 23:38, Jonathan Tan wrote:
>
> Refactor, into a common function, the version and capability negotiation
> done when invoking a long-running process as a clean or smudge filter.
> This will be useful for other Git code that needs to interact similarly
> with a long-running pr
On Wed, Jul 26, 2017 at 05:58:09PM +0200, Christian Couder wrote:
> Actually after taking another look at that, it looks like the following
> happens:
>
> 1) the run script sources the original GIT-BUILD-OPTIONS file from
> ../.. relative to its location
> 2) a git version is built in "build/$re
Raman Gupta writes:
> Provide the user an option to overwrite existing resolutions using an
> `--overwrite` flag. This might be used, for example, if the user knows
> that they already have an entry in their rerere cache for a conflict,
> but wish to drop it and retrain based on the merge commit(
Lars Schneider writes:
> ... I started
> to work on a patch that moves all TravisCI logic into scripts located
> in the `ci` folder. These scripts share a `lib-travisci.sh` for common
> functions such as `skip_branch_tip_with_tag ()` executed at the
> beginning of every script.
>
> Does this s
Lars Schneider writes:
> Please note that I've recently refactored the capabilities negotiation a bit:
> https://github.com/git/git/commit/1514c8edd62d96006cd1de31e906ed5798dd4681
>
> This change is still cooking in `next`. I am not sure how this should/could
> be handled but maybe you can use my
Refactor, into a common function, the version and capability negotiation
done when invoking a long-running process as a clean or smudge filter.
This will be useful for other Git code that needs to interact similarly
with a long-running process.
As you can see in the change to t0021, this commit ch
Move the documentation for the sub-process API from a separate txt file
to its header file.
Signed-off-by: Jonathan Tan
---
Documentation/technical/api-sub-process.txt | 59 -
sub-process.h | 25 +++-
2 files changed, 23 insertion
Thanks for all your comments.
This is now built off "next" to include Lars's changes.
About whether this is too restrictive (for example, as Junio mentions,
this will not allow future capabilities of the form "key=???"), I think
that this can be upgraded later if necessary. For now, both the filt
Phillip Wood writes:
> From: Phillip Wood
>
> These patches add an '--autostage' option (and corresponding config
> variable) to 'rebase --continue' that will stage any unstaged changes
> before continuing. This saves the user having to type 'git add' before
> running 'git rebase --continue'.
I
Johannes Schindelin writes:
>> * wd/rebase-conflict-guide (2017-07-17) 1 commit
>> (merged to 'next' on 2017-07-20 at c78e758b23)
>> + rebase: make resolve message clearer for inexperienced users
>>
>> Code clean-up.
>
> This is not a code clean-up. It is an improvement of the user experienc
Remove hard coded sha1 values, obtain the values using
'git rev-parse HEAD' which should be future proof regardless
of the hash function used.
Additionally future-proof the test by hard coding the
abbreviation length of the hash.
Signed-off-by: Stefan Beller
---
> Don't hardcoded lengths of the
On 26/07/17 02:05 PM, Junio C Hamano wrote:
> I haven't tried this patch, but would this work well with options
> meant for the 'git rev-list --parents "$@"' that grabs the list of
> merge commits to learn from? e.g.
>
> $ contrib/rerere-train.sh -n 4 --merges master
> $ contrib/rerer
Provide the user an option to overwrite existing resolutions using an
`--overwrite` flag. This might be used, for example, if the user knows
that they already have an entry in their rerere cache for a conflict,
but wish to drop it and retrain based on the merge commit(s) passed to
the rerere-train
Stefan Beller writes:
> So I took a step back and wrote about different proposals where
> we want to go long term. See below. This will help us
> figuring out how to approach this bug correctly.
Thanks for writing this.
> RFC: A new type of symbolic refs
>
> A symbolic ref can currently only po
Jonathan Tan writes:
> Thanks for all your comments.
>
> This is now built off "next" to include Lars's changes.
>
> About whether this is too restrictive (for example, as Junio mentions,
> this will not allow future capabilities of the form "key=???"), I think
> that this can be upgraded later i
When a submodule diff should be displayed we currently just add the
submodule objects to the main object store and then e.g. walk the
revision graph and create a summary for that submodule.
It is possible that we are missing the submodule either completely or
partially, which we currently differen
Jonathan Nieder writes:
> For an initial guess: in the example
>
> git grep test -n
>
> ...
> 2. Focus on "argument" instead of "filename" so that the message
> could still apply: something like
>
> fatal: option '-n' must come before non-option arguments
I think this one is the
Stefan Beller writes:
> When a submodule diff should be displayed we currently just add the
> submodule objects to the main object store and then e.g. walk the
> revision graph and create a summary for that submodule.
>
> It is possible that we are missing the submodule either completely or
> par
Stefan Beller writes:
> Remove hard coded sha1 values, obtain the values using
> 'git rev-parse HEAD' which should be future proof regardless
> of the hash function used.
>
> Additionally future-proof the test by hard coding the
> abbreviation length of the hash.
>
> Signed-off-by: Stefan Beller
Raman Gupta writes:
> On 26/07/17 02:05 PM, Junio C Hamano wrote:
>> I haven't tried this patch, but would this work well with options
>> meant for the 'git rev-list --parents "$@"' that grabs the list of
>> merge commits to learn from? e.g.
>>
>> $ contrib/rerere-train.sh -n 4 --merges ma
On Wed, Jul 26, 2017 at 1:30 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> When a submodule diff should be displayed we currently just add the
>> submodule objects to the main object store and then e.g. walk the
>> revision graph and create a summary for that submodule.
>>
>> It is possi
Brandon Williams writes:
> Check for configuration parsing errors in '.gitmodules' in t7411, which
> is explicitly testing the submodule-config subsystem, instead of in
> t7400. Also explicitly use the test helper instead of relying on the
> gitmodules file from being read in status.
Makes sens
Stefan Beller writes:
> Rereading the archives, there was quite some discussion on the design
> of these patches, but these lines of code did not get any attention
>
> https://public-inbox.org/git/4cdb3063.5010...@web.de/
>
> I cc'd Jens in the hope of him having a good memory why he
> wrote
Stefan Beller writes:
> We _do_ show the submodule as demonstrated by the code sample above
> if we possess the objects.
> ...
>> That sounds like a very sensible and user-centric behaviour to me,
>> and "not initialized" sounds like the right message to give in such
>> a case (as opposed to "com
Stefan Beller writes:
> On Tue, Jul 25, 2017 at 2:39 PM, Brandon Williams wrote:
>> Commit aee9c7d65 (Submodules: Add the new "ignore" config option for
>> diff and status) ...
>
> introduced in 2010, so quite widely spread.
>
>> ... introduced the ignore configuration option for
>> submodules
Brandon Williams writes:
> Remove the last remaining caller of 'submodule_config()' as well as the
> function itself.
>
> With 'submodule_config()' being removed the submodule-config API can be
> a little simpler as callers don't need to worry about whether or not
> they need to overlay the repos
Junio C Hamano writes:
> Phillip Wood writes:
>
>> From: Phillip Wood
>>
>> These patches add an '--autostage' option (and corresponding config
>> variable) to 'rebase --continue' that will stage any unstaged changes
>> before continuing. This saves the user having to type 'git add' before
>> r
Junio C Hamano writes:
> Hmph, this is interesting.
>
> "git rebase" does take "--rerere-autoupdate" option from the command
> line, and propagates it to a later invocation of "rebase --continue"
> by storing the value to $state_dir/allow_rerere_autoupdate file and
> reading the value from it. $
Kaartic Sivaraam writes:
> b347d06bf09 (branch: deprecate --set-upstream and show help if we detect
> possible mistaken use,
> Thu Aug 30 19:23:13 2012)
>
> Is there any possibility for it to be removed some time in the near
> future?
>
> I'm asking this because IIRC, the 'attr_only
When using git-blame lots of lines contain redundant information, for
example in hunks that consist of multiple lines, the metadata (commit name,
author) are repeated. A reader may not be interested in those, so darken
(commit, author) information that is the same as in the previous line.
Choose a
On Mon, Jul 24, 2017 at 03:44:23PM -0700, Junio C Hamano wrote:
> A release candidate Git v2.14.0-rc1 is now available for testing
> at the usual places. It is comprised of 708 non-merge commits
> since v2.13.0, contributed by 61 people, 14 of which are new faces.
>
> The tarballs are found at:
>
Stefan Beller writes:
> When using git-blame lots of lines contain redundant information, for
> example in hunks that consist of multiple lines, the metadata (commit name,
> author) are repeated. A reader may not be interested in those, so darken
> (commit, author) information that is the same as
Teach fsck to not treat refs with missing targets as an error when
extensions.lazyobject is set.
For the purposes of warning about no default refs, such refs are still
treated as legitimate refs.
Signed-off-by: Jonathan Tan
---
builtin/fsck.c | 8
t/t0410-lazy-object.sh | 20 +
Currently, Git does not support repos with very large numbers of objects
or repos that wish to minimize manipulation of certain blobs (for
example, because they are very large) very well, even if the user
operates mostly on part of the repo, because Git is designed on the
assumption that every refe
This is an updated version of my previous patch [1], but without the
list of promises. It is somewhat different now because fsck cannot just
mark all promised objects as HAS_OBJ.
This could be adapted and incorporated into patch sets that have objects
missing from the local repo.
I split this up
Teach fsck to not treat missing objects provided on the CLI as an error
when extensions.lazyobject is set.
Signed-off-by: Jonathan Tan
---
builtin/fsck.c | 2 ++
t/t0410-lazy-object.sh | 16
2 files changed, 18 insertions(+)
diff --git a/builtin/fsck.c b/builtin/fsck.c
Teach fsck to not treat missing objects indirectly pointed to by refs as
an error when extensions.lazyobject is set.
Signed-off-by: Jonathan Tan
---
builtin/fsck.c | 11 +++
t/t0410-lazy-object.sh | 27 +++
2 files changed, 38 insertions(+)
diff --git a/b
One of the tricks that `contrib/workdir/git-new-workdir` plays is to
making `packed-refs` in the new workdir a symlink to the `packed-refs`
file in the original repository. Before
42dfa7ecef ("commit_packed_refs(): use a staging file separate from
the lockfile", 2017-06-23), a lockfile was used as
On Wed, Jul 26, 2017 at 04:29:58PM -0700, Jonathan Tan wrote:
> This is an updated version of my previous patch [1], but without the
> list of promises. It is somewhat different now because fsck cannot just
> mark all promised objects as HAS_OBJ.
>
> This could be adapted and incorporated into pat
I just submitted a patch [1] that fixes the `packed-refs`-is-a-symlink
problem in combination with git-new-workdir.
I haven't considered any possible problems related to
`core.preferSymlinkRefs`. That behavior should be unaffected by the
packed-ref-store patch series and I'm not very interested in
On Wed, Jul 26, 2017 at 4:29 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> When using git-blame lots of lines contain redundant information, for
>> example in hunks that consist of multiple lines, the metadata (commit name,
>> author) are repeated. A reader may not be interested in those
On Wed, Jul 26, 2017 at 4:39 PM, Michael Haggerty wrote:
> One of the tricks that `contrib/workdir/git-new-workdir` plays is to
> making `packed-refs` in the new workdir a symlink to the `packed-refs`
> file in the original repository. Before
> 42dfa7ecef ("commit_packed_refs(): use a staging file
Hi,
Michael Haggerty wrote:
> One of the tricks that `contrib/workdir/git-new-workdir` plays is to
> making `packed-refs` in the new workdir a symlink to the `packed-refs`
> file in the original repository. Before
> 42dfa7ecef ("commit_packed_refs(): use a staging file separate from
> the lockfil
Dang, I just noticed that I hit "reply" rather than "reply-to-all" on
the below email (stupid GMail default). Junio, your response to this
email accordingly went only to me.
Michael
-- Forwarded message --
From: Michael Haggerty
Date: Mon, Jul 10, 2017 at 7:52 AM
Subject: Re: Sho
On Wed, Jul 26, 2017 at 4:42 PM, brian m. carlson
wrote:
> On Wed, Jul 26, 2017 at 04:29:58PM -0700, Jonathan Tan wrote:
>> This is an updated version of my previous patch [1], but without the
>> list of promises. It is somewhat different now because fsck cannot just
>> mark all promised objects a
Heh, then I'll forward my response and we are even ;-)
-- Forwarded message --
From: Junio C Hamano
Date: Mon, Jul 10, 2017 at 10:48 AM
Subject: Re: Should "head" also work for "HEAD" on case-insensitive FS?
To: Michael Haggerty
Michael Haggerty writes:
> I think the most na
Since commit 612c49e94d ("credential-cache: add tests for XDG
functionality", 17-03-2017), the cygwin build has been failing all the
new tests added by that commit. In particular, the 'git credential-cache
exit' command, as part of the test cleanup code, has been die-ing with
the message:
fat
69 matches
Mail list logo
