Re: Sort output of diff --stat?

[Robert Dailey]

On Wed, Oct 17, 2018 at 1:47 PM Jeff King  wrote:
> Hmm, I feel like another person asked for this recently, but I can't
> seem to find the thread.

Is it this one?
https://www.mail-archive.com/git@vger.kernel.org/msg159212.html

That's the only one I was able to find, but no one replied. Thanks for
your insight. I didn't get my hopes up, but maybe someday it'll be
added.

Sort output of diff --stat?

[Robert Dailey]

I'd like to sort the output of `git diff --stat` such that files are
listed in descending order based on number of lines changed. The
closest solution I've found online[1] has several readability issues.
I'd rather see a built-in solution in git, if one exists. Can anyone
recommend a solution?

[1]: https://gist.github.com/jakub-g/7599177

Re: Automatic core.autocrlf?

[Robert Dailey]

On Wed, Aug 29, 2018 at 11:54 PM Jonathan Nieder  wrote:
>
> Hi,
>
> Robert Dailey wrote:
>
> > Is there an 'auto' setting for the 'core.autocrlf' config? Reason I
> > ask is, I want that setting to be 'input' on linux but 'true' on
> > Windows.
>
> Others are exploring your question about the configuration language,
> but I want to emphasize some other ramifications.
>
> Why do we still have 'core.autocrlf'?  Do 'core.eol' and related
> settings take care of that need, or is autocrlf still needed?  If
> core.eol etc do not take care of this need, what should we do to get
> them to?
>
> Thanks, after having run into a few too many autocrlf-related messes,
> Jonathan

>From my perspective, the confusion is due to the evolution of the
feature. There's multiple ways to control EOL handling but most of it
is legacy/backward compatibility, I think. core.autocrlf is a
fall-back for repos that do not have a .gitattributes. Because
.gitattributes is optional by design, I'm not sure if getting rid of
the config options is a good idea. But your point did make me think
about how `core.autocrlf = true` should probably be a system config
default for the Git for Windows project. The default for that value
should be platform-defined. That would make it automatically work the
way I want, and might solve a lot of the issues where people are
committing CRLF into repositories on Windows.

Re: Automatic core.autocrlf?

[Robert Dailey]

On Mon, Aug 27, 2018 at 12:32 PM Andrei Rybak  wrote:
>
> On 2018-08-27 17:52, Duy Nguyen wrote:
> > On Mon, Aug 27, 2018 at 5:37 PM Torsten Bögershausen  wrote:
> >>> In those cases, when it falls back to
> >>> configuration for line ending management, I want it to be
> >>> automatically configured based on the host platform.
> >>
> >
> > An alternative is supporting conditional config includes based on
> > platform or host name, but I don't know if there are more use cases
> > like this to justify it.
> >
>
> How about just using unconditional includes?
>
> global.gitconfig (synced across machines):
>
>   [include]
>   path = platform-specific.gitconfig
>
> And two version of file named "platform-specific.gitconfig", which
> are not synced, and include only code.autocrlf setting.

I think I tried this some years back, but ended up ditching it because
when you modify settings via `git config --global`, it doesn't put
values in the right files. This is probably the best answer so far
though. It would still be great to have a mechanism that works within
1 file and is friendly to the git config command.

Re: Automatic core.autocrlf?

[Robert Dailey]

On Mon, Aug 27, 2018 at 10:53 AM Duy Nguyen  wrote:
>
> On Mon, Aug 27, 2018 at 5:37 PM Torsten Bögershausen  wrote:
> > > In those cases, when it falls back to
> > > configuration for line ending management, I want it to be
> > > automatically configured based on the host platform.
> >
> > There is
> > git config core.eol native
>
> An alternative is supporting conditional config includes based on
> platform or host name, but I don't know if there are more use cases
> like this to justify it.

To Torsten's comment: Yes, I've looked at git-config. it doesn't have
the answer to my question there, hence I posted on the mailing list.
To your point, eol being native doesn't matter if text=auto can't be
simulated. If there was a version of `autocrlf` that set `eol=native`
and `text=auto`, that would work as well. But the `true` setting sets
`text=auto` and `eol=crlf`.

Duy: There are more use cases I've run into, but they are not related to the OP:

* Different user email between machines (work vs personal)
* Different tooling on platform (e.g. `nano` on Ubuntu, Notepad++ on Windows)

Centralizing .gitconfig, especially when you have tons of aliases,
becomes more important. 95% of my .gitconfig is platform-agnostic, if
there was an `#ifdef` mechanism, per your suggestion, this would allow
a lot more flexibility. Maybe I should have worded my OP more in terms
of platform-specific configuration sections, instead of specifically
about autocrlf, since that's just one symptom of the real problem.

Automatic core.autocrlf?

[Robert Dailey]

Is there an 'auto' setting for the 'core.autocrlf' config? Reason I
ask is, I want that setting to be 'input' on linux but 'true' on
Windows. I have a global .gitconfig that I sync across different
platforms with Google Drive, and I hate to manage 2 copies of it on
each platform (linux and Windows). If there's some way to make the
line ending configuration the same between both, that would be
awesome.

Note that I do rely mostly on git attributes files for this, however
not all upstream repositories have one, and I don't always have
permission to create one there. In those cases, when it falls back to
configuration for line ending management, I want it to be
automatically configured based on the host platform.

Any advice is appreciated here. Unfortunately Google isn't much help
on this topic, Stack Overflow is a swamp full of different information
and none of it seems authoritative.

Re: Fetch on submodule update

[Robert Dailey]

On Mon, Aug 6, 2018 at 10:41 AM, Jonathan Nieder  wrote:
> Robert Dailey wrote:
>
>>  Automatic would be
>> great if submodules were treated as integrated in a similar manner to
>> subtree, but it's not there. I wasn't aware that `submodule update`
>> did a fetch, because sometimes if I do that, I get errors saying SHA1
>> is not present (because the submodule did not get fetched). Granted I
>> haven't seen this in a while, so maybe the fetch on submodule update
>> is a newer feature. Do you know what triggers the fetch on update
>> without --remote? Is it the missing SHA1 that triggers it, or is it
>> fetching unconditionally?
>
> Thanks for this and the rest of the context you sent.  It's very
> helpful.
>
> The relevant code in git-submodule.sh is
>
> # Run fetch only if $sha1 isn't present or it
> # is not reachable from a ref.
> is_tip_reachable "$sm_path" "$sha1" ||
> fetch_in_submodule "$sm_path" $depth ||
> say "$(eval_gettext "Unable to fetch in submodule path 
> '\$displaypath'")"
>
> # Now we tried the usual fetch, but $sha1 may
> # not be reachable from any of the refs
> is_tip_reachable "$sm_path" "$sha1" ||
> fetch_in_submodule "$sm_path" $depth "$sha1" ||
> die "$(eval_gettext "Fetched in submodule path '\$displaypath', but 
> it did not contain \$sha1. Direct fetching of that commit failed.")"
>
> The fallback to fetching by SHA-1 was introduced in v2.8.0-rc0~9^2
> (submodule: try harder to fetch needed sha1 by direct fetching sha1,
> 2018-02-23).

Yep, that's the root cause; I was basing my concerns on a legacy
issue. I just had avoided using `update` when I expected a fetch, so I
never saw the issue again, and thus didn't realize it was corrected.
Very helpful. Thanks again!

Re: Fetch on submodule update

[Robert Dailey]

On Thu, Aug 2, 2018 at 1:08 AM, Jonathan Nieder  wrote:
> I think I misread this the first time.  I got distracted by your
> mention of the --remote option, but you mentioned you want to use the
> SHA-1 of the submodule listed, so that was silly of me.
>
> I think you'll find that "git fetch --no-recurse-submodules" and "git
> submodule update" do exactly what you want.  "git submodule update"
> does perform a fetch (unless you pass --no-fetch).
>
> Let me know how it goes. :)
>
> I'd still be interested in hearing more about the nature of the
> submodules involved --- maybe `submodule.fetchJobs` would help, or
> maybe this is a workflow where a tool that transparently fetches
> submodules on demand like
> https://gerrit.googlesource.com/gitfs/+/master/docs/design.md would be
> useful (I'm not recommending using slothfs for this today, since it's
> read-only, but it illustrates the idea).

Hi thanks for your response, sorry I am a bit late getting back with you.

Maybe my workflow is dated, because I'm still used to treating
submodules as distinctly separated and independent things. I realize
submodule recursion is becoming more inherent in many high level git
commands, but outside of git there are separation issues that make
this workflow doomed to be non-seamless. For example, pull requests
will never offer the same uniformity: You will still have 1 pull
request per submodule. There's also the issue of log audits: You
cannot use blame, log, bisect, or other "diagnostic" commands to
introspect into submodules "as if" they were subtree or something of
the like (i.e. truly part of the DAG). A more realistic example of one
of the common questions I still can't answer easily is: "How do you
determine which commit in a submodule made it into which release of
the software?" In the case where the parent repository has the
annotated tags (representing software release milestones), and the
submodule is just a common library (which does not have those tags and
has no release cycle). Anyway, none of these issues are particularly
related but they do contribute to the answer to your question
regarding my workflow and use cases. The list goes on but I hope you
get the idea.

Some of the more functional issues are performance related: I am aware
enough, at times, that I can save time (in both local operations and
network overhead) by skipping submodules. For example, if I know that
I'm merging mainline branches, I do not need to mess with the
submodules (I can fetch, merge, commit, push from the parent repo
without messing with the submodules. This saves me time). If
`fetchJobs` was also `updateJobs`, i.e. you could update submodules in
parallel too, that might make this less of an issue. Think of
repositories [like boost][1] that have (I think) over a hundred
sibling submodules: Fetching 8 in parallel *and* doing `submodule
update` in parallel 8 times might also speed things up. There's also
`git status`, that if it recurses into submodules, is also
significantly slow in the boost case (I'm not sure if it is
parallelized).

Again, none of this is particularly related, but just to give you more
context on the "why" for my ask. Sorry if I'm dragging this out too
far.

The TLDR is that I do prefer the manual control. Automatic would be
great if submodules were treated as integrated in a similar manner to
subtree, but it's not there. I wasn't aware that `submodule update`
did a fetch, because sometimes if I do that, I get errors saying SHA1
is not present (because the submodule did not get fetched). Granted I
haven't seen this in a while, so maybe the fetch on submodule update
is a newer feature. Do you know what triggers the fetch on update
without --remote? Is it the missing SHA1 that triggers it, or is it
fetching unconditionally?

Thanks for confirming it behaves as I already wanted. And as you can
tell, I'm also happy to further discuss motivation / use cases /
details related to overall usage of submodules if you'd like. I'm
happy to help however I can!

[1]: https://github.com/boostorg/boost

Fetch on submodule update

[Robert Dailey]

Problem: I want to avoid recursively fetching submodules when I run a
`fetch` command, and instead defer that operation to the next
`submodule update`. Essentially I want `fetch.recurseSubmodules` to be
`false`, and `get submodule update` to do exactly what it does with
the `--remote` option, but still use the SHA1 of the submodule instead
of updating to the tip of the specified branch in the git modules
config.

I hope that makes sense. The reason for this ask is to
improve/streamline workflow in parent repositories. There are cases
where I want to quickly fetch only the parent repository, even if a
submodule changes, to perform some changes that do not require the
submodule itself (yet). Then at a later time, do `submodule update`
and have it automatically fetch when the SHA1 it's updating to does
not exist (because the former fetch operation for the submodule was
skipped). For my case, it's very slow to wait on submodules to
recursively fetch when I only wanted to fetch the parent repo for the
specific task I plan to do.

Is this possible right now through some variation of configuration?

Patch add: previous hunk across file boundaries

[Robert Dailey]

I noticed that when stepping into a new file while doing `git add -p`,
pressing `k` or `K` does not go back to the previous file. Is this a
bug? Is there a setting for it? I googled & checked out the git docs,
I didn't find any specific information on this.

Re: Need help debugging issue in git

[Robert Dailey]

On Mon, Apr 2, 2018 at 1:53 AM, Johannes Sixt <j...@kdbg.org> wrote:
> Am 02.04.2018 um 02:36 schrieb Robert Dailey:
>>
>> I'm struggling with a bug that I found introduced in git v2.13.2. The
>> bug was not reproducible in v2.13.1. The issue is that using arguments
>> like "@{-1}" to aliases causes those curly braces to be removed, so
>> once the command is executed after alias processing the argument looks
>> like "@-1". This breaks any aliases you have that wrap `git log` and
>> such. I originally opened the bug on the Git for Windows project
>> (since I use Git mostly on Windows):
>>
>> https://github.com/git-for-windows/git/issues/1220
>
> ...
>>
>> Here is the alias being used for a test:
>>
>> [alias]
>>  lgtest = !git log --oneline \"$@\"
>>
>> And here is the command I invoke for the test:
>>
>> $ git lgtest @{-1}
>>
>> I should get logs for the previously-checked-out branch.
>>
>> When `prepare_shell_cmd()` is called in run-command.c, it gets expanded
>> like so:
>>
>> + [0] "sh" const char *
>> + [1] "-c" const char *
>> + [2] "git log --oneline \"$@\" \"$@\"" const char *
>> + [3] "git log --oneline \"$@\"" const char *
>> + [4] "@{-1}" const char *
>>
>> With my modifications (again, patch inline below) I get this:
>>
>> + [0] "sh" const char *
>> + [1] "-c" const char *
>> + [2] "git log --oneline \"$@\"" const char *
>> + [3] "@{-1}" const char *
>>
>> The second version looks much better.
>
>
> But this is wrong. Try this on the command line:
>
>   sh -c 'echo "$@"' a b c
>
> Notice how this prints only 'b c', not 'a b c'. The reason is that the
> argument 'a' is treated like a "script" name, i.e. what you get for "$0",
> and 'b' and 'c' as the actual arguments to the "script".
>
> That is, you must fill in some dummy "script" name at slot [3], and
> run_command chooses to put the alias text there.
>
>> I think the constant nesting of
>> commands inside each other that the first version does is somehow
>> causing curly braces to be removed. I don't understand enough about
>> shell processing to know why it would do this.
>
>
> Some shells expand the curly braces. They must get lost somewhere by one of
> the two shell invocations that happen on the way.
>
> BTW, you don't happen to have a file named '@-1' in your directory, most
> likely by accident?

Thanks for your help. I checked for @-1 but I do not have a file with
that name (good catch though). I contacted the MinGW mailing list and
they seem to indicate that {-1} is a valid brace expansion. I was able
to verify the git.exe code itself is not causing this problem. It
seems to be GNU bash doing it. But oddly enough, the Ubuntu version of
Bash for example does not process {-1} as a brace expansion. It seems
weird to me that Git uses a syntax for a portion of its revision
specification that could be ambiguously treated as syntax processed by
Bash. In other words, I feel like this would have been designed into
Git years ago, so I'm not sure why this is a problem now all of a
sudden.

Their suggested solution was to start quoting items in the list or
escaping the braces, but that will make git revisions less intuitive
to use and make commands more tedious to type. I am still discussing
things over there but for the purposes of the Git mailing list, I
think it's clear at this point this is not an issue with Git itself.
Having said that, thanks again for the help!!

Re: [PATCH] Support long format for log-based submodule diff

[Robert Dailey]

On Tue, Mar 27, 2018 at 5:17 PM, Stefan Beller  wrote:
>> >> $ git diff --submodule=log --submodule-log-detail=(long|short)
>> >>
>> >> I'm not sure what makes sense here. I welcome thoughts/discussion and
>> >> will provide follow-up patches.
>> >
>> > The case of merges is usually configured with --[no-]merges, or
>> > --min-parents=.
>
>> But that is a knob that controls an irrelevant aspect of the detail
>> in the context of this discussion, isn't it?  This code is about "to
>> what degree the things that happened between two submodule commits
>> in an adjacent pair of commits in the superproject are summarized?"
>
> And I took it a step further and wanted to give a general solution, which
> allows giving any option that the diff machinery accepts to only apply
> to the submodule diffing part of the current diff.
>
>> The hack Robert illustrates below is to change it to stop favouring
>> such projects with "clean" histories, and show "log --oneline
>> --no-merges --left-right".  When presented that way, clean histories
>> of topic-branch based projects will suffer by losing conciseness,
>> but clean histories of totally linear projects will still be shown
>> the same way, and messy history that sometimes merges, sometimes
>> merges mergy histories, and sometimes directly builds on the trunk
>> will be shown as an enumeration of individual commits in a flat way
>> by ignoring merges and not restricting the traversal to the first
>> parent chains, which would appear more uniform than what the current
>> code shows.
>
> Oh, I realize this is in the *summary* code path, I was thinking about the
> show_submodule_inline_diff, which would benefit from more diff options.
>
>> I do not see a point in introducing --min/max-parents as a knob to
>> control how the history is summarized.
>
> For a summary a flat list of commits may be fine, ignoring
> (ideally non-evil) merges.
>
>> This is a strongly related tangent, but I wonder if we can and/or
>> want to share more code with the codepath that prepares the log
>> message for a merge.  It summarizes what happened on the side branch
>> since it forked from the history it is joining back to (I think it
>> is merge.c::shortlog() that computes this)
>
> I do not find code there. To me it looks like builtin/fmt-merge-msg.c
> is responsible for coming up with a default merge message?
> In that file there is a shortlog() function, which walks revisions
> and puts together the subject lines of commits.
>
>> and it is quite similar
>> to what Robert wants to use for submodules here.  On the other hand,
>> in a project _without_ submodule, if you are pulling history made by
>> your lieutenant whose history is full of linear merges of topic
>> branches to the mainline, it may not be a bad idea to allow
>> fmt-merge-msg to alternatively show something similar to the "diff
>> --submodule=log" gives us, i.e. summarize the history of the side
>> branch being merged by just listing the commits on the first-parent
>> chain.  So I sense some opportunity for cross pollination here.
>
> The cross pollination that I sense is the desire in both cases to freely
> specify the format as it may depend on the workflow.

First I want to apologize for having taken so long to get back with
each of you about this. I actually have a lot of work started to
expand the --submodule option to add a "full-log" option in addition
to the existing "log". This is a pretty big task for me already,
mostly because I'm unfamiliar with git and have limited personal time
to do this at home (this is part of what I am apologizing for). I kind
of get what Stefan and Junio are saying. There's a lot of opportunity
for cleanup. More specific to my use case, adding some functionality
to generate a log message (although I've developed a bash script to do
this since I wrote my original email. I'll attach it to this email for
those interested). Also I get that taking this a notch higher and
adding a new option to pass options down to submodules also addresses
my case. Before I waste anyone's time on this, I want to make sure
that my very narrow and specific implementation will be ideal. By all
means I do not want to do things the easy way which ends up adding
"cruft" you'll have to deal with later. If there's a larger effort to
generalize this and other things related to submodules maybe I can
just wait for that to happen instead? What direction would you guys
recommend?

