* Re: [PATCH v2 9/9] read_loose_refs(): read refs using resolve_ref_recursively()
From: Junio C Hamano @ 2017-02-13 23:18 UTC (permalink / raw)
To: Michael Haggerty
Cc: Nguyễn Thái Ngọc Duy, Stefan Beller,
Johannes Schindelin, David Turner, Jeff King, git
In-Reply-To: <ff0b0df6-9aed-9417-d9d4-1234d53f05c3@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> I pushed the fixed commit to branch `submodule-hash` in my fork [1]. If
> you'd like me to send it to the mailing list again, please let me know.
I was tempted to ask you to send it again, because fetching,
comparing and then cherry-picking is a lot more work than just
replacing one, but just to make sure my intuition about the
work required is correct, I did it anyway and yes, fetching,
comparing, cherry-picking and then amending the sign-off in was a
lot more work ;-)
So no need to resend. Thanks.
^ permalink raw reply
* Developing git with IDE
From: Oleg Taranenko @ 2017-02-13 23:15 UTC (permalink / raw)
To: git
Hi *,
being last decade working with java & javascript I completely lost
relation to c/c++ world. Trying to get into git internals I'm facing
with issue what IDE is more suitable for developing git @ macos ?
Have googled, but any my search queries following to non-relevant
themes, like supporting git in IDEs etc.
my first attempt - CLion (as far as I'm Jetbrains fan) - got failed,
as far as doesn't support makefile-based projects, only CMake.
There are a number of free C/C++ dev tools: Xcode, CodeBlocks,
CodeLite. Gnat, Qt creator, Dev C++, C++ Builder (Borland? :),
Eclipse, NetBeans... what else?
Because of lack my modern C experience, could somebody share his own
attempts/thoughts/use cases how more convenient dive into the git
development process on the Mac?
Tried to find in the git distribution Documentation more information
about this, nothing as well... Would be nice to have a kind of
'Getting Started Manual'
Thanks for your time,
Oleg Taranenko
^ permalink raw reply
* Re: [PATCH 08/11] refs.c: factor submodule code out of get_ref_store()
From: Stefan Beller @ 2017-02-13 23:13 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git@vger.kernel.org, Junio C Hamano, Michael Haggerty,
Johannes Schindelin, David Turner
In-Reply-To: <20170213152011.12050-9-pclouds@gmail.com>
On Mon, Feb 13, 2017 at 7:20 AM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
> This code is going to be expanded a bit soon. Keep it out for
> better readability later.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
Looks good,
Thanks,
Stefan
^ permalink raw reply
* new git-diff switch to eliminate leading "+" and "-" characters
From: Vanderhoof, Tzadik @ 2017-02-13 23:01 UTC (permalink / raw)
To: git@vger.kernel.org
The output of git-diff includes lines beginning with "+" and "-" to indicate added and deleted lines. A somewhat common task (at least for me) is to want to copy output from a "diff" (usually the deleted lines) and paste it back into my code.
This is quite inconvenient because of the leading "+" and "-" characters. I know there are shell and IDE / editor workarounds but it would be nice if there was a switch to git-diff to make it leave out those characters, especially since "--color" kind of makes those leading characters obsolete.
Would it make sense to develop such a switch or has there been work on that already?
______________________________
Tzadik Vanderhoof | Optum360
Sr Software Engineer, NLP Innovation
www.optum360.com
This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
^ permalink raw reply
* Re: [PATCH 07/11] files-backend: remove the use of git_path()
From: Stefan Beller @ 2017-02-13 23:09 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git@vger.kernel.org, Junio C Hamano, Michael Haggerty,
Johannes Schindelin, David Turner
In-Reply-To: <20170213152011.12050-8-pclouds@gmail.com>
> +
> + if (submodule) {
> + refs->submodule = xstrdup_or_null(submodule);
drop the _or_null here?
So in this patch we have either
* submodule set
* or gitdir/gitcommondir set
which means that we exercise the commondir for regular repos.
In the future when we want to be able to have a combination of worktrees
and submodules this ought to be possible by setting submodule != NULL
and still populating the gitdir/commondir buffers.
Thanks,
Stefan
^ permalink raw reply
* Re: [PATCH v3 4/5] stash: introduce new format create
From: Jeff King @ 2017-02-13 23:05 UTC (permalink / raw)
To: Thomas Gummerer
Cc: git, Stephan Beyer, Junio C Hamano, Marc Strapetz,
Johannes Schindelin, Øyvind A . Holm, Jakub Narębski
In-Reply-To: <20170213215734.puoung6hhdifbgai@sigill.intra.peff.net>
On Mon, Feb 13, 2017 at 04:57:34PM -0500, Jeff King wrote:
> Yeah, I think your patch is actually fixing that case. But your search
> is only part of the story. You found somebody using "-m" explicitly, but
> what about somebody blindly calling:
>
> git stash create $*
>
> That's now surprising to somebody who puts "-m" in their message.
>
> > I *think* this regression is acceptable, but I'm happy to introduce
> > another verb if people think otherwise.
>
> Despite what I wrote above, I'm still inclined to say that this isn't an
> important regression. I'd be surprised if "stash create" is used
> independently much at all.
Just thinking on this more...do we really care about "fixing" the
interface of "stash create"? This is really just about refactoring what
underlies the new "push", right?
So we could just do:
diff --git a/git-stash.sh b/git-stash.sh
index 6d629fc43..ee37db135 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -711,7 +711,7 @@ clear)
;;
create)
shift
- create_stash "$@" && echo "$w_commit"
+ create_stash -m "$*" && echo "$w_commit"
;;
store)
shift
on top of your patch and keep the external interface the same.
It might be nice to clean up the interface for "create" to match other
ones, but from this discussion I think it is mostly a historical wart
for scripting, and we are OK to just leave its slightly-broken interface
in place forever.
I could go either way.
-Peff
^ permalink raw reply related
* Re: [PATCH] mingw: make stderr unbuffered again
From: Junio C Hamano @ 2017-02-13 22:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Johannes Sixt, Jeff Hostetler
In-Reply-To: <c88612da0a62bfcbc3e278296f9d3eb010057071.1487025228.git.johannes.schindelin@gmx.de>
Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> When removing the hack for isatty(), we actually removed more than just
> an isatty() hack: we removed the hack where internal data structures of
> the MSVC runtime are modified in order to redirect stdout/stderr.
>
> Instead of using that hack (that does not work with newer versions of
> the runtime, anyway), we replaced it by reopening the respective file
> descriptors.
>
> What we forgot was to mark stderr as unbuffered again.
>
> Reported by Hannes Sixt. Fixed with Jeff Hostetler's assistance.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> Published-As: https://github.com/dscho/git/releases/tag/mingw-unbuffered-stderr-v1
> Fetch-It-Via: git fetch https://github.com/dscho/git mingw-unbuffered-stderr-v1
OK. Should this go directly to 'master', as the isatty thing is
already in?
>
> compat/winansi.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/compat/winansi.c b/compat/winansi.c
> index 82b89ab1376..793420f9d0d 100644
> --- a/compat/winansi.c
> +++ b/compat/winansi.c
> @@ -510,6 +510,8 @@ static HANDLE swap_osfhnd(int fd, HANDLE new_handle)
> */
> close(new_fd);
>
> + if (fd == 2)
> + setvbuf(stderr, NULL, _IONBF, BUFSIZ);
> fd_is_interactive[fd] |= FD_SWAPPED;
>
> return duplicate;
> @@ -547,6 +549,8 @@ static void detect_msys_tty(int fd)
> !wcsstr(name, L"-pty"))
> return;
>
> + if (fd == 2)
> + setvbuf(stderr, NULL, _IONBF, BUFSIZ);
> fd_is_interactive[fd] |= FD_MSYS;
> }
>
>
> base-commit: 5588dbffbd61e4906e453808c6ad32f792fea521
^ permalink raw reply
* Re: [PATCH] mingw: use OpenSSL's SHA-1 routines
From: Johannes Schindelin @ 2017-02-13 22:38 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Jeff King, git, Jeff Hostetler
In-Reply-To: <b530c820-9956-4396-d853-c7d70ccaf11d@kdbg.org>
Hi,
On Mon, 13 Feb 2017, Johannes Sixt wrote:
> Am 13.02.2017 um 20:42 schrieb Junio C Hamano:
> > I have been operating under the assumption that everybody on Windows
> > who builds Git works off of Dscho's Git for Windows tree, and patches
> > that are specific to Windows from Dscho's are sent to me via the list
> > only after they have been in Git for Windows and proven to help
> > Windows users in the wild.
> >
> > The consequence of these two assumptions is that I would feel safe to
> > treat Windows specific changes that do not touch generic part of the
> > codebase from Dscho just like updates from any other subsystem
> > maintainers (any git-svn thing from Eric, any gitk thing from Paul,
> > any p4 thing Luke and Lars are both happy with, etc.).
> >
> > You seem to be saying that the first of the two assumptions does not
> > hold. Should I change my expectations while queuing Windows specific
> > patches from Dscho?
>
> Your first assumption is incorrect as far as I am concerned. I build
> from your tree plus some topics. During -rc period, I build off of
> master; after a release, I build off of next. I merge some of the topics
> that you carry in pu when I find them interesting or when I suspect them
> to regress on Windows. Then I carry around a few additional patches
> that the public has never seen, and these days I also merge Dscho's
> rebase-i topic.
In addition, you build from a custom MINGW/MSys1 setup, correct?
Ciao,
Johannes
^ permalink raw reply
* Re: [RFC PATCH] show decorations at the end of the line
From: Jeff King @ 2017-02-13 22:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <xmqq7f4tdcua.fsf@gitster.mtv.corp.google.com>
On Mon, Feb 13, 2017 at 01:01:49PM -0800, Junio C Hamano wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > And if you actually want decorations, and you're parsing them, you are
> > *not* going to script it with "--oneline --decorations", because the
> > end result is basically impossible to parse already (because it's
> > ambiguous - think about parentheses in the commit message).
>
> OK. So let's wait to hear from others if they like the "obviously"
> improved output. Even though I find the decorations indispensable
> in my "git log" output, I personally do not have much preference
> either way, as my screen is often wide enough ;-)
I have a slight preference for the new output (decorations at the end)
versus the original, but I could go either way.
I don't think the scripting compatibility concerns are an issue, for all
the reasons given in the thread.
There is one related option, --source, which also puts its data between
the hash and the subject in --oneline. In theory that should be treated
similarly, though:
1. It's already really ugly, as it does not even get the parentheses
and coloring.
2. It's perhaps more likely to get scripted, as it really is parseable
in the current state.
I'm not sure if a better path forward would be to just extend the idea
of "decorator" to possibly include more than just ref-tips. On the other
hand, if you really want to get fancy with formatting, we already have a
complete formatting language. Perhaps it should learn a placeholder for
the "--source" data.
Similarly, I've often wanted a "contained in this tags/branches"
annotation for each commit. It's not too expensive to compute if you
topo-sort the set of commits and just paint down as you traverse.
Anyway, I think none of that needs to block changes to --decorate
output. Just thinking out loud.
-Peff
^ permalink raw reply
* Re: [PATCH 06/11] refs-internal.h: correct is_per_worktree_ref()
From: Stefan Beller @ 2017-02-13 22:37 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git@vger.kernel.org, Junio C Hamano, Michael Haggerty,
Johannes Schindelin, David Turner
In-Reply-To: <20170213152011.12050-7-pclouds@gmail.com>
On Mon, Feb 13, 2017 at 7:20 AM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
> All refs outside refs/ directory is per-worktree, not just HEAD.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> refs/refs-internal.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/refs/refs-internal.h b/refs/refs-internal.h
> index f4aed49f5..69d02b6ba 100644
> --- a/refs/refs-internal.h
> +++ b/refs/refs-internal.h
> @@ -653,7 +653,7 @@ const char *resolve_ref_recursively(struct ref_store *refs,
>
> static inline int is_per_worktree_ref(const char *refname)
> {
> - return !strcmp(refname, "HEAD") ||
> + return !starts_with(refname, "refs/") ||
> starts_with(refname, "refs/bisect/");
you're loosing HEAD here? (assuming we get HEAD in
short form here, as well as long form refs/HEAD)
> }
>
> --
> 2.11.0.157.gd943d85
>
^ permalink raw reply
* [PATCH] mingw: make stderr unbuffered again
From: Johannes Schindelin @ 2017-02-13 22:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Sixt, Jeff Hostetler
When removing the hack for isatty(), we actually removed more than just
an isatty() hack: we removed the hack where internal data structures of
the MSVC runtime are modified in order to redirect stdout/stderr.
Instead of using that hack (that does not work with newer versions of
the runtime, anyway), we replaced it by reopening the respective file
descriptors.
What we forgot was to mark stderr as unbuffered again.
Reported by Hannes Sixt. Fixed with Jeff Hostetler's assistance.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Published-As: https://github.com/dscho/git/releases/tag/mingw-unbuffered-stderr-v1
Fetch-It-Via: git fetch https://github.com/dscho/git mingw-unbuffered-stderr-v1
compat/winansi.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/compat/winansi.c b/compat/winansi.c
index 82b89ab1376..793420f9d0d 100644
--- a/compat/winansi.c
+++ b/compat/winansi.c
@@ -510,6 +510,8 @@ static HANDLE swap_osfhnd(int fd, HANDLE new_handle)
*/
close(new_fd);
+ if (fd == 2)
+ setvbuf(stderr, NULL, _IONBF, BUFSIZ);
fd_is_interactive[fd] |= FD_SWAPPED;
return duplicate;
@@ -547,6 +549,8 @@ static void detect_msys_tty(int fd)
!wcsstr(name, L"-pty"))
return;
+ if (fd == 2)
+ setvbuf(stderr, NULL, _IONBF, BUFSIZ);
fd_is_interactive[fd] |= FD_MSYS;
}
base-commit: 5588dbffbd61e4906e453808c6ad32f792fea521
--
2.11.1.windows.1
^ permalink raw reply related
* Re: [PATCH v3 0/5] stash: support pathspec argument
From: Thomas Gummerer @ 2017-02-13 22:33 UTC (permalink / raw)
To: Jeff King
Cc: Matthieu Moy, git, Stephan Beyer, Junio C Hamano, Marc Strapetz,
Johannes Schindelin, Øyvind A . Holm, Jakub Narębski
In-Reply-To: <20170213214521.pkjesijdlus36tnp@sigill.intra.peff.net>
On 02/13, Jeff King wrote:
> On Mon, Feb 13, 2017 at 10:35:31PM +0100, Matthieu Moy wrote:
>
> > > Is it really that dangerous, though? The likely outcome is Git saying
> > > "nope, you don't have any changes to the file named drop". Of course the
> > > user may have meant something different, but I feel like "-p" is a good
> > > indicator that they are interested in making an actual stash.
> >
> > Indeed -p is not the best example. In the old thread, I used -q which is
> > much more problematic:
> >
> > git stash -q drop => interpreted as: git stash push -q drop
> > git stash drop -q => drop with option -q
>
> Yeah, I'd agree with that. I wouldn't propose to loosen it entirely, but
> rather to treat "-p" specially.
>
> > It's not really "dangerous" at least in this case, since we misinterpret
> > a destructive command for a less destructive one, but it is rather
> > confusing that changing the order between command and options change the
> > behavior.
> >
> > I actually find it a reasonable expectation to allow swapping commands
> > and options, some programs other than git allow it.
>
> I think we may have already crossed that bridge with "git -p stash".
>
> Not to mention that the ordering already _is_ relevant (we disallow one
> order but not the other). If we really wanted to allow swapping, it
> would mean making:
>
> git stash -p drop
>
> the same as:
>
> git stash drop -p
>
> I actually find _that_ more confusing. It would perhaps make more sense
> with something like "-q", which is more of a "global" option than a
> command-specific one. But I think we'd want to whitelist such global
> options (and "-p" would not be on that list).
>
> > > The complexity is that right now, the first-level decision of "which
> > > stash sub-command am I running?" doesn't know about any options. So "git
> > > stash -m foo" would be rejected in the name of typo prevention, unless
> > > that outer decision learns about "-m" as an option.
> >
> > Ah, OK. But that's not really hard to implement: when going through the
> > option list looking for non-option, shift one more time when finding -m.
>
> No, it's not hard conceptually. It just means implementing the
> option-parsing policy in two places. That's not too bad now, but if we
> started using rev-parse's options helper, then I think you have corner
> cases like "git stash -km foo".
>
> My "-p" suggestion suffers from a similar problem if you treat it as
> "you can omit the 'push' if you say "-p", rather than "if -p is the
> first option, it is a synonym for 'push -p'".
I'm almost convinced of special casing "-p". (Maybe I'm easy to
convince as well, because it would be convenient ;) ) However it's a
bit weird that now "git stash -p file" would work, but "git stash -m
message" wouldn't. Maybe we should do it the other way around, and
only special case "-q", and see if there is an non option argument
after that? From a glance at the options that's the only one where
"git stash -<option> <verb>" could make sense to the user.
^ permalink raw reply
* Re: [PATCH] clean: use warning_errno() when appropriate
From: Jeff King @ 2017-02-13 22:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <xmqqy3x9bvvm.fsf@gitster.mtv.corp.google.com>
On Mon, Feb 13, 2017 at 01:53:33PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > IOW, I think this may be a case where we should be optimizing for
> > programmer time (fewer lines of code, and one less thing to worry about
> > in the callers) versus squeezing out every instruction.
>
> Fair enough.
>
> Unless we do the save_errno dance in all the helper functions we
> commonly use to safely stash away errno as necessary and tell
> developers that they can depend on it, the code in the patch that
> began this discussion still needs its own saved_errno dance to be
> safe, though. I do not have a feeling that we are not there yet,
> even after we teach xmalloc() and its family to do so.
Yeah, I certainly agree that is a potential blocker. Even if it is true
today, there's nothing guaranteeing that the quote functions don't grow
a new internal detail that violates.
So in that sense doing the errno dance as close to the caller who cares
is the most _obvious_ thing, even if it isn't the shortest.
It would be nice if there was a way to annotate a function as
errno-safe, and then transitively compute which other functions were
errno-safe when they do not call any errno-unsafe function. I don't know
if any static analyzers allow that kind of custom annotation, though
(and also I wonder whether the cost/benefit of maintaining those
annotations would be worth it).
-Peff
^ permalink raw reply
* Re: [PATCH v3 2/5] stash: introduce push verb
From: Thomas Gummerer @ 2017-02-13 22:16 UTC (permalink / raw)
To: Matthieu Moy
Cc: git, Stephan Beyer, Junio C Hamano, Marc Strapetz, Jeff King,
Johannes Schindelin, Øyvind A . Holm, Jakub Narębski
In-Reply-To: <vpqlgtaz09q.fsf@anie.imag.fr>
On 02/13, Matthieu Moy wrote:
> Thomas Gummerer <t.gummerer@gmail.com> writes:
>
> > Introduce a new git stash push verb in addition to git stash save. The
> > push verb is used to transition from the current command line arguments
> > to a more conventional way, in which the message is given as an argument
> > to the -m option.
>
> Sorry if this has been discussed before, but I find 'push' rather
> confusing here. It took me a while to understand that it meant "opposite
> of pop", because in the context of Git, "push" usually means "send to
> remote repository".
There wasn't much of a discussion about it, but it was pretty much the
only thing that came to my mind, and nobody complained or suggested
anything different, so I just went with it. No other verb came to my
mind yet, but if someone has a better suggestion, I'd be happy to
change.
> Unfortunately, I didn't come up with a better name. "create" is already
> taken ...
>
> Another think to have in mind: changing the option name to break
> backward compatibility is something we can't do often, so if there's
> anything else we should change about the UI, we should do it now. I
> don't have anything particular in mind, just thinking aloud.
Now that you mention this, there actually is one inconsistency that I
introduced, which I shouldn't have. git stash push works with
--include-untracked and --all to decide whether or not to include
untracked files, and if also ignored files should be included. I also
added a --include-untracked {untracked,all} argument to git stash
create, which is clearly inconsistent.
There really should only be one way. I'd be fine with either way, but
I think using --include-untracked and --all is the better choice,
because it's easy to understand, and also makes it easier to switch
git stash without a verb over to use push_stash internally.
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] docs/git-submodule: fix unbalanced quote
From: Junio C Hamano @ 2017-02-13 22:06 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20170213210549.jns7asrvjp3lb5wc@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> However, let's take a step back. Even when rendered
> correctly, it's hard to read a long command stuck into the
> middle of a paragraph, and the important punctuation is hard
> to notice.
Yes, I like this reasoning behind the solution very much.
Thanks.
> Documentation/git-submodule.txt | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index 918bd1d1b..a8eb1c7ce 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -228,9 +228,12 @@ foreach::
> the processing to terminate. This can be overridden by adding '|| :'
> to the end of the command.
> +
> -As an example, +git submodule foreach \'echo $path {backtick}git
> -rev-parse HEAD{backtick}'+ will show the path and currently checked out
> -commit for each submodule.
> +As an example, the command below will show the path and currently
> +checked out commit for each submodule:
> ++
> +--------------
> +git submodule foreach 'echo $path `git rev-parse HEAD`'
> +--------------
>
> sync::
> Synchronizes submodules' remote URL configuration setting
^ permalink raw reply
* Re: [PATCH v3 4/5] stash: introduce new format create
From: Jeff King @ 2017-02-13 21:57 UTC (permalink / raw)
To: Thomas Gummerer
Cc: git, Stephan Beyer, Junio C Hamano, Marc Strapetz,
Johannes Schindelin, Øyvind A . Holm, Jakub Narębski
In-Reply-To: <20170211145127.GA23081@hank>
On Sat, Feb 11, 2017 at 02:51:27PM +0000, Thomas Gummerer wrote:
> > How do we tell the difference between new-style invocations, and
> > old-style ones that look new-style? IOW, I think:
> >
> > git stash create -m works
> >
> > currently treats "-m works" as the full message, and it would now become
> > just "works".
> >
> > That may be an acceptable loss for the benefit we are getting. The
> > alternative is to make yet another verb for create, as we did with
> > save/push). I have a feeling that hardly anybody uses "create", though,
> > and it's mostly an implementation detail. So given the obscure nature,
> > maybe it's an acceptable level of regression. I dunno.
>
> Right. So I did a quick search on google and github for this, and
> there seems one place where git stash create -m is used [1]. From a
> quick look it does however not seem like the -m in the stash message
> is of any significance there, but rather that the intention was to use
> a flag that doesn't exist.
Yeah, I think your patch is actually fixing that case. But your search
is only part of the story. You found somebody using "-m" explicitly, but
what about somebody blindly calling:
git stash create $*
That's now surprising to somebody who puts "-m" in their message.
> I *think* this regression is acceptable, but I'm happy to introduce
> another verb if people think otherwise.
Despite what I wrote above, I'm still inclined to say that this isn't an
important regression. I'd be surprised if "stash create" is used
independently much at all.
-Peff
^ permalink raw reply
* Re: [PATCH] clean: use warning_errno() when appropriate
From: Junio C Hamano @ 2017-02-13 21:53 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20170213211051.vsnnrtcsvuvfcwyk@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> IOW, I think this may be a case where we should be optimizing for
> programmer time (fewer lines of code, and one less thing to worry about
> in the callers) versus squeezing out every instruction.
Fair enough.
Unless we do the save_errno dance in all the helper functions we
commonly use to safely stash away errno as necessary and tell
developers that they can depend on it, the code in the patch that
began this discussion still needs its own saved_errno dance to be
safe, though. I do not have a feeling that we are not there yet,
even after we teach xmalloc() and its family to do so.
^ permalink raw reply
* Re: Incorrect pipe for git log graph when using --name-status option
From: Jeff King @ 2017-02-13 21:51 UTC (permalink / raw)
To: hIpPy; +Cc: Junio C Hamano, git
In-Reply-To: <CAM_JFCzniePuqJTFOy-odLfuKcBjssh0zk3PFBsVcm6Ww6iW5w@mail.gmail.com>
On Mon, Feb 13, 2017 at 01:43:45PM -0800, hIpPy wrote:
> With --name-status: I'm sorry if I nitpick here but I think the
> --name-status items should either be preceeded and followed by
> blank line OR not (as in oneline) but not just preceded (example
> below).
Yeah, I agree the output is a bit ugly.
I don't think there is a way to do what you want currently. The
--oneline code path has some internal magic that suppresses some of the
newlines.
I think it is a good goal that anything that can be expressed via one of
the regular formats (like --oneline) can be expressed via custom
formats. I don't know offhand how hard it would be to make this
particular case work. If somebody is interested in tackling this, they'd
probably need to dig around in pretty.c to see where the ONELINE code
path diverge from the USER_FORMAT one, and then figure out how a user
can specify that they want the ONELINE-ish semantics for their format.
-Peff
^ permalink raw reply
* Re: [PATCH v3 0/5] stash: support pathspec argument
From: Jeff King @ 2017-02-13 21:45 UTC (permalink / raw)
To: Matthieu Moy
Cc: Thomas Gummerer, git, Stephan Beyer, Junio C Hamano,
Marc Strapetz, Johannes Schindelin, Øyvind A . Holm,
Jakub Narębski
In-Reply-To: <vpqo9y5lqos.fsf@anie.imag.fr>
On Mon, Feb 13, 2017 at 10:35:31PM +0100, Matthieu Moy wrote:
> > Is it really that dangerous, though? The likely outcome is Git saying
> > "nope, you don't have any changes to the file named drop". Of course the
> > user may have meant something different, but I feel like "-p" is a good
> > indicator that they are interested in making an actual stash.
>
> Indeed -p is not the best example. In the old thread, I used -q which is
> much more problematic:
>
> git stash -q drop => interpreted as: git stash push -q drop
> git stash drop -q => drop with option -q
Yeah, I'd agree with that. I wouldn't propose to loosen it entirely, but
rather to treat "-p" specially.
> It's not really "dangerous" at least in this case, since we misinterpret
> a destructive command for a less destructive one, but it is rather
> confusing that changing the order between command and options change the
> behavior.
>
> I actually find it a reasonable expectation to allow swapping commands
> and options, some programs other than git allow it.
I think we may have already crossed that bridge with "git -p stash".
Not to mention that the ordering already _is_ relevant (we disallow one
order but not the other). If we really wanted to allow swapping, it
would mean making:
git stash -p drop
the same as:
git stash drop -p
I actually find _that_ more confusing. It would perhaps make more sense
with something like "-q", which is more of a "global" option than a
command-specific one. But I think we'd want to whitelist such global
options (and "-p" would not be on that list).
> > The complexity is that right now, the first-level decision of "which
> > stash sub-command am I running?" doesn't know about any options. So "git
> > stash -m foo" would be rejected in the name of typo prevention, unless
> > that outer decision learns about "-m" as an option.
>
> Ah, OK. But that's not really hard to implement: when going through the
> option list looking for non-option, shift one more time when finding -m.
No, it's not hard conceptually. It just means implementing the
option-parsing policy in two places. That's not too bad now, but if we
started using rev-parse's options helper, then I think you have corner
cases like "git stash -km foo".
My "-p" suggestion suffers from a similar problem if you treat it as
"you can omit the 'push' if you say "-p", rather than "if -p is the
first option, it is a synonym for 'push -p'".
-Peff
^ permalink raw reply
* Re: Incorrect pipe for git log graph when using --name-status option
From: hIpPy @ 2017-02-13 21:43 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20170213212734.howisucqqhusbglc@sigill.intra.peff.net>
On Mon, Feb 13, 2017 at 1:27 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Feb 13, 2017 at 01:18:40PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > I think the problem is specifically related to the "terminator" versus
>> > "separator" semantics. Try:
>> >
>> > git log --graph --name-status --pretty=format:%h
>> >
>> > versus:
>> >
>> > git log --graph --name-status --pretty=tformat:%h
>> >
>> > The latter works fine. The problem seems to happen with all diff
>> > formats, so I think the issue is that git is not aggressive enough about
>> > inserting the newline at the right spot when using separator mode.
>>
>> I guess that is one of the reasons why we made --format=%h a synonym
>> to --pretty=tformat:%h and not --pretty=format:%h ;-)
>
> Yeah. I have never found "--pretty=format" to do what I want versus
> tformat. I wish we could just get rid of it, but I think it is likely to
> be used as a plumbing interface.
>
> So I think there probably _is_ a bug in it to be fixed, but my immediate
> response is "don't ever use --pretty=format:".
>
> -Peff
I have 1 issue with tformat in that I feel it reduces
readability a bit when using options. But I can use it if that
is recommended over the other.
Without --name-status: This is OK.
$ git log --graph --date=relative --decorate --abbrev-commit
--format='%h - %aD (%ar)%d%n %s - %an' -2
* bf7ace7daf - Mon, 6 Feb 2017 13:09:32 -0800 (7 days ago) (HEAD ->
rm/option-for-name-status)
| wip: --ns for --name-status - Rishikesh Mandvikar
* 592e5c5bce - Wed, 1 Feb 2017 16:35:30 +0100 (12 days ago)
(origin/master, origin/HEAD, master)
|\ Merge pull request #994 from
jeffhostetler/jeffhostetler/fscache_nfd - Johannes Schindelin
With --name-status: I'm sorry if I nitpick here but I think the
--name-status items should either be preceeded and followed by
blank line OR not (as in oneline) but not just preceded (example
below).
$ git log --graph --date=relative --decorate --abbrev-commit
--format='%h - %aD (%ar)%d%n %s - %an' -2 --name-status
* bf7ace7daf - Mon, 6 Feb 2017 13:09:32 -0800 (7 days ago) (HEAD ->
rm/option-for-name-status)
| wip: --ns for --name-status - Rishikesh Mandvikar
|
| M diff.c
* 592e5c5bce - Wed, 1 Feb 2017 16:35:30 +0100 (12 days ago)
(origin/master, origin/HEAD, master)
|\ Merge pull request #994 from
jeffhostetler/jeffhostetler/fscache_nfd - Johannes Schindelin
So either of below is better that above (I feel):
Blank lines before and after --name-status items:
$ git log --graph --date=relative --decorate --abbrev-commit
--format='%h - %aD (%ar)%d%n %s - %an' -2 --name-status
* bf7ace7daf - Mon, 6 Feb 2017 13:09:32 -0800 (7 days ago) (HEAD ->
rm/option-for-name-status)
| wip: --ns for --name-status - Rishikesh Mandvikar
|
| M diff.c
|
* 592e5c5bce - Wed, 1 Feb 2017 16:35:30 +0100 (12 days ago)
(origin/master, origin/HEAD, master)
|\ Merge pull request #994 from
jeffhostetler/jeffhostetler/fscache_nfd - Johannes Schindelin
No blank lines before and after --name-status items:
$ git log --graph --date=relative --decorate --abbrev-commit
--format='%h - %aD (%ar)%d%n %s - %an' -2 --name-status
* bf7ace7daf - Mon, 6 Feb 2017 13:09:32 -0800 (7 days ago) (HEAD ->
rm/option-for-name-status)
| wip: --ns for --name-status - Rishikesh Mandvikar
| M diff.c
* 592e5c5bce - Wed, 1 Feb 2017 16:35:30 +0100 (12 days ago)
(origin/master, origin/HEAD, master)
|\ Merge pull request #994 from
jeffhostetler/jeffhostetler/fscache_nfd - Johannes Schindelin
What do guys think?
If there is a way to get what I want using tformat?
Thanks,
RM
^ permalink raw reply
* Re: [RFH] Request for Git Merge 2017 impressions for Git Rev News
From: Christian Couder @ 2017-02-13 21:27 UTC (permalink / raw)
To: Jakub Narębski; +Cc: git
In-Reply-To: <8b6e998d-2bea-924b-42e3-936dcd9a2995@gmail.com>
Hi,
On Sat, Feb 11, 2017 at 5:33 PM, Jakub Narębski <jnareb@gmail.com> wrote:
> Hello,
>
> Git Rev News #24 is planned to be released on February 15. It is meant
> to cover what happened during the month of January 2017 (and earely
> February 2017) and the Git Merge 2017 conference that happened on
> February 2nd and 3rd 2017.
Yeah, I would have liked to release Git Rev News #24 on February 15
but I was busy and tired this week end, so let it be on Wednesday
February 22.
> A draft of a new Git Rev News edition is available here:
>
> https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-24.md
>
> I would like to ask everyone who attended the conference (and the
> GitMerge 2017 Contributors’s Summit day before it), or watched it live
> at http://git-merge.com/watch to write his or her impressions.
>
> You can contribute either by replying to this email, or by editing the
> above page on GitHub and sending a pull request, or by commenting on
> the following GitHub issue about Git Rev News 24:
>
> https://github.com/git/git.github.io/issues/221
>
> If you prefer to post on your own blog (or if you have did it
> already), please send an URL.
Yeah, any material (link, short impression, article, ...) would be very nice.
Thanks Jakub for the links you already added to the draft, by the way!
> P.S. I wonder if there should be not a separate section on
> https://git.github.io/ about recollection from various Git-related
> events, with Git Merge 2017 as the first one. This way we can wait
> for later response, and incorporate videos and slides from events, as
> they begin to be available.
Jakub, if you are willing to create and maintain this section, that
would be great!
> P.P.S. Please distribute this information more widely.
Thanks,
Christian.
^ permalink raw reply
* Re: Incorrect pipe for git log graph when using --name-status option
From: Jeff King @ 2017-02-13 21:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: hIpPy, git
In-Reply-To: <xmqq37fhdc27.fsf@gitster.mtv.corp.google.com>
On Mon, Feb 13, 2017 at 01:18:40PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I think the problem is specifically related to the "terminator" versus
> > "separator" semantics. Try:
> >
> > git log --graph --name-status --pretty=format:%h
> >
> > versus:
> >
> > git log --graph --name-status --pretty=tformat:%h
> >
> > The latter works fine. The problem seems to happen with all diff
> > formats, so I think the issue is that git is not aggressive enough about
> > inserting the newline at the right spot when using separator mode.
>
> I guess that is one of the reasons why we made --format=%h a synonym
> to --pretty=tformat:%h and not --pretty=format:%h ;-)
Yeah. I have never found "--pretty=format" to do what I want versus
tformat. I wish we could just get rid of it, but I think it is likely to
be used as a plumbing interface.
So I think there probably _is_ a bug in it to be fixed, but my immediate
response is "don't ever use --pretty=format:".
-Peff
^ permalink raw reply
* Re: Incorrect pipe for git log graph when using --name-status option
From: Junio C Hamano @ 2017-02-13 21:18 UTC (permalink / raw)
To: Jeff King; +Cc: hIpPy, git
In-Reply-To: <20170213211653.x3huwmzprvmm3yxj@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I think the problem is specifically related to the "terminator" versus
> "separator" semantics. Try:
>
> git log --graph --name-status --pretty=format:%h
>
> versus:
>
> git log --graph --name-status --pretty=tformat:%h
>
> The latter works fine. The problem seems to happen with all diff
> formats, so I think the issue is that git is not aggressive enough about
> inserting the newline at the right spot when using separator mode.
I guess that is one of the reasons why we made --format=%h a synonym
to --pretty=tformat:%h and not --pretty=format:%h ;-)
^ permalink raw reply
* Re: Incorrect pipe for git log graph when using --name-status option
From: Jeff King @ 2017-02-13 21:16 UTC (permalink / raw)
To: hIpPy; +Cc: Junio C Hamano, git
In-Reply-To: <CAM_JFCwN+o54mJ1XJ3rSKnXgPx3wt_i=fd8ZSGpcL-fSegQ=Ow@mail.gmail.com>
On Mon, Feb 13, 2017 at 12:55:07PM -0800, hIpPy wrote:
> I think that requiring to end custom formats with %n with options
> is not good. So I think this is a bug.
Yes, you don't normally need to do that.
I think the problem is specifically related to the "terminator" versus
"separator" semantics. Try:
git log --graph --name-status --pretty=format:%h
versus:
git log --graph --name-status --pretty=tformat:%h
The latter works fine. The problem seems to happen with all diff
formats, so I think the issue is that git is not aggressive enough about
inserting the newline at the right spot when using separator mode.
-Peff
^ permalink raw reply
* Re: [PATCH] clean: use warning_errno() when appropriate
From: Jeff King @ 2017-02-13 21:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <xmqqk28tddwo.fsf@gitster.mtv.corp.google.com>
On Mon, Feb 13, 2017 at 12:38:47PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I wonder if xmalloc() should be the one doing the saved_errno trick.
> > After all, it has only two outcomes: we successfully allocated the
> > memory, or we called die().
>
> I would be lying if I said I did not considered it when I wrote the
> message you are responding to, but I rejected it because that would
> be optimizing for a wrong case, in that most callers of xmalloc()
> and friends do not do so in the error codepath, and we would be
> penalizing them by doing the saved_errno dance unconditionally.
Yes, that also occurred to me. I'm not sure if two integer swaps is
enough to care about when compared to the cost of a malloc(), though.
IOW, I think this may be a case where we should be optimizing for
programmer time (fewer lines of code, and one less thing to worry about
in the callers) versus squeezing out every instruction.
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox