Re: [PATCH] contrib/subtree: Remove --annotate

[greened]

Sebastian Schuberth  writes:

> On Sat, Jan 2, 2016 at 9:36 PM, David Greene  wrote:
>
>> commit messages.  git has other tools more suited to rewriting
>> commit messages and it's easy enough to use them after a subtree
>> split.
>
> For completeness, it probably would be a good idea to name examples
> for such more suitable tools as part of the commit message.

Ok, that makes sense.

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

Detecting redundant commits

[greened]

I am attempting to teach cherry-pick to handle redundant commits
gracefully (via a new --skip-redundant-commits option) instead of
aborting.  However, I'm struggling a bit with how to check if the
changes in a commit will become redundant when appied to the new HEAD.

I found diff_tree_sha1 which seems promising.  Am I on the right track?
If not, what's the best way to determine whether a commit object is
redundant with respect to HEAD?

   -David
--
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: My Status

[greened]

Hi folks,

I apologize for being off the grid for a while.  We had a baby and
unexpectedly ended up in the NICU.  We just got him home a week ago.
Everyone is doing fine but I had to pretty much drop all non-essential
work for a month or so.

Rest assured that I have all of the git-subtree-related mail sitting in
my inbox.  It will take me some time to process it all -- looks ike
there has been a lot of good work!

Please remember that I don't consider myself a gatekeeper to git
subtree.  In fact I could use some help reviewing and approving patches.
If anyone thinks a patch looks good, let Junio know.  It's my
responsibility to object to things, not your responsibility to wait for
me.  :) Life happens and I want to make sure git-subtree moves forward.

Thanks everyone for understanding.

   -David
--
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 11/13] contrib/subtree: Make each test self-contained

[greened]

Junio C Hamano gits...@pobox.com writes:

 I also think it would be a good idea for you to learn to push back
 to the original authors; fixing problems in patches by others, while
 is a good way to learn how their thinking process went, is not
 necessarily fun.

Sure, but in this case I said I'd handle it so I will.

  -David
--
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 13/13] contrib/subtree: Remove --annotate

[greened]

James Nylen jny...@gmail.com writes:

 I don't agree that removing `--annotate` obviates the need for `--unannotate`.

 I responded on 1/17 with what I think is a typical and normal use case
 for that option:

Sorry, I must have missed that reply.

  - add fancylib as a subtree of myprog
  - commit to myprog repo: fancylib: don't crash as much
  - split these commits back out to fancylib main repo, and remove
 the fancylib:  prefix

I can see how that would be useful.

 `--unannotate` is a clunky name, but I think this functionality is
 worth taking another look at.  Maybe it could be called
 `--remove-prefix` ?

Should this really be a function of git-subtree?  It seems like it would
fit better in a history-rewriting command.  Wouldn't rebase -i or even
filter-branch be a better way to do this?

If there's no --annotate I don't see why git-subtree should have the
--unannotate functionality.

Again, I agree that your example is relevant, maybe even common, but I
don't necessarily think git-subtree should be in the business of
rewriting commit messages at all.

I'd appreciate more thoughts from you on this.  I want to make sure we
can support your use case.

 -David
--
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: Rebased git-subtree changes

[greened]

Junio C Hamano gits...@pobox.com writes:

 This looks to be of mixed quality.  The earlier ones look fairly
 finished, while the later ones not so much.

 I am tempted to take up to 06/13 and advance them to 'next', without
 the rest.

Can you let me know what you've taken up?  I have a new set with some
fixes.

-David
--
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 1/4] contrib/subtree: Store subtree sources in .gitsubtree and use for push/pull

[greened]

Paul Campbell pcampb...@kemitix.net writes:

 Subsequent git subtree push/pull operations now default to the values
 stored in .gitsubtree, unless overridden from the command line.

 The .gitsubtree file should be tracked as part of the repo as it
 describes where parts of the tree came from and can be used to update
 to/from that source.

I agree with the basic idea but have some questions about the
implementation.

Is there precedent of git commands storing information in hidden files
and requiring those files to be added to the repository and tracked?  It
seems like a bit of a kludge.

Could we use notes or something for this?

