Automating git add & commit for every change individually?

[git . 20 . BrowserUk]

Hi, 

Not sure this is the right place; I couldn't find a mailing list specifically 
for git *users*?

Problem: Given two source trees, neither yet under source control. One 
(hereafter:MOD)containing extensive modifications of the other 
(hereafter:ORIG), I want to bring these together under source control such that 
I can, starting with the full MOD version, back out (and subsequently 
reinstate) changes individually.

And I mean individually at the 'group of lines' level; not the 'whole file' 
level.

Reason. The ORIG does not compile locally due to dependency on proprietary 
libraries I do not have access to. The MOD compiles locally and runs; but I 
have introduced an error that means it produces the wrong results. 

None of the changes required to remove the dependence on the proprietary 
libraries should have affected the functionality. Obviously, I must have 
touched something that wasn't required to achieve the local compile.

Some of those 'incidental' changes are obvious: the original source files 
contain some tabs; my editor is set to replace tabs with spaces. This shouldn't 
affect anything, but shows up in diffs. Some changes are habitual: manually 
adjusting whitespace and comments when trying to understand particular sections 
of code. Some are changes I made trying to achieve the compile -- addressing 
warnings like "Information may be lost." -- that probably weren't ultimately 
required to achieve the compile. These *could* affect the results produced.

Suggested solution:: Put the ORIG into git (init/add ./commit -am "Original"). 
Copy the modified subtree over the original. Add & Commit the changes in chunks.

Problem: It doesn't allow me to back out the changes individually; only commit 
sized chunks.

Suggested solution:: use git add -p to stage individual changes; and then 
commit it. Rinse & repeat.

Problem:This is extremely laborious and error prone.
Ie. If I do git -p; {spews 377 lines of diff}; Do you want to stage this hunk. 
I accept: 'Y'; now that hunk is staged; but not committed. So, I have to quit 
out of git -p; then git commit -m {make up some reason} repeat for the next 
4000 changes.

Question 1:: Is there any way to automate the staging & committing of all 
existing changes as individual commits? Preferably with auto-generated commit 
messages.

Question 2:: Is there some other way get both versions into git such that I am 
to be able to 'undo' individual changes to the MOD version, try the build & 
test; and then redo the undone change if it wasn't the one that screwed things 
up?

Thanks, Buk


Can't remember your password? Do you need a strong and secure password?
Use Password manager! It stores your passwords & protects your account.
Check it out at http://mysecurelogon.com/manager



--
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

Re: Git log three-dot notation: include merge base

[Robert Dailey]

On Sat, May 14, 2016 at 6:30 PM, Junio C Hamano  wrote:
> Robert Dailey  writes:
>
>> This is because the merge base commit isn't shown. I understand this
>> is "by-design", but is there a way to include it? It's necessary to
>> have it, for this graph to make sense.
>
> --boundary, perhaps?

Big thanks to both you and Jeff. I figured there was some option for
this, but I always have trouble finding what I need in the
documentation sea of git log :-)

This worked perfectly. Much appreciated!!!
--
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

Re: Git log three-dot notation: include merge base

[Junio C Hamano]

Robert Dailey  writes:

> This is because the merge base commit isn't shown. I understand this
> is "by-design", but is there a way to include it? It's necessary to
> have it, for this graph to make sense.

--boundary, perhaps?
--
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

Re: Git log three-dot notation: include merge base

[Jeff King]

On Sat, May 14, 2016 at 06:09:21PM -0500, Robert Dailey wrote:

> Using A...B notation, I get this:
> 
> $ git log --oneline --decorate --graph A...B
> * eb28ae4 (HEAD -> B) Commit 6
> * 7173fa1 Commit 5
> * b5fe27b Commit 4
> * 37a8ca8 (A) Commit 3
> * 72745a7 Commit 2
> 
> The graph no longer makes any sense, and isn't helpful to me at all.
> This is because the merge base commit isn't shown. I understand this
> is "by-design", but is there a way to include it? It's necessary to
> have it, for this graph to make sense.

Try "--boundary".

-Peff
--
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

Git log three-dot notation: include merge base

[Robert Dailey]

If you consider a simple case where I run the following command:

$ git log --oneline --graph --decorate A...B

Where A and B are both branches with a single merge base and a series
of commits on each branch. Very simple example with no loops or crazy
ancestry. Below is an example repo I set up, where I show the whole
repository log graph:

$ git log --oneline --decorate --graph --all
* eb28ae4 (HEAD -> B) Commit 6
* 7173fa1 Commit 5
* b5fe27b Commit 4
| * 37a8ca8 (A) Commit 3
| * 72745a7 Commit 2
|/
* ffc8040 Commit 1

Using A...B notation, I get this:

$ git log --oneline --decorate --graph A...B
* eb28ae4 (HEAD -> B) Commit 6
* 7173fa1 Commit 5
* b5fe27b Commit 4
* 37a8ca8 (A) Commit 3
* 72745a7 Commit 2

