On Fri, Aug 01, 2014 at 03:01:31PM -0700, Junio C Hamano wrote:
> * jk/stash-list-p (2014-07-30) 7 commits
> - SQUASH??? future-proof, log --cc should imply -p without being told
> - stash: show combined diff with "stash show"
> - stash: default listing to "--cc --simplify-combined-diff"
> - a
Hi,
with rust's git repo -- located at
https://github.com/rust-lang/rust.git -- we see odd results from
git-describe for the latest tag.
$ git rev-parse HEAD
795f6ae829ab1bfd72394a5da9096e2717ec0f62
$ git describe --debug
searching to describe HEAD
finished search at 7140d7c52bdf55daf0b978a1970
Junio C Hamano writes:
> Sergey Organov writes:
>
>> Previous description implicitly favored 'true' value for "pull.rebase"
>> and "pull..rebase" options,
>
> I do not share that impression. It is true that 'true' is described
> first before 'preserve', which can be argued that it is being
> imp
Jonathan Nieder writes:
> Hi Sergei,
>
> Sergei Organov wrote:
>
>> --C--
>> / \
>>/ M topic,HEAD
>> / /
>> A---B master
>>
>> shouldn't
>>
>> $ git rebase master
>>
>> be a no-op here?
> [...]
>> I'd expect --force-rebase to be required for this to happen:
>>
>> -f, -
Can I talk to you, I will be very glad if you permit me to talk to you for an
important deal.
Regards,
KM.
--
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
[Patch v8]: git_die_config now allows custom error messages.
new tests are now not too reliant on specific strings. Diff
between v7 & v8 is appended at the bottom. Thanks to Junio &
Matthieu for their suggestions.
[Patch v7]: style nit corrected. (1/8) is Matthieu's transla
Currently `git_config()` returns an integer signifying an error code.
During rewrites of the function most of the code was shifted to
`git_config_with_options()`. `git_config_with_options()` normally
returns positive values if its `config_source` parameter is set as NULL,
as most errors are fatal,
From: Matthieu Moy
If a callback returns a negative value to `git_config*()` family,
they call `die()` while printing the line number and the file name.
Currently the printed line number is off by one, thus printing the
wrong line number.
Make `linenr` point to the line we just parsed during the
Store file name and line number for each key-value pair in the cache
during parsing of the configuration files.
Signed-off-by: Tanay Abhra
---
cache.h | 5 +
config.c | 16 ++--
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index 7292aef..0b1
From: Matthieu Moy
Signed-off-by: Matthieu Moy
---
config.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/config.c b/config.c
index a191328..34940fd 100644
--- a/config.c
+++ b/config.c
@@ -457,9 +457,9 @@ static int git_parse_source(config_fn_t fn,
Add `git_die_config` that dies printing the line number and the file name
of the highest priority value for the configuration variable `key`. A custom
error message is also printed before dying, specified by the caller, which can
be skipped if `err` argument is set to NULL.
It has usage in non-cal
Of all the functions in `git_config*()` family, `git_config()` has the
most invocations in the whole code base. Each `git_config()` invocation
causes config file rereads which can be avoided using the config-set API.
Use the config-set API to rewrite `git_config()` to use the config caching
layer
Add tests for `git_config_get_string_const()`, check whether it
dies printing the line number and the file name if a NULL
value is retrieved for the given key.
Signed-off-by: Tanay Abhra
---
t/t1308-config-set.sh | 10 ++
test-config.c | 10 ++
2 files changed, 20 inserti
Semantic errors (for example, for alias.* variables NULL values are
not allowed) in configuration files cause a die printing the line
number and file name of the offending value.
Add a test documenting that such errors cause a die printing the
accurate line number and file name.
Signed-off-by: Ta
Running on Windows with latest version of Git. 1.9.4. Also had this trouble
with 1.8.2 but upgraded hoping it would fix the problem.
When I do a reset on several files, it says they were successfully reverted
they still show up as modified when I do a git status. In this case it's just a
newlin
On 8/5/2014 12:29 AM, Eric Sunshine wrote:
> On Mon, Aug 4, 2014 at 2:33 PM, Tanay Abhra wrote:
>> Use `git_config_get_bool()` family instead of `git_config()` to take
>> advantage of
>> the config-set API which provides a cleaner control flow.
>>
>> Signed-off-by: Tanay Abhra
>> ---
>> http-
On 23.07.2014 21:33, Sergei Organov wrote:
What actually bothers me is the unfortunate consequence that "git pull"
is not always a no-op when nothing was changed at the origin since the
last "git pull". THIS is really surprising and probably should better be
fixed. Requiring -f is just one (obvio
Tanay Abhra writes:
> --- a/cache.h
> +++ b/cache.h
> @@ -1406,8 +1406,14 @@ extern int git_config_get_bool(const char *key, int
> *dest);
[...]
> +struct key_value_info {
> + const char *filename;
> + int linenr;
> +};
[...]
> diff --git a/config.c b/config.c
> index cf9124f..427850a 10
Tanay Abhra writes:
> +test_expect_success 'find string value for a key' '
> + check_config get_string case.baz hask &&
> + check_config expect_code 1 get_string case.ba "Value not found for
> \"case.ba\""
> +'
> +
> +test_expect_success 'check line error when NULL string is queried' '
>
Holger Hellmuth writes:
> On 23.07.2014 21:33, Sergei Organov wrote:
>> What actually bothers me is the unfortunate consequence that "git pull"
>> is not always a no-op when nothing was changed at the origin since the
>> last "git pull". THIS is really surprising and probably should better be
>>
Philip Oakley wrote:
From: "Mike Stump"
Sent: Friday, August 01, 2014 11:24 PM
On Aug 1, 2014, at 12:01 PM, Jakub Narębski wrote:
It can work in Subversion because Subversion stores information about
what was merged in (and this includes cherry-picks, or whatever it is
named in svn) in svn:
On 8/6/2014 9:02 PM, Matthieu Moy wrote:
> Tanay Abhra writes:
>
>> +test_expect_success 'find string value for a key' '
>> +check_config get_string case.baz hask &&
>> +check_config expect_code 1 get_string case.ba "Value not found for
>> \"case.ba\""
>> +'
>> +
>> +test_expect_succes
On 06/08/14 15:53, Tanay Abhra wrote:
> Store file name and line number for each key-value pair in the cache
> during parsing of the configuration files.
>
> Signed-off-by: Tanay Abhra
> ---
> cache.h | 5 +
> config.c | 16 ++--
> 2 files changed, 19 insertions(+), 2 deletions
Tanay Abhra writes:
> On 8/5/2014 12:29 AM, Eric Sunshine wrote:
>> On Mon, Aug 4, 2014 at 2:33 PM, Tanay Abhra wrote:
>>> - if (skip_prefix(var, "http.", &p)) {
>>> - int i;
>>> -
>>> - for (i = 0; i < ARRAY_SIZE(rpc_service); i++) {
>>> -
W dniu 2014-08-06 17:04, Jared Brank pisze:
Running on Windows with latest version of Git. 1.9.4. Also had this
trouble with 1.8.2 but upgraded hoping it would fix the problem.
When I do a reset on several files, it says they were successfully
reverted they still show up as modified when I do a
W dniu 2014-08-01 22:55, Nico Williams pisze:
On Fri, Aug 1, 2014 at 3:50 PM, Jonathan Nieder wrote:
Jonathan Nieder wrote:
Do you mean that "git merge" should be aware of what changes you have
already cherry-picked?
It isn't, and that's deliberate
That said, when today's "git merge" fails
On Wed, Aug 6, 2014 at 10:58 AM, Jakub Narębski wrote:
> W dniu 2014-08-01 22:55, Nico Williams pisze:
>> It would help if cherry-pick history where recorded somewhere (beyond
>> the reflog)...
>>
>> Cherry-picks should record two parents, like merges.
>>
>> (Of course, it does no good to know abo
Jeff King writes:
> On Fri, Aug 01, 2014 at 03:01:31PM -0700, Junio C Hamano wrote:
>
>> * jk/stash-list-p (2014-07-30) 7 commits
>> - SQUASH??? future-proof, log --cc should imply -p without being told
>> - stash: show combined diff with "stash show"
>> - stash: default listing to "--cc --sim
Is this even possible? The .gitmodule file has to be at the root of
the repository, AFAIK. So if the subtree is inherently not at the
root, how does it manage its own submodules?
Basically I have a common library that also keeps a submodule of third
party dependencies (binaries). Each super projec
Linus Arver writes:
> No, the unindenting/removal of blank lines is a non-grammar change and
> is not necessary, as it doesn't have any effect on the actual output
> (html/txt/manpage).
>
> I can either keep the same coding style with the rewording, or chop this
> into two commits, one for the re
Bug v1.9.3: Spurious whitespace warnings when using git apply with the
--exclude option
REPRO STEPS:
1. Create a patch PATCH that modifies two files, A and B. Make sure the
modifications to file A add whitespace errors and the modifications to file B
do not.
2. Apply that patch to a repo using
Linus Arver writes:
> On Tue, Aug 05, 2014 at 03:12:21PM -0700, Junio C Hamano wrote:
>> Linus Arver writes:
>>
>> > Signed-off-by: Linus Arver
>> > ---
>>
>> You would need to work on your justification skills ;-) in the log
>> message. What does this change "clarify" and in what way?
>
> O
Linus Arver writes:
> On Tue, Aug 05, 2014 at 03:14:48PM -0700, Junio C Hamano wrote:
>> Linus Arver writes:
>>
>> > Signed-off-by: Linus Arver
>> > ---
>> > Documentation/git-init.txt | 6 --
>> > 1 file changed, 4 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/Documentation/git-in
Robert Dailey writes:
> Is this even possible? The .gitmodule file has to be at the root of
> the repository, AFAIK. So if the subtree is inherently not at the
> root, how does it manage its own submodules?
>
> Basically I have a common library that also keeps a submodule of third
> party depende
Hello,
I ran git on my newly-set-up OS X Mavericks machine, and get:
$ git
Agreeing to the Xcode/iOS license requires admin privileges,
please re-run as root via sudo.
Running 'git --verision' gives the same result. This seems
problematic in a few ways, and I am wondering if th
On Wed, Aug 6, 2014 at 12:51 PM, Junio C Hamano wrote:
> My knee-jerk reaction would be "subtree would break submodules
> badly, don't use it" ;-).
>
> After all, I invented subtree merge as an ugly interim workaround
> before submodule subsystem got into a usable shape, hoping that new
> projects
On Wed, Aug 6, 2014 at 6:26 PM, Nico Williams wrote:
> On Wed, Aug 6, 2014 at 10:58 AM, Jakub Narębski wrote:
>> W dniu 2014-08-01 22:55, Nico Williams pisze:
>>>
>>> It would help if cherry-pick history where recorded somewhere (beyond
>>> the reflog)...
>>>
>>> Cherry-picks should record two pa
On Wed, Aug 06, 2014 at 02:10:08PM -0400, Robert P Fischer wrote:
>
> 3. The version of git I ran is clearly NOT a plain vanilla "official"
> git, it is a derivative work. Has Apple provided the source code of
> the special version that I just ran? If not, that would seem to be a
> violation of
On Aug 6, 2014, at 8:43 AM, Jakub Narębski wrote:
>>> I gave a solution for git using branches and it works just fine. It
>>> retains the simple 3-point merge as well.
>
> It works for this simple case, but I think it has unfortunate potential
> to go silently wrong.
That just means that you wa
On Wed, Aug 06, 2014 at 10:12:25AM -0700, Junio C Hamano wrote:
> > I think we want to drop the "stash show" patch, based on the discussion
> > we had. The first three patches are nominally prep for that final
> > patch, but actually are things I've often wanted over the years. I'd be
> > glad if
On Wed, Aug 06, 2014 at 02:10:08PM -0400, Robert P Fischer wrote:
> I ran git on my newly-set-up OS X Mavericks machine, and get:
>
> $ git
> Agreeing to the Xcode/iOS license requires admin privileges,
> please re-run as root via sudo.
>
> Running 'git --verision' gives the sam
The number of loose objects at which git-gui shows a gc warning has
historically been hardcoded to ~2000, or ~200 on Windows. The warning can
only be disabled completely via gui.gcwarning=false.
Especially on Windows, the hardcoded threshold is so ridiculously low that
git-gui often complains even
Am 05.08.2014 20:47, schrieb Jeff King:
> On Mon, Aug 04, 2014 at 09:19:46PM +0200, Karsten Blees wrote:
>
>> Hmm, I wonder if it wouldn't be simpler to read / write the desired on-disk
>> structure directly, without copying to a uchar[6] first.
>
> Probably. My initial attempt was to keep togeth
On Aug 1, 2014, at 4:40 PM, Nico Williams wrote:
> As for rebase, I still don't understand why it doesn't work for you.
http://git-scm.com/docs/git-rebase says:
Rebasing (or any other form of rewriting) a branch that others have based
work on is a bad idea
If you read stack-overflow, you wil
Karsten Blees writes:
> Am 05.08.2014 20:47, schrieb Jeff King:
>> On Mon, Aug 04, 2014 at 09:19:46PM +0200, Karsten Blees wrote:
>>
>>> Hmm, I wonder if it wouldn't be simpler to read / write the desired on-disk
>>> structure directly, without copying to a uchar[6] first.
>>
>> Probably. My in
On Wed, Aug 06, 2014 at 12:11:16PM -0700, Mike Stump wrote:
> On Aug 1, 2014, at 4:40 PM, Nico Williams wrote:
> > As for rebase, I still don't understand why it doesn't work for you.
>
> http://git-scm.com/docs/git-rebase says:
>
> Rebasing (or any other form of rewriting) a branch that other
On Wed, Aug 6, 2014 at 11:44 AM, Matthieu Moy
wrote:
> Tanay Abhra writes:
>
>> On 8/5/2014 12:29 AM, Eric Sunshine wrote:
>>> On Mon, Aug 4, 2014 at 2:33 PM, Tanay Abhra wrote:
- if (skip_prefix(var, "http.", &p)) {
- int i;
-
- for (i = 0;
On Wed, Aug 06, 2014 at 08:31:18PM +0200, Jakub Narębski wrote:
> On Wed, Aug 6, 2014 at 6:26 PM, Nico Williams wrote:
> > My proposal was to put this sort of ancillary history info in a
> > "branch object" (and that branches should be objects). This would
> > have a number of benefits, not the l
Peyton Randolph writes:
> Bug v1.9.3: Spurious whitespace warnings when using git apply with the
> --exclude option
> ...
> EXPECTED RESULT:
> No warning about adding whitespace errors because no whitespace
> errors are added to the tree since A is excluded and B has no
> whitespace errors.
By
On Wed, Aug 06, 2014 at 02:44:59PM -0500, Nico Williams wrote:
> That means that you have/maintain an intermediate upstream, yes?
>
> This is a bit trickier since once in a while that intermediate upstream
> and everyone downstream of it has to catch up with the real upstream.
>
> Here you have t
Am 06.08.2014 um 20:18 schrieb Robert Dailey:
> On Wed, Aug 6, 2014 at 12:51 PM, Junio C Hamano wrote:
>> My knee-jerk reaction would be "subtree would break submodules
>> badly, don't use it" ;-).
>>
>> After all, I invented subtree merge as an ugly interim workaround
>> before submodule subsyste
On 08/06/2014 11:43 AM, Jeff King wrote:
snippage here 8< >8
As it happens, though, they _do_ modify the git that they distribute. I know at least that they bake-in the osxkeychain helper config in away that the user cannot turn off. There
may be more changes, but I haven't done a full diff. And
> Also, minor nit, but git is GPL, not LGPL.
But Apple put a LGPL license in side the folder. See:
https://www.opensource.apple.com/source/Git/Git-48/src/git/LGPL-2.1
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majord
On Wed, Aug 06, 2014 at 01:23:00PM -0700, Tony wrote:
> > Also, minor nit, but git is GPL, not LGPL.
>
> But Apple put a LGPL license in side the folder. See:
> https://www.opensource.apple.com/source/Git/Git-48/src/git/LGPL-2.1
Interesting. It starts with:
While most of this project is under
On Wed, Aug 06, 2014 at 12:53:56PM -0700, Bruce Ferrell wrote:
> On 08/06/2014 11:43 AM, Jeff King wrote:
>
> snippage here 8< >8
> >As it happens, though, they _do_ modify the git that they distribute. I
> >know at least that they bake-in the osxkeychain helper config in away that
> >the user ca
Matthieu Moy writes:
> Tanay Abhra writes:
>
>> ...
>> +grep "line 7.*.git/config\|.git/config.*line 7" result
>> +'
>
> This is still dependant on the locale ("line" is translated). You need
> to use test_i18ngrep instead of grep here (see its definition and
> comment in t/test-lib.sh).
>
>
On Mon, Aug 04, 2014 at 08:51:42PM +0200, Fabian Ruch wrote:
> > though I would also not be opposed to some more uniform hook selection
> > mechanism (e.g., "--no-verify=pre-commit" or something).
>
> While the --no-verify= mechanism doesn't add a new option to the
> git-commit interface but lets
On Mon, Aug 04, 2014 at 11:21:41PM +0200, Fabian Ruch wrote:
> Thanks for laying out the differences in the user visible output. With
> stock git we are seeing summaries for other commits, but not root
> commits, _with the --verbose option_. It's the fault of my patch to show
> the summary even in
Jens Lehmann wrote:
> There were thoughts about having "git branch" optionally create a
> branch in the submodule too. But in a lot of real world scenarios
> that won't help because the same branch name won't necessarily make
> sense in superproject and submodule at the same time
So, here is how
This started as an attempt to fix a long-time bug, in which a
partial "git apply" with --exclude/--include still complained about
whitespace breakage in a part that was excluded from patch
application. The final patch fixes it.
Restructuring of the code necessary to fix it revealing another
long-
We will be adding a caller to the function a bit earlier in this
file in a later patch.
Signed-off-by: Junio C Hamano
---
builtin/apply.c | 81 ++---
1 file changed, 43 insertions(+), 38 deletions(-)
diff --git a/builtin/apply.c b/builtin/appl
We parse each patchfile and find to what path it applies to and then
use that name to consult the attribute system to find what
whitespace rules to be applied, and also which target file (either
in the working tree or in the index) to replay the changes the patch
represents.
A non-Git patch is tak
Whitespace breakages are checked while the patch is being parsed.
Disable them at the beginning of parse_chunk(), where each
individual patch is parsed, immediately after we learn what path the
patch applies to and before we start parsing the changes.
One may naively think we should be able to not
Jakub Narębski writes:
> There was (long time ago) a long thread about idea of adding some
> kind of 'weak' references (links), 'weakparent' that can be
> automatically used by Git but do not pollute the commit message,
> and do not affect reachability calculations. Ultimately it went
> nowhere
Junio C Hamano writes:
> Jakub Narębski writes:
>
>> There was (long time ago) a long thread about idea of adding some
>> kind of 'weak' references (links), 'weakparent' that can be
>> automatically used by Git but do not pollute the commit message,
>> and do not affect reachability calculations
Jonathan Nieder writes:
> 2. Submodules aware of their superproject and of the parent's branches.
> In other words, submodules would act as thought under refs/ they
> had a symlink
>
> parent -> ../../../refs
>
> So you could do
>
> git checkout --recurse-submodules maste
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> 2. Submodules aware of their superproject and of the parent's branches.
>> In other words, submodules would act as though under refs/ they
>> had a symlink
>>
>> parent -> ../../../refs
>>
>> So you could do
>>
>> git check
Hi List,
this is the second reroll of the patch series fixing corner-case bugs
regarding empty commits, commits with no log message and root
commits, providing a uniform implementation of the to-do list
commands using the `do_pick` interface.
This reroll includes the following list of changes to
git-rebase--interactive handles empty log messages inconsistently
between enabled and disabled fast-forwards. By default, commits with
empty log messages are rebased successfully like in non-interactive
mode. In contrast, the `--no-ff` option aborts the replay of such
commits.
In line with not ver
The to-do list commands `squash` and `fixup` apply the changes
introduced by the named commit to the tree but instead of creating
a new commit on top of the current head it replaces the previous
commit with a new commit that records the updated tree. If the
result is an empty commit git-rebase stop
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. If `--keep-empty` is
passed as option to git-rebase--interactive, empty commits ought to
be replayed without complaints. However, if the users chooses to
reword an empty commit by chan
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. If the edited log
message is empty or is found ill-formatted by one of the commit
hooks, git-rebase--interactive prints three error messages to the
console.
1. The git-commit outp
git-rebase--interactive prints summary messages of the commits it
creates in the final history only if the `--verbose` option is
specified by the user and suppresses them otherwise. This behaviour
is implemented by wrapping git-commit calls in a shell function named
`output` which redirects stderr
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. This happens in two
steps. Firstly, the named commit is cherry-picked. Secondly, the
commit created in the first step is amended using an unchanged index
to edit the log message. The p
Introduce the git-commit command line options `--no-pre-commit` and
`--no-commit-msg` to disable the pre-commit and commit-msg hooks,
respectively. Make `--no-verify` a synonym for specifying both at the
same time.
This change is motivated by an internal usage of git-commit in
git-rebase--interact
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement the to-do list command `pick`. To cater for
the different pick behaviours (like `reword`), `do_pick` accepts
several options not only from the git-cherry-pick but also the
git-commit interface. Add the com
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement the to-do list commands `pick`, `reword`
and `edit`. To cater for the different pick behaviours (like
`squash`), `do_pick` accepts several options not only from the
git-cherry-pick but also the git-commit
Read in to-do list lines as
command args
instead of
command sha1 rest
so that to-do list command lines can specify additional arguments
apart from the commit hash and the log message title, which become
the non-options in `args`. Loop over `args`, put all options (an
argument beginning
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement the to-do list command `pick`, `reword` and
`edit`. To cater for the different pick behaviours (like `squash`),
`do_pick` accepts several options not only from the git-cherry-pick
but also the git-commit i
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement many of the to-do list commands.
Eventually, the complete `do_pick` interface will be exposed to the
user in some form or another and those commands will become simple
aliases for the `do_pick` options now
The command line used to recreate root commits specifies the option
`-q` which suppresses the commit summary message. However,
git-rebase--interactive tends to tell the user about the commits it
creates in the final history, if she wishes (cf. command line option
`--verbose`). The code parts handli
Rewrite `squash` and `fixup` handling in `do_next` using the sequence
pick_one
commit
in order to test the correctness of a single `do_squash` or
parameterised `do_pick` and make the subsequent patch reimplementing
`squash` in terms of such a single function more readable.
Do not call `r
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is currently used to implement most of the to-do list commands
and offers additional options that will eventually find their way
onto to-do lists.
To extend the repertoire of available options, add the git-commit and
git-cher
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. If one thinks of `pick`
entries as scheduled `cherry-pick` command lines, then `reword`
becomes an alias for the command line `cherry-pick --edit`. The
porcelain `rebase--interactive`
The command line used to recreate root commits uses `-C` to suppress
the log message editor. This is unnecessarily confusing, though,
because that suppression is a secondary effect of the option. The
main purpose of `-C` is to pull the metadata from another commit, but
here we know that this is a n
Using the to-do list command `squash` the user can specify two or
more commits and git-rebase creates one commit that introduces all
their changes combined. The authorship for the created commit is
taken from the first commit specified and the user can edit the log
message. There is a variant of `s
Since `do_pick` might be executed in a sub-shell (a modified author
environment for instance), calling `die` in `do_pick` has no effect
but exiting the sub-shell with a failure exit status. The
git-rebase--interactive script is not terminated. Moreover, if
`do_pick` is called while a squash or fixu
There are two kinds of to-do list commands available. One kind
replays a commit (`pick`, `reword`, `edit`, `squash` and `fixup` that
is) and the other executes a shell command (`exec`). We will call the
first kind replay commands.
The two kinds of tasks are scheduled using different line formats.
The options passed to `do_pick` determine whether the picked commit
will be rewritten or not. If the commit gets rewritten, because the
user requested to edit the commit message for instance, let
`pick_one` merely apply the changes introduced by the commit and do
not commit the resulting tree yet.
The to-do list command `squash` and its close relative `fixup` replay
the changes of a commit like `pick` but do not recreate the commit.
Instead they replace the previous commit with a new commit that also
introduces the changes of the squashed commit. This is roughly like
cherry-picking without c
pick and reword are atomic to-do list commands in the sense that they
open a new task which is closed after the respective command is
completed. squash and fixup are not atomic. They create a new task
which is not completed until the last squash or fixup is processed.
Lift the general unknown opti
Hi Jeff,
Jeff King writes:
> On Tue, Jul 29, 2014 at 01:18:09AM +0200, Fabian Ruch wrote:
>> The options passed to `do_pick` determine whether the picked commit
>> will be rewritten or not. If the commit gets rewritten, because the
>> user requested to edit the commit message for instance, let
>>
On Thu, Aug 7, 2014 at 7:34 AM, Jonathan Nieder wrote:
> Package: git
> Version: 1:2.0.0-1
> Tags: upstream
>
> $ git init foo
> Initialized empty Git repository in /tmp/t/foo/.git/
> $ cd foo
> $ echo hi >README
> $ git add -N README
> $ git status
> On branch master
>
> Initial c
I tried using escaped globs with git mv, but globs don't seem to be
expanded with git mv.
So, for example, I've got files file1 & file2, and have been editing
them, so I've got file1~ and file2~ also, and *~ is in .gitignore.
If I do:
$ mkdir newdir
$ git mv file* newdir
I get a 'fatal: not in
On Thu, Aug 7, 2014 at 8:52 AM, Alan Grover wrote:
> Since we can do git add file\*, I tried:
>
> $ git mv file\* newdir
>
> I get a 'bad source, source=file* destination=file*' error. It seems
> to be looking for a file named 'file*' rather than performing glob
> expansion.
This is a known probl
On Wed, Aug 06, 2014 at 05:38:43PM -0700, Mike Stump wrote:
> Oh, wait, maybe I have misunderstood the prohibition. I have:
>
>upstream <—— fsf
>|
> \
> |
> v
> Me <—> master <—> coworker.
This looks a lot like what I meant about pro
96 matches
Mail list logo