I'm not necessarily against the patches, I just want to make sure we
don't go down a road that won't be acceptable later on.

   -David
--
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 (Feb 2013, #05; Tue, 12)

[greened]

Junio C Hamano gits...@pobox.com writes:

 * dg/subtree-fixes (2013-02-05) 6 commits
   (merged to 'next' on 2013-02-09 at 8f19ebe)
  + contrib/subtree: make the manual directory if needed
  + contrib/subtree: honor DESTDIR
  + contrib/subtree: fix synopsis
  + contrib/subtree: better error handling for 'subtree add'
  + contrib/subtree: use %B for split subject/body
  + contrib/subtree: remove test number comments

  contrib/subtree updates, but here are only the ones that looked
  ready to be merged to 'next'.  For the remainder, they will have
  another day.

Great, I've got updates for the rest.

   -David
--
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: Rebased git-subtree changes

[greened]

David A. Greene gree...@obbligato.org writes:

 Here's a re-send of the git-subtree patches after rebasing onto
 master.  Hopefully Junio will have better luck applying these.

Damn.  Sorry, I sent this before getting all of the feedback.  Just
ignore this sequence and I'll send a fixed version in the future.

 -David
--
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/7] contrib/subtree: Add --unannotate

[greened]

Junio C Hamano gits...@pobox.com writes:

 gree...@obbligato.org writes:

 gree...@obbligato.org writes:

 I think this paragraph inherits existing breakage from the beginning
 of time, but I do not think the above will format the second and
 subsequent paragraphs correctly.

 Ok, I'll take a look.

 I don't know what correctly is but it is at least formatted in a
 similar manner to the other options.

 That is what inherits existing breakage means ;-)

Ah.

 The first paragraph is typeset as body text, while the rest are
 typeset in monospaced font, no?

 It should be more like this, I think:

 --option::
 First paragraph
 +
 Second paragraph
 +
 And third paragraph

Ok.

  -David
--
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 2/7] contrib/subtree: Use %B for Split Subject/Body

[greened]

Junio C Hamano gits...@pobox.com writes:

 gree...@obbligato.org writes:

 Are you incorporating the other patches?  Should I drop them
 from my list?

 I actually was planning to accept patches to this subdirectory only
 through you, hopefully as messages that forward others' changes with
 your Acked-by: tagline.  That frees me from having to keeping track
 of what goes on there ;-)

Ok, just wanted to know the process.  Makes sense to me.

 -David
--
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 2/8] Add --unannotate

[greened]

James Nylen jny...@gmail.com writes:

 I just now saw these emails.  I'm having a hard time thinking of any
 good use case other than:

  - add fancylib as a subtree of myprog
  - commit to myprog repo: fancylib: don't crash as much
  - split these commits back out to fancylib's main repo, and remove
 the fancylib:  prefix

That does seem to me to be the common case, at least.

 You could potentially have something like Don't crash as much
 (fancylib) but that's awkward.  What might you want to do with a
 pattern-based rewrite that doesn't involve removing a prefix when
 splitting commits?

I'm not really sure.  I've never used --annotate in my own work.

 In fact, I don't see the use of the original --annotate option at all,
 since it causes more detailed commit messages in the smaller of the
 two repositories.

I'll have to look back through Avery's logs and see if I can puzzle out
why this was added.  If it's not useful, perhaps we can remove it before
migrating to mainline.

Junio, is there a policy for backward-compatability in contrib?  I hope
that since that directory is for stuff not yet in mainline, there is
some room to massage the user interface.

-David
--
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 2/7] contrib/subtree: Use %B for Split Subject/Body

[greened]

Junio C Hamano gits...@pobox.com writes:

 David A. Greene gree...@obbligato.org writes:

 From: Techlive Zheng techlivezh...@gmail.com

 Use %B to format the commit message and body to avoid an extra newline
 if a commit only has a subject line.

 Signed-off-by: Techlive Zheng techlivezh...@gmail.com

 Signed-off-by: David A. Greene gree...@obbligato.org
 ---

 This time (only), I'll try to fix them up at my end, but please
 check your toolchain, find out where the extra blank line between
 S-o-b: lines we see above come from, and fix that, so that I won't
 have to do so again.