The graph no longer makes any sense, and isn't helpful to me at all.
This is because the merge base commit isn't shown. I understand this
is "by-design", but is there a way to include it? It's necessary to
have it, for this graph to make sense.
--
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

Re: [PATCH 3/6] t9107: use "return 1" instead of "exit 1"

[Jeff King]

On Sat, May 14, 2016 at 10:37:07AM -0700, Junio C Hamano wrote:

> Thanks for sharp eyes.  Let's squash this in, perhaps?
> 
>  t/t9107-git-svn-migrate.sh | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/t/t9107-git-svn-migrate.sh b/t/t9107-git-svn-migrate.sh
> index 2908aef..b6a99b8 100755
> --- a/t/t9107-git-svn-migrate.sh
> +++ b/t/t9107-git-svn-migrate.sh
> @@ -80,12 +80,12 @@ test_expect_success 'multi-fetch works on partial urls + 
> paths' '
>   git rev-parse --verify refs/remotes/origin/$i^0 || return 1;
>   done >refs.out &&
>   test -z "$(sort  - >expect &&
>   for i in $refs
>   do
>   for j in $refs
>   do
> - git diff --exit-code refs/remotes/origin/$i 
> refs/remotes/origin/$j ||
> + git diff --exit-code refs/remotes/origin/$i \
> +  refs/remotes/origin/$j ||
>   return 1
>   done
>   done

Yeah, that looks perfect. Thanks.

-Peff
--
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

Re: [PATCH v2 00/94] libify apply and use lib in am

[Christian Couder]

On Sat, May 14, 2016 at 8:31 PM, Junio C Hamano  wrote:
>
> I however do not see a reason why you need to expose that feature to
> the users of "git apply".  So I am not sure if any of us care deeply
> the choice among --silent, --quiet and -q -q.

About that I wrote in initial email above:

"The last patch 94/94 adds a --silent command line option to git apply.
This is not necessary, but some scripts could perhaps use it, and it
could make it easier to test the new silent feature."

I expose the feature in the last patch exactly because, if we don't
want to expose the feature, is is easy to do by just dropping the last
patch.
And I explain the reasons why it might be a good idea to expose the
feature, but I am also ok with just dropping the patch.
--
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

Re: [PATCH 5/5] pathspec: record labels

[Junio C Hamano]

Stefan Beller  writes:

> Labels were originally designed to manage large amount of
> submodules, the discussion steered this in a more general
> direction, such that other files can be labeled as well.

s/other files/any path/.

> Labels are meant to describe arbitrary set of files, which
> is not described via the tree layout.

Let's avoid "are meant to", which is merely to give you an excuse to
say "it was meant to ... but the implementation did not quite achieve
that goal".

The "label" attribute can be attached to paths, and the pathspec
mechanism is extended via the new ":(label=X)pattern/to/match"
syntax to filter paths so that it requires paths to not just
match the given pattern but also have the specified labels
attached for them to be chosen.

or something?

> +Attaching labels to path
> +
> +
> +`label`
> +^^
> +By the value of this attribute you can specify a list of arbitrary strings
> +to be attached to a path as labels. These labels can be used for
> +easier paths matching using pathspecs (linkgit:gitglossary[1]).
> +It is recommended to use only alphanumeric characters, dashes and
> +underscores for the labels.

Make this recomendation stronger to requirement.  It is always
possible to loosen it later, but once we allow random things even
with a warning, it gets impossible to take them back. Users will say
"Even though we got a warning, it used to correctly filter; now Git
is broken and my setup does not work."

> diff --git a/Documentation/glossary-content.txt 
> b/Documentation/glossary-content.txt
> index 8ad29e6..f990017 100644
> --- a/Documentation/glossary-content.txt
> +++ b/Documentation/glossary-content.txt
> @@ -384,6 +384,10 @@ full pathname may have special meaning:
>  +
>  Glob magic is incompatible with literal magic.
>  
> +label:;;
> + Additionally to matching the pathspec, the path must habe a 'label'
> + attribute having set all labels listed here.

s/habe/have/

> + if (ATTR_TRUE(check.value))
> + ret = 1; /* has all the labels */

So this is "pretend that I have all the labels under the sun".

> + else if (ATTR_FALSE(check.value))
> + ret = 0; /* has no labels */

I do not see a value in this.  What difference does it have compared
to having a "label=" that explicitly says "I do not have one"?  What
is your answer to an end-user question "When should I say 'label='
and when should I say '!label'?"

Just forbid it for now; we may find a better use for it later.

> + else if (ATTR_UNSET(check.value))
> + /*
> +  * If no label was specified this matches, otherwise
> +  * there is a missing label.
> +  */
> + ret = (required_labels->nr > 0) ? 0 : 1;

Hmm, I can see that this is making things more complicated to
explain and understand, but I cannot see what the expected use case
is.