Junio basically hit the nail on the head with the comparisons of
different mainlines. I think some repositories are more disciplined
than others. At my workplace, I deal with a lot of folks that aren't
interested in learning git beyond the required day to day
responsibilities. It's difficult to enforce very specific branching,
rebase, and merge habits. As such, the best I can do to work around
that for building release notes is to exclude merge commits (since
most of the time, people keep the default message which is generally

Need help debugging issue in git

[Robert Dailey]

I'm struggling with a bug that I found introduced in git v2.13.2. The
bug was not reproducible in v2.13.1. The issue is that using arguments
like "@{-1}" to aliases causes those curly braces to be removed, so
once the command is executed after alias processing the argument looks
like "@-1". This breaks any aliases you have that wrap `git log` and
such. I originally opened the bug on the Git for Windows project
(since I use Git mostly on Windows):

https://github.com/git-for-windows/git/issues/1220

After digging into the code of run-command.c some more, I have a
change that fixes the issue but it doesn't feel like the right
solution. Furthermore, the function I'm modifying doesn't seem to have
been changed in the diff between v2.13.1 and v2.13.2. I'll provide my
diff at the bottom of this email for those curious as to what I've
modified.

I was not able to reproduce this bug on Linux. However, the way
aliases get expanded seems extremely wasteful. Essentially if an alias
already has $@ in it, Git shouldn't try to insert another one. This
results in the alias being repeated multiple times. I'll give you an
example (Note there's a ton of detail in the github post linked
earlier, and most of this is already there).

Here is the alias being used for a test:

[alias]
lgtest = !git log --oneline \"$@\"

And here is the command I invoke for the test:

$ git lgtest @{-1}

I should get logs for the previously-checked-out branch.

When `prepare_shell_cmd()` is called in run-command.c, it gets expanded like so:

+ [0] "sh" const char *
+ [1] "-c" const char *
+ [2] "git log --oneline \"$@\" \"$@\"" const char *
+ [3] "git log --oneline \"$@\"" const char *
+ [4] "@{-1}" const char *

With my modifications (again, patch inline below) I get this:

+ [0] "sh" const char *
+ [1] "-c" const char *
+ [2] "git log --oneline \"$@\"" const char *
+ [3] "@{-1}" const char *

The second version looks much better. I think the constant nesting of
commands inside each other that the first version does is somehow
causing curly braces to be removed. I don't understand enough about
shell processing to know why it would do this.

Essentially I don't feel like I'm addressing the root cause here. I
hope that someone has the time to take a peek and point me in the
right direction. If I can make sense of this maybe I can make a proper
fix somewhere.

Here is the patch:

diff --git a/run-command.c b/run-command.c
index 31fc5ea86e..39bab7f5b2 100644
--- a/run-command.c
+++ b/run-command.c
@@ -261,10 +261,10 @@ static const char **prepare_shell_cmd(struct
argv_array *out, const char **argv)
  if (!argv[1])
  argv_array_push(out, argv[0]);
  else
- argv_array_pushf(out, "%s \"$@\"", argv[0]);
+ argv_array_pushf(out, "%s", argv[0]);
  }

- argv_array_pushv(out, argv);
+ argv_array_pushv(out, argv+1);
  return out->argv;
 }

Re: Rename of file is causing changes to be lost

[Robert Dailey]

On Tue, Mar 13, 2018 at 11:51 AM, Elijah Newren  wrote:
> Anyway, I recorded this at
> https://bugs.chromium.org/p/git/issues/detail?id=11.  Sorry I don't
> have a workaround, but I'll try to eventually get back to this and fix
> it.

Thank you for taking the time to verify this for me. I will keep an
eye on the issue you linked!

Re: Rename of file is causing changes to be lost

[Robert Dailey]

On Thu, Mar 8, 2018 at 10:01 AM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> I'm on Windows and core.ignorecase is set to 'true' when I clone/init
> a repository. I've got a branch where I started making changes to a
> file AND renamed it only to change its case. The changes I've made
> were significant enough that git no longer detects a rename, instead
> the files show up as "D" and "A" in git status (deleted then added).
> To correct this, I do an interactive rebase to add an additional
> commit before the first one to rename the file without changing it,
> and *then* allow the second commit to change the file. The goal is
> that rebase should detect the rename and automatically move the
> changes in the (now) second commit to the newly named file. Here's a
> MCVE (treat this as a script):
>
> #/bin/bash
> git init testgitrepo
> cd testgitrepo/
> git config core.ignorecase true # This is set by Windows for me, but
> hopefully will allow this to repro on linux. Didn't test linux though.
> echo "first change" > foo.txt
> git add . && git commit -m 'first change'
> git checkout -b topic
> echo "second change" > foo.txt
> git mv foo.txt FOO.txt
> git add . && git commit -m 'second change'
> git rebase -i master # Move line 1 to line 2, and put "x false" in line 1
> git mv foo.txt FOO.txt && git commit -m 'rename foo'
> git rebase --continue
> git mergetool
>
> After the rebase continue, you will get a conflict like so:
>
> error: could not apply 527d208... second change
>
> When you have resolved this problem, run "git rebase --continue".
> If you prefer to skip this patch, run "git rebase --skip" instead.
> To check out the original branch and stop rebasing, run "git rebase --abort".
>
> Could not apply 527d208... second change
> CONFLICT (rename/delete): foo.txt deleted in 527d208... second change
> and renamed to FOO.txt in HEAD. Version HEAD of FOO.txt left in tree.
>
> The last command, `git mergetool` runs, giving you the option to pick
> the Created (left) or Deleted (right) version of the file:
>
> Left: The file is created, but selecting this erases the changes from
> the "added" version on the remote (which is topic). Basically the
> rename of only case confused git, and we lost the changes on the
> remote version of the file
> Right: File is deleted. Changes are still lost.
>
> The ideal outcome is that the changes from the "added" version of the
> file in the 2nd commit get carried over to the "renamed" version of
> the file, which when you compare the two are named exactly the same
> after the 1st commit is introduced. How can I solve this issue?

I wanted to bump this and see if anyone would have a spare few minutes
to help me out with this. I know it's a needlessly complex situation,
but I'd really love to know how to resolve the specific issue, or
perhaps learn a better way to approach this in the future if I'm
shooting myself in the foot here.

Thanks again.

Rename of file is causing changes to be lost

[Robert Dailey]

I'm on Windows and core.ignorecase is set to 'true' when I clone/init
a repository. I've got a branch where I started making changes to a
file AND renamed it only to change its case. The changes I've made
were significant enough that git no longer detects a rename, instead
the files show up as "D" and "A" in git status (deleted then added).
To correct this, I do an interactive rebase to add an additional
commit before the first one to rename the file without changing it,
and *then* allow the second commit to change the file. The goal is
that rebase should detect the rename and automatically move the
changes in the (now) second commit to the newly named file. Here's a
MCVE (treat this as a script):

#/bin/bash
git init testgitrepo
cd testgitrepo/
git config core.ignorecase true # This is set by Windows for me, but
hopefully will allow this to repro on linux. Didn't test linux though.
echo "first change" > foo.txt
git add . && git commit -m 'first change'
git checkout -b topic
echo "second change" > foo.txt
git mv foo.txt FOO.txt
git add . && git commit -m 'second change'
git rebase -i master # Move line 1 to line 2, and put "x false" in line 1
git mv foo.txt FOO.txt && git commit -m 'rename foo'
git rebase --continue
git mergetool

After the rebase continue, you will get a conflict like so:

error: could not apply 527d208... second change

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

Could not apply 527d208... second change
CONFLICT (rename/delete): foo.txt deleted in 527d208... second change
and renamed to FOO.txt in HEAD. Version HEAD of FOO.txt left in tree.

The last command, `git mergetool` runs, giving you the option to pick
the Created (left) or Deleted (right) version of the file:

Left: The file is created, but selecting this erases the changes from
the "added" version on the remote (which is topic). Basically the
rename of only case confused git, and we lost the changes on the
remote version of the file
Right: File is deleted. Changes are still lost.

The ideal outcome is that the changes from the "added" version of the
file in the 2nd commit get carried over to the "renamed" version of
the file, which when you compare the two are named exactly the same
after the 1st commit is introduced. How can I solve this issue?

[PATCH] Support long format for log-based submodule diff

[Robert Dailey]

I am experimenting with a version of submodule diff (using log style)
that prints the commits brought in from merges, while excluding the
merge commits themselves. This is useful in cases where a merge commit's
summary does not fully explain the changes being merged (for example,
for longer-lived branches).

I could have gone through the effort to make this more configurable, but
before doing that level of work I wanted to get some discussion going to
understand first if this is a useful change and second how it should be
configured. For example, we could allow:

$ git diff --submodule=long-log

Or a supplementary option such as:

$ git diff --submodule=log --submodule-log-detail=(long|short)

I'm not sure what makes sense here. I welcome thoughts/discussion and
will provide follow-up patches.

Signed-off-by: Robert Dailey <rcdai...@gmail.com>
---
 submodule.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/submodule.c b/submodule.c