Will do.

  contrib/subtree/git-subtree.sh |6 +-
  contrib/subtree/t/t7900-subtree.sh |   15 +++
  2 files changed, 20 insertions(+), 1 deletion(-)

 diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
 index 920c664..5341b36 100755
 --- a/contrib/subtree/git-subtree.sh
 +++ b/contrib/subtree/git-subtree.sh
 @@ -296,7 +296,11 @@ copy_commit()
  # We're going to set some environment vars here, so
  # do it in a subshell to get rid of them safely later
  debug copy_commit {$1} {$2} {$3}
 -git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%s%n%n%b' 
 $1 |
 +# Use %B rather than %s%n%n%b to handle the special case of a
 +# commit that only has a subject line.  We don't want to
 +# introduce a newline after the subject, causing generation of
 +# a new hash.
 +git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%B' $1 |

 The new format template is fine, but I do not think the comment
 should be there.  It does not give any useful information to people
 who are reading the end result of applying this patch and is useful
 only in the context of comparing the old and new templates, iow, it
 belongs to the commit log message.

I'll delete the comment.

   -David
--
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 2/7] contrib/subtree: Use %B for Split Subject/Body

[greened]

Junio C Hamano gits...@pobox.com writes:

 David, how would you like to handle a reroll of this piece?

I'll just get the test fix from Techlive Zheng, apply it to my
branch and re-send.

Are you incorporating the other patches?  Should I drop them
from my list?

-David
--
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/7] contrib/subtree: Add --unannotate

[greened]

Junio C Hamano gits...@pobox.com writes:

 David A. Greene gree...@obbligato.org writes:

 diff --git a/contrib/subtree/git-subtree.txt 
 b/contrib/subtree/git-subtree.txt
 index c5bce41..75aa690 100644
 --- a/contrib/subtree/git-subtree.txt
 +++ b/contrib/subtree/git-subtree.txt
 @@ -198,6 +198,21 @@ OPTIONS FOR split
  git subtree tries to make it work anyway, particularly
  if you use --rejoin, but it may not always be effective.
  
 +--unannotate=annotation::
 +This option is only valid for the split command.
 +
 +When generating synthetic history, try to remove the prefix
 +annotation from each commit message (using bash's strip
 +shortest match from beginning command, which supports
 +globbing).  This makes sense if you format library commits
 +like library: Change something or other when you're working
 +in your project's repository, but you want to remove this
 +prefix when pushing back to the library's upstream repository.
 +(In this case --unannotate='*: ' would work well.)
 +
 +Like --annotate,  you need to use the same annotation
 +whenever you split, or you may run into problems.

 I think this paragraph inherits existing breakage from the beginning
 of time, but I do not think the above will format the second and
 subsequent paragraphs correctly.

Ok, I'll take a look.

 I've applied all seven patches in the series with minor fix-ups, and
 will merge it to 'pu'.

Thanks!

  -David
--
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 4/7] contrib/subtree: Better Error Handling for add

[greened]

Junio C Hamano gits...@pobox.com writes:

 David A. Greene gree...@obbligato.org writes:

 From: David A. Greene gree...@obbligato.org

 Check refspecs for validity before passing them on to other commands.
 This lets us generate more helpful error messages.

 Signed-off-by: David A. Greene gree...@obbligato.org
 ---
  contrib/subtree/git-subtree.sh |   12 +---
  1 file changed, 9 insertions(+), 3 deletions(-)

 diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
 index cac0680..d53eaee 100755
 --- a/contrib/subtree/git-subtree.sh
 +++ b/contrib/subtree/git-subtree.sh
 @@ -508,12 +508,18 @@ cmd_add()
  ensure_clean
  
  if [ $# -eq 1 ]; then
 -cmd_add_commit $@
 +git rev-parse -q --verify $1^{commit} /dev/null ||
 +die '$1' does not refer to a commit

 Where do these uneven indentation come from?  Is it mimicking
 existing breakage in the script?

Huh.  I'm not sure how that happened.  I'll fix it if you haven't got to
it already.

-David
--
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/7] contrib/subtree: Add --unannotate

[greened]

gree...@obbligato.org writes:

 I think this paragraph inherits existing breakage from the beginning
 of time, but I do not think the above will format the second and
 subsequent paragraphs correctly.

 Ok, I'll take a look.