Unless there is any compelling use case, I'd say we should forbid it
for now.

> + else {
> + struct string_list_item *si;
> + struct string_list attr_labels = STRING_LIST_INIT_DUP;
> + string_list_split(_labels, check.value, ',', -1);
> + string_list_sort(_labels);

Filter out a non-compliant label values here, so that they are
ignored from day one.  That way you would not have to deal with "I
know I got the warning, but it used to work and you broke it" later.

> + ret = 1;
> + for_each_string_list_item(si, required_labels) {
> + if (!string_list_has_string(_labels, si->string)) {
> + ret = 0;
> + break;
> + }
> + }
> + string_list_clear(_labels, 0);
> + }
> +
> + return ret;
> +}

> +static void validate_label_name(const char *label)
> +{
> + if (check_valid_label_name(label))
> + warning(_("Label '%s' discouraged. Recommended label names 
> start "
> + "with an alphabetic character and use only alphanumeric 
> "
> + "characters, dashes and underscores."), label);
> +}

Instead of returning void, parrot the return value from
check_valid_label_name().

> + /* The label token may have no argument, so no trailing ':' */

Why close the door for future pathspec magic "labelfoo" by being
unnecessarily[*1*] lenient?

[*1*] Does ":(label)" mean anything useful, and is there a good
  reason why it should behave differently from ":(label:)"?

Unless there is a good reason why users would want ":(label)", I'd
say we should make it a syntax error.

> + if (skip_prefix(copyfrom, "label", )) {
> + struct strbuf sb = STRBUF_INIT;
> + skip_prefix(body, ":", );
> + strbuf_add(, body, nextat - body);
> + if (!item->labels) {
> + 

Re: Empty config sections are neither deleted nor reused

[Jonas Bernoulli]

Junio C Hamano  writes:

> Matthieu Moy  writes:
>
>> Junio's explanation must not necessarily be read as "it has to be the
>> way it is", but more as "getting it right is harder than you think", and
>> that in turn explains why no one changed the behavior.
>
> Thanks for clarification.  s/must not necessarily/must not/;

That's how I read it too ;-)

Apparently my reply left more room for interpretation.
--
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

Re: [PATCH] crlf: Add test showing double warning on commit

[Junio C Hamano]

Torsten Bögershausen  writes:

> Do we need to run diff_populate_filespec() twice when src==dst ?

Of course we do.

src and dst may have the same path, but are coming from different
places (src may be an indexed blob while dst may be a file in the
working tree).

> If yes, we may need to introduce a flag besides
> #define CHECK_SIZE_ONLY 1
> #define CHECK_BINARY2
> to suppress the conversion warning ??

I do not think that belongs to diff_populate_filespec() at all.

Why should conversion routine give this warning when called by
diff_populate_filespec() in the first place?  Shouldn't it be silent
by default, and is allowed to talk _ONLY_ when we are attempting to
actually replace the data in the index, e.g. "git add" and "git
commit -a"?

--
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

Re: 'git diff-index' doesn't honor the 'diff.algorithm' variable

[Junio C Hamano]

Dmitry Gutov  writes:

> Hi all,
>
> Subj. ...even though it's explicitly mentioned in the subcommand's man
> page. Git version 2.7.4 here.
>
> To elaborate:
>
> - Call 'git config --global diff.algorithm histogram'.

The variable belongs to UI config, meant for Porcelain "git diff",
together with things like "diff.color", "diff.context", etc.

As the point of lower-level plumbing commands in the diff family,
i.e. diff-files, diff-index and diff-tree, are about giving stable
output, which are _not_ affected by random end-user configuration,
for scripted use, it is very much deliberate design decision that
they ignore the UI config variables.

A script that calls diff-index, if it wants to honor end-users'
UI config variables, is allowed to use 'git config' to read them and
turn them into appropriate command line options.  e.g.

algo=$(git config diff.algorithm)
case "$algo" in
minimal|histogram|patience) algo=--$algo ;;
*) algo= ;;
esac

...
git diff-index $algo ... other args ...

or something like that.
--
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

Re: [PATCH v2 00/94] libify apply and use lib in am

[Junio C Hamano]

Christian Couder  writes:

>>> So it looks to me that --quiet means something like "don't tell the
>>> story of your life, but in case of problem you are allowed to
>>> complain". In other word --quiet generally doesn't suppress error
>>> messages from error() or die().
>>
>> Right.
>>
>> And if you care to take a step back, this is most likely what we want in
>> libified code.
>
> In the previous discussion, Junio asked:
>
> "How far can you go with just set-error-routine?  Are there things,
> other than the file descriptors, that you need to futz with in order
> to covert that "we'd fallback, so this early round must be silent"
> codepath?"
>
> So it looks to me that the goal is to have something that replicate
> the current behavior, which is to not even display messages from
> error().