index 2967704317..a0a62ad7bd 100644
--- a/submodule.c
+++ b/submodule.c
@@ -428,7 +428,8 @@ static int prepare_submodule_summary(struct rev_info *rev, 
const char *path,
init_revisions(rev, NULL);
setup_revisions(0, NULL, rev, NULL);
rev->left_right = 1;
-   rev->first_parent_only = 1;
+   rev->max_parents = 1;
+   rev->first_parent_only = 0;
left->object.flags |= SYMMETRIC_LEFT;
add_pending_object(rev, >object, path);
add_pending_object(rev, >object, path);
-- 
2.13.1.windows.2

Re: [RFC PATCH 0/1] Implement CMake build

[Robert Dailey]

On Thu, Jan 25, 2018 at 6:21 PM, Isaac Hier  wrote:
> Hi Jeff,
>
> I have been looking at the build generator, which looks promising, but
> I have one concern. Assuming I can generate a CMakeLists.txt that
> appropriately updates the library sources, etc. how do you suggest I
> handle new portability macros? For example, assume someone adds a
> macro HAVE_X to indicate the availability of some platform-specific
> function x. In the current Makefile, a comment would be added to the
> top indicating when HAVE_X or NO_X should be set, and that option
> would toggle the HAVE_X C macro. But CMake can test for the
> availability of x, which is one of the main motives for adding a CMake
> build. The current build generator uses the output of make, so all it
> would know is whether or not HAVE_X is defined on the platform that
> ran the Makefile, but not the entire list of platform that git
> supports.
>
> Bottom line: should I add the portability tests as they are now,
> without accounting for future portability macros? One good alternative
> might be to suggest the authors of new portability macros include a
> small sample C program to test it. That would allow me to easily patch
> the CMake tests whenever that came up. In a best case scenario, a
> practice could be established to write the test in a specific
> directory with a certain name so that I could automatically update the
> CMake tests from the build generator.

Isaac,

I'm very happy that you have started support for CMake. I have a lot
of experience with it. I'd love to help contribute. Do you have a fork
on github where this code is? I'd have to figure out how to apply a
patch from email, I haven't done it before. I think the goal should be
to replace the existing build system (this can be a transition that
happens slowly). I've been in situations where multiple build systems
are supported in parallel, worst case because of split personal
preferences on a project. That is more counterproductive than asking
the team to just compromise and take the initial hit on learning
curve. Ultimately that's up to the Git community, but that would be my
recommendation. But I think making CMake as complete as possible will
help build that confidence and trust. I can completely understand the
complexities and concerns they have.

Re: Line ending normalization doesn't work as expected

[Robert Dailey]

On Fri, Feb 16, 2018 at 10:34 AM, Torsten Bögershausen <tbo...@web.de> wrote:
> On Thu, Feb 15, 2018 at 09:24:40AM -0600, Robert Dailey wrote:
>> On Tue, Oct 3, 2017 at 9:00 PM, Junio C Hamano <gits...@pobox.com> wrote:
>
> []
>>
>> Sorry to bring this old thread back to life, but I did notice that
>> this causes file modes to reset back to 644 (from 755) on Windows
>> version of Git. Is there a way to `$ git read-tree --empty && git add
>> .` without mucking with file permissions?
>
> No problem with the delay, under the time we had the chance to improve Git:
>
>>Git 2.16 Release Notes
>>==
>>[]
>>* "git add --renormalize ." is a new and safer way to record the fact
>>   that you are correcting the end-of-line convention and other
>>   "convert_to_git()" glitches in the in-repository data.
>
> Could you upgrade to Git 2.16.1 (or higher, just take the latest)
> and try with
> git add --renormalize .
> ?

Thanks for the response. Unfortunately I've deliberately been stuck on
v2.13 because of [a bug in Git for Windows][1] that hasn't yet been
resolved (it's a bug *somewhere*, not sure if it's git related or
not). Curly braces in aliases are being stripped which makes newer
releases unusable for me. I'll try upgrading on a different machine
and see if renormalize works for the case of binary files with file
modes set to 755.

[1]: https://github.com/git-for-windows/git/issues/1220

Re: Line ending normalization doesn't work as expected

[Robert Dailey]

On Thu, Feb 15, 2018 at 1:16 PM, Junio C Hamano  wrote:
> I think the message you are referring to is a tangent that discusses
> how it was done in the old world, with issues that come from the
> fact that with such an approach the paths are first removed from the
> index and then added afresh to the index, which can lose cases and
> executable bits when working on a filesystem that does not retain
> enough information.
>
> The way in the new world is to use "add --renormalize" which was
> added at 9472935d ("add: introduce "--renormalize"", 2017-11-16), I
> think.

Oh I didn't realize someone actually did it. If so, that's awesome.
Thanks Junio!

Re: Line ending normalization doesn't work as expected

[Robert Dailey]

On Tue, Oct 3, 2017 at 9:00 PM, Junio C Hamano  wrote:
> Torsten Bögershausen  writes:
>
>>> $ git rm -r --cached . && git add .
>>
>> (Both should work)
>>
>> To be honest, from the documentation, I can't figure out the difference 
>> between
>> $ git read-tree --empty
>> and
>> $ git rm -r --cached .
>>
>> Does anybody remember the discussion, why we ended up with read-tree ?
>
> We used to use neither, and considered it fine to "rm .git/index" if
> you wanted to empty the on-disk index file in the old world.  In the
> modern world, folks want you to avoid touching filesystem directly
> and instead want you to use Git tools, and the above are two obvious
> ways to do so.
>
> "git read-tree" (without any parameter, i.e. "read these 0 trees and
> populate the index with it") and its modern and preferred synonym
> "git read-tree --empty" (i.e. "I am giving 0 trees and I know the
> sole effect of this command is to empty the index.") are more direct
> ways to express "I want the index emptied" between the two.
>
> The other one, "git rm -r --cached .", in the end gives you the same
> state because it tells Git to "iterate over all the entries in the
> index, find the ones that match pathspec '.', and remove them from
> the index.".  It is not wrong per-se, but conceptually it is a bit
> roundabout way to say that "I want the index emptied", I would
> think.
>
> I wouldn't be surprised if the "rm -r --cached ." were a lot slower,
> due to the overhead of having to do the pathspec filtering that ends
> up to be a no-op, but there shouldn't be a difference in the end
> result.

Sorry to bring this old thread back to life, but I did notice that
this causes file modes to reset back to 644 (from 755) on Windows
version of Git. Is there a way to `$ git read-tree --empty && git add
.` without mucking with file permissions?

An option to ignore submodules in stash push?

[Robert Dailey]

I haven't seen such an option, but I think it would be nice to be able
to ignore submodules when creating a stash. When I stash changes in a
directory, almost always I intend to only stash real files, not
modified submodules. When I pop the stash later, it gets disrupted due
to submodule conflicts. To avoid getting the conflicts in the first
place, it would be nice to somehow specify:

$ git stash push --no-submodules -- MyDirectory/

Would this make sense?

Re: Can't squash merge with merge.ff set to false

[Robert Dailey]

On Fri, Jan 5, 2018 at 2:54 PM, Bryan Turner  wrote:
> The two _aren't_ distinctly separate, though. "git merge --squash
> --ff-only" has very different semantics to "git merge --squash --ff",
> in that it will only create a new squashed commit (or fast-forward a
> single commit) if the incoming commit(s) are fast-forward from the
> target. So there _is_ a setting for the fast-forward mode (given
> "--ff", "--ff-only", and "--no-ff" are a tri-state switch, and
> therefore comprise a single setting) that does impact squashing.

That feels really contrived to me though. For example, when I'm asking
to squash I don't really care about fast forward in that case.
Squashing means I'm expecting a possibly completely new commit with my
collective changes. If I only had one commit on my branch, likely I'd
be aware of that, and would do a fast forward merge or something. I
think the difference here is mind set. And maybe this is just me, but
the mentality when I choose --squash means I want nothing to do with
fast-foward. I don't care about it affecting the operation. If a
fast-foward happens to be the end result, I still don't care. Git made
that decision for me. And all I want is the end result: A single
commit.

Re: Can't squash merge with merge.ff set to false

[Robert Dailey]

On Fri, Jan 5, 2018 at 2:26 PM, Paul Smith <p...@mad-scientist.net> wrote:
> On Fri, 2018-01-05 at 12:12 -0800, Bryan Turner wrote:
>> On Fri, Jan 5, 2018 at 11:59 AM, Robert Dailey <rcdailey.li...@gmail.com> 
>> wrote:
>> > Not sure if this is intended or a bug, but with the following
>> > configuration:
>> >
>> > $ git config --global merge.ff false
>> >
>> > I am not able to merge my topic branch into master with squash
>> > option:
>> >
>> > $ git checkout master
>> > $ git merge --squash topic
>> > fatal: You cannot combine --squash with --no-ff.
>> >
>> > I'm not sure why a non-fast-forward merge would prevent a squash
>> > merge, since by its very nature a squashed merge is not a fast
>> > forward merge (or maybe it is if you only have one commit).
>
> Hah!  I was just thinking of checking the latest Git RC I built
> yesterday to see if this pet peeve of mine has been fixed yet.  I guess
> not!
>
>> The easiest way to move forward is probably to pass "--ff" on the
>> command line to override the config, when you're using "--squash".
>
> That's what we always have to do.  Very annoying; we use squash-merge
> extensively but also want to require ff merge by default.
>
>> As for why the two aren't allowed together, my assumption would be
>> because if you're only squashing a single commit "--squash" and that
>> commit is fast-forward from the target, a new commit is not created
>> and instead the target branch is fast-forwarded. With "--no-ff", it's
>> questionable what "--squash" should do in that case. Fast-forward
>> anyway? Rewrite the commit simply to get new committer details and
>> SHA-1?
>
> If it only failed when you were squash-merging a single commit that was
> also fast-forwardable, I guess that would be one thing.  But even if I
> have multiple commits and I want to squash-merge them, which clearly is
> a separate operation giving different results, I get this error.
>
> I don't think Git should try to be clever here (if that's what it's
> doing--I always assumed it was just a missing configuration case in the
> error check).  If I asked for a squash-merge then Git should give me a
> squash merge.
>
> So in answer to your question, --squash should give me a squash merge
> and the setting of --ff / --no-ff should be completely ignored, as it's
> irrelevant.
>
> My $0.02.

Seems like --ff works, but is also misleading since in my case (more
than one commit) I'm not doing a ff merge and there's no possibility
of it. I think your idea of the 2 being distinctly separate makes
sense. Basically, --squash takes precedence and if the mechanism to
implement squash in certain scenarios (such as single commit) is
fast-forward merge, then that decision is made for the user and is no
longer something they can control.

Can't squash merge with merge.ff set to false

[Robert Dailey]

Not sure if this is intended or a bug, but with the following configuration:

$ git config --global merge.ff false

I am not able to merge my topic branch into master with squash option:

$ git checkout master
$ git merge --squash topic
fatal: You cannot combine --squash with --no-ff.

I'm not sure why a non-fast-forward merge would prevent a squash
merge, since by its very nature a squashed merge is not a fast forward
merge (or maybe it is if you only have one commit).

Is there an issue here? I like fast forward merges to be off by
default, since I want to control when they happen. Most of my merges
do not use --squash, so I'm catering to the common case.

Need advice on how to get past this issue. Thanks in advance.

Previous hunk in different file during add --patch

[Robert Dailey]

I keep expecting that pressing K during patch add that it will cross
file boundaries and go to previous hunks in files before the current
one. However, it reports "no hunks" when reaching the top hunk in the
current file. Is there a way to go to the previous file?

Usability issue with rebase fork-point option

[Robert Dailey]

When upstream is not specified for the rebase command (e.g. I just do
`git rebase`), `--fork-point` is assumed which results in commits
regenerating SHA1 even if the merge-base would otherwise be identical.

Here's my scenario:

I set my remote tracking branch to my parent branch:

$ git branch -u origin

I do a status to see that I'm 1 ahead:

$ git status -sb
## feature/foo...origin/master [ahead 1]

I then execute `git rebase`:

$ git rebase
First, rewinding head to replay your work on top of it...
Applying: Fix state machine hang after integrity checking

Since my merge-base is already the tip of `origin/master`, I expected
it to say it was up-to-date, as it would if I disabled fork point:

$ git rebase --no-fork-point
Current branch feature/foo is up to date.


The expected behavior is that if merge-base does not change, even with
--fork-point enabled, that SHA1's do not get rewritten.

As a workaround, I've created an alias that always assumes --no-fork-point:

[alias]
rb = rebase --no-fork-point


Possible long term solutions I'd be happy with:

1. A config option to disable fork point completely, something like
`rebase.forkPoint` and I can set it to `false`.
2. Change rebase to always assume `--no-fork-point` as a default,
which is opposite of the current behavior.
3. Assuming the behavior I'm observing is a bug, put more priority on
a matching merge-base instead of the reflogs, not sure of the
internals of how this fork-point behavior is implemented, but this
feels like the issue to me. The most ideal outcome is that this is a
bug and no interface or config changes are needed.

Would love to get feedback from the Git community on this. Thanks for reading!!

How to resolve mixture of modified and deleted conflicts easily in git?

[Robert Dailey]

When doing a rebase, sometimes I will get `DU` and `UU` conflicts
(locally deleted and locally modified, respectively). Furthermore, in
some of these cases, I want to take "ours" for all conflicts,
including ones where the local file is deleted. Ideally, it's just one
command:

$ git checkout --ours .

However, this fails for the locally deleted conflicts:

error: path 'foo.xml' does not have our version

Even more annoyingly, the fact that these failures occur prevents the
`UU` conflicts from being resolved. The whole operation fails
atomically. I am not aware of a straightforward and uniform way to
resolve conflicts with "ours" during a rebase when locally deleted
files exist in the list of conflicts. What is the most elegant
solution in this situation?

I'm running Git for Windows v2.13.1.

Multiple ways to undo changes to a file in the tip commit

[Robert Dailey]

Suppose the tip commit of my branch contains changes to multiple
files. If I want to revert all changes in one file from that commit, I
have two options that I know of:

$ git reset @^ -- foo.txt
$ git commit --amend --no-edit
$ git checkout -- foo.txt

Or:

$ git checkout @^ -- foo.txt
$ git commit --amend --no-edit

For simpler steps, I normally use the latter option. However, is there
value in the former option (using reset)? When would you use one or
the other?

Disclaimer: I just typed up the above commands, I might have some
details wrong, but hopefully you get the gist of it.

Thanks in advance.

Re: Line ending normalization doesn't work as expected

[Robert Dailey]

On Wed, Oct 4, 2017 at 11:59 AM, Jonathan Nieder <jrnie...@gmail.com> wrote:
> Hi Robert,
>
> Robert Dailey wrote:
>
>> You guys are obviously worlds ahead of me on the internals of things,
>> but from my perspective I like to avoid the "plumbing" commands as
>> much as I can.
>
> I suspect what we are dancing around is the need for some command like
>
> git checkout --renormalize .
>
> which would shorten the sequence to
>
> git checkout --renormalize .
> git status; # Show files that will be normalized
> git commit; # Commit the result
>
> What do you think?  Would you be interested in writing a patch for it?
> ("No" is as always an acceptable answer.)

I wish I could, but ultimately I'd probably not be able to do it. I
rarely have time to do recreational coding outside of work these days.

That aside, for now I want to know the proper & recommended method to
renormalize line endings using existing commands. Additionally I also
am interested in knowing why only 1 of the 3 solutions I tried (In my
OP) worked but the others didn't. My short term goal is just to get
educated a bit. There's so much conflicting and variable information
on this topic on Google. It makes it difficult to find the one true
path, especially since Git evolves and improves over time and
information usually becomes stale.

Re: Line ending normalization doesn't work as expected

[Robert Dailey]

On Tue, Oct 3, 2017 at 9:00 PM, Junio C Hamano  wrote:
> Torsten Bögershausen  writes:
>
>>> $ git rm -r --cached . && git add .
>>
>> (Both should work)
>>
>> To be honest, from the documentation, I can't figure out the difference 
>> between
>> $ git read-tree --empty
>> and
>> $ git rm -r --cached .
>>
>> Does anybody remember the discussion, why we ended up with read-tree ?
>
> We used to use neither, and considered it fine to "rm .git/index" if
> you wanted to empty the on-disk index file in the old world.  In the
> modern world, folks want you to avoid touching filesystem directly
> and instead want you to use Git tools, and the above are two obvious
> ways to do so.
>
> "git read-tree" (without any parameter, i.e. "read these 0 trees and
> populate the index with it") and its modern and preferred synonym
> "git read-tree --empty" (i.e. "I am giving 0 trees and I know the
> sole effect of this command is to empty the index.") are more direct
> ways to express "I want the index emptied" between the two.
>
> The other one, "git rm -r --cached .", in the end gives you the same
> state because it tells Git to "iterate over all the entries in the
> index, find the ones that match pathspec '.', and remove them from
> the index.".  It is not wrong per-se, but conceptually it is a bit
> roundabout way to say that "I want the index emptied", I would
> think.
>
> I wouldn't be surprised if the "rm -r --cached ." were a lot slower,
> due to the overhead of having to do the pathspec filtering that ends
> up to be a no-op, but there shouldn't be a difference in the end
> result.

You guys are obviously worlds ahead of me on the internals of things,
but from my perspective I like to avoid the "plumbing" commands as
much as I can. Even if I used them, if I have to tell the rest of my
team "this is the way to do it", they're going to give me dirty looks
if I ask them to run things like this that make no sense to them.
That's the argument I have to deal with when it comes to Git's
usability within the team I manage. So based on this, I'd favor the
`git rm -r --cached` approach because this is the more common result
you see in Google, and also makes a little more sense from a high
level of thought perspective. However, this is just my personal
opinion. `read-tree --empty` is far less self explanatory IMHO.

Also let's not forget the second part of the command chain that
results in the different behavior. In one case, I use `git add` which
results in proper line ending normalization. In the other case, I do
`git reset --hard` which does *NOT* result in the line endings
normalized (`git status` shows no results). In both cases, I'm still
doing `git rm -r --cached`, so I am doubtful that is the root cause
for the line ending normalization piece. I'm still trying to
understand why both give different results (root cause) and also get
an understanding of what the correct (modern) solution is for line
ending normalization (not necessarily which is the right way to
clear/delete the index, which is really AFAIK just a means to this end
and an implementation detail of sorts for this specific task).

Re: Line ending normalization doesn't work as expected

[Robert Dailey]

On Tue, Oct 3, 2017 at 11:26 AM, Torsten Bögershausen  wrote:
> The short version is, that the instructions on Github are outdated.
> This is the official procedure (since 2016, Git v2.12 or so)
> But it should work even with older version of Git.
>
> $ echo "* text=auto" >.gitattributes
> $ git read-tree --empty   # Clean index, force re-scan of working directory
> $ git add .
> $ git status# Show files that will be normalized
> $ git commit -m "Introduce end-of-line normalization"

Is the way I did it that worked also a valid solution? Or did it only
work accidentally? Again the command I ran that worked is:

$ git rm -r --cached . && git add .

Line ending normalization doesn't work as expected

[Robert Dailey]

I'm on Windows using Git for Windows v2.13.1. Following github's
recommended process for fixing line endings after adding a
`.gitattributes` file[1], I run the following:

$ rm .git/index && git reset

Once I run `git status`, I see that no files have changed. Note that I
know for a fact in my repository, files were committed using CRLF line
endings (the files in question are C# code files, and no
.gitattributes was present at the time).

I also tried this:

$ git rm -r --cached . && git reset --hard

However, again `git status` shows no working copy modifications. The
one thing that *did* work (and I tried this on accident actually) is:

$ git rm -r --cached . && git add .

This properly showed all files in my index with line ending
modifications (I ran `git diff --cached -R` to be sure; the output
shows `^M` at the end of each line in the diff in this case). Note
that my global git config has `core.autocrlf` set to `false`, but I
also tried the top 2 commands above with it set to `true` but it made
no difference.

So my question is: Why do the top 2 commands not work, but the third
one does? To me this all feels like magic / nondeterministic, so I'm
hoping someone here knows what is going on and can explain the logic
of it. Also if this is a git config issue, I'm not sure what it could
be. Note my `.gitattributes` just has this in it:

* text=auto

Thanks in advance.


[1]: https://help.github.com/articles/dealing-with-line-endings/

Re: Rebase & submodules

[Robert Dailey]

On Thu, Sep 14, 2017 at 10:57 AM, Nicolas Morey-Chaisemartin
 wrote:
> Without changing your workflow too much,

If you mean to imply that you have other recommendations if I'm
willing to change my workflow, then please by all means share them.
I'm very interested. I'm not too hooked on my workflow.

> simply add an annotated tag to your branch before your rebase.
> This way the SHA1 will always exists. Unless you want to cleanup at some 
> point (branch merged ?) and then you can simply delete all those old tags.

This definitely the best idea so far; although the maintenance
overhead of this could be high for long-lived branches with frequent
rebases. Maybe with bigger workflow changes there are other solutions?

Rebase & submodules

[Robert Dailey]

So I often will have a submodule that points to one of my own forks,
because I will have work done on a feature branch that hasn't been
merged upstream yet. Assuming this merge takes a long time to get
approved, I will occasionally rebase my topic branch to keep things up
to date and clean.

However, any previous commits in my parent repository that refer to a
SHA1 prior to the rebase will now be pointing to dangling/orphaned
commits, which means I wouldn't be able to go back to that commit in
history and do `git submodule update` since that checkout will fail.

One obvious solution to this is: Don't rebase. But, this could result
in a lot of merging between the upstream and my fork which would make
things not only ugly, but prevent me from making a pull request that
makes sense to the upstream repository (They'd likely request a rebase
in order to accept the PR, which I wouldn't be able to do for the
reasons outlined above).

Are there any other workflows that would support this kind of model better?

gitmodules below root directory

[Robert Dailey]

The gitmodules documentation[1] states that the .gitmodules file is at
the root. However, it would be nice if this could be supported in any
directory similar to how .gitignore works. Right now git-subrepo does
not support submodules inside of a subrepo[2] (I suspect subtrees
would have the same problem, but I did not verify). I think this is a
limitation of git, rather than subrepo itself. Perhaps there are
reasons why .gitmodules must be at the root, but I at least wanted to
point it out and see if this could be supported.

[1]: https://git-scm.com/docs/gitmodules
[2]: https://github.com/ingydotnet/git-subrepo/issues/262

subrepo vs submodule

[Robert Dailey]

So I found out about "subrepo" today: https://github.com/ingydotnet/git-subrepo

I'm still reading about how it works internally, but what do you guys
think about it? Is it a more or less perfect alternative to
submodules? What would be a reason not to use it?

Re: Better usability of stash refs

[Robert Dailey]

On Mon, Jun 19, 2017 at 3:56 PM, Jeff King <p...@peff.net> wrote:
> On Mon, Jun 19, 2017 at 03:32:54PM -0500, Robert Dailey wrote:
>
>> To drop a stash, I have to do this (example):
>>
>> $ git stash drop stash@{3}
>>
>> Using the full "stash@{N}" seems superfluous since the documentation
>> states it must be a stash in the first place. It would make more sense
>> (and be quicker to type) to do:
>>
>> $ git stash drop 3
>>
>> Is there a trick I can use to make this shorthand possible? I thought
>> about creating a "s" script for "stash" that intercepted the
>> parameters for only a couple of stash sub-commands and created the
>> ref, but that seems a lot of work.
>>
>> Any productivity tips here? Thanks in advance.
>
> Junio mentioned that this is already possible. I suspect the problem may
> be that your Git is not recent enough. It was added in a56c8f5aa (stash:
> allow stashes to be referenced by index only, 2016-10-24), which is in
> v2.11.0.
>
> -Peff

Thanks guys. Actually I'm running 2.13, I just haven't tried it since
way before 2.11. I always assumed it wasn't working like I expected
since last time I tried it. Yesterday I just happened to remember that
this would be nice to have, so I wrote the email but didn't bother
testing it on the newest version first. Sorry about that.

Better usability of stash refs

[Robert Dailey]

To drop a stash, I have to do this (example):

$ git stash drop stash@{3}

Using the full "stash@{N}" seems superfluous since the documentation
states it must be a stash in the first place. It would make more sense
(and be quicker to type) to do:

$ git stash drop 3

Is there a trick I can use to make this shorthand possible? I thought
about creating a "s" script for "stash" that intercepted the
parameters for only a couple of stash sub-commands and created the
ref, but that seems a lot of work.

Any productivity tips here? Thanks in advance.

Re: How to git push mirror local refs only?

[Robert Dailey]

On Fri, Jun 9, 2017 at 8:53 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Robert Dailey <rcdailey.li...@gmail.com> writes:
>
>> So I want to update my remote fork with all my local branches.
>> Normally I'd do this:
>>
>> $ git push --mirror fork
>>
>> However this will also push everything under `refs/remotes` which I do
>> not want. And it fails if I specify a refspec parameter with --mirror.
>>
>> Is there a way to achieve this through one or more git commands? Note
>> I'm doing this on a non-bare clone and have to keep it that way since
>> I'm pushing branches I actively work on.
>>
>> An intrinsic benefit of what I'm trying to do is that the mirror
>> command will also batch delete branches on the remote that do not
>> exist locally, which is behavior I want since I do not need them
>> anymore.
>
> Something along this line in your .git/config:
>
> [remote "fork"]
> url = ...
> push = refs/heads/*:refs/heads/*
>
> and then
>
> $ git push --prune --follow-tags fork

Sorry for the late reply, I was out of town all last week. Thanks for
your help. Does this serve as a good general default? I can't imagine
a case where I'd ever want to push something inside refs/remotes.

How to git push mirror local refs only?

[Robert Dailey]

So I want to update my remote fork with all my local branches.
Normally I'd do this:

$ git push --mirror fork

However this will also push everything under `refs/remotes` which I do
not want. And it fails if I specify a refspec parameter with --mirror.

Is there a way to achieve this through one or more git commands? Note
I'm doing this on a non-bare clone and have to keep it that way since
I'm pushing branches I actively work on.

An intrinsic benefit of what I'm trying to do is that the mirror
command will also batch delete branches on the remote that do not
exist locally, which is behavior I want since I do not need them
anymore.

Thanks in advance.

Re: Hide decorations in git log

[Robert Dailey]

On Wed, May 24, 2017 at 9:22 AM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> Hello,
>
> Is it possible to hide decorated refs in `git log` even if they are
> reachable from the refs I'm actually interested in seeing the logs of?
>
> For example, if I do `git log --graph --decorate --oneline --branches
> 'feature/*'`, I'd like to *only* see refnames that match the glob
> pattern. However, you'll see tags and other branches that do not match
> the glob if they are reachable from the result set.
>
> This is purely a visual thing, and shouldn't impact the search results
> I'd think.
>
> This is especially useful in cases where I do --simplify-by-decoration
> to get a better understanding of the topology of just a couple of
> select branches. Without some sort of "decoration exclusion", I am
> getting ton of results including tags, etc which obfuscates the
> information I'm really interested in.
>
> Thanks in advance.

Here is an even more concrete example:

$ git log --oneline --abbrev-commit --graph --simplify-by-decoration
--branches='hotfix'

I get the following results:

https://i.imgur.com/arHJss8.png

These results are incredibly confusing... I expected to see the first
line of the log results to be a branch matching 'hotfix' at the very
least. Maybe my question is more of a symptom of confusion about a
different problem. In any case, sorry for the confusion and hopefully
someone can clarify for me. I must be missing something basic.

Hide decorations in git log

[Robert Dailey]

Hello,

Is it possible to hide decorated refs in `git log` even if they are
reachable from the refs I'm actually interested in seeing the logs of?

For example, if I do `git log --graph --decorate --oneline --branches
'feature/*'`, I'd like to *only* see refnames that match the glob
pattern. However, you'll see tags and other branches that do not match
the glob if they are reachable from the result set.

This is purely a visual thing, and shouldn't impact the search results
I'd think.

This is especially useful in cases where I do --simplify-by-decoration
to get a better understanding of the topology of just a couple of
select branches. Without some sort of "decoration exclusion", I am
getting ton of results including tags, etc which obfuscates the
information I'm really interested in.

Thanks in advance.

Re: Diff topic branch + working copy changes?

[Robert Dailey]

On Wed, May 17, 2017 at 8:39 AM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> Thanks Junio, I forgot about merge-base. I'll create some aliases for now:
>
> # Diff Branch
> db = "!f() { : git diff ; git diff $(git merge-base @{upstream}
> HEAD) ; }; f"
>
> # Diff Tool Branch
> dtb = "!f() { : git diff ; git difftool -d $(git merge-base
> @{upstream} HEAD) ; }; f"
>
> Since I use push.default = current, I always keep my upstream set to
> the parent branch (origin/master, origin/release/1.2.3, etc). So in my
> case these aliases work, but probably not for other push.default
> settings like 'upstream'.

Correction: settings like 'simple'

> Would be nice in the future to have another revision specification
> like @{wc} for "HEAD + working copy". I guess this technically isn't a
> revision, but something along those lines. Or maybe just an
> --include-wc for diff or something.
>
> Thanks again!!

Re: Diff topic branch + working copy changes?

[Robert Dailey]

On Tue, May 16, 2017 at 9:47 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Robert Dailey <rcdailey.li...@gmail.com> writes:
>
>> So for a topic branch based on master, I can diff ONLY my changes on
>> the topic branch by doing this simple command:
>>
>> $ git diff origin/master...
>>
>> However, this does not include uncommitted working copy changes. To
>> work around this, I can do this instead:
>>
>> $ git diff origin/master
>>
>> (No three-dot notation above)
>>
>> However this implies a ".." notation which will include changes on
>> master that have been made after I branched my topic (I use three-dot
>> to exclude those).
>>
>> Is there a way I can do the first diff but also include working copy
>> changes?
>
> I've wished this a few times, but the answer is no.  Not as a
> short-hand like "..." anyway.
>
> You can still do
>
> $ git diff $(git merge-base origin/master HEAD)
>
> of course.

Thanks Junio, I forgot about merge-base. I'll create some aliases for now:

# Diff Branch
db = "!f() { : git diff ; git diff $(git merge-base @{upstream}
HEAD) ; }; f"

# Diff Tool Branch
dtb = "!f() { : git diff ; git difftool -d $(git merge-base
@{upstream} HEAD) ; }; f"

Since I use push.default = current, I always keep my upstream set to
the parent branch (origin/master, origin/release/1.2.3, etc). So in my
case these aliases work, but probably not for other push.default
settings like 'upstream'.

Would be nice in the future to have another revision specification
like @{wc} for "HEAD + working copy". I guess this technically isn't a
revision, but something along those lines. Or maybe just an
--include-wc for diff or something.

Thanks again!!

Diff topic branch + working copy changes?

[Robert Dailey]

So for a topic branch based on master, I can diff ONLY my changes on
the topic branch by doing this simple command:

$ git diff origin/master...

However, this does not include uncommitted working copy changes. To
work around this, I can do this instead:

$ git diff origin/master

(No three-dot notation above)

However this implies a ".." notation which will include changes on
master that have been made after I branched my topic (I use three-dot
to exclude those).

Is there a way I can do the first diff but also include working copy
changes? The reason I'm wanting to do this is because with difftool in
particular I like to make changes on the "right" side of each diff and
have those changes carry over to my working copy as edits I can
commit. This doesn't always work, especially if those same files are
already modified in my working copy but not committed.

Re: Best "triangle" workflow setup?

[Robert Dailey]

On Thu, May 11, 2017 at 6:36 PM, Jeff King <p...@peff.net> wrote:
> On Thu, May 11, 2017 at 04:23:03PM -0500, Robert Dailey wrote:
>
>> On Thu, May 11, 2017 at 3:17 PM, Jeff King <p...@peff.net> wrote:
>> > I think you want:
>> >
>> >   [push]
>> >   default = current
>> >   [remote]
>> >   pushDefault = myfork
>> >
>> > to make "git push" do what you want. And then generally have branches
>> > mark their counterparts on "origin" (which you can do either at creation
>> > time, or probably by using "git push -u origin my-topic" when you push
>> > them).
>>
>> So without the `pushDefault` setting, `current` will default to a
>> remote named `origin` if there is no tracking branch set, correct? So
>> `pushDefault` is effectively overriding this built-in default? In
>> addition, it seems like since this overrides `branch.name.remote`,
>> that this effectively makes the remote tracking branch *only* for
>> `pull`. Is this a correct understanding?
>
> Right. The general idea of a triangular workflow is that where you pull
> from is not the same as where you push to. We have branch.*.pushremote
> if you really wanted to do it on a per-branch basis, but in my
> experience you almost always want to use "myfork", because you can't
> push to "origin" in the first place. :)
>
>> > This is similar to what I do for my git.git workflow, though I usually
>> > have origin/master as the branch's upstream. I.e., I'd create them with:
>> >
>> >   git checkout -b my-topic origin
>>
>> I'm looking through the `git checkout` and `git branch` documentation,
>> but I don't see any mention of it being valid to use a remote name as
>> the  parameter (you're using `origin` in the above
>> example). Am I misunderstanding? Did you mean origin/my-topic?
>
> Using "origin" there will resolve to "origin/HEAD", i.e., origin/master.
> So basically I am saying that all of my topic branches are based on
> master, and if I were to rebase them (for example), I'd want to rebase
> the whole thing.
>
> If I were to "git pull", they'd also pull from master, which may or may
> not be what you want (though with pull.rebase, perhaps). I don't
> generally use "git pull" at all for my git.git workflow.

Thanks, just curious, where in the git documentation is the "origin"
to "origin/HEAD" resolution documented? I checked the git-revisions
page but it doesn't seem to mention it there. Thanks for explaining
though.

Also is there a similar mechanism for "track same-named branch on
specified remote"? Something like "origin/."? I follow git-flow
development process, so topic branches on hotfix or release branches
will track origin/master (since origin/HEAD still points to master or
develop). But I want to track "origin/release/1.2.3" without typing
the full thing. Basically would be nice if there was a lazy shorthand
for it similar to the "origin/HEAD" example you gave.


>> > And then rebasing always happens on top of master (because "origin"
>> > doesn't even have my topic branch at all). If I want to compare with
>> > what I've pushed to my fork, I'd use "@{push}".
>>
>> Can you explain more about how your rebase chooses master instead of
>> your same-named remote tracking branch? Maybe provide some examples of
>> your rebase command and respective configuration (unless what you've
>> already provided is sufficient). As for @{push}, I haven't used this
>> before, so I'll dig in the docs and learn about it.
>
> The default for "git rebase" (if you don't specify a base) is the
> configured upstream, which in my case is origin/master. Most of my
> rebasing is "rebase -i" to rewrite bits, so it automatically picks all
> the commits on my topic branch.
>
> Maybe it would help to set up a trivial example:
>
>   # just a helper to make dummy commits
>   commit() { echo "$1" >"$1" && git add "$1" && git commit -m "$1"; }
>
>   # some parent repo
>   git init parent
>   (cd parent && commit one)
>
>   # and imagine you have a public fork, too
>   git clone --bare parent myfork.git
>
>   # and then you have your local clone; in real life this is obviously
>   # the only one that would actually be on your machine, but this is a
>   # toy example
>   git clone parent local
>   cd local
>
>   # set up our triangular config
>   git remote add myfork ../myfork.git
>   git config remote.pushdefault myfo

Re: Best "triangle" workflow setup?

[Robert Dailey]

On Thu, May 11, 2017 at 3:17 PM, Jeff King  wrote:
> I think you want:
>
>   [push]
>   default = current
>   [remote]
>   pushDefault = myfork
>
> to make "git push" do what you want. And then generally have branches
> mark their counterparts on "origin" (which you can do either at creation
> time, or probably by using "git push -u origin my-topic" when you push
> them).

So without the `pushDefault` setting, `current` will default to a
remote named `origin` if there is no tracking branch set, correct? So
`pushDefault` is effectively overriding this built-in default? In
addition, it seems like since this overrides `branch.name.remote`,
that this effectively makes the remote tracking branch *only* for
`pull`. Is this a correct understanding?

> This is similar to what I do for my git.git workflow, though I usually
> have origin/master as the branch's upstream. I.e., I'd create them with:
>
>   git checkout -b my-topic origin

I'm looking through the `git checkout` and `git branch` documentation,
but I don't see any mention of it being valid to use a remote name as
the  parameter (you're using `origin` in the above
example). Am I misunderstanding? Did you mean origin/my-topic?

> And then rebasing always happens on top of master (because "origin"
> doesn't even have my topic branch at all). If I want to compare with
> what I've pushed to my fork, I'd use "@{push}".

Can you explain more about how your rebase chooses master instead of
your same-named remote tracking branch? Maybe provide some examples of
your rebase command and respective configuration (unless what you've
already provided is sufficient). As for @{push}, I haven't used this
before, so I'll dig in the docs and learn about it.

Thanks for your advice, so far I like this direction but seems like
there is more for me to learn!

Best "triangle" workflow setup?

[Robert Dailey]

I know Git has evolved to support the "triangle" workflow model in
different ways, with the goal of making it better. However because
there are so many different options from separate push URLs for
remotes to various ways to manage tracking branches, it's not clear to
me which specific configuration suits this workflow the best.

So my situation is that I have 3 repositories: The original upstream
repository, a fork of that repository (also remote), and my local
clone of the upstream repository.

What I want (as a default) is for `git pull` to pull from the
same-named branch on the upstream repository, but for `git push` to
push to the same-named branch on the fork repository. However to
override this behavior for when I want to push directly to upstream
repo, I should be able to use an explicit `git push origin my-topic`
(but `git push` by default will act as `git push fork my-topic`).

What is the best way to achieve this? Is there a different workflow
from what I'm imagining that works a little better (in other words, I
don't need it to work *exactly* as I've described, mainly I just want
to avoid accidentally pushing changes to the upstream repo in the
default case when I want to push to the fork instead for pull
request)?

Thanks in advance for any advice.

Re: Finding a tag that introduced a submodule change

[Robert Dailey]

On Fri, Mar 3, 2017 at 12:04 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Robert Dailey <rcdailey.li...@gmail.com> writes:
>
>> Sometimes I run into a situation where I need to find out which
>> release of the product a submodule change was introduced in. This is
>> nontrivial, since there are no tags in the submodule itself.
>
> Does your superproject rewind the commit in the submodule project as
> it goes forward?  That is, is this property guaranteed to hold by
> your project's discipline:
>
> Given any two commits C1 and C2 in the superproject, and the
> commit in the submodule bound to C1's and C2's tree (call
> them S1 and S2, respectively), if C1 is an ancestor of C2,
> then S1 is the same as S2 or an ancestor of S2.
>
> If so, I think you can do a bisection of the history in the
> superproject.  Pick an old commit in the superproject that binds an
> old commit from the submodule that does not have the change and call
> it "good".  Similarly pick a new one in the superproject that binds
> a newer commit from the submodule that does have the change, and
> call it "bad".  Then do
>
> $ git bisect start $bad $good -- $path_to_submodule
>
> which would suggest you to test commits that change what commit is
> bound at the submodule's path.
>
> When testing each of these commits, you would see if the commit
> bound at the submodule's path has the change or not.
>
> $ current=$(git rev-parse HEAD:$path_to_submodule)
>
> would give you the object name of that commit, and then
>
> $ git -C $path_to_submodule merge-base --is-ancestor $change $current
>
> would tell you if the $change you are interested in is already
> contained in that $current commit.  Then you say "git bisect good"
> if $current is too old to contain the $change, and "git bisect bad"
> if $current is sufficiently new and contains the $change, to
> continue.
>
> If your superproject rewinds the commit in the submodule as it goes
> forward, e.g. an older commit in the superproject used submodule
> commit from day X, but somebody who made yesterday's commit in the
> superproject realized that that submodule commit was broken and used
> an older commit in the submodule from day (X-1), then you cannot
> bisect.  In such a case, I think you would essentially need to check
> all superproject commits that changed the commit bound at the
> submodule's path.
>
> $ git rev-list $bad..$good -- $path_to_submodule
>
> would give a list of such commits, and you would do the "merge-base"
> check for all them to see which ones have and do not have the
> $change (replace "HEAD" with the commit you are testing in the
> computation that gives you $current).


Hi Junio, my apologies for the very late response.

I really like your idea, however unfortunately often times people on
my team accidentally rewind the submodule. However your latter
suggestion about just doing merge-base on each change would be a
worthy solution to try. Thank you very much, I will certainly give
this a try!!

git pretty format: "%+b" not working with "%w" in front of it?

[Robert Dailey]

I have the following log:

$ git log

commit 7ffb909bb8f38607e3d6d9f3504a66ca978f0ac2
Author: Robert Dailey <rob...@ziosk.com>
Date:   Mon Dec 12 11:01:00 2016 -0600

Add initial skeleton files & a few interfaces for new kizi/sc16 stuff

This is still FAR from complete


I want to generate changelogs, using github markdown list format. I
tried doing that using this command:

$ git log --pretty=format:"* %s%n%w(100,2,2)%+b"

However, the 2nd newline is not inserted:

* Add initial skeleton files & a few interfaces for new kizi/sc16 stuff
   This is still FAR from complete

The format I'm expecting is:

* Add initial skeleton files & a few interfaces for new kizi/sc16 stuff

  This is still FAR from complete

This seems to work, but I do not get the 2-space indentation required
to continue text on the current list item:

$ git log --pretty=format:"* %s%n%+b"

* Add initial skeleton files & a few interfaces for new kizi/sc16 stuff

This is still FAR from complete

So why isn't it working when I use %w before the %+b? Am I doing
something wrong? Note I'm using git version 2.10 on Windows through
Git Bash.

Finding a tag that introduced a submodule change

[Robert Dailey]

I have a repository with a single submodule in it. Since the parent
repository represents the code base for an actual product, I tag
release versions in the parent repository. I do not put tags in the
submodule since multiple other products may be using it there and I
wanted to avoid ambiguous tags.

Sometimes I run into a situation where I need to find out which
release of the product a submodule change was introduced in. This is
nontrivial, since there are no tags in the submodule itself. This is
one thing I tried:

1. Do a `git log` in the submodule to find the SHA1 representing the
change I want to check for
2. In the parent repository, do a git log with pickaxe to determine
when the submodule itself changed to the value of that SHA1.
3. Based on the result of #2, do a `git tag --contains` to see the
lowest-version tag that contains the SHA1, which will identify the
first release that introduced that change

However, I was not able to get past #2 because apparently there are
cases where when we move the submodule "forward", we skip over
commits, so the value of the submodule itself never was set to that
SHA1.

I'm at a loss here on how to easily do this. Can someone recommend a
way to do this? Obviously the easier the better, as I have to somehow
train my team how to do this on their own.

Thanks in advance.

Re: Rebasing a branch with merges

[Robert Dailey]

On Fri, Jan 6, 2017 at 3:28 PM, Philip Oakley <philipoak...@iee.org> wrote:
> From: "Robert Dailey" <rcdailey.li...@gmail.com>
>>
>> Here's the scenario:
>>
>> I create a topic branch so one other developer and myself can work on
>> a feature that takes 2 weeks to complete. During that 2 week period,
>> changes are occurring on master that I need in my topic branch. Since
>> I have a collaborator on the branch, I opt for merges instead of
>> rebase.
>>
>> Each day I merge from master to the topic branch, which changes code
>> I'm actively working in and requires semantic changes (functions
>> renamed, moved, etc).
>>
>> Once I'm ready to merge the topic branch back into master, I have two
>> options (bearing in mind the goal is to keep history as clean as
>> possible. Furthermore this implies that the constant merging into
>> topic from master has made the topic branch look unwieldy and
>> difficult to audit):
>
>
> a broader question zero;
> 0. Is the merge always clean? Do you always do a preparatory fixup! to
> ensure that the merge will be clean?
>
> Ensuring that the merge will be clean should greatly simplify your decision
> about process.

I don't understand what you're asking. How would I do a fixup with
merges? Can you explain a bit? Normally the only time I use fixup! or
squash! is for local changes prior to pushing.

>> 1. Do a squash merge, which keeps history clean but we lose context
>> for the important bits (the commits representing units of work that
>> contribute to the topic itself).
>>
>> 2. Do a final rebase prior to merging.
>>
>> #2 doesn't seem to be possible due to patch ordering. For example, if
>> I have real commits after merge commits that depend on those changes
>> from master being present as a base at that point in time, the rebase
>> will cause the patch before it to no longer include those changes from
>> master.
>
>
> How much of the historic fixups to cover changes on master do you want to
> keep visible? i.e. how many fork-points are truly needed (a. by you, b. by
> the project - personal knowledge vs corporate knowledge).?


Again, I do not understand. Maybe the first question you asked needs
to be understood before I can answer this one. Sorry for the trouble.

Rebasing a branch with merges

[Robert Dailey]

Here's the scenario:

I create a topic branch so one other developer and myself can work on
a feature that takes 2 weeks to complete. During that 2 week period,
changes are occurring on master that I need in my topic branch. Since
I have a collaborator on the branch, I opt for merges instead of
rebase.

Each day I merge from master to the topic branch, which changes code
I'm actively working in and requires semantic changes (functions
renamed, moved, etc).

Once I'm ready to merge the topic branch back into master, I have two
options (bearing in mind the goal is to keep history as clean as
possible. Furthermore this implies that the constant merging into
topic from master has made the topic branch look unwieldy and
difficult to audit):

1. Do a squash merge, which keeps history clean but we lose context
for the important bits (the commits representing units of work that
contribute to the topic itself).

2. Do a final rebase prior to merging.

#2 doesn't seem to be possible due to patch ordering. For example, if
I have real commits after merge commits that depend on those changes
from master being present as a base at that point in time, the rebase
will cause the patch before it to no longer include those changes from
master.

Is there a mechanism to rebase in this situation to both achieve a
clean, linear history for the topic branch and allow fast forward
merging if desired, while still not causing superfluous conflicts due
to the merges being omitted during the rebase?

Thanks in advance for any advice in this scenario.

v2.11 new diff heuristic?

[Robert Dailey]

The release notes mention a new heuristic for diff:

* Output from "git diff" can be made easier to read by selecting
which lines are common and which lines are added/deleted
intelligently when the lines before and after the changed section
are the same. A command line option is added to help with the
experiment to find a good heuristics.

However, it lacks information on exactly how to use this new feature.
I dug into the git diff documentation here:

https://git-scm.com/docs/git-diff

It mentions a "--compaction-heuristic" option. Is this the new
heuristic outlined by the release notes? If not, which is it? Is the
compaction heuristic compatible with the histogram diff algorithm? Is
there a config option to turn this on all the time? For that matter,
is this something I can keep on all the time or is it only useful in
certain situations?

There's still so much more about this feature I would like to know.

Re: Integrating submodules with no side effects

[Robert Dailey]

On Wed, Oct 19, 2016 at 2:51 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> On Wed, Oct 19, 2016 at 2:45 PM, Stefan Beller <sbel...@google.com> wrote:
>> On Wed, Oct 19, 2016 at 12:19 PM, Robert Dailey
>> <rcdailey.li...@gmail.com> wrote:
>>> On Wed, Oct 19, 2016 at 11:23 AM, Stefan Beller <sbel...@google.com> wrote:
>>>> You could try this patch series:
>>>> https://github.com/jlehmann/git-submod-enhancements/tree/git-checkout-recurse-submodules
>>>> (rebased to a newer version; no functional changes:)
>>>> https://github.com/stefanbeller/git/tree/submodule-co
>>>> (I'll rebase that later to origin/master)
>>>>
>>>>>
>>>>> Do you have any info on how I can prevent that error? Ideally I want
>>>>> the integration to go smoothly and transparently, not just for the
>>>>> person doing the actual transition (me) but for everyone else that
>>>>> gets those changes from upstream. They should not even notice that it
>>>>> happened (i.e. no failed commands, awkward behavior, or manual steps).
>>>>
>>>> It depends on how long you want to postpone the transition, but I plan to
>>>> upstream the series referenced above in the near future,
>>>> which would enable your situation to Just Work (tm). ;)
>>>
>>> At first glance, what you've linked to essentially looks like
>>> automated `git submodule update` for every `git checkout`. Am I
>>> misunderstanding?
>>
>> Essentially yes, except with stricter rules than the actual submodule update
>> IIRC.
>>
>>>
>>> If I'm correct, this is not the same as what I'm talking about. The
>>> problem appears to be more internal: When a submodule is removed, the
>>> physical files that were there are not removed by Git.
>>
>> That is also done by that series: submodules ought to be treated as files:
>> If you checkout a new version where a file is deleted, the checkout command
>> will actually remove the file for you (and e.g. solve any
>> directory/file conflicts
>> that may happen in the transition.)
>>
>>> It leaves them
>>> there in the working copy as untracked files.
>>
>> That is the current behavior as checkout tries hard to ignore submodules.
>>
>>> The next step Git takes
>>> (again, just from outside observation) is to add those very same files
>>> to the working copy, since they were added to a commit. However, at
>>> this point Git fails because it's trying to create (write) files to
>>> the working copy when an exact file of that name already exists there.
>>> Git will not overwrite untracked files, so at this point it fails.
>>>
>>> What needs to happen, somehow, is Git sees that the files were
>>> actually part of a submodule (which was removed) and remove the
>>> physical files as well, assuming that they were not modified in the
>>> submodule itself. This will ensure that the next step (creating the
>>> files) will succeed since the files no longer block it.
>>
>> Yep.
>
> It's great we're finally on the same page ;-)
>
> However, I don't see how this problem can be solved with your script,
> or solved in general outside of that. Does this mean that Git needs to
> change to treat submodules as it does normal files, per your previous
> assertion, which means submodules should *not* be left behind in the
> working copy as untracked files?

I'll assume (due to the lack of responses) that the only viable
solution here is to integrate the submodule using a different
directory name than the one used by the submodule itself. It's
unfortunate but I'll do it if I have no other option.

Re: Integrating submodules with no side effects

[Robert Dailey]

On Wed, Oct 19, 2016 at 2:45 PM, Stefan Beller <sbel...@google.com> wrote:
> On Wed, Oct 19, 2016 at 12:19 PM, Robert Dailey
> <rcdailey.li...@gmail.com> wrote:
>> On Wed, Oct 19, 2016 at 11:23 AM, Stefan Beller <sbel...@google.com> wrote:
>>> You could try this patch series:
>>> https://github.com/jlehmann/git-submod-enhancements/tree/git-checkout-recurse-submodules
>>> (rebased to a newer version; no functional changes:)
>>> https://github.com/stefanbeller/git/tree/submodule-co
>>> (I'll rebase that later to origin/master)
>>>
>>>>
>>>> Do you have any info on how I can prevent that error? Ideally I want
>>>> the integration to go smoothly and transparently, not just for the
>>>> person doing the actual transition (me) but for everyone else that
>>>> gets those changes from upstream. They should not even notice that it
>>>> happened (i.e. no failed commands, awkward behavior, or manual steps).
>>>
>>> It depends on how long you want to postpone the transition, but I plan to
>>> upstream the series referenced above in the near future,
>>> which would enable your situation to Just Work (tm). ;)
>>
>> At first glance, what you've linked to essentially looks like
>> automated `git submodule update` for every `git checkout`. Am I
>> misunderstanding?
>
> Essentially yes, except with stricter rules than the actual submodule update
> IIRC.
>
>>
>> If I'm correct, this is not the same as what I'm talking about. The
>> problem appears to be more internal: When a submodule is removed, the
>> physical files that were there are not removed by Git.
>
> That is also done by that series: submodules ought to be treated as files:
> If you checkout a new version where a file is deleted, the checkout command
> will actually remove the file for you (and e.g. solve any
> directory/file conflicts
> that may happen in the transition.)
>
>> It leaves them
>> there in the working copy as untracked files.
>
> That is the current behavior as checkout tries hard to ignore submodules.
>
>> The next step Git takes
>> (again, just from outside observation) is to add those very same files
>> to the working copy, since they were added to a commit. However, at
>> this point Git fails because it's trying to create (write) files to
>> the working copy when an exact file of that name already exists there.
>> Git will not overwrite untracked files, so at this point it fails.
>>
>> What needs to happen, somehow, is Git sees that the files were
>> actually part of a submodule (which was removed) and remove the
>> physical files as well, assuming that they were not modified in the
>> submodule itself. This will ensure that the next step (creating the
>> files) will succeed since the files no longer block it.
>
> Yep.

It's great we're finally on the same page ;-)

However, I don't see how this problem can be solved with your script,
or solved in general outside of that. Does this mean that Git needs to
change to treat submodules as it does normal files, per your previous
assertion, which means submodules should *not* be left behind in the
working copy as untracked files?

Re: Integrating submodules with no side effects

[Robert Dailey]

On Wed, Oct 19, 2016 at 11:23 AM, Stefan Beller  wrote:
> You could try this patch series:
> https://github.com/jlehmann/git-submod-enhancements/tree/git-checkout-recurse-submodules
> (rebased to a newer version; no functional changes:)
> https://github.com/stefanbeller/git/tree/submodule-co
> (I'll rebase that later to origin/master)
>
>>
>> Do you have any info on how I can prevent that error? Ideally I want
>> the integration to go smoothly and transparently, not just for the
>> person doing the actual transition (me) but for everyone else that
>> gets those changes from upstream. They should not even notice that it
>> happened (i.e. no failed commands, awkward behavior, or manual steps).
>
> It depends on how long you want to postpone the transition, but I plan to
> upstream the series referenced above in the near future,
> which would enable your situation to Just Work (tm). ;)

At first glance, what you've linked to essentially looks like
automated `git submodule update` for every `git checkout`. Am I
misunderstanding?

If I'm correct, this is not the same as what I'm talking about. The
problem appears to be more internal: When a submodule is removed, the
physical files that were there are not removed by Git. It leaves them
there in the working copy as untracked files. The next step Git takes
(again, just from outside observation) is to add those very same files
to the working copy, since they were added to a commit. However, at
this point Git fails because it's trying to create (write) files to
the working copy when an exact file of that name already exists there.
Git will not overwrite untracked files, so at this point it fails.

What needs to happen, somehow, is Git sees that the files were
actually part of a submodule (which was removed) and remove the
physical files as well, assuming that they were not modified in the
submodule itself. This will ensure that the next step (creating the
files) will succeed since the files no longer block it.

Re: Integrating submodules with no side effects

[Robert Dailey]

On Tue, Oct 18, 2016 at 4:17 PM, Stefan Beller <sbel...@google.com> wrote:
> On Tue, Oct 18, 2016 at 12:35 PM, Robert Dailey
> <rcdailey.li...@gmail.com> wrote:
>> Hello git experts,
>>
>> I have in the past attempted to integrate submodules into my primary
>> repository using the same directory name. However, this has always
>> caused headache when going to and from branches that take you between
>> when this integration occurred and when it didn't. It's a bit hard to
>> explain. Basically, if I have a submodule "foo", and I delete that
>> submodule and physically add its files under the same directory "foo",
>> when I do a pull to get this change from another clone, it fails
>> saying:
>>
>> error: The following untracked working tree files would be overwritten
>> by checkout:
>> foo/somefile.txt
>> Please move or remove them before you switch branches.
>> Aborting
>> could not detach HEAD
>>
>>
>> Obviously, git can't delete the submodule because the files have also
>> been added directly. I don't think it is built to handle this
>> scenario. Here is the series of commands I ran to "integrate" the
>> submodule (replace the submodule with a directory containing the exact
>> contents of the submodule itself):
>>
>> #!/usr/bin/env bash
>> mv "$1" "${1}_"
>> git submodule deinit "$1"
>
> This removes the submodule entries from .git/config
> (and it would remove the contents of that submodule, but they are moved)
>
>> git rm "$1"
>
> Removing the git link here.
>
> So we still have the entries in the .gitmodules file there.
> Maybe add:
>
> name=$(git submodule-helper name $1)
> git config -f .gitmodules --unset submodule.$name.*
> git add .gitmodules
>
> ? (Could be optional)

Actually I verified that it seems `git rm` is specialized for
submodules somewhere, because when I run that command on a submodule
the relevant entries in the .gitmodules file are removed. I did not
have to do this as a separate step.

>> mv "${1}_" "$1"
>> git add "$1/**"
>
> Moving back into place and adding all files in there.
>
>>
>> The above script is named git-integrate-submodule, I run it like so:
>>
>> $ git integrate-submodule foo
>>
>> Then I do:
>>
>> $ git commit -m 'Integrated foo submodule'
>>
>> Is there any way to make this work nicely?
>
> I think you can just remove the gitlink from the index and not from the 
> working
> tree ("git rm --cached $1")

What is the goal of doing it this way? What does this simplify?

>> The only solution I've
>> found is to obviously rename the directory before adding the physical
>> files, for example name it foo1. Because they're different, they never
>> "clash".
>
> Also look at the difference between plumbing and porcelain commands[1],
> as plumbing is more stable than the porcelain, so it will be easier to 
> maintain
> this script.

Which plumbing commands did you have in mind?

> I think this would be an actually reasonable feature, which Git itself
> could support via "git submodule [de]integrate", but then we'd also want
> to see the reverse, i.e. take a sub directory and make it a submodule.

Integrating this as a feature might be fine, I think when you bring up
the question of retaining history makes things much harder.
Fortunately for me that is not a requirement in this case, so I'm able
to do things with much less effort.

However the primary purpose of my post was to find out how to
integrate the submodule without the error on next pull by other
collaborators of my repository. It's a real pain to recover your
working copy when going inbetween commits where the submodule
integration happened inbetween them. I did quote the exact error
message I got in my original post.

Do you have any info on how I can prevent that error? Ideally I want
the integration to go smoothly and transparently, not just for the
person doing the actual transition (me) but for everyone else that
gets those changes from upstream. They should not even notice that it
happened (i.e. no failed commands, awkward behavior, or manual steps).

Integrating submodules with no side effects

[Robert Dailey]

Hello git experts,

I have in the past attempted to integrate submodules into my primary
repository using the same directory name. However, this has always
caused headache when going to and from branches that take you between
when this integration occurred and when it didn't. It's a bit hard to
explain. Basically, if I have a submodule "foo", and I delete that
submodule and physically add its files under the same directory "foo",
when I do a pull to get this change from another clone, it fails
saying:

error: The following untracked working tree files would be overwritten
by checkout:
foo/somefile.txt
Please move or remove them before you switch branches.
Aborting
could not detach HEAD


Obviously, git can't delete the submodule because the files have also
been added directly. I don't think it is built to handle this
scenario. Here is the series of commands I ran to "integrate" the
submodule (replace the submodule with a directory containing the exact
contents of the submodule itself):

#!/usr/bin/env bash
mv "$1" "${1}_"
git submodule deinit "$1"
git rm "$1"
mv "${1}_" "$1"
git add "$1/**"

The above script is named git-integrate-submodule, I run it like so:

$ git integrate-submodule foo

Then I do:

$ git commit -m 'Integrated foo submodule'

Is there any way to make this work nicely? The only solution I've
found is to obviously rename the directory before adding the physical
files, for example name it foo1. Because they're different, they never
"clash".

Git log exclude/remotes/branches options not working as expected

[Robert Dailey]

I have 3 remotes registered in my clone:

origin, fork, drive

When I do:

$ git log --oneline --decorate --graph

I only want to see branches under:

refs/heads/*
refs/remotes/origin/*

I tried the following:

$ git log --oneline --decorate --graph --simplify-by-decoration
--remote=origin topic1..master

However, I still see refs present in the graph for 'drive' and 'fork'
remote tracking branches. I can't tell if these are shown simply
because other refs not excluded by my options happen to also be at
that SHA1, or if the log command is still generating the graph based
on other branches.

What I'm expecting is that I literally see NONE of those excluded refs
on the graph, even if other included refs also happen to be positioned
at those commits. It's the visualization of the refs I'm concerned
about: I have a lot of remote tracking branches in those remotes that
clutter the view; I'd rather not see them at all (in addition to the
graph not considering them when it is being built/generated). Am I
misunderstanding the purpose here? How can I achieve my goals?
Documentation hasn't really helped me out here.

Can we make interactive add easier to use?

[Robert Dailey]

Normally when I use interactive add, I just want to add files to the
index via simple numbers, instead of typing paths. So I'll do this as
quick as I can:

1. Type `git add -i`
2. Press `u` after prompt appears
3. Press numbers for the files I want to add, ENTER key
4. ENTER key again to go back to main add -i menu
5. Press `q` to exit interactive add
6. Type `git commit`

This feels very tedious. Is there a simplified workflow for this? I
remember using a "git index" unofficial extension to git that let you
do a `git status` that showed numbers next to each item (including
untracked files!) and you could do `git add 1, 2, 3-5`, etc.

Thoughts? Even though this feels like I'm complaining, honestly I am
just consulting the experts here to see if I'm missing out on some
usability features. Thanks in advance!!

Re: Fixup of a fixup not working right

[Robert Dailey]

On Fri, Sep 2, 2016 at 9:22 PM, Junio C Hamano  wrote:
> Perhaps a change like this to "rebase -i":
>
>  - The search for "original" when handling "pick fixup! original",
>when it does not find "original", could turn it into "reword
>fixup! original" without changing its position in the instruction
>sequence.

If it did this, then later when I'm ready to merge and all
contributions upstream are completed, I would most likely lose track
of which original commit to fixup to. This would only be an issue if
you gave the option to reword the "fixup! original". Rewording it, to
me, inherently means you no longer want to meld it into another commit
and instead intend on it being independent (looking at this
semantically, without relying on translating the commit message
itself, even though it may clearly tell me to squash it to something
else, that's not as reliable as the fixup! mechanics IMHO).

>  - The search for "original" when handling "pick fixup! fixup!
>original", could be (probably unconditionally) changed to look
>for "fixup! original" to amend, instead of looking for "original"
>as the current code (this is your "separate issue").  The same
>"if the commit to be amended is not found, turn it into reword"
>rule from the above applies to this one, too.

So this is mostly for my education, since I don't see a difference
from a user-standpoint. Why would "fixup! fixup! original" look for
"original" instead of "fixup! original"? As far as I can see, the
behavior would be the same and the order would be retained since you
are essentially "chaining" the fixups together this way. This also
gives you the behavior you want directly because the algorithm will
naturally tie to "fixup! original" even if "original" doesn't exist,
because Git would expect that "fixup! original" will automatically
manage its own order, and that subsequent processed nested "fixup!"
commits would not need to depend on any other commits.

Fixup of a fixup not working right

[Robert Dailey]

Suppose I have a branch with 4 commits, in the following order (as you
might see during interactive rebase):

pick 123 Original Change
pick 789 fixup! Original Change
pick 456 Some Other Thing
pick abc fixup! fixup! Original Change

However, let's say the first commit is already pushed upstream on a
topic branch. Since there are multiple developers on this topic
branch, I do not want to rebase right now. Instead, I want to document
future fixups via fixup commits and then when we're ready to merge, do
a final rebase prior to the merge to master to clean things up after
we're all done collaborating.

For this specific situation, since the first commit is already pushed,
I want to perform a fixup on the 1st fixup commit. When I perform an
interactive rebase against upstream topic, I get the following:

pick 789 fixup! Original Change
pick 456 Some Other Thing
pick abc fixup! fixup! Original Change

The tip commit (abc in this case) is not marked as a fixup. What I
expect to see is:

pick 789 fixup! Original Change
fixup abc fixup! fixup! Original Change
pick 456 Some Other Thing

Is this by design, or a defect? I assumed that Git would only look at
the first occurrence of "fixup!" and treat everything else after as
the commit description to match. But it seems in this case that it
stops at the last occurrence of "fixup!", which would explain why it
isn't matching in the interactive rebase. I haven't looked at the
code, though.

Thoughts? Also I'm perfectly willing to accept feedback involving me
just using the feature wrong or as not intended. Thanks in advance.

Re: diff using 3-dot behavior

[Robert Dailey]

On Wed, Aug 24, 2016 at 11:00 AM, Michael J Gruber
 wrote:
> The 3-dot notation means:
>
> Show the difference between the merge-base of master and topic, and topic.
>
> I'm not completely sure, but I guess what you want is:
>
> Show the difference between the merge-base of master and topic, and the
> worktree.
>
> You can accomplish this with:
>
> git diff $(git merge-base master topic)
>
> I guess a shorter notation for that could come in handy. OTOH, I usually
> diff against HEAD in a situation like that.

Great solution. I feel silly now, the answer ended up being rather
obvious. I can create an alias for that. But I can't diff against HEAD
because then I am not seeing a diff of changes already committed.
Thanks for your help.
--
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

diff using 3-dot behavior

[Robert Dailey]

I want to view the complete diff of my branch (topic) relative to its
parent branch (master). This should include cached/staged files and
unstaged working tree changes.

If I do this:

$ git diff master

This will include changes on master *since* my last merge, which I do
not want (I don't want to see changes on master, only on topic). I
tried this:

$ git diff master --not master

This didn't give me any output. If I do this:

$ git diff master...topic

This shows me only committed changes on topic, but excludes staged &
unstaged changes.

How can I get the results I want?
--
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: diff --diff-filter on modified but locally deleted files

[Robert Dailey]

On Wed, Aug 17, 2016 at 1:34 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Robert Dailey <rcdailey.li...@gmail.com> writes:
>
>> My use case is that I do a merge from branch A to branch B. Branch A
>> modified a file which is already deleted on B some time before the
>> merge.
>>
>> When I do a `git status -sb`, these locally deleted but remotely
>> modified files show up as "DU".
>>
>> I want to invoke git status or diff (or something else) to get a list
>> of these specific conflicts (locally deleted, remotely modified).
>
> As far as "git diff [--cached]" (which is "compare HEAD with the
> working tree through index") is concerned, these paths are in the
> "U"nmerged category, so you'd give "U" to diff-filter to view them.
> Of course, that would give you other kinds of unmerged entries.
>
> If you know they show up as DU, why not "grep DU" in that output?

I'm happy to do that and in fact considered it, but since
--diff-filter exists, I figured it might solve the problem. I also
need a better understanding of how diff-filter works since it
technically has 2 sides during a merge conflict. I guess it functions
only on the right (local) side.

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

diff --diff-filter on modified but locally deleted files

[Robert Dailey]

My use case is that I do a merge from branch A to branch B. Branch A
modified a file which is already deleted on B some time before the
merge.

When I do a `git status -sb`, these locally deleted but remotely
modified files show up as "DU".

I want to invoke git status or diff (or something else) to get a list
of these specific conflicts (locally deleted, remotely modified). I
tried this:

$ git diff --diff-filter=D --name-status

This gave me no results. I also tried adding --cached, didn't make a
difference. If I just do this:

$ git diff --name-status

This lists those files as just U instead of DU. So I'm not sure where
the "D" is coming from in this case.

Is there a way I can get a list of these specific conflicts? I'd like
to rely on working/index status for this if possible, since as I
resolve these conflicts I want the list to shorten and only show
unresolved conflicts of this type. Which rules out a diff range
between B...A that I could do.
--
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 add without whitespace

[Robert Dailey]

On Mon, May 30, 2016 at 2:06 PM, Junio C Hamano  wrote:
> I have had this in my ~/.gitconfig for a long time.
>
> [alias]
> wsadd = "!sh -c 'git diff -- \"$@\" | git apply --cached 
> --whitespace=fix;\
> git co -- ${1-.} \"$@\"' -"
>
> That is, "take what's different from the _index_ and the working
> tree, apply that difference while correcting whitespace errors to
> the index, and check the result out to the working tree".  This
> would _not_ touch existing whitespace-damaged lines that you are not
> touching, and honours the customized definition of what is
> considered whitespace breakage for each paths (which you set up with
> the attributes system).
>

I like your solution better than mine because it utilizes the rules
defined in .gitattributes. I think that's a really good idea. But
other than that, yours is functionally the same as what I'm doing,
right? I just want to make sure I understand: What ends up in the
index/staging area is the code MINUS the trailing whitespace (e.g.
whitespace errors)?

What does the checkout at the end do? That part confuses me (granted
I'm not well-versed with bash script).

Thanks for the feedback. Looks like this is niche enough that an
alias/script is probably the best solution.
--
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 add without whitespace

[Robert Dailey]

I think it would be useful to have a '-w' option for 'git add' that
completely ignores whitespace changes, the same way that 'git diff -w'
does.

Real life scenario:

Sometimes developers will use tooling that does not properly strip
trailing whitespace in source files. Next time I edit those files for
a simple 1-line code change, my tooling will strip whitespace from the
whole file. I *do* want these changes, however I want 2 commits: 1
commit with the bugfix, and a supplementary commit with just the
whitespace changes.

At the moment, there is no way for me to conveniently add the source
file to the index without whitespace. The only way to accomplish this
today that I'm aware of is via this command:

$ git diff -U0 -w --no-color | git apply --cached --ignore-whitespace
--unidiff-zero

This command explicitly leaves out context because it can sometimes
cause the patch to fail to apply, I think due to whitespace being in
it, but I'm not completely sure myself.

It would be useful to be able to do this instead:

$ git add -w

This would effectively function the same as my workaround command
shown earlier. It should also be valid to use -w with -i and -p. In
the -p case, it just won't show hunks containing whitespace changes.
For -i, it would assume '-w' as part of any command run during the
interactive session.

Does this idea sound good? I have some free time on my hands so I
wouldn't mind implementing this. Maybe there isn't a huge audience for
this kind of thing, or maybe I'm just going about this the wrong way.
Thoughts would be 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

Best Practices with code/build fixes post-merge?

[Robert Dailey]

Sometimes, I merge 2 branches that have deviated quite a bit. A
worst-case example would be some API change. The topic branch
(long-lived) may start using the old API. However, once I merge the
topic back to master, that API no longer exists. As such, every place
that introduces a usage of the old API will fail to build (but won't
necessarily cause a conflict during a merge).

Concerning best practices, which of the following is better?

1. Make the fixes (which may be vast), smoke test, get a general feel
that everything is working on master again. Amend the changes to the
previous merge commit.

2. Make the fixes as in step 1, but instead of amending to the merge
commit, create a new descendant commit representing the changes.

Concerns I see with either choice:

1. Pros: Changes are atomic. Cons: merge commits are typically very
difficult to view, especially from logs. For example, `git log
--name-status` does nothing for merge commits, so it makes it
less-intuitive to get a good overview of changes.

2. Opposite of #1: Changes are not atomic (con), but it makes it very
clear that these changes were made "on top of" the merge (pro)

Is there a best practice here? What do each of you do as a personal
preference or policy? Thanks in advance.
--
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 <gits...@pobox.com> wrote:
> Robert Dailey <rcdailey.li...@gmail.com> 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

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: How to use @{-1} with push?

[Robert Dailey]

On Fri, Mar 25, 2016 at 1:58 PM, Junio C Hamano  wrote:
> I thought these are clear from their documentation.  "push" works on
> refnames, "branch" works on branch names.  "push" takes an branch
> name as a short-hand and adds refs/heads/ when it makes sense, but
> because it does not make any sense for "git branch" to create a
> "branch" in a random place in refs/ (e.g. "refs/tags/foo" is not a
> branch), it takes "foo" (i.e. the name of the branch, whose
> underlying ref is "refs/heads/foo").
>
> So
>
> ref=$(git rev-parse --symbolic-full-name "$2") &&
> case "$ref" in
> '') echo >&2 "No such thing $2"; exit 1 ;;
> refs/heads/*) ref=${ref#refs/heads/} ;;
> *) echo >&2 "That's not a branch $2"; exit 2 ;;
> esac &&
> git push "$1" "refs/heads/$ref" &&
> git branch -D "$ref"
>
> or something?

Reading the git documentation feels a lot like reading the C++
standard. Not the best place to go to learn something. Some of the
terminology is very detail-oriented. For example, until you explained
the differences between push & branch, I always thought "ref" and
"branch" were interchangeable. But now it's clear to me that a branch
is just a type of ref, but refs are not branches. Also as a Windows
developer, I am not as well-versed in bash scripting as I'd like to
be.

So thanks for your explanation, it is clear 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: How to use @{-1} with push?

[Robert Dailey]

On Fri, Mar 25, 2016 at 1:02 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> On Fri, Mar 25, 2016 at 12:45 PM, Junio C Hamano <gits...@pobox.com> wrote:
>> You can ask rev-parse to give you --symbolic-full-name, error out if
>> it is empty (i.e. detached HEAD), and otherwise use the result, no?
>>
>> $ git checkout next
>> $ git checkout master
>> $ git rev-parse --symbolic-full-name @{-1}
>> refs/heads/master
>> $ git checkout HEAD^0
>> $ git checkout master
>> $ git rev-parse --symbolic-full-name @{-1}
>> $ exit
>>
>> And
>>
>> $ git push origin :refs/heads/master
>>
>> would be the fully-spelled out way to remove that branch.
>
> Thanks Junio, I figured there was a command to do that. I tried to do
> this using '-' shorthand, but that didn't work. I guess because that's
> not really a revision, but a special function of git checkout only.

So the push works with the fully-qualified ref, but not git branch:

$ git rev-parse --symbolic-full-name foo
refs/heads/foo

$ git branch -d refs/heads/foo
error: branch 'refs/heads/foo' not found.

Any reason for this? I'm using git 2.7.4 on windows
--
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: How to use @{-1} with push?

[Robert Dailey]

On Fri, Mar 25, 2016 at 12:45 PM, Junio C Hamano  wrote:
> You can ask rev-parse to give you --symbolic-full-name, error out if
> it is empty (i.e. detached HEAD), and otherwise use the result, no?
>
> $ git checkout next
> $ git checkout master
> $ git rev-parse --symbolic-full-name @{-1}
> refs/heads/master
> $ git checkout HEAD^0
> $ git checkout master
> $ git rev-parse --symbolic-full-name @{-1}
> $ exit
>
> And
>
> $ git push origin :refs/heads/master
>
> would be the fully-spelled out way to remove that branch.

Thanks Junio, I figured there was a command to do that. I tried to do
this using '-' shorthand, but that didn't work. I guess because that's
not really a revision, but a special function of git checkout only.
--
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

How to use @{-1} with push?

[Robert Dailey]

I have an alias that I'm working on to do a push and delete of a topic branch:


# Push HEAD, delete branch local & remote
#
# $1 = remote name
# $2 = branch name
pushdel = "!f() { : git push ; git push \"$1\" HEAD \":$2\" && git
branch -d \"$2\" ; }; f"


I use it after I merge a topic branch, like so:

$ git pushdel origin my-topic-branch

What would be nice is if I could do one of the two:

$ git pushdel origin -
$ git pushdel origin @{-1}

Both should refer to the last branch, but I know that these can't be
used verbatim in a push command because it doesn't read it as a branch
name normally like `git checkout` would. I'm not sure why, as I do not
have knowledge of the underlying mechanics of these commands.

Is there a way I can use these "relative" branch shorthands in my push
command? If not directly, perhaps there is a way I can update my alias
to do an intermediate translation?

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

How can I get a list of checkout history?

[Robert Dailey]

As you know, I can checkout the Nth checked out branch via this syntax:

$ git checkout @{-N}

Is there a built-in mechanism to get a listing of previously checked
out refs? Basically, this would be similar to 'history' command in
linux where instead of actual commands, it lists like this:

HEAD@{-1}: master
HEAD@{-2}: topic1
HEAD@{-3}: 3f556e9 (detached)

Seems like reflog should be able to do this, and maybe it can, but I'm
not sure. Any tips? I'd be fine making a convenient alias for this if
it ends up being a series of piped commands.

Thanks in advance.
--
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 clean without ignored files

[Robert Dailey]

I noticed that `git clean` does not handle a specific scenario. I have
the following types of untracked entities in my working copy:

* Untracked files in tracked directories (non-recursive; sibling files
are tracked)
* Untracked files in untracked directories (recursive)
* Ignored files meeting the same criteria above

My goal is to clean the first 2 points, but not the 3rd. Basically, I
want all untracked files that show up in `git status` to be removed,
but not ignored files or directories.

If I run this command:

$ git clean -nd

I get a list of all the untracked files but oddly I get a few
directories in the list that indirectly ignored via my .gitignore.
Basically, the directory itself isn't ignored by any pattern in my
.gitignore but its entire contents (recursively) is ignored, due to
patterns matching the files themselves.

I think `clean` sees this as an untracked directory, because it's not
specifically matching a pattern in my .gitignore. Whereas git status
is smart enough to not display it because it knows that every single
file contained in there, regardless of depth, matches an ignore
pattern.

As a workaround, the following command accomplishes what I want:

$ git ls-files --others --exclude-standard | sed 's/.*/"&"/' | xargs rm -rfv

Is there a reason why `git clean -nd` file listing doesn't match more
closely with what I see in `git status` regarding untracked files and
directories?

Note I am aware git does not directly track directories. So when I
refer to tracked/untracked directories, I'm actually referring to that
directories contents recursively. If recursively 100 files exist, but
only 99 are ignored, then I consider that root directory to be
"untracked" but not ignored, because 1 file still shows up in `git
status`.
--
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

Convenient shortcut to push delete current branch?

[Robert Dailey]

For convenient pushing of current branch, git supports this syntax:

$ git push origin HEAD

This will push your current branch up. However, is there such a
shortcut for *deleting* the branch? The only goal here is to avoid
having to type the branch name in the push command. Normally I rely on
tab completion but we have tons of branches, all which start with some
prefix mixed with numbers, so it becomes cumbersome to rely on tab
completion. Ideally I'd like to be able to do:

$ git push --delete origin HEAD
$ git push origin :HEAD

Is there a syntax like this available?
--
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: Convenient shortcut to push delete current branch?

[Robert Dailey]

On Thu, Oct 1, 2015 at 1:22 PM, Jacob Keller <jacob.kel...@gmail.com> wrote:
> On Thu, Oct 1, 2015 at 9:43 AM, Robert Dailey <rcdailey.li...@gmail.com> 
> wrote:
>> For convenient pushing of current branch, git supports this syntax:
>>
>> $ git push origin HEAD
>>
>> This will push your current branch up. However, is there such a
>> shortcut for *deleting* the branch? The only goal here is to avoid
>> having to type the branch name in the push command. Normally I rely on
>> tab completion but we have tons of branches, all which start with some
>> prefix mixed with numbers, so it becomes cumbersome to rely on tab
>> completion. Ideally I'd like to be able to do:
>>
>> $ git push --delete origin HEAD
>> $ git push origin :HEAD
>>
>> Is there a syntax like this available?
>
> You can do
>
> git push origin:
>
> but I don't believe HEAD is supported. It might be valuable to extend
> push to have a --delete option which would maybe be useful for those
> who didn't learn the full refspec syntax.

Push already has a --delete option.

> I don't think git push origin :HEAD makes too much sense, since that's
> on the remote side of a refspec, and you want it interpreted
> locally... I suppose it makes sense somewhat, but other refspecs with
> HEAD on the remote side of the refspec don't really make sense, where
> as HEAD always makes sense on the local side of the refspec.

HEAD makes sense on the remote side if you think of it like an alias:

HEAD -> branch-name -> SHA1

HEAD simply points to branch-name. It makes sense for git to assume
that we should never do anything with real HEAD ref on the remote
side, and instead treat it as a substitution for the remote name. My
assumption may not be correct, but at the very least it should be a
niche case.
--
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 submodule init --recursive?

[Robert Dailey]

I have a few nested submodules, all use relative URLs such as:

../mysubmodule.git
../../tools/tool1.git

If I change my parent repo URL, I need to recursively update all
remotes in each submodule. There is no `--recursive` option for `git
submodule init`. What is the recommend method for accomplishing this?

Thanks in advance.
--
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 submodule init --recursive?

[Robert Dailey]

On Thu, Jun 25, 2015 at 8:04 PM, Robert Dailey rcdailey.li...@gmail.com wrote:
 I have a few nested submodules, all use relative URLs such as:

 ../mysubmodule.git
 ../../tools/tool1.git

 If I change my parent repo URL, I need to recursively update all
 remotes in each submodule. There is no `--recursive` option for `git
 submodule init`. What is the recommend method for accomplishing this?

 Thanks in advance.

Never mind please, I'm a moron. I'm supposed to use sync for this task.

Been a long day and haven't had enough beer yet.
--
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

'eol' documentation confusion

[Robert Dailey]

Upon inspection of the gitattributes documentation page here:
https://git-scm.com/docs/gitattributes

When comparing the documentation for 'text' with 'eol', I see the
following missing explanations for 'eol':

* eol
* -eol

Maybe the fact that these are missing means they are not valid to use.
There is also the issue that `text` usually controls EOL anyway. Is
there ever any reason to set eol in a way differently than explained
in the documentation (that is, `eol=lf` or `eol=crlf`)?

For example, what if you want a file to be treated as text BUT you do
not want it to perform EOL normalization at all. Could you do this?

foo.txt text -eol

Just at first glance, this to me would mean line endings on checkin
and checkout are not touched (CRLF could be checked in). Is this
possible?

What about setting `eol` but not `text`?

Honestly it seems like `eol` is just a supplementary setting for
`text` and was never intended to be used in ways that are
undocumented. Some explanation to help uncloud this would help, or
maybe I missed something in the documentation that explains this.
--
To unsubscribe from this list: send the line unsubscribe git in

Re: 'eol' documentation confusion

[Robert Dailey]

On Sun, Jun 21, 2015 at 9:04 AM, Robert Dailey rcdailey.li...@gmail.com wrote:
 Upon inspection of the gitattributes documentation page here:
 https://git-scm.com/docs/gitattributes

 When comparing the documentation for 'text' with 'eol', I see the
 following missing explanations for 'eol':

 * eol
 * -eol

 Maybe the fact that these are missing means they are not valid to use.
 There is also the issue that `text` usually controls EOL anyway. Is
 there ever any reason to set eol in a way differently than explained
 in the documentation (that is, `eol=lf` or `eol=crlf`)?

 For example, what if you want a file to be treated as text BUT you do
 not want it to perform EOL normalization at all. Could you do this?

 foo.txt text -eol

 Just at first glance, this to me would mean line endings on checkin
 and checkout are not touched (CRLF could be checked in). Is this
 possible?

 What about setting `eol` but not `text`?

 Honestly it seems like `eol` is just a supplementary setting for
 `text` and was never intended to be used in ways that are
 undocumented. Some explanation to help uncloud this would help, or
 maybe I missed something in the documentation that explains this.

I did a few tests out of curiosity:

* eol

This allowed CRLF to be committed in a file named `foo.txt` (I saw ^M
in the diff, which I think means CR character, and treats this
character as an error)

* text=auto eol

This did not differ in behavior from `* text=auto` from what I could
see. It removed CR characters in the repository on check in.

* text=auto -eol

Same as before, the addition of `-eol` did not change the behavior at all.

So yeah, I'm still horribly confused. None of these scenarios make any
sense. The only time I ever set `eol` explicitly is to either do
`eol=lf` or `eol=crlf`.
--
To unsubscribe from this list: send the line unsubscribe git in

Re: Git completion not using ls-remote to auto-complete during push

[Robert Dailey]

On Thu, Jun 18, 2015 at 6:29 AM, SZEDER Gábor sze...@ira.uka.de wrote:
 Quoting Robert Dailey rcdailey.li...@gmail.com
 I do the following:

 $ git push origin :topic

 If I stop halfway through typing 'topic' and hit TAB, auto-completion
 does not work if I do not have a local branch by that name (sometimes
 I delete my local branch first, then I push to delete it remotely). I
 thought that git completion code was supposed to use ls-remote to auto
 complete refs used in push operations. Is this supposed to work?

 It's intentional.  Running 'git ls-remote' with a far away remote can
 take ages, so instead we grab the refs on the remote from the locally
 stored refs under 'refs/remotes/remote/'.

 See e832f5c096 (completion: avoid ls-remote in certain scenarios,
 2013-05-28).  The commit message mentions that you can force
 completion of remote refs via 'git ls-remote' by starting with the full
 refname, i.e.  'refs/TAB', however, that seems to work only on the
 left hand side of the colon in the push refspec.

 Gábor


If that's indeed the case, then completion should work. I have a
'refs/remotes/origin/topic'. Why will auto complete not work even
though this exists? Do multiple remotes cause issues (in theory there
is no reason why it should cause problems, since it should know I'm
auto-completing a ref on 'origin')?
--
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 completion not using ls-remote to auto-complete during push

[Robert Dailey]

On Thu, Jun 18, 2015 at 10:55 AM, SZEDER Gábor sze...@ira.uka.de wrote:

 Quoting Robert Dailey rcdailey.li...@gmail.com:

 On Thu, Jun 18, 2015 at 6:29 AM, SZEDER Gábor sze...@ira.uka.de wrote:

 Quoting Robert Dailey rcdailey.li...@gmail.com

 I do the following:

 $ git push origin :topic

 If I stop halfway through typing 'topic' and hit TAB, auto-completion
 does not work if I do not have a local branch by that name (sometimes
 I delete my local branch first, then I push to delete it remotely). I
 thought that git completion code was supposed to use ls-remote to auto
 complete refs used in push operations. Is this supposed to work?


 It's intentional.  Running 'git ls-remote' with a far away remote can
 take ages, so instead we grab the refs on the remote from the locally
 stored refs under 'refs/remotes/remote/'.

 See e832f5c096 (completion: avoid ls-remote in certain scenarios,
 2013-05-28).  The commit message mentions that you can force
 completion of remote refs via 'git ls-remote' by starting with the full
 refname, i.e.  'refs/TAB', however, that seems to work only on the
 left hand side of the colon in the push refspec.

 Gábor


 If that's indeed the case, then completion should work. I have a
 'refs/remotes/origin/topic'. Why will auto complete not work even
 though this exists? Do multiple remotes cause issues (in theory there
 is no reason why it should cause problems, since it should know I'm
 auto-completing a ref on 'origin')?


 The number of remotes doesn't matter.
 What matters is which side of the colon the ref to be completed is.

 You can complete

   git push origin refs/TAB

 and

   git fetch origin refs/TAB

 will even list you refs freshly queried via 'git ls-remote'.
 However,

   git push origin :refs/TAB
   git push origin branch:refs/TAB

 don't work, because there are no refs starting with the prefix ':refs/' or
 'branch:refs/'.

 Gábor


Interesting. So is it just a glaring bug that the git completion
script isn't ignoring the : and anything to the left of it? Or is this
beyond the control of the script?
--
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 completion not using ls-remote to auto-complete during push

[Robert Dailey]

I do the following:

$ git push origin :topic

If I stop halfway through typing 'topic' and hit TAB, auto-completion
does not work if I do not have a local branch by that name (sometimes
I delete my local branch first, then I push to delete it remotely). I
thought that git completion code was supposed to use ls-remote to auto
complete refs used in push operations. Is this supposed to work?

I'm using Git 2.4.3. Tested on both MSYS2 in Windows and Linux Mint.
Same behavior in both. I am using the latest git completion code from
the master branch in the git repo.
--
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: Diffing submodule does not yield complete logs for merge commits

[Robert Dailey]

On Sat, May 30, 2015 at 2:19 PM, Robert Dailey rcdailey.li...@gmail.com wrote:
 On Sat, May 30, 2015 at 12:04 PM, Junio C Hamano gits...@pobox.com wrote:
 Robert Dailey rcdailey.li...@gmail.com writes:

 In the meantime I'd like to ask, do we even need to add an option for
 this? What if we just make `diff.submodule log` not use
 --first-parent? This seems like a backward compatible change in of
 itself.

 Why?  People have relied on submodule-log not to include all the
 noise coming from individual commits on side branches and instead
 appreciated seeing only the overview by merges of side branch topics
 being listed---why is regressing the system to inconvenience these
 existing users a backward compatible change?

 Backward compatible in the sense that it does not break existing
 functionality. For example, removing -D from `git branch` would be a
 backward breaking change.

 Also not everyone has a disciplined merge-commit editing policy like
 the Linux  Git projects do. In fact (especially in corporate
 environments), most merge commit messages are useless and
 auto-generated. It's in fact very common (depending on popular
 tooling) to not have the ability to edit these messages. Example:

 Merge branch topic into master

 This is the defacto message you get when you use Github, Atlassian
 Stash, etc. any time you merge a PR. For repositories that only accept
 changes through pull requests, it is not possible to generate a diff
 log of submodules that is useful without showing the ancestor commits
 on all parents. Right now 'log' literally gives you the following for
 a submodule that has a mainline branch that does not accept direct
 pushes (i.e. only PRs):

  Merge branch topic1 into master
  Merge branch topic2 into master
  Merge branch origin/develop into master
  Merge branch topic3 into master

 I would argue that this situation is common -- more common than what
 you would typically see in a well groomed git repository that does not
 use PRs or always does rebase+ff-merge.

 That is the basis for my concern. No functionality is broken and
 cators to the common case. But I guess since we're discussing 2
 distinct workflows, it makes sense to have 2 options for viewing the
 submodule logs. Because if 'full-log' were indeed the default, it
 would cause a lot of noise in the well-disciplined-merge-commit
 workflow.

 From a high level (to explain my motivation for my simplified and
 arguably naive suggestion), I work with a lot of amateur users of Git.
 They always complain about using Git and how SVN is better. Yet they
 do not accept the challenge of learning Git, which is a very
 complicated tool. Much of git I would argue is not very beginner (even
 user) friendly (although things are certainly getting better). With
 such an advanced tool, with such complex configuration and behavior,
 and given all the friction it causes, I can only do my best to offer
 seemingly sensible alternatives to adding MORE configuration.

 Anyway it's just a thought. Glad to get feedback and I see both sides
 of the fence on this one.

 And it's simpler to implement. I can't think of a good
 justification to add more settings to an already hugely complex
 configuration scheme for such a minor difference in behavior.

 Careful, as that argument can cut both ways.  If it is so a minor
 difference in behaviour, perhaps we can do without not just an
 option but a feature to omit --first-parent here.  That would be
 even simpler to implement, as you do not have to do anything.

 So, if you think the new behaviour can help _some_ users, then you
 would need the feature and a knob to enable it, I would think.

 I don't really understand your contrasted example here. Can you explain:

 ...we can do without not just an option but a feature to omit
 --first-parent...

 Again thanks for the feedback.

I'm having some difficulty with the tests. What it looks like is that
the test repository is created by calling test-lib.sh at the top. Then
by the time the commands after that are run, it's inside the temp
repository.

At the bottom of t4041, I add this:

test_create_repo sm3 
git add sm3 
cd sm3 
echo  foo.txt 
git add foo.txt 
git commit -m 'foo.txt' /dev/null 
git checkout -b topic /dev/null 
echo  topic.txt 
git add topic.txt 
git commit -m 'topic.txt' /dev/null 
git checkout master /dev/null 
git merge --no-ff --no-edit topic /dev/null 
cd .. 
git diff --submodule=log sm3

But this does not work as I expect. How do I add a submodule and then
simulate creation of branches, commits, and merges, prior to running
code in text_expect_success?
--
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: Diffing submodule does not yield complete logs for merge commits

[Robert Dailey]

On Sat, May 30, 2015 at 12:04 PM, Junio C Hamano gits...@pobox.com wrote:
 Robert Dailey rcdailey.li...@gmail.com writes:

 In the meantime I'd like to ask, do we even need to add an option for
 this? What if we just make `diff.submodule log` not use
 --first-parent? This seems like a backward compatible change in of
 itself.

 Why?  People have relied on submodule-log not to include all the
 noise coming from individual commits on side branches and instead
 appreciated seeing only the overview by merges of side branch topics
 being listed---why is regressing the system to inconvenience these
 existing users a backward compatible change?

Backward compatible in the sense that it does not break existing
functionality. For example, removing -D from `git branch` would be a
backward breaking change.

Also not everyone has a disciplined merge-commit editing policy like
the Linux  Git projects do. In fact (especially in corporate
environments), most merge commit messages are useless and
auto-generated. It's in fact very common (depending on popular
tooling) to not have the ability to edit these messages. Example:

Merge branch topic into master

This is the defacto message you get when you use Github, Atlassian
Stash, etc. any time you merge a PR. For repositories that only accept
changes through pull requests, it is not possible to generate a diff
log of submodules that is useful without showing the ancestor commits
on all parents. Right now 'log' literally gives you the following for
a submodule that has a mainline branch that does not accept direct
pushes (i.e. only PRs):

 Merge branch topic1 into master
 Merge branch topic2 into master
 Merge branch origin/develop into master
 Merge branch topic3 into master

I would argue that this situation is common -- more common than what
you would typically see in a well groomed git repository that does not
use PRs or always does rebase+ff-merge.

That is the basis for my concern. No functionality is broken and
cators to the common case. But I guess since we're discussing 2
distinct workflows, it makes sense to have 2 options for viewing the
submodule logs. Because if 'full-log' were indeed the default, it
would cause a lot of noise in the well-disciplined-merge-commit
workflow.

From a high level (to explain my motivation for my simplified and
arguably naive suggestion), I work with a lot of amateur users of Git.
They always complain about using Git and how SVN is better. Yet they
do not accept the challenge of learning Git, which is a very
complicated tool. Much of git I would argue is not very beginner (even
user) friendly (although things are certainly getting better). With
such an advanced tool, with such complex configuration and behavior,
and given all the friction it causes, I can only do my best to offer
seemingly sensible alternatives to adding MORE configuration.

Anyway it's just a thought. Glad to get feedback and I see both sides
of the fence on this one.

 And it's simpler to implement. I can't think of a good
 justification to add more settings to an already hugely complex
 configuration scheme for such a minor difference in behavior.

 Careful, as that argument can cut both ways.  If it is so a minor
 difference in behaviour, perhaps we can do without not just an
 option but a feature to omit --first-parent here.  That would be
 even simpler to implement, as you do not have to do anything.

 So, if you think the new behaviour can help _some_ users, then you
 would need the feature and a knob to enable it, I would think.

I don't really understand your contrasted example here. Can you explain:

...we can do without not just an option but a feature to omit
--first-parent...

Again thanks for the feedback.
--
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: Diffing submodule does not yield complete logs for merge commits

[Robert Dailey]

On Sat, May 30, 2015 at 2:54 PM, Junio C Hamano gits...@pobox.com wrote:
 Robert Dailey rcdailey.li...@gmail.com writes:

 On Sat, May 30, 2015 at 12:04 PM, Junio C Hamano gits...@pobox.com wrote:
 Robert Dailey rcdailey.li...@gmail.com writes:

 In the meantime I'd like to ask, do we even need to add an option for
 this? What if we just make `diff.submodule log` not use
 --first-parent? This seems like a backward compatible change in of
 itself.

 Why?  People have relied on submodule-log not to include all the
 noise coming from individual commits on side branches and instead
 appreciated seeing only the overview by merges of side branch topics
 being listed---why is regressing the system to inconvenience these
 existing users a backward compatible change?

 Backward compatible in the sense that it does not break existing
 functionality

 And adding one-line-per-commit from side branches does break
 existing functionality.  You seem to be arguing that more
 information is always good and does not break existing
 functionality, but summarizing by omitting irrelevant details *is* a
 feature.  Do you honestly believe that a change to make the full
 log -p output in submodule log be a backward compatible change??

  Merge branch topic1 into master
  Merge branch topic2 into master
  Merge branch origin/develop into master
  Merge branch topic3 into master

 It is not a real argument; it is something you can fix by naming
 your branches more sensibly, which would make you a better developer
 regardless of how submodule-log is shown.

I just use git, I don't have the deep technical understanding of its
implementation as you may have. From my perspective I can't think of
how this breaks backward compatibility, or perhaps your definition of
backward compatibility does not align with mine.

And please don't over generalize and misconvey what I said. I am not
saying more information is always good. Did you not read anything I
wrote?

Also good branch names may help but that doesn't go into detail and
explain features that may have been sitting on a topic branch for
weeks. That's not a practical solution to the problem. Also branch
names do not determine or influence the skill and quality of a
developer, as you seem to imply.

I'll do us both a favor and end the discussion here, as I do not feel
you are being very patient or welcoming in the discussion. I sense
frustration on your side.

 And it's simpler to implement. I can't think of a good
 justification to add more settings to an already hugely complex
 configuration scheme for such a minor difference in behavior.

 Careful, as that argument can cut both ways.  If it is so a minor
 difference in behaviour, perhaps we can do without not just an
 option but a feature to omit --first-parent here.  That would be
 even simpler to implement, as you do not have to do anything.

 I don't really understand your contrasted example here. Can you explain:

 ...we can do without not just an option but a feature to omit
 --first-parent...

 I am not sure how to phrase that any easier. Sorry.

You mean you don't want to? That's fine, if you don't have the will or
patience to explain then I won't bother caring.

 Assuming that you consider output with and without --first-parent
 does not make much of a difference (i.e. minor difference in
 behaviour), instead of dropping --first-parent unconditionally,
 like you seem to be pushing with the argument, we can
 unconditionally keep the --first-parent and do not change anything.
 The end result would not make much of a difference either way, and
 not doing anything is much simpler than dropping --first-parent.

 Hopefully you can see how absurd that line of reasoning is.  So do
 not make the same argument to push for changing the behaviour
 unconditionally.

 If you think the new behaviour can help _some_ users, then you would
 need the feature and a knob to enable it.

First of all, you keep calling this an argument. Perhaps it is for
you, since you're being absurdly rude with me and impatient with the
discussion. This is a brainstorming session. My suggestions may not
seem rational or make sense, but this is natural since I am ignorant
of the finer details of the application.

You're really just overanalyzing my statements from a nonsensical
perspective. I am talking about not adding more settings to an already
complex set of settings. I am not justifying my feature. I think the
feature is just as justified as everything else. Git is FULL of tons
of little options to cater to niche workflows.

I am not fighting against having another option. In fact, that was my
idea to begin with. I am investigating and trying to discuss all
possible approaches and perspectives.

Your attitude is not very welcoming to those that wish to contribute
to the project. In fact, because of your attitude towards me, I will
kindly see myself out. I do not have time to spend my free time
dealing with this nonsense and irrational

Re: Diffing submodule does not yield complete logs for merge commits

[Robert Dailey]

On 5/21/2015 7:51 AM, Heiko Voigt wrote:

On Tue, May 19, 2015 at 02:29:55PM -0500, Robert Dailey wrote:

On Tue, May 19, 2015 at 5:44 AM, Heiko Voigt hvo...@hvoigt.net wrote:

On Mon, May 18, 2015 at 10:06:32AM -0500, Robert Dailey wrote:

Unfortunately I find it unintuitive and counter productive to perform
inline patches or do anything on a mailing list. Especially on
Windows, it's a pain to setup git to effectively do this. Also I read
mailing lists through Gmail which does not offer a proper monospace
font view or syntax coloring to effectively review patches and
comments pertaining to them.


Are you sure you are not overestimating the effort it takes to send
patches inline? Once you've got your user agent correctly setup its just
a matter of copy and paste instead of attaching the patch. On Windows I
would probably use Thunderbird which has a section in the format-patch
documentation how to configure it. Compared to the effort you probably
spent on writing your patch isn't this bit of extra effort neglectable?
And your patch is almost done. It just needs some tests and maybe a few
rounds on the mailinglist after that.


Since I am not willing to properly follow your process, I will
withdraw my patch. However it is here if someone else wishes to take
it over. Really wish you guys used github's amazing features but I
understand that Linus has already made his decision in that matter.


It not just Linus decision it is also a matter of many people are used
to this workflow. AFAIR there have been many discussions and tries about
using other tools. Email has many advantages which a webinterface does
not provide. It is simply less effort that one person adjusts to this
workflow instead of changing many peoples working workflow.


I'm sorry I couldn't be more agreeable on the matter. Thanks for the
time you spent reviewing my patch.


If you are really this fixed in your workflow that would be too bad.


How do you send your patches inline? Do you use git send-email? I have
tried that and it is horrible to setup. Do you just copy/paste the
patch inline in your compose window?


For bigger patch series I did use send-email but currently I am back to
just using the compose window from whatever email client I am using. On
Windows that would be Thunderbird. But when possible I am not using
Windows.


It would be much simpler to fork Git, create a branch, make my change,
and initiate a pull request. I can get email notifications on comments
to my PR diff and address them with subsequent pushes to my branch
(which would also automatically update the code review). Turn around
times for collaborating on a change are much quicker via Github pull
requests.


I think that depends more on the collaborators than on the tool. When
you get quick replies the turnaround times with both workflows are
quick.

It would be nice if there was a perfect solution for every project that
everyone could use but unfortunately there is not so we sometimes have
to adjust. But I think its more matter of what you are used to. If you
did not have a github account but email software setup you could
complain about the fact that you need to register a github account, fork
git, setup that fork in your local repository, ... instead of just copy
and paste your change into the compose window and then send it to a
mailinglist.


I am willing to review the typical workflow for contributing via git
on mailing lists but I haven't seen any informative reading material
on this. I just find using command line to email patches and dealing
with other issues not worth the trouble. Lack of syntax highlighting,
lack of monospace font, the fact that I'm basically forced to install
mail client software just to contribute a single git patch.


As already mentioned by Stefan there is Documentation/SubmittingPatches
in the Git repository that describes everything and also has a section
on how to do that with Thunderbird.

I tend to not do much on the commandline on Windows since it basically
sucks there. For sending patches you just need

git format-patch HEAD^

and thats it.

Cheers Heiko



So I am working on trying to setup my environment (VM through Virtual 
Box) to do some testing on this. You all have encouraged me to try the 
mailing list review model. So I won't give up yet.


In the meantime I'd like to ask, do we even need to add an option for 
this? What if we just make `diff.submodule log` not use --first-parent? 
This seems like a backward compatible change in of itself. And it's 
simpler to implement. I can't think of a good justification to add more 
settings to an already hugely complex configuration scheme for such a 
minor difference in behavior.


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

How are submodule conflicts resolved during rebase?

[Robert Dailey]

Hey guys,

I'm using Git for Windows 2.3.6. There is a bit of confusion I have
with regards to how submodule conflicts are resolved/handled during a
rebase.

Suppose I have a branch with 10 commits on it, 3 of those commits
contain a change to the same (and only) submodule in the repository.
When I rebase this branch onto the tip of its parent branch, I get a
conflict in each of the 3 commits because the submodule also changed
on the parent branch since my last rebase.

I've seen some cases where I am asked to resolve the submodule
conflict with local or remote. I expect this behavior and it isn't
confusing to me. However, I have also seen cases where rebase auto
resolves the conflicted submodule.

How does Git know to auto resolve some submodule conflicts but not the
others? I find this behavior unpredictable and I haven't found any
documentation on it (I'm giving the git docs the benefit of the doubt
and assuming it's there, since the git docs are very very good).

Help is appreciated. 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: How are submodule conflicts resolved during rebase?

[Robert Dailey]

On Tue, Apr 28, 2015 at 9:34 AM, Robert Dailey rcdailey.li...@gmail.com wrote:
 Hey guys,

 I'm using Git for Windows 2.3.6. There is a bit of confusion I have
 with regards to how submodule conflicts are resolved/handled during a
 rebase.

 Suppose I have a branch with 10 commits on it, 3 of those commits
 contain a change to the same (and only) submodule in the repository.
 When I rebase this branch onto the tip of its parent branch, I get a
 conflict in each of the 3 commits because the submodule also changed
 on the parent branch since my last rebase.

 I've seen some cases where I am asked to resolve the submodule
 conflict with local or remote. I expect this behavior and it isn't
 confusing to me. However, I have also seen cases where rebase auto
 resolves the conflicted submodule.

 How does Git know to auto resolve some submodule conflicts but not the
 others? I find this behavior unpredictable and I haven't found any
 documentation on it (I'm giving the git docs the benefit of the doubt
 and assuming it's there, since the git docs are very very good).

 Help is appreciated. Thank you.

I also have rerere enabled in my global .gitconfig. Would this result
in the behavior above? Resolve first submodule conflict, rebase
--continue, then the next one is auto resolved?
--
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: How are submodule conflicts resolved during rebase?

[Robert Dailey]

On Tue, Apr 28, 2015 at 11:49 AM, Heiko Voigt hvo...@hvoigt.net wrote:
 On Tue, Apr 28, 2015 at 09:34:06AM -0500, Robert Dailey wrote:
 Suppose I have a branch with 10 commits on it, 3 of those commits
 contain a change to the same (and only) submodule in the repository.
 When I rebase this branch onto the tip of its parent branch, I get a
 conflict in each of the 3 commits because the submodule also changed
 on the parent branch since my last rebase.

 I've seen some cases where I am asked to resolve the submodule
 conflict with local or remote. I expect this behavior and it isn't
 confusing to me. However, I have also seen cases where rebase auto
 resolves the conflicted submodule.

 How does Git know to auto resolve some submodule conflicts but not the
 others? I find this behavior unpredictable and I haven't found any
 documentation on it (I'm giving the git docs the benefit of the doubt
 and assuming it's there, since the git docs are very very good).

 There is some logic for submodule merges, but to prevent false merges
 only the straight forward case results in a clean merge. In short:
 Conflicts for submodules are auto resolved when one side is contained in
 the other and both changes point forward.

 I.e. when merging A and B in the superproject and the submodule looks
 like this:

 base---*---*---B
 \ /
  *---A---*---*

 It will result in a clean merge in the superproject.

 If there is a common commit that contains both sides but that commit is
 not part of any side in the superproject the merge will fail but suggest
 that commit as a conflict resolution.

 Hope that helps.

 Cheers Heiko

So if I understand this correctly, you are saying that during a rebase
if it sees a potential conflict for a submodule in the commit being
rebased, it will inspect the ancestry of the actual commits in the
submodule logs? For a rebase, does this mean that the local (latest
SHA1 from the submodule in the target branch of the rebase) submodule
commit must be reachable from the remote (SHA1 contained in the diff
of the commit currently being rebased) submodule commit?

I just want to make sure this is the logic. Thanks for explaining,
still trying to wrap my head around it.
--
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: Rebasing with submodule change causes red herring with --continue

[Robert Dailey]

On Thu, Apr 23, 2015 at 5:43 PM, John Keeping j...@keeping.me.uk wrote:
 On Thu, Apr 23, 2015 at 09:35:38PM +0100, John Keeping wrote:
 On Thu, Apr 23, 2015 at 09:43:44PM +0200, Jens Lehmann wrote:
  Am 23.04.2015 um 21:07 schrieb Robert Dailey:
   On Thu, Apr 23, 2015 at 1:17 PM, Robert Dailey 
   rcdailey.li...@gmail.com wrote:
   On Fri, Apr 10, 2015 at 11:44 AM, John Keeping j...@keeping.me.uk 
   wrote:
   On Fri, Apr 10, 2015 at 11:30:20AM -0500, Robert Dailey wrote:
   I have a branch that contains a commit with a single change: A
   submodule pointing to a new SHA1.
  
   When I rebase this branch onto the tip of its parent branch AND that
   parent branch had modified that same submodule, the rebase stops at
   the commit on my branch that modified the submodule and asks me if I
   want to keep REMOTE or LOCAL. I say LOCAL and notice immediately that
   the submodule is not staged (normally it would be).
  
   I do:
  
   $ git add my-submodule
  
   Then I do:
  
   $ git rebase --continue
  
   At this point, it fails asking me if I forgot to stage changes and
   recommends doing --skip. This is normally what you would see if the
   staging area was completely empty, however it isn't, since I see the
   submodule is in there.
  
   Is this a bug or am I missing a fundamental here? I'm using Git 2.1.0
   on Windows through MSYS. I'll provide more concrete examples if my
   summary of the issue doesn't ring any bells.
  
   I hit something similar in the past, but it was fixed with commit
   a6754cd (rebase -i continue: don't skip commits that only change
   submodules, 2012-04-07) so I think you must be hitting a slightly
   different problem, although the tests added in that commit look like
   they do test the scenario you describe (specifically 'rebase -i 
   continue
   with only submodule staged').
  
   I am still running into this issue on git 2.3.5 on Windows. Logs
   below. One interesting thing to note in the git trace output is that
   it is specifying --ignore-submodules option to `git diff-files` during
   the rebase continue. Is this due to a configuration option? It seems
   like git should not be ignoring submodules when continuing a rebase
   (this should only affect direct calls to diff)
  
  
   |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --|
   $ git status
   rebase in progress; onto bb05e7c
   You are currently rebasing branch 'timeline-ids-develop' on 'bb05e7c'.
  (all conflicts fixed: run git rebase --continue)
  
   Changes to be committed:
  (use git reset HEAD file... to unstage)
  
modified:   Core
  
   Changes not staged for commit:
  (use git add file... to update what will be committed)
  (use git checkout -- file... to discard changes in working 
   directory)
  
modified:   Core (new commits)
  
   Untracked files:
  (use git add file... to include in what will be committed)
  
Tools/FontTool/
  
  
   |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --|
   $ GIT_TRACE=1 git rebase --continue
   19:15:33.569945 git.c:557   trace: exec: 'git-rebase' 
   '--continue'
   19:15:33.569945 run-command.c:351   trace: run_command:
   'git-rebase' '--continue'
   19:15:33.775097 git.c:348   trace: built-in: git
   'rev-parse' '--parseopt' '--stuck-long' '--' '--continue'
   19:15:33.931190 git.c:348   trace: built-in: git
   'rev-parse' '--git-dir'
   19:15:34.007242 git.c:348   trace: built-in: git
   'rev-parse' '--is-bare-repository'
   19:15:34.059280 git.c:348   trace: built-in: git
   'rev-parse' '--show-toplevel'
   19:15:34.148343 git.c:348   trace: built-in: git 'config'
   '--bool' 'rebase.stat'
   19:15:34.227399 git.c:348   trace: built-in: git 'config'
   '--bool' 'rebase.autostash'
   19:15:34.280437 git.c:348   trace: built-in: git 'config'
   '--bool' 'rebase.autosquash'
   19:15:34.335476 git.c:348   trace: built-in: git
   'rev-parse' '--verify' 'HEAD'
   19:15:34.389515 git.c:348   trace: built-in: git
   'update-index' '--ignore-submodules' '--refresh'
   19:15:34.554631 git.c:348   trace: built-in: git
   'diff-files' '--quiet' '--ignore-submodules'
   19:15:34.902879 git.c:557   trace: exec: 'git-am'
   '--resolved' '--resolvemsg=
   When you have resolved this problem, run git rebase --continue.
   If you prefer to skip this patch, run git rebase --skip instead.
   To check out the original branch and stop rebasing, run git rebase 
   --abort.
   '
   19:15:34.902879 run-command.c:351   trace: run_command: 'git-am'
   '--resolved' '--resolvemsg=
   When you have resolved this problem, run git rebase --continue.
   If you prefer to skip this patch, run git rebase --skip instead.
   To check out the original branch and stop rebasing, run git rebase 
   --abort.
   '
   19:15:35.113028 git.c:348

Re: Rebasing with submodule change causes red herring with --continue

[Robert Dailey]

On Fri, Apr 10, 2015 at 11:44 AM, John Keeping j...@keeping.me.uk wrote:
 On Fri, Apr 10, 2015 at 11:30:20AM -0500, Robert Dailey wrote:
 I have a branch that contains a commit with a single change: A
 submodule pointing to a new SHA1.

 When I rebase this branch onto the tip of its parent branch AND that
 parent branch had modified that same submodule, the rebase stops at
 the commit on my branch that modified the submodule and asks me if I
 want to keep REMOTE or LOCAL. I say LOCAL and notice immediately that
 the submodule is not staged (normally it would be).

 I do:

 $ git add my-submodule

 Then I do:

 $ git rebase --continue

 At this point, it fails asking me if I forgot to stage changes and
 recommends doing --skip. This is normally what you would see if the
 staging area was completely empty, however it isn't, since I see the
 submodule is in there.

 Is this a bug or am I missing a fundamental here? I'm using Git 2.1.0
 on Windows through MSYS. I'll provide more concrete examples if my
 summary of the issue doesn't ring any bells.

 I hit something similar in the past, but it was fixed with commit
 a6754cd (rebase -i continue: don't skip commits that only change
 submodules, 2012-04-07) so I think you must be hitting a slightly
 different problem, although the tests added in that commit look like
 they do test the scenario you describe (specifically 'rebase -i continue
 with only submodule staged').

I am still running into this issue on git 2.3.5 on Windows. Logs
below. One interesting thing to note in the git trace output is that
it is specifying --ignore-submodules option to `git diff-files` during
the rebase continue. Is this due to a configuration option? It seems
like git should not be ignoring submodules when continuing a rebase
(this should only affect direct calls to diff)


|-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --|
$ git status
rebase in progress; onto bb05e7c
You are currently rebasing branch 'timeline-ids-develop' on 'bb05e7c'.
  (all conflicts fixed: run git rebase --continue)

Changes to be committed:
  (use git reset HEAD file... to unstage)

modified:   Core

Changes not staged for commit:
  (use git add file... to update what will be committed)
  (use git checkout -- file... to discard changes in working directory)

modified:   Core (new commits)

Untracked files:
  (use git add file... to include in what will be committed)

Tools/FontTool/


|-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --|
$ GIT_TRACE=1 git rebase --continue
19:15:33.569945 git.c:557   trace: exec: 'git-rebase' '--continue'
19:15:33.569945 run-command.c:351   trace: run_command:
'git-rebase' '--continue'
19:15:33.775097 git.c:348   trace: built-in: git
'rev-parse' '--parseopt' '--stuck-long' '--' '--continue'
19:15:33.931190 git.c:348   trace: built-in: git
'rev-parse' '--git-dir'
19:15:34.007242 git.c:348   trace: built-in: git
'rev-parse' '--is-bare-repository'
19:15:34.059280 git.c:348   trace: built-in: git
'rev-parse' '--show-toplevel'
19:15:34.148343 git.c:348   trace: built-in: git 'config'
'--bool' 'rebase.stat'
19:15:34.227399 git.c:348   trace: built-in: git 'config'
'--bool' 'rebase.autostash'
19:15:34.280437 git.c:348   trace: built-in: git 'config'
'--bool' 'rebase.autosquash'
19:15:34.335476 git.c:348   trace: built-in: git
'rev-parse' '--verify' 'HEAD'
19:15:34.389515 git.c:348   trace: built-in: git
'update-index' '--ignore-submodules' '--refresh'
19:15:34.554631 git.c:348   trace: built-in: git
'diff-files' '--quiet' '--ignore-submodules'
19:15:34.902879 git.c:557   trace: exec: 'git-am'
'--resolved' '--resolvemsg=
When you have resolved this problem, run git rebase --continue.
If you prefer to skip this patch, run git rebase --skip instead.
To check out the original branch and stop rebasing, run git rebase --abort.
'
19:15:34.902879 run-command.c:351   trace: run_command: 'git-am'
'--resolved' '--resolvemsg=
When you have resolved this problem, run git rebase --continue.
If you prefer to skip this patch, run git rebase --skip instead.
To check out the original branch and stop rebasing, run git rebase --abort.
'
19:15:35.113028 git.c:348   trace: built-in: git
'rev-parse' '--parseopt' '--stuck-long' '--' '--resolved'
'--resolvemsg=
When you have resolved this problem, run git rebase --continue.
If you prefer to skip this patch, run git rebase --skip instead.
To check out the original branch and stop rebasing, run git rebase --abort.
'
19:15:35.290155 git.c:348   trace: built-in: git
'rev-parse' '--git-dir'
19:15:35.387224 git.c:348   trace: built-in: git
'rev-parse' '--show-prefix'
19:15:35.541332 git.c:348   trace: built-in: git
'rev-parse' '--show-toplevel'
19:15:35.598374 git.c:348   trace: built-in: git

Re: Rebasing with submodule change causes red herring with --continue

[Robert Dailey]

On Thu, Apr 23, 2015 at 1:17 PM, Robert Dailey rcdailey.li...@gmail.com wrote:
 On Fri, Apr 10, 2015 at 11:44 AM, John Keeping j...@keeping.me.uk wrote:
 On Fri, Apr 10, 2015 at 11:30:20AM -0500, Robert Dailey wrote:
 I have a branch that contains a commit with a single change: A
 submodule pointing to a new SHA1.

 When I rebase this branch onto the tip of its parent branch AND that
 parent branch had modified that same submodule, the rebase stops at
 the commit on my branch that modified the submodule and asks me if I
 want to keep REMOTE or LOCAL. I say LOCAL and notice immediately that
 the submodule is not staged (normally it would be).

 I do:

 $ git add my-submodule

 Then I do:

 $ git rebase --continue

 At this point, it fails asking me if I forgot to stage changes and
 recommends doing --skip. This is normally what you would see if the
 staging area was completely empty, however it isn't, since I see the
 submodule is in there.

 Is this a bug or am I missing a fundamental here? I'm using Git 2.1.0
 on Windows through MSYS. I'll provide more concrete examples if my
 summary of the issue doesn't ring any bells.

 I hit something similar in the past, but it was fixed with commit
 a6754cd (rebase -i continue: don't skip commits that only change
 submodules, 2012-04-07) so I think you must be hitting a slightly
 different problem, although the tests added in that commit look like
 they do test the scenario you describe (specifically 'rebase -i continue
 with only submodule staged').

 I am still running into this issue on git 2.3.5 on Windows. Logs
 below. One interesting thing to note in the git trace output is that
 it is specifying --ignore-submodules option to `git diff-files` during
 the rebase continue. Is this due to a configuration option? It seems
 like git should not be ignoring submodules when continuing a rebase
 (this should only affect direct calls to diff)


 |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --|
 $ git status
 rebase in progress; onto bb05e7c
 You are currently rebasing branch 'timeline-ids-develop' on 'bb05e7c'.
   (all conflicts fixed: run git rebase --continue)

 Changes to be committed:
   (use git reset HEAD file... to unstage)

 modified:   Core

 Changes not staged for commit:
   (use git add file... to update what will be committed)
   (use git checkout -- file... to discard changes in working directory)

 modified:   Core (new commits)

 Untracked files:
   (use git add file... to include in what will be committed)

 Tools/FontTool/


 |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --|
 $ GIT_TRACE=1 git rebase --continue
 19:15:33.569945 git.c:557   trace: exec: 'git-rebase' '--continue'
 19:15:33.569945 run-command.c:351   trace: run_command:
 'git-rebase' '--continue'
 19:15:33.775097 git.c:348   trace: built-in: git
 'rev-parse' '--parseopt' '--stuck-long' '--' '--continue'
 19:15:33.931190 git.c:348   trace: built-in: git
 'rev-parse' '--git-dir'
 19:15:34.007242 git.c:348   trace: built-in: git
 'rev-parse' '--is-bare-repository'
 19:15:34.059280 git.c:348   trace: built-in: git
 'rev-parse' '--show-toplevel'
 19:15:34.148343 git.c:348   trace: built-in: git 'config'
 '--bool' 'rebase.stat'
 19:15:34.227399 git.c:348   trace: built-in: git 'config'
 '--bool' 'rebase.autostash'
 19:15:34.280437 git.c:348   trace: built-in: git 'config'
 '--bool' 'rebase.autosquash'
 19:15:34.335476 git.c:348   trace: built-in: git
 'rev-parse' '--verify' 'HEAD'
 19:15:34.389515 git.c:348   trace: built-in: git
 'update-index' '--ignore-submodules' '--refresh'
 19:15:34.554631 git.c:348   trace: built-in: git
 'diff-files' '--quiet' '--ignore-submodules'
 19:15:34.902879 git.c:557   trace: exec: 'git-am'
 '--resolved' '--resolvemsg=
 When you have resolved this problem, run git rebase --continue.
 If you prefer to skip this patch, run git rebase --skip instead.
 To check out the original branch and stop rebasing, run git rebase --abort.
 '
 19:15:34.902879 run-command.c:351   trace: run_command: 'git-am'
 '--resolved' '--resolvemsg=
 When you have resolved this problem, run git rebase --continue.
 If you prefer to skip this patch, run git rebase --skip instead.
 To check out the original branch and stop rebasing, run git rebase --abort.
 '
 19:15:35.113028 git.c:348   trace: built-in: git
 'rev-parse' '--parseopt' '--stuck-long' '--' '--resolved'
 '--resolvemsg=
 When you have resolved this problem, run git rebase --continue.
 If you prefer to skip this patch, run git rebase --skip instead.
 To check out the original branch and stop rebasing, run git rebase --abort.
 '
 19:15:35.290155 git.c:348   trace: built-in: git
 'rev-parse' '--git-dir'
 19:15:35.387224 git.c:348   trace: built-in: git
 'rev-parse' '--show-prefix'
 19

Re: Need help deciding between subtree and submodule

[Robert Dailey]

On Wed, Mar 18, 2015 at 6:04 PM, Doug Kelly dougk@gmail.com wrote:
 On Wed, Mar 18, 2015 at 3:20 AM, Chris Packham judge.pack...@gmail.com 
 wrote:
 My $0.02 based on $dayjob

 (disclaimer I've never used subtree)

 On Wed, Mar 18, 2015 at 11:14 AM, Robert Dailey
 rcdailey.li...@gmail.com wrote:
 At my workplace, the team is using Atlassian Stash + git

 We have a Core library that is our common code between various
 projects. To avoid a single monolithic repository and to allow our
 apps and tools to be modularized into their own repos, I have
 considered moving Core to a subtree or submodule.

 $DAYJOB has actually tried both... with varying levels of success.  As
 you note, subtree looks wonderful from a user perspective, but behind
 the scenes, it does have issues.  In our case, subtree support was
 modified into Gerrit, and this became cumbersome and difficult to
 maintain (which is the reason we eventually dropped support for
 subtree).  Submodules have more of a labor-intensive aspect, but
 are far more obvious about what actions have been taken (IMHO).
 Either way, both our developers' needs were satisfied: the code was
 tracked cleanly, and there wasn't a configuration mismatch where
 a dependency was able to change versions without implicit direction.


 Our environment is slightly different. Our projects are made up
 entirely of submodules, we don't embed submodules within a repo with
 actual code (side note: I know syslog-ng does so it might be worth
 having a look around there).

 Day to day development is done at the submodule level. A developer
 working on a particular feature is generally only touching one repo
 notwithstanding a little bit of to-and-fro as they work on the UI
 aspects. When changes do touch multiple submodules the pushes can
 generally be ordered in a sane manner. Things get a little complicated
 when there are interdependent changes, then those pushes require
 co-operation between submodule owners.

 We've done both (all of the above? a hybrid approach?)... We've gone so
 far to create 30 modules for every conceivable component, then tried to
 work that way with submodule, and our developers quickly revolted as it
 became too much of a maintenance burden.  The other direction (with
 hugely monolithic code) is also problematic since the module boundaries
 become blurred.  For us, usually cooperation between modules isn't so
 difficult, but the problem comes about when attempting to merge the
 changes.  Sometimes, it can take significant effort to ensure conflict-free
 merges (going so far as to require merge lock emails to ask other
 developers to hold off on merging commits until the change lands
 completely and the project is stable).


 The key to making this work is our build system. It is the thing that
 updates the project repo. After a successful build for all targets (we
 hope to add unit/regression tests one day) the submodules sha1s are
 updated and a new baseline (to borrow a clearcase term) is published.
 Developers can do git pull  git submodule update to get the latest
 stable baseline, but they can also run git pull in a submodule if they
 want to be on the bleeding edge.

 I tried subtree and this is definitely far more transparent and simple
 to the team (simplicity is very important), however I notice it has
 problems with unnecessary conflicts when you do not do `git subtree
 push` for each `git subtree pull`. This is unnecessary overhead and
 complicates the log graph which I don't like.

 Submodule functionally works but it is complicated. We make heavy use
 of pull requests for code reviews (they are required due to company
 policy). Instead of a pull request being atomic and containing any app
 changes + accompanying Core changes, we now need to create two pull
 requests and manage them in proper order. Things also become more
 difficult when branching. All around it just feels like submodule
 would interfere and add more administration overhead on a day to day
 basis, affecting productivity.

 We do have policies around review etc. With submodules it does
 sometimes require engaging owners/reviewers from multiple
 repositories. Tools like Gerrit can help, particularly where multiple
 changes and reviewers are involved.

 Conflicts are definitely going to be a difficulty with either subtree or
 submodule (if multiple users could be changing the submodule), but
 if you have additional tools, such as Gerrit to look out for, submodule
 is the way to go since subtrees aren't supported within Gerrit. (Other
 tools may support it better: I'm honestly not sure?)  That would be
 my one word of caution: I don't know how well Stash supports subtree.

 You are absolutely correct about the difficulty of integrating submodule
 pull requests taking two steps.  This was an issue we worked hard
 to mitigate here, but at the end of the day, the work is necessary.
 Basically, we could also use a feature within Gerrit to automatically
 bring up a specific branch

Need help deciding between subtree and submodule

[Robert Dailey]

At my workplace, the team is using Atlassian Stash + git

We have a Core library that is our common code between various
projects. To avoid a single monolithic repository and to allow our
apps and tools to be modularized into their own repos, I have
considered moving Core to a subtree or submodule.

I tried subtree and this is definitely far more transparent and simple
to the team (simplicity is very important), however I notice it has
problems with unnecessary conflicts when you do not do `git subtree
push` for each `git subtree pull`. This is unnecessary overhead and
complicates the log graph which I don't like.

Submodule functionally works but it is complicated. We make heavy use
of pull requests for code reviews (they are required due to company
policy). Instead of a pull request being atomic and containing any app
changes + accompanying Core changes, we now need to create two pull
requests and manage them in proper order. Things also become more
difficult when branching. All around it just feels like submodule
would interfere and add more administration overhead on a day to day
basis, affecting productivity.

Is there a third option here I'm missing? If only that issue with
subtree could be addressed (the conflicts), it would be perfect enough
for us I think. I have done all the stackoverflow reading and research
I can manage at this point. I would really love some feedback from the
actual git community on what would be a practical solution and
structure here from a company perspective.

Thanks in advance!
--
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