I don't know what correctly is but it is at least formatted in a
similar manner to the other options.

  -David
--
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 1/8] Use %B for Split Subject/Body

[greened]

Junio C Hamano gits...@pobox.com writes:

 The question was about the lossage of the blank line, which does not
 seem to be related to what this patch wants to do.

Ah, missed that.

 -# 25
 +#25

 Why the lossage of a SP?

 I think this got fixed later in the series.

 That is not a good excuse to introduce breakages in the first place, no?

Oh, I agree.  I wasn't making excuses.  :)

 It may make sense to lose these # num that will have to be touched
 every time somebody inserts new test pieces in the middle, as a
 preparatory step before any of these patches, by the way.  That will
 reduce noise in the patches for real changes.

 Yeah, I know, but it makes it really easy to find a test when something
 goes wrong.

 That is what t-*.sh -i is for, isn't it?

Oh, I didn't know about that!

-David
--
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 2/8] Add --unannotate

[greened]

Junio C Hamano gits...@pobox.com writes:

 gree...@obbligato.org writes:

 In the meantime, will you apply the patch or do you prefer a new design?

 The --unannotate option will become a baggage you will have to keep
 working until the end of time, if we applied it.  I think it is not
 too uch a baggage, so it probably is OK.

Ok.  I think it's worth applying since people find it useful.  It's not
very complicated.

   -David
--
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 1/8] Use %B for Split Subject/Body

[greened]

Junio C Hamano gits...@pobox.com writes:

 David A. Greene gree...@obbligato.org writes:

 From: Techlive Zheng techlivezh...@gmail.com

 Use %B to format the commit message and body to avoid an extra newline
 if a commit only has a subject line.

 Is this an unconditional improvement, or is it generally an
 improvement but for some users it may be a regression?  I am
 guessing it is the former but am just making sure.

The former.

 Author:Techlive Zheng techlivezh...@gmail.com

 Signed-off-by: David A. Greene gree...@obbligato.org

 Please don't do Author:  which does not add anything new.  That is
 what From:  is for.  Instead it needs to be a sign-off.

Ok.  Unfortunately I sent a number of patches like that.  Do you want me
to re-send them?

 Also, is that a real name, I have to wonder?

No idea.  Not likely, I'd say.

-David
--
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 1/8] Use %B for Split Subject/Body

[greened]

Junio C Hamano gits...@pobox.com writes:

 Also, please be careful about the subject line.  I doubt that these
 8 patches will stand out as relating to contrib/subtree, when mixed
 in 200 line output of git shortlog --no-merges.

Ah, ok.  I'll be more careful next time.

  -David
--
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 1/8] Use %B for Split Subject/Body

[greened]

Junio C Hamano gits...@pobox.com writes:

 David A. Greene gree...@obbligato.org writes:

 Subject: Re: [PATCH 1/8] Use %B for Split Subject/Body

 This needs to say contrib/subtree somewhere (applies to all
 patches in this series).

Ok.  Shall I re-send everything?

 From: Techlive Zheng techlivezh...@gmail.com

 Use %B to format the commit message and body to avoid an extra newline
 if a commit only has a subject line.

 Author:Techlive Zheng techlivezh...@gmail.com

 This needs to be a S-o-b instead; is it a real name, by the way?

Ok.  No idea about the name but his online presence seems consistent at
least.

 +# Save this hash for testing later.
 +
 +subdir_hash=`git rev-parse HEAD`
 +

 We prefer $() over ``; much more readable.

Ack, of course.  I don't know how I missed that.

  # 15
  test_expect_success 'add main6' '
  create main6 

 Why?

It was in the original testsuite from Avery.  I didn't add or remove any
tests when I first integrated git-subtree.

 @@ -235,7 +238,19 @@ test_expect_success 'check split with --branch' '
  check_equal ''$(git rev-parse splitbr1)'' $spl1

 Is quoting screwed up around here (and in many other places in this
 patch)?  What are these no-op '' doing?

I assumed they are there to get the double-quotes around the command.
I'll see about removing them.

 -# 25
 +#25

 Why the lossage of a SP?