Note that I was not endorsing the approach to use set-error-routine,
one of whose downside is that it is easy to silence everything
unconditionally.  Between --quiet/--silent, I wasn't making any
choice, as I hadn't even formed an opinion back when I wrote it.

I was merely asking "is use of set-error-routine the worst thing you
need to do, or do you need to do anything more gross?", half
anticipating "no, it turns out that I need to longjmp(3) from my
die-routine to come back from deep in the existing code because I do
not think I'd bother propagating the error status all the way along
the call stack", at which point my response would have been "Ugh,
use of set-error-routine to avoid properly refactoring, even if we
assume it is OK to squelch the errors unconditionally, is bad
enough.  If you need to longjmp(3), that's no longer a libification.
You are better off using the run_command() interface to give the
caller and the callee a proper isolation".

Libification is not just "now it runs inside a single process" at
all.  It is more about "it has proper abstraction and separation so
that callers have _more_ control than they used to (compared to
interacting with a spawned process) while retaining the control of
their own environment".

And as this thread showed, when turning an implementation that uses
run-command with program's standard error sent to /dev/null into a
"libified" implementation, we _gain_ a possibility to be more
selective in what we silence.  I think that exactly falls into
"callers have more control" category of libification benefit.

Quite honestly, I was sort of surprised by the quality of the
argument for proper libification Dscho has been making in this
thread, and that was why I didn't say much here.

Having said all that, as to --quiet/--silent, another way to surface
the "even more quiet" used is with "-q -q" (i.e. multiple levels of
quietness).  I am just saying this for the record without suggesting
it is better or worse suited for this case than what has been
discussed.

In any case, I do see the need for what your --silent option does
internally when a caller like "am" calls into the libified "apply"
machinery.  When we _know_ we will run a "fallback" invocation after
an initial "more strict" apply attempt fails, we do want the initial
invocation to be totally silent, not even with any error message,
because we know that it is sufficient to let the fallback invocation
show its error message (if it fails).  The fallback may even succeed
in which case error messages from the initial invocation serves only
as an explanation of the reason why we used fallback, which is not
interesting to the end user at all.

I however do not see a reason why you need to expose that feature to
the users of "git apply".  So I am not sure if any of us care deeply
the choice among --silent, --quiet and -q -q.
--
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

Re: [PATCH v2 48/94] builtin/apply: rename 'prefix_' parameter to 'prefix'

[Junio C Hamano]

Christian Couder  writes:

> On Thu, May 12, 2016 at 10:43 PM, Junio C Hamano  wrote:
>> Junio C Hamano  writes:
>>
>>> Up to this point, the conversion looks quite sensible, even though I
>>> think the organization of fields in apply_state do not look logical.
>>
>> I'd stop here for now, as everything before this step looks
>> uncontroversial.  Anybody whose tasked to move the global state for
>> these variables into a structure would reach the samestate after
>> applying these 48 patches, modulo minor differences in the way the
>> comments would say things, how the patches are split and how the
>> fields in apply_state() are organized.
>>
>> One thing that is missing is a counterpart of init_apply_state().
>> In the early part of patches where it added only "const char *"
>> borrowed from the caller and fields of intregral type, the lack of
>> clear_apply_state() did not mattter, but with a few fields with
>> "string_list" type, anybody who want to make repeated call into the
>> apply machinery would want a way to release the resource the
>> structure holds.
>>
>> Because 49/94 is a step to add an unfreeable resource, this is a
>> good place to stop and then add the clean_apply_state() before that
>> happens, I would think.  After that, I think both the contributor
>> and the reviewers would benefit if these early patches are merged
>> early without waiting for the review of the remainder.
>
> Ok, I will add add the clean_apply_state() and resend the patches up
> to that point soon, so that they can be merged early.

Two more comments:

 - Just like the change between v1 and v2, if we were to introduce
   clear_apply_state(), it would be nicer if it were done early in
   the series, ideally at the same time as init_apply_state() gets
   introduced, or at least no later than the first field that holds
   resource that needs releasing is added.

 - I didn't double check if 50 and later still had changes that
   belong to this "early batch that moves things into a struct" (aka
   cc/apply-introduce-state) topic, as I stopped at 49 and saw the
   need for clear_apply_state().  So 48 may not be the ideal place
   to stop.  From a cursory read of their titles, perhaps 49, 50, 56
   and possibly 60 should be in this early series?  While 60 does
   sound like an immediate follow-up to 09/94, it depends on a few
   "die elimination" changes, so I do NOT think it must be in the
   early batch.





--
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

Re: [BUG] t9801 and t9803 broken on next

[Junio C Hamano]

Lars Schneider  writes:

