Re: [PATCH 1/4] git-prompt.sh: add submodule indicator
On Sun, Feb 5, 2017 at 9:55 PM, Jacob Keller wrote: > On Sun, Feb 5, 2017 at 8:23 PM, Stefan Beller wrote: >> >> (unrelated side note:) >> At GitMerge facebook presented their improvements on mercurial >> and one of the things was "hg absorb". It would take the dirty hunks/lines >> of the working tree and amend them into the "stack of commits", i.e. into >> your local unpublished history. So instead of making fixup commits >> and doing the whole interactive rebase thing, it would do it automatically >> for you. I think that is a neat time saver. >> >> Thanks, >> Stefan > > How exactly was it different from doing "git commit --fixup xyz" and > "git rebase -i --autosquash"? Like, what was the advantage to the user > facing workflow? Just curious to see if we could learn something from > it. My impression is that all local changes were split up and the "xyz" was determined based off a heuristic, e.g. blame(?) and then the rebase is run automatically after that, i.e. having just one command for a complete workflow here, moving up a whole level in abstraction.
Re: [PATCH 1/4] git-prompt.sh: add submodule indicator
On Sun, Feb 5, 2017 at 8:23 PM, Stefan Beller wrote: > > (unrelated side note:) > At GitMerge facebook presented their improvements on mercurial > and one of the things was "hg absorb". It would take the dirty hunks/lines > of the working tree and amend them into the "stack of commits", i.e. into > your local unpublished history. So instead of making fixup commits > and doing the whole interactive rebase thing, it would do it automatically > for you. I think that is a neat time saver. > > Thanks, > Stefan How exactly was it different from doing "git commit --fixup xyz" and "git rebase -i --autosquash"? Like, what was the advantage to the user facing workflow? Just curious to see if we could learn something from it. Regards, Jake
Re: [PATCH 1/4] git-prompt.sh: add submodule indicator
On Mon, Jan 30, 2017 at 7:11 PM, Junio C Hamano wrote: > Benjamin Fuchs writes: > >> In [2/4] I got rid of the loop by feedback of Gábor. >> Sorry if my patch wasn't well formed. > > While it might be the way other development communities work, in the > Git development community, we do not work that way when presenting > your second and subsequent attempt to the community. > > Having the initial draft from the original developers that records > the bugs and misdesigns in an earlier parts of a series and separate > patches that record how the problems were fixed to arrive at the > final shape of the codebase might be interesting to the original > developers, and they may even find such a history valuable, but in > the context of the history that will be recorded in the official > tree of the project for eternity, that just adds useless noise. > > Instead of keeping the original, in which problems were pointed out, > and adding later commits to correct them incrementally, a patch is > "rerolled". That is, you are expected to learn from the review > comments and pretend as if you did the work from scratch and you > already possessed the wisdom lent by the reviewers when you started > your work. In the "rerolled" patches you send, you pretend as if > you worked without making mistakes you made in the earlier rounds at > all, producing (more) perfect patches from the beginning. > > In reality, you may locally be using Git tools like rebase, > cherry-pick and "add -p" while preparing these "rerolled" rounds of > patches, but the name of the game is to hide that effort from the > public and pretend to be a perfect human, recording the result of > exercising your best ability in the official history ;-). > > So this is OK: > > 0/3: I want to improve X, and for that I identified that I need > A, B and C done. A or B alone is already an improvement, but A > and B together makes it even more useful, and implementation of > C requires patches to do A and B. > > 1/3: do A > 2/3: do B > 3/3: do C, building on A and B > > This is not: > > 0/3: I want to improve X, and for that I need to do C. > 1/3: I couldn't do C, and I did A instead. > 2/3: A was totally useless. I fix it to do B. > 3/3: B is not very useful, either. I fix it to do C. > I agree with Junio here, "git rebase --interactive" and then editing/squashing commits is your friend. (unrelated side note:) At GitMerge facebook presented their improvements on mercurial and one of the things was "hg absorb". It would take the dirty hunks/lines of the working tree and amend them into the "stack of commits", i.e. into your local unpublished history. So instead of making fixup commits and doing the whole interactive rebase thing, it would do it automatically for you. I think that is a neat time saver. Thanks, Stefan
Re: [PATCH 1/4] git-prompt.sh: add submodule indicator
Benjamin Fuchs writes: > In [2/4] I got rid of the loop by feedback of Gábor. > Sorry if my patch wasn't well formed. While it might be the way other development communities work, in the Git development community, we do not work that way when presenting your second and subsequent attempt to the community. Having the initial draft from the original developers that records the bugs and misdesigns in an earlier parts of a series and separate patches that record how the problems were fixed to arrive at the final shape of the codebase might be interesting to the original developers, and they may even find such a history valuable, but in the context of the history that will be recorded in the official tree of the project for eternity, that just adds useless noise. Instead of keeping the original, in which problems were pointed out, and adding later commits to correct them incrementally, a patch is "rerolled". That is, you are expected to learn from the review comments and pretend as if you did the work from scratch and you already possessed the wisdom lent by the reviewers when you started your work. In the "rerolled" patches you send, you pretend as if you worked without making mistakes you made in the earlier rounds at all, producing (more) perfect patches from the beginning. In reality, you may locally be using Git tools like rebase, cherry-pick and "add -p" while preparing these "rerolled" rounds of patches, but the name of the game is to hide that effort from the public and pretend to be a perfect human, recording the result of exercising your best ability in the official history ;-). So this is OK: 0/3: I want to improve X, and for that I identified that I need A, B and C done. A or B alone is already an improvement, but A and B together makes it even more useful, and implementation of C requires patches to do A and B. 1/3: do A 2/3: do B 3/3: do C, building on A and B This is not: 0/3: I want to improve X, and for that I need to do C. 1/3: I couldn't do C, and I did A instead. 2/3: A was totally useless. I fix it to do B. 3/3: B is not very useful, either. I fix it to do C.
Re: [PATCH 1/4] git-prompt.sh: add submodule indicator
Hi Junio,
thanks for your reply. Some of your suggestions are covered by my rework
in Patch [2/4].
In [2/4] I got rid of the loop by feedback of Gábor.
Sorry if my patch wasn't well formed.
On 31.01.2017 00:48, Junio C Hamano wrote:
Benjamin Fuchs writes:
I expirienced that working with submodules can be confusing. This indicator
will make you notice very easy when you switch into a submodule.
I am not quite sure what the above wants to say. If you work on two
projects, A and B, then having something that quickly reminds you
which one you are in is beneficial and people often do so by having
the current directory name in the prompt.
The log message needs to explain why working on a submodule C of a
project A is any more special, i.e. why are the existing ways the
users are using to remind them between A and B cannot be used for C.
A submodule can be anywhere in your parent git repository. And while
walking through the
parent repository it is sometime a good reminder to know when to just
entered a submodule.
Because now all git command will work on the submodule. I guess this
indicator is a good way
to show that.
And with patch [2/4] (and fixed it with [3/4]) I also introduced the
"dirty" indicator for the submodule, which can
show you, that your current checked out state in the submodule is not
the one committed
to the parent.
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 97eacd7..4c82e7f 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -93,6 +93,10 @@
# directory is set up to be ignored by git, then set
# GIT_PS1_HIDE_IF_PWD_IGNORED to a nonempty value. Override this on the
# repository level by setting bash.hideIfPwdIgnored to "false".
+#
+# If you would like __git_ps1 to indicate that you are in a submodule,
+# set GIT_PS1_SHOWSUBMODULE. In this case a "sub:" will be added before
+# the branch name.
# check whether printf supports -v
__git_printf_supports_v=
@@ -284,6 +288,32 @@ __git_eread ()
test -r "$f" && read "$@" <"$f"
}
+# __git_is_submodule
+# Based on:
+#
http://stackoverflow.com/questions/7359204/git-command-line-know-if-in-submodule
+__git_is_submodule ()
It seems like this function is checking if you are "IN" submodule,
not "IS" submodule. A misnamed function?
Reworked in Patch [2/4]
+{
+ local git_dir parent_git module_name path
+ # Find the root of this git repo, then check if its parent dir is also
a repo
+ git_dir="$(git rev-parse --show-toplevel)"
+ module_name="$(basename "$git_dir")"
This does not give "module_name" in the sense the word is used in
the submodule subsystem. If this variable is useful, call that
with "path" in its name (I do not think it alone is useful at all).
Reworked in Patch [2/4]
+ parent_git="$(cd "$git_dir/.." && git rev-parse --show-toplevel 2>
/dev/null)"
+ if [[ -n $parent_git ]]; then
+ # List all the submodule paths for the parent repo
+ while read path
+ do
+ if [[ "$path" != "$module_name" ]]; then continue; fi
+ if [[ -d "$git_dir/../$path" ]];then return 0; fi
+ done < <(cd $parent_git && git submodule --quiet foreach 'echo
$path' 2> /dev/null)
Instead of doing this "loop over submodules and just get true or
false", it may make a lot more sense to find the module name and
report that. That would allow you to have the actual submodule
name, not a generic "sub:" which does not help the users to tell
which one of 47 submodules they have in their top-level project
they are currently in.
If your projects are layed out like so
/home/bf/projects/A/
/home/bf/projects/A/lib/B/ -- submodule
/home/bf/projects/A/Doc/ -- another submodule
/home/bf/projects/A/Doc/technical -- a subdirectory of Doc submodule
and you are in /home/bf/projects/A/Doc/technical/ subdirectory, your
$git_dir variable (which is grossly misnamed, too; call it "top"
perhaps?) would be "/home/bf/projects/A/Doc" and then your
$parent_git variable (again, that is misnamed; call it
"parent_top"?) would be "/home/bf/projects/A". The submodule path
to the submodule you are currently in is "Doc" (you learn it as the
difference between these two).
You can ask the top-level project the name of the submodule that is
currently at "Doc" with "submodule--helper name". Unless the project
has moved it since it first added the submodule, the module name may
also be "Doc", but if it were moved, it may be different.
And that "module name" is a more useful thing than a hardcoded
string "sub:" to use in the prompt, I would think.
Reworked in Patch [2/4].
Re: [PATCH 1/4] git-prompt.sh: add submodule indicator
Benjamin Fuchs writes:
> I expirienced that working with submodules can be confusing. This indicator
> will make you notice very easy when you switch into a submodule.
I am not quite sure what the above wants to say. If you work on two
projects, A and B, then having something that quickly reminds you
which one you are in is beneficial and people often do so by having
the current directory name in the prompt.
The log message needs to explain why working on a submodule C of a
project A is any more special, i.e. why are the existing ways the
users are using to remind them between A and B cannot be used for C.
> diff --git a/contrib/completion/git-prompt.sh
> b/contrib/completion/git-prompt.sh
> index 97eacd7..4c82e7f 100644
> --- a/contrib/completion/git-prompt.sh
> +++ b/contrib/completion/git-prompt.sh
> @@ -93,6 +93,10 @@
> # directory is set up to be ignored by git, then set
> # GIT_PS1_HIDE_IF_PWD_IGNORED to a nonempty value. Override this on the
> # repository level by setting bash.hideIfPwdIgnored to "false".
> +#
> +# If you would like __git_ps1 to indicate that you are in a submodule,
> +# set GIT_PS1_SHOWSUBMODULE. In this case a "sub:" will be added before
> +# the branch name.
>
> # check whether printf supports -v
> __git_printf_supports_v=
> @@ -284,6 +288,32 @@ __git_eread ()
> test -r "$f" && read "$@" <"$f"
> }
>
> +# __git_is_submodule
> +# Based on:
> +#
> http://stackoverflow.com/questions/7359204/git-command-line-know-if-in-submodule
> +__git_is_submodule ()
It seems like this function is checking if you are "IN" submodule,
not "IS" submodule. A misnamed function?
> +{
> + local git_dir parent_git module_name path
> + # Find the root of this git repo, then check if its parent dir is also
> a repo
> + git_dir="$(git rev-parse --show-toplevel)"
> + module_name="$(basename "$git_dir")"
This does not give "module_name" in the sense the word is used in
the submodule subsystem. If this variable is useful, call that
with "path" in its name (I do not think it alone is useful at all).
> + parent_git="$(cd "$git_dir/.." && git rev-parse --show-toplevel 2>
> /dev/null)"
> + if [[ -n $parent_git ]]; then
> + # List all the submodule paths for the parent repo
> + while read path
> + do
> + if [[ "$path" != "$module_name" ]]; then continue; fi
> + if [[ -d "$git_dir/../$path" ]];then return 0; fi
> + done < <(cd $parent_git && git submodule --quiet foreach 'echo
> $path' 2> /dev/null)
Instead of doing this "loop over submodules and just get true or
false", it may make a lot more sense to find the module name and
report that. That would allow you to have the actual submodule
name, not a generic "sub:" which does not help the users to tell
which one of 47 submodules they have in their top-level project
they are currently in.
If your projects are layed out like so
/home/bf/projects/A/
/home/bf/projects/A/lib/B/ -- submodule
/home/bf/projects/A/Doc/ -- another submodule
/home/bf/projects/A/Doc/technical -- a subdirectory of Doc submodule
and you are in /home/bf/projects/A/Doc/technical/ subdirectory, your
$git_dir variable (which is grossly misnamed, too; call it "top"
perhaps?) would be "/home/bf/projects/A/Doc" and then your
$parent_git variable (again, that is misnamed; call it
"parent_top"?) would be "/home/bf/projects/A". The submodule path
to the submodule you are currently in is "Doc" (you learn it as the
difference between these two).
You can ask the top-level project the name of the submodule that is
currently at "Doc" with "submodule--helper name". Unless the project
has moved it since it first added the submodule, the module name may
also be "Doc", but if it were moved, it may be different.
And that "module name" is a more useful thing than a hardcoded
string "sub:" to use in the prompt, I would think.
[PATCH 1/4] git-prompt.sh: add submodule indicator
I expirienced that working with submodules can be confusing. This indicator
will make you notice very easy when you switch into a submodule.
The new prompt will look like this: (sub:master)
Adding a new optional env variable for the new feature.
Signed-off-by: Benjamin Fuchs
---
contrib/completion/git-prompt.sh | 37 -
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 97eacd7..4c82e7f 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -93,6 +93,10 @@
# directory is set up to be ignored by git, then set
# GIT_PS1_HIDE_IF_PWD_IGNORED to a nonempty value. Override this on the
# repository level by setting bash.hideIfPwdIgnored to "false".
+#
+# If you would like __git_ps1 to indicate that you are in a submodule,
+# set GIT_PS1_SHOWSUBMODULE. In this case a "sub:" will be added before
+# the branch name.
# check whether printf supports -v
__git_printf_supports_v=
@@ -284,6 +288,32 @@ __git_eread ()
test -r "$f" && read "$@" <"$f"
}
+# __git_is_submodule
+# Based on:
+#
http://stackoverflow.com/questions/7359204/git-command-line-know-if-in-submodule
+__git_is_submodule ()
+{
+ local git_dir parent_git module_name path
+ # Find the root of this git repo, then check if its parent dir is also
a repo
+ git_dir="$(git rev-parse --show-toplevel)"
+ module_name="$(basename "$git_dir")"
+ parent_git="$(cd "$git_dir/.." && git rev-parse --show-toplevel 2>
/dev/null)"
+ if [[ -n $parent_git ]]; then
+ # List all the submodule paths for the parent repo
+ while read path
+ do
+ if [[ "$path" != "$module_name" ]]; then continue; fi
+ if [[ -d "$git_dir/../$path" ]];then return 0; fi
+ done < <(cd $parent_git && git submodule --quiet foreach 'echo
$path' 2> /dev/null)
+fi
+return 1
+}
+
+__git_ps1_submodule ()
+{
+ __git_is_submodule && printf "sub:"
+}
+
# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
# when called from PS1 using command substitution
# in this mode it prints text to add to bash PS1 prompt (includes branch name)
@@ -513,8 +543,13 @@ __git_ps1 ()
b="\${__git_ps1_branch_name}"
fi
+ local sub=""
+ if [ -n "${GIT_PS1_SHOWSUBMODULE}" ]; then
+ sub="$(__git_ps1_submodule)"
+ fi
+
local f="$w$i$s$u"
- local gitstring="$c$b${f:+$z$f}$r$p"
+ local gitstring="$c$sub$b${f:+$z$f}$r$p"
if [ $pcmode = yes ]; then
if [ "${__git_printf_supports_v-}" != yes ]; then
--
2.7.4