I think this got fixed later in the series.

 It may make sense to lose these # num that will have to be touched
 every time somebody inserts new test pieces in the middle, as a
 preparatory step before any of these patches, by the way.  That will
 reduce noise in the patches for real changes.

Yeah, I know, but it makes it really easy to find a test when something
goes wrong.

-David
--
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 2/8] Add --unannotate

[greened]

Junio C Hamano gits...@pobox.com writes:

 David A. Greene gree...@obbligato.org writes:

 From: James Nylen jny...@gmail.com

 Teach git-subtree about --unannotate.  This option strips a prefix
 from a commit message when doing a subtree split.

 Hrm.  This looks like a workaround for a short-sighted misdesign of
 the annotate option that only allowed prefixing a fixed string.  I
 have to wonder if it is better to deprecate --annotate and replace
 it with a more general commit log rewriting facility that can
 cover both use cases?

That's not a bad idea.  I'd have to think a bit about a sensible design.
Do you have any ideas, James?

In the meantime, will you apply the patch or do you prefer a new design?

  -David
--
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/8] Better Error Handling for add

[greened]

Junio C Hamano gits...@pobox.com writes:

 diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
 index 7ceb413..b8a807a 100755
 --- a/contrib/subtree/git-subtree.sh
 +++ b/contrib/subtree/git-subtree.sh
 @@ -509,8 +509,20 @@ cmd_add()
  ensure_clean
  
  if [ $# -eq 1 ]; then
 +ref=$(git check-ref-format --normalize refs/heads/$1) ||
 +die '$1' is not a valid refspec.  Are you missing a 
 branch?

 Is a user forbidden from passing a commit that is not at the tip of
 an existing branch?  In other words, is

   $ subtree add origin/next~4^2

 forbidden?

Good point.  It probably shouldn't be.  I think rev-parse should be
enough of a check.

 +rev=$(git rev-parse --verify $1) ||
 +die '$1' is not a valid refspec.  Are you missing a 
 branch?
 +
  cmd_add_commit $@

 If you want to make sure you give a comit to add_commit, you can
 probably say something like this:

   git rev-parse -q --verify $1^{commit} /dev/null ||
 die '$1' does not refer to a commit

What does $1^{commit} mean?  I think your suggestion is what I want but
I don't know what it means yet.  :)

   -David
--
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 4/8] Fix Synopsis

[greened]

Junio C Hamano gits...@pobox.com writes:

 -git subtree add   --prefix=prefix commit
 +git subtree add   --prefix=prefix refspec

 Again, this is not refspec but commit.

Ok, I need to study the terminology.  :)

 +git subtree add   --prefix=prefix repository refspec

 This is given to fetch and it seems to acccept any refspec, so
 it is probably a good change (I didn't fully follow the codepath,
 though).

I think you are correct.

  -David
--
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/8] Honor DESTDIR

[greened]

Junio C Hamano gits...@pobox.com writes:

 David A. Greene gree...@obbligato.org writes:

 From: Adam Tkac at...@redhat.com

 Teach git-subtree's Makefile to honor DESTDIR.

 Author:Adam Tkac at...@redhat.com

 Signed-off-by:Adam Tkac at...@redhat.com

 Signed-off-by: David A. Greene gree...@obbligato.org
 ---

 The contents of the patch looks sensible; the above is questionable
 as all the other messages in this series, though.  Did any of our
 tools cause this failure?  If so I would like to know more about it.

What failure are you referring to?  When I used git send-email --author,
the Author: line was commented out.  I assumed I was supposed to
uncomment it.  Guess I was wrong.

I'll re-send the series since you pointed out a number of improvements.

   -David
--
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 6/8] Make the Manual Directory if Needed

[greened]

Junio C Hamano gits...@pobox.com writes:

 diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile
 index 36ae3e4..52d6fb9 100644
 --- a/contrib/subtree/Makefile
 +++ b/contrib/subtree/Makefile
 @@ -35,6 +35,7 @@ install: $(GIT_SUBTREE)
  install-doc: install-man
  
  install-man: $(GIT_SUBTREE_DOC)
 +mkdir -p $(man1dir)

 We seem to use $(INSTALL) -d -m 755 for this kind of thing (see
 the Documentation/Makefile).