>> On 13 May 2016, at 18:37, Junio C Hamano  wrote:
>> 
>> Are you saying that "git p4" itself breaks unless fast-import always
>> writes a new (tiny) packfile?  That sounds quite broken, and setting
>> unpacklimit to 0 does not sound like a sensible "fix".  Of course,
>> if the test script is somehow looking at the number of packs or
>> loose objects and declaring a failure, even when the resulting
>> history in p4 and git are correct, then that is a different issue,
>> and forcing to explode a tiny pack is a reasonable workaround.  I
>> couldn't quite tell which the case is.
>> 
>> Puzzled.  Please help.
>
> t9801 "import depot, branch detection" is the first test that fails
> with a fast import error:
> https://github.com/git/git/blob/78b384c29366e199741393e56030a8384110760d/t/t9801-git-p4-branch.sh#L110
>
> fast-import crash report:
> fast-import process: 77079
> parent process : 77077
> at 2016-05-14 07:48:40 +
>
> fatal: offset beyond end of packfile (truncated pack?)

Hmm, does that suggest Eric's "explode them into loose instead of
keeping a small pack" insufficient?  It sounds like that somebody
wanted to read some data back from its packfile without knowing that
the updated code may make it available in a loose object form, which
would mean that somebody needs to be told about what is going on,
namely, these objects are not in a half-written pack but are found
as loose objects.

> The problem seems to be related to the git-p4 branch import.
> I don't have time this weekend to look further into it, but
> I will try next week.

Thanks.
--
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

Re: [PATCH 3/6] t9107: use "return 1" instead of "exit 1"

[Junio C Hamano]

Jeff King  writes:

> On Fri, May 13, 2016 at 07:45:42PM -0400, Eric Sunshine wrote:
>
>> > +   >expect &&
>> 
>> What's this 'expect' file for? Is it leftover gunk from before you
>> settled on 'diff --exit-code'?
>
> Oops, yes, that's exactly it.
>
> -Peff

Thanks for sharp eyes.  Let's squash this in, perhaps?

 t/t9107-git-svn-migrate.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/t9107-git-svn-migrate.sh b/t/t9107-git-svn-migrate.sh
index 2908aef..b6a99b8 100755
--- a/t/t9107-git-svn-migrate.sh
+++ b/t/t9107-git-svn-migrate.sh
@@ -80,12 +80,12 @@ test_expect_success 'multi-fetch works on partial urls + 
paths' '
git rev-parse --verify refs/remotes/origin/$i^0 || return 1;
done >refs.out &&
test -z "$(sort expect &&
for i in $refs
do
for j in $refs
do
-   git diff --exit-code refs/remotes/origin/$i 
refs/remotes/origin/$j ||
+   git diff --exit-code refs/remotes/origin/$i \
+refs/remotes/origin/$j ||
return 1
done
done
--
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

Re: Empty config sections are neither deleted nor reused

[Junio C Hamano]

Matthieu Moy  writes:

> Junio's explanation must not necessarily be read as "it has to be the
> way it is", but more as "getting it right is harder than you think", and
> that in turn explains why no one changed the behavior.

Thanks for clarification.  s/must not necessarily/must not/;
--
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

Subtree split unsquashes everything

[Joseph Musser]

Hello! I was directed to ask here; I hope I am respecting your format.

I have a repo with a subtree. I squashed every merge with the subtree
remote to keep the history manageable. Now down the road after a bunch
of merges, I need to split my repo’s master branch into two new
branches and move the subtree from `/subdir/subdir/` to `/`.
(`/subdir/subdir/user/mycode/` contains code from my repo.)

I ran `git subtree split -P=subdir/subdir/ -b newbranch` and the
outcome seems to be perfect except that each squash merge has turned
into a full merge, bringing along all history from the other repo. Why
does it do this and how can I preserve my repo history, including only
squashes from the subtree remote repo like it is today?

I initially asked at http://stackoverflow.com/q/36957809

Thank you.
--
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

Re: Empty config sections are neither deleted nor reused

[Matthieu Moy]

Jonas Bernoulli  writes:

>> The configuration sections can have comments and they are preserved
>> even when they become empty.  Adding something unrelated will still
>> make it appear the stale comment applies to it.
>
> Now that you mention it, I think I have read that before.  Unfortunately
> I forgot about it until you reminded me.  I would still prefer if empty
> sections were removed and/or reused provided no comment is nearby, but
> now that you reminded me why the current behavior is how it is, I can
> live with it.

Junio's explanation must not necessarily be read as "it has to be the
way it is", but more as "getting it right is harder than you think", and
that in turn explains why no one changed the behavior.

Actually, Tanay Abhra's GSoC two years ago included working on this, but
the project had other priorities and the empty sections issue was not
tackled.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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

Git and Mozaik

[Randall S. Becker]

Hi Everyone,

I'm embarking on a bit of a quest to bring git into a CNC manufacturing
environment for the Mozaik software package. Does anyone in the group have
experience with git for that package (expecting probably not, but I had to
ask)? I'm hoping that there won't be too many problems (internal file format
seems relatively compatible for the stuff that needs to be versioned
although if there are one-liner text files it may be annoying and I may have
to provide my own diff engine).

