or checkout the
[release notes in the
source](https://github.com/git/git/blob/master/Documentation/RelNotes/2.5.0.txt)
for all the nitty gritty details.
--8<--
I'll copy this over to a pull request so you have it there if you
think it's useful.
Again, thanks for the edition, love read
hangeset.author.name or changeset.author.emailAddress if you want to
filter on whose commits are included, or changeset.parents if you only
want to include merge commits.
There are plenty of options for more complex filtering, but that might
be able to help
Regards,
Andrew Ardill
--
To unsubscribe from this list: send th
nlikely that that is all that is going on is
due to you seeing the behaviour on a completely fresh OS and git
install.
If you are able to give more details in the bug report about how to
reproduce the behaviour that will help a lot too.
Regards,
Andrew Ardill
--
To unsubscribe from this list:
the same time as they update
other packages, but it would be interesting to know if people, for
example, only upgrade their managed environments every year/6 months
or something to avoid introducing changes to their users.
Regards,
Andrew Ardill
--
To unsubscribe from this list: send the l
Hi,
Jakub Narębski wrote:
> Andrew Ardill pisze:
> > Jakub Narębski wrote:
> >> 25. What [channel(s)] do you use to request/get help about Git [(if any)]
> >
> > It may also be useful to ask how people hear news about git, such as
> > when a new release com
-f to rename files on
case insensitive file systems.
Details at
https://stackoverflow.com/questions/17683458/how-do-i-commit-case-sensitive-only-filename-changes-in-git
Regards,
Andrew Ardill
rying to do as many microprojects as possible, leaving few
for other people.
Regards,
Andrew Ardill
--
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
the
commits?
My practical knowledge of notes is severely lacking so excuse me if I
missed anything obvious.
Regards,
Andrew Ardill
(sorry for the double post Junio, gmail ate my plain text encoding at
some point...)
--
To unsubscribe from this list: send the line "unsubscribe git"
may well cause more problems then
it fixes.
What I wonder is, in what situation is the current behaviour is desirable?
While I agree that the option works as designed, I think its behaviour
is more surprising to the end user then it should be.
Regards,
Andrew Ardill
--
To unsubscribe from this
s etc, but if so you could
make it implied only if we detect a terminal or something like is done
in other places.
Regards,
Andrew Ardill
--
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
esses over at Git Rev
News[0] straightforward and sensible, if you're looking for ideas.
Regards,
Andrew Ardill
[0] https://git.github.io/rev_news/rev_news/
the 'git flow' development methodology
(but doesn't require it).
A pretty good discussion of these ideas can be found at
https://stackoverflow.com/questions/7175869/managing-hotfixes-when-develop-branch-is-very-different-from-master
Regards,
Andrew Ardill
scripts to a built-in. I'm sure other people are too, and I'll
bet the ones who have been there before will have feedback for you as
well.
I'd find it interesting even if it was a 5-line bullet list of what's
going through your mind with respect to the project! Looking forward
to following along.
Regards,
Andrew Ardill
t
has happened to it.
Really enjoying your updates, by the way, they are very clear and show
what looks like great progress!
Regards,
Andrew Ardill
ing on how you do the revert.
Does that page describe what you're trying to do?
Regards,
Andrew Ardill
On 8 July 2017 at 07:07, Martin Langhoff wrote:
> Hi git-folk!
>
> long time no see! I'm trying to do one of those "actually, please
> don't" things
sk. See more at
https://en.wikipedia.org/wiki/Yes_(Unix)
I agree it's a little weird if you have no idea what it's doing, but
it is very useful and very old, used by many many different scripts
etc, and so unlikely to change.
Regards,
Andrew Ardill
ks like it might work for stash pop conflicts.
This one[1] shows how to create hooks that catch any conflicts that
are being committed, and would also probably work with stash
conflicts.
Teaching the tool to handle stash conflicts, or making any of the
above changes to the base distribution of git wo
, and it worked quite well, but nothing
further has been done to my knowledge.
[0] http://public-inbox.org/git/7vvc3d1o01@alter.siamese.dyndns.org/
Regards,
Andrew Ardill
replicated later on, but I don't want to add 4GB
of data to the repo every single time the dataset gets updated (also
every quarter). Storing that in LFS would be a good solution then.
Regards,
Andrew Ardill
EAD^ # 44.658s
$ time git checkout master # 38.267s
$ git gc
$ du -h --max-depth=1
1.3G./.git
3.4G.
$ time git checkout HEAD^ # 34.743s
$ time git checkout HEAD^ # 41.226s
Regards,
Andrew Ardill
On 25 July 2017 at 04:11, Jeff King wrote:
> On Mon, Jul 24, 2017 at 02:58:38PM +1000, Andrew Ardill wrote:
>
>> On 24 July 2017 at 13:45, Farshid Zavareh wrote:
>> > I'll probably test this myself, but would modifying and committing a 4GB
>> > text file actual
ions, and might
have an idea about how it could be localised if that was something
your community wanted to support.
Regards,
Andrew Ardill
[0] https://git.github.io/rev_news/
gards,
Andrew Ardill
On 16 August 2017 at 16:47, Kim Birkelund wrote:
> Apologies. I should obviously have mentioned which OSes the machines I
> tested on ran.
>
> One Windows 10 (fully updated) and one Windows Server 2016 (also
> updated). I've also seen it in a real repos
mits
> with bogus ident information, we changed it in 2012.
Maybe I am missing something obvious, but if that's the case then
can't we just do the identity check when trying to make new commits,
in which case you should be able to pull without setting your
identity?
Regards,
Andrew Ardill
Hi Anatoli,
On 21 August 2017 at 07:57, Anatolii Borodin wrote:
> On Sun, Aug 20, 2017 at 2:40 PM, Andrew Ardill
> wrote:
>> Maybe I am missing something obvious, but if that's the case then
>> can't we just do the identity check when trying to make new commits,
&g
vise not using & in branch names,
specifically because it is a special character in shells.
Regards,
Andrew Ardill
er change
to the commands logic.
Thus, my initial work was to refactor the internal naming to use the
terms with and without, as that would make a better place from which
to add other features (such as reversing the relationship direction,
or adding new adjective pairs).
Sorry if that is all confus
approved logos.
If there is not another location, or a more appropriate one,
https://github.com/git would be a good place to put this.
Regards,
Andrew Ardill
(I'm always concerned about making useless contributions to
conversations like this, but I think having a specific location for
resourc
ve
found to this file is at http://markmail.org/message/l7shxticxo3kzdpn
from Junio in a discussion around an RFD for ignore rules.
I think these three changes together would make the intended usage
more obvious to both new and old users, though each change could stand
on its own as well
/gsoc2014/tanayabh/5766466041282560
Regards,
Andrew Ardill
--
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
ith any bug tracking
solution; the solution is not obvious, and the current (very
customised) workflow is not supported directly by any tool.
Regards,
Andrew Ardill
[1] https://git-scm.atlassian.net
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to m
authenticator-osx
>
> As far as I can tell the feature is not supported. I'd like to be able to
> use the 2-step authentication but obviously I'd like to be able to push my
> code :D
I was under the impression that private key authentication worked
regardless of two-facto
iour.
> They are only displayed if
> they pass a minimum threshold of participation.
Out of interest, how is the threshold determined and is it configurable?
Regards,
Andrew Ardill
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord.
,
Andrew Ardill
--
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
me and I don't know what the cycle will look
like. Will be interesting to see how it progresses.
Regards,
Andrew Ardill
--
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
about git rebase, but it seems to tamper with commit numbers
> and looses tags.. Is there any other way to have it done ?
It sounds like a shallow checkout might be appropriate for you, try
looking that up.
Regards,
Andrew Ardill
--
To unsubscribe from this list: send the line &quo
Have you tried backslash escaping the backslash? double escaping?
I don't know how many are required, but I would try first \S, then
\\S, then S, etc
Regards,
Andrew Ardill
On 30 October 2013 12:34, Eugene Sajine wrote:
> Hi,
>
> I need some advice about creating the git
value
regardless of any other measures that might be introduced, such as Git
Traffic.
At the least it gives long time lurkers, and people who skim the list,
an easy way to put 'names to code', and it promotes the very people
who should be promoted.
Thanks to everyone involved in making thi
?
I think the git-flow and git-list style workflows have done a lot to
promote a set of usage patterns that keep this metadata around, I just
wonder if we can do more to assist users in what seems to be a
relatively common request.
Regards,
Andrew Ardill
--
To unsubscribe from this list: send th
and maybe there is something I am missing, but
there shouldn't be too much pain going that way.
Regards,
Andrew Ardill
--
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
folder to my other
git directories, and as such it would be extremely convenient if every
repository under that folder defaulted to the same profile. That may
be asking for too much though!
Regards,
Andrew Ardill
--
To unsubscribe from this list: send the line "unsubscribe git" in
th
a bit of use the edge cases will be a bit
clearer.
Again thanks, this will scratch an itch I didn't even realise I had.
Regards,
Andrew Ardill
--
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
On Mon, Aug 12, 2013 at 11:01:03PM +1000, Andrew Ardill wrote:
>On 12 August 2013 22:39, Jeff King wrote:
>> We could do something like the patch below, which allows:
>>
>> $ git config --global include./magic/.path .gitconfig-magic
>>
>> to read ~/.gitc
~/.gitconfig-magic
[include "magicrepos"]
mode = repo
param = "/magic/"
path = ~/.gitconfig-magic
Of the three I probably think the subsection chaining is the nicest
overall, though your original "repo:" proposal seems to be the easiest
to implement.
Reg
]
https://git.wiki.kernel.org/index.php/GitFaq#How_to_share_objects_between_existing_repositories.3F
Regards,
Andrew Ardill
--
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
an use git fsck to
> check for corruption. If things go wrong, you can always recover by replacing
> the alternates file and starting over).
Regards,
Andrew Ardill
--
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
make a back-up of your repository)
--no-hardlinks can be used.
So hardlinks should be used where possible, and if they are not try
upgrading Git.
I think that covers all the use cases you have?
Regards,
Andrew Ardill
--
To unsubscribe from this list: send the line "unsubscribe git" in
> ideal.
It is already possible to show multiple branches in gitk at the same
time. You probably have some more specific needs beyond simply showing
the different branches. Maybe you can be more specific?
Regards,
Andrew Ardill
--
To unsubscribe from this list: send the line "unsubscrib
d branches as part of the same swim-lane, as per current
behaviour, but to have separate branch heads in different swim-lanes.
This would be a nice feature, and is similar to the behaviour in, for
example, Atlassian's Fisheye repository viewer and the GitHub network
view.
Regards,
Andrew Ardil
other
gmail traffic has been fine over the period. Maybe somebody else knows
what happened :)
Regards,
Andrew Ardill
--
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
deed only contain the working directory,
and so doesn't include the history.
Hope that helps!
Regards,
Andrew Ardill
Regards,
Andrew Ardill
--
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
s into the same tree might be, or even if git would allow
it in general (maybe if you ignored everything belonging to the other
repository?) In any case, this solution could quickly become messy,
but if carefully controlled might solve your problem. Then again,
maybe you can achieve what you want
king at the remote repository's branch
but don't have a local copy of it, so any changes we make might be
'lost' (that is, not have an easy to find branch name).
Regards,
Andrew Ardill
--
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
'. So what does you mean
> by 'don't have a local copy'?
I should have been more clear. Here I mean that you don't have a local
copy of the branch reference. Your working directory is updated to be
in sync with the remote branch, but you haven't yet copied tha
it?
In any case, might be useful to make this behaviour more clear.
Regards,
Andrew Ardill
--
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
On 17 December 2012 18:21, Junio C Hamano wrote:
> does it format well (I didn't check)?
It applied cleanly for me on latest master, and the output looked
consistent with existing documentation.
Regards,
Andrew Ardill
--
To unsubscribe from this list: send the line "unsubscrib
Regards,
Andrew Ardill
On 17 December 2012 19:20, Johannes Sixt wrote:
> Am 12/17/2012 8:21, schrieb Junio C Hamano:
>> Chris Rorvick writes:
>>> 'git checkout' []::
>
> Is really optional in this form?
>
> BTW, what does plain 'git checkout&
visible without an account. Can you
transcribe the relevant parts?
Regards,
Andrew Ardill
--
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
cal use case it makes it clear what the
intended use of the command is, and some idea about the mechanics of
its function.
I realised that my signature was improperly placed when I submitted my
suggestion last, so I will include it here as reference for anyone who
skipped over it. It builds on top
On 18 December 2012 08:59, Junio C Hamano wrote:
> Andrew Ardill writes:
>> Even if the primary purpose of "git checkout " is to "check
>> out the branch so that further work is done on that branch", I don't
>> believe that means it has to be stated
On 18 December 2012 03:01, Toralf Förster wrote:
> On 12/17/2012 12:38 PM, Andrew Ardill wrote:
>> On 17 December 2012 21:23, Toralf Förster wrote:
>>> Hello,
>>>
>>> I'm faced with this situation :
>>> http://lists.ssl.berkeley.edu/mailman/pri
prepare for working with , detach HEAD at it
+ (see "DETACHED HEAD" section), and update the index and the
+ files in the working tree.
Regards,
Andrew Ardill
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord.
know that there might be sensitive information in the
output. Are there any use cases where prompting the user would be
annoying when using this command?
Regards,
Andrew Ardill
--
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
from a second snapshot, but if you
wanted to commit the resulting tree to the repository it would store a
third snapshot containing the exact state of all files.
Hopefully that clears it up for you?
Regards,
Andrew Ardill
--
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
m has been set.
Your proposed change would break all those. For that reason, it might
be nicer to introduce a flag that returns the config if it is set or
the default otherwise. Something like git config --value perhaps.
Regards,
Andrew Ardill
--
To unsubscribe from this list: send the line "unsu
bably too big a breaking change,
but a flag to change the behaviour might be nice. Then again, there
may be away to do what you want already :-)
Regards,
Andrew Ardill
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
r the short description to make it clear that they belong
together.
The only real 'new' information required is the short description, but
that could be replaced with the topic name if short description is not
available (or the topic name is self explanatory).
Most of the parsing benefit wo
On 14 September 2012 04:06, Junio C Hamano wrote:
> Andrew Ardill writes:
>
>> Currently, the output for each branch looks something like:
>> * ()
>> ()
>> [list-of-commits]
>> ()
>>
>>
>>
>>
>> and these are gro
On 14 September 2012 12:29, Junio C Hamano wrote:
> Andrew Ardill writes:
>
>> On 14 September 2012 04:06, Junio C Hamano wrote:
>>> Andrew Ardill writes:
>>>
>>>>
>>>>
>>>>
>>>>
>>>> * (
On 5 October 2012 12:20, Sitaram Chamarty wrote:
> On Fri, Oct 5, 2012 at 7:05 AM, demerphq wrote:
>> On 5 October 2012 03:00, Andrew Ardill wrote:
>>> On 5 October 2012 07:20, Marco Craveiro wrote:
>>>> ...
>>>> Similar but not quite; the idea is
r, can you?
>
> Not seeing any merit in the proposal (yet).
Would this allow setting up a project-default merge configuration for
contributors that defaulted to --humble? Not sure if that is useful or
not, but it at least seems safer than trying to default to doing reset
--hard after every m
tion is in my opinion to check what is going to be merged
before you merge it, but a tool to warn that someone else is modifying
the same file would have its uses.
Regards,
Andrew Ardill
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majo
is
simply the reference manual, but perhaps there is something else going
on here.
On another (related) note, the wayback machine has some very
interesting entries for the scm-git.org domain [1] and it seems the
/doc directory is not indexed at all. Is this on purpose?
Regards,
tential workflows that this would cause problems
for, such as if you sync directly to another user's repository and then try
and push those to a central server.
The most robust system would probably involve using signed tags to
verify what is being pushed, however I am not aware of any set-ups that
git checkout -f
??
Regards,
Andrew Ardill
--
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
s this?
I have been bitten by this before (the 'huh?' reaction) and think the
previous discussions and patch look reasonable. Does it need testing?
Further input??
Regards,
Andrew Ardill
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a
ined themselves not to do
> "git add -u" or "git commit -a".
Many people use git add -p by default, so I would not be surprised
about people not using -u or -a.
Regards,
Andrew Ardill
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of
ated in general.
Git add is also inconsistent with git add -p (although that might be
due to unclear documentation for -p). When in patch mode, git add will
propose deletions get added to the index as well, not just additions
and modifications.
Regards,
Andrew Ardill
--
To unsubscribe from this list:
discussing this.
Obviously I agree. I was actually bringing up a point about patch mode
and it got incorporated into the bigger picture; patch mode includes
deletions by default and I don't even know if you can turn that
behaviour off. So, when we talk about git add -u and git add -A, we
s
79 matches
Mail list logo