Ok, will fix.

 -Dave
--
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/Enhancement: contrib/subtree should ship with manpage

[greened]

Neil kngsp...@gmail.com writes:

 Actual: git-subtree.1 fails to be generated because my system doesn't ship
 asciidoc and xmlto.

Well, you need those tools to build ANY git documentation.  I just ran a
test to build git-subtree and its documentation and it went just fine.
This is not a bug.

  -Dave
--
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] subtree.sh: Use raw subject and body modifier %B instead of %s%n%n%b

[greened]

gree...@obbligato.org writes:

 Techlive Zheng techlivezh...@gmail.com writes:

 %s%n%n%b is not always equal to %B. If the commit msg does not have
 a body, this will append an extra new-line character to the msg title
 which would cause the splited commit has a new sha1 hash. In most cases,
 this does not matter, but for a project which did not merged using this
 script initially, the 'split' command would not genereate the same
 commits as the orginal which may cause conflicts.

 Signed-off-by: Techlive Zheng techlivezh...@gmail.com
 ---
  contrib/subtree/git-subtree.sh | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
 index 920c664..5598210 100755
 --- a/contrib/subtree/git-subtree.sh
 +++ b/contrib/subtree/git-subtree.sh
 @@ -296,7 +296,7 @@ copy_commit()
  # We're going to set some environment vars here, so
  # do it in a subshell to get rid of them safely later
  debug copy_commit {$1} {$2} {$3}
 -git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%s%n%n%b' 
 $1 |
 +git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%B' $1 |
  (
  read GIT_AUTHOR_NAME
  read GIT_AUTHOR_EMAIL

 This looks good to me.  I assume this passes all the tests.  Can you add
 a test for this bug so we don't regress?  Junio, I am good with this
 patch as soon as we get a test for the problem.

I've applied this patch to my working copy but I'm not finding that I
can recreate the original problem when the patch is disabled.

I assumed the scenario you're trying to fix is:

- Make some commit C to project A with a one-line message
- work, commit, work...
- Add project A as a subproject
- work, commit, work...
- Split project A off into a separate repository

After this, commit C with the one-line message in the split-off projet
should have the same hash it had before project A was incorporated as a
subproject.

As I understad it, you saw the post-split commit having a different
hash?

Is that right?  I am not seeing that problem even without your patch.

I want to make sure I understand what the problem is so I can test for
it.

Thanks!

  -David
--
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] Add --unannotate option to git-subtree

[greened]

Herman van Rink r...@initfour.nl writes:

 Has anybody looked at this?

 It has been very useful for me.

I am looking at it now.

 The version of subtree in contrib is rather out-dated unfortunately.

It is the official version.  What's missing?  You have a bunch of
changes that need rework to include into mainline but other than that
I am not aware of any major missing pieces.  If there are such changes I
would very much like to get them integrated

 Your patch looks interesting though. I can see how this could be useful.

 I've collected a bunch of patches in
 https://github.com/helmo/git/tree/subtree-updates

I hope you will submit your changes for inclusion.  Again, I'm not a
gatekeeper but I do want the patches to have proper testcases and
integrate into contrib/subtree.

 -David
--
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] Add --unannotate option to git-subtree

[greened]

James Nylen jny...@gmail.com writes:

 Rather than adding a marker to each commit when splitting out the
 commits back to the subproject, --unannotate removes the specified
 string (or bash glob pattern) from the beginning of the first line of
 the commit message.  This enables the following workflow:

I applied the patch to my working copy but it doesn't seem to do
what I'd expect.  The test script does something like this:

- create project A
- add file to project A with message subproj: add F1
- add file to project A with message subproj: add F2
- add project A as a subtree of project B under directory subdir
- add a file to subdir with message subproj: add F3
- do a split --unannotate=subproj:

I expected to see a log with no mention of subproj anywhere.  Instead
I get:

add F3
subproj: add F2
subproj: add F1

Is this as you intend?  Is --unannotate only supposed to strip the
string for commits added when A was a subtree of B?

I guess this behavior makes sense in that the user would want to
see the same commits that existed before A became a subproject.

   -David