Cheers,
Randall

-- Brief whoami: NonStop developer since approximately
UNIX(421664400)/NonStop(2112884442)
-- In my real life, I talk too much.


--
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

Re: Empty config sections are neither deleted nor reused

[Jonas Bernoulli]

> The configuration sections can have comments and they are preserved
> even when they become empty.  Adding something unrelated will still
> make it appear the stale comment applies to it.

Now that you mention it, I think I have read that before.  Unfortunately
I forgot about it until you reminded me.  I would still prefer if empty
sections were removed and/or reused provided no comment is nearby, but
now that you reminded me why the current behavior is how it is, I can
live with it.

Thanks for the link.

  Jonas

--
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

Re: [PATCH v10 00/20] index-helper/watchman

[Dennis Kaarsemaker]

On do, 2016-05-12 at 16:19 -0400, David Turner wrote:

> This version fixes that.  I didn't test on a virtual machine, but I
> did test by adding a sleep().

I can confirm that on my single-cpu test VM, this no longer triggers
errors.

D.
--
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

Re: What's cooking in git.git (May 2016, #05; Fri, 13)

[Pranit Bauva]

On Sat, May 14, 2016 at 3:41 AM, Junio C Hamano  wrote:

> * pb/bisect (2016-05-13) 4 commits
>  - t6030: explicitly test for bisection cleanup

This one can be considered as independent of the entire series.

>  - bisect--helper: `write_terms` shell function in C
>  - bisect: rewrite `check_term_format` shell function in C
>  - bisect--helper: use OPT_CMDMODE instead of OPT_BOOL
>
>  Beginning of GSoC "git bisect" project.

Regards,
Pranit Bauva
--
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

PAYMENT

[UNITED NATIONS]

 
 

 Congratulations,


 You may not understand why this letter came to you. We have been having a 
meeting for quit sometime now and we just came to a logical conclusion few days 
ago in affiliation with
the World Bank president. This letter is to few well listed people that have 
been scammed
in any part of the world, the UNITED NATIONS in Affiliation with WORLD BANK 
have agreed to compensate them with the sum of USD $1.250,000.00 Dollars each.

These includes every foreign contractors that may have not received their 
contract sum,
and people that have had an unfinished transaction or international businesses 
that
failed due to Government problems etc. We found your name in the list of those 
who are
to benefit from these compensation exercise and that is why we are contacting 
you, this
have been agreed upon and have been signed.

You are advised to contact Dr Gift Solomon to our paying center in South 
Africa, as he is our representative in Africa. Contact him immediately for your 
Cheque International Bank Draft of USD$1.250,000.00Dollars.This fund is in form 
of a Bank Draft for security
purpose ok? So he will send it to you and you can clear it in any bank of your 
choice.
Therefore, you should send him your full Name and telephone number your correct 
mailing
address where you want him to send the Draft to you.

Contact information is as follow:
Dr. MICHEAL NKUNA
E-mail: michealnk...@consultant.com

Please contact him with your payment code: 09051982 immediately for your Cheque 
to be delivered to your address.

begin_of_the_skype_highlightingend_of_the_skype_highli I apologize on behalf of 
the United Nation organization for any delay you might have
encountered in receiving your fund in the past. Thanks and God bless you and 
your
family.

Congratulations, and I look forward to hear from you as soon as you confirm 
your payment
making the world a better place.

Regards,
Secretary-General Ban Ki-moon,
United Nations.
http://www.un.org/sg/ Secretary-General Ban Ki-moon,
United Nations.
http://www.un.org/sg/
--
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] crlf: Add test showing double warning on commit

[Adam Dinwoodie]

Add failing test case showing CRLF -> LF rewrite warnings being printed
multiple times when running "git commit".

Signed-off-by: Adam Dinwoodie 
---
 t/t0020-crlf.sh | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
index f94120a..188b1dd 100755
--- a/t/t0020-crlf.sh
+++ b/t/t0020-crlf.sh
@@ -74,7 +74,7 @@ test_expect_success 'safecrlf: autocrlf=true mixed LF/CRLF' '
test_must_fail git add mixed
 '
 
-test_expect_success 'safecrlf: print warning only once' '
+test_expect_success 'safecrlf: print warning only once on add' '
 
git config core.autocrlf input &&
git config core.safecrlf warn &&
@@ -87,6 +87,20 @@ test_expect_success 'safecrlf: print warning only once' '
 '
 
 
+test_expect_failure 'safecrlf: print warning only once on commit' '
+
+   git config core.autocrlf input &&
+   git config core.safecrlf warn &&
+
+   for w in I am all LF; do echo $w; done >doublewarn2 &&
+   git add doublewarn2 &&
+   git commit -m "nowarn" &&
+   for w in Oh here is CRLFQ in text; do echo $w; done | q_to_cr 
>doublewarn2 &&
+   git add doublewarn2 2>&1 &&
+   test $(git commit -m Message | grep "CRLF will be replaced by LF" | wc 
-l) = 1
+'
+
+
 test_expect_success 'safecrlf: git diff demotes safecrlf=true to warn' '
