At 15:33 -0700 08 Aug 2018, Brandon Williams wrote:
Teach "submodule_name_to_gitdir()" to munge a submodule's name (by url
encoding it) before using it to build a path to the submodule's gitdir.
Seems like this will be a problem if it results in names that exceed
NAME_MAX? On common systems t
At 10:15 -0700 12 Jul 2018, Junio C Hamano wrote:
>Aaron Schrab writes:
>> Note that the comment_line_char has already been resolved by this point,
>> even if the user has configured the comment character to be selected
>> automatically.
>
>Isn't this a slig
his configuration causes a
failure to parse the resulting todo list.
Note that the comment_line_char has already been resolved by this point,
even if the user has configured the comment character to be selected
automatically.
Signed-off-by: Aaron Schrab
---
sequencer.c | 2 +-
1 file changed
Use configured comment character when generating comments about branches
in an instruction sheet. Failure to honor this configuration causes a
failure to parse the resulting instruction sheet.
Signed-off-by: Aaron Schrab
---
sequencer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
At 12:11 -0700 27 Jun 2018, Junio C Hamano wrote:
Hmph. Do other people have difficulty applying this patch to their
trees? It is just several lines long so I could retype it myself,
but I guess "Content-Type: text/plain; charset=utf-8; format=flowed"
has destroyed formatting of the patch rath
At 17:24 +0200 08 May 2018, Duy Nguyen wrote:
It took me so long to reply partly because I remember seeing some guy
doing clever trick with tab completion that also shows a short help
text in addition to the complete words. I could not find that again
and from my reading (also internet searching
At 20:14 + 15 Dec 2016, Larry Minton wrote:
Let's say I have a code change that I want to 'bake' for a while
locally, just to make sure some edge case doesn't pop up while I am
working on other things. Is there any practical way of doing that?
I could constantly merge that 'bake me' branch
At 12:17 +0100 05 Feb 2016, Jan Hudec wrote:
I have a repository with following situation:
$ git describe next
v4.1-2196-g5a414d7
$ git describe next --match=v4.2
v4.2-4757-g5a414d7
Since the tag with fewest commits since is selected, it appears logical.
However, v4.2 is descendant
I was working with a fresh clone of a repository where I'd forgotten
that one of the directories was setup as a submodule, so I hadn't
initialized it.
I tried to add a symlink to a location outside the repository and this
failed with an assertion (exact text in comment below). When looking
in
At 16:36 -0400 03 Oct 2016, Jeff King wrote:
On a case-insensitive filesystem, we should realize that
"a/objects" and "A/objects" are the same path.
The current repository being on a case-insensitive filesystem doesn't
guarantee that the alternates are as well.
On the other hand, I suspect
At 14:55 +0200 24 May 2016, Matthieu Moy wrote:
So, when trying a forbidden push, Git would deny it and the only way to
force the push would be to remove the blacklist from the config, right?
Probably the sanest way to go. I thought about adding a "git push
--force-even-if-in-blacklist" or so,
At 14:49 +0200 24 May 2016, Matthieu Moy wrote:
Samuel GROOT writes:
What kind of help text would you want to see?
Maybe something like this:
GIT: Quoted message body below.
GIT: Feel free to trim down the quoted text
GIT: to only relevant portions.
As "GIT:" portions are ignored whe
At 10:38 +0200 29 May 2015, Christian Neukirchen wrote:
Junio C Hamano writes:
* You can help yourself with something like this, I suppose:
[alias]
git = "!sh -c 'exec git \"$@\"' -"
but I personally feel that it is too ugly to live as part of our
official suggestion, so p
Is there a way to do a merge but only record conflicts in the index, not
update the working versions of files with conflict markers?
Like many people, I use git to manage configuration files for my shell,
editor, git itself, and a number of other things. The vast majority of
times that I upda
At 10:11 -0800 16 Nov 2014, Junio C Hamano wrote:
It does not have any significance that a random shell implementation
is not POSIX compliant. That would merely mean that such a shell
cannot be used to run POSIX shell scripts like our Porcelain.
Right, and I suspect that it's very rare for zs
Mattias, the convention on this list is to send directly to participants
in the thread as well as the list. So I've added Andreas as a
recipient.
At 05:52 +0200 17 Aug 2013, Mattias Andrée wrote:
- For example CET (which is 2 hours ahead UTC) is `+0200`.
+ For example CEST (which
At 11:59 +0200 10 Aug 2013, Michael Haggerty wrote:
I intentionally don't set user.email in my ~/.gitconfig because I use
different identities (on the same machine) depending on what project I
am committing to (open-source vs. work). After I clone a repo, I *rely*
on Git reminding me to set use
At 06:07 -0700 12 Jul 2013, "Kyle J. McKay" wrote:
I don't think it's necessary to split the URL apart though. Whatever
URL the user gave to git on the command line (at some point even if
it's now stored as a remote setting in config) complete with URL-
encoding, user names, port names, etc. i
At 12:53 -0700 09 Jul 2013, Junio C Hamano wrote:
+This is meant to make `--force` safer to use. Imagine that you have
+to rebase what you have already published. You will have to
+`--force` the push to replace the history you originally published
+with the rebased history. If somebody else b
At 13:05 +0100 11 Apr 2013, Adam Spiers wrote:
The above use case suggests that empty STDIN is actually a reasonable
scenario (e.g. when the caller doesn't know in advance whether any
queries need to be fed to the background process until after it's
already started), so we make the minor behavio
Try reading gitfile files when processing --reference options to clone.
This will allow, among other things, using a submodule checked out with
a recent version of git as a reference repository without requiring the
user to have internal knowledge of submodule layout.
Signed-off-by: Aaron Schrab
tate
the actual paths which were checked, but I believe that giving a good
description of that would be too verbose for a simple error message and
would be too dependent on implementation details.
Signed-off-by: Aaron Schrab
Reviewed-by: Jonathan Nieder
diff --git a/builtin/clone.c b/builti
Here's the third version of my series for dealing with gitfiles in clone
--reference.
The first patch is unchanged from the previous version except for the
addition of a Reviewed-by line.
The second patch has been modified so that it now supports having a .git
file supplied as the argument to the
At 09:47 -0700 09 Apr 2013, Junio C Hamano wrote:
Aaron Schrab writes:
But if others disagree, I could be convinced to add support for that.
If M/.git weren't a gitfile that points elsewhere, that request
ought to work, no? A gitfile is the moral equilvalent of a symbolic
link, mea
At 17:24 -0700 08 Apr 2013, Jonathan Nieder wrote:
+test_expect_success 'clone using repo with gitfile as a reference' '
+ git clone --separate-git-dir=L A M &&
+ git clone --reference=M A N &&
What should happen if I pass --reference=M/.git?
That isn't supported and I wouldn't e
Try reading gitfile files when processing --reference options to clone.
This will allow, among other things, using a submodule checked out with
a recent version of git as a reference repository without requiring the
user to have internal knowledge of submodule layout.
Signed-off-by: Aaron Schrab
tate
the actual paths which were checked, but I believe that giving a good
description of that would be too verbose for a simple error message and
would be too dependent on implementation details.
Signed-off-by: Aaron Schrab
---
builtin/clone.c |2 +-
1 file changed, 1 insertion(+), 1 deletion
Here's the promised second version of this series.
The diff in the first patch is unchanged, but I have made significant
changes to the commit message to hopefully to a better job of describing
why I think the old error message is bad.
For the second patch I've eliminated the need to do a cast.
At 11:00 -0700 08 Apr 2013, Junio C Hamano wrote:
Aaron Schrab writes:
Good catch. I'll fix that in the next version.
Thanks. The patch otherwise looks good to me.
Great, I'll plan to send version 2 of this series later today.
--
To unsubscribe from this list: send the line &q
At 10:57 -0700 08 Apr 2013, Junio C Hamano wrote:
In general I am in favor of resolving a gitfile given to --reference
when clone interprets it, and have it use the location of the real
underlying object store when it grabs objects not in there from the
origin and store the location of the real
At 08:30 -0700 08 Apr 2013, Junio C Hamano wrote:
You switch to a version of the superproject with a plain file at
dirA/ or there is nothing at dirA. The checkout will fail and you
need to manually rectify the situation [*1*], but after that is
done, you do not have any repository at /path/to/s
At 06:58 -0700 08 Apr 2013, Junio C Hamano wrote:
I do agree that it would be nice to dereference .git gitfile when we
deal with --reference argument, but you do not want to use in-tree
repository of a submodule working tree. What happens when you have
to check out a version of the containing s
At 20:06 -0400 07 Apr 2013, I wrote:
At 16:48 -0700 07 Apr 2013, Jonathan Nieder wrote:
Would it make sense for the message to say something like the
following?
fatal: alternate object store '/path/to/repo.git/objects' is not a
local directory
That would also avoid lying to the user
At 16:51 -0700 07 Apr 2013, Jonathan Nieder wrote:
- char *ref_git;
+ char *ref_git, *repo;
[...]
+ repo = (char *)read_gitfile(mkpath("%s/.git", ref_git));
Why not make repo a "const char *" and avoid the cast? The above
would seem to make it too tempting to treat the ret
At 16:48 -0700 07 Apr 2013, Jonathan Nieder wrote:
Hi Aaron,
Thanks for the feedback.
Aaron Schrab wrote:
Do not report an argument to clone's --reference option is not a local
directory. Nothing checks for the actual directory so we have no way to
know if whether or not exists. Te
e wrong
path to finding the problem.
Signed-off-by: Aaron Schrab
---
builtin/clone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index f9c380e..0a1e0bf 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -241,7 +241,7 @@ static int ad
Try reading gitfile files when processing --reference options to clone.
This will allow, among other things, using a submodule checked out with
a recent version of git as a reference repository without requiring the
user to have internal knowledge of submodule layout.
Signed-off-by: Aaron Schrab
: Aaron Schrab
---
templates/hooks--pre-push.sample | 53
1 file changed, 53 insertions(+)
create mode 100644 templates/hooks--pre-push.sample
diff --git a/templates/hooks--pre-push.sample b/templates/hooks--pre-push.sample
new file mode 100644
index 000
, and even the source branches in some cases.
Signed-off-by: Aaron Schrab
---
Documentation/githooks.txt | 29 ++
builtin/push.c | 1 +
t/t5571-pre-push-hook.sh | 129 +
transport.c
for a longer time are expected to
duplicate the return value themselves.
Signed-off-by: Aaron Schrab
---
builtin/commit.c | 6 ++
builtin/receive-pack.c | 25 +++--
run-command.c | 15 +--
run-command.h | 1 +
4 files changed, 27
Main changes since the initial version:
* The first patch converts the existing hook callers to use the new
find_hook() function.
* Information about what is to be pushed is now sent over a pipe rather
than passed as command-line parameters.
Aaron Schrab (3):
hooks: Add function to
At 18:08 -0800 28 Dec 2012, Junio C Hamano wrote:
Aaron Schrab writes:
Create find_hook() function to determine if a given hook exists and is
executable. If it is the path to the script will be returned, otherwise
NULL is returned.
Sounds like a sensible thing to do. To make sure the API
At 18:01 -0800 28 Dec 2012, Junio C Hamano wrote:
One lesson we learned long time ago while doing hooks is to avoid
unbound number of command line arguments and instead feed them from
the standard input. I think this should do the same.
Good point. I had been trying to keep the interface for
e here, use a longer name for the 'test' alias as well since that is
also short and meaningful enough to make it not unlikely that somebody
would have a command in their $PATH which will shadow that as well.
Signed-off-by: Aaron Schrab
---
t/t1020-subdirectory.sh | 12 ++--
1 fi
ushed, and even the source branches in some cases.
Signed-off-by: Aaron Schrab
---
Documentation/githooks.txt | 28 +
builtin/push.c |1 +
t/t5571-pre-push-hook.sh | 145
transport.c| 25
transp
: Aaron Schrab
---
templates/hooks--pre-push.sample | 63 ++
1 file changed, 63 insertions(+)
create mode 100644 templates/hooks--pre-push.sample
diff --git a/templates/hooks--pre-push.sample b/templates/hooks--pre-push.sample
new file mode 100644
index 000
compile time. This function will allow the caller of a hook
to determine the number of arguments to pass when preparing to call the
hook.
The first use of this function will be for a pre-push hook which will
add an argument for every reference which is to be pushed.
Signed-off-by: Aaron Schrab
r a script to easily determine
the set of commits that is being pushed, and thus make a decision if that
should be allowed.
The final patch adds a sample pre-push hook script which will deny
attempts to push commits that are marked as a work in progress.
Aaron Schrab (4):
hooks: Add function to ch
anticipated that the return value will
either be used as a boolean, or immediately added to an argv_array list
which would result in it being duplicated at that point.
Signed-off-by: Aaron Schrab
---
run-command.c | 15 +--
run-command.h |1 +
2 files changed, 14 insertions
At 10:04 -0500 20 Dec 2012, Jeff King wrote:
The problem seems to be that people are giving bad advice to tell
people to post "git config -l" output without looking at. Maybe we
could help them with a "git config --share-config" option that dumps
all config, but sanitizes the output. It would
At 18:07 -0500 27 Nov 2012, Jeff King wrote:
PS I also think the OP's "sockpuppet creates innocuous bugfix" above is
easier said than done. We do not have SHA-1 collisions yet, but if
the md5 attacks are any indication, the innocuous file will not be
completely clean; it will need to have
At 09:58 -0800 26 Nov 2012, Junio C Hamano wrote:
Kacper Kornet writes:
The change of order of parents happens at the very last moment, so
"ours" in merge options is local version and "theirs" upstream.
That may be something that wants to go to the proposed commit log
message. I am neutral
I came across this odd question on stackoverflow:
http://stackoverflow.com/q/13092854/1507392
If git diff is run with "..." as a separate argument between two
commit-ish arguments causes it to produce strange output. The
differences seem to be the same as if "..." was left out, but ch
53 matches
Mail list logo