--
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?] git-subtree behavior when the -P tree is removed and recreated

[greened]

Tomi Belan tomi.be...@gmail.com writes:

 Thanks. Here's one more bump. Avery? David?

I don't know how this is supposed to work, unfortunately.  I'm still in
the middle of learning the code...

   -David
--
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 subtree error (just how do you expect me to merge 0 trees?)

[greened]

Drew Crawford d...@drewcrawfordapps.com writes:

 I noticed today that if you leave off the branch name from git subtree like 
 so:

 $ git subtree add --prefix somewhere -m adding CDH as subtree path/to/repo
 warning: read-tree: emptying the index with no arguments is deprecated; use 
 --empty
 fatal: just how do you expect me to merge 0 trees?

 The error message is not particularly helpful (and seems to actually be in 
 read-subtree?)  The solution in my case was to add the branch name on the end 
 of the command.

 Ideally it would be better to emit an error-message from a script higher up 
 the calling chain that would be more descriptive about the problem (such as 
 suggesting no branch is specified).--

Good idea.  I'll code it up.

-David
--
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 subtree error (just how do you expect me to merge 0 trees?)

[greened]

Drew Crawford d...@drewcrawfordapps.com writes:

 Ideally it would be better to emit an error-message from a script
 higher up the calling chain that would be more descriptive about the
 problem (such as suggesting no branch is specified).--

I'm looking at implementing this but I need a bit of help from the git
experts.

git-subtree add accepts either a refspec or a path to a repository and a
refspec.  With one positional option, git-subtree add simply assumes
it's a refspec.  Is there an easy way to check whether a string is a
proper refspec?  Even better would be a way to check if a string is a
path to a git repository.

 -David
--
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 subtree error (just how do you expect me to merge 0 trees?)

[greened]

Drew Crawford d...@drewcrawfordapps.com writes:

 Ideally it would be better to emit an error-message from a script
 higher up the calling chain that would be more descriptive about the
 problem (such as suggesting no branch is specified).--

Ok, I used git rev-parse --verify and I have this working now.  Will
send to Junio in the batch with fixes from other folks.

Thanks for catching this!

 -David
--
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] DESTDIR support in contrib/subtree/Makefile

[greened]

Adam Tkac at...@redhat.com writes:

 Signed-off-by: Adam Tkac at...@redhat.com
 ---

 It is a good habit in Makefiles to honor DESTDIR variable to support

 `make DESTDIR=/instalroot install`

 syntax.

 Comments are welcomed.

Applied.  I'll be sending this to the mailing list tonight or tomorrow.

 -David
--
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] For git-subtree, when installing docs (make install-doc), create man1 folder first.

[greened]

Junio C Hamano gits...@pobox.com writes:

 Jesper L. Nielsen lya...@gmail.com writes:

 From: Jesper L. Nielsen lya...@gmail.com

 Hi..

 I installed Git subtree and discovered that the if the man1dir doesn't exist 
 the man-page for Git Subtree is just called man1.

 So, small patch to create the folder first in the Makefile. Hope everything 
 is right with the patch and submitting of the patch.

 Best Regards
 Jesper

 Signed-off-by: Jesper L. Nielsen lya...@gmail.com
 ---

 Thanks.  David, Ack?

Yep.  I can add it to my queue which I'll send to you tomorrow.
Otherwise, feel free to apply it to your copy.

   -David
--
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] For git-subtree, when installing docs (make install-doc), create man1 folder first.

[greened]

Jesper L. Nielsen lya...@gmail.com writes:

 So, small patch to create the folder first in the Makefile. Hope
 everything is right with the patch and submitting of the patch.

I've applied this to my local copy and will send it to the list for
integration.

Thanks for fixing this!

 -David
--
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] git-subtree: ignore git-subtree executable

[greened]

Michael Schubert msc...@elegosoft.com writes:

 Signed-off-by: Michael Schubert msc...@elegosoft.com

Obviously good.  Applied and will send for integration.

-David
--
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 subtree error (just how do you expect me to merge 0 trees?)

[greened]