git config core.autocrlf input &&
git config core.safecrlf true &&
-- 
2.8.1
--
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

Re: Bug report: Duplicate CRLF rewrite warnings on commit

[Adam Dinwoodie]

On Sat, May 14, 2016 at 07:40:11AM +0200, Torsten Bögershausen wrote:
> On 13.05.16 18:43, Junio C Hamano wrote:
> > Adam Dinwoodie  writes:
> > 
> >> If you use .gitattributes to enable CRLF->LF rewriting, then commit a
> >> file that would have its line endings rewritten, the "CRLF will be
> >> replaced by LF" warning is printed several times over; I'd expect it to
> >> be printed only once.
> >>
> >> There's a test case in t0020 -- "safecrlf: print warning only once" --
> >> that checks the warning is only printed once when using `git add`, but
> >> nothing that seems to check the same thing on `git commit`.  The
> >> unnecessary multiple warnings seem to have existed since at least v1.6.0
> >> (the warnings appear to have been added in v1.5.5 in 21e5ad5, but I
> >> couldn't get that to build on my current box), and I'm seeing them on my
> >> Cygwin box's build of the current next branch (d10caa2) and on my CentOS
> >> box's v2.8.1 release.
> > 
> > Torsten, I know you are not heavily invested in "commit" codepath,
> > but since you've been actively touching the CRLF area, I wonder
> > perhaps you might be interested in taking a look?
> > 
> I have seen this double warning as well, but never digged further,
> as it is most probably in the code outside convert.c
> 
> I can put it on the TODO list, and I think it would make sense to add
> a TC in t0020, which is marked as test_expect_failure.

Grand.  I'll submit the test patch now.
--
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

Re: [PATCH v2 00/94] libify apply and use lib in am

[Christian Couder]

On Sat, May 14, 2016 at 8:26 AM, Johannes Schindelin
 wrote:

[...]

>> >> By the way there are no tests yet for this new feature, and I am not
>> >> sure at all that "--silent" and "be_silent" are good names.
>> >
>> > If you want to follow existing code's example, we typically call this
>> > option "quiet".
>>
>> In the documentation there is: [... snip ...]
>> ...
>>
>> So it looks to me that --quiet means something like "don't tell the
>> story of your life, but in case of problem you are allowed to
>> complain". In other word --quiet generally doesn't suppress error
>> messages from error() or die().
>
> Right.
>
> And if you care to take a step back, this is most likely what we want in
> libified code.

In the previous discussion, Junio asked:

"How far can you go with just set-error-routine?  Are there things,
other than the file descriptors, that you need to futz with in order
to covert that "we'd fallback, so this early round must be silent"
codepath?"

So it looks to me that the goal is to have something that replicate
the current behavior, which is to not even display messages from
error().

[...]

>> >> Sorry if this patch series is long. I can split it into two or more
>> >> series if it is prefered.
>> >
>> > It is preferred. Much.
>>
>> Ok, I will split it then.
>
> Thank you. Maybe you take me off of the Cc: list, too?

Ok I will do that.
--
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

Re: [PATCH v2 29/33] refs: resolve symbolic refs first

[Torsten Bögershausen]

On 13.05.16 14:33, Michael Haggerty wrote:
> Torsten, thanks for the report. Peff, thanks for the analysis.
I didn't follow all the details.
The new "pu" passes with no errors on all of my test systems :-)
 
 

--
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

Re: [BUG] t9801 and t9803 broken on next

[Lars Schneider]