Junio C Hamano gits...@pobox.com writes:

 With one positional option, git-subtree add simply assumes
 it's a refspec.  Is there an easy way to check whether a string is a
 proper refspec?  Even better would be a way to check if a string is a
 path to a git repository.

 Do you literally mean a path to a repository in the above, or do
 you mean a remote that is like what is accepted by 'git fetch'?

It's the latter as git-subtree calls git-fetch to do the work of
getting revisions.

 On the other hand, if you mean the command takes a remote and an
 optional list of refspecs just like git fetch does, then I am not
 sure it is a good design in the first place to allow refspecs
 only, if only to keep the interface similar to git fetch (you
 cannot omit remote and give refspecs, as you cannot interpret
 refspecs without knowing in the context of which remote they are to
 be interpreted).

If just a refspec is given, git-subtree does a rev-parse in the current
directory and that seems to work fine.  It's what I as a user would
expect to happen.

 I would imagine you could disambiguate and default to origin or
 something when you guessed that remote was omitted if you really
 wanted to, with a syntacitical heuristics, such as a refspec will
 never have two colons in it, a URL tends to begin with a short
 alphabet word, a colon and double-slash, etc.

Hmm...I haven't added code to verify the repository/remote argument if
given.  I suppose a rev-parse --verify would suffice?

-David
--
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 1/8] Use %B for Split Subject/Body

[greened]

David A. Greene gree...@obbligato.org writes:

 From: Techlive Zheng techlivezh...@gmail.com

 Use %B to format the commit message and body to avoid an extra newline
 if a commit only has a subject line.

Wow.  So that was a spectacular fail.  Sorry about th duplicate patch
e-mails.  I have no idea how that happened.

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

libgit2 status

[greened]

What is the status of libgit2 WRT the overall git project?  I recall
that there was some discussion of basing bits of git on libgit2 once it
matures.

I ask because I'm starting a project to improve the abysmal speed of
git-subtree split.  It's unbearably slow at the moment and as far as I
can puzzle out it's due almost entirely to repeated subshell invocations
to run git commands.

I was planning on doing some experiments rewriting bits of git-subtree
using libgit2 but I want to make sure that that isn't wasted work.  It
appears to be exactly what I need to code bits of git-subtree natively.

Thoughts?

-Dave
--
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] subtree.sh: Use raw subject and body modifier %B instead of %s%n%n%b

[greened]

Techlive Zheng techlivezh...@gmail.com writes:

 %s%n%n%b is not always equal to %B. If the commit msg does not have
 a body, this will append an extra new-line character to the msg title
 which would cause the splited commit has a new sha1 hash. In most cases,
 this does not matter, but for a project which did not merged using this
 script initially, the 'split' command would not genereate the same
 commits as the orginal which may cause conflicts.

 Signed-off-by: Techlive Zheng techlivezh...@gmail.com
 ---
  contrib/subtree/git-subtree.sh | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
 index 920c664..5598210 100755
 --- a/contrib/subtree/git-subtree.sh
 +++ b/contrib/subtree/git-subtree.sh
 @@ -296,7 +296,7 @@ copy_commit()
   # We're going to set some environment vars here, so
   # do it in a subshell to get rid of them safely later
   debug copy_commit {$1} {$2} {$3}
 - git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%s%n%n%b' 
 $1 |
 + git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%B' $1 |
   (
   read GIT_AUTHOR_NAME
   read GIT_AUTHOR_EMAIL

This looks good to me.  I assume this passes all the tests.  Can you add
a test for this bug so we don't regress?  Junio, I am good with this
patch as soon as we get a test for the problem.

Thanks!

 -Dave
--
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: A possible subtree split bug

[greened]

Fabien POTENCIER fabien.potenc...@gmail.com writes:

 According to the docs:

 Repeated splits of exactly the same history are
 guaranteed to be identical (ie. to produce the same
 commit ids).  Because of this, if you add new commits
 and then re-split, the new commits will be attached as
 commits on top of the history you generated last time...

 But unfortunately, that's not always the case.

 I've found that if you have a commit that reverts the previous one and
 then merge a branch where those two commits did not exist, then the
 next time you split, they won't be present anymore in the split tree.

I'm not entirely sure that they history *should* be the same in the
presence of a merge.  It's certainly not the same history as when
the original split was done so I don't think guarantee holds.

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