> On 13 May 2016, at 18:37, Junio C Hamano  wrote:
> 
> Eric Wong  writes:
> 
>> Lars Schneider  wrote:
>>> Hi,
>>> 
>>> t9801 and t9803 seem to be broken on next. A quick bisect indicates that 
>>> d9545c7 
>>> "fast-import: implement unpack limit" might be the reason. (@gmane/292562).
>>> 
>>> Did anyone look into that already?
>> 
>> Just took a look (no p4, so couldn't run tests) and I guess it's
>> because the default changed and it doesn't generate tiny packs.
> 
> I looked at t9801 but I couldn't spot where it cares if the objects
> are in a (tiny) pack or stored as individual loose objects.  All the
> counting I saw was about rev-list/log output and they shouldn't care.
> 
> Are you saying that "git p4" itself breaks unless fast-import always
> writes a new (tiny) packfile?  That sounds quite broken, and setting
> unpacklimit to 0 does not sound like a sensible "fix".  Of course,
> if the test script is somehow looking at the number of packs or
> loose objects and declaring a failure, even when the resulting
> history in p4 and git are correct, then that is a different issue,
> and forcing to explode a tiny pack is a reasonable workaround.  I
> couldn't quite tell which the case is.
> 
> Puzzled.  Please help.

t9801 "import depot, branch detection" is the first test that fails
with a fast import error:
https://github.com/git/git/blob/78b384c29366e199741393e56030a8384110760d/t/t9801-git-p4-branch.sh#L110

fast-import crash report:
fast-import process: 77079
parent process : 77077
at 2016-05-14 07:48:40 +

fatal: offset beyond end of packfile (truncated pack?)

Most Recent Commands Before Crash
-
  commit refs/remotes/p4/master
  mark :1
  committer Dr. author  1463212118 +
  data < 1463212118 +
  data < 1463212118 +
  data < 1463212118 +
  data < 1463212118 +
  data < 
>> The easiest change is probably to call:
>> 
>>  git config fastimport.unpackLimit 0
>> 
>> during setup like t9300 now does.
Unfortunately that seems not to help.

The problem seems to be related to the git-p4 branch import.
I don't have time this weekend to look further into it, but
I will try next week.

Cheers,
Lars--
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

Re: [PATCH v2 00/94] libify apply and use lib in am

[Johannes Schindelin]

Hi Chris,

On Fri, 13 May 2016, Christian Couder wrote:

> On Fri, May 13, 2016 at 8:32 AM, Johannes Schindelin
>  wrote:
> >
> > On Wed, 11 May 2016, Christian Couder wrote:
> >
> >> I consider that the apply functionality is properly libified before
> >> these patches, and that they should be in a separate series, but
> >> unfortunately using the libified apply in "git am" unmasks the fact
> >> that "git am", since it was a shell script, has been silencing the
> >> apply functionality by "futzing with file descriptors". And
> >> unfortunately this makes some reviewers unhappy.
> >
> > It is a misrepresentation to claim that this makes some reviewers
> > unhappy.  Speaking for myself, I am very happy. Despite having had to
> > point out that the previous iteration of this patch series had a
> > serious flaw.
> >
> > It is also incorrect to say that the shell script had been "futzing
> > with the file descriptors". You see, the shell script's *own* file
> > descriptors had been left completely unaffected by the redirection of
> > the spawned process' output. That was perfectly fine a thing to do,
> > even if it possibly hid fatal errors. Shell scripts are simply very
> > limiting. The problem was introduced by v1 of this patch series, which
> > changed *the caller's file descriptors* back and forth simply because
> > the called code no longer runs in a separate process. And *that* was,
> > and is, improper.
> 
> I think we should just agree that we disagree on what we think the v1
> was doing and move on to v2.

It is obvious that you want to disagree. But that is counterproductive.

It is important to keep in mind, and needs to be remembered in future
libification efforts, that extra care is required when we no longer spawn
a separate process: you no longer have the option to change global state
*just* for the called process.

This is very true when redirecting (global) file descriptors. I struggle
with this myself in the rebase--helper branch, so it is not only you who
has to face, and address, this issue.

The same goes for die(), too, of course. And for statically allocated
memory. And even worse: when all of a sudden reusing static lockfile
structs. And, and, and. The list goes on.

It really comes back at us that we originally simple did not care about
cleaning up after us "because it is a short-lived process, anyway".

The thing is: this is not at all the philosophical discussion as which
your comment tries to color it. We *have* to address these issues when
libifying code. Yes, it's hard. Yes, it's tedious. Yes, I also want to
bitch about it.

And yes, it must be done.

> >> By the way there are no tests yet for this new feature, and I am not
> >> sure at all that "--silent" and "be_silent" are good names.
> >
> > If you want to follow existing code's example, we typically call this
> > option "quiet".
> 
> In the documentation there is: [... snip ...]
> ...
> 
> So it looks to me that --quiet means something like "don't tell the
> story of your life, but in case of problem you are allowed to
> complain". In other word --quiet generally doesn't suppress error
> messages from error() or die().

Right.

And if you care to take a step back, this is most likely what we want in
libified code.

Modulo die(), of course!

> On the contrary the new feature I tentatively called --silent does
> suppress all output including error messages from error().

And what would be the point of that? Now that we are libifying code, in
contrast to the spawned-process approach, we *can* discern between "prints
to stderr" and "displays an error". I'd wager that you won't find any
error() call in the code path that we want to silence.

> Now if people think that it is not worth making a difference between the
> different behaviors, then I am ok to rename it --quiet, though I wonder
> what will happen if people later want a --quiet that does only what
> --quiet usually does to the other commands.

You know, I get the distinct impression that you do not want my feedback
because you always want "people" to agree with my assessment. I hoped that
my arguments would make sense, but I guess I should spend my time
differently.

> >> Sorry if this patch series is long. I can split it into two or more
> >> series if it is prefered.
> >
> > It is preferred. Much.
> 
> Ok, I will split it then.

Thank you. Maybe you take me off of the Cc: list, too?

Thanks,
Dscho
--
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